From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 13 09:20:25 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24277DB3 for ; Mon, 13 Oct 2014 09:20:25 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D6D0D901 for ; Mon, 13 Oct 2014 09:20:24 +0000 (UTC) Received: from [89.15.237.217] (helo=unixarea.DDR.dd) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1Xdbnh-0006dF-QT for freebsd-hackers@freebsd.org; Mon, 13 Oct 2014 11:20:22 +0200 Received: from unixarea.DDR.dd (localhost [127.0.0.1]) by unixarea.DDR.dd (8.14.9/8.14.3) with ESMTP id s9D9KJ56002772 for ; Mon, 13 Oct 2014 11:20:19 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by unixarea.DDR.dd (8.14.9/8.14.3/Submit) id s9D9KIsV002771 for freebsd-hackers@freebsd.org; Mon, 13 Oct 2014 11:20:18 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: unixarea.DDR.dd: guru set sender to guru@unixarea.de using -f Date: Mon, 13 Oct 2014 11:20:18 +0200 From: Matthias Apitz To: freebsd-hackers@freebsd.org Subject: gmake && file time precision of 1 second Message-ID: <20141013092018.GA2737@unixarea.DDR.dd> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Operating-System: FreeBSD 11.0-CURRENT r269739 (i386) User-Agent: Mutt/1.5.23 (2014-03-12) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.15.237.217 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, 13 Oct 2014 09:20:25 -0000 Hello, I have a large project where a shell script fires up gmake runs in subdirs as: for dir in src norm print ....; do cd $dir gmake cd .. done in each subdir *.c are compiled to *.o and the resulting *.o are ar'ed into all the same lib.a; based on normal Makefile rules like: SRCS = f1.c f2.c OBJS = $(SRCS:.c=.o) .c.o: $(CC) -c ... $*.c lib.a:: $(OBJS) $(AR) $@ $(OBJS) after moving to a faster server it turned out that gmake sometimes forget to ar the *.o into the lib; I investigated it and it turned out that the *.o files have the same modification time (in seconds) as the target lib.a (which was produced/updated in the last directory worked on) and gmake thinks that the lib.a is uptodate. Any idea how to address this in the Makefiles? Well I could place (and it works) a 'sleep 1' into the loop, but I think that there is some better way. Thx matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 13 12:07:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8F2DEAA for ; Mon, 13 Oct 2014 12:07:20 +0000 (UTC) Received: from BAY004-OMC1S15.hotmail.com (bay004-omc1s15.hotmail.com [65.54.190.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0149A49 for ; Mon, 13 Oct 2014 12:07:20 +0000 (UTC) Received: from BAY169-W12 ([65.54.190.60]) by BAY004-OMC1S15.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 13 Oct 2014 05:06:14 -0700 X-TMN: [r9paJlsGz81aHeCtRZwZJanAC5lj99aAX7VRGg4nfAA=] X-Originating-Email: [tris_vern@hotmail.com] Message-ID: From: Tristan Verniquet To: Matthias Apitz , freebsd hackers Subject: RE: gmake && file time precision of 1 second Date: Mon, 13 Oct 2014 22:06:14 +1000 Importance: Normal In-Reply-To: <20141013092018.GA2737@unixarea.DDR.dd> References: <20141013092018.GA2737@unixarea.DDR.dd> MIME-Version: 1.0 X-OriginalArrivalTime: 13 Oct 2014 12:06:14.0529 (UTC) FILETIME=[161EF710:01CFE6DE] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 12:07:20 -0000 We have this problem too using recursive make and I am interested in =0A= what other solutions there are. Currently we sleep until the start of the n= ext =0A= second using a custom binary=2C but it does slow down the =0A= build. Another thing I've tried though haven't put much thought into is touching t= he lib file -1 second after each ar command. Tristan > Date: Mon=2C 13 Oct 2014 11:20:18 +0200 > From: guru@unixarea.de > To: freebsd-hackers@freebsd.org > Subject: gmake && file time precision of 1 second >=20 >=20 > Hello=2C >=20 > I have a large project where a shell script fires up > gmake runs in subdirs as: >=20 > for dir in src norm print ....=3B do=20 > cd $dir > gmake > cd .. > done >=20 > in each subdir *.c are compiled to *.o and the resulting *.o are ar'ed > into all the same lib.a=3B based on normal Makefile rules like: >=20 > SRCS =3D f1.c f2.c > OBJS =3D $(SRCS:.c=3D.o) >=20 > .c.o: > $(CC) -c ... $*.c >=20 > lib.a:: $(OBJS) > $(AR) $@ $(OBJS) >=20 >=20 > after moving to a faster server it turned out that gmake sometimes forget > to ar the *.o into the lib=3B I investigated it and it turned out that th= e > *.o files have the same modification time (in seconds) as the target > lib.a (which was produced/updated in the last directory worked on) and > gmake thinks that the lib.a is uptodate. >=20 > Any idea how to address this in the Makefiles? >=20 > Well I could place (and it works) a 'sleep 1' into the loop=2C but I thin= k > that there is some better way. >=20 > Thx >=20 > matthias > --=20 > Matthias Apitz | /"\ ASCII Ribbon Campaign: > E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail > WWW: http://www.unixarea.de/ | X - No proprietary attachments > phone: +49-170-4527211 | / \ - Respect for open standards > | en.wikipedia.org/wiki/ASCII_Ribbon_Campaig= n > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe=2C send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" = From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 13 12:29:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BE0F41C for ; Mon, 13 Oct 2014 12:29:36 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 226D1C27 for ; Mon, 13 Oct 2014 12:29:35 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id n3so7264362wiv.15 for ; Mon, 13 Oct 2014 05:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=EDIyS6BjoTJtGaCREdvkZmAxz/NK32k0IypVuOrdpoE=; b=pbYzKTZuPCx7ZWlg4EhoqMAD3AzciX0Tvd+WLnW35FS40AjcGi0K6mgjnZSOKdaau1 1YiJyNAs8pz7mt7Gm3pJQWtKp5pT52XzzK4OWAbHDkB/WZakqwQWVHrq5g7hYxQVUyjs Q70gBddX6pF3LtgPZe9cS7uxxLnCamIS2Zwvfq2hMhMI1Hivn9pjd10bOdEZ1ZTsTrYn GVSZc+PYAodZAtsfCG8wLVEveutc2Fpvo+yBJtBwoEafhY0FsPTNSsgxGY+fz4jDuX33 O7qxSQhjNZ+NyPHG+EPWd+Efn20YzJFXOhv3bO5QPq3Qhs+ln0XBrfYOsGTXmcBoJuRW wgug== X-Received: by 10.194.121.33 with SMTP id lh1mr3013376wjb.78.1413203373962; Mon, 13 Oct 2014 05:29:33 -0700 (PDT) Received: from gumby.homeunix.com (5ec1f671.skybroadband.com. [94.193.246.113]) by mx.google.com with ESMTPSA id cu9sm16520011wjc.3.2014.10.13.05.29.32 for (version=SSLv3 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Oct 2014 05:29:33 -0700 (PDT) Date: Mon, 13 Oct 2014 13:29:26 +0100 From: RW To: freebsd-hackers@freebsd.org Subject: Re: GBDE not protecting the user Message-ID: <20141013132926.164cece9@gumby.homeunix.com> In-Reply-To: <20141011074412.GA9432@mail.michaelwlucas.com> References: <20141010215842.GA6717@mail.michaelwlucas.com> <20141011113008.705ba16d@X220.alogt.com> <20141011074412.GA9432@mail.michaelwlucas.com> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) 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, 13 Oct 2014 12:29:36 -0000 On Sat, 11 Oct 2014 03:44:12 -0400 Michael W. Lucas wrote: > On Sat, Oct 11, 2014 at 11:30:08AM +0800, Erich Dollansky wrote: > > Hi, > > > > On Fri, 10 Oct 2014 17:58:42 -0400 > > "Michael W. Lucas" wrote: > > > > > [Tried questions@, no answer, and the code contains things I just > > > cannot trigger.] > > > > > just try geli. It works for me. What I like most is that you can > > have key and password on external media. No external media - no > > decyphering. > > GELI does not verify key destruction when the correct passphrase is > used. There are use cases where this is very important--e.g., finance. You can overwrite the geli metadata on the end of the provider with dd. Preferably the whole partition if you want to be sure because anyone that's ever had access to the disk could have copied the metadata. If you are going to use a passphrase I'd recommend geli which has password strengthening. > I'd really like to include GBDE in my FreeBSD storage book, but it > seems that it doesn't actually work. > > ==ml > From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 13 13:06:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09037C2E; Mon, 13 Oct 2014 13:06:47 +0000 (UTC) Received: from mailout12.t-online.de (mailout12.t-online.de [194.25.134.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BCC75FBC; Mon, 13 Oct 2014 13:06:46 +0000 (UTC) Received: from fwd35.aul.t-online.de (fwd35.aul.t-online.de [172.20.27.145]) by mailout12.t-online.de (Postfix) with SMTP id 6063E14E986; Mon, 13 Oct 2014 14:59:07 +0200 (CEST) Received: from [192.168.119.10] (G5NOUMZ6Yh7tAht2WeGhe3XS-FPk52S3gG4w8kl51CGSvv8q3+Fal0r3lHPrLZxZpt@[84.154.118.168]) by fwd35.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XdfDO-38hAw40; Mon, 13 Oct 2014 14:59:06 +0200 Message-ID: <543BCC97.7080608@freebsd.org> Date: Mon, 13 Oct 2014 14:59:03 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Matthias Apitz Subject: Re: gmake && file time precision of 1 second References: <20141013092018.GA2737@unixarea.DDR.dd> In-Reply-To: <20141013092018.GA2737@unixarea.DDR.dd> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ID: G5NOUMZ6Yh7tAht2WeGhe3XS-FPk52S3gG4w8kl51CGSvv8q3+Fal0r3lHPrLZxZpt X-TOI-MSGID: e5570e22-252f-4210-a6d8-0a3ec0bddc00 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, 13 Oct 2014 13:06:47 -0000 Am 13.10.2014 um 11:20 schrieb Matthias Apitz: > > Hello, > > I have a large project where a shell script fires up > gmake runs in subdirs as: > > for dir in src norm print ....; do > cd $dir > gmake > cd .. > done > > in each subdir *.c are compiled to *.o and the resulting *.o are ar'ed > into all the same lib.a; based on normal Makefile rules like: > > SRCS = f1.c f2.c > OBJS = $(SRCS:.c=.o) > > .c.o: > $(CC) -c ... $*.c > > lib.a:: $(OBJS) > $(AR) $@ $(OBJS) > > > after moving to a faster server it turned out that gmake sometimes forget > to ar the *.o into the lib; I investigated it and it turned out that the > *.o files have the same modification time (in seconds) as the target > lib.a (which was produced/updated in the last directory worked on) and > gmake thinks that the lib.a is uptodate. > > Any idea how to address this in the Makefiles? > > Well I could place (and it works) a 'sleep 1' into the loop, but I think > that there is some better way. Could this be a solutionn for you: $ sysctl -d vfs.timestamp_precision vfs.timestamp_precision: File timestamp precision (0: seconds, 1: sec + ns accurate to 1/HZ, 2: sec + ns truncated to ms, 3+: sec + ns (max. precision)) Beware: This is a global variable, higher resolution timestamps are not supported on all filesystems, and not all programs check for the sub-second part of the timestamp value ... Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 13 23:01: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 461BAE48 for ; Mon, 13 Oct 2014 23:01:01 +0000 (UTC) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 EC43CC96 for ; Mon, 13 Oct 2014 23:01:00 +0000 (UTC) X-AuditID: 1209190d-f79c06d000006f95-e5-543c59a5d592 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id E4.C7.28565.5A95C345; Mon, 13 Oct 2014 19:00:53 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s9DN0q6U014117; Mon, 13 Oct 2014 19:00:53 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9DN0oQj013648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Oct 2014 19:00:51 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9DN0ohh011558; Mon, 13 Oct 2014 19:00:50 -0400 (EDT) Date: Mon, 13 Oct 2014 19:00:49 -0400 (EDT) From: Benjamin Kaduk To: Matthias Apitz Subject: Re: gmake && file time precision of 1 second In-Reply-To: <20141013092018.GA2737@unixarea.DDR.dd> Message-ID: References: <20141013092018.GA2737@unixarea.DDR.dd> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixG6nors00ibEoKtX2mL75n+MFvcvX2Nx YPKY8Wk+i8fSA3OYA5iiuGxSUnMyy1KL9O0SuDK2bdjBWLCDseLtxb/MDYx9jF2MnBwSAiYS jzZeZ4ewxSQu3FvP1sXIxSEkMJtJ4sjXlcwQzkZGia1fVzBCOIeYJL6vW8UE4TQwSrxd08/S xcjBwSKgLXFysinIKDYBFYmZbzaygdgiAqoSn7c/ZwKxmQXkJS5sPgS2WljAVGL6nTYWEJsT 6IxF91eA2bwCjhLXfi8Cs4UEjCW+f5gLNkdUQEdi9f4pUDWCEidnPmGBmKklsXz6NpYJjIKz kKRmIUktYGRaxSibklulm5uYmVOcmqxbnJyYl5dapGukl5tZopeaUrqJERSqnJK8OxjfHVQ6 xCjAwajEw6tYax0ixJpYVlyZe4hRkoNJSZT3YLhNiBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR 3rchQDnelMTKqtSifJiUNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQneJRFAjYJFqemp FWmZOSUIaSYOTpDhPEDDP4DU8BYXJOYWZ6ZD5E8xGnPsaX/Zy8TR0vS2l0mIJS8/L1VKnJcN mDCEBEBKM0rz4KbB0s0rRnGg54R5f4MM5AGmKrh5r4BWMQGtel1sDbKqJBEhJdXAmMVwPsUt 20ske/3l4hNnpf5zF3G8nVK3u7Nz77U/Qb8Ukv51X5DWX7ZQ8Vv5Gkf2nzYN96zfXBSYr66y MmTx1Wuzu6y8ctRfdTaWlPz20k1neHldPLBk4ZFfN6Y2HVnZIV32ketGlkdeSpcQe9uzlfZW H4+b/75t9KS0PnNaoezNM+q+q6XqlFiKMxINtZiLihMBKwtF9xIDAAA= 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, 13 Oct 2014 23:01:01 -0000 On Mon, 13 Oct 2014, Matthias Apitz wrote: > after moving to a faster server it turned out that gmake sometimes forget What is the filesystem being uesd on that server? -Ben From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 14 01:46:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C65ACC6 for ; Tue, 14 Oct 2014 01:46:24 +0000 (UTC) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (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 E7A116E for ; Tue, 14 Oct 2014 01:46:23 +0000 (UTC) Received: by quine.pinyon.org (Postfix, from userid 122) id 818451603CB; Mon, 13 Oct 2014 18:38:35 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (feyerabend.n1.pinyon.org [10.0.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id 78DE7160170 for ; Mon, 13 Oct 2014 18:38:33 -0700 (MST) Message-ID: <543C7E99.60802@pinyon.org> Date: Mon, 13 Oct 2014 18:38:33 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: gmake && file time precision of 1 second References: <20141013092018.GA2737@unixarea.DDR.dd> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 01:46:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/13/14 16:00, Benjamin Kaduk wrote: > On Mon, 13 Oct 2014, Matthias Apitz wrote: > >> after moving to a faster server it turned out that gmake >> sometimes forget > > What is the filesystem being uesd on that server? And is it mounted over NFS (can't tell from the original message). Russell > > -Ben _______________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUPH6ZAAoJEFnLrGVSDFaE138QAKcgVb3hNWuCxNQY+sMc+vj1 EKqOZd0SwjOpNbjPtbIdTYM18KY64jRD2xYQ+CmvlbC3AwkMUxL46ju2TnGpGMA8 Cd4I9TCVxpCiO9JDDabFILNZ2CC3q8eLjj3AJPgSmCz9mLx92zo5+ujOvAuE2lsz qUz8vUUXql5X/U88e6DMIe/UGLVVdJiuZUZLreHtTR4PcSsJNkKSW9oW5Y+MIpcW 3is17poM1gbFNvZQE4OCcfwwrQ8u4LcZRXZMVPIAUpLt+XwFnEDbmAHxwRC/6zyG YR8pT6g/Tpc/ESOchAjiihRiXvyTKpzz1k00AYH2qXJ3RCDUU+EIp1HZD0mjtB9i SK/TR2Y++Kx3fDCxUNaHdCV7YmdGjfJ3RG44Wr64jQ+Q5bF6juONndGF3B/4Lrl1 yHdXur5+drj5YxVFBUmR69U3TwFHvERFQ9e5VzupR+cx2ZNaMJ83fW3wPPAiAZSy nvjOyw2ELie6aDj4lqCL85W1aoemobjVL1FE1i5Bv7U+sOn0BvyBXDnjqr+eR/hv zRY8pJGZju9sPFHzna8IQMeBDG5snR26Gkhb0FBxSYWFBwjQngBBpMxVtXEyWYP3 +tf6ciThBL+mb6BWuMuIeKpMR/kQc5cakvZI9HdJJvCBjt3N8afdvtZE3jjtR74D NOOPYUZ+WsilaBBSCd33 =GQu/ -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 14 02:40:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1315130E for ; Tue, 14 Oct 2014 02:40:24 +0000 (UTC) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (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 DB2346B4 for ; Tue, 14 Oct 2014 02:40:23 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id r10so6616748pdi.38 for ; Mon, 13 Oct 2014 19:40:22 -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=fXquTGTEXE1S/fw9Xoa430BHuhv/uu1UidWhLNs/lxk=; b=UNhH4g/0OV8DeY4ZY/IbLTqOYNpbkpW29099E4F95ZNcZktY+8sbRg3EkTncewWfrT EwacTKW6IsunR3wY0KyDRlgm1WI30XbN3Jp9ukz4n38raAcbbqE9NOx4I5A3j5TRZSE/ 3yC3dseoTL8RQDnzIWNnylEbUT3sfw4fsfeX4tlzMWgr4bz0ZEpuRILDy6xGghXqm9wy zwF7PNbll079reCORb55N2dkY3y1fgCukDkNQR7/FsGHXkb4LzEkOLZADWmlhhxK2SJq 360Toonb8aizNYDfRAByS1GCd4xfI2xndxhYq42l+TdPvXAwYRrPy/1Ea5vnT2b8p1YH WPBQ== X-Gm-Message-State: ALoCoQmn+LVWYg660/JUsXzhdMANO7VtIYiWtJ142fXltMZMJ1y3xPX0Ld/4VU2aWnZOT0DpSOQr X-Received: by 10.70.62.74 with SMTP id w10mr660656pdr.140.1413254422734; Mon, 13 Oct 2014 19:40:22 -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 h6sm8754482pdk.38.2014.10.13.19.40.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Oct 2014 19:40:22 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: gmake && file time precision of 1 second From: Tim Kientzle In-Reply-To: <20141013092018.GA2737@unixarea.DDR.dd> Date: Mon, 13 Oct 2014 19:40:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141013092018.GA2737@unixarea.DDR.dd> To: Matthias Apitz 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: Tue, 14 Oct 2014 02:40:24 -0000 On Oct 13, 2014, at 2:20 AM, Matthias Apitz wrote: >=20 > Hello, >=20 > I have a large project where a shell script fires up > gmake runs in subdirs as: >=20 > for dir in src norm print ....; do=20 > cd $dir > gmake > cd .. > done >=20 > in each subdir *.c are compiled to *.o and the resulting *.o are ar'ed > into all the same lib.a; based on normal Makefile rules like: >=20 > SRCS =3D f1.c f2.c > OBJS =3D $(SRCS:.c=3D.o) >=20 > .c.o: > $(CC) -c ... $*.c >=20 > lib.a:: $(OBJS) > $(AR) $@ $(OBJS) >=20 >=20 > after moving to a faster server it turned out that gmake sometimes = forget > to ar the *.o into the lib; I investigated it and it turned out that = the > *.o files have the same modification time (in seconds) as the target > lib.a (which was produced/updated in the last directory worked on) and > gmake thinks that the lib.a is uptodate. >=20 > Any idea how to address this in the Makefiles? Instead of updating the same lib.a from every makefile, instead consider = creating a separate lib.a in each directory and then combining them at = the end. Combining .a libraries is a little tricky: Try creating a dir, = extracting each lib.a into that same directory, then creating a new = lib.a. It might be possible to combine them directly using tar = =97format=3Dar but I=92ve not tried it. Cheers, Tim From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 14 07:10:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 553C0372; Tue, 14 Oct 2014 07:10:57 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 66DD0E8; Tue, 14 Oct 2014 07:10:56 +0000 (UTC) Received: from [89.204.137.254] (helo=unixarea.DDR.dd) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1XdwFw-0007hQ-IV; Tue, 14 Oct 2014 09:10:53 +0200 Received: from unixarea.DDR.dd (localhost [127.0.0.1]) by unixarea.DDR.dd (8.14.9/8.14.3) with ESMTP id s9E7Ai4E001627; Tue, 14 Oct 2014 09:10:45 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by unixarea.DDR.dd (8.14.9/8.14.3/Submit) id s9E7Af11001626; Tue, 14 Oct 2014 09:10:41 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: unixarea.DDR.dd: guru set sender to guru@unixarea.de using -f Date: Tue, 14 Oct 2014 09:10:40 +0200 From: Matthias Apitz To: Stefan Esser Subject: Re: gmake && file time precision of 1 second Message-ID: <20141014071040.GA1596@unixarea.DDR.dd> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , Stefan Esser , freebsd-hackers@freebsd.org References: <20141013092018.GA2737@unixarea.DDR.dd> <543BCC97.7080608@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <543BCC97.7080608@freebsd.org> X-Operating-System: FreeBSD 11.0-CURRENT r269739 (i386) User-Agent: Mutt/1.5.23 (2014-03-12) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.137.254 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 07:10:57 -0000 El día Monday, October 13, 2014 a las 02:59:03PM +0200, Stefan Esser escribió: > > after moving to a faster server it turned out that gmake sometimes forget > > to ar the *.o into the lib; I investigated it and it turned out that the > > *.o files have the same modification time (in seconds) as the target > > lib.a (which was produced/updated in the last directory worked on) and > > gmake thinks that the lib.a is uptodate. > > > > Any idea how to address this in the Makefiles? > > > > Well I could place (and it works) a 'sleep 1' into the loop, but I think > > that there is some better way. > > Could this be a solutionn for you: > > $ sysctl -d vfs.timestamp_precision > vfs.timestamp_precision: File timestamp precision (0: seconds, 1: sec + > ns accurate to 1/HZ, 2: sec + ns truncated to ms, 3+: sec + ns (max. > precision)) > > Beware: This is a global variable, higher resolution timestamps are > not supported on all filesystems, and not all programs check for the > sub-second part of the timestamp value ... Thanks. I was hoping that there is a Makefile solution in the sense that if objs and target lib have the same age (i.e. the same second of age), that gmake assumes that the obj is newer. We will re-think our Makefiles, write into different lib.a and merge them in a final step by unpacking the libs with ar again. Thx matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 14 16:34:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA018517 for ; Tue, 14 Oct 2014 16:34:21 +0000 (UTC) Received: from mail.michaelwlucas.com (mail.michaelwlucas.com [108.61.84.26]) (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 840AC374 for ; Tue, 14 Oct 2014 16:34:21 +0000 (UTC) Received: from mail.michaelwlucas.com (localhost [127.0.0.1]) by mail.michaelwlucas.com (8.14.7/8.14.7) with ESMTP id s9EGY8XD026515; Tue, 14 Oct 2014 12:34:09 -0400 (EDT) (envelope-from mwlucas@mail.michaelwlucas.com) Received: (from mwlucas@localhost) by mail.michaelwlucas.com (8.14.7/8.14.7/Submit) id s9EGY8Qv026514; Tue, 14 Oct 2014 12:34:08 -0400 (EDT) (envelope-from mwlucas) Date: Tue, 14 Oct 2014 12:34:05 -0400 From: "Michael W. Lucas" To: RW Subject: Re: GBDE not protecting the user Message-ID: <20141014163405.GA26488@mail.michaelwlucas.com> References: <20141010215842.GA6717@mail.michaelwlucas.com> <20141011113008.705ba16d@X220.alogt.com> <20141011074412.GA9432@mail.michaelwlucas.com> <20141013132926.164cece9@gumby.homeunix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141013132926.164cece9@gumby.homeunix.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.michaelwlucas.com Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 16:34:21 -0000 On Mon, Oct 13, 2014 at 01:29:26PM +0100, RW wrote: > You can overwrite the geli metadata on the end of the provider with dd. > Preferably the whole partition if you want to be sure because anyone > that's ever had access to the disk could have copied the metadata. > > If you are going to use a passphrase I'd recommend geli which has > password strengthening. If Mallory is holding a gun to my head, I want the computer to say "The passphrase entered by the user is correct, but the on-disk decryption keys no longer exist. The user has cooperated fully. Please don't shoot him." GELI does not do this. It's designed for a different threat model. That's not a problem, or a weakness. GBDE does. Or, rather, it's supposed to. Hence this bug report. It's an unusual use case, yes. But the people who need this functionality REALLY need it. ==ml -- Michael W. Lucas - mwlucas@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 14 16:35:38 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A7C9659 for ; Tue, 14 Oct 2014 16:35:38 +0000 (UTC) Received: from mail.michaelwlucas.com (mail.michaelwlucas.com [108.61.84.26]) (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 4AA9A3A0 for ; Tue, 14 Oct 2014 16:35:38 +0000 (UTC) Received: from mail.michaelwlucas.com (localhost [127.0.0.1]) by mail.michaelwlucas.com (8.14.7/8.14.7) with ESMTP id s9EGZWPT026530; Tue, 14 Oct 2014 12:35:32 -0400 (EDT) (envelope-from mwlucas@mail.michaelwlucas.com) Received: (from mwlucas@localhost) by mail.michaelwlucas.com (8.14.7/8.14.7/Submit) id s9EGZWLJ026529; Tue, 14 Oct 2014 12:35:32 -0400 (EDT) (envelope-from mwlucas) Date: Tue, 14 Oct 2014 12:35:31 -0400 From: "Michael W. Lucas" To: "Michael W. Lucas" Subject: Re: GBDE not protecting the user Message-ID: <20141014163531.GB26488@mail.michaelwlucas.com> References: <20141010215842.GA6717@mail.michaelwlucas.com> <20141011113008.705ba16d@X220.alogt.com> <20141011074412.GA9432@mail.michaelwlucas.com> <54394A03.6060403@freebsd.org> <20141011175944.GA11131@mail.michaelwlucas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141011175944.GA11131@mail.michaelwlucas.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.michaelwlucas.com Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 16:35:38 -0000 On Sat, Oct 11, 2014 at 01:59:44PM -0400, Michael W. Lucas wrote: > On Sat, Oct 11, 2014 at 11:17:23AM -0400, Allan Jude wrote: > > Michael: please file a PR on this now that it is confirmed, and together > > we can nag someone to fix it. > > Fair enough. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194304 Following up on my own bug report: This seems to be a generic GBDE error message breakage. Here I change key 0's passphrase and key file. # gbde setkey da0p1 -n 0 -l da0p1.lock -k rat.jpg -L da0p1.lock-new Enter passphrase: Opened with key 0 Enter new passphrase: Reenter new passphrase: I now have a new lock file with a new passphrase. Let's try the old key file and see what happens. It appears to work, except it doesn't. # gbde attach da0p1 -l da0p1.lock -k rat.jpg Enter passphrase: # ls /dev/da0p1* /dev/da0p1 # gbde detach da0p1 gbde: Detach of da0p1 failed: Geom not found: "da0p1.bde" The new lock file and passphrase do work. I would have expected the attach command to call me an idiot rather than fail silently. An ignorant, uneducated, non-programmer look at the code encourages my belief. Bug report updated. ==ml -- Michael W. Lucas - mwlucas@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 14 21:59:11 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C12CED0; Tue, 14 Oct 2014 21:59:11 +0000 (UTC) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 7F8BEC83; Tue, 14 Oct 2014 21:59:10 +0000 (UTC) X-AuditID: 1209190f-f79aa6d000005b45-77-543d9ca69b7d Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 60.B8.23365.6AC9D345; Tue, 14 Oct 2014 17:59:02 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s9ELx1EE026774; Tue, 14 Oct 2014 17:59:02 -0400 Received: from localhost (mass-toolpike.mit.edu [18.9.64.17]) (authenticated bits=0) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9ELx0Zp008940; Tue, 14 Oct 2014 17:59:01 -0400 Date: Tue, 14 Oct 2014 17:59:00 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@mass-toolpike.mit.edu To: freebsd-hackers@FreeBSD.org Subject: FreeBSD Quarterly Status Report - Third Quarter 2014 Message-ID: User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixCmqrbtsjm2Iwc1NJha7rp1mt5jz5gOT xfbN/xgtDjcLObB4zPg0nyWAMYrLJiU1J7MstUjfLoEro3nHRLaC/1+YK+ZO+8bcwHi9i7mL kZNDQsBEounLF0YIW0ziwr31bF2MXBxCArOZJHb9usQC4WxklPi1ZyoThPOJUWLnze1sIC0s AtoSM3vfgo1iE1CTWL/iGtRYdYnP8xeCjRURkJfY1/SeHcRmFrCWaFn5grWLkYNDWMBW4t6F dJAwr4C7xMyWX2DlogK6Eof+/WGDiAtKnJz5hAWi1V/i+bzN7BMY+WchSc1CkoKwdSSmTFzB CGFrS9y/2ca2gJFlFaNsSm6Vbm5iZk5xarJucXJiXl5qka6JXm5miV5qSukmRnDQSvLvYPx2 UOkQowAHoxIPb0GkTYgQa2JZcWXuIUZJDiYlUd7ZfbYhQnxJ+SmVGYnFGfFFpTmpxYcYJTiY lUR47ZOBcrwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKErx5s4EaBYtS 01Mr0jJzShDSTBycIMN5gIbHg9TwFhck5hZnpkPkTzHacxzreNnLxNHzGUR++AUiH+z+M4FJ iCUvPy9VSpy3DKRNAKQtozQPbjIsIb1iFAd6VJjXDKSKB5jM4Ga/AlrLBLR2YijY2pJEhJRU A6PPtK43un9vl1n/3fzbvCp0YWa47geFXY1KLMJbl53Pk7lx6Z2D5mFrXoMP1z9HXwhrvMta d3j1klmm2osZnWx9THeGdU7f+uFYrn3GxrCj2i8vey2tWNgiIrdqFYP4fsU01j0VZ5++YfJ9 yBMRwhPLGGHT1Rw177saj5yq18zLC9+e82bRMFRiKc5INNRiLipOBAD90mepIwMAAA== Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 21:59:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 FreeBSD Project Quarterly Status Report: July - September 2014 This report covers FreeBSD-related projects between July and September 2014. This is the third of four reports planned for 2014. The third quarter of 2014 was another productive quarter for the FreeBSD project. A lot of work has been done on various ARM platforms, with the goal of bringing them to Tier 1 status in FreeBSD 11. The various ports teams have also worked hard to improve the state of FreeBSD as a desktop operating system. As usual, performance improvements feature in several places in this report and many of these can benefit from user benchmarking to validate our results. Thanks to all the reporters for the excellent work! The deadline for submissions covering the period from October to December 2014 is January 7th, 2015. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Cluster Administration Team * FreeBSD Release Engineering Team * Ports Collection * The FreeBSD Core Team Projects * Address Space Layout Randomization (ASLR) * amd64 Xen Paravirtualization * bhyve * Chelsio iSCSI Offload Support * Debian GNU/kFreeBSD * FreeBSD Preseed Installation (PXE) * Jenkins Continuous Integration for FreeBSD * New Automounter * QEMU bsd-user-Enabled Ports Building * VMWare VAAI and Microsoft ODX Acceleration in CTL * ZFSguru Kernel * Intel GPU Driver Update * SDIO Driver * UEFI Boot * Updated vt(4) System Console * Updating OpenCrypto Architectures * FreeBSD on Newer ARM Boards * FreeBSD/arm64 Userland Programs * LLDB Debugger Port * LLVM Address Sanitizer (Asan) * SSE Variants of libc Routines for amd64 Ports * FreeBSD Python Ports * GNOME/FreeBSD * KDE on FreeBSD * The Graphics Stack on FreeBSD * Xfce Documentation * Handbook ezjail Section * Michael Lucas Books * ZFS Chapter of the Handbook Miscellaneous * The FreeBSD Foundation __________________________________________________________________ FreeBSD Cluster Administration Team Contact: FreeBSD Cluster Administration Team The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the project relies on for its distributed work and communications to be synchronised. In this quarter, the team has worked on: * Implemented a central, FreeBSD cluster-specific package building node using ports-mgmt/poudriere-devel, providing a single consistent set of third-party binary packages throughout the FreeBSD cluster from a common, known-working configuration. * Converted all machines running in the FreeBSD cluster from individual (and sometimes different) userland and kernel configurations to a single configuration for the base system. This enabled the implementation of a FreeBSD.org-specific binary update mechanism currently deployed throughout the cluster. This project is sponsored by The FreeBSD Foundation . __________________________________________________________________ FreeBSD Release Engineering Team URL: http://www.freebsd.org/releases/10.1R/schedule.html URL: http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. In mid-July, FreeBSD 9.3-RELEASE was released without delay in release cycle. In late August, the FreeBSD 10.1-RELEASE cycle began, and as of this writing, is expected to stay on schedule. Work to produce virtual machine images as part of the release cycle has continued, supporting various cloud services such as Microsoft Azure, Amazon EC2, and Google Compute Engine. This project is sponsored by The FreeBSD Foundation . __________________________________________________________________ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.freebsd.org/index.html URL: http://portscout.freebsd.org/ URL: http://www.freebsd.org/portmgr/index.html URL: http://blogs.freebsdish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr URL: http://plus.google.com/communities/108335846196454338383 Contact: Frederic Culot Contact: Port Management Team As of the end of Q3, the ports tree holds a bit more than 24,000 ports, and the PR count is below 1,400. Despite the summer holidays the tree saw sustained activity with more than 9,000 commits and almost 2,000 ports PRs closed! In Q3, five new developers were granted a ports commit bit. None were taken in for safekeeping. On the management side, tabthorpe@ decided to step down from his portmgr duties in July. No other changes were made to the team during Q3. This quarter also saw the release of the third quarterly branch, namely 2014Q3. On the QA side, 34 exp-runs were performed to validate sensitive updates or cleanups. Last, the 20th anniversary of the ports tree was commemorated during Q3 and a video was published for this event. Open tasks: 1. Tremendous work was done on the PR front in Q3 and we would be very pleased to see committers dedicate themselves to closing as many as possible in Q4 as well. __________________________________________________________________ The FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team constitutes the project's "Board of Directors", responsible for deciding the project's overall goals and direction as well as managing specific areas of the FreeBSD project landscape. The third quarter of this year was a relatively quiet time in terms of Core Team activity. No major policy changes were decided, but the criterea for awarding commit bits were reviewed and the existing requirements were clarified and documented at http://www.freebsd.org/interna=B3proposing-committers.html. Other items dealt with by core during this period: * Confirmed with Microsoft that it is permissible to include DCTCP in FreeBSD. * Promoted git-beta.freebsd.org out of beta-test to an official service, consequently renaming it to git.freebsd.org. * Mediated between groups of contributors and committers adopting different positions on the on-going work to introduce ASLR and associated technologies. * Worked with the FreeBSD Foundation to obtain a license for XenForo, and with the forum administrators on plans to migrate the FreeBSD forums onto the FreeBSD cluster and to switch to XenForo. During this period, three commit bits were granted, and two commit bits were taken in for safe keeping. __________________________________________________________________ Address Space Layout Randomization (ASLR) URL: http://hardenedbsd.org/ URL: https://reviews.freebsd.org/D473 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193940 URL: https://wiki.freebsd.org/201409DevSummit/ASLR URL: https://wiki.freebsd.org/AddressSpaceLayoutRandomization Contact: Shawn Webb Contact: Oliver Pinter Address Space Layout Randomization (ASLR) is a computer security technique that aids in mitigating low-level vulnerabilities such as buffer overflows. ASLR randomizes the memory layout of running applications, to prevent an attacker from knowing where a given exploitable vulnerability lies in memory. A lot has happened in the last few months. Shawn Webb gave presentations at both BSDCan 2014 and EuroBSDCon 2014. The presentations were met with a lot of support and backing. At the end of EuroBSDCon Ilya Bakulin fixed the known bug with ASLR on ARM systems. Shawn Webb and Oliver Pinter have submitted our patch to the Phabricator code review system. Shawn Webb added an API for allowing a debugger to disable ASLR to support deterministic debugging. Oliver Pinter enhanced the performance of our ASLR implementation. A package building exp-run was ran and came out favorably in terms of performance. Shawn Webb bumped up the maximum number of bits allowed to be randomized to 20 and set the default to 14. Shawn Webb and Oliver Pinter founded The HardenedBSD project to serve as a staging area for their work on security-related projects for FreeBSD. This project is sponsored by SoldierX. Open tasks: 1. Get more people testing and reviewing our patch 2. Run more performance tests 3. Figure out why the two ports failed in the EXP-RUN. Involve the port maintainers. 4. Test on different architectures (we need help with this) __________________________________________________________________ amd64 Xen Paravirtualization URL: https://wiki.freebsd.org/FreeBSD/Xen Contact: Cherry Mathew This project aims to add support to the FreeBSD kernel for running in Xen Paravirtualised mode on amd64 systems. This project has finally reached a "Proof of Concept" stage on the branch projects/amd64_xen_pv. Testing and bug reports on various configurations is encouraged! The author is also seeking bounties to help complete the effort and assess potential interest. Please send email if interested. PV kernels are still supported by most cloud providers for a range of configurations, although they are expected to be phased out in the future. This project is sponsored by Spectralogic Corporation (2012-2013) . Open tasks: 1. Large page support 2. SMP support 3. Debug and cleanup 4. Security vetting 5. Performance tweaks __________________________________________________________________ bhyve URL: http://www.bhyve.org URL: http://www.youtube.com/watch?v=3DlTOiSyu0-MA Contact: Peter Grehan Contact: Neel Natu Contact: John Baldwin Contact: Tycho Nightingale Contact: Allan Jude bhyve is a hypervisor that runs on the FreeBSD/amd64 platform. At present, it runs FreeBSD (8.x or later), Linux i386/x64, OpenBSD i386/amd64, and NetBSD/amd64 guests. Current development is focused on enabling additional guest operating systems and implementing features found in other hypervisors. A significant amount of progress has been made since the last status report. Most importantly, all of this work has been MFCed to the 10-STABLE branch and will be included in the 10.1 release. Support for AMD processors is being developed in the bhyve_svm SVN project branch. The branch is almost at feature-parity with mainline Intel VT-x support, and will be committed into -CURRENT in the near future. New features added this quarter: * Guest support for recent Linux i386/x64, OpenBSD i386/amd64, and NetBSD amd64. * Force guest reset and poweroff with bhyvectl * Allow the SMBIOS UUID to be set from the command line * PCI MMIO extended config space access * Improved AHCI error handling, legacy interrupt mode * Additional instruction emulation required by a number of guests * Legacy x86 task switching to support double-faults in FreeBSD/i386 * Legacy PCI interrupts, operation without an APIC (OpenBSD install) * Guest memory not included by default in core dumps * Allow guest vCPUs to be pinned to individual host CPUs * Virtio RNG device emulation * Chapter about bhyve added to FreeBSD Handbook Open tasks: 1. Improve documentation 2. CSM BIOS boot support for non UEFI-aware guests 3. Add support for virtio-scsi 4. Improve virtio-net, add offload features, support multiple queues 5. Implement Intel 82580 and e1000 NIC emulation 6. Netmap support 7. Flexible networking backend: wanproxy, vhost-net 8. Move to a single process model, instead of bhyveload and bhyve 9. Support running bhyve as non-root 10. Add filters for popular VM file formats (VMDK, VHD, QCOW2) 11. Implement an abstraction layer for video (no X11 or SDL in base system) 12. Support for VNC as a video output 13. Suspend/resume support 14. Live Migration 15. Nested VT-x support (bhyve in bhyve) 16. Support for other architectures (ARM, MIPS, PPC) __________________________________________________________________ Chelsio iSCSI Offload Support Contact: Sreenivasa Honnur Contact: Edward Tomasz Napiera=B3a Building on the new in-kernel iSCSI target and initiator stack released in FreeBSD 10.0, Chelsio Communications has begun developing an offload interface to take advantage of the hardware offload capabilities of Chelsio T4 and T5 10 and 40 gigabit Ethernet adapters. The code implements hardware PDU offload for both target and initiator. The iSCSI stack has been modified to provide a hardware-independent offload API, allowing offload drivers to be loaded as kernel modules, and to provide mechanisms for the system administrator to configure this feature. The project is entering a testing phase. The code will be released under the BSD license and is expected to be completed later in the year and ship in FreeBSD 10.2-RELEASE. This project is sponsored by Chelsio Communications , and The FreeBSD Foundation . Open tasks: 1. Complete testing __________________________________________________________________ Debian GNU/kFreeBSD URL: https://wiki.debian.org/Debian_GNU/kFreeBSD URL: https://www.debian.org/ports/kfreebsd-gnu/ Contact: Debian GNU/kFreeBSD Maintainers Debian GNU/kFreeBSD is a software distribution produced by Debian, based on the kernel of FreeBSD (instead of Linux) and GNU libc. Around 90% of Debian's software archive has now been ported to it, for amd64 and i386 architectures. It was first released with Debian "squeeze" as a development preview in 2011, featured again in the "wheezy" release, and hopes to be part of the official Debian "jessie" release in early 2015. In 2003 there were several attempts to bootstrap a minimal Debian system upon FreeBSD or NetBSD kernels, some also trying to use the native BSD libc. The most successful and longest-lived of these was a "GNU/FreeBSD" chroot bootstrapped by Robert Millan with the GNU libc that most of Debian's core packages were designed to work with. The "k" was later added to the name to reflect that it takes just the kernel from FreeBSD, with most everything else from the Debian archive. We do also package some FreeBSD utilities as needed to boot it and take advantage of certain features. FreeBSD support within GNU libc is now mostly maintained by Petr Salinger, who recently converted it from an older threading implementation based on LinuxThreads to NPTL, which is much more compatible with the software we run. We have the GNU compiler toolchain as well as Clang 3.4; Perl, Python and Ruby; and OpenJDK 7, based the on work done in FreeBSD's own ports collection. We use linprocfs for /proc because much of Debian GNU software expects this. The Linuxulator is not needed at all, but could make for interesting future uses. Porting work mostly focuses now on individual packages' build systems, on preprocessor #ifdefs that do not clearly distinguish between kernel and libc, or fixing testsuites' presumptions of Linux-specific behaviour. In the course of this, we even found the odd FreeBSD kernel bug, including EN-14:06 / CVE-2014-3880. GNU/kFreeBSD has already seen production use, mostly on webservers, email servers and file servers; one such machine has 475 days' uptime receiving around 10,000 emails per day. It has become increasingly practical for desktop/laptop uses thanks largely to new features coming in from FreeBSD 10.1. KMS graphics mean that 3D gaming and high-definition video playback perform brilliantly. We have great support for Intel graphics chipsets, but only an older nvidia Xorg driver. For radeonkms, Robert Millan was able to add firmware-loading support so that non-free binary blobs can be packaged separately, outside of Debian's main archive. Proprietary drivers are not useful to us as they would need to be rebuilt from source to port them. vt(4) was necessary for KMS to not break VT switching. But it has also improved the console's handling of non-ASCII character sets and we do look forward to having console fonts for non-Latin scripts. We have supported ZFS for some time, even as a root/boot filesystem (using GRUB 2; Robert Millan added the ZFS support which now FreeBSD itself is able to benefit from). Enhancements coming from OpenZFS, especially LZ4 compression, in combination with better memory management and GEOM improvements, mean that "jessie" should see a noticeable performance boost. debian-installer already allows for pre-seeded, unattended installs and there are PXE-bootable install images available. virtio drivers are new to the "jessie" release, enabling support for some public clouds. We are now compiling Xen domU and PVHVM support into our standard kernel builds. We already have userland tools to configure the PF firewall. As an experiment, we are compiling in IPSEC support by default for the upcoming release, and would like to see it put to good use against present-day privacy and security threats. We try to support the use of Debian GNU/kFreeBSD inside a jail on a FreeBSD host system, and hopefully vice-versa. Some of the jail utilities are not yet packaged, but we have documentation on the Debian Wiki on how to set up jails on "wheezy", which are fully functional. The init system we currently use is a parallel System V-style init, although Debian GNU/Linux will be switching away from that to systemd. For the next release we may switch to OpenRC, which is mostly ported already. Not having systemd or udev means that we will be unable to support GNOME 3.14 in the upcoming release. We have very good support for XFCE, also have KDE, LXDE and the recently-packaged MATE desktop environment. The Debian software archive provides many alternative window managers for Xorg such as IceWM, dozens of terminal emulators, and so on. As we approach the freeze of the Debian "jessie" release, we would love for anyone to test GNU/kFreeBSD, try to use it for whatever would be useful to you, and let us know what issues you run into. Ask for help on our project mailing list or IRC channel, and let us know of any bugs you find. We still have time to fix problems before release, and we would be happy to improve our documentation at any time. __________________________________________________________________ FreeBSD Preseed Installation (PXE) URL: https://wiki.freebsd.org/SummerOfCode2014/FreeBSD_PXE_preseed Contact: Kamil Czekirda This is a Google Summer of code project to provide a noninteractive FreeBSD installation process from the network. In the first part, an implementation was added for scripted bsdinstall(8). It supports variables such as KEYMAP, HOSTNAME, MIRROR, RELEASE, TIMEZONE, DAEMONS, ROOTPWHASH, and USERS. Network configuration, ZFS options, and others are also included. The second part of the project is about booting the fai (Fully Automatic Installer) from the network by PXE. An installer distro was created based on mfsBSD. After boot, fai looks for the "bootfile-name" parameter from the DHCP server. This parameter tells fai where the bsdinstall script is located. fai supports MAC-based configuration, or a default if a MAC-based configuration file does not exist. This project is sponsored by Google Summer of Code 2014 . Open tasks: 1. Documentation, including a HOWTO and handbook 2. More tests in different configurations 3. Support for more than one network interface is planned __________________________________________________________________ Jenkins Continuous Integration for FreeBSD URL: https://jenkins.freebsd.org URL: https://wiki.freebsd.org/201405DevSummit/Jenkins URL: http://www.bsdcan.org/2014/schedule/events/445.en.html URL: http://clang-analyzer.llvm.org/scan-build.html URL: http://scan.freebsd.org URL: http://www.bsdnow.tv/episodes/2014_07_02-base_iso_100 URL: http://www.slideshare.net/CraigRodrigues1/libvirt-bhyve URL: https://github.com/jmmv/kyua URL: https://issues.jenkins-ci.org/browse/JENKINS-24521 URL: https://github.com/jenkinsci/jenkins/pul=B31387 URL: https://github.com/jenkinsci/jenkins/pul=B31410 URL: http://jenkins.mouf.net/job/pkg/ URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193499 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193246 URL: https://github.com/rodrigc/kyua/wiki/Quickstart-Guide Contact: Craig Rodrigues Contact: Jenkins Administrators Contact: FreeBSD Testing In May, Craig Rodrigues led a working group Continuous Integration and Testing with Jenkins for FreeBSD at the FreeBSD Devsummit in Ottawa. Craig Rodrigues also gave a Jenkins presentation at BSDCan. At BSDCan, Craig Rodrigues had some discussions with Julio Merino about how to better integrate FreeBSD testing efforts with Jenkins and kyua. As a result of this discussion, Julio Merino enhanced the kyua testing framework with a kyua report-junit command. This command takes kyua test results and outputs a test report in JUnit XML format. Jenkins can directly import JUnit XML test results and display them nicely. In June, Craig Rodrigues was interviewed for episode 44 of BSD Now. The interview covered Jenkins and Continuous Integration in the FreeBSD project. In July, Craig Rodrigues gave a presentation to the Bay Area FreeBSD Users Group (BAFUG), Libvirt and bhyve, based on experience he had with those technologies when used with Jenkins. Li-Wen Hsu set up a Jenkins job to run the LLVM scan-build tool to perform static analysis of the FreeBSD code, and make the results availalble at scan.freebsd.org. Steve Wills modified the Jenkins job which builds pkg(8) to use the kyua report-junit command to integrate pkg(8) test results in Jenkins. Anthony Williams reported that the version of the Java Native Access (JNA) library bundled with Jenkins has problems on FreeBSD. This causes problems with Jenkins using libpam and other plugins that use JNA. Craig filed JENKINS-24521 against Jenkins. Craig submitted patches to Jenkins to update Jenkins to use JNA 4.1.0, which has fixes for FreeBSD. Craig Rodrigues worked on automatically running the tests in the FreeBSD /usr/tests directory under Jenkins using the kyua test framework. Craig Rodrigues provided feedback to Julio Merino about kyua and Julio Merino incorporated some of the feedback as bugfixes and feature enhancements to kyua. Craig Rodrigues committed some fixes to FreeBSD to eliminate some test failures. One of the tests still results in a crash in byacc. This is being tracked in PR 193499. Thomas E. Dickey (byacc maintainer) submitted a patch to fix the problem, and this has been committed to FreeBSD. Craig Rodrigues analyzed the cause of some startup errors in Jenkins when opening a multicast socket. He had some discussion with Bruce M. Simpson captured in PR 193246. The Java JDK depends on functionality in Solaris where it is possible to open an IPv4 multicast socket, but with an IPv4 multicast address mapped to an IPv6 address. On Linux, there are modifications to the JDK itself to work around this. Bruce M. Simpson said that the work to make the FreeBSD IPv6 stack behave like Solaris would require some work. Craig Rodrigues started writing a Kyua Quickstart Guide. This guide is meant to help new kyua users who want to write tests and run them under kyua. Craig Rodrigues is seeking feedback to help improve this guide. Open tasks: 1. Upstream more fixes to Jenkins for FreeBSD, such as JNA fixes. 2. Automate the build of /usr/tests. 3. Set up more builds based on examples from the existing FreeBSD Tinderbox. 4. Get feedback for improving the Kyua Quickstart Guide. 5. We need more people to join us on freebsd-testing@FreeBSD.org and help out. We especially need people with devops and scripting experience to help us set up more builds and tests. We would also like to integrate with other parts of the project, such as Phabricator. __________________________________________________________________ New Automounter URL: https://wiki.freebsd.org/Automounter URL: http://people.freebsd.org/~trasz/autofs.pdf Contact: Edward Tomasz Napiera=B3a Limitations of the current automounter, amd(8), are a recurring problem reported by many FreeBSD users. A new automounter is being developed to address these concerns. The automounter is a cleanroom implementation of functionality available in most other Unix systems, using proper kernel support implemented via an autofs filesystem. The automounter supports a standard map format, and will integrate with the Lightweight Directory Access Protocol (LDAP) service. The FreeBSD Foundation worked with enterprise and university users to test the new automounter in existing LDAP-based environments, including some with thousands of map entries. The code is now ready to use. It has been committed to 11-CURRENT and 10-STABLE, and will ship as part of 10.1-RELEASE. There is ongoing work on improving performance and fixing possible bugs. This project is sponsored by The FreeBSD Foundation . __________________________________________________________________ QEMU bsd-user-Enabled Ports Building URL: https://wiki.freebsd.org/QemuUserModeHowTo URL: http://chips.ysv.freebsd.org/packages URL: https://github.com/seanbruno/qemu-bsd-user Contact: Sean Bruno Contact: Juergen Lock Contact: Stacey Son FreeBSD packages for the Tier-1 i386 and amd64 CPU architectures are built by a single very high-performance machine. Other architectures lack equivalent hardware, and we began experimenting with QEMU's user-mode emulation to cross-build packages from an amd64 builder. We have moved from just being able to produce packages to providing a stable repo of packages for ARMv6. ports-mgmt/poudriere-devel is still the current method for building packages. See the previous status report for explanations and details on methods. __________________________________________________________________ VMWare VAAI and Microsoft ODX Acceleration in CTL Contact: Alexander Motin The CAM Target Layer (CTL), used as base for the kernel iSCSI server, got support for VMWare VAAI and Microsoft ODX storage acceleration. It permits avoiding network bottlenecks and improves storage efficiency on sets of large operations, such as virtual machine (or large file) creation, initialization to zeros, copy, delete, etc.. VMWare VAAI includes support for these primitives/SCSI commands: Atomic Test and Set (ATS) -- COMPARE AND WRITE command; Extended Copy (Clone) -- SPC-3 subset of XCOPY commands; Write Same (Zero) -- set of WRITE SAME commands; and Dead Space Reclamation (Delete) -- UNMAP command. Microsoft ODX includes support for these SCSI commands: POPULATE TOKEN/WRITE USING TOKEN (SPC-4 extensions of XCOPY), WRITE SAME and UNMAP. All XCOPY operations are currently limited to one storage host. ODX operations are currently limited only to iSCSI disks. Accelerated inter-host copying or copying to/from files on Samba shares is not implemented and is handled by initiators in the legacy way. The code is committed to FreeBSD head and stable/10 branches, and will be present in FreeBSD 10.1 and FreeNAS 9.2.1.8 / 9.3 releases. This project is sponsored by iXsystems, Inc. . Open tasks: 1. Full support for thin provisioning, including capacity usage reporting and threshold notifications. 2. Inter-host XCOPY operations. __________________________________________________________________ ZFSguru URL: http://zfsguru.com URL: http://zfsguru.com/news/stateoftheproject/2014 URL: http://zfsguru.com/forum/zfsgurudevelopment/876 Contact: Jason Edwards ZFSguru is a multifunctional server appliance with a strong emphasis on storage. ZFSguru began as simple web-interface frontend to ZFS, but has since grown into a FreeBSD derivative with its own infrastructure. The scope of the project has also grown with the inclusion of add-on packages that add functionality beyond the traditional NAS functionality found in similar product like FreeNAS and NAS4Free. ZFSguru aims to be a true multifunctional server appliance that is extremely easy to set up and can unite both novice and more experienced users in a single user interface. The modular nature of the project combats the danger of bloat, whilst still allowing extended functionality to be easily deployed. The development work in Q3 focused heavily on the new build infrastructure. This allows the ZFSguru project to release new system images together with addon services at much higher frequency and with much less manual intervention. This should free up a lot of development time to be spent on the core of the project: the web interface. Furthermore, a new website and forum is being worked on, replacing the old-fashioned website that offers only limited functionality. The new website will be linked to the server database, providing real-time updates about the project. In addition, a new platform for collaborated development is in the works. A service addon has been created for the GitLab project, which is a drop-in replacement of the popular GitHub website. The choice was made to host our own solution and not rely on GitHub itself. In retrospect this appears to have been a good decision. The recent development where GitHub removed projects after DCMA-takedowns being sent is incompatible with the philosophy of free-flow-of-information, of which the ZFSguru project is a strong proponent. By hosting our own solution, we have avoided any dependency on third party projects. The next task will be to introduce a new remote database structure, dubbed GuruDB. This will speed up the web-interface as well as introduce Service Bulletins which address important notifications to our users, as well as announce new releases. After GuruDB, the Migration Manager is one of the last remaining features still missing in the web-interface. This functionality provides an easy way to upgrade the current system by performing a new clean installation, but migrate all relevant configuration to the new installation. It also allows users to 'backup' all system configuration in a single file to be stored on a different machine should things go awry. A longer version of the 2014 development progress of the ZFSguru project and information specific to the newly-released 10.1-002 system image can be found in the Links section. __________________________________________________________________ Intel GPU Driver Update URL: https://lists.freebsd.org/pipermai=B3freebsd-current/2014-October/052532 .html Contact: Konstantin Belousov The project to update the Intel graphics chipset driver (i915kms) to a recent snapshot of the Linux upstream code continues. A patch with a large chunk of updates has been made available to test for regressions against current functionality, but is not yet expected to provide working new functions. The GEM I/O ioctl code path has been modified to more closely resemble the Linux code structure (easing future imports). This project is sponsored by FreeBSD Foundation . Open tasks: 1. Fix any bugs reported against the latest versions of the patch. 2. Make Haswell graphics work with Mesa. __________________________________________________________________ SDIO Driver URL: https://wiki.freebsd.org/SDIO URL: https://github.com/kibab/freebsd/tree/mmccam URL: https://reviews.freebsd.org/D862 Contact: Ilya Bakulin SDIO is an interface designed as an extension of the existing SD card standard, allowing the connection of different peripherals to a host with a standard SD controller. Peripherals currently sold in the general market include WLAN/BT modules, cameras, fingerprint readers, and barcode scanners. SDIO is also used to connect some peripherals in products like Chromebooks and Wandboard. The current main focus of the project is to reimplement the existing MMC/SD stack using the CAM framework. This will allow utilizing the well-tested CAM locking model and debug features. The first version of the code was uploaded on Phabricator for review. The new stack is able to attach to the SD card and bring it to an operational state. The only supported SD controller driver is ti_sdhci which is used by the BeagleBone Black. Modifying other SDHCI-compliant drivers should not be a hard task. Open tasks: 1. At this point, feedback from kernel developers is really needed. This may be done in the form of code review. If the chosen way of implementing the CAM-aware MMC stack is considered correct, then adding code for interacting with SD cards (for example, setting the optimal transfer rates) will be the next task. 2. Write a CAM peripheral driver that implements an interface to the FreeBSD disk(9). It will send MMC I/O commands using the MMC XPT layer. 3. Extending camcontrol(8) to make it possible to send MMC-specific commands directly to the MMC/SD card using pass(4) will greatly assist in developing new features for the stack. 4. Modify the sdhci(4) driver to work with the new stack. This is required to work on the new stack using PC hardware, not only the BeagleBone Black. __________________________________________________________________ UEFI Boot URL: https://wiki.freebsd.org/UEFI URL: http://www.freebsd.org/snapshots/ Contact: Ed Maste Contact: Nathan Whitehorn The Unified Extensible Firmware Interface, or UEFI, provides boot- and run-time services for x86 and other computers. For the x86 architecture it replaces the legacy BIOS. This project will adapt the FreeBSD loader and kernel boot process for compatibility with UEFI firmware, found on contemporary servers, desktops, and laptops. Over the last three months Ed and others refined the existing UEFI support and merged it to the stable/10 branch for the upcoming FreeBSD 10.1 release. To avoid the risk of a regression, the standard FreeBSD 10.1 install images continue to use the existing partitioning scheme and support only legacy BIOS boot. Separate UEFI-enabled installer images will be included with 10.1. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Document manual installation, including dual-boot configurations. 2. Implement boot1.efi for ZFS file systems. 3. Add support for UEFI variables stored in non-volatile memory (NVRAM). 4. Debug boot failures with certain UEFI firmware implementations. 5. Support secure boot. __________________________________________________________________ Updated vt(4) System Console URL: https://wiki.freebsd.org/Newcons Contact: Aleksandr Rybalko Contact: Ed Maste Contact: Ed Schouten Contact: Jean-S=E9bastien P=E9dron Contact: Warren Block The vt(4) (aka Newcons) project provides a replacement for the legacy syscons system console. It brings a number of improvements, including better integration with graphics modes and broader character set support. A large number of improvements were committed to vt(4) over the last three months. Jean-S=E9bastien P=E9dron fixed significant performance regressions observed with vt_vga, particularly noticeable on virtual machines. Stefan Esser converted and cleaned up all of the keyboard map files for use with vt(4). The EFI framebuffer driver and the ofwfb driver now work with the xf86-video-scfb X11 video driver, supporting native-resolution (albeit unaccelerated) X. The fixes and improvements have all been merged and will be available in the upcoming FreeBSD 10.1 release. Open tasks: 1. Implement the remaining features supported by vidcontrol(1). 2. Write manual pages for vt(4) drivers and kernel interfaces. 3. Support direct handling of keyboards by the kbd device (without kbdmux(4)). 4. CJK fonts. This is in progress. 5. Switch to vt(4) by default. 6. Implement compatibility mode to be able to use single-byte charsets/key-codes in vt(4). __________________________________________________________________ Updating OpenCrypto URL: https://p4db.freebsd.org/depotTreeBrowser.cgi?FSPC=3D//depot/projects/op= e ncrypto URL: http://freebsdfoundation.blogspot.com/2014/08/freebsd-foundation-announ ces-ipsec.html Contact: John-Mark Gurney The project adds support for the AES-GCM and AES-CTR cryptography modes to the OpenCrypto framework. Both software and AES-NI accelerated versions are now functional and working. Ermal Lu=E7i (eri@) is working on adding support for these additional modes to IPsec. This project is sponsored by The FreeBSD Foundation , and Netgate . Open tasks: 1. Create a test suite for the most common modes. __________________________________________________________________ FreeBSD on Newer ARM Boards URL: https://github.com/tsgan/qualcomm Contact: Ganbold Tsagaankhuu Work on initial support of the IFC6410 board, which was stopped due to a bricked bootloader, has been started again. This board has the Qualcomm Snapdragon S4 SoC, featuring the Krait CPU. This CPU is considered a "platform" for use in smartphones, tablets, and smartbook devices. Krait has many similarities with the ARM Cortex-A15 CPU and is also based on the ARMv7 instruction set. These peripherals are working: * Qualcomm High Speed UART driver for MSM 7000/8000 series chips (included in src tree) * Krait Timer Open tasks: 1. Get the MMC driver working. May need more help from experts. __________________________________________________________________ FreeBSD/arm64 URL: http://svnweb.freebsd.org/base/projects/arm64/ Contact: Andrew Turner Until recently, all ARM CPU designs were 32-bit only. With the introduction of the ARMv8 architecture, ARM has added a new 64-bit mode. This new mode has been named AArch64. Arm64 is the name of the in-progress port of FreeBSD to ARMv8 CPUs when in AArch64 mode. Since the last status report, FreeBSD has started to execute userland instructions. This includes implementing more of the needed kernel functions to handle creation of processes. Using clang to compile userland has found a few issues with the version in the base system. These issues are expected to be resolved when clang 3.5 is imported. Initial support for device drivers has been added. This includes the start of the bus_space functions and interrupt handling. This allowed the existing timer and interrupt controller drivers from armv6 to be used as these devices are similar. The FDT data is now being passed from the loader to the kernel using the standard mechanism. The pmap implementation has been changed to be based on the amd64 code. This fixes a number of issues with the old implementation. Open tasks: 1. Boot to multi-user mode 2. Get dynamic libraries working 3. Test on real hardware __________________________________________________________________ LLDB Debugger Port URL: https://wiki.FreeBSD.org/lldb Contact: Ed Maste LLDB is the debugger project associated with Clang/LLVM. It supports the Mac OS X, Linux, and FreeBSD platforms, with Windows support under development. It builds on existing components in the larger LLVM project, for example using Clang's expression parser and LLVM's disassembler. Work over the last three months consisted mainly of maintenance, ensuring that the upstream FreeBSD port continues to build and that testsuite failures are promptly addressed. I plan to import a new LLDB snapshot after the base system Clang is updated to 3.5. Some upstream improvements that will be in that import include: * Ability to specify a count to thread step-* operations. * Ongoing AArch64 development. * Significant progress on the lldb-gdbserver debug stub. * I/O handling improvements. * A much faster C++ name demangler for most symbols. A proof-of-concept implementation of kernel debugging support for amd64 was completed as part of Google Summer of Code. It is not ready to be committed, but will form the basis for upcoming kernel debugging support. This project is sponsored by DARP/AFRL, SRI International, and University of Cambridge. Open tasks: 1. Port remote debug stub (lldb-gdbserver) from Linux to FreeBSD. 2. Add support for local and core file kernel debugging. 3. Implement, fix or test support on all non-amd64 architectures. 4. Verify cross-debugging. 5. Investigate and fix test suite failures. 6. Package LLDB as a port. 7. Enable by default in the base system for working architectures. __________________________________________________________________ LLVM Address Sanitizer (Asan) URL: https://code.google.com/p/address-sanitizer/ URL: http://clang.llvm.org/docs/AddressSanitizer.html URL: http://lab.llvm.org:8011/builders/sanitizer_x86_64-freebsd URL: http://lists.freebsd.org/pipermai=B3svn-src-head/2014-July/060270.html URL: http://lists.freebsd.org/pipermai=B3svn-src-head/2014-July/060504.html Contact: Viktor Kuzutov The LLVM address sanitizer (Asan) is a fast memory error detector that can detect use-after-free errors and buffer overflows. It has been ported to FreeBSD. The mainline version of LLVM is known to pass all of the tests in the LLVM and Asan test suites without unexpected failures on FreeBSD 10.0. A buildbot running sanitizer tests under FreeBSD stable/10 has been established. See the Links section. To make it possible to run programs with sanitizer checks enabled on FreeBSD, a new sysctl named kern.proc_vmmap_skip_resident_count has been added. See the Links section. Running the address sanitizer checks on stable/10 requires this sysctl to be set to 1. A similar work is in progress to add FreeBSD support to the thread sanitizer (Tsan), which detects data races in parallel programs. __________________________________________________________________ SSE Variants of libc Routines for amd64 URL: http://trac.baldwin.cx:8080/freebsd/wiki/LibCSSE Contact: John Baldwin I have written SSE/AVX-optimized versions of a few libc routines for amd64. So far the list includes memcpy, memset, and strlen. For each routine I have written a simple regression test as well as performed some simple microbenchmarks on various AMD and Intel CPUs. The simplest routine is strlen which appears to be a general win in microbenchmarks. memcpy and memset have proven trickier as different variants can behave quite differently on different CPUs. At present, I do not yet have a patch relative to libc. Once I do, this will be suitable for more testing. I would like to see some real-world benchmarks that show measurable improvement before pushing any of this up into the tree. Open tasks: 1. Create a branch that holds a modified libc and is suitable for testing __________________________________________________________________ FreeBSD Python Ports URL: https://wiki.FreeBSD.org/Python URL: irc://freebsd-python@irc.freenode.net Contact: FreeBSD Python Team The FreeBSD Python team continued to improve the overall experience with Python-based software on FreeBSD. During the last quarter, the bsd.python.mk bits of the ports infrastructure were converted to the more modern USES format. Several options, such as support for easy_install, were deprecated or removed to make the infrastructure easier to maintain and less complex for port maintainers. The Python ports were refactored and simplified to improve maintainability and to get rid of long-standing issues due to the previously complex and error-prone build process. The Python 2 branch was updated to Python 2.7.8 and setuptools to 5.5.1. With the availability of pkg 1.3, installing Python packages and modules for different Python versions is now supported in the package management infrastructure. This allows us to remove the previously required port duplicates for Python 2 and Python 3. Open tasks: 1. Retire the Python 3 specific port duplicates 2. Convert ports to the new USES syntax 3. More tasks can be found on the team's wiki page (see Links). 4. To get involved, interested people can say hello on IRC and let us know their areas of interest! __________________________________________________________________ GNOME/FreeBSD URL: http://www.freebsd.org/gnome URL: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD URL: http://marcuscom.com/downloads/marcusmerge Contact: FreeBSD GNOME Team GNOME is a desktop environment and graphical user interface that runs on top of a computer operating system. GNOME is part of the GNU Project and can be used with various Unix-like operating systems, including FreeBSD. MATE is a fork of GNOME 2. The MATE ports were updated to the 1.8 versions. Cairo, the vector graphics library used by GNOME, has been updated to 1.12. This allowed the merge of GNOME 3 to begin. We are currently doing test builds to find ports broken by the update and pruning ports that do not build any more because of incompatible updates. Gustau Perez started preliminary work on the next development version of GNOME in MC, to be ready for GNOME 3.15. We will skip 3.14 entirely. Open tasks: 1. Finish the GNOME 3.12 merge, and start tracking GNOME 3.15 (development series). __________________________________________________________________ KDE on FreeBSD URL: https://freebsd.kde.org/ URL: https://freebsd.kde.org/area51.php URL: https://wiki.freebsd.org/KDE URL: https://mail.kde.org/mailman/listinfo/kde-freebsd URL: http://portscout.freebsd.org/kde@freebsd.org.html Contact: KDE on FreeBSD team The KDE on FreeBSD team focuses on packaging and making sure the experience of KDE and Qt on FreeBSD is as good as possible. First of all, we are happy to announce that Alonso Schaich, longtime contributor to our experimental area51 repositories, has become a ports committer, mentored by KDE on FreeBSD members Raphael Kubo da Costa (rakuco@) and Max Brazhnikov (makc@). During this quarter, the team has kept most of the KDE and Qt ports up-to-date, working on the following releases: * CMake 3.0.1 and 3.0.2 * PyQt 4.11.1, SIP 4.16.2, QScintilla 2.8.3 * DigiKam 4.2.0 (in area51) * KDE 4.13.3, 4.14.0 and 4.14.1 (in area51) * KDE Telepathy 0.8.0 (in area51) Additionally, work on updating the Qt5 ports to the 5.3 series has begun, and we intend to commit the updated ports in our experimental area51 repository to the ports tree in Q4. Open tasks: 1. Updating out-of-date ports, see the Links Portscout entry for a list. 2. Committing all the updated ports we have been accumulating in our experimental repositories into the ports tree. __________________________________________________________________ The Graphics Stack on FreeBSD URL: https://wiki.freebsd.org/Graphics URL: http://trillian.chruetertee.ch/ports/browser/trunk URL: http://lists.freebsd.org/pipermai=B3freebsd-ports-announce/2014-October/ 000096.html URL: http://wiki.x.org/wiki/Events/XDC2014/ Contact: FreeBSD Graphics team The newest graphics stack (that is, the set of ports conditional on the WITH_NEW_XORG knob) was enabled on all architectures. The only regression is for users of Intel GPUs and FreeBSD 8.X or 9.0. Those releases lack the required kernel driver and therefore xf86-video-intel will not work (the last UMS-aware version does not work with xserver 1.12). Users can still use xf86-video-vesa if they cannot or do not want to update their FreeBSD workstation. Owners of Radeon GPUs can use xf86-video-ati-ums 6.14.6 with xserver 1.12 if the KMS driver is not available (that is, before FreeBSD 9.3). The old graphics stack will be removed with the next update to these ports. See the announcement in the Links section. Hardware context support was added to the i915 driver in both HEAD and 10.1-RELEASE. This will allow us to update libglapi, libGL, dri, libEGL and libglesv2 ports to a newer version of Mesa. The latest version is already available from our development ports tree (see the links section). Cairo was updated to 1.12. This will allow the FreeBSD GNOME team to upgrade pango and Gtk+ 3. Unfortunately, the update also revealed that xf86-video-intel 2.7.1 was in a much worse state than previously assumed. We will attend XDC 2014 (X.Org Developer's Conference) from October 8th through 10th in Bordeaux, France. The goal is to reconnect with graphics stack developers, who are mostly working with Linux these days. We will give a presentation on the current state of this stack on FreeBSD. See the XDC website in the Links section for the program and live streaming. Open tasks: 1. See the "Graphics" wiki page for up-to-date information. __________________________________________________________________ Xfce URL: https://wiki.freebsd.org/Xfce URL: http://www.redports.org/browser/olivierd/xfce4 URL: https://people.freebsd.org/~olivierd/xfce4-4.11-screencast.webm Contact: FreeBSD Xfce Team Xfce is a free software desktop environment for Unix and Unix-like platforms including FreeBSD. It aims to be fast and lightweight while still being visually appealing and easy to use. The Xfce team continues to keep each piece of the Xfce Desktop up to date. That is why we are working on the next stable release (no date scheduled). There were no major updates in the ports tree except for cosmetic changes this quarter. Major upcoming changes include: * Switch to the USES framework * Support both GTK2 and GTK3, with GTK2 being the default. * A GNOME-like default icons theme * Enhanced documentation (handbooks, FAQ) Below is a list of current ports in the devel repository (see link). * deskutils/xfce4-xkb-plugin 0.7.0 * deve=B3xfce4-dev-tools 4.11.0 * misc/xfce4-appfinder 4.11.0 * multimedia/xfce4-parole 0.6.1 and 0.7.0 * sysutils/garcon 0.3.0 * sysutils/xfce4-settings 4.11.3 * x11/libxfce4menu 4.11.1 * x11/libxfce4util 4.11.0 * x11-wm/xfce4-desktop 4.11.8 * x11-wm/xfce4-panel 4.11.1 * x11-wm/xfce4-session 4.11.0 There are also two new ports * deskutils/xfce4-volumed-pulse 0.2.0 * x11/xfce4-dashboard 0.2.3 and 0.3.2 For more details, please see our wiki page in the Links section. Open tasks: 1. Finish patching the ACPI helper (xfce4-power-manager). 2. Continue to work on documentation, especially the Porter's Handbook, and creata a FAQ). __________________________________________________________________ Handbook ezjail Section URL: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-ezjail .html Contact: Warren Block ezjail is a very popular jails management utility, but was only mentioned in passing in the Handbook. This new section describes basic setup and usage. An in-depth example shows how to create and configure a jail. It also serves as an example of how to run a simple caching-only BIND in a jail. __________________________________________________________________ Michael Lucas Books URL: http://blather.michaelwlucas.com/archives/2088 URL: http://blather.michaelwlucas.com/archives/2119 URL: https://www.tiltedwindmillpress.com/?product=3Dfreebsd-mastery-storage-e= s sentials Contact: Michael Lucas Lucas is working on a series of small FreeBSD books. The first one, FreeBSD Mastery: Storage Essentials, is underway, and covers GEOM, gpart, MBR, UFS, GELI, GBDE, disk sector alignment, and more. You can pre-order the book at a discount from his web site, or wait for it to hit print and all major ebook retailers. Get status updates on his blog, or check @mwlauthor on Twitter. Open tasks: 1. Lucas needs to write faster. __________________________________________________________________ ZFS Chapter of the Handbook URL: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/zfs.html Contact: Allan Jude Contact: Benedict Reuschling Contact: Warren Block ZFS is one of the premier features of FreeBSD, and the quality of the documentation should match that of other important features. Much of the original documentation from Sun and Oracle has disappeared, moved, or is about the proprietary version of ZFS. The OpenZFS project does not provide much documentation and instead provides users with a few links, including the FreeBSD Handbook. New users have many questions about ZFS and yet there exists a great deal more bad advice about ZFS than proper documentation. After over a year of work, a new ZFS chapter has been added to the FreeBSD Handbook. Over 20,000 words describe the basics of creating, managing, and maintaining a ZFS pool. Advanced features like compression, deduplication, and delegation are covered. The chapter also contains a glossary of terms, explaining a number of the concepts unique to ZFS, and documents some of the many sysctl variables that can be used for tuning. The remaining work to be done is in the FAQ section, which aims to help users address the most common questions or problems they might face with ZFS. We would like to hear experiences, questions, misconceptions, gotchas, stumbling blocks and suggestions for the FAQ section from other users. A use cases section that highlights some of the cases where ZFS provides advantages over traditional file systems is also planned. Please send suggestions to the docs mailing list. This project is sponsored by ScaleEngine Inc.. Open tasks: 1. Technical review by Matt Ahrens (co-creator of ZFS) 2. Improve the delegation section 3. Improve the tuning section, and cover recently added sysctls 4. Add a section on jails and the jailed property 5. Add an FAQ section 6. Add a Use Cases section 7. General editing and review __________________________________________________________________ The FreeBSD Foundation URL: http://www.FreeBSDFoundation.org/ URL: http://freebsdjournal.com/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Most of the funding is used to support FreeBSD development projects, conferences, and developer summits, purchase equipment to grow and improve the FreeBSD infrastructure, and provide legal support for the Project. We published our fourth issue of the FreeBSD Journal. We have over 4500 subscriptions to date. Work continued on adding support for the Dynamic Edition which will be available soon. The fifth issue is also due out soon. Foundation staff member Konstantin Belousov wrapped up the PostgreSQL performance investigation project. Kostik reran the benchmarks as a configuration error may have affected earlier results. Improvements arising from the investigation are merged to the FreeBSD 10 development branch and will be in the 10.1 release. Kostik also committed a variety of virtual memory and file system bug fixes and improvements. Over the quarter, Foundation staff member Edward Napiera=B3a refined the new autofs-based automounter and incorporated feedback from testers in enterprise and university contexts. The automounter is available in the development branch of FreeBSD and will be included in FreeBSD 10.1. Edward also supported engineers at Chelsio in preparing iSCSI offload support for Chelsio's 10- and 40-gigabit per second Ethernet adapters. Ed Maste, our project manager, tested and integrated UEFI system boot and new vt(4) console work into the release branch for the upcoming FreeBSD 10.1 release. He committed a number of small toolchain and build infrastructure improvements. He also wrote an article on LLDB for the FreeBSD Journal and presented the LLDB work at EuroBSDCon. FreeBSD Foundation Systems Administrator and Release Engineer Glen Barber continued work on finalizing the 9.3-RELEASE process, followed by starting the 10.1-RELEASE process. Work has continued on producing regularly-updated FreeBSD development snapshot builds for the various supported architectures, which include amd64, i386, ia64, powerpc, powerpc64, sparc64, and arm. In addition, work has been committed to a project branch which allows FreeBSD virtual machine disk images to be produced by default as part of the release process. A plan has been put together for the upcoming Secure Boot work. More hardware has been purchased to support FreeBSD infrastructure at NYI and Sentex. We announced a collaboration between the Foundation and Cavium to deliver a FreeBSD ARMv8 based implementation. We signed a license agreement with Oracle to get access to the TCKs for Java 7 and 8. Robert Watson ran and organized the Cambridge Developer Summit. We provided a travel grant to a Google Summer of Code student to attend the summit. We provided a travel grant to a developer who organized and ran BSDDay in Argentina. We were a Gold Sponsor for EuroBSDCon 2014 and sponsored the Developer Summit. We provided 4 travel grants to assist FreeBSD contributors with their travel expenses to attend the conference. We also had 6 board/staff members attend the conference and some gave talks, tutorials, and chaired some sessions. We held our Fall Fundraising campaign there and raised over $2,000 in donations from attendees. We organized the Silicon Valley Vendor/Developer Summit that is happening November 3 and 4. Kirk McKusick, Robert Watson, and George Neville-Neil published the second edition of "The Design and Implementation of the FreeBSD Operating System." Kirk McKusick presented a 2-day tutorial on the FreeBSD kernel and gave a talk on the implementation of ZFS at EuroBSDCon. Dru Lavigne attended Fossetcon: September 11-13 (fossetcon.org). We created new recruiting fliers for upcoming events, including the Grace Hopper conference. We started sending out Foundation monthly update emails to keep the FreeBSD community informed on some of the activities we did the previous month to support FreeBSD. __________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAEBCgAGBQJUPZwDAAoJECjZpvNk63USKbkMH0Q4dV1ZPR5PwkJXLW9HV8Ap wllhTQ9OG3kjq73nMkRpTI0xoGvldwAWbIXfAw1g0LfooewgImx4eLNBX858mYHA IQtafoDDrH2retKtUsDiobsoTAAbMjtRJDZJ0sd+sMWr9y59CkdvaLhnNLeQni7w jwIlDviZQYPyY0upTgXitb0sDN0K3W0ys1AmQoVYpClfn8N4qGKuCzWX95linj4R ykB3SSSeN1rI6dZhSR8H1Uc6aCv3D3gokP3sbwADYG6A321TAYCEtj7uQzTCO+V7 uZNn1LrhFQ8dT4Es8VU2FCbW4qdenFy2I5/86o/PF46kNoEnuOoCLxTcUa7UCtHj OtA4g/k9J3FKjOAiufMaAP44xy+fPvFPJWI88kwaSv/npX3VyhwNR3MN2RNUNEiJ HMm/ImuYIWCuFTqvVzAiWWZxxXxrzMAbdZCNiRmFhmv5KJznhnWkUvUI8CRqtMVF ZfANAYYgcZ8qqmeFpo2K/sDhsDbYu5IU9YY60MOJfOBcnQg=3D =3D3AH2 -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 14 22:21:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F3377E3 for ; Tue, 14 Oct 2014 22:21:44 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 045D1F14 for ; Tue, 14 Oct 2014 22:21:43 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id lj1so38946pab.10 for ; Tue, 14 Oct 2014 15:21:43 -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:content-transfer-encoding; bh=gHRo8mOF8Bb3z6nnR0jMigWjlCrsCgDaXxz0Gn1iejs=; b=SMF9s1cmPyV1UcH3opI8AMMKyMGOkNgWrp4USlSMcrjl2H44a1CT9fS4oFOhkfQDoK Kxp4Tuu5PX0m2DReWiE9PxSawYNqv5jpsftuMrYl7joSoFbnZbKpUYbEoV0jPYz/am07 GTEDW4TbQMz4ZA4c7qbaEKIjUx3lxJyo7SZhcdjqjrYxAOYNzbnsYz/ggQvljLp7hI9K XRuTiNkbUXUQZZAFEn1kT3Y60Id2eqtFeJfdBgTE+YOiETcDTtZvqOkvoM/WH9J86Ofo OOv5LoymOY74z2t0EbEwQjcxnBN7Svbrtja4tvTn64caeCHcnGlo2k0PTLqpOA5oKAfz 2WLw== MIME-Version: 1.0 X-Received: by 10.70.88.35 with SMTP id bd3mr8053610pdb.91.1413325303665; Tue, 14 Oct 2014 15:21:43 -0700 (PDT) Received: by 10.70.88.36 with HTTP; Tue, 14 Oct 2014 15:21:43 -0700 (PDT) In-Reply-To: <102210795.47541414.1410995911907.JavaMail.root@uoguelph.ca> References: <102210795.47541414.1410995911907.JavaMail.root@uoguelph.ca> Date: Wed, 15 Oct 2014 00:21:43 +0200 Message-ID: Subject: Re: Tool to access ZFS/NFSv4 alternate data streams on FreeBSD? From: Lionel Cons To: Rick Macklem Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Freebsd hackers list , Simon Toedt , Jordan Hubbard , Richard Yao , Jan Bramkamp 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, 14 Oct 2014 22:21:44 -0000 On 18 September 2014 01:18, Rick Macklem wrote: > Simon Toedt wrote: >> On Mon, Sep 15, 2014 at 12:17 PM, Lionel Cons >> wrote: >> > On 12 September 2014 17:47, Simon Toedt >> > wrote: >> >> On Fri, Sep 12, 2014 at 2:24 AM, Lionel Cons >> >> wrote: >> >>> On 9 September 2014 23:29, Rick Macklem >> >>> wrote: >> >>>> Simon Toedt wrote: >> >>>>> On Tue, Sep 9, 2014 at 1:47 PM, Rick Macklem >> >>>>> >> >>>>> wrote: >> >>>>> > Jordan Hubbard wrote: >> >>>>> >> Yep. I was just describing the experience that OS X went >> >>>>> >> through >> >>>>> >> in >> >>>>> >> implementing extattrs / legacy resource fork support. To >> >>>>> >> recap it >> >>>>> >> very briefly: Having NFSv4 support extattrs (or even named >> >>>>> >> streams, >> >>>>> >> if you want to go that far) is the comparatively easy part. >> >>>>> >> It=E2=80=99s >> >>>>> >> backing them up / copying them around that gets more >> >>>>> >> involved, and >> >>>>> >> if you can=E2=80=99t back up certain attributes then you=E2=80= =99re not >> >>>>> >> likely to >> >>>>> >> get anyone to want to use them, at which point the whole >> >>>>> >> =E2=80=9Csharing=E2=80=9D >> >>>>> >> aspect kind of takes a back seat. >> >>>>> >> >> >>>>> > Yep. I strongly suspect you are correct. >> >>>>> > >> >>>>> > The question then becomes: >> >>>>> > - Do we wait and see if someone chooses to get around to >> >>>>> > doing all >> >>>>> > the hard userland work. >> >>>>> >> >>>>> Solaris tools already have support for this. Also AT&T AST from >> >>>>> David >> >>>>> Korn have support for O_XATTR, too. >> >>>>> >> >>>> Hopefully others will correct me if I have this incorrect, but I >> >>>> thought >> >>>> CDDL code could only be used for optional components of FreeBSD? >> >>>> I suspect tar and friends are considered core components and >> >>>> that code >> >>>> for this would have to be written by someone (ie. couldn't use >> >>>> CDDL code?). >> >>>> (I'm assuming that these tools are in OpenSolaris.) >> >>> >> >>> I don't think you FreeBSD should *copy* the code. But it can be >> >>> used >> >>> for reference how the extended tar headers for filesystem forks >> >>> should >> >>> look like. That's all. >> >>> >> >>>> >> >>>> Be aware that most of FreeBSD's development is done by >> >>>> volunteers in their >> >>>> spare time, so I have no idea if someone is interested in doing >> >>>> this. >> >>> >> >>> If anyone can get the kernel parts I think we can sponsor someone >> >>> to >> >>> do the userland work. >> >> >> >> How much money would CERN offer? :) >> >> >> >> Simon >> > >> > Depends. First I need to have more support (2nd funding pillar) and >> > then write a proposal. Short: Paperwork. Long: More paperwork. >> > But given the number of projects here which rely on O_XATTR there >> > isn't a way around it so funding should be easy to obtain. >> >> Our institute volunteers for testing! >> >> is there a task or todo list yet? >> > Well, first I believe the FreeBSD project (I refer to it as the > "collective" for want of a better word) needs to come to a consensus > that this should be done. > > As I understand it, the first step towards that is a post on > freebsd-arch@ proposing this work and why you think it is a good idea. > > Then, based upon the discussion/comments in response to this post, it wil= l > hopefully become fairly clear if the "collective" is in favour > of doing this or not. > > Then, if the consensus is in favour, someone needs to do the > coding. (I have volunteered to at least look at the kernel changes, > but only the kernel changes.) > Okay. I've just got the go-ahead, and initial funding :) Lionel From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 16 12:23:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85CA9551 for ; Thu, 16 Oct 2014 12:23:21 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 21F64C48 for ; Thu, 16 Oct 2014 12:23:20 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id s9GCJDMZ070210 for ; Thu, 16 Oct 2014 14:19:13 +0200 (CEST) (envelope-from wojtek@puchar.net) Date: Thu, 16 Oct 2014 14:19:07 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop To: freebsd-hackers@freebsd.org Subject: help with backlight control and memory Message-ID: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Thu, 16 Oct 2014 14:19:14 +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: Thu, 16 Oct 2014 12:23:21 -0000 bought new laptop. it's lenovo B590 most things works fine. but brightness control keys doesn't work after FreeBSD is loaded. they work before it. i don't ask for a solution but any point to start. What should i check? is it ACPI tables problem (kernel shows some errors). Other question - can amount of memory dedicated to GFX card be changed? There is no option in BIOS setup to do this. and i have lots of memory wasted as you may see below. Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.1-BETA1 #4: Wed Oct 15 23:56:56 CEST 2014 root@laptop:/usr/src/sys/amd64/compile/laptop amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: Intel(R) Celeron(R) CPU 1005M @ 1.90GHz (1895.73-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x306a9 Family = 0x6 Model = 0x3a Stepping = 9 Features=0xbfebfbff Features2=0xdbae3bf AMD Features=0x28100800 AMD Features2=0x1 Structured Extended Features=0x281 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 2147483648 (2048 MB) avail memory = 1585037312 (1511 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 ioapic0 irqs 0-23 on motherboard random: initialized iscsi: version 2.3.1 kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard ACPI Error: No handler for Region [ECOR] (0xfffff80001710400) [EmbeddedControl] (20130823/evregion-178) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20130823/exfldio-320) ACPI Error: Method parse/execution failed [\134_SB_.PCI0.LPCB.H_EC._REG] (Node 0xfffff8000171e200), AE_NOT_EXIST (20130823/psparse-553) acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 Event timer "HPET5" frequency 14318180 Hz quality 440 Event timer "HPET6" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x3000-0x303f mem 0x90000000-0x903fffff,0x80000000-0x8fffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 32764k stolen memory vgapci0: Boot video device xhci0: mem 0x90600000-0x9060ffff irq 21 at device 20.0 on pci0 xhci0: 32 byte context size. xhci0: Port routing mask set to 0xffffffff usbus0 on xhci0 pci0: at device 22.0 (no driver attached) ehci0: mem 0x9061a000-0x9061a3ff irq 16 at device 26.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 hdac0: mem 0x90610000-0x90613fff irq 22 at device 27.0 on pci0 pcib1: irq 16 at device 28.0 on pci0 pci1: on pcib1 pcib2: irq 17 at device 28.1 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) pcib3: irq 19 at device 28.3 on pci0 pci3: on pcib3 re0: port 0x2000-0x20ff mem 0x90404000-0x90404fff,0x90400000-0x90403fff irq 19 at device 0.0 on pci3 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x2c800000 re0: MAC rev. 0x00100000 miibus0: on re0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow re0: Ethernet address: 54:ee:75:13:f2:6b ehci1: mem 0x90619000-0x906193ff irq 23 at device 29.0 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci1 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x3088-0x308f,0x3094-0x3097,0x3080-0x3087,0x3090-0x3093,0x3060-0x307f mem 0x90618000-0x906187ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 4 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich4: at channel 4 on ahci0 ahciem0: on ahci0 acpi_acad0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 battery0: on acpi0 acpi_ibm0: on acpi0 orm0: at iomem 0xc0000-0xcefff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 fuse-freebsd: version 0.4.4, FUSE ABI 7.8 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to accept, logging disabled DUMMYNET 0 with IPv6 initialized (100409) load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched QFQ loaded hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 20,21 and 24,25 on hdaa0 hdacc1: at cad 3 on hdac0 hdaa1: at nid 1 on hdacc1 pcm1: at nid 5 on hdaa1 random: unblocking device. usbus0: 5.0Gbps Super Speed USB v3.0 usbus1: 480Mbps High Speed USB v2.0 usbus2: 480Mbps High Speed USB v2.0 ACPI Error: No handler for Region [ECRM] (0xfffff800017dd180) [EmbeddedControl] (20130823/evregion-178) ACPI Error: Region EmbeddedControl (ID=3) has no handler (20130823/exfldio-320) ACPI Error: Method parse/execution failed [\134_TZ_.MDEC] (Node 0xfffff80001725b40), AE_NOT_EXIST (20130823/psparse-553) ACPI Error: Method parse/execution failed [\134_TZ_.TZS0._SCP] (Node 0xfffff80001725a40), AE_NOT_EXIST (20130823/psparse-553) ugen2.1: at usbus2 uhub0: on usbus2 ugen1.1: at usbus1 ugen0.1: <0x8086> at usbus0 uhub1: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 uhub2: on usbus1 ses0 at ahciem0 bus 0 scbus2 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: Serial Number WD-WXL1EB3KUNR5 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled cd0 at ahcich4 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: Serial Number KW9E4571958 cd0: 150.000MB/s transfers (SATA 1.x, UDMA2, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad0 Enter passphrase for ada0d: SMP: AP CPU #1 Launched! hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 IAP/8/48/0x3ff IAF/3/48/0x67 Timecounter "TSC" frequency 1895731156 Hz quality 1000 uhub1: 8 ports with 8 removable, self powered uhub0: 3 ports with 3 removable, self powered uhub2: 3 ports with 3 removable, self powered ugen2.2: at usbus2 uhub3: on usbus2 ugen1.2: at usbus1 uhub4: on usbus1 uhub3: 4 ports with 4 removable, self powered uhub4: 4 ports with 4 removable, self powered ugen1.3: at usbus1 ugen1.4: at usbus1 umass0: on usbus1 da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: Serial Number 058F63666435 da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da0: quirks=0x2 ugen1.5: at usbus1 GEOM_ELI: Device ada0d.eli created. GEOM_ELI: Encryption: AES-CBC 128 GEOM_ELI: Crypto: software Trying to mount root from ufs:ada0d.eli []... From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 16 15:46:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5444166 for ; Thu, 16 Oct 2014 15:46:30 +0000 (UTC) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (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 A287086F for ; Thu, 16 Oct 2014 15:46:30 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id hq11so2878693vcb.21 for ; Thu, 16 Oct 2014 08:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HOhHwYGNPGUa7AFJlEXiOLCGoX0L6z1/KNqDX39QIqc=; b=l6rX84BIJd8a1vlD8doOpfQ8A+I5MPqQbLVxiQnU/RgZ/ur79IJw9gAeqSoFtRV3Dk TenIhIaGWyiKNZJ6XfISXTvyBSr7H8hLOzwKg2wD95A6x4ydeYFO+dSYgnvgWf4Vb8kI NLFdeblj18bUM2khUD2HNLMbUMSQ4UWhRiLohrszdfgKte4WnsaN6RSFHGrmVsb/ALbY qjWATafW979nl2x+stAsfyunnENULpRD/R+IDALP68wT21xx8PE00XsoyLcJLBcNN3Mn JQAM3YvsFQCcUZsE8ARN1kkHRzs+53cizFUL/mt+Ov1qHagLGgR4AKiWAvtDnvZZg0/d R/2g== X-Received: by 10.220.102.143 with SMTP id g15mr1647867vco.79.1413474389584; Thu, 16 Oct 2014 08:46:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.136.1 with HTTP; Thu, 16 Oct 2014 08:45:49 -0700 (PDT) In-Reply-To: References: From: Henry Hu Date: Thu, 16 Oct 2014 11:45:49 -0400 Message-ID: Subject: Re: help with backlight control and memory To: Wojciech Puchar Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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, 16 Oct 2014 15:46:31 -0000 On Thu, Oct 16, 2014 at 8:19 AM, Wojciech Puchar wrote: > bought new laptop. it's lenovo B590 > > most things works fine. but brightness control keys doesn't work after > FreeBSD is loaded. they work before it. > > i don't ask for a solution but any point to start. What should i check? > > Have you loaded the acpi_video module? What does `sysctl hw.acpi.video` say? > is it ACPI tables problem (kernel shows some errors). > > Other question - can amount of memory dedicated to GFX card be changed? > There is no option in BIOS setup to do this. and i have lots of memory > wasted as you may see below. > > > > Copyright (c) 1992-2014 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 10.1-BETA1 #4: Wed Oct 15 23:56:56 CEST 2014 > root@laptop:/usr/src/sys/amd64/compile/laptop amd64 > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > CPU: Intel(R) Celeron(R) CPU 1005M @ 1.90GHz (1895.73-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0x306a9 Family = 0x6 Model = 0x3a > Stepping = 9 > Features=0xbfebfbff APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI, > MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=0xdbae3bf VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2, > x2APIC,POPCNT,TSCDLT,XSAVE,OSXSAVE> > AMD Features=0x28100800 > AMD Features2=0x1 > Structured Extended Features=0x281 > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID > TSC: P-state invariant, performance statistics > real memory = 2147483648 (2048 MB) > avail memory = 1585037312 (1511 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 2 > ioapic0 irqs 0-23 on motherboard > random: initialized > iscsi: version 2.3.1 > kbd1 at kbdmux0 > cryptosoft0: on motherboard > acpi0: on motherboard > ACPI Error: No handler for Region [ECOR] (0xfffff80001710400) > [EmbeddedControl] (20130823/evregion-178) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20130823/exfldio-320) > ACPI Error: Method parse/execution failed [\134_SB_.PCI0.LPCB.H_EC._REG] > (Node 0xfffff8000171e200), AE_NOT_EXIST (20130823/psparse-553) > acpi0: Power Button (fixed) > cpu0: on acpi0 > cpu1: on acpi0 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 550 > Event timer "HPET1" frequency 14318180 Hz quality 440 > Event timer "HPET2" frequency 14318180 Hz quality 440 > Event timer "HPET3" frequency 14318180 Hz quality 440 > Event timer "HPET4" frequency 14318180 Hz quality 440 > Event timer "HPET5" frequency 14318180 Hz quality 440 > Event timer "HPET6" frequency 14318180 Hz quality 440 > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atrtc0: Warning: Couldn't map I/O. > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > vgapci0: port 0x3000-0x303f mem > 0x90000000-0x903fffff,0x80000000-0x8fffffff irq 16 at device 2.0 on pci0 > agp0: on vgapci0 > agp0: aperture size is 256M, detected 32764k stolen memory > vgapci0: Boot video device > xhci0: mem 0x90600000-0x9060ffff > irq 21 at device 20.0 on pci0 > xhci0: 32 byte context size. > xhci0: Port routing mask set to 0xffffffff > usbus0 on xhci0 > pci0: at device 22.0 (no driver attached) > ehci0: mem 0x9061a000-0x9061a3ff > irq 16 at device 26.0 on pci0 > usbus1: EHCI version 1.0 > usbus1 on ehci0 > hdac0: mem 0x90610000-0x90613fff irq > 22 at device 27.0 on pci0 > pcib1: irq 16 at device 28.0 on pci0 > pci1: on pcib1 > pcib2: irq 17 at device 28.1 on pci0 > pci2: on pcib2 > pci2: at device 0.0 (no driver attached) > pcib3: irq 19 at device 28.3 on pci0 > pci3: on pcib3 > re0: port > 0x2000-0x20ff mem 0x90404000-0x90404fff,0x90400000-0x90403fff irq 19 at > device 0.0 on pci3 > re0: Using 1 MSI-X message > re0: ASPM disabled > re0: Chip rev. 0x2c800000 > re0: MAC rev. 0x00100000 > miibus0: on re0 > ukphy0: PHY 1 on miibus0 > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > re0: Ethernet address: 54:ee:75:13:f2:6b > ehci1: mem 0x90619000-0x906193ff > irq 23 at device 29.0 on pci0 > usbus2: EHCI version 1.0 > usbus2 on ehci1 > isab0: at device 31.0 on pci0 > isa0: on isab0 > ahci0: port > 0x3088-0x308f,0x3094-0x3097,0x3080-0x3087,0x3090-0x3093,0x3060-0x307f mem > 0x90618000-0x906187ff irq 19 at device 31.2 on pci0 > ahci0: AHCI v1.30 with 4 6Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > ahcich4: at channel 4 on ahci0 > ahciem0: on ahci0 > acpi_acad0: on acpi0 > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > acpi_tz0: on acpi0 > acpi_tz1: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Generic PS/2 mouse, device ID 0 > battery0: on acpi0 > acpi_ibm0: on acpi0 > orm0: at iomem 0xc0000-0xcefff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > est0: on cpu0 > p4tcc0: on cpu0 > est1: on cpu1 > p4tcc1: on cpu1 > fuse-freebsd: version 0.4.4, FUSE ABI 7.8 > Timecounters tick every 1.000 msec > ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to accept, > logging disabled > DUMMYNET 0 with IPv6 initialized (100409) > load_dn_sched dn_sched RR loaded > load_dn_sched dn_sched WF2Q+ loaded > load_dn_sched dn_sched FIFO loaded > load_dn_sched dn_sched PRIO loaded > load_dn_sched dn_sched QFQ loaded > hdacc0: at cad 0 on hdac0 > hdaa0: at nid 1 on hdacc0 > pcm0: at nid 20,21 and 24,25 on hdaa0 > hdacc1: at cad 3 on hdac0 > hdaa1: at nid 1 on hdacc1 > pcm1: at nid 5 on hdaa1 > random: unblocking device. > usbus0: 5.0Gbps Super Speed USB v3.0 > usbus1: 480Mbps High Speed USB v2.0 > usbus2: 480Mbps High Speed USB v2.0 > ACPI Error: No handler for Region [ECRM] (0xfffff800017dd180) > [EmbeddedControl] (20130823/evregion-178) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20130823/exfldio-320) > ACPI Error: Method parse/execution failed [\134_TZ_.MDEC] (Node > 0xfffff80001725b40), AE_NOT_EXIST (20130823/psparse-553) > ACPI Error: Method parse/execution failed [\134_TZ_.TZS0._SCP] (Node > 0xfffff80001725a40), AE_NOT_EXIST (20130823/psparse-553) > ugen2.1: at usbus2 > uhub0: on usbus2 > ugen1.1: at usbus1 > ugen0.1: <0x8086> at usbus0 > uhub1: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 > uhub2: on usbus1 > ses0 at ahciem0 bus 0 scbus2 target 0 lun 0 > ses0: SEMB S-E-S 2.00 device > ses0: SEMB SES Device > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 2.x device > ada0: Serial Number WD-WXL1EB3KUNR5 > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > cd0 at ahcich4 bus 0 scbus1 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device cd0: > Serial Number KW9E4571958 > cd0: 150.000MB/s transfers (SATA 1.x, UDMA2, ATAPI 12bytes, PIO 8192bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present - > tray closed > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada0: quirks=0x1<4K> > ada0: Previously was known as ad0 > Enter passphrase for ada0d: SMP: AP CPU #1 Launched! > hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 > IAP/8/48/0x3ff > IAF/3/48/0x67 > Timecounter "TSC" frequency 1895731156 Hz quality 1000 > uhub1: 8 ports with 8 removable, self powered > uhub0: 3 ports with 3 removable, self powered > uhub2: 3 ports with 3 removable, self powered > ugen2.2: at usbus2 > uhub3: on > usbus2 > ugen1.2: at usbus1 > uhub4: on > usbus1 > uhub3: 4 ports with 4 removable, self powered > uhub4: 4 ports with 4 removable, self powered > ugen1.3: at usbus1 > ugen1.4: at usbus1 > umass0: 4> on usbus1 > da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: Serial Number 058F63666435 > da0: 40.000MB/s transfers > da0: Attempt to query device size failed: NOT READY, Medium not present > da0: quirks=0x2 > ugen1.5: at usbus1 > GEOM_ELI: Device ada0d.eli created. > GEOM_ELI: Encryption: AES-CBC 128 > GEOM_ELI: Crypto: software > Trying to mount root from ufs:ada0d.eli []... > _______________________________________________ > 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" > -- Cheers, Henry From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 16 17:04:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D90A3577 for ; Thu, 16 Oct 2014 17:04:14 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6332CF0 for ; Thu, 16 Oct 2014 17:04:14 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id h11so16522wiw.1 for ; Thu, 16 Oct 2014 10:04:12 -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=8VKew1lH6qeP8Y3IQs7Ih0JxWHhAXb8lx0YhQ1MOLXA=; b=KwssRcX2Rt1olL+wMRmOvf7dQMrybwBBTEEZzJ+wC0zDsU3SICqDsA1S2NGTZyLPv3 VLsIuUyaeQULviGXKO1FyQ9DJyw1dTdU8yYXifXG0HdmFvqyxIuro2qpTe4wQZc8iwBK FP7KcTcT7w7uxNBmLFj4pKydHb4brBbd74Tf6YL+fA5Un92y/Clcdbb3vZo2I51mu7LV 1y6ytF4HZGIxY6t5RvUWkJvJLPhJlAv6P5mYtQq+/QXK2X90F9BQ+RIcN3eHNyhkRWEJ MgPPhxoOvauQunjJIJzbVso9d0GTLV+ans+1Yy8P+XvdrmiWAp1Uvs/DjynEbOC1O6vR vDEA== MIME-Version: 1.0 X-Received: by 10.180.13.1 with SMTP id d1mr21952693wic.20.1413479052543; Thu, 16 Oct 2014 10:04:12 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Thu, 16 Oct 2014 10:04:12 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Oct 2014 10:04:12 -0700 X-Google-Sender-Auth: whRR-kGz8_m7dzxmqqQf22Tb3z8 Message-ID: Subject: Re: help with backlight control and memory From: Adrian Chadd To: Wojciech Puchar 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, 16 Oct 2014 17:04:15 -0000 Hi! Please try the latest FreeBSD-11 snapshot and see if it still works once you've started Xorg. -a On 16 October 2014 05:19, Wojciech Puchar wrote: > bought new laptop. it's lenovo B590 > > most things works fine. but brightness control keys doesn't work after > FreeBSD is loaded. they work before it. > > i don't ask for a solution but any point to start. What should i check? > > is it ACPI tables problem (kernel shows some errors). > > Other question - can amount of memory dedicated to GFX card be changed? > There is no option in BIOS setup to do this. and i have lots of memory > wasted as you may see below. > > > > Copyright (c) 1992-2014 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 10.1-BETA1 #4: Wed Oct 15 23:56:56 CEST 2014 > root@laptop:/usr/src/sys/amd64/compile/laptop amd64 > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > CPU: Intel(R) Celeron(R) CPU 1005M @ 1.90GHz (1895.73-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0x306a9 Family = 0x6 Model = 0x3a > Stepping = 9 > > Features=0xbfebfbff > > Features2=0xdbae3bf > AMD Features=0x28100800 > AMD Features2=0x1 > Structured Extended Features=0x281 > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID > TSC: P-state invariant, performance statistics > real memory = 2147483648 (2048 MB) > avail memory = 1585037312 (1511 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 2 > ioapic0 irqs 0-23 on motherboard > random: initialized > iscsi: version 2.3.1 > kbd1 at kbdmux0 > cryptosoft0: on motherboard > acpi0: on motherboard > ACPI Error: No handler for Region [ECOR] (0xfffff80001710400) > [EmbeddedControl] (20130823/evregion-178) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20130823/exfldio-320) > ACPI Error: Method parse/execution failed [\134_SB_.PCI0.LPCB.H_EC._REG] > (Node 0xfffff8000171e200), AE_NOT_EXIST (20130823/psparse-553) > acpi0: Power Button (fixed) > cpu0: on acpi0 > cpu1: on acpi0 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 550 > Event timer "HPET1" frequency 14318180 Hz quality 440 > Event timer "HPET2" frequency 14318180 Hz quality 440 > Event timer "HPET3" frequency 14318180 Hz quality 440 > Event timer "HPET4" frequency 14318180 Hz quality 440 > Event timer "HPET5" frequency 14318180 Hz quality 440 > Event timer "HPET6" frequency 14318180 Hz quality 440 > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atrtc0: Warning: Couldn't map I/O. > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > vgapci0: port 0x3000-0x303f mem > 0x90000000-0x903fffff,0x80000000-0x8fffffff irq 16 at device 2.0 on pci0 > agp0: on vgapci0 > agp0: aperture size is 256M, detected 32764k stolen memory > vgapci0: Boot video device > xhci0: mem 0x90600000-0x9060ffff > irq 21 at device 20.0 on pci0 > xhci0: 32 byte context size. > xhci0: Port routing mask set to 0xffffffff > usbus0 on xhci0 > pci0: at device 22.0 (no driver attached) > ehci0: mem 0x9061a000-0x9061a3ff > irq 16 at device 26.0 on pci0 > usbus1: EHCI version 1.0 > usbus1 on ehci0 > hdac0: mem 0x90610000-0x90613fff irq 22 > at device 27.0 on pci0 > pcib1: irq 16 at device 28.0 on pci0 > pci1: on pcib1 > pcib2: irq 17 at device 28.1 on pci0 > pci2: on pcib2 > pci2: at device 0.0 (no driver attached) > pcib3: irq 19 at device 28.3 on pci0 > pci3: on pcib3 > re0: port > 0x2000-0x20ff mem 0x90404000-0x90404fff,0x90400000-0x90403fff irq 19 at > device 0.0 on pci3 > re0: Using 1 MSI-X message > re0: ASPM disabled > re0: Chip rev. 0x2c800000 > re0: MAC rev. 0x00100000 > miibus0: on re0 > ukphy0: PHY 1 on miibus0 > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > re0: Ethernet address: 54:ee:75:13:f2:6b > ehci1: mem 0x90619000-0x906193ff > irq 23 at device 29.0 on pci0 > usbus2: EHCI version 1.0 > usbus2 on ehci1 > isab0: at device 31.0 on pci0 > isa0: on isab0 > ahci0: port > 0x3088-0x308f,0x3094-0x3097,0x3080-0x3087,0x3090-0x3093,0x3060-0x307f mem > 0x90618000-0x906187ff irq 19 at device 31.2 on pci0 > ahci0: AHCI v1.30 with 4 6Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > ahcich4: at channel 4 on ahci0 > ahciem0: on ahci0 > acpi_acad0: on acpi0 > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > acpi_tz0: on acpi0 > acpi_tz1: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Generic PS/2 mouse, device ID 0 > battery0: on acpi0 > acpi_ibm0: on acpi0 > orm0: at iomem 0xc0000-0xcefff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > est0: on cpu0 > p4tcc0: on cpu0 > est1: on cpu1 > p4tcc1: on cpu1 > fuse-freebsd: version 0.4.4, FUSE ABI 7.8 > Timecounters tick every 1.000 msec > ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to accept, > logging disabled > DUMMYNET 0 with IPv6 initialized (100409) > load_dn_sched dn_sched RR loaded > load_dn_sched dn_sched WF2Q+ loaded > load_dn_sched dn_sched FIFO loaded > load_dn_sched dn_sched PRIO loaded > load_dn_sched dn_sched QFQ loaded > hdacc0: at cad 0 on hdac0 > hdaa0: at nid 1 on hdacc0 > pcm0: at nid 20,21 and 24,25 on hdaa0 > hdacc1: at cad 3 on hdac0 > hdaa1: at nid 1 on hdacc1 > pcm1: at nid 5 on hdaa1 > random: unblocking device. > usbus0: 5.0Gbps Super Speed USB v3.0 > usbus1: 480Mbps High Speed USB v2.0 > usbus2: 480Mbps High Speed USB v2.0 > ACPI Error: No handler for Region [ECRM] (0xfffff800017dd180) > [EmbeddedControl] (20130823/evregion-178) > ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20130823/exfldio-320) > ACPI Error: Method parse/execution failed [\134_TZ_.MDEC] (Node > 0xfffff80001725b40), AE_NOT_EXIST (20130823/psparse-553) > ACPI Error: Method parse/execution failed [\134_TZ_.TZS0._SCP] (Node > 0xfffff80001725a40), AE_NOT_EXIST (20130823/psparse-553) > ugen2.1: at usbus2 > uhub0: on usbus2 > ugen1.1: at usbus1 > ugen0.1: <0x8086> at usbus0 > uhub1: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 > uhub2: on usbus1 > ses0 at ahciem0 bus 0 scbus2 target 0 lun 0 > ses0: SEMB S-E-S 2.00 device > ses0: SEMB SES Device > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 2.x device > ada0: Serial Number WD-WXL1EB3KUNR5 > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > cd0 at ahcich4 bus 0 scbus1 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device cd0: Serial > Number KW9E4571958 > cd0: 150.000MB/s transfers (SATA 1.x, UDMA2, ATAPI 12bytes, PIO 8192bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present - > tray closed > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada0: quirks=0x1<4K> > ada0: Previously was known as ad0 > Enter passphrase for ada0d: SMP: AP CPU #1 Launched! > hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 > IAP/8/48/0x3ff > IAF/3/48/0x67 > Timecounter "TSC" frequency 1895731156 Hz quality 1000 > uhub1: 8 ports with 8 removable, self powered > uhub0: 3 ports with 3 removable, self powered > uhub2: 3 ports with 3 removable, self powered > ugen2.2: at usbus2 > uhub3: on > usbus2 > ugen1.2: at usbus1 > uhub4: on > usbus1 > uhub3: 4 ports with 4 removable, self powered > uhub4: 4 ports with 4 removable, self powered > ugen1.3: at usbus1 > ugen1.4: at usbus1 > umass0: > on usbus1 > da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device da0: > Serial Number 058F63666435 > da0: 40.000MB/s transfers > da0: Attempt to query device size failed: NOT READY, Medium not present > da0: quirks=0x2 > ugen1.5: at usbus1 > GEOM_ELI: Device ada0d.eli created. > GEOM_ELI: Encryption: AES-CBC 128 > GEOM_ELI: Crypto: software > Trying to mount root from ufs:ada0d.eli []... > _______________________________________________ > 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 Oct 16 22:15:58 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47C5A455 for ; Thu, 16 Oct 2014 22:15:58 +0000 (UTC) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::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 0B23A948 for ; Thu, 16 Oct 2014 22:15:57 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id le20so3485866vcb.12 for ; Thu, 16 Oct 2014 15:15:57 -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=T1kiNWZ1wFy1O1hLkSUGsL2Su7qzIKddR2KqdzKKUf0=; b=i0qOY3QRP5mml1SgGXQiC9Vy2CZaj1aMD79KzIJMy9y0ul4QTuYnxJhDP8da5qidPk p5C4sk2aM5E5ZUOPBK0M6yF0UQa78xYEpw8mZlVJ4fiCQ6CXX3ZHiVfWxQ8GSRzYX2V1 bKuvtnr6q5I2J7IlefeBbQ7arLeeqYaW8+ZIKV2H4H6fBRFBidwJ/eBoX+UI7faP5rf/ 87DCQz95c3dYdY6xgI+F1EleJg4FcAZMK4Cea80i8fKR/Tb2aCl8EeZqZlzpAVHz4/i8 T3bv2kWvLwx6tLKNCaUl2WX7ma6ZvoVNyOtAYjvJoPcjEFhZ+3T3sfkuPvBK6SuDQ/2W E2Ng== MIME-Version: 1.0 X-Received: by 10.52.167.195 with SMTP id zq3mr3493554vdb.44.1413497757077; Thu, 16 Oct 2014 15:15:57 -0700 (PDT) Sender: jlehen@gmail.com Received: by 10.31.136.79 with HTTP; Thu, 16 Oct 2014 15:15:57 -0700 (PDT) Date: Fri, 17 Oct 2014 00:15:57 +0200 X-Google-Sender-Auth: v5weWoheibH60JIOUbkQIEZynSQ Message-ID: Subject: struct bintime From: Jeremie Le Hen To: freebsd-hackers@FreeBSD.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 22:15:58 -0000 Hi, I need to get microseconds from a struct bintime. I found bintime2timeval() in sys/time.h which more or less does this, but I don't understand how the computation works. Can someone explain it to me please? static __inline void bintime2timeval(const struct bintime *_bt, struct timeval *_tv) { _tv->tv_sec = _bt->sec; _tv->tv_usec = ((uint64_t)1000000 * (uint32_t)(_bt->frac >> 32)) >> 32; } Thanks! -- Jeremie Le Hen jlh@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 16 22:47: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2715D1DF; Thu, 16 Oct 2014 22:47:42 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id DEE92C11; Thu, 16 Oct 2014 22:47:41 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 7F31A7300A; Fri, 17 Oct 2014 00:51:19 +0200 (CEST) Date: Fri, 17 Oct 2014 00:51:19 +0200 From: Luigi Rizzo To: Jeremie Le Hen Subject: Re: struct bintime Message-ID: <20141016225119.GD10204@onelab2.iet.unipi.it> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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, 16 Oct 2014 22:47:42 -0000 On Fri, Oct 17, 2014 at 12:15:57AM +0200, Jeremie Le Hen wrote: > Hi, > > I need to get microseconds from a struct bintime. I found > bintime2timeval() in sys/time.h which more or less does this, but I > don't understand how the computation works. > > Can someone explain it to me please? > > static __inline void > bintime2timeval(const struct bintime *_bt, struct timeval *_tv) > { > > _tv->tv_sec = _bt->sec; > _tv->tv_usec = ((uint64_t)1000000 * (uint32_t)(_bt->frac >> 32)) >> 32; > } bt->frac has 64 bits representing the fractional part of the second, call it f, with 0 <= f < 1 (uint32_t)(_bt->frac >> 32) is equivalent to \floor{f * 2^32} you then multiply by 10^6 and do an integer division by 2^32 so the overall expression is tv_usec = \floor{ ( 10^6 * \floor{f * 2^32} ) / 2^32 } = \floor{ 10^6*f } i.e. the number of microseconds. cheers luigi > Thanks! > -- > Jeremie Le Hen > jlh@FreeBSD.org > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 16 22:48:37 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A25132C4; Thu, 16 Oct 2014 22:48:37 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5FDEBC1E; Thu, 16 Oct 2014 22:48:37 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::35d1:185d:a69:50df] (unknown [IPv6:2001:7b8:3a7:0:35d1:185d:a69:50df]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 7C737B80A; Fri, 17 Oct 2014 00:48:33 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_4BFEECBE-F3E4-4609-9EA6-CAD13806F845"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: struct bintime From: Dimitry Andric In-Reply-To: Date: Fri, 17 Oct 2014 00:48:14 +0200 Message-Id: <353C79A7-1D1D-48CF-8B42-7BA369D22321@FreeBSD.org> References: To: Jeremie Le Hen 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: Thu, 16 Oct 2014 22:48:37 -0000 --Apple-Mail=_4BFEECBE-F3E4-4609-9EA6-CAD13806F845 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 17 Oct 2014, at 00:15, Jeremie Le Hen wrote: > I need to get microseconds from a struct bintime. I found > bintime2timeval() in sys/time.h which more or less does this, but I > don't understand how the computation works. >=20 > Can someone explain it to me please? >=20 > static __inline void > bintime2timeval(const struct bintime *_bt, struct timeval *_tv) > { >=20 > _tv->tv_sec =3D _bt->sec; > _tv->tv_usec =3D ((uint64_t)1000000 * (uint32_t)(_bt->frac >> = 32)) >> 32; > } Maybe it's easier to grok if you read it as: usec =3D (10^6 * (frac / 2^32)) / 2^32 or even: usec =3D 10^6 * (frac / 2^64) and the other way around: frac =3D (usec / 10^6) * 2^64 E.g., bintime divides a second into 2^64 slices, instead of 10^6 or 10^9. And the division by 2^64 in bintime2timeval() is split up in two shifts, to avoid losing precision. -Dimitry --Apple-Mail=_4BFEECBE-F3E4-4609-9EA6-CAD13806F845 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlRASzsACgkQsF6jCi4glqNb9QCg5prZlWvI1JyvzhqdNJC0h2gM B1kAniyO5+eJGWXqyuj2AoBDhljA3Gy8 =RE2w -----END PGP SIGNATURE----- --Apple-Mail=_4BFEECBE-F3E4-4609-9EA6-CAD13806F845-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 17 16:52:24 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C694B5D3 for ; Fri, 17 Oct 2014 16:52:24 +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 9BDEAFE2 for ; Fri, 17 Oct 2014 16:52:24 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7A508B91E; Fri, 17 Oct 2014 12:52:23 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Tool to access ZFS/NFSv4 alternate data streams on FreeBSD? Date: Fri, 17 Oct 2014 11:58:04 -0400 Message-ID: <61546786.Po81nNR1Xh@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: References: <102210795.47541414.1410995911907.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 17 Oct 2014 12:52:23 -0400 (EDT) Cc: Rick Macklem , Jan Bramkamp , Simon Toedt , Jordan Hubbard , Lionel Cons , Richard Yao X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 16:52:24 -0000 On Wednesday, October 15, 2014 12:21:43 AM Lionel Cons wrote: > On 18 September 2014 01:18, Rick Macklem wrote: > > Well, first I believe the FreeBSD project (I refer to it as the > > "collective" for want of a better word) needs to come to a consensus > > that this should be done. > > > > As I understand it, the first step towards that is a post on > > freebsd-arch@ proposing this work and why you think it is a good idea. > > > > Then, based upon the discussion/comments in response to this post, it will > > hopefully become fairly clear if the "collective" is in favour > > of doing this or not. > > > > Then, if the consensus is in favour, someone needs to do the > > coding. (I have volunteered to at least look at the kernel changes, > > but only the kernel changes.) > > Okay. I've just got the go-ahead, and initial funding :) Do you have a proposed design for how you plan to implement O_XATTR? Also, are you targeting a specific filesystem (e.g. ZFS?) -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 17 16:52: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55F045D4; Fri, 17 Oct 2014 16:52:25 +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 308EEFE3; Fri, 17 Oct 2014 16:52:25 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3E1F9B98D; Fri, 17 Oct 2014 12:52:24 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: panic in ivy_rng_store() when compiled with -O0 Date: Fri, 17 Oct 2014 11:53:58 -0400 Message-ID: <2533199.DHZybpy49d@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: <54384ABD.5080806@FreeBSD.org> References: <54384ABD.5080806@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 17 Oct 2014 12:52:24 -0400 (EDT) Cc: Navdeep Parhar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 16:52:25 -0000 On Friday, October 10, 2014 02:08:13 PM Navdeep Parhar wrote: > I built my kernel + modules (head as of today) with -O0 and now it > panics during boot. I did bump up KSTACK_PAGES significantly so that's > not the problem. I'm going to take out the RNG device next and see if I > can get past this. > > Regards, > Navdeep > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xffffffff814ac661 > stack pointer = 0x28:0xfffffe01ed6c6930 > frame pointer = 0x28:0xfffffe01ed6c6960 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 14 (rand_harvestq) > [ thread pid 14 tid 100017 ] > Stopped at ivy_rng_store+0x31: movq %rdi,(%rdi) > db> bt > Tracing pid 14 tid 100017 td 0xfffff800042c84c0 > ivy_rng_store() at ivy_rng_store+0x31/frame 0xfffffe01ed6c6960 > random_ivy_read() at random_ivy_read+0x78/frame 0xfffffe01ed6c6990 > live_entropy_sources_feed() at live_entropy_sources_feed+0x73/frame > 0xfffffe01ed6c69d0 > random_kthread() at random_kthread+0x224/frame 0xfffffe01ed6c6a30 > fork_exit() at fork_exit+0x14a/frame 0xfffffe01ed6c6ab0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe01ed6c6ab0 > --- trap 0, rip = 0, rsp = 0xfffffe01ed6c6b70, rbp = 0 --- Can you 'p $rdi'? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 17 18:00: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E6856B1; Fri, 17 Oct 2014 18:00:02 +0000 (UTC) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e: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 EB0968F3; Fri, 17 Oct 2014 18:00:01 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id ey11so1262369pad.13 for ; Fri, 17 Oct 2014 11:00:01 -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:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=3cCLFWNrps3KFEiPiP6skUMMwo6PJM3l8Z5tc1BBKhE=; b=PcGcokNxnVzbAK2xwQPhGntbSllb3LW0ZZOlvlZ39QxSwXL7FVlbLronnsUqzAQKhz NNfcO99j9dfUMalfSeoHPRffrXWfqWqbyRaBNfI2mgKN/OfqutonbYXLCQ1+BJvs0AFL q+3HngJYGvyHBwNLt9yIcL74aUMdPDTjjpdXGmfIp553tQTi4aWRmhYcBHuzF+mwTrcn Fw8wlFhkE8R27u0361Dzka2oLqScu9h2vAxdHFn2x6dMUtaHtTcGyqRMv0JcOpvcevjg t//9tf8grApPixZpdDf9chxJHC9cnHDiPvWGQJ7bO5A6TU8DhvBMS5/K/Ulb2J5XMJxy Z8kg== X-Received: by 10.66.219.38 with SMTP id pl6mr10039845pac.43.1413568800968; Fri, 17 Oct 2014 11:00:00 -0700 (PDT) Received: from ox ([24.6.44.228]) by mx.google.com with ESMTPSA id ey5sm2110406pbb.67.2014.10.17.10.59.58 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 17 Oct 2014 10:59:59 -0700 (PDT) Sender: Navdeep Parhar Date: Fri, 17 Oct 2014 10:59:18 -0700 From: Navdeep Parhar To: John Baldwin Subject: Re: panic in ivy_rng_store() when compiled with -O0 Message-ID: <20141017175918.GA6074@ox> Mail-Followup-To: John Baldwin , freebsd-hackers@freebsd.org References: <54384ABD.5080806@FreeBSD.org> <2533199.DHZybpy49d@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2533199.DHZybpy49d@ralph.baldwin.cx> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Fri, 17 Oct 2014 18:00:02 -0000 On Fri, Oct 17, 2014 at 11:53:58AM -0400, John Baldwin wrote: > On Friday, October 10, 2014 02:08:13 PM Navdeep Parhar wrote: > > I built my kernel + modules (head as of today) with -O0 and now it > > panics during boot. I did bump up KSTACK_PAGES significantly so that's > > not the problem. I'm going to take out the RNG device next and see if I > > can get past this. > > > > Regards, > > Navdeep > > > > Fatal trap 9: general protection fault while in kernel mode > > cpuid = 0; apic id = 00 > > instruction pointer = 0x20:0xffffffff814ac661 > > stack pointer = 0x28:0xfffffe01ed6c6930 > > frame pointer = 0x28:0xfffffe01ed6c6960 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 14 (rand_harvestq) > > [ thread pid 14 tid 100017 ] > > Stopped at ivy_rng_store+0x31: movq %rdi,(%rdi) > > db> bt > > Tracing pid 14 tid 100017 td 0xfffff800042c84c0 > > ivy_rng_store() at ivy_rng_store+0x31/frame 0xfffffe01ed6c6960 > > random_ivy_read() at random_ivy_read+0x78/frame 0xfffffe01ed6c6990 > > live_entropy_sources_feed() at live_entropy_sources_feed+0x73/frame > > 0xfffffe01ed6c69d0 > > random_kthread() at random_kthread+0x224/frame 0xfffffe01ed6c6a30 > > fork_exit() at fork_exit+0x14a/frame 0xfffffe01ed6c6ab0 > > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe01ed6c6ab0 > > --- trap 0, rip = 0, rsp = 0xfffffe01ed6c6b70, rbp = 0 --- > > Can you 'p $rdi'? I don't have this core around any more. The problem was fixed in r273027. Navdeep From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 17 18:21:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D849CB4F; Fri, 17 Oct 2014 18:21:08 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B40B5B68; Fri, 17 Oct 2014 18:21:08 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 34A6C14639; Fri, 17 Oct 2014 11:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1413570068; x=1413584468; bh=HKOcKtEv2pSSm+Jss6BmTdpFe1b9syw4HLiTKcI+F04=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=NSQDQfhOJSTiu593rlMGYR496CZV7xjQkMGiDfEQSoCCfwNiegCz/TYXV5mfrsX7R G1bdjH/hiiCx2tcZbf7VnAQ76XD8tzmp6bGisXcIJ50SWXF9LNZaA6icHUUuFBN9FB Q30gps/SoRoGgkqvcEr2ITDw4uLODtemLym1n2pk= Message-ID: <54415E13.4000203@delphij.net> Date: Fri, 17 Oct 2014 11:21:07 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: John Baldwin , freebsd-hackers@freebsd.org Subject: Re: panic in ivy_rng_store() when compiled with -O0 References: <54384ABD.5080806@FreeBSD.org> <2533199.DHZybpy49d@ralph.baldwin.cx> In-Reply-To: <2533199.DHZybpy49d@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Navdeep Parhar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:21:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/17/14 08:53, John Baldwin wrote: > On Friday, October 10, 2014 02:08:13 PM Navdeep Parhar wrote: >> I built my kernel + modules (head as of today) with -O0 and now >> it panics during boot. I did bump up KSTACK_PAGES significantly >> so that's not the problem. I'm going to take out the RNG device >> next and see if I can get past this. >> >> Regards, Navdeep >> >> Fatal trap 9: general protection fault while in kernel mode cpuid >> = 0; apic id = 00 instruction pointer = 0x20:0xffffffff814ac661 >> stack pointer = 0x28:0xfffffe01ed6c6930 frame pointer >> = 0x28:0xfffffe01ed6c6960 code segment = base 0x0, limit >> 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 current >> process = 14 (rand_harvestq) [ thread pid 14 tid 100017 ] >> Stopped at ivy_rng_store+0x31: movq %rdi,(%rdi) db> >> bt Tracing pid 14 tid 100017 td 0xfffff800042c84c0 >> ivy_rng_store() at ivy_rng_store+0x31/frame 0xfffffe01ed6c6960 >> random_ivy_read() at random_ivy_read+0x78/frame >> 0xfffffe01ed6c6990 live_entropy_sources_feed() at >> live_entropy_sources_feed+0x73/frame 0xfffffe01ed6c69d0 >> random_kthread() at random_kthread+0x224/frame >> 0xfffffe01ed6c6a30 fork_exit() at fork_exit+0x14a/frame >> 0xfffffe01ed6c6ab0 fork_trampoline() at fork_trampoline+0xe/frame >> 0xfffffe01ed6c6ab0 --- trap 0, rip = 0, rsp = 0xfffffe01ed6c6b70, >> rbp = 0 --- > > Can you 'p $rdi'? movq %rdi,(%rdi) is obviously wrong (%rdi holds the result from rdrand), which I believed to be a compiler bug in register allocation. Navdeep have committed a change to mark 'tmp' input+output, which does fix the output but I'm not 100% sure if that's right, as 'tmp' is not considered an input of the inline assembler block, and this may break compile on other compilers, but for now it's better than previous situation. Speaking for the compiler issue, Dimitry have reported this upstream at: http://llvm.org/bugs/show_bug.cgi?id=21273 There is a suggestion in the reply, that change 'tmp' to early clobber would workaround the issue, like: Index: ivy.c =================================================================== - --- ivy.c (revision 273195) +++ ivy.c (working copy) @@ -79,7 +79,7 @@ "2:\n\t" "mov %2,%1\n\t" /* *buf = tmp */ "3:" - - : "+q" (retry), "=m" (*buf), "+q" (tmp) : : "cc"); + : "+q" (retry), "=m" (*buf), "=&q" (tmp) : : "cc"); return (retry); #else /* __GNUCLIKE_ASM */ return (0); A glance at the resulting assembler seems sane but I haven't got some time to carefully review the result yet. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0 iQIcBAEBCgAGBQJUQV4TAAoJEJW2GBstM+ns2BsP/0xOr27EWZ21ypSLxw9p0cnJ cEPVdi7ewOL3MM8Op91Ek30BFKsogM/JQWSYp9GCwyO5O1t7eGrCVCxUObkXWgZF wzSSvGGz4vkLoIcs22bXzfkkWeyMBxL/M0qlTYLT1hq/co5ARRy2XQ2kHp/zfn/0 xFumeoEaBdRAt9LKHdW/NYqyc6FPRilclftNgMQMYyQKehb5oNlj2WLST7ol9gHm VCZE2CfiHkLGxG8sW9QN8Si98jTjs7wPsVM/FBJBC8ABcIyf2urnx+vMcx5QGH/r cKWDqyX6coCGQ1mSTEitoU2E3PuGgEqFkzbctxA/mRVCw+f2XIzdyw86ImaOqOJH 6fP6WZnffV82WdgJEaNWI6EB8wuvS2Ic7tZUuKJU0KYCwU8E9hYAsUuzdWF76zm7 X8TU4LWfsX24CglJ/bNEHpWbCAXjQAblYxK7P1W1ppfHSm4pnBZWL7XADlDVAiYT GaVVVEX9pUQJC4lX84C+UvoBFHWnwyLzecMDGNEFaCey+KFkyaCHf2vaK/KK5Tzb oprFA9V9nl6P5ZvAU8EWnFsKZUh1y/8+C2d26m8kMYkp2IGex8zV9ivOh/WKhdSK 8oz3QlPq+A49SfZkK6HafTa4HTBgkkr22/Xh+MACbIdpV3lskSGZD+IRq8BKbVm/ sJh9aJMRPpQ/FfHWNnCF =aLJ0 -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 17 18:34:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26342FC6; Fri, 17 Oct 2014 18:34:05 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB214C92; Fri, 17 Oct 2014 18:34:04 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::74:4835:c62e:9c49] (unknown [IPv6:2001:7b8:3a7:0:74:4835:c62e:9c49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 60284B80A; Fri, 17 Oct 2014 20:34:00 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: panic in ivy_rng_store() when compiled with -O0 From: Dimitry Andric In-Reply-To: <54415E13.4000203@delphij.net> Date: Fri, 17 Oct 2014 20:33:57 +0200 Content-Transfer-Encoding: 7bit Message-Id: <7A5C3D84-1B1F-4BA3-818D-37231BF424FE@FreeBSD.org> References: <54384ABD.5080806@FreeBSD.org> <2533199.DHZybpy49d@ralph.baldwin.cx> <54415E13.4000203@delphij.net> To: d@delphij.net X-Mailer: Apple Mail (2.1990.1) Cc: freebsd-hackers@freebsd.org, Navdeep Parhar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:34:05 -0000 On 17 Oct 2014, at 20:21, Xin Li wrote: > On 10/17/14 08:53, John Baldwin wrote: >> On Friday, October 10, 2014 02:08:13 PM Navdeep Parhar wrote: ... > movq %rdi,(%rdi) is obviously wrong (%rdi holds the result from > rdrand), which I believed to be a compiler bug in register allocation. > > Navdeep have committed a change to mark 'tmp' input+output, which does > fix the output but I'm not 100% sure if that's right, as 'tmp' is not > considered an input of the inline assembler block, and this may break > compile on other compilers, but for now it's better than previous > situation. > > Speaking for the compiler issue, Dimitry have reported this upstream at: > > http://llvm.org/bugs/show_bug.cgi?id=21273 > > There is a suggestion in the reply, that change 'tmp' to early clobber > would workaround the issue, like: > > Index: ivy.c > =================================================================== > - --- ivy.c (revision 273195) > +++ ivy.c (working copy) > @@ -79,7 +79,7 @@ > "2:\n\t" > "mov %2,%1\n\t" /* *buf = tmp */ > "3:" > - - : "+q" (retry), "=m" (*buf), "+q" (tmp) : : "cc"); > + : "+q" (retry), "=m" (*buf), "=&q" (tmp) : : "cc"); Yes, this generates the correct code for all cases I tried, e.g. with gcc 4.2 from base, gcc 4.7 through 5.0 from ports, clang 3.4, clang 3.5 and clang trunk, all at -O0 through -O3, and -Os. So at the moment this fix is the best option, I think. -Dimitry From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 18 16:53:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 822783DA; Sat, 18 Oct 2014 16:53:41 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EA29221; Sat, 18 Oct 2014 16:53:40 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s9IGrYlM075871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Oct 2014 19:53:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s9IGrYlM075871 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s9IGrWVB075870; Sat, 18 Oct 2014 19:53:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 18 Oct 2014 19:53:32 +0300 From: Konstantin Belousov To: John Baldwin Subject: Re: Fwd: Questions with the in_cksumdata() function in sys/amd64/amd64/in_cksum.c Message-ID: <20141018165332.GK2153@kib.kiev.ua> References: <5764827.IHU6o1xrAW@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5764827.IHU6o1xrAW@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers , btw@mail.ustc.edu.cn 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, 18 Oct 2014 16:53:41 -0000 On Sat, Oct 18, 2014 at 07:29:12AM -0400, John Baldwin wrote: > Do you have any thoughts on this? On modern Intel CPUs with the hardware > prefetcher this would seem to be a waste, so I wonder how useful this is > in practice. I would be not surprised if this manual prefetching by explicit reads causes slowdown of the function. I suspect it could confuse hardware prefetcher by breaking the linear pattern, or the patch could break the logic of the limited forward-looking oracle by reading too far from the current linear read tip. Also, it could confuse the data flow engine if the register allocator is unable to see that the read value is needed not right now, and cause unneeded stall while next cache line is fetched. Sure, all my speculations are pure garbage until confirmed by measurements with pmc, but I think that the patch below must be benchmarked to confirm any value it provides as well. My opinion is, we should either remove the manual prefetch, or do it with PREFETCHLX instructions only, instead of real read. > > ---------- Forwarded Message ---------- > > Subject: Questions with the in_cksumdata() function in > sys/amd64/amd64/in_cksum.c > Date: Friday, September 26, 2014, 10:51:36 PM > From: btw@mail.ustc.edu.cn > To: freebsd-hackers > > Hi All, > > I'm reading the in_cksumdata() function in sys/amd64/amd64/in_cksum.c, and > I have some questions with the following comment and code: > > static u_int64_t > in_cksumdata(const void *buf, int len) > { > ...... > > /* > * access prefilling to start load of next cache line. > * then add current cache line > * save result of prefilling for loop iteration. > */ > prefilled = lw[0]; > while ((len -= 32) >= 4) { > u_int64_t prefilling = lw[8]; > sum += prefilled + lw[1] + lw[2] + lw[3] > + lw[4] + lw[5] + lw[6] + lw[7]; > lw += 8; > prefilled = prefilling; > } > > ...... > } > > It said that it adds the current cache line, and it adds 32 bytes actually, > while on amd64 platform, the size of each cache line is 64 bytes. So I think > the correct code should be something like this: > > static u_int64_t > in_cksumdata(const void *buf, int len) > { > ...... > > /* > * access prefilling to start load of next cache line. > * then add current cache line > * save result of prefilling for loop iteration. > */ > prefilled = lw[0]; > while ((len -= 64) >= 4) { > u_int64_t prefilling = lw[16]; > sum += prefilled + lw[1] + lw[2] + lw[3] > + lw[4] + lw[5] + lw[6] + lw[7] > + lw[8] + lw[9] + lw[10] + lw[11] > + lw[12] + lw[13] + lw[14] + lw[15]; > lw += 16; > prefilled = prefilling; > } > > ...... > } > > The full patch is: > > diff --git a/in_cksum.c b/in_cksum.c > index 2ae3a0c..4f141f8 100644 > --- a/in_cksum.c > +++ b/in_cksum.c > @@ -140,19 +140,23 @@ in_cksumdata(const void *buf, int len) > * save result of prefilling for loop iteration. > */ > prefilled = lw[0]; > - while ((len -= 32) >= 4) { > - u_int64_t prefilling = lw[8]; > + while ((len -= 64) >= 4) { > + u_int64_t prefilling = lw[16]; > sum += prefilled + lw[1] + lw[2] + lw[3] > - + lw[4] + lw[5] + lw[6] + lw[7]; > - lw += 8; > + + lw[4] + lw[5] + lw[6] + lw[7] > + + lw[8] + lw[9] + lw[10] + lw[11] > + + lw[12] + lw[13] + lw[14] + lw[15]; > + lw += 16; > prefilled = prefilling; > } > if (len >= 0) { > sum += prefilled + lw[1] + lw[2] + lw[3] > - + lw[4] + lw[5] + lw[6] + lw[7]; > - lw += 8; > + + lw[4] + lw[5] + lw[6] + lw[7] > + + lw[8] + lw[9] + lw[10] + lw[11] > + + lw[12] + lw[13] + lw[14] + lw[15]; > + lw += 16; > } else { > - len += 32; > + len += 64; > } > while ((len -= 16) >= 0) { > sum += (u_int64_t) lw[0] + lw[1] + lw[2] + lw[3]; > > Sorry about the confusion if I did something wrong. > > - twb > _______________________________________________ > 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" > ----------------------------------------- > > -- > John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 18 18:23:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C50AED4 for ; Sat, 18 Oct 2014 18:23:23 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CC262C22 for ; Sat, 18 Oct 2014 18:23:22 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id s9IINDCm047024; Sat, 18 Oct 2014 20:23:13 +0200 (CEST) (envelope-from wojtek@puchar.net) Date: Sat, 18 Oct 2014 20:23:09 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop To: Henry Hu Subject: Re: help with backlight control and memory 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 (puchar.net [10.0.1.1]); Sat, 18 Oct 2014 20:23:13 +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: Sat, 18 Oct 2014 18:23:23 -0000 > bought new laptop. it's lenovo B590 > > most things works fine. but brightness control keys doesn't work after FreeBSD is loaded. they work before it. > > i don't ask for a solution but any point to start. What should i check? > > > Have you loaded the acpi_video module? What does `sysctl hw.acpi.video` say? no i didn't. but after loading: hw.acpi.reset_video: 0 hw.acpi.video.lcd0.active: 0 hw.acpi.video.lcd0.brightness: 99 hw.acpi.video.lcd0.fullpower: 100 hw.acpi.video.lcd0.economy: 100 hw.acpi.video.lcd0.levels: 100 100 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 dev.acpi_video.%parent: dev.acpi_video.0.%desc: ACPI video extension dev.acpi_video.0.%driver: acpi_video dev.acpi_video.0.%location: dev.acpi_video.0.%pnpinfo: dev.acpi_video.0.%parent: vgapci0 no effect on keys. still doesn't work From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 18 18:24:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8CAD9FBB; Sat, 18 Oct 2014 18:24:05 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F27FC31; Sat, 18 Oct 2014 18:24:04 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id s9IIO3mO047045; Sat, 18 Oct 2014 20:24:03 +0200 (CEST) (envelope-from wojtek@puchar.net) Date: Sat, 18 Oct 2014 20:23:59 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop To: Adrian Chadd Subject: Re: help with backlight control and memory 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 (puchar.net [10.0.1.1]); Sat, 18 Oct 2014 20:24:03 +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: Sat, 18 Oct 2014 18:24:05 -0000 > > Please try the latest FreeBSD-11 snapshot and see if it still works > once you've started Xorg. it doesn't work in FreeBSD-10 just after booting kernel, no matter if i run X or not. i will try latest svn snapshot. > > > -a > > > On 16 October 2014 05:19, Wojciech Puchar wrote: >> bought new laptop. it's lenovo B590 >> >> most things works fine. but brightness control keys doesn't work after >> FreeBSD is loaded. they work before it. >> >> i don't ask for a solution but any point to start. What should i check? >> >> is it ACPI tables problem (kernel shows some errors). >> >> Other question - can amount of memory dedicated to GFX card be changed? >> There is no option in BIOS setup to do this. and i have lots of memory >> wasted as you may see below. >> >> >> >> Copyright (c) 1992-2014 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 10.1-BETA1 #4: Wed Oct 15 23:56:56 CEST 2014 >> root@laptop:/usr/src/sys/amd64/compile/laptop amd64 >> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 >> CPU: Intel(R) Celeron(R) CPU 1005M @ 1.90GHz (1895.73-MHz K8-class CPU) >> Origin = "GenuineIntel" Id = 0x306a9 Family = 0x6 Model = 0x3a >> Stepping = 9 >> >> Features=0xbfebfbff >> >> Features2=0xdbae3bf >> AMD Features=0x28100800 >> AMD Features2=0x1 >> Structured Extended Features=0x281 >> VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID >> TSC: P-state invariant, performance statistics >> real memory = 2147483648 (2048 MB) >> avail memory = 1585037312 (1511 MB) >> Event timer "LAPIC" quality 600 >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> FreeBSD/SMP: 1 package(s) x 2 core(s) >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 2 >> ioapic0 irqs 0-23 on motherboard >> random: initialized >> iscsi: version 2.3.1 >> kbd1 at kbdmux0 >> cryptosoft0: on motherboard >> acpi0: on motherboard >> ACPI Error: No handler for Region [ECOR] (0xfffff80001710400) >> [EmbeddedControl] (20130823/evregion-178) >> ACPI Error: Region EmbeddedControl (ID=3) has no handler >> (20130823/exfldio-320) >> ACPI Error: Method parse/execution failed [\134_SB_.PCI0.LPCB.H_EC._REG] >> (Node 0xfffff8000171e200), AE_NOT_EXIST (20130823/psparse-553) >> acpi0: Power Button (fixed) >> cpu0: on acpi0 >> cpu1: on acpi0 >> hpet0: iomem 0xfed00000-0xfed003ff on acpi0 >> Timecounter "HPET" frequency 14318180 Hz quality 950 >> Event timer "HPET" frequency 14318180 Hz quality 550 >> Event timer "HPET1" frequency 14318180 Hz quality 440 >> Event timer "HPET2" frequency 14318180 Hz quality 440 >> Event timer "HPET3" frequency 14318180 Hz quality 440 >> Event timer "HPET4" frequency 14318180 Hz quality 440 >> Event timer "HPET5" frequency 14318180 Hz quality 440 >> Event timer "HPET6" frequency 14318180 Hz quality 440 >> atrtc0: port 0x70-0x77 irq 8 on acpi0 >> atrtc0: Warning: Couldn't map I/O. >> Event timer "RTC" frequency 32768 Hz quality 0 >> attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> Event timer "i8254" frequency 1193182 Hz quality 100 >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >> acpi_ec0: port 0x62,0x66 on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> vgapci0: port 0x3000-0x303f mem >> 0x90000000-0x903fffff,0x80000000-0x8fffffff irq 16 at device 2.0 on pci0 >> agp0: on vgapci0 >> agp0: aperture size is 256M, detected 32764k stolen memory >> vgapci0: Boot video device >> xhci0: mem 0x90600000-0x9060ffff >> irq 21 at device 20.0 on pci0 >> xhci0: 32 byte context size. >> xhci0: Port routing mask set to 0xffffffff >> usbus0 on xhci0 >> pci0: at device 22.0 (no driver attached) >> ehci0: mem 0x9061a000-0x9061a3ff >> irq 16 at device 26.0 on pci0 >> usbus1: EHCI version 1.0 >> usbus1 on ehci0 >> hdac0: mem 0x90610000-0x90613fff irq 22 >> at device 27.0 on pci0 >> pcib1: irq 16 at device 28.0 on pci0 >> pci1: on pcib1 >> pcib2: irq 17 at device 28.1 on pci0 >> pci2: on pcib2 >> pci2: at device 0.0 (no driver attached) >> pcib3: irq 19 at device 28.3 on pci0 >> pci3: on pcib3 >> re0: port >> 0x2000-0x20ff mem 0x90404000-0x90404fff,0x90400000-0x90403fff irq 19 at >> device 0.0 on pci3 >> re0: Using 1 MSI-X message >> re0: ASPM disabled >> re0: Chip rev. 0x2c800000 >> re0: MAC rev. 0x00100000 >> miibus0: on re0 >> ukphy0: PHY 1 on miibus0 >> ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow >> re0: Ethernet address: 54:ee:75:13:f2:6b >> ehci1: mem 0x90619000-0x906193ff >> irq 23 at device 29.0 on pci0 >> usbus2: EHCI version 1.0 >> usbus2 on ehci1 >> isab0: at device 31.0 on pci0 >> isa0: on isab0 >> ahci0: port >> 0x3088-0x308f,0x3094-0x3097,0x3080-0x3087,0x3090-0x3093,0x3060-0x307f mem >> 0x90618000-0x906187ff irq 19 at device 31.2 on pci0 >> ahci0: AHCI v1.30 with 4 6Gbps ports, Port Multiplier not supported >> ahcich0: at channel 0 on ahci0 >> ahcich4: at channel 4 on ahci0 >> ahciem0: on ahci0 >> acpi_acad0: on acpi0 >> acpi_lid0: on acpi0 >> acpi_button0: on acpi0 >> acpi_tz0: on acpi0 >> acpi_tz1: on acpi0 >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> psm0: irq 12 on atkbdc0 >> psm0: [GIANT-LOCKED] >> psm0: model Generic PS/2 mouse, device ID 0 >> battery0: on acpi0 >> acpi_ibm0: on acpi0 >> orm0: at iomem 0xc0000-0xcefff on isa0 >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=0x300> >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >> est0: on cpu0 >> p4tcc0: on cpu0 >> est1: on cpu1 >> p4tcc1: on cpu1 >> fuse-freebsd: version 0.4.4, FUSE ABI 7.8 >> Timecounters tick every 1.000 msec >> ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to accept, >> logging disabled >> DUMMYNET 0 with IPv6 initialized (100409) >> load_dn_sched dn_sched RR loaded >> load_dn_sched dn_sched WF2Q+ loaded >> load_dn_sched dn_sched FIFO loaded >> load_dn_sched dn_sched PRIO loaded >> load_dn_sched dn_sched QFQ loaded >> hdacc0: at cad 0 on hdac0 >> hdaa0: at nid 1 on hdacc0 >> pcm0: at nid 20,21 and 24,25 on hdaa0 >> hdacc1: at cad 3 on hdac0 >> hdaa1: at nid 1 on hdacc1 >> pcm1: at nid 5 on hdaa1 >> random: unblocking device. >> usbus0: 5.0Gbps Super Speed USB v3.0 >> usbus1: 480Mbps High Speed USB v2.0 >> usbus2: 480Mbps High Speed USB v2.0 >> ACPI Error: No handler for Region [ECRM] (0xfffff800017dd180) >> [EmbeddedControl] (20130823/evregion-178) >> ACPI Error: Region EmbeddedControl (ID=3) has no handler >> (20130823/exfldio-320) >> ACPI Error: Method parse/execution failed [\134_TZ_.MDEC] (Node >> 0xfffff80001725b40), AE_NOT_EXIST (20130823/psparse-553) >> ACPI Error: Method parse/execution failed [\134_TZ_.TZS0._SCP] (Node >> 0xfffff80001725a40), AE_NOT_EXIST (20130823/psparse-553) >> ugen2.1: at usbus2 >> uhub0: on usbus2 >> ugen1.1: at usbus1 >> ugen0.1: <0x8086> at usbus0 >> uhub1: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 >> uhub2: on usbus1 >> ses0 at ahciem0 bus 0 scbus2 target 0 lun 0 >> ses0: SEMB S-E-S 2.00 device >> ses0: SEMB SES Device >> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >> ada0: ATA-8 SATA 2.x device >> ada0: Serial Number WD-WXL1EB3KUNR5 >> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada0: Command Queueing enabled >> cd0 at ahcich4 bus 0 scbus1 target 0 lun 0 >> cd0: Removable CD-ROM SCSI-0 device cd0: Serial >> Number KW9E4571958 >> cd0: 150.000MB/s transfers (SATA 1.x, UDMA2, ATAPI 12bytes, PIO 8192bytes) >> cd0: Attempt to query device size failed: NOT READY, Medium not present - >> tray closed >> ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) >> ada0: quirks=0x1<4K> >> ada0: Previously was known as ad0 >> Enter passphrase for ada0d: SMP: AP CPU #1 Launched! >> hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 >> IAP/8/48/0x3ff >> IAF/3/48/0x67 >> Timecounter "TSC" frequency 1895731156 Hz quality 1000 >> uhub1: 8 ports with 8 removable, self powered >> uhub0: 3 ports with 3 removable, self powered >> uhub2: 3 ports with 3 removable, self powered >> ugen2.2: at usbus2 >> uhub3: on >> usbus2 >> ugen1.2: at usbus1 >> uhub4: on >> usbus1 >> uhub3: 4 ports with 4 removable, self powered >> uhub4: 4 ports with 4 removable, self powered >> ugen1.3: at usbus1 >> ugen1.4: at usbus1 >> umass0: >> on usbus1 >> da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 >> da0: Removable Direct Access SCSI-0 device da0: >> Serial Number 058F63666435 >> da0: 40.000MB/s transfers >> da0: Attempt to query device size failed: NOT READY, Medium not present >> da0: quirks=0x2 >> ugen1.5: at usbus1 >> GEOM_ELI: Device ada0d.eli created. >> GEOM_ELI: Encryption: AES-CBC 128 >> GEOM_ELI: Crypto: software >> Trying to mount root from ufs:ada0d.eli []... >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 18 21:03:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34B66960; Sat, 18 Oct 2014 21:03:47 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AACD3B85; Sat, 18 Oct 2014 21:03:46 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id s9IL3gYW051800; Sat, 18 Oct 2014 23:03:42 +0200 (CEST) (envelope-from wojtek@puchar.net) Date: Sat, 18 Oct 2014 23:03:38 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop To: Adrian Chadd Subject: Re: help with backlight control and memory 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 (puchar.net [10.0.1.1]); Sat, 18 Oct 2014 23:03:42 +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: Sat, 18 Oct 2014 21:03:47 -0000 tried. jsut after kernel is loaded backlight control keys stops working. tried loading every acpi_* kernel module that is available, with no results On Thu, 16 Oct 2014, Adrian Chadd wrote: > Hi! > > Please try the latest FreeBSD-11 snapshot and see if it still works > once you've started Xorg. > > > -a > > > On 16 October 2014 05:19, Wojciech Puchar wrote: >> bought new laptop. it's lenovo B590 >> >> most things works fine. but brightness control keys doesn't work after >> FreeBSD is loaded. they work before it. >> >> i don't ask for a solution but any point to start. What should i check? >> >> is it ACPI tables problem (kernel shows some errors). >> >> Other question - can amount of memory dedicated to GFX card be changed? >> There is no option in BIOS setup to do this. and i have lots of memory >> wasted as you may see below. >> >> >> >> Copyright (c) 1992-2014 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 10.1-BETA1 #4: Wed Oct 15 23:56:56 CEST 2014 >> root@laptop:/usr/src/sys/amd64/compile/laptop amd64 >> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 >> CPU: Intel(R) Celeron(R) CPU 1005M @ 1.90GHz (1895.73-MHz K8-class CPU) >> Origin = "GenuineIntel" Id = 0x306a9 Family = 0x6 Model = 0x3a >> Stepping = 9 >> >> Features=0xbfebfbff >> >> Features2=0xdbae3bf >> AMD Features=0x28100800 >> AMD Features2=0x1 >> Structured Extended Features=0x281 >> VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID >> TSC: P-state invariant, performance statistics >> real memory = 2147483648 (2048 MB) >> avail memory = 1585037312 (1511 MB) >> Event timer "LAPIC" quality 600 >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> FreeBSD/SMP: 1 package(s) x 2 core(s) >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 2 >> ioapic0 irqs 0-23 on motherboard >> random: initialized >> iscsi: version 2.3.1 >> kbd1 at kbdmux0 >> cryptosoft0: on motherboard >> acpi0: on motherboard >> ACPI Error: No handler for Region [ECOR] (0xfffff80001710400) >> [EmbeddedControl] (20130823/evregion-178) >> ACPI Error: Region EmbeddedControl (ID=3) has no handler >> (20130823/exfldio-320) >> ACPI Error: Method parse/execution failed [\134_SB_.PCI0.LPCB.H_EC._REG] >> (Node 0xfffff8000171e200), AE_NOT_EXIST (20130823/psparse-553) >> acpi0: Power Button (fixed) >> cpu0: on acpi0 >> cpu1: on acpi0 >> hpet0: iomem 0xfed00000-0xfed003ff on acpi0 >> Timecounter "HPET" frequency 14318180 Hz quality 950 >> Event timer "HPET" frequency 14318180 Hz quality 550 >> Event timer "HPET1" frequency 14318180 Hz quality 440 >> Event timer "HPET2" frequency 14318180 Hz quality 440 >> Event timer "HPET3" frequency 14318180 Hz quality 440 >> Event timer "HPET4" frequency 14318180 Hz quality 440 >> Event timer "HPET5" frequency 14318180 Hz quality 440 >> Event timer "HPET6" frequency 14318180 Hz quality 440 >> atrtc0: port 0x70-0x77 irq 8 on acpi0 >> atrtc0: Warning: Couldn't map I/O. >> Event timer "RTC" frequency 32768 Hz quality 0 >> attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> Event timer "i8254" frequency 1193182 Hz quality 100 >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >> acpi_ec0: port 0x62,0x66 on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> vgapci0: port 0x3000-0x303f mem >> 0x90000000-0x903fffff,0x80000000-0x8fffffff irq 16 at device 2.0 on pci0 >> agp0: on vgapci0 >> agp0: aperture size is 256M, detected 32764k stolen memory >> vgapci0: Boot video device >> xhci0: mem 0x90600000-0x9060ffff >> irq 21 at device 20.0 on pci0 >> xhci0: 32 byte context size. >> xhci0: Port routing mask set to 0xffffffff >> usbus0 on xhci0 >> pci0: at device 22.0 (no driver attached) >> ehci0: mem 0x9061a000-0x9061a3ff >> irq 16 at device 26.0 on pci0 >> usbus1: EHCI version 1.0 >> usbus1 on ehci0 >> hdac0: mem 0x90610000-0x90613fff irq 22 >> at device 27.0 on pci0 >> pcib1: irq 16 at device 28.0 on pci0 >> pci1: on pcib1 >> pcib2: irq 17 at device 28.1 on pci0 >> pci2: on pcib2 >> pci2: at device 0.0 (no driver attached) >> pcib3: irq 19 at device 28.3 on pci0 >> pci3: on pcib3 >> re0: port >> 0x2000-0x20ff mem 0x90404000-0x90404fff,0x90400000-0x90403fff irq 19 at >> device 0.0 on pci3 >> re0: Using 1 MSI-X message >> re0: ASPM disabled >> re0: Chip rev. 0x2c800000 >> re0: MAC rev. 0x00100000 >> miibus0: on re0 >> ukphy0: PHY 1 on miibus0 >> ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow >> re0: Ethernet address: 54:ee:75:13:f2:6b >> ehci1: mem 0x90619000-0x906193ff >> irq 23 at device 29.0 on pci0 >> usbus2: EHCI version 1.0 >> usbus2 on ehci1 >> isab0: at device 31.0 on pci0 >> isa0: on isab0 >> ahci0: port >> 0x3088-0x308f,0x3094-0x3097,0x3080-0x3087,0x3090-0x3093,0x3060-0x307f mem >> 0x90618000-0x906187ff irq 19 at device 31.2 on pci0 >> ahci0: AHCI v1.30 with 4 6Gbps ports, Port Multiplier not supported >> ahcich0: at channel 0 on ahci0 >> ahcich4: at channel 4 on ahci0 >> ahciem0: on ahci0 >> acpi_acad0: on acpi0 >> acpi_lid0: on acpi0 >> acpi_button0: on acpi0 >> acpi_tz0: on acpi0 >> acpi_tz1: on acpi0 >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> psm0: irq 12 on atkbdc0 >> psm0: [GIANT-LOCKED] >> psm0: model Generic PS/2 mouse, device ID 0 >> battery0: on acpi0 >> acpi_ibm0: on acpi0 >> orm0: at iomem 0xc0000-0xcefff on isa0 >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=0x300> >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >> est0: on cpu0 >> p4tcc0: on cpu0 >> est1: on cpu1 >> p4tcc1: on cpu1 >> fuse-freebsd: version 0.4.4, FUSE ABI 7.8 >> Timecounters tick every 1.000 msec >> ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to accept, >> logging disabled >> DUMMYNET 0 with IPv6 initialized (100409) >> load_dn_sched dn_sched RR loaded >> load_dn_sched dn_sched WF2Q+ loaded >> load_dn_sched dn_sched FIFO loaded >> load_dn_sched dn_sched PRIO loaded >> load_dn_sched dn_sched QFQ loaded >> hdacc0: at cad 0 on hdac0 >> hdaa0: at nid 1 on hdacc0 >> pcm0: at nid 20,21 and 24,25 on hdaa0 >> hdacc1: at cad 3 on hdac0 >> hdaa1: at nid 1 on hdacc1 >> pcm1: at nid 5 on hdaa1 >> random: unblocking device. >> usbus0: 5.0Gbps Super Speed USB v3.0 >> usbus1: 480Mbps High Speed USB v2.0 >> usbus2: 480Mbps High Speed USB v2.0 >> ACPI Error: No handler for Region [ECRM] (0xfffff800017dd180) >> [EmbeddedControl] (20130823/evregion-178) >> ACPI Error: Region EmbeddedControl (ID=3) has no handler >> (20130823/exfldio-320) >> ACPI Error: Method parse/execution failed [\134_TZ_.MDEC] (Node >> 0xfffff80001725b40), AE_NOT_EXIST (20130823/psparse-553) >> ACPI Error: Method parse/execution failed [\134_TZ_.TZS0._SCP] (Node >> 0xfffff80001725a40), AE_NOT_EXIST (20130823/psparse-553) >> ugen2.1: at usbus2 >> uhub0: on usbus2 >> ugen1.1: at usbus1 >> ugen0.1: <0x8086> at usbus0 >> uhub1: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 >> uhub2: on usbus1 >> ses0 at ahciem0 bus 0 scbus2 target 0 lun 0 >> ses0: SEMB S-E-S 2.00 device >> ses0: SEMB SES Device >> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >> ada0: ATA-8 SATA 2.x device >> ada0: Serial Number WD-WXL1EB3KUNR5 >> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada0: Command Queueing enabled >> cd0 at ahcich4 bus 0 scbus1 target 0 lun 0 >> cd0: Removable CD-ROM SCSI-0 device cd0: Serial >> Number KW9E4571958 >> cd0: 150.000MB/s transfers (SATA 1.x, UDMA2, ATAPI 12bytes, PIO 8192bytes) >> cd0: Attempt to query device size failed: NOT READY, Medium not present - >> tray closed >> ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) >> ada0: quirks=0x1<4K> >> ada0: Previously was known as ad0 >> Enter passphrase for ada0d: SMP: AP CPU #1 Launched! >> hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 >> IAP/8/48/0x3ff >> IAF/3/48/0x67 >> Timecounter "TSC" frequency 1895731156 Hz quality 1000 >> uhub1: 8 ports with 8 removable, self powered >> uhub0: 3 ports with 3 removable, self powered >> uhub2: 3 ports with 3 removable, self powered >> ugen2.2: at usbus2 >> uhub3: on >> usbus2 >> ugen1.2: at usbus1 >> uhub4: on >> usbus1 >> uhub3: 4 ports with 4 removable, self powered >> uhub4: 4 ports with 4 removable, self powered >> ugen1.3: at usbus1 >> ugen1.4: at usbus1 >> umass0: >> on usbus1 >> da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 >> da0: Removable Direct Access SCSI-0 device da0: >> Serial Number 058F63666435 >> da0: 40.000MB/s transfers >> da0: Attempt to query device size failed: NOT READY, Medium not present >> da0: quirks=0x2 >> ugen1.5: at usbus1 >> GEOM_ELI: Device ada0d.eli created. >> GEOM_ELI: Encryption: AES-CBC 128 >> GEOM_ELI: Crypto: software >> Trying to mount root from ufs:ada0d.eli []... >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 18 22:39: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1359DE8; Sat, 18 Oct 2014 22:39:32 +0000 (UTC) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B83A346; Sat, 18 Oct 2014 22:39:32 +0000 (UTC) Received: by mail-vc0-f172.google.com with SMTP id lf12so2073219vcb.17 for ; Sat, 18 Oct 2014 15:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5AJp0ul56iF1HjyFfzlyy8pyo+3XAD5xkOEoV04vkhE=; b=wA2xA82DFnFGFXwU1br8k7UjHWTseOWDYXXWexO6/f9LAw2CTPgAgnHHaynCfr6ADL KTcxD/g0F0B7pgrn2ypaUwOVnWJRYRWZAM+GgzfwKqDka8Ba5RN/t5+Vi3Ak1fsm/NIq TofzQQ2qSbjczcNe65HSnup62IE3bby0HIuo4RB6qVoPWJo3BTUIeGUHyyxX3nbrK+lF SMh11KvYJnC9771rRHGL9CMzWCMmcfaR36sdV2aPpvo1yO0ObxxCbrJItPKxx95vnTnS xTUq8mxIiSaaNYzPhNSJUBS5ZxO2b2k7QRLbT2gsa6AcvKf56aGfiKAFwaJD487AtcA9 MeHw== X-Received: by 10.220.77.196 with SMTP id h4mr14716796vck.14.1413671971500; Sat, 18 Oct 2014 15:39:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.136.1 with HTTP; Sat, 18 Oct 2014 15:38:51 -0700 (PDT) In-Reply-To: References: From: Henry Hu Date: Sat, 18 Oct 2014 18:38:51 -0400 Message-ID: Subject: Re: help with backlight control and memory To: Wojciech Puchar Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd 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, 18 Oct 2014 22:39:32 -0000 On Sat, Oct 18, 2014 at 5:03 PM, Wojciech Puchar wrote: > tried. jsut after kernel is loaded backlight control keys stops working. > tried loading every acpi_* kernel module that is available, with no results > > Does it work if you set hw.acpi.video.lcd0.brightness directly? > > On Thu, 16 Oct 2014, Adrian Chadd wrote: > > Hi! >> >> Please try the latest FreeBSD-11 snapshot and see if it still works >> once you've started Xorg. >> >> >> -a >> >> >> On 16 October 2014 05:19, Wojciech Puchar wrote: >> >>> bought new laptop. it's lenovo B590 >>> >>> most things works fine. but brightness control keys doesn't work after >>> FreeBSD is loaded. they work before it. >>> >>> i don't ask for a solution but any point to start. What should i check? >>> >>> is it ACPI tables problem (kernel shows some errors). >>> >>> Other question - can amount of memory dedicated to GFX card be changed? >>> There is no option in BIOS setup to do this. and i have lots of memory >>> wasted as you may see below. >>> >>> >>> >>> Copyright (c) 1992-2014 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >>> The Regents of the University of California. All rights reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 10.1-BETA1 #4: Wed Oct 15 23:56:56 CEST 2014 >>> root@laptop:/usr/src/sys/amd64/compile/laptop amd64 >>> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 >>> CPU: Intel(R) Celeron(R) CPU 1005M @ 1.90GHz (1895.73-MHz K8-class CPU) >>> Origin = "GenuineIntel" Id = 0x306a9 Family = 0x6 Model = 0x3a >>> Stepping = 9 >>> >>> Features=0xbfebfbff>> APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI, >>> MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> >>> >>> Features2=0xdbae3bf>> VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2, >>> x2APIC,POPCNT,TSCDLT,XSAVE,OSXSAVE> >>> AMD Features=0x28100800 >>> AMD Features2=0x1 >>> Structured Extended Features=0x281 >>> VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID >>> TSC: P-state invariant, performance statistics >>> real memory = 2147483648 (2048 MB) >>> avail memory = 1585037312 (1511 MB) >>> Event timer "LAPIC" quality 600 >>> ACPI APIC Table: >>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>> FreeBSD/SMP: 1 package(s) x 2 core(s) >>> cpu0 (BSP): APIC ID: 0 >>> cpu1 (AP): APIC ID: 2 >>> ioapic0 irqs 0-23 on motherboard >>> random: initialized >>> iscsi: version 2.3.1 >>> kbd1 at kbdmux0 >>> cryptosoft0: on motherboard >>> acpi0: on motherboard >>> ACPI Error: No handler for Region [ECOR] (0xfffff80001710400) >>> [EmbeddedControl] (20130823/evregion-178) >>> ACPI Error: Region EmbeddedControl (ID=3) has no handler >>> (20130823/exfldio-320) >>> ACPI Error: Method parse/execution failed [\134_SB_.PCI0.LPCB.H_EC._REG] >>> (Node 0xfffff8000171e200), AE_NOT_EXIST (20130823/psparse-553) >>> acpi0: Power Button (fixed) >>> cpu0: on acpi0 >>> cpu1: on acpi0 >>> hpet0: iomem 0xfed00000-0xfed003ff on acpi0 >>> Timecounter "HPET" frequency 14318180 Hz quality 950 >>> Event timer "HPET" frequency 14318180 Hz quality 550 >>> Event timer "HPET1" frequency 14318180 Hz quality 440 >>> Event timer "HPET2" frequency 14318180 Hz quality 440 >>> Event timer "HPET3" frequency 14318180 Hz quality 440 >>> Event timer "HPET4" frequency 14318180 Hz quality 440 >>> Event timer "HPET5" frequency 14318180 Hz quality 440 >>> Event timer "HPET6" frequency 14318180 Hz quality 440 >>> atrtc0: port 0x70-0x77 irq 8 on acpi0 >>> atrtc0: Warning: Couldn't map I/O. >>> Event timer "RTC" frequency 32768 Hz quality 0 >>> attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 >>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>> Event timer "i8254" frequency 1193182 Hz quality 100 >>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 >>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >>> acpi_ec0: port 0x62,0x66 on acpi0 >>> pcib0: port 0xcf8-0xcff on acpi0 >>> pci0: on pcib0 >>> vgapci0: port 0x3000-0x303f mem >>> 0x90000000-0x903fffff,0x80000000-0x8fffffff irq 16 at device 2.0 on pci0 >>> agp0: on vgapci0 >>> agp0: aperture size is 256M, detected 32764k stolen memory >>> vgapci0: Boot video device >>> xhci0: mem 0x90600000-0x9060ffff >>> irq 21 at device 20.0 on pci0 >>> xhci0: 32 byte context size. >>> xhci0: Port routing mask set to 0xffffffff >>> usbus0 on xhci0 >>> pci0: at device 22.0 (no driver attached) >>> ehci0: mem 0x9061a000-0x9061a3ff >>> irq 16 at device 26.0 on pci0 >>> usbus1: EHCI version 1.0 >>> usbus1 on ehci0 >>> hdac0: mem 0x90610000-0x90613fff >>> irq 22 >>> at device 27.0 on pci0 >>> pcib1: irq 16 at device 28.0 on pci0 >>> pci1: on pcib1 >>> pcib2: irq 17 at device 28.1 on pci0 >>> pci2: on pcib2 >>> pci2: at device 0.0 (no driver attached) >>> pcib3: irq 19 at device 28.3 on pci0 >>> pci3: on pcib3 >>> re0: port >>> 0x2000-0x20ff mem 0x90404000-0x90404fff,0x90400000-0x90403fff irq 19 at >>> device 0.0 on pci3 >>> re0: Using 1 MSI-X message >>> re0: ASPM disabled >>> re0: Chip rev. 0x2c800000 >>> re0: MAC rev. 0x00100000 >>> miibus0: on re0 >>> ukphy0: PHY 1 on miibus0 >>> ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >>> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow >>> re0: Ethernet address: 54:ee:75:13:f2:6b >>> ehci1: mem 0x90619000-0x906193ff >>> irq 23 at device 29.0 on pci0 >>> usbus2: EHCI version 1.0 >>> usbus2 on ehci1 >>> isab0: at device 31.0 on pci0 >>> isa0: on isab0 >>> ahci0: port >>> 0x3088-0x308f,0x3094-0x3097,0x3080-0x3087,0x3090-0x3093,0x3060-0x307f >>> mem >>> 0x90618000-0x906187ff irq 19 at device 31.2 on pci0 >>> ahci0: AHCI v1.30 with 4 6Gbps ports, Port Multiplier not supported >>> ahcich0: at channel 0 on ahci0 >>> ahcich4: at channel 4 on ahci0 >>> ahciem0: on ahci0 >>> acpi_acad0: on acpi0 >>> acpi_lid0: on acpi0 >>> acpi_button0: on acpi0 >>> acpi_tz0: on acpi0 >>> acpi_tz1: on acpi0 >>> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >>> atkbd0: irq 1 on atkbdc0 >>> kbd0 at atkbd0 >>> atkbd0: [GIANT-LOCKED] >>> psm0: irq 12 on atkbdc0 >>> psm0: [GIANT-LOCKED] >>> psm0: model Generic PS/2 mouse, device ID 0 >>> battery0: on acpi0 >>> acpi_ibm0: on acpi0 >>> orm0: at iomem 0xc0000-0xcefff on isa0 >>> sc0: at flags 0x100 on isa0 >>> sc0: VGA <16 virtual consoles, flags=0x300> >>> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >>> est0: on cpu0 >>> p4tcc0: on cpu0 >>> est1: on cpu1 >>> p4tcc1: on cpu1 >>> fuse-freebsd: version 0.4.4, FUSE ABI 7.8 >>> Timecounters tick every 1.000 msec >>> ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to >>> accept, >>> logging disabled >>> DUMMYNET 0 with IPv6 initialized (100409) >>> load_dn_sched dn_sched RR loaded >>> load_dn_sched dn_sched WF2Q+ loaded >>> load_dn_sched dn_sched FIFO loaded >>> load_dn_sched dn_sched PRIO loaded >>> load_dn_sched dn_sched QFQ loaded >>> hdacc0: at cad 0 on hdac0 >>> hdaa0: at nid 1 on hdacc0 >>> pcm0: at nid 20,21 and 24,25 on >>> hdaa0 >>> hdacc1: at cad 3 on hdac0 >>> hdaa1: at nid 1 on hdacc1 >>> pcm1: at nid 5 on hdaa1 >>> random: unblocking device. >>> usbus0: 5.0Gbps Super Speed USB v3.0 >>> usbus1: 480Mbps High Speed USB v2.0 >>> usbus2: 480Mbps High Speed USB v2.0 >>> ACPI Error: No handler for Region [ECRM] (0xfffff800017dd180) >>> [EmbeddedControl] (20130823/evregion-178) >>> ACPI Error: Region EmbeddedControl (ID=3) has no handler >>> (20130823/exfldio-320) >>> ACPI Error: Method parse/execution failed [\134_TZ_.MDEC] (Node >>> 0xfffff80001725b40), AE_NOT_EXIST (20130823/psparse-553) >>> ACPI Error: Method parse/execution failed [\134_TZ_.TZS0._SCP] (Node >>> 0xfffff80001725a40), AE_NOT_EXIST (20130823/psparse-553) >>> ugen2.1: at usbus2 >>> uhub0: on usbus2 >>> ugen1.1: at usbus1 >>> ugen0.1: <0x8086> at usbus0 >>> uhub1: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 >>> uhub2: on usbus1 >>> ses0 at ahciem0 bus 0 scbus2 target 0 lun 0 >>> ses0: SEMB S-E-S 2.00 device >>> ses0: SEMB SES Device >>> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >>> ada0: ATA-8 SATA 2.x device >>> ada0: Serial Number WD-WXL1EB3KUNR5 >>> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >>> ada0: Command Queueing enabled >>> cd0 at ahcich4 bus 0 scbus1 target 0 lun 0 >>> cd0: Removable CD-ROM SCSI-0 device cd0: >>> Serial >>> Number KW9E4571958 >>> cd0: 150.000MB/s transfers (SATA 1.x, UDMA2, ATAPI 12bytes, PIO >>> 8192bytes) >>> cd0: Attempt to query device size failed: NOT READY, Medium not present - >>> tray closed >>> ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) >>> ada0: quirks=0x1<4K> >>> ada0: Previously was known as ad0 >>> Enter passphrase for ada0d: SMP: AP CPU #1 Launched! >>> hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 >>> IAP/8/48/0x3ff >>> IAF/3/48/0x67 >>> Timecounter "TSC" frequency 1895731156 Hz quality 1000 >>> uhub1: 8 ports with 8 removable, self powered >>> uhub0: 3 ports with 3 removable, self powered >>> uhub2: 3 ports with 3 removable, self powered >>> ugen2.2: at usbus2 >>> uhub3: >>> on >>> usbus2 >>> ugen1.2: at usbus1 >>> uhub4: >>> on >>> usbus1 >>> uhub3: 4 ports with 4 removable, self powered >>> uhub4: 4 ports with 4 removable, self powered >>> ugen1.3: at usbus1 >>> ugen1.4: at usbus1 >>> umass0: >> 4> >>> on usbus1 >>> da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 >>> da0: Removable Direct Access SCSI-0 device >>> da0: >>> Serial Number 058F63666435 >>> da0: 40.000MB/s transfers >>> da0: Attempt to query device size failed: NOT READY, Medium not present >>> da0: quirks=0x2 >>> ugen1.5: at usbus1 >>> GEOM_ELI: Device ada0d.eli created. >>> GEOM_ELI: Encryption: AES-CBC 128 >>> GEOM_ELI: Crypto: software >>> Trying to mount root from ufs:ada0d.eli []... >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@ >>> freebsd.org" >>> >> >> >> _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Cheers, Henry