From owner-freebsd-current@FreeBSD.ORG Sat Feb 23 22:41:38 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 38463C27 for ; Sat, 23 Feb 2013 22:41:38 +0000 (UTC) (envelope-from cpet@sdf.org) Received: from sdf.lonestar.org (mx.sdf.org [192.94.73.19]) by mx1.freebsd.org (Postfix) with ESMTP id E6CA18A0 for ; Sat, 23 Feb 2013 22:41:37 +0000 (UTC) Received: from sdf.org (IDENT:U2FsdGVkX1+sB8eoCaPdPpicKZfxJQrYsALy3mejSw0@[192.94.73.31]) by sdf.lonestar.org (8.14.5/8.14.5) with ESMTP id r1NMfCbV028433 for ; Sat, 23 Feb 2013 22:41:12 GMT Received: (from cpet@localhost) by sdf.org (8.14.4/8.12.8/Submit) id r1NMfYde001001 for current@freebsd.org; Sat, 23 Feb 2013 22:41:34 GMT Date: Sat, 23 Feb 2013 22:41:34 +0000 From: cpet@ma.sdf.org To: current@freebsd.org Subject: CURRENT rev 247203 fails to boot Message-ID: <20130223224134.GA459@ma.sdf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-12-10) X-Mailman-Approved-At: Sun, 24 Feb 2013 00:00:49 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 22:41:38 -0000 CURRENT rev fails to boot even after updating world after bintuils patch. the rev that does work is 246703 which is whats booted up now. 3ware card is a 9650 8 port with latest fw but i dont think this is a fw/card issue as the said rev works fine. From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 02:37:08 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5EF07779; Sun, 24 Feb 2013 02:37:08 +0000 (UTC) (envelope-from cpet@SDF.ORG) Received: from sdf.org (ma.sdf.org [192.94.73.31]) by mx1.freebsd.org (Postfix) with ESMTP id 1C2B5F19; Sun, 24 Feb 2013 02:37:07 +0000 (UTC) Received: from ma.sdf.org (IDENT:U2FsdGVkX1/IxqIQaYUYzRS8BaaqWTy/9z8N86TQJCQ@ma.sdf.org [192.94.73.31]) by sdf.org (8.14.4/8.14.3) with ESMTP id r1O1fIYZ029741; Sun, 24 Feb 2013 01:41:18 GMT MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 23 Feb 2013 19:41:18 -0600 From: cpet To: Subject: panic =?UTF-8?Q?bus=5Fdma?= Message-ID: <7ebe4b8082cbfa2b61936dc06de65a41@SDF.ORG> X-Sender: cpet@SDF.ORG User-Agent: Roundcube Webmail/0.8.2 Cc: kib@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 02:37:08 -0000 Seems like my issue was imposed by commit 246713 tested using 246712 boots tested using 246713 panics keeping all the current debug stuff made the system keep going but reset the 3ware removing all the debug info made the system instantly panic with latest rev 247203 panic: _bus_dmama_load_ccb Unsupported Func Code 0 rev 246713 Chris From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 06:01:49 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4FE83247 for ; Sun, 24 Feb 2013 06:01:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9FA8B1632 for ; Sun, 24 Feb 2013 06:01:48 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1O61ii3016476; Sun, 24 Feb 2013 08:01:44 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1O61ii3016476 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1O61iuj016475; Sun, 24 Feb 2013 08:01:44 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 24 Feb 2013 08:01:44 +0200 From: Konstantin Belousov To: cpet Subject: Re: panic bus_dma Message-ID: <20130224060144.GG2454@kib.kiev.ua> References: <7ebe4b8082cbfa2b61936dc06de65a41@SDF.ORG> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MrRUTeZlqqNo1jQ9" Content-Disposition: inline In-Reply-To: <7ebe4b8082cbfa2b61936dc06de65a41@SDF.ORG> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 06:01:49 -0000 --MrRUTeZlqqNo1jQ9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 23, 2013 at 07:41:18PM -0600, cpet wrote: > Seems like my issue was imposed by commit 246713 >=20 > tested using 246712 boots > tested using 246713 panics >=20 > keeping all the current debug stuff made the system keep going but=20 > reset the 3ware > removing all the debug info made the system instantly panic with latest= =20 > rev 247203 >=20 >=20 > panic: _bus_dmama_load_ccb Unsupported Func Code 0 rev 246713 >=20 I am very sorry that I did not develop my mentiferous abilities far enough in time of your report arrival, so we unfortunately need to resort to some burdensome methods of properly reporting an issue. Specify the exact driver you use, preferrably demonstrating the fragment of the verbose dmesg related to the controller attachment. Show exact printout on the console at the time of panic. The grep of the kernel sources for 'Unsupported Func Code' finds nothing. This is probably panic("_bus_dmamap_load_ccb: Unsupported func code %d") in the _bus_dmamap_load_ccb(). Show the backtrace from ddb and kgdb for the panic. --MrRUTeZlqqNo1jQ9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRKazIAAoJEJDCuSvBvK1B96MP/1m2KhvmdF2qNKHUrBcAx/WH HsPJVTuX8xyJONhYE5ClaJu+zOctFQpxwuF2g/1eTob2ksbdZWWoOj7VEtKKd2aZ nuwufI3YzWdF0Iz0GFBy2iIuwnkZPt8NRU1dG95FgtDVwU7WsO07tok4JaF0Xc/B wooUTeTAd0jyreHsKod69TWJ7Tvgm+XqBpuf7D4sFDen8pLGhvsxSRvHlfMsKOVI tHY4K0og8G+bHg9kdyYdhkj332jl1xy9YJHpBYtJp50hNgpOZJwkAbrGSekfmp2n U1w8DFFNDWmEqed/cbQPdQg+JRp+3H3DwvQhJQcNK7+6014fhCI2p/a0t3qLF0En jqu5kkIuj4cB48B1QOY/U0URizYZ1ukvBKh4GvOfoQzYzmyN42Qp4wOSnNKxQ1oB FDQFwj0Bof+hScddDrb8e2v4HbeaRrtVikLJycSKZqLLQA/3OiNG76LBFuNPAgpm VBYJBUGiIzQPN0GxI9y3pecDKi5kI/ISlQmNyvErOsv4MUSdlC5lAZWpsErc2+lc wU6ZswCYgImQCRHn/imCBBMe6DnlVDR/JitgsJoIomjDLHKRbpzpaFdujIjBuq78 xpFg9ctxq4B9qkkUwEXtTaZAE9VJcr+7bS1KuPZ61ZUCthBDj14TDfIJYv1Uv9B0 ByYvroBcogoXKwCrnrvP =G7nC -----END PGP SIGNATURE----- --MrRUTeZlqqNo1jQ9-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 15:05:41 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 50DF59F7; Sun, 24 Feb 2013 15:05:41 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 11BF1615; Sun, 24 Feb 2013 15:05:40 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r1OF5YxZ002957; Sun, 24 Feb 2013 07:05:34 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r1OF5YDF002956; Sun, 24 Feb 2013 07:05:34 -0800 (PST) (envelope-from david) Date: Sun, 24 Feb 2013 07:05:34 -0800 From: David Wolfskill To: current@freebsd.org Subject: [PATCH] Fix sbin/fsdb/fsdbutil.c for r247212 Message-ID: <20130224150534.GA2785@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U+BazGySraz5kW0T" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kirk McKusick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 15:05:41 -0000 --U+BazGySraz5kW0T Content-Type: multipart/mixed; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Whine was: =2E.. CC=3D'clang' mkdep -f .depend -a -I/usr/src/sbin/fsdb/../fsck_ffs -std= =3Dgnu99 =20 /usr/src/sbin/fsdb/fsdb.c /usr/src/sbin/fsdb/fsdbutil.c /usr/src/sbin/fsdb/= =2E./fs ck_ffs/dir.c /usr/src/sbin/fsdb/../fsck_ffs/ea.c /usr/src/sbin/fsdb/../fsck= _ffs/ fsutil.c /usr/src/sbin/fsdb/../fsck_ffs/inode.c /usr/src/sbin/fsdb/../fsck_= ffs/p ass1.c /usr/src/sbin/fsdb/../fsck_ffs/pass1b.c /usr/src/sbin/fsdb/../fsck_f= fs/pa ss2.c /usr/src/sbin/fsdb/../fsck_ffs/pass3.c /usr/src/sbin/fsdb/../fsck_ffs= /pass 4.c /usr/src/sbin/fsdb/../fsck_ffs/pass5.c /usr/src/sbin/fsdb/../fsck_ffs/s= etup. c /usr/src/sbin/fsdb/../fsck_ffs/utilities.c /usr/src/sbin/fsdb/../../sys/u= fs/ff s/ffs_subr.c /usr/src/sbin/fsdb/../../sys/ufs/ffs/ffs_tables.c /usr/src/sbin/fsdb/fsdbutil.c:242:14: error: too few arguments provided to = funct ion-like macro invocation initbarea(bp); ^ 1 error generated. mkdep: compile failed *** [.depend] Error code 1 1 error *** [depend] Error code 2 1 error *** [sbin.depend__D] Error code 2 Simple patch attached; world is still building, but at least it got through the "make dependencies" phase this time. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --/9DWx/yDrRhgMJTb Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="fsdbutil.c.patch" Content-Transfer-Encoding: quoted-printable Index: sbin/fsdb/fsdbutil.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sbin/fsdb/fsdbutil.c (revision 247218) +++ sbin/fsdb/fsdbutil.c (working copy) @@ -239,7 +239,7 @@ /* for the final indirect level, don't use the cache */ bp =3D &buf; bp->b_un.b_buf =3D bufp; - initbarea(bp); + initbarea(bp, BT_UNKNOWN); =20 getblk(bp, blk, sblock.fs_bsize); } else --/9DWx/yDrRhgMJTb-- --U+BazGySraz5kW0T Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEqLDoACgkQmprOCmdXAD0QigCfXulJyAZL57b0qMbbmmSjoPdK 9YIAn2gTC1iNDUb0nhJMhhY2UnhaC+/c =P0o+ -----END PGP SIGNATURE----- --U+BazGySraz5kW0T-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 15:25:52 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EB529E5A; Sun, 24 Feb 2013 15:25:52 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 9682E6C7; Sun, 24 Feb 2013 15:25:52 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r1OFPqRA003045; Sun, 24 Feb 2013 07:25:52 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r1OFPq5U003044; Sun, 24 Feb 2013 07:25:52 -0800 (PST) (envelope-from david) Date: Sun, 24 Feb 2013 07:25:52 -0800 From: David Wolfskill To: current@freebsd.org Subject: Re: [PATCH] Fix sbin/fsdb/fsdbutil.c for r247212 Message-ID: <20130224152552.GB2785@albert.catwhisker.org> References: <20130224150534.GA2785@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sgneBHv3152wZ8jf" Content-Disposition: inline In-Reply-To: <20130224150534.GA2785@albert.catwhisker.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kirk McKusick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 15:25:53 -0000 --sgneBHv3152wZ8jf Content-Type: multipart/mixed; boundary="Md/poaVZ8hnGTzuv" Content-Disposition: inline --Md/poaVZ8hnGTzuv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 24, 2013 at 07:05:34AM -0800, David Wolfskill wrote: > ...hine was: > Simple patch attached; world is still building, but at least it got > through the "make dependencies" phase this time. > ... That was incomplete, as it didn't (also) address the change to getdatablk(). The attached patch actually made it through buildworld. Note that it is entirely possible that I erred in specifying "BT_UNKNOWN" for the additional "type" argument. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --Md/poaVZ8hnGTzuv Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="fsdbutil.c.patch" Content-Transfer-Encoding: quoted-printable Index: sbin/fsdb/fsdbutil.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sbin/fsdb/fsdbutil.c (revision 247218) +++ sbin/fsdb/fsdbutil.c (working copy) @@ -239,11 +239,11 @@ /* for the final indirect level, don't use the cache */ bp =3D &buf; bp->b_un.b_buf =3D bufp; - initbarea(bp); + initbarea(bp, BT_UNKNOWN); =20 getblk(bp, blk, sblock.fs_bsize); } else - bp =3D getdatablk(blk, sblock.fs_bsize); + bp =3D getdatablk(blk, sblock.fs_bsize, BT_UNKNOWN); =20 cpl =3D charsperline(); for (i =3D charssofar =3D 0; i < NINDIR(&sblock); i++) { --Md/poaVZ8hnGTzuv-- --sgneBHv3152wZ8jf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEqMP8ACgkQmprOCmdXAD3LDACeLZ4syFP5HGQISbqz9RuUm9Vz DpIAnRmYNQU7GxV25ARO/glHJDTmvMyu =HT8v -----END PGP SIGNATURE----- --sgneBHv3152wZ8jf-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 17:25:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 72573DDF for ; Sun, 24 Feb 2013 17:25:42 +0000 (UTC) (envelope-from gkeramidas@gmail.com) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by mx1.freebsd.org (Postfix) with ESMTP id 0F3CEA69 for ; Sun, 24 Feb 2013 17:25:41 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id dq12so1854713wgb.24 for ; Sun, 24 Feb 2013 09:25:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to; bh=8n14xs6QnNJr2ShmwMwJPVlxYzh6F8IHJH194rV6sYQ=; b=q49Pet1ZlvSvVysOD+HM2UyRmzVEZ8Q4sB+fafi7VkIRGaz7x8Q8yZ7i8pUSJfmWeN ljlsYo6OiZP2ZlO3OmbO1MMibHm8f/x76n76vSVhAm9NOWwpql613rDz54NAcyE4u9yY mPmIkmQoU8FU4pxIXPsf3ZtbFDXwnpODgA8C2sxWy8Ct60TsiJwYms/5X6ZF9wSHrhLV NjYEzF9RjMRqF4oLq+v9zZxweqRG+6Eb2vTcQu87Z7Op2XhXiOVbtyB6JDD1NlEtufQ5 dUp7RFyEZYkRA8mgubZjsW5/jfTlxghTyE/vWttjt2VLcd+doyuiUjbkwY4AB3Dt+2md kfKA== X-Received: by 10.180.14.233 with SMTP id s9mr7552806wic.25.1361726740893; Sun, 24 Feb 2013 09:25:40 -0800 (PST) Received: from saturn (217-162-217-29.dynamic.hispeed.ch. [217.162.217.29]) by mx.google.com with ESMTPS id n2sm10096127wiy.6.2013.02.24.09.25.38 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 24 Feb 2013 09:25:39 -0800 (PST) Sender: Giorgos Keramidas Date: Sun, 24 Feb 2013 18:25:34 +0100 From: Giorgos Keramidas To: Mehmet Erol Sanliturk Subject: Re: FreeBSD Testing Facility Message-ID: <20130224172524.GA24919@saturn> References: <51263782.3020205@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <51263782.3020205@freebsd.org> Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 17:25:42 -0000 On 2013-02-21 07:04, Matthew Jacob wrote: > On 2/21/2013 5:04 AM, Mehmet Erol Sanliturk wrote: > >Dear All , > > > >During development of FreeBSD , testing is very vital . > >... > > This in general is a good suggestion. Most companies do such > automated testing as a matter of course. > > Note however that this is a volunteer effort. Were you volunteering > to set up such an automated, possibly testzilla driven, facility? It > would certainly help the quality, although as others have noted > snapshots are often likely to be broken. To the OP: Like Matthew has said, this is a volunteer effort. So if you have experience with setting up testing automation, and you are willing to help us set up something like this, please go ahead :-) I've worked in places where the following types of tests are used: - Presubmit tests that check specific parts of functionality. - Commit-related tests that run asynchronously in the background, and report back later (e.g. through email). - Test systems that cache previous results and report a simple 'green' vs. 'red' status for _every_ single commit. - System tests that check for particular functionality, health criteria, etc. - some times fully automated, some other times requiring a token amount of manual support. So here are two important questions, regarding the tests you mentioned: When you speak about 'testing FreeBSD', which type of tests are you interested in seeing? Are you willing to help us set up something that runs the type of tests that you want to see? From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 17:56:49 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E4DD34A9; Sun, 24 Feb 2013 17:56:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A01A6B4C; Sun, 24 Feb 2013 17:56:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1OHugmW046678; Sun, 24 Feb 2013 12:56:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1OHugiE046665; Sun, 24 Feb 2013 17:56:42 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Feb 2013 17:56:42 GMT Message-Id: <201302241756.r1OHugiE046665@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 17:56:50 -0000 TB --- 2013-02-24 16:20:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-24 16:20:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-24 16:20:19 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-24 16:20:19 - cleaning the object tree TB --- 2013-02-24 16:20:19 - /usr/local/bin/svn stat /src TB --- 2013-02-24 16:20:23 - At svn revision 247223 TB --- 2013-02-24 16:20:24 - building world TB --- 2013-02-24 16:20:24 - CROSS_BUILD_TESTING=YES TB --- 2013-02-24 16:20:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-24 16:20:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-24 16:20:24 - SRCCONF=/dev/null TB --- 2013-02-24 16:20:24 - TARGET=arm TB --- 2013-02-24 16:20:24 - TARGET_ARCH=arm TB --- 2013-02-24 16:20:24 - TZ=UTC TB --- 2013-02-24 16:20:24 - __MAKE_CONF=/dev/null TB --- 2013-02-24 16:20:24 - cd /src TB --- 2013-02-24 16:20:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Feb 24 16:20:29 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] mkdep -f .depend -a -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 /src/sbin/fsck_ffs/dir.c /src/sbin/fsck_ffs/ea.c /src/sbin/fsck_ffs/fsutil.c /src/sbin/fsck_ffs/inode.c /src/sbin/fsck_ffs/main.c /src/sbin/fsck_ffs/pass1.c /src/sbin/fsck_ffs/pass1b.c /src/sbin/fsck_ffs/pass2.c /src/sbin/fsck_ffs/pass3.c /src/sbin/fsck_ffs/pass4.c /src/sbin/fsck_ffs/pass5.c /src/sbin/fsck_ffs/setup.c /src/sbin/fsck_ffs/suj.c /src/sbin/fsck_ffs/utilities.c /src/sbin/fsck_ffs/gjournal.c /src/sbin/fsck_ffs/../mount/getmntopts.c echo fsck_ffs: /obj/arm.arm/src/tmp/usr/lib/libc.a /obj/arm.arm/src/tmp/usr/lib/libufs.a >> .depend cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/dir.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:452: warning: format '%ld' expects type 'long int', but argument 2 has type 'time_t' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/arm.arm/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-24 17:56:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-24 17:56:42 - ERROR: failed to build world TB --- 2013-02-24 17:56:42 - 4685.55 user 828.98 system 5782.79 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 17:56:52 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6783859E; Sun, 24 Feb 2013 17:56:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 40667B4D; Sun, 24 Feb 2013 17:56:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1OHuhdU046708; Sun, 24 Feb 2013 12:56:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1OHugKH046707; Sun, 24 Feb 2013 17:56:42 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Feb 2013 17:56:42 GMT Message-Id: <201302241756.r1OHugKH046707@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 17:56:52 -0000 TB --- 2013-02-24 16:20:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-24 16:20:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-24 16:20:19 - starting HEAD tinderbox run for armv6/arm TB --- 2013-02-24 16:20:19 - cleaning the object tree TB --- 2013-02-24 16:20:19 - /usr/local/bin/svn stat /src TB --- 2013-02-24 16:20:23 - At svn revision 247223 TB --- 2013-02-24 16:20:24 - building world TB --- 2013-02-24 16:20:24 - CROSS_BUILD_TESTING=YES TB --- 2013-02-24 16:20:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-24 16:20:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-24 16:20:24 - SRCCONF=/dev/null TB --- 2013-02-24 16:20:24 - TARGET=arm TB --- 2013-02-24 16:20:24 - TARGET_ARCH=armv6 TB --- 2013-02-24 16:20:24 - TZ=UTC TB --- 2013-02-24 16:20:24 - __MAKE_CONF=/dev/null TB --- 2013-02-24 16:20:24 - cd /src TB --- 2013-02-24 16:20:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Feb 24 16:20:29 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] mkdep -f .depend -a -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 /src/sbin/fsck_ffs/dir.c /src/sbin/fsck_ffs/ea.c /src/sbin/fsck_ffs/fsutil.c /src/sbin/fsck_ffs/inode.c /src/sbin/fsck_ffs/main.c /src/sbin/fsck_ffs/pass1.c /src/sbin/fsck_ffs/pass1b.c /src/sbin/fsck_ffs/pass2.c /src/sbin/fsck_ffs/pass3.c /src/sbin/fsck_ffs/pass4.c /src/sbin/fsck_ffs/pass5.c /src/sbin/fsck_ffs/setup.c /src/sbin/fsck_ffs/suj.c /src/sbin/fsck_ffs/utilities.c /src/sbin/fsck_ffs/gjournal.c /src/sbin/fsck_ffs/../mount/getmntopts.c echo fsck_ffs: /obj/arm.armv6/src/tmp/usr/lib/libc.a /obj/arm.armv6/src/tmp/usr/lib/libufs.a >> .depend cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/dir.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:452: warning: format '%ld' expects type 'long int', but argument 2 has type 'time_t' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/arm.armv6/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-24 17:56:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-24 17:56:42 - ERROR: failed to build world TB --- 2013-02-24 17:56:42 - 4684.16 user 830.77 system 5783.31 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 18:29:17 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6062C16C; Sun, 24 Feb 2013 18:29:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 07A5DD84; Sun, 24 Feb 2013 18:29:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1OITG2L042296; Sun, 24 Feb 2013 13:29:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1OITGIK042289; Sun, 24 Feb 2013 18:29:16 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Feb 2013 18:29:16 GMT Message-Id: <201302241829.r1OITGIK042289@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 18:29:17 -0000 TB --- 2013-02-24 16:20:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-24 16:20:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-24 16:20:19 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-02-24 16:20:19 - cleaning the object tree TB --- 2013-02-24 16:20:19 - /usr/local/bin/svn stat /src TB --- 2013-02-24 16:20:23 - At svn revision 247223 TB --- 2013-02-24 16:20:24 - building world TB --- 2013-02-24 16:20:24 - CROSS_BUILD_TESTING=YES TB --- 2013-02-24 16:20:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-24 16:20:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-24 16:20:24 - SRCCONF=/dev/null TB --- 2013-02-24 16:20:24 - TARGET=amd64 TB --- 2013-02-24 16:20:24 - TARGET_ARCH=amd64 TB --- 2013-02-24 16:20:24 - TZ=UTC TB --- 2013-02-24 16:20:24 - __MAKE_CONF=/dev/null TB --- 2013-02-24 16:20:24 - cd /src TB --- 2013-02-24 16:20:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Feb 24 16:20:29 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies [...] ===> sbin/fsdb (depend) rm -f .depend mkdep -f .depend -a -I/src/sbin/fsdb/../fsck_ffs -std=gnu99 /src/sbin/fsdb/fsdb.c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/../fsck_ffs/dir.c /src/sbin/fsdb/../fsck_ffs/ea.c /src/sbin/fsdb/../fsck_ffs/fsutil.c /src/sbin/fsdb/../fsck_ffs/inode.c /src/sbin/fsdb/../fsck_ffs/pass1.c /src/sbin/fsdb/../fsck_ffs/pass1b.c /src/sbin/fsdb/../fsck_ffs/pass2.c /src/sbin/fsdb/../fsck_ffs/pass3.c /src/sbin/fsdb/../fsck_ffs/pass4.c /src/sbin/fsdb/../fsck_ffs/pass5.c /src/sbin/fsdb/../fsck_ffs/setup.c /src/sbin/fsdb/../fsck_ffs/utilities.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_subr.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_tables.c /src/sbin/fsdb/fsdbutil.c:242:14: error: too few arguments provided to function-like macro invocation initbarea(bp); ^ 1 error generated. mkdep: compile failed *** [.depend] Error code 1 Stop in /src/sbin/fsdb. *** [depend] Error code 1 Stop in /src/sbin. *** [sbin.depend__D] Error code 1 Stop in /src. *** [_depend] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-24 18:29:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-24 18:29:16 - ERROR: failed to build world TB --- 2013-02-24 18:29:16 - 6594.05 user 783.11 system 7736.63 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 18:29:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 474852BB; Sun, 24 Feb 2013 18:29:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EE77AD9C; Sun, 24 Feb 2013 18:29:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1OITTTw043650; Sun, 24 Feb 2013 13:29:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1OITTRk043646; Sun, 24 Feb 2013 18:29:29 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Feb 2013 18:29:29 GMT Message-Id: <201302241829.r1OITTRk043646@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 18:29:35 -0000 TB --- 2013-02-24 16:20:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-24 16:20:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-24 16:20:19 - starting HEAD tinderbox run for i386/i386 TB --- 2013-02-24 16:20:19 - cleaning the object tree TB --- 2013-02-24 16:20:19 - /usr/local/bin/svn stat /src TB --- 2013-02-24 16:20:23 - At svn revision 247223 TB --- 2013-02-24 16:20:24 - building world TB --- 2013-02-24 16:20:24 - CROSS_BUILD_TESTING=YES TB --- 2013-02-24 16:20:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-24 16:20:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-24 16:20:24 - SRCCONF=/dev/null TB --- 2013-02-24 16:20:24 - TARGET=i386 TB --- 2013-02-24 16:20:24 - TARGET_ARCH=i386 TB --- 2013-02-24 16:20:24 - TZ=UTC TB --- 2013-02-24 16:20:24 - __MAKE_CONF=/dev/null TB --- 2013-02-24 16:20:24 - cd /src TB --- 2013-02-24 16:20:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Feb 24 16:20:29 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies [...] ===> sbin/fsdb (depend) rm -f .depend mkdep -f .depend -a -I/src/sbin/fsdb/../fsck_ffs -std=gnu99 /src/sbin/fsdb/fsdb.c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/../fsck_ffs/dir.c /src/sbin/fsdb/../fsck_ffs/ea.c /src/sbin/fsdb/../fsck_ffs/fsutil.c /src/sbin/fsdb/../fsck_ffs/inode.c /src/sbin/fsdb/../fsck_ffs/pass1.c /src/sbin/fsdb/../fsck_ffs/pass1b.c /src/sbin/fsdb/../fsck_ffs/pass2.c /src/sbin/fsdb/../fsck_ffs/pass3.c /src/sbin/fsdb/../fsck_ffs/pass4.c /src/sbin/fsdb/../fsck_ffs/pass5.c /src/sbin/fsdb/../fsck_ffs/setup.c /src/sbin/fsdb/../fsck_ffs/utilities.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_subr.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_tables.c /src/sbin/fsdb/fsdbutil.c:242:14: error: too few arguments provided to function-like macro invocation initbarea(bp); ^ 1 error generated. mkdep: compile failed *** [.depend] Error code 1 Stop in /src/sbin/fsdb. *** [depend] Error code 1 Stop in /src/sbin. *** [sbin.depend__D] Error code 1 Stop in /src. *** [_depend] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-24 18:29:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-24 18:29:29 - ERROR: failed to build world TB --- 2013-02-24 18:29:29 - 6616.56 user 788.73 system 7749.69 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 19:03:19 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AACE76B0; Sun, 24 Feb 2013 19:03:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 68CB5E96; Sun, 24 Feb 2013 19:03:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1OJ3IoF075706; Sun, 24 Feb 2013 14:03:18 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1OJ3IhQ075703; Sun, 24 Feb 2013 19:03:18 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Feb 2013 19:03:18 GMT Message-Id: <201302241903.r1OJ3IhQ075703@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 19:03:19 -0000 TB --- 2013-02-24 17:56:43 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-24 17:56:43 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-24 17:56:43 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-02-24 17:56:43 - cleaning the object tree TB --- 2013-02-24 17:56:43 - /usr/local/bin/svn stat /src TB --- 2013-02-24 17:56:46 - At svn revision 247223 TB --- 2013-02-24 17:56:47 - building world TB --- 2013-02-24 17:56:47 - CROSS_BUILD_TESTING=YES TB --- 2013-02-24 17:56:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-24 17:56:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-24 17:56:47 - SRCCONF=/dev/null TB --- 2013-02-24 17:56:47 - TARGET=ia64 TB --- 2013-02-24 17:56:47 - TARGET_ARCH=ia64 TB --- 2013-02-24 17:56:47 - TZ=UTC TB --- 2013-02-24 17:56:47 - __MAKE_CONF=/dev/null TB --- 2013-02-24 17:56:47 - cd /src TB --- 2013-02-24 17:56:47 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Feb 24 17:56:51 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdb.c cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/fsdbutil.c:242:14: error: macro "initbarea" requires 2 arguments, but only 1 given /src/sbin/fsdb/fsdbutil.c: In function 'printindir': /src/sbin/fsdb/fsdbutil.c:242: error: 'initbarea' undeclared (first use in this function) /src/sbin/fsdb/fsdbutil.c:242: error: (Each undeclared identifier is reported only once /src/sbin/fsdb/fsdbutil.c:242: error: for each function it appears in.) /src/sbin/fsdb/fsdbutil.c:246: error: too few arguments to function 'getdatablk' *** [fsdbutil.o] Error code 1 Stop in /src/sbin/fsdb. *** [fsdb_make] Error code 1 Stop in /obj/ia64.ia64/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-24 19:03:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-24 19:03:18 - ERROR: failed to build world TB --- 2013-02-24 19:03:18 - 3202.59 user 503.70 system 3995.32 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 19:17:27 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3F2A9B0E; Sun, 24 Feb 2013 19:17:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 161FAF13; Sun, 24 Feb 2013 19:17:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1OJHQjw061646; Sun, 24 Feb 2013 14:17:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1OJHQQP061639; Sun, 24 Feb 2013 19:17:26 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Feb 2013 19:17:26 GMT Message-Id: <201302241917.r1OJHQQP061639@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 19:17:27 -0000 TB --- 2013-02-24 18:29:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-24 18:29:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-24 18:29:16 - starting HEAD tinderbox run for mips/mips TB --- 2013-02-24 18:29:16 - cleaning the object tree TB --- 2013-02-24 18:29:16 - /usr/local/bin/svn stat /src TB --- 2013-02-24 18:29:20 - At svn revision 247223 TB --- 2013-02-24 18:29:21 - building world TB --- 2013-02-24 18:29:21 - CROSS_BUILD_TESTING=YES TB --- 2013-02-24 18:29:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-24 18:29:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-24 18:29:21 - SRCCONF=/dev/null TB --- 2013-02-24 18:29:21 - TARGET=mips TB --- 2013-02-24 18:29:21 - TARGET_ARCH=mips TB --- 2013-02-24 18:29:21 - TZ=UTC TB --- 2013-02-24 18:29:21 - __MAKE_CONF=/dev/null TB --- 2013-02-24 18:29:21 - cd /src TB --- 2013-02-24 18:29:21 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Feb 24 18:29:26 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] mkdep -f .depend -a -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 /src/sbin/fsck_ffs/dir.c /src/sbin/fsck_ffs/ea.c /src/sbin/fsck_ffs/fsutil.c /src/sbin/fsck_ffs/inode.c /src/sbin/fsck_ffs/main.c /src/sbin/fsck_ffs/pass1.c /src/sbin/fsck_ffs/pass1b.c /src/sbin/fsck_ffs/pass2.c /src/sbin/fsck_ffs/pass3.c /src/sbin/fsck_ffs/pass4.c /src/sbin/fsck_ffs/pass5.c /src/sbin/fsck_ffs/setup.c /src/sbin/fsck_ffs/suj.c /src/sbin/fsck_ffs/utilities.c /src/sbin/fsck_ffs/gjournal.c /src/sbin/fsck_ffs/../mount/getmntopts.c echo fsck_ffs: /obj/mips.mips/src/tmp/usr/lib/libc.a /obj/mips.mips/src/tmp/usr/lib/libufs.a >> .depend cc -O -pipe -G0 -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/dir.c cc -O -pipe -G0 -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O -pipe -G0 -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:452: warning: format '%ld' expects type 'long int', but argument 2 has type 'time_t' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/mips.mips/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-24 19:17:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-24 19:17:26 - ERROR: failed to build world TB --- 2013-02-24 19:17:26 - 2132.34 user 500.16 system 2889.84 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 19:17:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D62C1C3D; Sun, 24 Feb 2013 19:17:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 94D05F27; Sun, 24 Feb 2013 19:17:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1OJHd4o064364; Sun, 24 Feb 2013 14:17:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1OJHdGC064354; Sun, 24 Feb 2013 19:17:39 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Feb 2013 19:17:39 GMT Message-Id: <201302241917.r1OJHdGC064354@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 19:17:42 -0000 TB --- 2013-02-24 18:29:29 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-24 18:29:29 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-24 18:29:29 - starting HEAD tinderbox run for mips64/mips TB --- 2013-02-24 18:29:29 - cleaning the object tree TB --- 2013-02-24 18:29:29 - /usr/local/bin/svn stat /src TB --- 2013-02-24 18:29:32 - At svn revision 247223 TB --- 2013-02-24 18:29:33 - building world TB --- 2013-02-24 18:29:33 - CROSS_BUILD_TESTING=YES TB --- 2013-02-24 18:29:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-24 18:29:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-24 18:29:33 - SRCCONF=/dev/null TB --- 2013-02-24 18:29:33 - TARGET=mips TB --- 2013-02-24 18:29:33 - TARGET_ARCH=mips64 TB --- 2013-02-24 18:29:33 - TZ=UTC TB --- 2013-02-24 18:29:33 - __MAKE_CONF=/dev/null TB --- 2013-02-24 18:29:33 - cd /src TB --- 2013-02-24 18:29:33 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Feb 24 18:29:38 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -G0 -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdb.c cc -O -pipe -G0 -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/fsdbutil.c:242:14: error: macro "initbarea" requires 2 arguments, but only 1 given /src/sbin/fsdb/fsdbutil.c: In function 'printindir': /src/sbin/fsdb/fsdbutil.c:242: error: 'initbarea' undeclared (first use in this function) /src/sbin/fsdb/fsdbutil.c:242: error: (Each undeclared identifier is reported only once /src/sbin/fsdb/fsdbutil.c:242: error: for each function it appears in.) /src/sbin/fsdb/fsdbutil.c:246: error: too few arguments to function 'getdatablk' *** [fsdbutil.o] Error code 1 Stop in /src/sbin/fsdb. *** [fsdb_make] Error code 1 Stop in /obj/mips.mips64/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-24 19:17:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-24 19:17:39 - ERROR: failed to build world TB --- 2013-02-24 19:17:39 - 2144.02 user 501.80 system 2889.41 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 19:31:59 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 15462187 for ; Sun, 24 Feb 2013 19:31:59 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id D4BEBFA2 for ; Sun, 24 Feb 2013 19:31:58 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r1OJVqfV013376 for ; Sun, 24 Feb 2013 14:31:52 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.10]); Sun, 24 Feb 2013 14:31:52 -0500 (EST) Date: Sun, 24 Feb 2013 14:31:52 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: freebsd-current@FreeBSD.org Subject: USB not working Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 19:31:59 -0000 Hey, I've got a Dell Inspiron 15R Special Edition and haven't had working USB since first installing FreeBSD on it. I'm currently at r247154. When I insert a flash drive (which works fine on my desktop -current system), it is not recognized. I've tried multiple different USB drives (external HDD, flash) that all work on my desktop, but aren't recognized on me Dell notebook. This is what is in dmesg: xhci_do_command: Command timeout! usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) ugen0.2: at usbus0 (disconnected) uhub_reattach_port: could not allocate new device I've got the output of a dmesg, pciconf -lv, and messages during insertion with: hw.usb.dev.debug=1 hw.usb.umass.debug=1 hw.usb.uhub.debug=1 hw.usb.ugen.debug=1 hw.usb.xhci.debug=1 here: http://people.freebsd.org/~deischen/usb/dmesg.txt http://people.freebsd.org/~deischen/usb/pciconf.txt http://people.freebsd.org/~deischen/usb/usb_flash_insertion.tx Any suggestions? -- DE From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 19:41:22 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EEB5B50F; Sun, 24 Feb 2013 19:41:22 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id 551337F; Sun, 24 Feb 2013 19:41:22 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hm14so2652005wib.9 for ; Sun, 24 Feb 2013 11:41:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=M84IDsw1C3g7fjoROU11vs5qyZUZmMgaAt/SfB+6ka8=; b=jVO1oW8/OCRBbdq8c8bYIGWAqXWnqN1SMAY4IZnxuBKHoPOuMlIp9gSA5NEZ+ihyFy B3yWblSnTRnAmTCWVPTTwWpzVbziLFaKfG2IepK9yQkAHCMlwY3M6CKNp4hbmJ7AnFgq gW8/tyVyo3HzceFFtoXQAGMPn8D4AKQPO2UTryjTxJpX3LvZKoPpCu4wsMCJ7khavyJq g37j9F7ZHxSwvInbmt8q2qmGobh8QhTkefJgRW6uUID6inbrxSQM3px1BY6wB4pHkmEC NJ30UTK2C3Mvd0Tl/ZOzg9fkkuodcElVNBIU0t4MppVv6PDQrSmdBNm6Fkq88XLp1mYF zOQg== MIME-Version: 1.0 X-Received: by 10.194.242.69 with SMTP id wo5mr14784115wjc.10.1361734881227; Sun, 24 Feb 2013 11:41:21 -0800 (PST) Sender: pluknet@gmail.com Received: by 10.194.86.167 with HTTP; Sun, 24 Feb 2013 11:41:21 -0800 (PST) In-Reply-To: <20130224152552.GB2785@albert.catwhisker.org> References: <20130224150534.GA2785@albert.catwhisker.org> <20130224152552.GB2785@albert.catwhisker.org> Date: Sun, 24 Feb 2013 22:41:21 +0300 X-Google-Sender-Auth: CMxsDwuo1oOXA5mYZhKDto2uSKo Message-ID: Subject: Re: [PATCH] Fix sbin/fsdb/fsdbutil.c for r247212 From: Sergey Kandaurov To: David Wolfskill Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org, Kirk McKusick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 19:41:23 -0000 On 24 February 2013 19:25, David Wolfskill wrote: > On Sun, Feb 24, 2013 at 07:05:34AM -0800, David Wolfskill wrote: >> ...hine was: >> Simple patch attached; world is still building, but at least it got >> through the "make dependencies" phase this time. >> ... > > That was incomplete, as it didn't (also) address the change to > getdatablk(). > > The attached patch actually made it through buildworld. > > Note that it is entirely possible that I erred in specifying > "BT_UNKNOWN" for the additional "type" argument. Hi David. Thank you for the proposed fix. I committed it with r247234. I'm not sure regarding BT_UNKNOWN value either. Well.. at least it should be not worse that it is now, and it should fix the build. I have not found any (regressive) changes in fsdb -d `blocks' output. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 19:55:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C166B7CB; Sun, 24 Feb 2013 19:55:48 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-da0-f52.google.com (mail-da0-f52.google.com [209.85.210.52]) by mx1.freebsd.org (Postfix) with ESMTP id 6F7BA115; Sun, 24 Feb 2013 19:55:48 +0000 (UTC) Received: by mail-da0-f52.google.com with SMTP id x33so113119dad.39 for ; Sun, 24 Feb 2013 11:55:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=kBbTUmkhxW0iNvLGNGsW6/OC2bPt0MD7ohu7nkVh/KQ=; b=ilZQjhaLMv8K/jDC808PNPzGS4lSDksleFj4S7Au6PZCmsYrd2Cc8OBFG3BL4XycO6 GfUTGbGgbAo7wmJJuPeO3vDzTf/UNQwBbjgCoYX6a6+18qlY8lq8soHG9TtlWU4Askgc mfTRD5V6Wz/w6HPRFYFx0RMwmR1+3D+L2v/LcZOliuMdN0XEvUCqRFdyXExqAKave0vt 8Mw3Hj+R+FK28f6/lwcOg3whdCf0nhlffHjOzQM/RIo0bacitDTW8s0BDdbzvmdcljMC KrAJEf4Ewj0Eag/4tzVTeX3RjVqZgGDzQTuefxBLbX6J5bwoRtwq3moSrbkMIBslodSc 0znw== X-Received: by 10.68.227.9 with SMTP id rw9mr14456370pbc.185.1361735741921; Sun, 24 Feb 2013 11:55:41 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id dk1sm10074608pbc.15.2013.02.24.11.55.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Feb 2013 11:55:41 -0800 (PST) Message-ID: <512A6FFF.2060603@gmail.com> Date: Sun, 24 Feb 2013 11:54:39 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130202 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-acpi Subject: Fixing X220 Video The Right Way Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 19:55:48 -0000 I am working on fixing acpi_video for X220. My X220 is back to FreeBSD land, and I always felt \VBRC calls were dirty. So I've set out to fix acpi_video to work naturally, as it does in linux land. Background: Lenovo laptops boot in a mode where the brightness keys automagically work, under BIOS/EC control. This gets blown away (for us) shortly after Kernel attach. At this point, the acpi method \NBCF will return 0, which means acpi cannot control video brightness. Once we touch the _BCL method on the video output (even inactive ones), \NBCF returns 1 and will allow acpi control. You may remember that acpi_video records some brightness value that changes with keypresses, but does not work on X220. Current status: If I modify acpi video to attach to \_SB.PCI0.PEG.VID, brightness works via sysctl but not keypress (\NBCF = 1) If I leave that alone, but just redirect the brightness set function to \_SB.PCI0.PEG.VID.LCD0._BCM, the keyboard works That is obviously a hack, but it indicates something is going on here. I think that get_acpi_handle() on the X220 vgapci is returning the wrong ACPI_HANDLE. Perhaps this is why the screen stays off when resume used to work? Obviously it can be fixed by hard coding this path into acpi_video, but I feel like that is definitely the wrong way. A tunable for an acpi_video override might be useful, but it still leaves potentially the wrong path in vgapci's IVARs. Is there a better place to "correct" the ACPI_PATH that gets stored in vgapci's ivar? Is there already a tunable I can use to fix this? Thanks! Matt From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 19:58:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C1DDD925 for ; Sun, 24 Feb 2013 19:58:40 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by mx1.freebsd.org (Postfix) with ESMTP id A24B4143 for ; Sun, 24 Feb 2013 19:58:40 +0000 (UTC) Received: by mail-pb0-f46.google.com with SMTP id uo15so1280415pbc.5 for ; Sun, 24 Feb 2013 11:58:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=C2zr/lPOHPBW3a4h2dZZzMkY3InKImz5g67+Qp7Iki8=; b=g9zWJYsMgTS8Nsf9OHd1w+T9aUJOSyU1n7Mckc2e2lp3VLmWHQvwwPmxZsfkjCZ92T H/83CkueCmwZIhOrL5fjONwgFHCYSXCjxVAmpsatmIiiWoZtlfkfLzuKxmHT1hV/Fr2z 0g8UipH3oSzEZHa42R2r3i6rxpc/BfYWGvqh6CwTqb3BXyYE3HoXW1qj6x3dX7zZpzSg RMoxGJ8tGlp2PYOkayqAJ/Ima/Uk0MwARQcrgwrt2Xw3H8iU+iPi3rNAPmlkCLNi7VX3 3yXxTNoyoOVLNfrK00kn+YnnlKajU1JHgWMjBGorsKrzLLThfAVkAxoNSrbDGaBSTnFw 3g7Q== X-Received: by 10.68.240.33 with SMTP id vx1mr14289907pbc.173.1361735914500; Sun, 24 Feb 2013 11:58:34 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id y10sm10076171pbf.39.2013.02.24.11.58.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Feb 2013 11:58:33 -0800 (PST) Message-ID: <512A70AC.6050906@gmail.com> Date: Sun, 24 Feb 2013 11:57:32 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130202 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: CPU0: Local APIC error 0x80 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 19:58:40 -0000 What does this mean exactly? Whenever I call/evaluate certain ACPI paths, this gets printed on console. I assume it's a concurrent access issue or something, or perhaps just a bios/uefi problem? Matt From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 19:58:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 32A9CA22 for ; Sun, 24 Feb 2013 19:58:45 +0000 (UTC) (envelope-from cpet@SDF.ORG) Received: from sdf.org (ma.sdf.org [192.94.73.31]) by mx1.freebsd.org (Postfix) with ESMTP id 1AD5A149 for ; Sun, 24 Feb 2013 19:58:44 +0000 (UTC) Received: from ma.sdf.org (IDENT:U2FsdGVkX19qp/n+9uCjqFOW/AzPr6qriO9lNzSs84M@ma.sdf.org [192.94.73.31]) by sdf.org (8.14.4/8.14.3) with ESMTP id r1OJwkhe007242 for ; Sun, 24 Feb 2013 19:58:46 GMT MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 24 Feb 2013 13:58:46 -0600 From: cpet To: Subject: Re: panic =?UTF-8?Q?bus=5Fdma?= In-Reply-To: <20130224060144.GG2454@kib.kiev.ua> References: <7ebe4b8082cbfa2b61936dc06de65a41@SDF.ORG> <20130224060144.GG2454@kib.kiev.ua> Message-ID: <80b5ac01b7e7c6418c1b305501f6e3ed@SDF.ORG> X-Sender: cpet@SDF.ORG User-Agent: Roundcube Webmail/0.8.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 19:58:45 -0000 On 2013-02-24 00:01, Konstantin Belousov wrote: > On Sat, Feb 23, 2013 at 07:41:18PM -0600, cpet wrote: >> Seems like my issue was imposed by commit 246713 >> >> tested using 246712 boots >> tested using 246713 panics >> >> keeping all the current debug stuff made the system keep going but >> reset the 3ware >> removing all the debug info made the system instantly panic with >> latest >> rev 247203 >> >> >> panic: _bus_dmama_load_ccb Unsupported Func Code 0 rev 246713 >> > > I am very sorry that I did not develop my mentiferous abilities far > enough > in time of your report arrival, so we unfortunately need to resort to > some > burdensome methods of properly reporting an issue. > > Specify the exact driver you use, preferrably demonstrating the > fragment > of the verbose dmesg related to the controller attachment. > > Show exact printout on the console at the time of panic. The grep of > the kernel sources for 'Unsupported Func Code' finds nothing. This is > probably panic("_bus_dmamap_load_ccb: Unsupported func code %d") in > the _bus_dmamap_load_ccb(). > > Show the backtrace from ddb and kgdb for the panic. Hi I will get the bt later tonight as i had to remember how to do it :) From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 20:02:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EFCC1C64; Sun, 24 Feb 2013 20:02:05 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by mx1.freebsd.org (Postfix) with ESMTP id 712AB19C; Sun, 24 Feb 2013 20:02:05 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id m8so1378548vcd.9 for ; Sun, 24 Feb 2013 12:01:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ACLTqlIYaftlY9WSdipGA8fpXefDpIJCDpkqt0pEsbY=; b=N98eH6HwPgE2GtuJ9eUOwR1x4rPQgsSp39sck2EtY6WxLrymFVme5zvwBD1vSI3yv1 VF/yLJcvR97SBsaGbkU6zAulTvjSGLNUkGJKNgeucjf35XRUW6nK5Vtx5opPMy6z7kAP 0rQqdNdXXqVwzo0yljZnXbfjHnAey4ae36qzc/z3tuGLWn73K2sJ+OFZIHdozh3LIUAE +TQdnouviU1uMqr93dGd88/CiDLkCJ0DAduaBzpBsGlDdKSIFJoXbTMNzeHomcIkmwWp X777VPZ8VToU4MgKQx4rJ9pt3aX6MSEmEZpfUCWR7sl6+nP9CQurvj4t5u8NJheh6FMg z7Qg== MIME-Version: 1.0 X-Received: by 10.52.68.116 with SMTP id v20mr7593691vdt.126.1361736118822; Sun, 24 Feb 2013 12:01:58 -0800 (PST) Received: by 10.58.170.36 with HTTP; Sun, 24 Feb 2013 12:01:58 -0800 (PST) In-Reply-To: <20130224172524.GA24919@saturn> References: <51263782.3020205@freebsd.org> <20130224172524.GA24919@saturn> Date: Sun, 24 Feb 2013 12:01:58 -0800 Message-ID: Subject: Re: FreeBSD Testing Facility From: Mehmet Erol Sanliturk To: Giorgos Keramidas Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 20:02:06 -0000 On Sun, Feb 24, 2013 at 9:25 AM, Giorgos Keramidas wrote: > On 2013-02-21 07:04, Matthew Jacob wrote: > > On 2/21/2013 5:04 AM, Mehmet Erol Sanliturk wrote: > > >Dear All , > > > > > >During development of FreeBSD , testing is very vital . > > >... > > > > This in general is a good suggestion. Most companies do such > > automated testing as a matter of course. > > > > Note however that this is a volunteer effort. Were you volunteering > > to set up such an automated, possibly testzilla driven, facility? It > > would certainly help the quality, although as others have noted > > snapshots are often likely to be broken. > > To the OP: > > Like Matthew has said, this is a volunteer effort. So if you have > experience with setting up testing automation, and you are willing to > help us set up something like this, please go ahead :-) > > I've worked in places where the following types of tests are used: > > - Presubmit tests that check specific parts of functionality. > > - Commit-related tests that run asynchronously in the background, > and report back later (e.g. through email). > > - Test systems that cache previous results and report a simple 'green' > vs. 'red' status for _every_ single commit. > > - System tests that check for particular functionality, health > criteria, etc. - some times fully automated, some other times > requiring a token amount of manual support. > > So here are two important questions, regarding the tests you mentioned: > > When you speak about 'testing FreeBSD', which type of tests are you > interested in seeing? > > Are you willing to help us set up something that runs the type of tests > that you want to see? > > To another message I replied as follows : http://lists.freebsd.org/pipermail/freebsd-current/2013-February/039984.html I want say that again to manage such a system is not possible for me very much , additionally for lack of facilities . My wish is that let's take this subject to be worked in detail and by a group effort , design , implement and apply such a testing facility . In this work , if anything I can supply , I will never keep myself back . Without reflective responses , if we consider my first message : http://lists.freebsd.org/pipermail/freebsd-current/2013-February/039976.html a very rough outline is supplied . Reason is such a suggestion is to see many failures of *BSD systems that these can be eliminated if such a system is designed , implemented , and applied . In many messages by FreeBSD developers , it is said that it is not possible to establish a testing farm by the FreeBSD project and maintain it , which is quite correct . Assume the following : If any one is downloading and trying to install and run Current development iso files , itis very likely that the main intention is to test and help to its development . By counting number of such testing attempts , it is possible to estimate the number of people which can participate to a more coordinated testing system . My opinion is that such a system ( a distributed testers population ) is already present , and over time , even it may be enlarged . Actually , problem is large enough to establish a working group to attack it . There is a necessity to have committers to generate the necessary ftp sites and manage them . At present , there is a port system . The testing facility will be similar to that system , but different programs will be employed . The first action will be to design what will be tested and how . Since FreeBSD is composed from components ( boot , kernel , each system programs , etc. , ) , every component will be a testing subject . In the svn , there are already testing parts . By combining these , and supplying , developing missing parts will generate a testing framework . At the beginning , it will not be possible to generate a state of the art testing facility . By starting from the existing parts , over time , it will be possible to ad tests one by one . This will be similar to development of ports system : Over time it has been populated one by one . As a an applicable first step , a FreeBSD developer , may establish a wiki page or use an existing one to develop a "Testing Requirements and Design , Implementation and Applications" page . A mailing list may be established to discuss testing problems . An ftp site may be established to apply tests as suggested in my first message . As an example : Assume that a part related to video display cards is under development , such as KMS . The developer(s) will have a limited number of cards available in their computers . A potential people population exists which they use such cards , for example RADEON , or INTEL cards . In the mailing lists , it may be announced that testers are needed for specific video card branch , such as RADEON . People , fills a form to participate in the tests . The developer prepares a file just like a port/package . Sends a message to the subscribers wishing to test this problem . Possible testers , upon receiving that message , may enter a command , such as # test_apply name_of_testing_package just similar to pkg_add command . The test_apply program , downloads the testing package and applies it . At the end , the best action is to generate a structured e-mail , the results may be sent to the testing data base just a like bug tracker system . I emphasize structured messages for their automatic processing possibility . If this is not very feasible , at least a formal message may be requested to evaluate results easily . Otherwise results like "Tests failed" will not be very helpful for the developers . A script in there processes the returned e-mails and generates a report to developer(s) ,. A cycle of such tests continues up to a satisfactory result . Some parts , such as the following , are dependent very much to hardware to be used : - Booting process - Network communications - Video display units - USB attached components - Parts requiring BIOS cooperation , - Parts detecting , managing main board parts ( circuits , ports , etc. ) - Parts detecting , managing attached peripheral devices . All of these may be subject of such distributed testing actions . After testing many of the components and ensuing that they are working , there comes to testing of their combinations , for example : - File systems in local disks, - NFS like systems Then , a whole test : Testing complete install iso files . Here , there will not be a booting or hardware detection failure , but failures related to cooperative working of systems under user applications . These failures may occur between mismatched components during their interaction . Therefore , such a testing facility requires cooperation of many people to function properly . A group of leaders may organize the efforts . Thank you very much . From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 20:10:25 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C44DADE5; Sun, 24 Feb 2013 20:10:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 79ACF1E6; Sun, 24 Feb 2013 20:10:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1OKAOtL009542; Sun, 24 Feb 2013 15:10:24 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1OKAO1l009541; Sun, 24 Feb 2013 20:10:24 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Feb 2013 20:10:24 GMT Message-Id: <201302242010.r1OKAO1l009541@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 20:10:25 -0000 TB --- 2013-02-24 17:56:42 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-24 17:56:42 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-24 17:56:42 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-02-24 17:56:42 - cleaning the object tree TB --- 2013-02-24 17:56:42 - /usr/local/bin/svn stat /src TB --- 2013-02-24 17:56:46 - At svn revision 247223 TB --- 2013-02-24 17:56:47 - building world TB --- 2013-02-24 17:56:47 - CROSS_BUILD_TESTING=YES TB --- 2013-02-24 17:56:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-24 17:56:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-24 17:56:47 - SRCCONF=/dev/null TB --- 2013-02-24 17:56:47 - TARGET=pc98 TB --- 2013-02-24 17:56:47 - TARGET_ARCH=i386 TB --- 2013-02-24 17:56:47 - TZ=UTC TB --- 2013-02-24 17:56:47 - __MAKE_CONF=/dev/null TB --- 2013-02-24 17:56:47 - cd /src TB --- 2013-02-24 17:56:47 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Feb 24 17:56:51 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies [...] ===> sbin/fsdb (depend) rm -f .depend mkdep -f .depend -a -I/src/sbin/fsdb/../fsck_ffs -std=gnu99 /src/sbin/fsdb/fsdb.c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/../fsck_ffs/dir.c /src/sbin/fsdb/../fsck_ffs/ea.c /src/sbin/fsdb/../fsck_ffs/fsutil.c /src/sbin/fsdb/../fsck_ffs/inode.c /src/sbin/fsdb/../fsck_ffs/pass1.c /src/sbin/fsdb/../fsck_ffs/pass1b.c /src/sbin/fsdb/../fsck_ffs/pass2.c /src/sbin/fsdb/../fsck_ffs/pass3.c /src/sbin/fsdb/../fsck_ffs/pass4.c /src/sbin/fsdb/../fsck_ffs/pass5.c /src/sbin/fsdb/../fsck_ffs/setup.c /src/sbin/fsdb/../fsck_ffs/utilities.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_subr.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_tables.c /src/sbin/fsdb/fsdbutil.c:242:14: error: too few arguments provided to function-like macro invocation initbarea(bp); ^ 1 error generated. mkdep: compile failed *** [.depend] Error code 1 Stop in /src/sbin/fsdb. *** [depend] Error code 1 Stop in /src/sbin. *** [sbin.depend__D] Error code 1 Stop in /src. *** [_depend] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-24 20:10:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-24 20:10:24 - ERROR: failed to build world TB --- 2013-02-24 20:10:24 - 6859.84 user 761.70 system 8021.67 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 20:10:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 34F07DE6; Sun, 24 Feb 2013 20:10:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E72EB1E7; Sun, 24 Feb 2013 20:10:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1OKAYgF009831; Sun, 24 Feb 2013 15:10:34 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1OKAYwq009830; Sun, 24 Feb 2013 20:10:34 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Feb 2013 20:10:34 GMT Message-Id: <201302242010.r1OKAYwq009830@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 20:10:35 -0000 TB --- 2013-02-24 19:17:39 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-24 19:17:39 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-24 19:17:39 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-02-24 19:17:39 - cleaning the object tree TB --- 2013-02-24 19:17:39 - /usr/local/bin/svn stat /src TB --- 2013-02-24 19:17:42 - At svn revision 247223 TB --- 2013-02-24 19:17:43 - building world TB --- 2013-02-24 19:17:43 - CROSS_BUILD_TESTING=YES TB --- 2013-02-24 19:17:43 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-24 19:17:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-24 19:17:43 - SRCCONF=/dev/null TB --- 2013-02-24 19:17:43 - TARGET=sparc64 TB --- 2013-02-24 19:17:43 - TARGET_ARCH=sparc64 TB --- 2013-02-24 19:17:43 - TZ=UTC TB --- 2013-02-24 19:17:43 - __MAKE_CONF=/dev/null TB --- 2013-02-24 19:17:43 - cd /src TB --- 2013-02-24 19:17:43 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Feb 24 19:17:47 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdb.c cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/fsdbutil.c:242:14: error: macro "initbarea" requires 2 arguments, but only 1 given /src/sbin/fsdb/fsdbutil.c: In function 'printindir': /src/sbin/fsdb/fsdbutil.c:242: error: 'initbarea' undeclared (first use in this function) /src/sbin/fsdb/fsdbutil.c:242: error: (Each undeclared identifier is reported only once /src/sbin/fsdb/fsdbutil.c:242: error: for each function it appears in.) /src/sbin/fsdb/fsdbutil.c:246: error: too few arguments to function 'getdatablk' *** [fsdbutil.o] Error code 1 Stop in /src/sbin/fsdb. *** [fsdb_make] Error code 1 Stop in /obj/sparc64.sparc64/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-24 20:10:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-24 20:10:34 - ERROR: failed to build world TB --- 2013-02-24 20:10:34 - 2443.66 user 429.99 system 3175.12 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 20:48:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A6F055DE; Sun, 24 Feb 2013 20:48:22 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by mx1.freebsd.org (Postfix) with ESMTP id 7D470325; Sun, 24 Feb 2013 20:48:22 +0000 (UTC) Received: by mail-pb0-f52.google.com with SMTP id ma3so1298381pbc.39 for ; Sun, 24 Feb 2013 12:48:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7zxuCfH5GE2bAPSG/VtdCNj8Qd0TS84wSBuQZqc2tzE=; b=q4qVCIcpq37k0SJV5OJ3FVpvGwmvJfx0iN1LnNtgaG7NmnTUOaOqpV9thJRPZZzEGt E9KztIJVSIW+peR5zVDoxs0JmT7WNrZSGHcyqznpd18drnMYxHoLBSKcuq0DuWRfFawi xhUghmZiFYPPjtwJMWcPwyT8C+YXmrCKDLNoH0nZTwCKbjIETmoqSOSC4QnJZ69AO7Tt 17AgLsQyHa4qYU+vgGx3qvZNSZje2X5sIBN7TEjk6imbD625bZcRO0TZvr1FORALDkys cDYj7hedhFLeBCYBf40M6ZVa10qyxGUQmfjV1bhMLvFsQrOSvydd034GGqwwWCQnAWmI Q0qg== MIME-Version: 1.0 X-Received: by 10.68.213.7 with SMTP id no7mr14372652pbc.48.1361738896144; Sun, 24 Feb 2013 12:48:16 -0800 (PST) Received: by 10.68.36.69 with HTTP; Sun, 24 Feb 2013 12:48:16 -0800 (PST) In-Reply-To: References: <51263782.3020205@freebsd.org> <20130224172524.GA24919@saturn> Date: Sun, 24 Feb 2013 22:48:16 +0200 Message-ID: Subject: Re: FreeBSD Testing Facility From: Alexander Yerenkow To: Mehmet Erol Sanliturk Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org, Giorgos Keramidas X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 20:48:22 -0000 How about create -testing mail list, and start searching for any kind of volunteers? I could lend a hand in creating auto-testing some aspects of FreeBSD (at leas successful booting/working net/route etc), someone else probably could have to say something too. I think resources are there, they just need to be gathered :) -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 21:05:23 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1C226C36; Sun, 24 Feb 2013 21:05:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id CD0A73A7; Sun, 24 Feb 2013 21:05:22 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1OL5Lq7078843; Sun, 24 Feb 2013 16:05:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1OL5LLl078842; Sun, 24 Feb 2013 21:05:21 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Feb 2013 21:05:21 GMT Message-Id: <201302242105.r1OL5LLl078842@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 21:05:23 -0000 TB --- 2013-02-24 19:03:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-24 19:03:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-24 19:03:18 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-02-24 19:03:18 - cleaning the object tree TB --- 2013-02-24 19:03:18 - /usr/local/bin/svn stat /src TB --- 2013-02-24 19:03:22 - At svn revision 247223 TB --- 2013-02-24 19:03:23 - building world TB --- 2013-02-24 19:03:23 - CROSS_BUILD_TESTING=YES TB --- 2013-02-24 19:03:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-24 19:03:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-24 19:03:23 - SRCCONF=/dev/null TB --- 2013-02-24 19:03:23 - TARGET=powerpc TB --- 2013-02-24 19:03:23 - TARGET_ARCH=powerpc TB --- 2013-02-24 19:03:23 - TZ=UTC TB --- 2013-02-24 19:03:23 - __MAKE_CONF=/dev/null TB --- 2013-02-24 19:03:23 - cd /src TB --- 2013-02-24 19:03:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Feb 24 19:03:28 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdb.c cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/fsdbutil.c:242:14: error: macro "initbarea" requires 2 arguments, but only 1 given /src/sbin/fsdb/fsdbutil.c: In function 'printindir': /src/sbin/fsdb/fsdbutil.c:242: error: 'initbarea' undeclared (first use in this function) /src/sbin/fsdb/fsdbutil.c:242: error: (Each undeclared identifier is reported only once /src/sbin/fsdb/fsdbutil.c:242: error: for each function it appears in.) /src/sbin/fsdb/fsdbutil.c:246: error: too few arguments to function 'getdatablk' *** [fsdbutil.o] Error code 1 Stop in /src/sbin/fsdb. *** [fsdb_make] Error code 1 Stop in /obj/powerpc.powerpc/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-24 21:05:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-24 21:05:21 - ERROR: failed to build world TB --- 2013-02-24 21:05:21 - 6368.54 user 771.83 system 7323.20 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 21:19:34 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EF5EA211; Sun, 24 Feb 2013 21:19:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id ACEF9681; Sun, 24 Feb 2013 21:19:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1OLJXFD091695; Sun, 24 Feb 2013 16:19:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1OLJXp0091694; Sun, 24 Feb 2013 21:19:33 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Feb 2013 21:19:33 GMT Message-Id: <201302242119.r1OLJXp0091694@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 21:19:35 -0000 TB --- 2013-02-24 19:17:26 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-24 19:17:26 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-24 19:17:26 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-02-24 19:17:26 - cleaning the object tree TB --- 2013-02-24 19:17:26 - /usr/local/bin/svn stat /src TB --- 2013-02-24 19:17:30 - At svn revision 247223 TB --- 2013-02-24 19:17:31 - building world TB --- 2013-02-24 19:17:31 - CROSS_BUILD_TESTING=YES TB --- 2013-02-24 19:17:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-24 19:17:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-24 19:17:31 - SRCCONF=/dev/null TB --- 2013-02-24 19:17:31 - TARGET=powerpc TB --- 2013-02-24 19:17:31 - TARGET_ARCH=powerpc64 TB --- 2013-02-24 19:17:31 - TZ=UTC TB --- 2013-02-24 19:17:31 - __MAKE_CONF=/dev/null TB --- 2013-02-24 19:17:31 - cd /src TB --- 2013-02-24 19:17:31 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Feb 24 19:17:35 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdb.c cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/fsdbutil.c:242:14: error: macro "initbarea" requires 2 arguments, but only 1 given /src/sbin/fsdb/fsdbutil.c: In function 'printindir': /src/sbin/fsdb/fsdbutil.c:242: error: 'initbarea' undeclared (first use in this function) /src/sbin/fsdb/fsdbutil.c:242: error: (Each undeclared identifier is reported only once /src/sbin/fsdb/fsdbutil.c:242: error: for each function it appears in.) /src/sbin/fsdb/fsdbutil.c:246: error: too few arguments to function 'getdatablk' *** [fsdbutil.o] Error code 1 Stop in /src/sbin/fsdb. *** [fsdb_make] Error code 1 Stop in /obj/powerpc.powerpc64/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-24 21:19:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-24 21:19:33 - ERROR: failed to build world TB --- 2013-02-24 21:19:33 - 6448.36 user 731.76 system 7326.98 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 22:49:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 70C92AE1; Sun, 24 Feb 2013 22:49:18 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by mx1.freebsd.org (Postfix) with ESMTP id EE718A7F; Sun, 24 Feb 2013 22:49:17 +0000 (UTC) Received: by mail-vb0-f51.google.com with SMTP id fq11so1414422vbb.10 for ; Sun, 24 Feb 2013 14:49:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zxbCDBBY6UQSb+7D4H2+zHR1wgU3+5cSaWbVNByIQnw=; b=elBSMxbZ69y0V2dOaIbuoti0uo5H2gyaMGd3avecyR/kDa+ZzzpWa5RO0vXtxlwJVr JVGvkEcXAONfzcSNUxnw83G0bASeBVPtckdR1pWRZQU/Yg+O/jtEl3mM1AeMrCnzMDmv 7EVSXXlFLJL+s4vOETglKRtL0SHlvxWuNk3Tb+AgF+dNXwOzZfyH1qg7dKExDUIPMSpS nlt5cLk9oI86vE07EIpUIg6a7aQI9M/BrUUTT20i3sxpOSdmMZ8Hv4sIK2ENjlf2dz4e QZ0AYNZ3jrTk7kfuwv71TI9V66JG5MJBGOicFMoxgOWgOmlACtUjCNsHP/1wrkHaUvSe CgVQ== MIME-Version: 1.0 X-Received: by 10.220.242.73 with SMTP id lh9mr6132081vcb.49.1361746150847; Sun, 24 Feb 2013 14:49:10 -0800 (PST) Received: by 10.58.170.36 with HTTP; Sun, 24 Feb 2013 14:49:10 -0800 (PST) In-Reply-To: References: <51263782.3020205@freebsd.org> <20130224172524.GA24919@saturn> Date: Sun, 24 Feb 2013 14:49:10 -0800 Message-ID: Subject: Re: FreeBSD Testing Facility From: Mehmet Erol Sanliturk To: Alexander Yerenkow Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org, Giorgos Keramidas X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 22:49:18 -0000 On Sun, Feb 24, 2013 at 12:48 PM, Alexander Yerenkow wrote: > How about create -testing mail list, and start searching for any kind of > volunteers? > I could lend a hand in creating auto-testing some aspects of FreeBSD (at > leas successful booting/working net/route etc), > someone else probably could have to say something too. > > I think resources are there, they just need to be gathered :) > > -- > Regards, > Alexander Yerenkow Really , there are ample amount of facilities in FreeBSD already . The steps may be the following : - Prepare a testing requirements document : There are existing testing programs in the svn .List them . . The developers may use tests that are not in svn . Collect information about them . . Collect additional testing point suggestions . . Design a testing facility : This may be just an imitation of the packages/ports tree . For each test , prepare a package . The new package management project contains very important information to imitate . Prepare a test_apply program just like pkg_add . Generate an ftp site parts for .../testing/Fatal/... , .../testing/Dangerous/... , .../testing/Harmless/... Generate databases for the collected result mails , with respect to message groups . For each test , generate an ( xml , or JSON , or just name = value pairs ( like .conf files ) ) results e-mail structure . During tests , this file will be created . When such an e-mail is received into a definite address , with program , introduce it into a database . Generate reports from databases to submit to developers . Generate a mailing list about testing facility . Prepare e-mail templates with respect to testing points ( groups , subjects ) . To the subscriber , present a form to fill information which parts he or she can test , and store these into a data base . Associate each test package with fields of the subscribers testing possibilities . When a testing action is required ( generated by a modification in a tested area ) , query the subscribers database , and send an e-mail to possible testers . Before test_apply program is executed , if it is necessary to perform some actions , prepare an algorithm to define such steps and attach to e-mail , or fetch by test_apply . Implementation : The above steps may be implemented mostly by facilities present in the base system and packages in the ports tree . Identify required new programs , write-ups , scripts , etc. , to design , and implement them . Application , Testing : By using a harmless test , apply the above designed system and evaluate outcome , recycle the above steps , Start to populate the testing system with packages one by one . Maintain the testing tree , and when a modification is applied into a part , if necessary , also modify the testing package and request a testing step . Now , there are "Call for Testing" applications in the present mailing lists . With the above structure , such requests will be more widely applied and will produce structured , analyzable results . If one such package is developed , the rest will start to imitate its many steps , development of new testing packages will be easy . Some of the test packages may also be installed during a complete FreeBSD installation and may be used to test the installed system , and the results may be collected to analyze . I always emphasize structured messages because other messages may not be easily analyzed . Over the studies of this system , there may be some modifications in the base system parts or packages to facilitate a more effective testing . These requirements will emerge over time . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 23:01:37 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 72BD3F49; Sun, 24 Feb 2013 23:01:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4469BB69; Sun, 24 Feb 2013 23:01:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1ON1aDk049499; Sun, 24 Feb 2013 18:01:36 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1ON1aDG049495; Sun, 24 Feb 2013 23:01:36 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Feb 2013 23:01:36 GMT Message-Id: <201302242301.r1ON1aDG049495@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 23:01:37 -0000 TB --- 2013-02-24 21:20:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-24 21:20:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-24 21:20:19 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-24 21:20:19 - cleaning the object tree TB --- 2013-02-24 21:24:35 - /usr/local/bin/svn stat /src TB --- 2013-02-24 21:24:38 - At svn revision 247237 TB --- 2013-02-24 21:24:39 - building world TB --- 2013-02-24 21:24:39 - CROSS_BUILD_TESTING=YES TB --- 2013-02-24 21:24:39 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-24 21:24:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-24 21:24:39 - SRCCONF=/dev/null TB --- 2013-02-24 21:24:39 - TARGET=arm TB --- 2013-02-24 21:24:39 - TARGET_ARCH=arm TB --- 2013-02-24 21:24:39 - TZ=UTC TB --- 2013-02-24 21:24:39 - __MAKE_CONF=/dev/null TB --- 2013-02-24 21:24:39 - cd /src TB --- 2013-02-24 21:24:39 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Feb 24 21:24:44 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] mkdep -f .depend -a -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 /src/sbin/fsck_ffs/dir.c /src/sbin/fsck_ffs/ea.c /src/sbin/fsck_ffs/fsutil.c /src/sbin/fsck_ffs/inode.c /src/sbin/fsck_ffs/main.c /src/sbin/fsck_ffs/pass1.c /src/sbin/fsck_ffs/pass1b.c /src/sbin/fsck_ffs/pass2.c /src/sbin/fsck_ffs/pass3.c /src/sbin/fsck_ffs/pass4.c /src/sbin/fsck_ffs/pass5.c /src/sbin/fsck_ffs/setup.c /src/sbin/fsck_ffs/suj.c /src/sbin/fsck_ffs/utilities.c /src/sbin/fsck_ffs/gjournal.c /src/sbin/fsck_ffs/../mount/getmntopts.c echo fsck_ffs: /obj/arm.arm/src/tmp/usr/lib/libc.a /obj/arm.arm/src/tmp/usr/lib/libufs.a >> .depend cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/dir.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:452: warning: format '%ld' expects type 'long int', but argument 2 has type 'time_t' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/arm.arm/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-24 23:01:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-24 23:01:36 - ERROR: failed to build world TB --- 2013-02-24 23:01:36 - 4686.91 user 840.68 system 6076.77 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 23:01:37 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 81160F4A; Sun, 24 Feb 2013 23:01:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 53318B6A; Sun, 24 Feb 2013 23:01:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1ON1aws049500; Sun, 24 Feb 2013 18:01:36 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1ON1aI6049496; Sun, 24 Feb 2013 23:01:36 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 24 Feb 2013 23:01:36 GMT Message-Id: <201302242301.r1ON1aI6049496@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 23:01:37 -0000 TB --- 2013-02-24 21:20:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-24 21:20:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-24 21:20:19 - starting HEAD tinderbox run for armv6/arm TB --- 2013-02-24 21:20:19 - cleaning the object tree TB --- 2013-02-24 21:24:34 - /usr/local/bin/svn stat /src TB --- 2013-02-24 21:24:37 - At svn revision 247237 TB --- 2013-02-24 21:24:38 - building world TB --- 2013-02-24 21:24:38 - CROSS_BUILD_TESTING=YES TB --- 2013-02-24 21:24:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-24 21:24:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-24 21:24:38 - SRCCONF=/dev/null TB --- 2013-02-24 21:24:38 - TARGET=arm TB --- 2013-02-24 21:24:38 - TARGET_ARCH=armv6 TB --- 2013-02-24 21:24:38 - TZ=UTC TB --- 2013-02-24 21:24:38 - __MAKE_CONF=/dev/null TB --- 2013-02-24 21:24:38 - cd /src TB --- 2013-02-24 21:24:38 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Feb 24 21:24:43 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] mkdep -f .depend -a -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 /src/sbin/fsck_ffs/dir.c /src/sbin/fsck_ffs/ea.c /src/sbin/fsck_ffs/fsutil.c /src/sbin/fsck_ffs/inode.c /src/sbin/fsck_ffs/main.c /src/sbin/fsck_ffs/pass1.c /src/sbin/fsck_ffs/pass1b.c /src/sbin/fsck_ffs/pass2.c /src/sbin/fsck_ffs/pass3.c /src/sbin/fsck_ffs/pass4.c /src/sbin/fsck_ffs/pass5.c /src/sbin/fsck_ffs/setup.c /src/sbin/fsck_ffs/suj.c /src/sbin/fsck_ffs/utilities.c /src/sbin/fsck_ffs/gjournal.c /src/sbin/fsck_ffs/../mount/getmntopts.c echo fsck_ffs: /obj/arm.armv6/src/tmp/usr/lib/libc.a /obj/arm.armv6/src/tmp/usr/lib/libufs.a >> .depend cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/dir.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:452: warning: format '%ld' expects type 'long int', but argument 2 has type 'time_t' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/arm.armv6/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-24 23:01:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-24 23:01:36 - ERROR: failed to build world TB --- 2013-02-24 23:01:36 - 4685.37 user 841.18 system 6076.78 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 02:23:01 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1C14E967; Mon, 25 Feb 2013 02:23:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D323068F; Mon, 25 Feb 2013 02:23:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1P2MxxH092420; Sun, 24 Feb 2013 21:22:59 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1P2Mxkk092392; Mon, 25 Feb 2013 02:22:59 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 25 Feb 2013 02:22:59 GMT Message-Id: <201302250222.r1P2Mxkk092392@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 02:23:01 -0000 TB --- 2013-02-25 01:32:42 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-25 01:32:42 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-25 01:32:42 - starting HEAD tinderbox run for mips/mips TB --- 2013-02-25 01:32:42 - cleaning the object tree TB --- 2013-02-25 01:33:39 - /usr/local/bin/svn stat /src TB --- 2013-02-25 01:33:54 - At svn revision 247237 TB --- 2013-02-25 01:33:55 - building world TB --- 2013-02-25 01:33:55 - CROSS_BUILD_TESTING=YES TB --- 2013-02-25 01:33:55 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-25 01:33:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-25 01:33:55 - SRCCONF=/dev/null TB --- 2013-02-25 01:33:55 - TARGET=mips TB --- 2013-02-25 01:33:55 - TARGET_ARCH=mips TB --- 2013-02-25 01:33:55 - TZ=UTC TB --- 2013-02-25 01:33:55 - __MAKE_CONF=/dev/null TB --- 2013-02-25 01:33:55 - cd /src TB --- 2013-02-25 01:33:55 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Feb 25 01:33:59 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] mkdep -f .depend -a -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 /src/sbin/fsck_ffs/dir.c /src/sbin/fsck_ffs/ea.c /src/sbin/fsck_ffs/fsutil.c /src/sbin/fsck_ffs/inode.c /src/sbin/fsck_ffs/main.c /src/sbin/fsck_ffs/pass1.c /src/sbin/fsck_ffs/pass1b.c /src/sbin/fsck_ffs/pass2.c /src/sbin/fsck_ffs/pass3.c /src/sbin/fsck_ffs/pass4.c /src/sbin/fsck_ffs/pass5.c /src/sbin/fsck_ffs/setup.c /src/sbin/fsck_ffs/suj.c /src/sbin/fsck_ffs/utilities.c /src/sbin/fsck_ffs/gjournal.c /src/sbin/fsck_ffs/../mount/getmntopts.c echo fsck_ffs: /obj/mips.mips/src/tmp/usr/lib/libc.a /obj/mips.mips/src/tmp/usr/lib/libufs.a >> .depend cc -O -pipe -G0 -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/dir.c cc -O -pipe -G0 -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O -pipe -G0 -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:452: warning: format '%ld' expects type 'long int', but argument 2 has type 'time_t' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/mips.mips/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-25 02:22:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-25 02:22:59 - ERROR: failed to build world TB --- 2013-02-25 02:22:59 - 2140.26 user 533.20 system 3016.84 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 06:09:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1E2E5A83; Mon, 25 Feb 2013 06:09:50 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp4.clear.net.nz (smtp4.clear.net.nz [203.97.37.64]) by mx1.freebsd.org (Postfix) with ESMTP id D2C15F21; Mon, 25 Feb 2013 06:09:49 +0000 (UTC) Received: from mxin2-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp4.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MIR00H8AIGALX10@smtp4.clear.net.nz>; Mon, 25 Feb 2013 19:09:47 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin2.paradise.net.nz with ESMTP; Mon, 25 Feb 2013 19:09:43 +1300 Date: Mon, 25 Feb 2013 19:09:20 +1300 From: Andrew Turner Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access In-reply-to: <201302211043.49906.jhb@freebsd.org> To: John Baldwin Message-id: <20130225190920.1b7d348d@bender> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: <201302201022.29294.jhb@freebsd.org> <201302211043.49906.jhb@freebsd.org> Cc: Konstantin Belousov , freebsd-current@freebsd.org, Svatopluk Kraus , cognet@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 06:09:50 -0000 On Thu, 21 Feb 2013 10:43:49 -0500 John Baldwin wrote: > On Thursday, February 21, 2013 7:53:52 am Svatopluk Kraus wrote: > > On Wed, Feb 20, 2013 at 4:22 PM, John Baldwin > > wrote: > > > On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus wrote: > > >> On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov > > >> wrote: > > >> > On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus > > >> > wrote: > > >> >> On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov > > >> >> wrote: > > >> >> Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP > > >> >> case was simple. SMP case is more complex and rather new for > > >> >> me. Recently, I was solving a problem with PCPU stuff. For > > >> >> example, PCPU_GET is implemented by one instruction on i386 > > >> >> arch. So, a need of atomicity with respect to interrupts can > > >> >> be overlooked. On load-store archs, the implementation which > > >> >> works in SMP case is not so simple. And what works in UP case > > >> >> (single PCPU), not works in SMP case. Believe me, mysterious > > >> >> and sporadic 'mutex not owned' assertions and others ones > > >> >> caused by curthreads mess, it takes a while ... > > >> > Note that PCPU_GET() is not needed to be atomic. The reason is > > >> > that the code which uses its result would not be atomic > > >> > (single-instruction or whatever, see below). Thus, either the > > >> > preemption should not matter since the action with the per-cpu > > >> > data is advisory, as is in the case of i386 pmap you noted. or > > >> > some external measures should be applied in advance to the > > >> > containing region (which you proposed, by bracing with > > >> > sched_pin()). > > >> > > >> So, it's advisory in the case of i386 pmap... Well, if you can > > >> live with that, I can too. > > >> > > >> > > > >> > Also, note that it is not interrupts but preemption which is > > >> > concern. > > >> > > >> Yes and no. In theory, yes, a preemption is a concern. In > > >> FreeBSD, however, sched_pin() and critical_enter() and their > > >> counterparts are implemented with help of curthread. And > > >> curthread definition falls to PCPU_GET(curthread) if not defined > > >> in other way. So, curthread should be atomic with respect to > > >> interrupts and in general, PCPU_GET() should be too. Note that > > >> spinlock_enter() definitions often (always) use curthread too. > > >> Anyhow, it's defined in MD code and can be defined for each arch > > >> separately. > > > > > > curthread is a bit magic. :) If you perform a context switch > > > during an interrupt (which will change 'curthread') you also > > > change your register state. When you resume, the register state > > > is also restored. This means that while something like > > > 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread' > > > never is. However, it is true that actually reading curthread > > > has to be atomic. If your read of curthread looks like: > > > > > > mov , r0 > > > add , r0 > > > ld r0, r1 > > > > > > Then that will indeed break. Alpha used a fixed register for > > > 'pcpu_reg' (as does ia64 IIRC). OTOH, you might also be able to > > > depend on the fact that pc_curthread is the first thing in > > > 'struct pcpu' (and always will be, you could add a CTASSERT to > > > future-proof). In that case, you can remove the 'add' > > > instruction and instead just do: > > > > > > ld , r1 > > > > > > which is fine. > > > > Just for the record. There are three extra (coprocessor) registers > > per a core in arm11mpcore (armv6k). Unfortunately only one is > > Privileged. The other ones are respectively User Read only and User > > Read Write. For now, we are using the Privileged one to store pcpu > > pointer (curthread is correctly set during each context switch). > > Thus, using a coprocessor register means that reading of curthread > > is not a single instruction implementation now. After we figured > > out the curthread issue in SMP case, using a fixed (processor) > > register for pcpu is an option. Meanwhile, we disable interrupts > > before reading of curthread and enable them after. The same is done > > for other PCPU stuff. For now we have not stable system enough for > > profiling, however, when it will be, it would be interesting to > > learn how various implementations of curthread reading impact > > system performance. > > curthread is read _a lot_, so I would expect this to hurt. What we > did on Alpha was to use a fixed register for pcpu access, but we used > the equivalent of a coprocessor register to also store the value so > we could set that fixed register on entry to the kernel (userland was > free to use the register for its own purposes). > The current code on ARM is not atomic, it loads the base address of the pcpu data from the coprocessor then loads curthread from this address. One solution I discussed with Olivier Houchard is to keep the data in the coprocessor but to then load it into a dedicated register when we enter the kernel. Reading curthread would then be a single load instruction thanks to ARM's ldr using an immediate offset [1], e.g. to load from r12 into r1 it would be 'ldr r1, [r12]'. Andrew [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489c/CIHGJHED.html From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 08:23:51 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7283146D; Mon, 25 Feb 2013 08:23:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by mx1.freebsd.org (Postfix) with ESMTP id 310AD400; Mon, 25 Feb 2013 08:23:50 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id fb1so1615794pad.25 for ; Mon, 25 Feb 2013 00:23:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=8scQliQEVjJRdqJwOBbLDV9KwzfgaFEhkMngoKI4xg0=; b=j/CcaFO44Gri2eXlTVHRkK6hzooUngIEWAlTYiL6ZgkvC3sQbh8Vmdfp/Ymn04eJKt BjYA+QdM7Q2itVyhThLGC1RJOGmJZFj7auYyv5tHncIZ3RP3WBIIeacd2N9rlS5CtRz2 TuYiRIhgoroBEA2pKYMToT6FFwnbt0pc4JGDNZLWUNhE3FjvsownnzoDTPqKiVCWFqxs cqpalGkhngASh4YWvbvVhFVxO2AtcsCG9ibCJx8HjI0Wu0wHaWg3e55T08pSAyTZ+hjw Fup9wTc6VAqUod5BLWgyJAmQqSqEfIDkcfDICZo+CbfKpqAV6/kWc2XxQ+CEadc6hvbW KdtA== X-Received: by 10.68.153.97 with SMTP id vf1mr16605081pbb.93.1361780630556; Mon, 25 Feb 2013 00:23:50 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id qf7sm11994358pbb.2.2013.02.25.00.23.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 25 Feb 2013 00:23:49 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 25 Feb 2013 17:23:44 +0900 From: YongHyeon PYUN Date: Mon, 25 Feb 2013 17:23:44 +0900 To: Alexey Dokuchaev Subject: Re: ale(4) cannot negotiate as GigE Message-ID: <20130225082344.GC1426@michelle.cdnetworks.com> References: <20130219082302.GA86501@FreeBSD.org> <20130220043739.GA1469@michelle.cdnetworks.com> <20130220060853.GA83110@FreeBSD.org> <20130221083335.GA3226@michelle.cdnetworks.com> <20130221124344.GA93056@FreeBSD.org> <20130222011308.GA3259@michelle.cdnetworks.com> <20130222015607.GC66767@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130222015607.GC66767@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 08:23:51 -0000 On Fri, Feb 22, 2013 at 01:56:07AM +0000, Alexey Dokuchaev wrote: > On Fri, Feb 22, 2013 at 10:13:08AM +0900, YongHyeon PYUN wrote: > > On Thu, Feb 21, 2013 at 12:43:44PM +0000, Alexey Dokuchaev wrote: > > > ale_flags = 0x00000040 > > > > Thanks for the info. Indeed, your controller is AR8121 Gigabit > > etherent(L1E). I guess the PHY initialization is not complete. > > Would you try attached patch? > > Thanks for the patch. Unfortunately, it's still "100baseTX " > after driver reload. Even tried delaying for 3000, no difference. :( > Then have no idea at this moment. Can you try other OS and check whether it can establish a gigabit link? > ./danfe From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 08:42:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F265599B; Mon, 25 Feb 2013 08:42:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3EF786DA; Mon, 25 Feb 2013 08:42:16 +0000 (UTC) X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 379638143; Mon, 25 Feb 2013 09:37:07 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org, Daniel Eischen Subject: Re: USB not working Date: Mon, 25 Feb 2013 09:38:22 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: In-Reply-To: X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 08:42:18 -0000 On Sunday 24 February 2013 20:31:52 Daniel Eischen wrote: > Hey, I've got a Dell Inspiron 15R Special Edition and haven't > had working USB since first installing FreeBSD on it. I'm > currently at r247154. > > When I insert a flash drive (which works fine on my desktop > -current system), it is not recognized. I've tried multiple > different USB drives (external HDD, flash) that all work > on my desktop, but aren't recognized on me Dell notebook. > This is what is in dmesg: > > xhci_do_command: Command timeout! > usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) > ugen0.2: at usbus0 (disconnected) > uhub_reattach_port: could not allocate new device > > I've got the output of a dmesg, pciconf -lv, and messages > during insertion with: > > hw.usb.dev.debug=1 > hw.usb.umass.debug=1 > hw.usb.uhub.debug=1 > hw.usb.ugen.debug=1 > hw.usb.xhci.debug=1 > > here: > > http://people.freebsd.org/~deischen/usb/dmesg.txt > http://people.freebsd.org/~deischen/usb/pciconf.txt > http://people.freebsd.org/~deischen/usb/usb_flash_insertion.tx > > Any suggestions? Try to set: sysctl hw.usb.xhci.xhci_port_route=-1 In /boot/loader.conf I see you have a Pantherpoint chipset, and those have special port routing features. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 08:50:39 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8A43EDD5; Mon, 25 Feb 2013 08:50:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 62CDA74A; Mon, 25 Feb 2013 08:50:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1P8ocND030666; Mon, 25 Feb 2013 03:50:38 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1P8ocFf030661; Mon, 25 Feb 2013 08:50:38 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 25 Feb 2013 08:50:38 GMT Message-Id: <201302250850.r1P8ocFf030661@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 08:50:39 -0000 TB --- 2013-02-25 07:10:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-25 07:10:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-25 07:10:16 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-25 07:10:16 - cleaning the object tree TB --- 2013-02-25 07:12:20 - /usr/local/bin/svn stat /src TB --- 2013-02-25 07:12:23 - At svn revision 247251 TB --- 2013-02-25 07:12:24 - building world TB --- 2013-02-25 07:12:24 - CROSS_BUILD_TESTING=YES TB --- 2013-02-25 07:12:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-25 07:12:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-25 07:12:24 - SRCCONF=/dev/null TB --- 2013-02-25 07:12:24 - TARGET=arm TB --- 2013-02-25 07:12:24 - TARGET_ARCH=arm TB --- 2013-02-25 07:12:24 - TZ=UTC TB --- 2013-02-25 07:12:24 - __MAKE_CONF=/dev/null TB --- 2013-02-25 07:12:24 - cd /src TB --- 2013-02-25 07:12:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Feb 25 07:12:28 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] mkdep -f .depend -a -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 /src/sbin/fsck_ffs/dir.c /src/sbin/fsck_ffs/ea.c /src/sbin/fsck_ffs/fsutil.c /src/sbin/fsck_ffs/inode.c /src/sbin/fsck_ffs/main.c /src/sbin/fsck_ffs/pass1.c /src/sbin/fsck_ffs/pass1b.c /src/sbin/fsck_ffs/pass2.c /src/sbin/fsck_ffs/pass3.c /src/sbin/fsck_ffs/pass4.c /src/sbin/fsck_ffs/pass5.c /src/sbin/fsck_ffs/setup.c /src/sbin/fsck_ffs/suj.c /src/sbin/fsck_ffs/utilities.c /src/sbin/fsck_ffs/gjournal.c /src/sbin/fsck_ffs/../mount/getmntopts.c echo fsck_ffs: /obj/arm.arm/src/tmp/usr/lib/libc.a /obj/arm.arm/src/tmp/usr/lib/libufs.a >> .depend cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/dir.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:452: warning: format '%ld' expects type 'long int', but argument 2 has type 'time_t' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/arm.arm/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-25 08:50:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-25 08:50:38 - ERROR: failed to build world TB --- 2013-02-25 08:50:38 - 4695.34 user 834.30 system 6021.73 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 08:50:39 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A3899DD6; Mon, 25 Feb 2013 08:50:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7C96874B; Mon, 25 Feb 2013 08:50:39 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1P8ocwY030692; Mon, 25 Feb 2013 03:50:38 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1P8ocGY030691; Mon, 25 Feb 2013 08:50:38 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 25 Feb 2013 08:50:38 GMT Message-Id: <201302250850.r1P8ocGY030691@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 08:50:39 -0000 TB --- 2013-02-25 07:10:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-25 07:10:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-25 07:10:16 - starting HEAD tinderbox run for armv6/arm TB --- 2013-02-25 07:10:16 - cleaning the object tree TB --- 2013-02-25 07:12:19 - /usr/local/bin/svn stat /src TB --- 2013-02-25 07:12:23 - At svn revision 247251 TB --- 2013-02-25 07:12:24 - building world TB --- 2013-02-25 07:12:24 - CROSS_BUILD_TESTING=YES TB --- 2013-02-25 07:12:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-25 07:12:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-25 07:12:24 - SRCCONF=/dev/null TB --- 2013-02-25 07:12:24 - TARGET=arm TB --- 2013-02-25 07:12:24 - TARGET_ARCH=armv6 TB --- 2013-02-25 07:12:24 - TZ=UTC TB --- 2013-02-25 07:12:24 - __MAKE_CONF=/dev/null TB --- 2013-02-25 07:12:24 - cd /src TB --- 2013-02-25 07:12:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Feb 25 07:12:28 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] mkdep -f .depend -a -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 /src/sbin/fsck_ffs/dir.c /src/sbin/fsck_ffs/ea.c /src/sbin/fsck_ffs/fsutil.c /src/sbin/fsck_ffs/inode.c /src/sbin/fsck_ffs/main.c /src/sbin/fsck_ffs/pass1.c /src/sbin/fsck_ffs/pass1b.c /src/sbin/fsck_ffs/pass2.c /src/sbin/fsck_ffs/pass3.c /src/sbin/fsck_ffs/pass4.c /src/sbin/fsck_ffs/pass5.c /src/sbin/fsck_ffs/setup.c /src/sbin/fsck_ffs/suj.c /src/sbin/fsck_ffs/utilities.c /src/sbin/fsck_ffs/gjournal.c /src/sbin/fsck_ffs/../mount/getmntopts.c echo fsck_ffs: /obj/arm.armv6/src/tmp/usr/lib/libc.a /obj/arm.armv6/src/tmp/usr/lib/libufs.a >> .depend cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/dir.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:452: warning: format '%ld' expects type 'long int', but argument 2 has type 'time_t' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/arm.armv6/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-25 08:50:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-25 08:50:38 - ERROR: failed to build world TB --- 2013-02-25 08:50:38 - 4690.77 user 834.89 system 6022.24 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 12:11:32 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 30A68B73; Mon, 25 Feb 2013 12:11:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E8FF669F; Mon, 25 Feb 2013 12:11:31 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1PCBVgU077678; Mon, 25 Feb 2013 07:11:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1PCBV1g077655; Mon, 25 Feb 2013 12:11:31 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 25 Feb 2013 12:11:31 GMT Message-Id: <201302251211.r1PCBV1g077655@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 12:11:32 -0000 TB --- 2013-02-25 11:21:39 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-25 11:21:39 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-25 11:21:39 - starting HEAD tinderbox run for mips/mips TB --- 2013-02-25 11:21:39 - cleaning the object tree TB --- 2013-02-25 11:22:28 - /usr/local/bin/svn stat /src TB --- 2013-02-25 11:22:45 - At svn revision 247251 TB --- 2013-02-25 11:22:46 - building world TB --- 2013-02-25 11:22:46 - CROSS_BUILD_TESTING=YES TB --- 2013-02-25 11:22:46 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-25 11:22:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-25 11:22:46 - SRCCONF=/dev/null TB --- 2013-02-25 11:22:46 - TARGET=mips TB --- 2013-02-25 11:22:46 - TARGET_ARCH=mips TB --- 2013-02-25 11:22:46 - TZ=UTC TB --- 2013-02-25 11:22:46 - __MAKE_CONF=/dev/null TB --- 2013-02-25 11:22:46 - cd /src TB --- 2013-02-25 11:22:46 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Feb 25 11:22:50 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] mkdep -f .depend -a -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 /src/sbin/fsck_ffs/dir.c /src/sbin/fsck_ffs/ea.c /src/sbin/fsck_ffs/fsutil.c /src/sbin/fsck_ffs/inode.c /src/sbin/fsck_ffs/main.c /src/sbin/fsck_ffs/pass1.c /src/sbin/fsck_ffs/pass1b.c /src/sbin/fsck_ffs/pass2.c /src/sbin/fsck_ffs/pass3.c /src/sbin/fsck_ffs/pass4.c /src/sbin/fsck_ffs/pass5.c /src/sbin/fsck_ffs/setup.c /src/sbin/fsck_ffs/suj.c /src/sbin/fsck_ffs/utilities.c /src/sbin/fsck_ffs/gjournal.c /src/sbin/fsck_ffs/../mount/getmntopts.c echo fsck_ffs: /obj/mips.mips/src/tmp/usr/lib/libc.a /obj/mips.mips/src/tmp/usr/lib/libufs.a >> .depend cc -O -pipe -G0 -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/dir.c cc -O -pipe -G0 -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O -pipe -G0 -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:452: warning: format '%ld' expects type 'long int', but argument 2 has type 'time_t' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Stop in /obj/mips.mips/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-25 12:11:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-25 12:11:30 - ERROR: failed to build world TB --- 2013-02-25 12:11:30 - 2122.27 user 532.38 system 2991.35 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 12:48:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 670D2694; Mon, 25 Feb 2013 12:48:11 +0000 (UTC) (envelope-from cognet@ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:150:ca0a:a9ff:fef1:a4c9]) by mx1.freebsd.org (Postfix) with ESMTP id E97F7848; Mon, 25 Feb 2013 12:48:10 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.5/8.14.5) with ESMTP id r1PCllf5021109; Mon, 25 Feb 2013 13:47:47 +0100 (CET) (envelope-from cognet@ci0.org) Received: (from doginou@localhost) by kanar.ci0.org (8.14.5/8.14.5/Submit) id r1PCllAx021108; Mon, 25 Feb 2013 13:47:47 +0100 (CET) (envelope-from cognet@ci0.org) X-Authentication-Warning: kanar.ci0.org: doginou set sender to cognet@ci0.org using -f Date: Mon, 25 Feb 2013 13:47:47 +0100 From: Olivier Houchard To: Andrew Turner Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access Message-ID: <20130225124747.GA21027@ci0.org> References: <201302201022.29294.jhb@freebsd.org> <201302211043.49906.jhb@freebsd.org> <20130225190920.1b7d348d@bender> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130225190920.1b7d348d@bender> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Mon, 25 Feb 2013 12:50:38 +0000 Cc: Konstantin Belousov , freebsd-current@freebsd.org, Svatopluk Kraus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 12:48:11 -0000 On Mon, Feb 25, 2013 at 07:09:20PM +1300, Andrew Turner wrote: > On Thu, 21 Feb 2013 10:43:49 -0500 > John Baldwin wrote: > > > On Thursday, February 21, 2013 7:53:52 am Svatopluk Kraus wrote: > > > On Wed, Feb 20, 2013 at 4:22 PM, John Baldwin > > > wrote: > > > > On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus wrote: > > > >> On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov > > > >> wrote: > > > >> > On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus > > > >> > wrote: > > > >> >> On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov > > > >> >> wrote: > > > >> >> Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP > > > >> >> case was simple. SMP case is more complex and rather new for > > > >> >> me. Recently, I was solving a problem with PCPU stuff. For > > > >> >> example, PCPU_GET is implemented by one instruction on i386 > > > >> >> arch. So, a need of atomicity with respect to interrupts can > > > >> >> be overlooked. On load-store archs, the implementation which > > > >> >> works in SMP case is not so simple. And what works in UP case > > > >> >> (single PCPU), not works in SMP case. Believe me, mysterious > > > >> >> and sporadic 'mutex not owned' assertions and others ones > > > >> >> caused by curthreads mess, it takes a while ... > > > >> > Note that PCPU_GET() is not needed to be atomic. The reason is > > > >> > that the code which uses its result would not be atomic > > > >> > (single-instruction or whatever, see below). Thus, either the > > > >> > preemption should not matter since the action with the per-cpu > > > >> > data is advisory, as is in the case of i386 pmap you noted. or > > > >> > some external measures should be applied in advance to the > > > >> > containing region (which you proposed, by bracing with > > > >> > sched_pin()). > > > >> > > > >> So, it's advisory in the case of i386 pmap... Well, if you can > > > >> live with that, I can too. > > > >> > > > >> > > > > >> > Also, note that it is not interrupts but preemption which is > > > >> > concern. > > > >> > > > >> Yes and no. In theory, yes, a preemption is a concern. In > > > >> FreeBSD, however, sched_pin() and critical_enter() and their > > > >> counterparts are implemented with help of curthread. And > > > >> curthread definition falls to PCPU_GET(curthread) if not defined > > > >> in other way. So, curthread should be atomic with respect to > > > >> interrupts and in general, PCPU_GET() should be too. Note that > > > >> spinlock_enter() definitions often (always) use curthread too. > > > >> Anyhow, it's defined in MD code and can be defined for each arch > > > >> separately. > > > > > > > > curthread is a bit magic. :) If you perform a context switch > > > > during an interrupt (which will change 'curthread') you also > > > > change your register state. When you resume, the register state > > > > is also restored. This means that while something like > > > > 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread' > > > > never is. However, it is true that actually reading curthread > > > > has to be atomic. If your read of curthread looks like: > > > > > > > > mov , r0 > > > > add , r0 > > > > ld r0, r1 > > > > > > > > Then that will indeed break. Alpha used a fixed register for > > > > 'pcpu_reg' (as does ia64 IIRC). OTOH, you might also be able to > > > > depend on the fact that pc_curthread is the first thing in > > > > 'struct pcpu' (and always will be, you could add a CTASSERT to > > > > future-proof). In that case, you can remove the 'add' > > > > instruction and instead just do: > > > > > > > > ld , r1 > > > > > > > > which is fine. > > > > > > Just for the record. There are three extra (coprocessor) registers > > > per a core in arm11mpcore (armv6k). Unfortunately only one is > > > Privileged. The other ones are respectively User Read only and User > > > Read Write. For now, we are using the Privileged one to store pcpu > > > pointer (curthread is correctly set during each context switch). > > > Thus, using a coprocessor register means that reading of curthread > > > is not a single instruction implementation now. After we figured > > > out the curthread issue in SMP case, using a fixed (processor) > > > register for pcpu is an option. Meanwhile, we disable interrupts > > > before reading of curthread and enable them after. The same is done > > > for other PCPU stuff. For now we have not stable system enough for > > > profiling, however, when it will be, it would be interesting to > > > learn how various implementations of curthread reading impact > > > system performance. > > > > curthread is read _a lot_, so I would expect this to hurt. What we > > did on Alpha was to use a fixed register for pcpu access, but we used > > the equivalent of a coprocessor register to also store the value so > > we could set that fixed register on entry to the kernel (userland was > > free to use the register for its own purposes). > > > > The current code on ARM is not atomic, it loads the base address of the > pcpu data from the coprocessor then loads curthread from this address. > One solution I discussed with Olivier Houchard is to keep the data in > the coprocessor but to then load it into a dedicated register when we > enter the kernel. > > Reading curthread would then be a single load instruction thanks to > ARM's ldr using an immediate offset [1], e.g. to load from r12 into r1 > it would be 'ldr r1, [r12]'. > Wouldn't it be doable to either use the extra coprocessor register for curthread, setting it when entering the kernel as John suggested, or just using the privileged one for curthread, and changing get_pcpu() to be __pcpu[cpuid], and then making sure pcpu accesses are atomic, either by disabling interrupts or using ldrex/strex ? I take it curthread (and curpcb, which we can get from curthread) is by far the most used, and it wouldn't hurt that badly to pessimize the other pcpu variables ? Olivier From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 14:01:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3191C9F2 for ; Mon, 25 Feb 2013 14:01:30 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id DFE3CE3D for ; Mon, 25 Feb 2013 14:01:29 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r1PE1OMg005906; Mon, 25 Feb 2013 09:01:24 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.10]); Mon, 25 Feb 2013 09:01:24 -0500 (EST) Date: Mon, 25 Feb 2013 09:01:24 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Hans Petter Selasky Subject: Re: USB not working In-Reply-To: <201302250938.23012.hselasky@c2i.net> Message-ID: References: <201302250938.23012.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 14:01:30 -0000 On Mon, 25 Feb 2013, Hans Petter Selasky wrote: > On Sunday 24 February 2013 20:31:52 Daniel Eischen wrote: >> Hey, I've got a Dell Inspiron 15R Special Edition and haven't >> had working USB since first installing FreeBSD on it. I'm >> currently at r247154. >> >> When I insert a flash drive (which works fine on my desktop >> -current system), it is not recognized. I've tried multiple >> different USB drives (external HDD, flash) that all work >> on my desktop, but aren't recognized on me Dell notebook. >> This is what is in dmesg: >> >> xhci_do_command: Command timeout! >> usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) >> ugen0.2: at usbus0 (disconnected) >> uhub_reattach_port: could not allocate new device >> >> I've got the output of a dmesg, pciconf -lv, and messages >> during insertion with: >> >> hw.usb.dev.debug=1 >> hw.usb.umass.debug=1 >> hw.usb.uhub.debug=1 >> hw.usb.ugen.debug=1 >> hw.usb.xhci.debug=1 >> >> here: >> >> http://people.freebsd.org/~deischen/usb/dmesg.txt >> http://people.freebsd.org/~deischen/usb/pciconf.txt >> http://people.freebsd.org/~deischen/usb/usb_flash_insertion.tx >> >> Any suggestions? > > Try to set: > > sysctl hw.usb.xhci.xhci_port_route=-1 > > In /boot/loader.conf > > I see you have a Pantherpoint chipset, and those have special port routing > features. Thanks, that didn't help. $ sysctl hw.usb.xhci.xhci_port_route hw.usb.xhci.xhci_port_route: 1 And from /var/log/messages with the above: Feb 25 08:56:21 rigel kernel: xhci_do_command: Command timeout! Feb 25 08:56:21 rigel kernel: usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) Feb 25 08:56:21 rigel kernel: ugen0.2: at usbus0 (disconnected) Feb 25 08:56:21 rigel kernel: uhub_reattach_port: could not allocate new device -- DE From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 14:21:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3368023C; Mon, 25 Feb 2013 14:21:58 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id 93443F56; Mon, 25 Feb 2013 14:21:57 +0000 (UTC) X-T2-Spam-Status: No, hits=0.0 required=5.0 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 380120051; Mon, 25 Feb 2013 15:16:48 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org, Daniel Eischen Subject: Re: USB not working Date: Mon, 25 Feb 2013 15:18:04 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <201302250938.23012.hselasky@c2i.net> In-Reply-To: X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 14:21:58 -0000 On Monday 25 February 2013 15:01:24 Daniel Eischen wrote: > On Mon, 25 Feb 2013, Hans Petter Selasky wrote: > > On Sunday 24 February 2013 20:31:52 Daniel Eischen wrote: > >> Hey, I've got a Dell Inspiron 15R Special Edition and haven't > >> had working USB since first installing FreeBSD on it. I'm > >> currently at r247154. > >> > >> When I insert a flash drive (which works fine on my desktop > >> -current system), it is not recognized. I've tried multiple > >> different USB drives (external HDD, flash) that all work > >> on my desktop, but aren't recognized on me Dell notebook. > >> This is what is in dmesg: > >> > >> xhci_do_command: Command timeout! > >> usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) > >> ugen0.2: at usbus0 (disconnected) > >> uhub_reattach_port: could not allocate new device > >> > >> I've got the output of a dmesg, pciconf -lv, and messages > >> > >> during insertion with: > >> hw.usb.dev.debug=1 > >> hw.usb.umass.debug=1 > >> hw.usb.uhub.debug=1 > >> hw.usb.ugen.debug=1 > >> hw.usb.xhci.debug=1 > >> > >> here: > >> http://people.freebsd.org/~deischen/usb/dmesg.txt > >> http://people.freebsd.org/~deischen/usb/pciconf.txt > >> http://people.freebsd.org/~deischen/usb/usb_flash_insertion.tx > >> > >> Any suggestions? > > > > Try to set: > > > > sysctl hw.usb.xhci.xhci_port_route=-1 > > > > In /boot/loader.conf > > > > I see you have a Pantherpoint chipset, and those have special port > > routing features. > > Thanks, that didn't help. > > $ sysctl hw.usb.xhci.xhci_port_route > hw.usb.xhci.xhci_port_route: 1 > It should be minus one. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 14:32:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4FDF058C for ; Mon, 25 Feb 2013 14:32:32 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id E5237FE2 for ; Mon, 25 Feb 2013 14:32:31 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r1PEWQcF043593; Mon, 25 Feb 2013 09:32:26 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.10]); Mon, 25 Feb 2013 09:32:26 -0500 (EST) Date: Mon, 25 Feb 2013 09:32:26 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Hans Petter Selasky Subject: Re: USB not working In-Reply-To: <201302251518.04798.hselasky@c2i.net> Message-ID: References: <201302250938.23012.hselasky@c2i.net> <201302251518.04798.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 14:32:32 -0000 On Mon, 25 Feb 2013, Hans Petter Selasky wrote: > On Monday 25 February 2013 15:01:24 Daniel Eischen wrote: >> On Mon, 25 Feb 2013, Hans Petter Selasky wrote: >>> On Sunday 24 February 2013 20:31:52 Daniel Eischen wrote: >>>> Hey, I've got a Dell Inspiron 15R Special Edition and haven't >>>> had working USB since first installing FreeBSD on it. I'm >>>> currently at r247154. >>>> >>>> When I insert a flash drive (which works fine on my desktop >>>> -current system), it is not recognized. I've tried multiple >>>> different USB drives (external HDD, flash) that all work >>>> on my desktop, but aren't recognized on me Dell notebook. >>>> This is what is in dmesg: >>>> >>>> xhci_do_command: Command timeout! >>>> usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) >>>> ugen0.2: at usbus0 (disconnected) >>>> uhub_reattach_port: could not allocate new device >>>> >>>> I've got the output of a dmesg, pciconf -lv, and messages >>>> >>>> during insertion with: >>>> hw.usb.dev.debug=1 >>>> hw.usb.umass.debug=1 >>>> hw.usb.uhub.debug=1 >>>> hw.usb.ugen.debug=1 >>>> hw.usb.xhci.debug=1 >>>> >>>> here: >>>> http://people.freebsd.org/~deischen/usb/dmesg.txt >>>> http://people.freebsd.org/~deischen/usb/pciconf.txt >>>> http://people.freebsd.org/~deischen/usb/usb_flash_insertion.tx >>>> >>>> Any suggestions? >>> >>> Try to set: >>> >>> sysctl hw.usb.xhci.xhci_port_route=-1 >>> >>> In /boot/loader.conf >>> >>> I see you have a Pantherpoint chipset, and those have special port >>> routing features. >> >> Thanks, that didn't help. >> >> $ sysctl hw.usb.xhci.xhci_port_route >> hw.usb.xhci.xhci_port_route: 1 >> > > It should be minus one. Oops, that blended right in with the '='. I just tried -1 and it didn't work: $ sysctl hw.usb.xhci.xhci_port_route hw.usb.xhci.xhci_port_route: -1 Feb 25 09:28:25 rigel kernel: xhci_do_command: Command timeout! Feb 25 09:28:25 rigel kernel: usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) Feb 25 09:28:25 rigel kernel: ugen0.2: at usbus0 (disconnected) Feb 25 09:28:25 rigel kernel: uhub_reattach_port: could not allocate new device Should I reboot just to start fresh? -- DE From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 14:36:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DD268707 for ; Mon, 25 Feb 2013 14:36:12 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9BA878C for ; Mon, 25 Feb 2013 14:36:12 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r1PEa7sY048410; Mon, 25 Feb 2013 09:36:07 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.10]); Mon, 25 Feb 2013 09:36:07 -0500 (EST) Date: Mon, 25 Feb 2013 09:36:07 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Hans Petter Selasky Subject: Re: USB not working In-Reply-To: Message-ID: References: <201302250938.23012.hselasky@c2i.net> <201302251518.04798.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 14:36:12 -0000 On Mon, 25 Feb 2013, Daniel Eischen wrote: > On Mon, 25 Feb 2013, Hans Petter Selasky wrote: > >> On Monday 25 February 2013 15:01:24 Daniel Eischen wrote: >>> On Mon, 25 Feb 2013, Hans Petter Selasky wrote: >>>> Try to set: >>>> >>>> sysctl hw.usb.xhci.xhci_port_route=-1 >>>> >>>> In /boot/loader.conf >>>> >>>> I see you have a Pantherpoint chipset, and those have special port >>>> routing features. >>> >>> Thanks, that didn't help. >>> >>> $ sysctl hw.usb.xhci.xhci_port_route >>> hw.usb.xhci.xhci_port_route: 1 >>> >> >> It should be minus one. > > Oops, that blended right in with the '='. I just tried -1 and it > didn't work: > > $ sysctl hw.usb.xhci.xhci_port_route > hw.usb.xhci.xhci_port_route: -1 > > Feb 25 09:28:25 rigel kernel: xhci_do_command: Command timeout! > Feb 25 09:28:25 rigel kernel: usb_alloc_device: device init 2 failed > (USB_ERR_TIMEOUT, ignored) > Feb 25 09:28:25 rigel kernel: ugen0.2: at usbus0 (disconnected) > Feb 25 09:28:25 rigel kernel: uhub_reattach_port: could not allocate new > device > > Should I reboot just to start fresh? That didn't help either. -- DE From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 14:38:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0EC02863; Mon, 25 Feb 2013 14:38:27 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id 75997E0; Mon, 25 Feb 2013 14:38:26 +0000 (UTC) X-T2-Spam-Status: No, hits=0.0 required=5.0 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 381878293; Mon, 25 Feb 2013 15:38:18 +0100 From: Hans Petter Selasky To: Daniel Eischen Subject: Re: USB not working Date: Mon, 25 Feb 2013 15:39:34 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <201302251518.04798.hselasky@c2i.net> In-Reply-To: X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 14:38:27 -0000 On Monday 25 February 2013 15:32:26 Daniel Eischen wrote: > On Mon, 25 Feb 2013, Hans Petter Selasky wrote: > > On Monday 25 February 2013 15:01:24 Daniel Eischen wrote: > >> On Mon, 25 Feb 2013, Hans Petter Selasky wrote: > >>> On Sunday 24 February 2013 20:31:52 Daniel Eischen wrote: > >>>> Hey, I've got a Dell Inspiron 15R Special Edition and haven't > >>>> had working USB since first installing FreeBSD on it. I'm > >>>> currently at r247154. > >>>> > >>>> When I insert a flash drive (which works fine on my desktop > >>>> -current system), it is not recognized. I've tried multiple > >>>> different USB drives (external HDD, flash) that all work > >>>> on my desktop, but aren't recognized on me Dell notebook. > >>>> This is what is in dmesg: > >>>> > >>>> xhci_do_command: Command timeout! > >>>> usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) > >>>> ugen0.2: at usbus0 (disconnected) > >>>> uhub_reattach_port: could not allocate new device > >>>> > >>>> I've got the output of a dmesg, pciconf -lv, and messages > >>>> > >>>> during insertion with: > >>>> hw.usb.dev.debug=1 > >>>> hw.usb.umass.debug=1 > >>>> hw.usb.uhub.debug=1 > >>>> hw.usb.ugen.debug=1 > >>>> hw.usb.xhci.debug=1 > >>>> > >>>> here: > >>>> http://people.freebsd.org/~deischen/usb/dmesg.txt > >>>> http://people.freebsd.org/~deischen/usb/pciconf.txt > >>>> http://people.freebsd.org/~deischen/usb/usb_flash_insertion.tx > >>>> > >>>> Any suggestions? > >>> > >>> Try to set: > >>> > >>> sysctl hw.usb.xhci.xhci_port_route=-1 > >>> > >>> In /boot/loader.conf > >>> > >>> I see you have a Pantherpoint chipset, and those have special port > >>> routing features. > >> > >> Thanks, that didn't help. > >> > >> $ sysctl hw.usb.xhci.xhci_port_route > >> hw.usb.xhci.xhci_port_route: 1 > > > > It should be minus one. > > Oops, that blended right in with the '='. I just tried -1 and it > didn't work: > > $ sysctl hw.usb.xhci.xhci_port_route > hw.usb.xhci.xhci_port_route: -1 > > Feb 25 09:28:25 rigel kernel: xhci_do_command: Command timeout! > Feb 25 09:28:25 rigel kernel: usb_alloc_device: device init 2 failed > (USB_ERR_TIMEOUT, ignored) Feb 25 09:28:25 rigel kernel: ugen0.2: > at usbus0 (disconnected) Feb 25 09:28:25 rigel kernel: > uhub_reattach_port: could not allocate new device > > Should I reboot just to start fresh? Hi, You need to set this in /boot/loader.conf and reboot before you test. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 18:20:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 837312DE for ; Mon, 25 Feb 2013 18:20:40 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1CE88D2B for ; Mon, 25 Feb 2013 18:20:39 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.6/8.14.6/NETPLEX) with ESMTP id r1PIKYgc033921; Mon, 25 Feb 2013 13:20:34 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.1 (mail.netplex.net [204.213.176.10]); Mon, 25 Feb 2013 13:20:34 -0500 (EST) Date: Mon, 25 Feb 2013 13:20:34 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Hans Petter Selasky Subject: Re: USB not working In-Reply-To: <201302251539.34465.hselasky@c2i.net> Message-ID: References: <201302251518.04798.hselasky@c2i.net> <201302251539.34465.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 18:20:40 -0000 On Mon, 25 Feb 2013, Hans Petter Selasky wrote: > On Monday 25 February 2013 15:32:26 Daniel Eischen wrote: >> On Mon, 25 Feb 2013, Hans Petter Selasky wrote: >>> On Monday 25 February 2013 15:01:24 Daniel Eischen wrote: >>>> On Mon, 25 Feb 2013, Hans Petter Selasky wrote: >>>>> On Sunday 24 February 2013 20:31:52 Daniel Eischen wrote: >>>>>> Hey, I've got a Dell Inspiron 15R Special Edition and haven't >>>>>> had working USB since first installing FreeBSD on it. I'm >>>>>> currently at r247154. >>>>>> >>>>>> When I insert a flash drive (which works fine on my desktop >>>>>> -current system), it is not recognized. I've tried multiple >>>>>> different USB drives (external HDD, flash) that all work >>>>>> on my desktop, but aren't recognized on me Dell notebook. >>>>>> This is what is in dmesg: >>>>>> >>>>>> xhci_do_command: Command timeout! >>>>>> usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) >>>>>> ugen0.2: at usbus0 (disconnected) >>>>>> uhub_reattach_port: could not allocate new device >>>>>> >>>>>> I've got the output of a dmesg, pciconf -lv, and messages >>>>>> >>>>>> during insertion with: >>>>>> hw.usb.dev.debug=1 >>>>>> hw.usb.umass.debug=1 >>>>>> hw.usb.uhub.debug=1 >>>>>> hw.usb.ugen.debug=1 >>>>>> hw.usb.xhci.debug=1 >>>>>> >>>>>> here: >>>>>> http://people.freebsd.org/~deischen/usb/dmesg.txt >>>>>> http://people.freebsd.org/~deischen/usb/pciconf.txt >>>>>> http://people.freebsd.org/~deischen/usb/usb_flash_insertion.tx >>>>>> >>>>>> Any suggestions? >>>>> >>>>> Try to set: >>>>> >>>>> sysctl hw.usb.xhci.xhci_port_route=-1 >>>>> >>>>> In /boot/loader.conf >>>>> >>>>> I see you have a Pantherpoint chipset, and those have special port >>>>> routing features. >>>> >>>> Thanks, that didn't help. >>>> >>>> $ sysctl hw.usb.xhci.xhci_port_route >>>> hw.usb.xhci.xhci_port_route: 1 >>> >>> It should be minus one. >> >> Oops, that blended right in with the '='. I just tried -1 and it >> didn't work: >> >> $ sysctl hw.usb.xhci.xhci_port_route >> hw.usb.xhci.xhci_port_route: -1 >> >> Feb 25 09:28:25 rigel kernel: xhci_do_command: Command timeout! >> Feb 25 09:28:25 rigel kernel: usb_alloc_device: device init 2 failed >> (USB_ERR_TIMEOUT, ignored) Feb 25 09:28:25 rigel kernel: ugen0.2: >> at usbus0 (disconnected) Feb 25 09:28:25 rigel kernel: >> uhub_reattach_port: could not allocate new device >> >> Should I reboot just to start fresh? > > Hi, > > You need to set this in /boot/loader.conf and reboot before you test. This worked - thanks! Any chance of getting this to be automatic, without having to tweak any knobs? -- DE From owner-freebsd-current@FreeBSD.ORG Mon Feb 25 21:13:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8AFC8F48; Mon, 25 Feb 2013 21:13:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 69995854; Mon, 25 Feb 2013 21:13:24 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 93BDEB93B; Mon, 25 Feb 2013 16:13:22 -0500 (EST) From: John Baldwin To: freebsd-acpi@freebsd.org Subject: Re: Fixing X220 Video The Right Way Date: Mon, 25 Feb 2013 13:30:56 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <512A6FFF.2060603@gmail.com> In-Reply-To: <512A6FFF.2060603@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302251330.57034.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 25 Feb 2013 16:13:22 -0500 (EST) Cc: matt , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 21:13:24 -0000 On Sunday, February 24, 2013 2:54:39 pm matt wrote: > I am working on fixing acpi_video for X220. > > My X220 is back to FreeBSD land, and I always felt \VBRC calls were dirty. > So I've set out to fix acpi_video to work naturally, as it does in linux > land. > > Background: > Lenovo laptops boot in a mode where the brightness keys automagically > work, under BIOS/EC control. > This gets blown away (for us) shortly after Kernel attach. > > At this point, the acpi method \NBCF will return 0, which means acpi > cannot control video brightness. > > Once we touch the _BCL method on the video output (even inactive ones), > \NBCF returns 1 and will allow acpi control. > > You may remember that acpi_video records some brightness value that > changes with keypresses, but does not work on X220. > > Current status: > If I modify acpi video to attach to \_SB.PCI0.PEG.VID, brightness works > via sysctl but not keypress (\NBCF = 1) > > If I leave that alone, but just redirect the brightness set function to > \_SB.PCI0.PEG.VID.LCD0._BCM, the keyboard works > > That is obviously a hack, but it indicates something is going on here. > > I think that get_acpi_handle() on the X220 vgapci is returning the wrong > ACPI_HANDLE. > Perhaps this is why the screen stays off when resume used to work? > > Obviously it can be fixed by hard coding this path into acpi_video, but > I feel like that is definitely the wrong way. > A tunable for an acpi_video override might be useful, but it still > leaves potentially the wrong path in vgapci's IVARs. > > Is there a better place to "correct" the ACPI_PATH that gets stored in > vgapci's ivar? Is there already a tunable I can use to fix this? vgapci's ivar is set by the PCI address. Do you have multiple vgapci devices? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 00:07:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7D06B7A7 for ; Tue, 26 Feb 2013 00:07:58 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by mx1.freebsd.org (Postfix) with ESMTP id 1D351FC0 for ; Tue, 26 Feb 2013 00:07:57 +0000 (UTC) Received: by mail-ve0-f173.google.com with SMTP id oz10so2799336veb.18 for ; Mon, 25 Feb 2013 16:07:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=23uoF+NCEfAo6kYAGEO8WCrKOg3oyurfRx05ZVgw9Pc=; b=WeTz3njuw87d3c0u1DQ8dd0K4iDBLESFT1u2a/TfB4S+EEHLgnICS94J64UPJvKzJR nSa6eeIFz7lkKrxtL8DOwZ5fuwLMNiKbgPZFkqkqAoulBFkOzmiu46Bz2BSDQ8DGHB4y 7bS0G4pDul8CBuiBkQYvjq2ZiE6DyMfdspGaII3/mJdWUuWT5ASVxVb5Ag0cNPDesCc1 8wZqiQLxvs7D+CM39QM41t2E16UtFq9mFw4FbB+NqoZueISXoSCAMrdaOq9e+tEBSiPO x7WI/WSpoCQ27JtuVtOAom9CiVO5YxdYpOyFWYwCv9ew2PX7ZbJ5fniwspVlAXBitIOI QGyg== MIME-Version: 1.0 X-Received: by 10.220.107.210 with SMTP id c18mr10822619vcp.5.1361837277162; Mon, 25 Feb 2013 16:07:57 -0800 (PST) Received: by 10.58.170.36 with HTTP; Mon, 25 Feb 2013 16:07:57 -0800 (PST) Date: Mon, 25 Feb 2013 16:07:57 -0800 Message-ID: Subject: OpenSolaris Testing Files From: Mehmet Erol Sanliturk To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 00:07:58 -0000 Dear All , The following sites will be removed completely by the Oracle after March 24 , 2013 with the following message : "ATTENTION: This website and all services within the opensolaris.org domain will be unavailable after March 24, 2013." http://hub.opensolaris.org/bin/view/Community+Group+testing/downloads http://hub.opensolaris.org/bin/view/Community+Group+testing/testlinks http://hub.opensolaris.org/bin/view/Community+Group+testing/perfbench http://hub.opensolaris.org/bin/view/Main/ In the following site : http://dlc.sun.com/osol/test/downloads/current/ there are OpenSolaris testing files with licenses such as CDDL , MIT , Artistic , BSD . I did not use any one of them for testing , but if they are saved by forking for future usage , and they can be used for FreeBSD testing ( perhaps after some modifications ) they can be useful . If they can not be used directly , they may inspire testing ideas at least . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 01:54:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9C261245; Tue, 26 Feb 2013 01:54:43 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by mx1.freebsd.org (Postfix) with ESMTP id 56E633A7; Tue, 26 Feb 2013 01:54:43 +0000 (UTC) Received: by mail-pb0-f41.google.com with SMTP id um15so2038050pbc.0 for ; Mon, 25 Feb 2013 17:54:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=Asf1qZ865mpkCGbhtWXyxaIsLHlAJpeZKnAiQvcLY6U=; b=07lp1ugUad/R8jJHdpWTsr0KlDElWdH+i6StTry4OlNxdd9gxkxP6eERcE/WDBOlxn DXI8BtOyIf6VujonF/NAPZfIoBW/2DaA4q7NtTm2DJd4avvqJOlgFi8xqtsnI3qIs6ju zHpbJV+BU4HIuSDew8C3CQkIESQAQK9u4EinaY9muNR8gG2y/dCK+E8uJbhah0WfS562 zLRYVkuhGro9agNaf8TbbY/nDatP5R+htD3xxCk6hYm9ajPJdsxj3ctN/g6VRU54A5ji gKGxqGFBULhMXA09JywckJqjvHqq2tFo/Vz/TBwBIthYsAM3TSHY40uixSY+sJr1DuNW Re6w== X-Received: by 10.68.212.197 with SMTP id nm5mr20799872pbc.179.1361843677654; Mon, 25 Feb 2013 17:54:37 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id t6sm15625028paz.11.2013.02.25.17.54.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 17:54:36 -0800 (PST) Message-ID: <512C159B.3020707@gmail.com> Date: Mon, 25 Feb 2013 17:53:31 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130224 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Baldwin Subject: Re: Fixing X220 Video The Right Way References: <512A6FFF.2060603@gmail.com> <201302251330.57034.jhb@freebsd.org> In-Reply-To: <201302251330.57034.jhb@freebsd.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 01:54:43 -0000 On 02/25/13 10:30, John Baldwin wrote: > > Is there a better place to "correct" the ACPI_PATH that gets stored in > vgapci's ivar? Is there already a tunable I can use to fix this? > vgapci's ivar is set by the PCI address. Do you have multiple vgapci devices? > No, just one. I think that the DSDT is very creative on recent Lenovos (read: broken). There are multiple video devices defined, with "functional" calls that nonetheless don't work to actually do anything. The acpi_get_handle() call in acpi_video returns a handle that has no active outputs and doesn't have any control over the brightness. The other path can control brightness. Here's a related discussion on Linux, I'm not sure how much applies other than the situation discussed: http://comments.gmane.org/gmane.linux.acpi.devel/57228 The same thing happens on AGP thinkpads, I believe, based on Mitsuru Iwasaki's comment a long time ago to an X220 thread. Matt From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 02:19:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E7F81796; Tue, 26 Feb 2013 02:19:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by mx1.freebsd.org (Postfix) with ESMTP id 1776D74B; Tue, 26 Feb 2013 02:19:26 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id l13so5470768wie.0 for ; Mon, 25 Feb 2013 18:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5nKdek7JZHUSEM+8qH3tDJxs0ZQ0+uy4JlK23YS5plA=; b=H3t3e/7Mp0FzlA8LnWN7/I7JQUenm4gF9bJL3jSQsh3UFEFQwdYTQ9oHpHQT8JYM29 o1Hl6VnGKEXAw8iL0Ym6gE0FwFxhXYV9pA9i2G7/3kIrd9NxAN/38//DKTjgQ9IwGnQr Az3Zf/NlzUqOu8Y98OFIkp1UxJLKZU7SgkRlabiBn9wDWbRoKN93Bmnomn8ukH6Iy2sV 6UD677t9KkT4J3IwtyPvNhdyh7Cl7JHCtzQU2h1v3MeXZzNIgHHoi05nQ3MIoX473WyO 7QORHAySGUn586eMTDUpKPquuFqeNHPjwO0g90/9jpw1uHb8u2RLPDXWZavqVS+7eRvx dDyg== MIME-Version: 1.0 X-Received: by 10.194.5.137 with SMTP id s9mr21990527wjs.5.1361845166348; Mon, 25 Feb 2013 18:19:26 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.74.194 with HTTP; Mon, 25 Feb 2013 18:19:25 -0800 (PST) In-Reply-To: <512C159B.3020707@gmail.com> References: <512A6FFF.2060603@gmail.com> <201302251330.57034.jhb@freebsd.org> <512C159B.3020707@gmail.com> Date: Mon, 25 Feb 2013 18:19:25 -0800 X-Google-Sender-Auth: 5Qj_KNR34GIgUeGOPWZy8mcs9UQ Message-ID: Subject: Re: Fixing X220 Video The Right Way From: Adrian Chadd To: matt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 02:19:28 -0000 On 25 February 2013 17:53, matt wrote: > No, just one. I think that the DSDT is very creative on recent Lenovos > (read: broken). There are multiple video devices defined, with > "functional" calls that nonetheless don't work to actually do anything. > The acpi_get_handle() call in acpi_video returns a handle that has no > active outputs and doesn't have any control over the brightness. The > other path can control brightness. > My T400 has: vgapci0@pci0:0:2:0: class=0x030000 card=0x20e417aa chip=0x2a428086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset Integrated Graphics Controller' class = display subclass = VGA vgapci1@pci0:0:2:1: class=0x038000 card=0x20e417aa chip=0x2a438086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset Integrated Graphics Controller' class = display And I get glitches in xorg on 9.1 when I have multiple windows of different sizes. Adrian From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 02:24:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E81E38FF; Tue, 26 Feb 2013 02:24:48 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8ED5B77E; Tue, 26 Feb 2013 02:24:48 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id kq12so2117315pab.15 for ; Mon, 25 Feb 2013 18:24:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lzTASf+Zy3LZeA+BAvis46C9DXpDv6awjlbIdYXIsrU=; b=b92iCkTTa6Fw+D594Ii6y+b7EX0gHgLShf8C5ThHtSUV7O92dVH+E1VW24k5S0/s9l CEI2NJYn19gkJwQZ2OiKNEGJusEho5u5+KVS9zuyJgnMmRBuzj3h8C9cPLpSSdZyWFOM XZGG8ogkFmDlEro+4IVGqmJgzOU7h6k3ucromPFGxelEdNPYPfaE1eausjLDEQ/kufUJ mfQOOawYRcAPVXFk72tnXozzJK+AvcZAZOi/oRkM1I40YPUZUKEEoAOBc3ozp7UA1NtV becaS9ThzZVhQ0StllItL0NYjalLA7tGJFmioZ0qnCAmibYXdut8de6ikqLeX84wNsVf P2kQ== X-Received: by 10.68.0.170 with SMTP id 10mr21345691pbf.59.1361845482788; Mon, 25 Feb 2013 18:24:42 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id g4sm15725530pax.4.2013.02.25.18.24.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 18:24:41 -0800 (PST) Message-ID: <512C1C8A.5020104@gmail.com> Date: Mon, 25 Feb 2013 18:23:06 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130224 Thunderbird/17.0.3 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Fixing X220 Video The Right Way References: <512A6FFF.2060603@gmail.com> <201302251330.57034.jhb@freebsd.org> <512C159B.3020707@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 02:24:49 -0000 On 02/25/13 18:19, Adrian Chadd wrote: > > My T400 has: > > > vgapci0@pci0:0:2:0: class=0x030000 card=0x20e417aa chip=0x2a428086 > rev=0x07 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Mobile 4 Series Chipset Integrated Graphics Controller' > class = display > subclass = VGA > vgapci1@pci0:0:2:1: class=0x038000 card=0x20e417aa chip=0x2a438086 > rev=0x07 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Mobile 4 Series Chipset Integrated Graphics Controller' > class = display > > And I get glitches in xorg on 9.1 when I have multiple windows of > different sizes. > > > > Adrian > Does acpi_video like either one? Does acpi_get_handle return the same path? Matt From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 02:33:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 77FB0C1A; Tue, 26 Feb 2013 02:33:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by mx1.freebsd.org (Postfix) with ESMTP id C64807D2; Tue, 26 Feb 2013 02:33:16 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ez12so4039618wid.6 for ; Mon, 25 Feb 2013 18:33:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IPI64pSTL/1a92+KftRb0qDWZBPHXrNqPPrcAT8kYQY=; b=UAbpBTTp1JGTYDbvlEjURScub7YeOND6LWgCx9EvNLEe+rXRHwV0eZhRsC+4R+3Mbu yrMk55k9fccu6TDHfW5cgs2fqDHoyiftAO+C959vqSnYuWq3/uVRL2GznbJjLQDVfyIn XDTF7aXtEdAJGn0gSo2415G2tGoRPCKJZ66pFcge+RFhCZqVZqwlHQGEdHAPJ8tKO3iG AmxJXNeN8vS/qY53Oic0gM8PFw/N/M5E3sS9VAFAG9SyMZDY5ieNWpkwottUDqrDRGld 8l7BtGLUQhSQ9KTNYgDHQQnasMPMuxVFvakZTHyR2yr2nywUEJ1jzeQZHGKFFhol/L40 FhDg== MIME-Version: 1.0 X-Received: by 10.194.90.168 with SMTP id bx8mr23011794wjb.59.1361845995658; Mon, 25 Feb 2013 18:33:15 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.74.194 with HTTP; Mon, 25 Feb 2013 18:33:15 -0800 (PST) In-Reply-To: <512C1C8A.5020104@gmail.com> References: <512A6FFF.2060603@gmail.com> <201302251330.57034.jhb@freebsd.org> <512C159B.3020707@gmail.com> <512C1C8A.5020104@gmail.com> Date: Mon, 25 Feb 2013 18:33:15 -0800 X-Google-Sender-Auth: kuHt_VZhfaSdbcx7cpuki_HQ_6A Message-ID: Subject: Re: Fixing X220 Video The Right Way From: Adrian Chadd To: matt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 02:33:17 -0000 [101232] acpi_video0: on vgapci0 found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 And what do I do with acpi_get_handle ? Adrian On 25 February 2013 18:23, matt wrote: > On 02/25/13 18:19, Adrian Chadd wrote: >> >> My T400 has: >> >> >> vgapci0@pci0:0:2:0: class=0x030000 card=0x20e417aa chip=0x2a428086 >> rev=0x07 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Mobile 4 Series Chipset Integrated Graphics Controller' >> class = display >> subclass = VGA >> vgapci1@pci0:0:2:1: class=0x038000 card=0x20e417aa chip=0x2a438086 >> rev=0x07 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Mobile 4 Series Chipset Integrated Graphics Controller' >> class = display >> >> And I get glitches in xorg on 9.1 when I have multiple windows of >> different sizes. >> >> >> >> Adrian >> > Does acpi_video like either one? > Does acpi_get_handle return the same path? > > Matt From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 02:33:24 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 98D5FD3D for ; Tue, 26 Feb 2013 02:33:24 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 720347D6 for ; Tue, 26 Feb 2013 02:33:24 +0000 (UTC) Received: from pool-96-250-5-62.nycmny.fios.verizon.net ([96.250.5.62]:55745 helo=new-host.home) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UAAM7-0001SN-6j for current@freebsd.org; Mon, 25 Feb 2013 21:33:23 -0500 From: George Neville-Neil Content-Type: multipart/signed; boundary="Apple-Mail=_7E3EEBA9-9BC9-4173-B296-6DE15AC472C4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Boot crash with HEAD on Thinkpad X220... Message-Id: <13054114-EE88-44D7-AC3F-2B40CDB87113@neville-neil.com> Date: Mon, 25 Feb 2013 21:33:29 -0500 To: current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 02:33:24 -0000 --Apple-Mail=_7E3EEBA9-9BC9-4173-B296-6DE15AC472C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Howdy, This has been happening since I updated on Saturday. I updated my tree = today (Monday) as well: http://people.freebsd.org/~gnn/X220bootcrash25Feb2013.jpg The system boots and works well enough to connect to the network and = build a new kernel if I use safe mode. Thoughts? Best, George --Apple-Mail=_7E3EEBA9-9BC9-4173-B296-6DE15AC472C4 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.19 (Darwin) iEYEARECAAYFAlEsHvkACgkQYdh2wUQKM9I/pwCgg/y6ZQeTB9zCdmWGE/DJrwsF WrcAoIJDFzz1b+V0PsQyiHSmErbk7VSb =6r7W -----END PGP SIGNATURE----- --Apple-Mail=_7E3EEBA9-9BC9-4173-B296-6DE15AC472C4-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 04:21:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A02D234A; Tue, 26 Feb 2013 04:21:41 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by mx1.freebsd.org (Postfix) with ESMTP id 61D49B22; Tue, 26 Feb 2013 04:21:41 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id kp14so2169636pab.33 for ; Mon, 25 Feb 2013 20:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=mSTINisJwrFDhUim3BTKR5s2ah2QCDmqqmyMQ7K02Us=; b=KO3hIdLdYxVOUY58JMls1K5gyDMEux5isKBlDzWsq2ICkBhpRSwdjXoofLXVvvMfLa mYSe/NLMLX/7CkNhX/i+ZgnMvMzSXcqJ8ecSc9xyb306ZiJ/ZlGaIorV/KS9Q4k/frRt 6Xs2rW3djObf9WyhNjol/j9blewLIbGxFZ2x81Jaxv33kkoMmAC9btLfYMvSEiKoFNIQ lw22squWn092hiUaeO2Iy8icZ2s6K4PbNOmPBPu88cUJBLALUAIB1qzh6Dt6ibnWrexR ys60MF5BEhCEOW3kZbpJBUky8pVVfU4eiEHQEHIf5I6Oq+RU/Cq4u4RQ5PU8OtuuVYAi 1Jyw== X-Received: by 10.68.75.109 with SMTP id b13mr21804107pbw.25.1361852495787; Mon, 25 Feb 2013 20:21:35 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id qf7sm14978316pbb.2.2013.02.25.20.21.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 20:21:34 -0800 (PST) Message-ID: <512C380D.5030506@gmail.com> Date: Mon, 25 Feb 2013 20:20:29 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130224 Thunderbird/17.0.3 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Fixing X220 Video The Right Way References: <512A6FFF.2060603@gmail.com> <201302251330.57034.jhb@freebsd.org> <512C159B.3020707@gmail.com> <512C1C8A.5020104@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 04:21:41 -0000 On 02/25/13 18:33, Adrian Chadd wrote: > [101232] acpi_video0: on vgapci0 > found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 > > And what do I do with acpi_get_handle ? > > > > I threw printfs into acpi_video, not sure if that would work for both vgapci or not. I'm not sure if I wiped out my debug patches yet, I may have a patch. Basically the idea is to figure out which paths in the DSDT are getting attached to the vgapci devices. This dsdt patch from Mitsuru Iwasaki illustrates fixing a similar issue to X220 via a custom dsdt http://people.freebsd.org/~iwasaki/acpi/tpx61.asl.diff It seems like we could either try to find these paths on affected models, or have a tunable override for acpi_video. Matt From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 07:01:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 95DE8119; Tue, 26 Feb 2013 07:01:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id C7AA6140; Tue, 26 Feb 2013 07:01:51 +0000 (UTC) X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 382504828; Tue, 26 Feb 2013 08:01:43 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org, Daniel Eischen Subject: Re: USB not working Date: Tue, 26 Feb 2013 08:02:59 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <201302251539.34465.hselasky@c2i.net> In-Reply-To: X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: "mav@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 07:01:52 -0000 > > This worked - thanks! > > Any chance of getting this to be automatic, without having to > tweak any knobs? Not as I know of. Possibly we could set/clear the route bits when enumeration fails. Feel free to submit patches. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 08:22:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 686D56BD; Tue, 26 Feb 2013 08:22:24 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp5.clear.net.nz (smtp5.clear.net.nz [203.97.33.68]) by mx1.freebsd.org (Postfix) with ESMTP id 230EF3F0; Tue, 26 Feb 2013 08:22:23 +0000 (UTC) Received: from mxin3-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp5.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MIT002XGIJYPZ10@smtp5.clear.net.nz>; Tue, 26 Feb 2013 21:07:17 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin32.paradise.net.nz with ESMTP; Tue, 26 Feb 2013 21:07:13 +1300 Date: Tue, 26 Feb 2013 21:06:51 +1300 From: Andrew Turner Subject: ARM pcpu changes, was Re: [patch] i386 pmap sysmaps_pcpu[] atomic access In-reply-to: <20130225124747.GA21027@ci0.org> To: Olivier Houchard Message-id: <20130226210651.580c46a7@bender> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: <201302201022.29294.jhb@freebsd.org> <201302211043.49906.jhb@freebsd.org> <20130225190920.1b7d348d@bender> <20130225124747.GA21027@ci0.org> Cc: Konstantin Belousov , freebsd-current@freebsd.org, Svatopluk Kraus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 08:22:24 -0000 On Mon, 25 Feb 2013 13:47:47 +0100 Olivier Houchard wrote: > On Mon, Feb 25, 2013 at 07:09:20PM +1300, Andrew Turner wrote: > > On Thu, 21 Feb 2013 10:43:49 -0500 > > John Baldwin wrote: > > > > > On Thursday, February 21, 2013 7:53:52 am Svatopluk Kraus wrote: > > > > On Wed, Feb 20, 2013 at 4:22 PM, John Baldwin > > > > wrote: > > > > > On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus > > > > > wrote: > > > > >> On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov > > > > >> wrote: > > > > >> > On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus > > > > >> > wrote: > > > > >> >> On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov > > > > >> >> wrote: > > > > >> >> Well, I'm taking a part on porting FreeBSD to > > > > >> >> ARM11mpcore. UP case was simple. SMP case is more complex > > > > >> >> and rather new for me. Recently, I was solving a problem > > > > >> >> with PCPU stuff. For example, PCPU_GET is implemented by > > > > >> >> one instruction on i386 arch. So, a need of atomicity > > > > >> >> with respect to interrupts can be overlooked. On > > > > >> >> load-store archs, the implementation which works in SMP > > > > >> >> case is not so simple. And what works in UP case (single > > > > >> >> PCPU), not works in SMP case. Believe me, mysterious and > > > > >> >> sporadic 'mutex not owned' assertions and others ones > > > > >> >> caused by curthreads mess, it takes a while ... > > > > >> > Note that PCPU_GET() is not needed to be atomic. The > > > > >> > reason is that the code which uses its result would not be > > > > >> > atomic (single-instruction or whatever, see below). Thus, > > > > >> > either the preemption should not matter since the action > > > > >> > with the per-cpu data is advisory, as is in the case of > > > > >> > i386 pmap you noted. or some external measures should be > > > > >> > applied in advance to the containing region (which you > > > > >> > proposed, by bracing with sched_pin()). > > > > >> > > > > >> So, it's advisory in the case of i386 pmap... Well, if you > > > > >> can live with that, I can too. > > > > >> > > > > >> > > > > > >> > Also, note that it is not interrupts but preemption which > > > > >> > is concern. > > > > >> > > > > >> Yes and no. In theory, yes, a preemption is a concern. In > > > > >> FreeBSD, however, sched_pin() and critical_enter() and their > > > > >> counterparts are implemented with help of curthread. And > > > > >> curthread definition falls to PCPU_GET(curthread) if not > > > > >> defined in other way. So, curthread should be atomic with > > > > >> respect to interrupts and in general, PCPU_GET() should be > > > > >> too. Note that spinlock_enter() definitions often (always) > > > > >> use curthread too. Anyhow, it's defined in MD code and can > > > > >> be defined for each arch separately. > > > > > > > > > > curthread is a bit magic. :) If you perform a context switch > > > > > during an interrupt (which will change 'curthread') you also > > > > > change your register state. When you resume, the register > > > > > state is also restored. This means that while something like > > > > > 'PCPU_GET(cpuid)' might be stale after you read it, > > > > > 'curthread' never is. However, it is true that actually > > > > > reading curthread has to be atomic. If your read of > > > > > curthread looks like: > > > > > > > > > > mov , r0 > > > > > add , r0 > > > > > ld r0, r1 > > > > > > > > > > Then that will indeed break. Alpha used a fixed register for > > > > > 'pcpu_reg' (as does ia64 IIRC). OTOH, you might also be able > > > > > to depend on the fact that pc_curthread is the first thing in > > > > > 'struct pcpu' (and always will be, you could add a CTASSERT to > > > > > future-proof). In that case, you can remove the 'add' > > > > > instruction and instead just do: > > > > > > > > > > ld , r1 > > > > > > > > > > which is fine. > > > > > > > > Just for the record. There are three extra (coprocessor) > > > > registers per a core in arm11mpcore (armv6k). Unfortunately > > > > only one is Privileged. The other ones are respectively User > > > > Read only and User Read Write. For now, we are using the > > > > Privileged one to store pcpu pointer (curthread is correctly > > > > set during each context switch). Thus, using a coprocessor > > > > register means that reading of curthread is not a single > > > > instruction implementation now. After we figured out the > > > > curthread issue in SMP case, using a fixed (processor) register > > > > for pcpu is an option. Meanwhile, we disable interrupts before > > > > reading of curthread and enable them after. The same is done > > > > for other PCPU stuff. For now we have not stable system enough > > > > for profiling, however, when it will be, it would be > > > > interesting to learn how various implementations of curthread > > > > reading impact system performance. > > > > > > curthread is read _a lot_, so I would expect this to hurt. What > > > we did on Alpha was to use a fixed register for pcpu access, but > > > we used the equivalent of a coprocessor register to also store > > > the value so we could set that fixed register on entry to the > > > kernel (userland was free to use the register for its own > > > purposes). > > > > > > > The current code on ARM is not atomic, it loads the base address of > > the pcpu data from the coprocessor then loads curthread from this > > address. One solution I discussed with Olivier Houchard is to keep > > the data in the coprocessor but to then load it into a dedicated > > register when we enter the kernel. > > > > Reading curthread would then be a single load instruction thanks to > > ARM's ldr using an immediate offset [1], e.g. to load from r12 into > > r1 it would be 'ldr r1, [r12]'. > > > > Wouldn't it be doable to either use the extra coprocessor register for > curthread, setting it when entering the kernel as John suggested, or > just using the privileged one for curthread, and changing get_pcpu() > to be __pcpu[cpuid], and then making sure pcpu accesses are atomic, > either by disabling interrupts or using ldrex/strex ? I take it > curthread (and curpcb, which we can get from curthread) is by far the > most used, and it wouldn't hurt that badly to pessimize the other > pcpu variables ? Does anyone know if it is only curthread that needs to be atomic? If so this should work. Reading the cpuid from the system currently is a single instruction, however it appears the code will need to be reworked for use with multiple levels of affinity, for example when there are clusters of cores the current code will number two cores on different clusters with the same id. I don't think we need to use ldrex/strex to read/write the values, my understanding is the rest should be safe to access without atomic functions. Andrew From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 10:22:19 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DFC44F3D for ; Tue, 26 Feb 2013 10:22:19 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from zcs03.jnb1.cloudseed.co.za (zcs03.jnb1.cloudseed.co.za [41.154.0.139]) by mx1.freebsd.org (Postfix) with ESMTP id 7D42BA0D for ; Tue, 26 Feb 2013 10:22:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTP id 7BF0C2B42F17 for ; Tue, 26 Feb 2013 12:16:11 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs03.jnb1.cloudseed.co.za Received: from zcs03.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs03.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAJa+GdxW2dj for ; Tue, 26 Feb 2013 12:16:10 +0200 (SAST) Received: from clue.co.za (unknown [197.87.27.46]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id C56222B42EF5 for ; Tue, 26 Feb 2013 12:16:10 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=new.clue.co.za) by clue.co.za with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UAHZw-0001in-VS for current@freebsd.org; Tue, 26 Feb 2013 12:16:08 +0200 To: current@freebsd.org Subject: Centrino "Advanced"-N 6235 wireless From: "Ian FREISLICH" X-Attribution: BOFH Date: Tue, 26 Feb 2013 12:16:07 +0200 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 10:22:19 -0000 Hi I have one of these "Advanced" controlers in my laptop. It's up for grabs for an interested developer after this coming week-end. I need to de-solder the w.FL connectors to to put them on a supported non-Intel card to get working wifi. I will replace the on-card connectors with u.FL. iwn0@pci0:2:0:0: class=0x028000 card=0x40608086 chip=0x088e8086 rev=0x24 hdr=0x00 vendor = 'Intel Corporation' device = 'Centrino Advanced-N 6235' class = network Contact me in private email if you're interested. The issues are: 1. Need the latest Intel firmware (iwlwifi-6000g2b-18.168.6.1) to get anything approaching connectivity. 2. The 2.4GHz radio will absolutely not use a 20MHz channel if the AP will do 40MHz. 3. 40MHz channels don't work. 4. Random disconnects every 30 minutes or so requiring a wlan0 destroy/create to recover. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 10:49:12 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 590256F1 for ; Tue, 26 Feb 2013 10:49:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id F0D4AB2B for ; Tue, 26 Feb 2013 10:49:11 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id r6so3367466wey.19 for ; Tue, 26 Feb 2013 02:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ft5KiA8np9HPr9tqVS7XPJ1TpnnRI6vhPnUrQDQjxqw=; b=HtQzDx8weLB6lzWrDQX2/TMt8yORLYTzUHvThaKizFOB+jsxFAv3O3sIWTNG50mDGK dUY1/Iyn3P7wxyLsONbCbtGBK0C9azc2DZLRX0QqFF5LFOXAFi7rIN3kgQwIUL+6HoB2 nBW+5ZH1QwTMYYEzzf3/LeoY77UvPGRq0hvlhfeOZsK6xsVSrIJdCduSYjIQRkGcFxRi W5xk+FG+Xnllg35jhTWfT56QJ4kQOMNZQ7891ZrCMV/KUvbHcDQiYsBzB0qKHRPAmZBe VWks5/oL+XiSPMQr73ngMC6yDo5n/VxAGtXD9xoP8asndOQ5okfqwE0p3v8YRgAXYubK ZLCQ== MIME-Version: 1.0 X-Received: by 10.194.5.137 with SMTP id s9mr24287647wjs.5.1361875751224; Tue, 26 Feb 2013 02:49:11 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.74.194 with HTTP; Tue, 26 Feb 2013 02:49:11 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Feb 2013 02:49:11 -0800 X-Google-Sender-Auth: xFb5rAN6gzCQm1mYVs88eftBmLw Message-ID: Subject: Re: Centrino "Advanced"-N 6235 wireless From: Adrian Chadd To: Ian FREISLICH Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 10:49:12 -0000 Does Linux run stable with this NIC? Adrian On 26 February 2013 02:16, Ian FREISLICH wrote: > Hi > > I have one of these "Advanced" controlers in my laptop. It's up > for grabs for an interested developer after this coming week-end. > I need to de-solder the w.FL connectors to to put them on a supported > non-Intel card to get working wifi. I will replace the on-card > connectors with u.FL. > > iwn0@pci0:2:0:0: class=0x028000 card=0x40608086 chip=0x088e8086 rev=0x24 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Centrino Advanced-N 6235' > class = network > > Contact me in private email if you're interested. > > The issues are: > 1. Need the latest Intel firmware (iwlwifi-6000g2b-18.168.6.1) > to get anything approaching connectivity. > 2. The 2.4GHz radio will absolutely not use a 20MHz channel if the > AP will do 40MHz. > 3. 40MHz channels don't work. > 4. Random disconnects every 30 minutes or so requiring a wlan0 > destroy/create to recover. > > Ian > > -- > Ian Freislich > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 11:39:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C753F2A3 for ; Tue, 26 Feb 2013 11:39:28 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 357ADDAD for ; Tue, 26 Feb 2013 11:39:27 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id ez12so4698137wid.17 for ; Tue, 26 Feb 2013 03:39:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=u1sCx8XHH2zSanW1e6TH41eCGUIluABJcz6P059U6Tw=; b=mReI8+m9XuodKt1LFjFCRYNVJxQXR9qXJvbPNI8qyPgnz+ylFefh3kBp5RanErp2Wo yyt6nZGx9oB1lm534IAiRMZQGBa9MVlC3sCFVAKCXEqBP8iJL4yNgZXRgN/Dmh6HbMKZ LnPnMzy4aJHAyuCLLZTmQOeQZFQsLfkDi2YpcGie3siCkMvfxZHXcOnumZNi71cTGK5m O3OrXGHa1ZW/ZO/vMr9DQUc29s0dmxkGoOHAoaKnV4CN3InhBTVg/K1e8f/dBEjZsw6p zJ4OiktvZyjUUnUe9QKIUuHhaJEMxpIwPKkv5N32rRmlVByUmmlFuvIKZFc+wrSSznuM 4MCQ== MIME-Version: 1.0 X-Received: by 10.194.6.2 with SMTP id w2mr1313521wjw.10.1361878767019; Tue, 26 Feb 2013 03:39:27 -0800 (PST) Received: by 10.194.86.167 with HTTP; Tue, 26 Feb 2013 03:39:26 -0800 (PST) Date: Tue, 26 Feb 2013 14:39:26 +0300 Message-ID: Subject: [patch] Proposal: move getmntopts(3) into libutil From: Sergey Kandaurov To: FreeBSD Current Content-Type: multipart/mixed; boundary=047d7b5d2e2022af2f04d69f1c80 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 11:39:28 -0000 --047d7b5d2e2022af2f04d69f1c80 Content-Type: text/plain; charset=ISO-8859-1 Hi. The functions from sbin/mount/getmntopts.c are used in a bunch of other stuff like mount_* utilities which have to suck them in as their own functions in quite a hackish way. getmntopts.c copies are compiled in to an every utility-consumer instead of being present in one place. Looks like getmntopts.c was brought together with mount_ufs.c in 4.4BSD-Lite. After that other mount_* were converted to use getmntopts(). The utilities consuming getmntopts.c as currently present in HEAD: mount_smbfs fsck_ffs growfs mksnap_ffs mount mount_cd9660 mount_ext2fs mount_fusefs mount_hpfs mount_msdosfs mount_nfs mount_nullfs mount_reiserfs mount_std mount_udf mount_unionfs mount_nwfs mount_portalfs mount_smbfs mountd External mount-like utilities may also have difficulties with building to get getmntopts.c source as this requires /usr/src presence which is in sync with installed world. Look how mount_fusefs from ports compiles: # mount_fusefs needs mntopts.h and getmntopts.c from src/sbin/mount/ The attached patch moves them to the IMHO architecturally more correct place: a separate library -lutil. sbin/mount/mntopts.h -> include/mntopts.h sbin/mount/getmntopts.[3c] -> lib/libutil/getmntopts.[3c] The full list of functions in getmntopts.c: getmntopts() rmslashes() checkpath() build_iovec() build_iovec_argf() This will eventually give them public and documented status. It will also bring back to live its semi-dead man page getmntopts(3) currently disconnected from build, that will force us to update (and use) it which is also a goody. getmntopts.3 was never installed. As a bonus, it will bring us in sync with others BSDs. The attached patch was buildworld-tested and contains only minimal changes; getmntopts(3) updates and other improvements could be made separately. - rearrange files from sbin/mount/ to the new place - update Makefiles's of mount_* to use getmntopts(3) from libutil - #include "mntopts.h" -> #include Well, the include changes should be safe to commit as is. Below is a changelist from svn stat, for convenience 'sake. M contrib/smbfs/mount_smbfs/mount_smbfs.c M include/Makefile A + include/mntopts.h M lib/libutil/Makefile A + lib/libutil/getmntopts.3 A + lib/libutil/getmntopts.c M sbin/fsck_ffs/Makefile M sbin/growfs/Makefile M sbin/mksnap_ffs/Makefile M sbin/mount/Makefile D sbin/mount/getmntopts.3 D sbin/mount/getmntopts.c D sbin/mount/mntopts.h M sbin/mount/mount.c M sbin/mount/mount_fs.c M sbin/mount_cd9660/Makefile M sbin/mount_cd9660/mount_cd9660.c M sbin/mount_ext2fs/Makefile M sbin/mount_ext2fs/mount_ext2fs.c M sbin/mount_fusefs/Makefile M sbin/mount_fusefs/mount_fusefs.c M sbin/mount_hpfs/Makefile M sbin/mount_hpfs/mount_hpfs.c M sbin/mount_msdosfs/Makefile M sbin/mount_msdosfs/mount_msdosfs.c M sbin/mount_nfs/Makefile M sbin/mount_nfs/mount_nfs.c M sbin/mount_ntfs/Makefile M sbin/mount_ntfs/mount_ntfs.c M sbin/mount_nullfs/Makefile M sbin/mount_nullfs/mount_nullfs.c M sbin/mount_reiserfs/Makefile M sbin/mount_reiserfs/mount_reiserfs.c M sbin/mount_std/Makefile M sbin/mount_std/mount_std.c M sbin/mount_udf/Makefile M sbin/mount_udf/mount_udf.c M sbin/mount_unionfs/Makefile M sbin/mount_unionfs/mount_unionfs.c M usr.sbin/mount_nwfs/Makefile M usr.sbin/mount_nwfs/mount_nwfs.c M usr.sbin/mount_portalfs/Makefile M usr.sbin/mount_portalfs/mount_portalfs.c M usr.sbin/mount_smbfs/Makefile M usr.sbin/mountd/Makefile M usr.sbin/mountd/mountd.c -- wbr, pluknet --047d7b5d2e2022af2f04d69f1c80 Content-Type: application/octet-stream; name="getmntopts.patch" Content-Disposition: attachment; filename="getmntopts.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hdmyh1c80 SW5kZXg6IGNvbnRyaWIvc21iZnMvbW91bnRfc21iZnMvbW91bnRfc21iZnMuYwo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0tLSBjb250cmliL3NtYmZzL21vdW50X3NtYmZzL21vdW50X3NtYmZzLmMJKHJldmlzaW9uIDI0 NzE0OSkKKysrIGNvbnRyaWIvc21iZnMvbW91bnRfc21iZnMvbW91bnRfc21iZnMuYwkod29ya2lu ZyBjb3B5KQpAQCAtNDcsNiArNDcsNyBAQAogI2luY2x1ZGUgPHN0ZGxpYi5oPgogI2luY2x1ZGUg PGVyci5oPgogI2luY2x1ZGUgPHN5c2V4aXRzLmg+CisjaW5jbHVkZSA8bW50b3B0cy5oPgogCiAj aW5jbHVkZSA8Y2ZsaWIuaD4KIApAQCAtNTYsOCArNTcsNiBAQAogCiAjaW5jbHVkZSA8ZnMvc21i ZnMvc21iZnMuaD4KIAotI2luY2x1ZGUgIm1udG9wdHMuaCIKLQogc3RhdGljIGNoYXIgbW91bnRf cG9pbnRbTUFYUEFUSExFTiArIDFdOwogc3RhdGljIHZvaWQgdXNhZ2Uodm9pZCk7CiAKSW5kZXg6 IGluY2x1ZGUvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gaW5jbHVkZS9NYWtlZmlsZQkocmV2aXNp b24gMjQ3MTQ5KQorKysgaW5jbHVkZS9NYWtlZmlsZQkod29ya2luZyBjb3B5KQpAQCAtMTMsOCAr MTMsOCBAQAogCWZ0cy5oIGZ0dy5oIGdldG9wdC5oIGdsb2IuaCBncnAuaCBnc3NhcGkuaCBcCiAJ aWVlZWZwLmggaWZhZGRycy5oIFwKIAlpbnR0eXBlcy5oIGlzbzY0Ni5oIGtlbnYuaCBsYW5naW5m by5oIGxpYmdlbi5oIGxpbWl0cy5oIGxpbmsuaCBcCi0JbG9jYWxlLmggbWFsbG9jLmggbWFsbG9j X25wLmggbWVtb3J5LmggbW9uZXRhcnkuaCBtcG9vbC5oIG1xdWV1ZS5oIFwKLQluZGJtLmggbmV0 Y29uZmlnLmggXAorCWxvY2FsZS5oIG1hbGxvYy5oIG1hbGxvY19ucC5oIG1lbW9yeS5oIG1udG9w dHMuaCBcCisJbW9uZXRhcnkuaCBtcG9vbC5oIG1xdWV1ZS5oIG5kYm0uaCBuZXRjb25maWcuaCBc CiAJbmV0ZGIuaCBubF90eXBlcy5oIG5saXN0LmggbnNzLmggbnNzd2l0Y2guaCBwYXRocy5oIFwK IAlwcmludGYuaCBwcm9jX3NlcnZpY2UuaCBwdGhyZWFkLmggXAogCXB0aHJlYWRfbnAuaCBwd2Qu aCByYW5saWIuaCByZWFkcGFzc3BocmFzZS5oIHJlZ2V4LmggXApJbmRleDogbGliL2xpYnV0aWwv TWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQotLS0gbGliL2xpYnV0aWwvTWFrZWZpbGUJKHJldmlzaW9uIDI0 NzE0OSkKKysrIGxpYi9saWJ1dGlsL01ha2VmaWxlCSh3b3JraW5nIGNvcHkpCkBAIC04LDcgKzgs OCBAQAogTElCPQl1dGlsCiBTSExJQl9NQUpPUj0gOQogCi1TUkNTPQlfc2VjdXJlX3BhdGguYyBh dXRoLmMgZXhwYW5kX251bWJlci5jIGZsb3Blbi5jIGZwYXJzZWxuLmMgZ3JfdXRpbC5jIFwKK1NS Q1M9CV9zZWN1cmVfcGF0aC5jIGF1dGguYyBleHBhbmRfbnVtYmVyLmMgZmxvcGVuLmMgZnBhcnNl bG4uYyBcCisJZ2V0bW50b3B0cy5jIGdyX3V0aWwuYyBcCiAJaGV4ZHVtcC5jIGh1bWFuaXplX251 bWJlci5jIGtpbmZvX2dldGZpbGUuYyBraW5mb19nZXRmaWxlLmMgXAogCWtpbmZvX2dldGFsbHBy b2MuYyBraW5mb19nZXRwcm9jLmMga2luZm9fZ2V0dm1tYXAuYyBrbGQuYyBcCiAJbG9naW5fYXV0 aC5jIGxvZ2luX2NhcC5jIFwKQEAgLTI1LDcgKzI2LDcgQEAKIAogQ0ZMQUdTKz0gLUkkey5DVVJE SVJ9IC1JJHsuQ1VSRElSfS8uLi9saWJjL2dlbi8KIAotTUFOKz0JZXhwYW5kX251bWJlci4zIGZs b3Blbi4zIGZwYXJzZWxuLjMgaGV4ZHVtcC4zIFwKK01BTis9CWV4cGFuZF9udW1iZXIuMyBmbG9w ZW4uMyBmcGFyc2Vsbi4zIGdldG1udG9wdHMuMyBoZXhkdW1wLjMgXAogCWh1bWFuaXplX251bWJl ci4zIGtpbmZvX2dldGFsbHByb2MuMyBraW5mb19nZXRmaWxlLjMgXAogCWtpbmZvX2dldHByb2Mu MyBraW5mb19nZXR2bW1hcC4zIGtsZC4zIGxvZ2luX2F1dGguMyBsb2dpbl9jYXAuMyBcCiAJbG9n aW5fY2xhc3MuMyBsb2dpbl9vay4zIGxvZ2luX3RpbWVzLjMgbG9naW5fdHR5LjMgcGlkZmlsZS4z IFwKSW5kZXg6IHNiaW4vZnNja19mZnMvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9mc2Nr X2Zmcy9NYWtlZmlsZQkocmV2aXNpb24gMjQ3MjU2KQorKysgc2Jpbi9mc2NrX2Zmcy9NYWtlZmls ZQkod29ya2luZyBjb3B5KQpAQCAtNywxMiArNywxMiBAQAogTUFOPQlmc2NrX2Zmcy44CiBNTElO S1M9CWZzY2tfZmZzLjggZnNja191ZnMuOCBmc2NrX2Zmcy44IGZzY2tfNC4yYnNkLjgKIFNSQ1M9 CWRpci5jIGVhLmMgZnN1dGlsLmMgaW5vZGUuYyBtYWluLmMgcGFzczEuYyBwYXNzMWIuYyBwYXNz Mi5jIHBhc3MzLmMgXAotCXBhc3M0LmMgcGFzczUuYyBzZXR1cC5jIHN1ai5jIHV0aWxpdGllcy5j IGdqb3VybmFsLmMgZ2V0bW50b3B0cy5jCi1EUEFERD0JJHtMSUJVRlN9Ci1MREFERD0JLWx1ZnMK KwlwYXNzNC5jIHBhc3M1LmMgc2V0dXAuYyBzdWouYyB1dGlsaXRpZXMuYyBnam91cm5hbC5jCitE UEFERD0JJHtMSUJVRlN9ICR7TElCVVRJTH0KK0xEQUREPQktbHVmcyAtbHV0aWwKIFdBUk5TPz0J MgotQ0ZMQUdTKz0gLUkkey5DVVJESVJ9IC1JJHsuQ1VSRElSfS8uLi9tb3VudAorQ0ZMQUdTKz0g LUkkey5DVVJESVJ9CiAKLS5QQVRIOgkkey5DVVJESVJ9Ly4uLy4uL3N5cy91ZnMvZmZzICR7LkNV UkRJUn0vLi4vbW91bnQKKy5QQVRIOgkkey5DVVJESVJ9Ly4uLy4uL3N5cy91ZnMvZmZzCiAKIC5p bmNsdWRlIDxic2QucHJvZy5taz4KSW5kZXg6IHNiaW4vZ3Jvd2ZzL01ha2VmaWxlCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIHNiaW4vZ3Jvd2ZzL01ha2VmaWxlCShyZXZpc2lvbiAyNDcxNDkpCisrKyBzYmluL2dy b3dmcy9NYWtlZmlsZQkod29ya2luZyBjb3B5KQpAQCAtNiwxMiArNiw5IEBACiAKICNHRlNEQkc9 CiAKLS5QQVRIOgkkey5DVVJESVJ9Ly4uL21vdW50Ci0KIFBST0c9ICAgZ3Jvd2ZzCi1TUkNTPSAg IGdyb3dmcy5jIGdldG1udG9wdHMuYworU1JDUz0gICBncm93ZnMuYwogTUFOPQlncm93ZnMuOAot Q0ZMQUdTKz0tSSR7LkNVUkRJUn0vLi4vbW91bnQKIAogLmlmIGRlZmluZWQoR0ZTREJHKQogU1JD Uys9ICBkZWJ1Zy5jCkluZGV4OiBzYmluL21rc25hcF9mZnMvTWFrZWZpbGUKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gc2Jpbi9ta3NuYXBfZmZzL01ha2VmaWxlCShyZXZpc2lvbiAyNDcxNDkpCisrKyBzYmluL21r c25hcF9mZnMvTWFrZWZpbGUJKHdvcmtpbmcgY29weSkKQEAgLTMsMTIgKzMsMTMgQEAKIC5QQVRI Ogkkey5DVVJESVJ9Ly4uL21vdW50CiAKIFBST0c9CW1rc25hcF9mZnMKLVNSQ1M9CW1rc25hcF9m ZnMuYyBnZXRtbnRvcHRzLmMKIE1BTj0JbWtzbmFwX2Zmcy44CiAKIFdBUk5TPz0JMgotQ0ZMQUdT Kz0tSSR7LkNVUkRJUn0vLi4vbW91bnQKIAorRFBBREQ9CSR7TElCVVRJTH0KK0xEQUREPQktbHV0 aWwKKwogLmlmIGRlZmluZWQoTk9TVUlEKQogQklOTU9ERT01NTAKIC5lbHNlCkluZGV4OiBzYmlu L21vdW50L01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHNiaW4vbW91bnQvTWFrZWZpbGUJKHJldmlz aW9uIDI0NzE0OSkKKysrIHNiaW4vbW91bnQvTWFrZWZpbGUJKHdvcmtpbmcgY29weSkKQEAgLTIs OSArMiw4IEBACiAjICRGcmVlQlNEJAogCiBQUk9HPQltb3VudAotU1JDUz0JbW91bnQuYyBtb3Vu dF9mcy5jIGdldG1udG9wdHMuYyB2ZnNsaXN0LmMKK1NSQ1M9CW1vdW50LmMgbW91bnRfZnMuYyB2 ZnNsaXN0LmMKIE1BTj0JbW91bnQuOAotIyBXZSBkbyBOT1QgaW5zdGFsbCB0aGUgZ2V0bW50b3B0 cy4zIG1hbiBwYWdlLgogCiBEUEFERD0JJHtMSUJVVElMfQogTERBREQ9CS1sdXRpbApJbmRleDog c2Jpbi9tb3VudC9nZXRtbnRvcHRzLjMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9tb3VudC9nZXRtbnRv cHRzLjMJKHJldmlzaW9uIDI0NzE0OSkKKysrIHNiaW4vbW91bnQvZ2V0bW50b3B0cy4zCSh3b3Jr aW5nIGNvcHkpCkBAIC0xLDE4MSArMCwwIEBACi0uXCIgQ29weXJpZ2h0IChjKSAxOTk0Ci0uXCIJ VGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gIEFsbCByaWdodHMg cmVzZXJ2ZWQuCi0uXCIKLS5cIiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQg YmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKLS5cIiBtb2RpZmljYXRpb24sIGFyZSBwZXJt aXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKLS5cIiBhcmUgbWV0 OgotLlwiIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUg YWJvdmUgY29weXJpZ2h0Ci0uXCIgICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBh bmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgotLlwiIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBi aW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0Ci0uXCIgICAgbm90 aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVy IGluIHRoZQotLlwiICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92 aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCi0uXCIgNC4gTmVpdGhlciB0aGUgbmFtZSBvZiB0 aGUgVW5pdmVyc2l0eSBub3IgdGhlIG5hbWVzIG9mIGl0cyBjb250cmlidXRvcnMKLS5cIiAgICBt YXkgYmUgdXNlZCB0byBlbmRvcnNlIG9yIHByb21vdGUgcHJvZHVjdHMgZGVyaXZlZCBmcm9tIHRo aXMgc29mdHdhcmUKLS5cIiAgICB3aXRob3V0IHNwZWNpZmljIHByaW9yIHdyaXR0ZW4gcGVybWlz c2lvbi4KLS5cIgotLlwiIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIFJFR0VOVFMg QU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECi0uXCIgQU5ZIEVYUFJFU1MgT1IgSU1QTElF RCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCi0uXCIgSU1Q TElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJU SUNVTEFSIFBVUlBPU0UKLS5cIiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRI RSBSRUdFTlRTIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKLS5cIiBGT1IgQU5ZIERJUkVDVCwg SU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElB TAotLlwiIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVO VCBPRiBTVUJTVElUVVRFIEdPT0RTCi0uXCIgT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRB LCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pCi0uXCIgSE9XRVZFUiBDQVVT RUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBT VFJJQ1QKLS5cIiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9U SEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCi0uXCIgT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBT T0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRgotLlwiIFNVQ0gg REFNQUdFLgotLlwiCi0uXCIJQCgjKWdldG1udG9wdHMuMwk4LjMgKEJlcmtlbGV5KSAzLzMwLzk1 Ci0uXCIgJEZyZWVCU0QkCi0uXCIKLS5EZCBGZWJydWFyeSAxNywgMjAwOAotLkR0IEdFVE1OVE9Q VFMgMwotLk9zCi0uU2ggTkFNRQotLk5tIGdldG1udG9wdHMKLS5OZCBzY2FuIG1vdW50IG9wdGlv bnMKLS5TaCBTWU5PUFNJUwotLkZkICNpbmNsdWRlIFwmIm1udG9wdHMuaCIKLS5GdCB2b2lkCi0u Rm8gZ2V0bW50b3B0cwotLkZhICJjb25zdCBjaGFyICpvcHRpb25zIiAiY29uc3Qgc3RydWN0IG1u dG9wdCAqbW9wdHMiCi0uRmEgImludCAqZmxhZ3AiICJpbnQgKmFsdGZsYWdwIgotLkZjCi0uU2gg REVTQ1JJUFRJT04KLVRoZQotLkZuIGdldG1udG9wdHMKLWZ1bmN0aW9uIHRha2VzIGEgY29tbWEg c2VwYXJhdGVkIG9wdGlvbiBsaXN0IGFuZCBhIGxpc3QKLW9mIHZhbGlkIG9wdGlvbiBuYW1lcywg YW5kIGNvbXB1dGVzIHRoZSBiaXRtYXNrCi1jb3JyZXNwb25kaW5nIHRvIHRoZSByZXF1ZXN0ZWQg c2V0IG9mIG9wdGlvbnMuCi0uUHAKLVRoZSBzdHJpbmcKLS5GYSBvcHRpb25zCi1pcyBicm9rZW4g ZG93biBpbnRvIGEgc2VxdWVuY2Ugb2YgY29tbWEgc2VwYXJhdGVkIHRva2Vucy4KLUVhY2ggdG9r ZW4gaXMgbG9va2VkIHVwIGluIHRoZSB0YWJsZSBkZXNjcmliZWQgYnkKLS5GYSBtb3B0cwotYW5k IHRoZSBiaXRzIGluCi10aGUgd29yZCByZWZlcmVuY2VkIGJ5IGVpdGhlcgotLkZhIGZsYWdwCi1v cgotLkZhIGFsdGZsYWdwCi0oZGVwZW5kaW5nIG9uIHRoZQotLlZhIG1fYWx0bG9jCi1maWVsZCBv ZiB0aGUgb3B0aW9uJ3MgdGFibGUgZW50cnkpCi1hcmUgdXBkYXRlZC4KLVRoZSBmbGFnIHdvcmRz IGFyZSBub3QgaW5pdGlhbGl6ZWQgYnkKLS5GbiBnZXRtbnRvcHRzIC4KLVRoZSB0YWJsZSwKLS5G YSBtb3B0cyAsCi1oYXMgdGhlIGZvbGxvd2luZyBmb3JtYXQ6Ci0uQmQgLWxpdGVyYWwKLXN0cnVj dCBtbnRvcHQgewotCWNoYXIgKm1fb3B0aW9uOwkJLyogb3B0aW9uIG5hbWUgKi8KLQlpbnQgbV9p bnZlcnNlOwkJLyogaXMgdGhpcyBhIG5lZ2F0aXZlIG9wdGlvbiwgZS5nLiwgImRldiIgKi8KLQlp bnQgbV9mbGFnOwkJLyogYml0IHRvIHNldCwgZS5nLiwgTU5UX1JET05MWSAqLwotCWludCBtX2Fs dGxvYzsJCS8qIG5vbi16ZXJvIHRvIHVzZSBhbHRmbGFncCByYXRoZXIgdGhhbiBmbGFncCAqLwot fTsKLS5FZAotLlBwCi1UaGUgbWVtYmVycyBvZiB0aGlzIHN0cnVjdHVyZSBhcmU6Ci0uQmwgLXRh ZyAtd2lkdGggbV9pbnZlcnNlCi0uSXQgVmEgbV9vcHRpb24KLXRoZSBvcHRpb24gbmFtZSwKLWZv ciBleGFtcGxlCi0uRHEgTGkgc3VpZCAuCi0uSXQgVmEgbV9pbnZlcnNlCi10ZWxscwotLkZuIGdl dG1udG9wdHMKLXRoYXQgdGhlIG5hbWUgaGFzIHRoZSBpbnZlcnNlIG1lYW5pbmcgb2YgdGhlCi1i aXQuCi1Gb3IgZXhhbXBsZSwKLS5EcSBMaSBzdWlkCi1pcyB0aGUgc3RyaW5nLCB3aGVyZWFzIHRo ZQotbW91bnQgZmxhZyBpcwotLkR2IE1OVF9OT1NVSUQgLgotSW4gdGhpcyBjYXNlLCB0aGUgc2Vu c2Ugb2YgdGhlIHN0cmluZyBhbmQgdGhlIGZsYWcKLWFyZSBpbnZlcnRlZCwgc28gdGhlCi0uVmEg bV9pbnZlcnNlCi1mbGFnIHNob3VsZCBiZSBzZXQuCi0uSXQgVmEgbV9mbGFnCi10aGUgdmFsdWUg b2YgdGhlIGJpdCB0byBiZSBzZXQgb3IgY2xlYXJlZCBpbgotdGhlIGZsYWcgd29yZCB3aGVuIHRo ZSBvcHRpb24gaXMgcmVjb2duaXplZC4KLVRoZSBiaXQgaXMgc2V0IHdoZW4gdGhlIG9wdGlvbiBp cyBkaXNjb3ZlcmVkLAotYnV0IGNsZWFyZWQgaWYgdGhlIG9wdGlvbiBuYW1lIHdhcyBwcmVjZWRl ZAotYnkgdGhlIGxldHRlcnMKLS5EcSBMaSBubyAuCi1UaGUKLS5WYSBtX2ludmVyc2UKLWZsYWcg Y2F1c2VzIHRoZXNlIHR3byBvcGVyYXRpb25zIHRvIGJlIHJldmVyc2VkLgotLkl0IFZhIG1fYWx0 bG9jCi10aGUgYml0IHNob3VsZCBiZSBzZXQgb3IgY2xlYXJlZCBpbgotLkZhIGFsdGZsYWdwCi1y YXRoZXIgdGhhbgotLkZhIGZsYWdwIC4KLS5FbAotLlBwCi1FYWNoIG9mIHRoZSB1c2VyIHZpc2li bGUKLS5EdiBNTlRfCi1mbGFncyBoYXMgYSBjb3JyZXNwb25kaW5nCi0uRHYgTU9QVF8KLW1hY3Jv IHdoaWNoIGRlZmluZXMgYW4gYXBwcm9wcmlhdGUKLS5WdCAic3RydWN0IG1udG9wdCIKLWVudHJ5 LgotVG8gc2ltcGxpZnkgdGhlIHByb2dyYW0gaW50ZXJmYWNlIGFuZCBlbnN1cmUgY29uc2lzdGVu Y3kgYWNyb3NzIGFsbAotcHJvZ3JhbXMsIGEgZ2VuZXJhbCBwdXJwb3NlIG1hY3JvLAotLkR2IE1P UFRfU1RET1BUUyAsCi1pcyBkZWZpbmVkIHdoaWNoCi1jb250YWlucyBhbiBlbnRyeSBmb3IgYWxs IHRoZSBnZW5lcmljIFZGUyBvcHRpb25zLgotSW4gYWRkaXRpb24sIHRoZSBtYWNyb3MKLS5EdiBN T1BUX0ZPUkNFCi1hbmQKLS5EdiBNT1BUX1VQREFURQotZXhpc3QgdG8gZW5hYmxlIHRoZQotLkR2 IE1OVF9GT1JDRQotYW5kCi0uRHYgTU5UX1VQREFURQotZmxhZ3MgdG8gYmUgc2V0LgotRmluYWxs eSwgdGhlIHRhYmxlIG11c3QgYmUgdGVybWluYXRlZCBieSBhbiBlbnRyeSB3aXRoIGEKLS5EdiBO VUxMCi1maXJzdCBlbGVtZW50LgotLlNoIEVYQU1QTEVTCi1Nb3N0IGNvbW1hbmRzIHdpbGwgdXNl IHRoZSBzdGFuZGFyZCBvcHRpb24gc2V0LgotTG9jYWwgZmlsZSBzeXN0ZW1zIHdoaWNoIHN1cHBv cnQgdGhlCi0uRHYgTU5UX1VQREFURQotZmxhZywgd291bGQgYWxzbyBoYXZlIGFuCi0uRHYgTU9Q VF9VUERBVEUKLWVudHJ5LgotVGhpcyBjYW4gYmUgZGVjbGFyZWQgYW5kIHVzZWQgYXMgZm9sbG93 czoKLS5CZCAtbGl0ZXJhbAotI2luY2x1ZGUgIm1udG9wdHMuaCIKLQotc3RydWN0IG1udG9wdCBt b3B0c1tdID0gewotCU1PUFRfU1RET1BUUywKLQlNT1BUX1VQREFURSwKLQl7IE5VTEwgfQotfTsK LQotCS4uLgotCW1udGZsYWdzID0gbW50YWx0ZmxhZ3MgPSAwOwotCS4uLgotCWdldG1udG9wdHMo b3B0aW9ucywgbW9wdHMsICZtbnRmbGFncywgJm1udGFsdGZsYWdzKTsKLQkuLi4KLS5FZAotLlNo IERJQUdOT1NUSUNTCi1JZiB0aGUgZXh0ZXJuYWwgaW50ZWdlciB2YXJpYWJsZQotLlZhIGdldG1u dF9zaWxlbnQKLWlzIHplcm8sIHRoZW4gdGhlCi0uRm4gZ2V0bW50b3B0cwotZnVuY3Rpb24gZGlz cGxheXMgYW4gZXJyb3IgbWVzc2FnZSBhbmQgZXhpdHMgaWYgYW4KLXVucmVjb2duaXplZCBvcHRp b24gaXMgZW5jb3VudGVyZWQuCi1PdGhlcndpc2UgdW5yZWNvZ25pemVkIG9wdGlvbnMgYXJlIHNp bGVudGx5IGlnbm9yZWQuCi1CeSBkZWZhdWx0Ci0uVmEgZ2V0bW50X3NpbGVudAotaXMgemVyby4K LS5TaCBTRUUgQUxTTwotLlhyIGVyciAzICwKLS5YciBtb3VudCA4Ci0uU2ggSElTVE9SWQotVGhl Ci0uRm4gZ2V0bW50b3B0cwotZnVuY3Rpb24gYXBwZWFyZWQgaW4KLS5CeCA0LjQgLgpJbmRleDog c2Jpbi9tb3VudC9nZXRtbnRvcHRzLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9tb3VudC9nZXRtbnRv cHRzLmMJKHJldmlzaW9uIDI0NzE0OSkKKysrIHNiaW4vbW91bnQvZ2V0bW50b3B0cy5jCSh3b3Jr aW5nIGNvcHkpCkBAIC0xLDE4MyArMCwwIEBACi0vKi0KLSAqIENvcHlyaWdodCAoYykgMTk5NAot ICoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gIEFsbCByaWdo dHMgcmVzZXJ2ZWQuCi0gKgotICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5k IGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0Ci0gKiBtb2RpZmljYXRpb24sIGFyZSBwZXJt aXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKLSAqIGFyZSBtZXQ6 Ci0gKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFi b3ZlIGNvcHlyaWdodAotICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQg dGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgotICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFy eSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKLSAqICAgIG5vdGljZSwg dGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0 aGUKLSAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3 aXRoIHRoZSBkaXN0cmlidXRpb24uCi0gKiA0LiBOZWl0aGVyIHRoZSBuYW1lIG9mIHRoZSBVbml2 ZXJzaXR5IG5vciB0aGUgbmFtZXMgb2YgaXRzIGNvbnRyaWJ1dG9ycwotICogICAgbWF5IGJlIHVz ZWQgdG8gZW5kb3JzZSBvciBwcm9tb3RlIHByb2R1Y3RzIGRlcml2ZWQgZnJvbSB0aGlzIHNvZnR3 YXJlCi0gKiAgICB3aXRob3V0IHNwZWNpZmljIHByaW9yIHdyaXR0ZW4gcGVybWlzc2lvbi4KLSAq Ci0gKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBSRUdFTlRTIEFORCBDT05UUklC VVRPUlMgYGBBUyBJUycnIEFORAotICogQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVT LCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCi0gKiBJTVBMSUVEIFdBUlJBTlRJ RVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9T RQotICogQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgUkVHRU5UUyBPUiBD T05UUklCVVRPUlMgQkUgTElBQkxFCi0gKiBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lE RU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTAotICogREFNQUdFUyAo SU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUg R09PRFMKLSAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1Ig QlVTSU5FU1MgSU5URVJSVVBUSU9OKQotICogSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVP UlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QKLSAqIExJQUJJTElU WSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElO IEFOWSBXQVkKLSAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURW SVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKLSAqIFNVQ0ggREFNQUdFLgotICovCi0KLSNpZiAw Ci0jaWZuZGVmIGxpbnQKLXN0YXRpYyBjaGFyIHNjY3NpZFtdID0gIkAoIylnZXRtbnRvcHRzLmMJ OC4zIChCZXJrZWxleSkgMy8yOS85NSI7Ci0jZW5kaWYgLyogbm90IGxpbnQgKi8KLSNlbmRpZgot I2luY2x1ZGUgPHN5cy9jZGVmcy5oPgotX19GQlNESUQoIiRGcmVlQlNEJCIpOwotCi0jaW5jbHVk ZSA8c3lzL3BhcmFtLmg+Ci0jaW5jbHVkZSA8c3lzL21vdW50Lmg+Ci0jaW5jbHVkZSA8c3lzL3N0 YXQuaD4KLSNpbmNsdWRlIDxzeXMvdWlvLmg+Ci0KLSNpbmNsdWRlIDxlcnIuaD4KLSNpbmNsdWRl IDxlcnJuby5oPgotI2luY2x1ZGUgPHN0ZGFyZy5oPgotI2luY2x1ZGUgPHN0ZGlvLmg+Ci0jaW5j bHVkZSA8c3RkbGliLmg+Ci0jaW5jbHVkZSA8c3RyaW5nLmg+Ci0KLSNpbmNsdWRlICJtbnRvcHRz LmgiCi0KLWludCBnZXRtbnRfc2lsZW50ID0gMDsKLQotdm9pZAotZ2V0bW50b3B0cyhjb25zdCBj aGFyICpvcHRpb25zLCBjb25zdCBzdHJ1Y3QgbW50b3B0ICptMCwgaW50ICpmbGFncCwKLQlpbnQg KmFsdGZsYWdwKQotewotCWNvbnN0IHN0cnVjdCBtbnRvcHQgKm07Ci0JaW50IG5lZ2F0aXZlLCBs ZW47Ci0JY2hhciAqb3B0LCAqb3B0YnVmLCAqcDsKLQlpbnQgKnRoaXNmbGFncDsKLQotCS8qIENv cHkgb3B0aW9uIHN0cmluZywgc2luY2UgaXQgaXMgYWJvdXQgdG8gYmUgdG9ybiBhc3VuZGVyLi4u ICovCi0JaWYgKChvcHRidWYgPSBzdHJkdXAob3B0aW9ucykpID09IE5VTEwpCi0JCWVycigxLCBO VUxMKTsKLQotCWZvciAob3B0ID0gb3B0YnVmOyAob3B0ID0gc3RydG9rKG9wdCwgIiwiKSkgIT0g TlVMTDsgb3B0ID0gTlVMTCkgewotCQkvKiBDaGVjayBmb3IgIm5vIiBwcmVmaXguICovCi0JCWlm IChvcHRbMF0gPT0gJ24nICYmIG9wdFsxXSA9PSAnbycpIHsKLQkJCW5lZ2F0aXZlID0gMTsKLQkJ CW9wdCArPSAyOwotCQl9IGVsc2UKLQkJCW5lZ2F0aXZlID0gMDsKLQotCQkvKgotCQkgKiBmb3Ig b3B0aW9ucyB3aXRoIGFzc2lnbm1lbnRzIGluIHRoZW0gKGllLiBxdW90YXMpCi0JCSAqIGlnbm9y ZSB0aGUgYXNzaWdubWVudCBhcyBpdCdzIGhhbmRsZWQgZWxzZXdoZXJlCi0JCSAqLwotCQlwID0g c3RyY2hyKG9wdCwgJz0nKTsKLQkJaWYgKHAgIT0gTlVMTCkKLQkJCSAqKytwID0gJ1wwJzsKLQot CQkvKiBTY2FuIG9wdGlvbiB0YWJsZS4gKi8KLQkJZm9yIChtID0gbTA7IG0tPm1fb3B0aW9uICE9 IE5VTEw7ICsrbSkgewotCQkJbGVuID0gc3RybGVuKG0tPm1fb3B0aW9uKTsKLQkJCWlmIChzdHJu Y2FzZWNtcChvcHQsIG0tPm1fb3B0aW9uLCBsZW4pID09IDApCi0JCQkJaWYgKG9wdFtsZW5dID09 ICdcMCcgfHwgb3B0W2xlbl0gPT0gJz0nKQotCQkJCQlicmVhazsKLQkJfQotCi0JCS8qIFNhdmUg ZmxhZywgb3IgZmFpbCBpZiBvcHRpb24gaXMgbm90IHJlY29nbml6ZWQuICovCi0JCWlmIChtLT5t X29wdGlvbikgewotCQkJdGhpc2ZsYWdwID0gbS0+bV9hbHRsb2MgPyBhbHRmbGFncCA6IGZsYWdw OwotCQkJaWYgKG5lZ2F0aXZlID09IG0tPm1faW52ZXJzZSkKLQkJCQkqdGhpc2ZsYWdwIHw9IG0t Pm1fZmxhZzsKLQkJCWVsc2UKLQkJCQkqdGhpc2ZsYWdwICY9IH5tLT5tX2ZsYWc7Ci0JCX0gZWxz ZSBpZiAoIWdldG1udF9zaWxlbnQpIHsKLQkJCWVycngoMSwgIi1vICVzOiBvcHRpb24gbm90IHN1 cHBvcnRlZCIsIG9wdCk7Ci0JCX0KLQl9Ci0KLQlmcmVlKG9wdGJ1Zik7Ci19Ci0KLXZvaWQKLXJt c2xhc2hlcyhjaGFyICpycnBpbiwgY2hhciAqcnJwb3V0KQotewotCWNoYXIgKnJycG91dHN0YXJ0 OwotCi0JKnJycG91dCA9ICpycnBpbjsKLQlmb3IgKHJycG91dHN0YXJ0ID0gcnJwb3V0OyAqcnJw aW4gIT0gJ1wwJzsgKnJycG91dCsrID0gKnJycGluKyspIHsKLQotCQkvKiBza2lwIGFsbCBkb3Vi bGUgc2xhc2hlcyAqLwotCQl3aGlsZSAoKnJycGluID09ICcvJyAmJiAqKHJycGluICsgMSkgPT0g Jy8nKQotCQkJIHJycGluKys7Ci0JfQotCi0JLyogcmVtb3ZlIHRyYWlsaW5nIHNsYXNoIGlmIG5l Y2Vzc2FyeSAqLwotCWlmIChycnBvdXQgLSBycnBvdXRzdGFydCA+IDEgJiYgKihycnBvdXQgLSAx KSA9PSAnLycpCi0JCSoocnJwb3V0IC0gMSkgPSAnXDAnOwotCWVsc2UKLQkJKnJycG91dCA9ICdc MCc7Ci19Ci0KLWludAotY2hlY2twYXRoKGNvbnN0IGNoYXIgKnBhdGgsIGNoYXIgKnJlc29sdmVk KQotewotCXN0cnVjdCBzdGF0IHNiOwotCi0JaWYgKHJlYWxwYXRoKHBhdGgsIHJlc29sdmVkKSA9 PSBOVUxMIHx8IHN0YXQocmVzb2x2ZWQsICZzYikgIT0gMCkKLQkJcmV0dXJuICgxKTsKLQlpZiAo IVNfSVNESVIoc2Iuc3RfbW9kZSkpIHsKLQkJZXJybm8gPSBFTk9URElSOwotCQlyZXR1cm4gKDEp OwotCX0KLQlyZXR1cm4gKDApOwotfQotCi12b2lkCi1idWlsZF9pb3ZlYyhzdHJ1Y3QgaW92ZWMg Kippb3YsIGludCAqaW92bGVuLCBjb25zdCBjaGFyICpuYW1lLCB2b2lkICp2YWwsCi0JICAgIHNp emVfdCBsZW4pCi17Ci0JaW50IGk7Ci0KLQlpZiAoKmlvdmxlbiA8IDApCi0JCXJldHVybjsKLQlp ID0gKmlvdmxlbjsKLQkqaW92ID0gcmVhbGxvYygqaW92LCBzaXplb2YgKippb3YgKiAoaSArIDIp KTsKLQlpZiAoKmlvdiA9PSBOVUxMKSB7Ci0JCSppb3ZsZW4gPSAtMTsKLQkJcmV0dXJuOwotCX0K LQkoKmlvdilbaV0uaW92X2Jhc2UgPSBzdHJkdXAobmFtZSk7Ci0JKCppb3YpW2ldLmlvdl9sZW4g PSBzdHJsZW4obmFtZSkgKyAxOwotCWkrKzsKLQkoKmlvdilbaV0uaW92X2Jhc2UgPSB2YWw7Ci0J aWYgKGxlbiA9PSAoc2l6ZV90KS0xKSB7Ci0JCWlmICh2YWwgIT0gTlVMTCkKLQkJCWxlbiA9IHN0 cmxlbih2YWwpICsgMTsKLQkJZWxzZQotCQkJbGVuID0gMDsKLQl9Ci0JKCppb3YpW2ldLmlvdl9s ZW4gPSAoaW50KWxlbjsKLQkqaW92bGVuID0gKytpOwotfQotCi0vKgotICogVGhpcyBmdW5jdGlv biBpcyBuZWVkZWQgZm9yIGNvbXBhdGliaWxpdHkgd2l0aCBwYXJhbWV0ZXJzCi0gKiB3aGljaCB1 c2VkIHRvIHVzZSB0aGUgbW91bnRfYXJnZigpIGNvbW1hbmQgZm9yIHRoZSBvbGQgbW91bnQoKSBz eXNjYWxsLgotICovCi12b2lkCi1idWlsZF9pb3ZlY19hcmdmKHN0cnVjdCBpb3ZlYyAqKmlvdiwg aW50ICppb3ZsZW4sIGNvbnN0IGNoYXIgKm5hbWUsCi0gICAgY29uc3QgY2hhciAqZm10LCAuLi4p Ci17Ci0JdmFfbGlzdCBhcDsKLQljaGFyIHZhbFsyNTVdID0geyAwIH07Ci0KLQl2YV9zdGFydChh cCwgZm10KTsKLQl2c25wcmludGYodmFsLCBzaXplb2YodmFsKSwgZm10LCBhcCk7Ci0JdmFfZW5k KGFwKTsKLQlidWlsZF9pb3ZlYyhpb3YsIGlvdmxlbiwgbmFtZSwgc3RyZHVwKHZhbCksIChzaXpl X3QpLTEpOwotfQpJbmRleDogc2Jpbi9tb3VudC9tbnRvcHRzLmgKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jp bi9tb3VudC9tbnRvcHRzLmgJKHJldmlzaW9uIDI0NzE0OSkKKysrIHNiaW4vbW91bnQvbW50b3B0 cy5oCSh3b3JraW5nIGNvcHkpCkBAIC0xLDk5ICswLDAgQEAKLS8qLQotICogQ29weXJpZ2h0IChj KSAxOTk0Ci0gKiAgICAgIFRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3Ju aWEuICBBbGwgcmlnaHRzIHJlc2VydmVkLgotICoKLSAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2Ug aW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAotICogbW9kaWZpY2F0 aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25z Ci0gKiBhcmUgbWV0OgotICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3Qg cmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKLSAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNv bmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KLSAqIDIuIFJlZGlzdHJpYnV0 aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0Ci0g KiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRp c2NsYWltZXIgaW4gdGhlCi0gKiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlh bHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgotICogNC4gTmVpdGhlciB0aGUgbmFt ZSBvZiB0aGUgVW5pdmVyc2l0eSBub3IgdGhlIG5hbWVzIG9mIGl0cyBjb250cmlidXRvcnMKLSAq ICAgIG1heSBiZSB1c2VkIHRvIGVuZG9yc2Ugb3IgcHJvbW90ZSBwcm9kdWN0cyBkZXJpdmVkIGZy b20gdGhpcyBzb2Z0d2FyZQotICogICAgd2l0aG91dCBzcGVjaWZpYyBwcmlvciB3cml0dGVuIHBl cm1pc3Npb24uCi0gKgotICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgUkVHRU5U UyBBTkQgQ09OVFJJQlVUT1JTIGBgQVMgSVMnJyBBTkQKLSAqIEFOWSBFWFBSRVNTIE9SIElNUExJ RUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQotICogSU1Q TElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJU SUNVTEFSIFBVUlBPU0UKLSAqIEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhF IFJFR0VOVFMgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQotICogRk9SIEFOWSBESVJFQ1QsIElO RElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwK LSAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBP RiBTVUJTVElUVVRFIEdPT0RTCi0gKiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9S IFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKLSAqIEhPV0VWRVIgQ0FVU0VEIEFO RCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNU Ci0gKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lT RSkgQVJJU0lORyBJTiBBTlkgV0FZCi0gKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJF LCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCi0gKiBTVUNIIERBTUFHRS4K LSAqCi0gKglAKCMpbW50b3B0cy5oCTguNyAoQmVya2VsZXkpIDMvMjkvOTUKLSAqICRGcmVlQlNE JAotICovCi0KLXN0cnVjdCBtbnRvcHQgewotCWNvbnN0IGNoYXIgKm1fb3B0aW9uOwkvKiBvcHRp b24gbmFtZSAqLwotCWludCBtX2ludmVyc2U7CQkvKiBpZiBhIG5lZ2F0aXZlIG9wdGlvbiwgZS5n LiAiYXRpbWUiICovCi0JaW50IG1fZmxhZzsJCS8qIGJpdCB0byBzZXQsIGUuZy4gTU5UX1JET05M WSAqLwotCWludCBtX2FsdGxvYzsJCS8qIDEgPT4gc2V0IGJpdCBpbiBhbHRmbGFncyAqLwotfTsK LQotLyogVXNlci12aXNpYmxlIE1OVF8gZmxhZ3MuICovCi0jZGVmaW5lIE1PUFRfQVNZTkMJCXsg ImFzeW5jIiwJMCwgTU5UX0FTWU5DLCAwIH0KLSNkZWZpbmUgTU9QVF9OT0FUSU1FCQl7ICJhdGlt ZSIsCTEsIE1OVF9OT0FUSU1FLCAwIH0KLSNkZWZpbmUgTU9QVF9OT0VYRUMJCXsgImV4ZWMiLAkx LCBNTlRfTk9FWEVDLCAwIH0KLSNkZWZpbmUgTU9QVF9OT1NVSUQJCXsgInN1aWQiLAkxLCBNTlRf Tk9TVUlELCAwIH0KLSNkZWZpbmUgTU9QVF9OT1NZTUZPTExPVwl7ICJzeW1mb2xsb3ciLCAgMSwg TU5UX05PU1lNRk9MTE9XLCAwIH0KLSNkZWZpbmUgTU9QVF9SRE9OTFkJCXsgInJkb25seSIsCTAs IE1OVF9SRE9OTFksIDAgfQotI2RlZmluZSBNT1BUX1NZTkMJCXsgInN5bmMiLAkwLCBNTlRfU1lO Q0hST05PVVMsIDAgfQotI2RlZmluZSBNT1BUX1VOSU9OCQl7ICJ1bmlvbiIsCTAsIE1OVF9VTklP TiwgMCB9Ci0jZGVmaW5lIE1PUFRfVVNFUlFVT1RBCQl7ICJ1c2VycXVvdGEiLAkwLCAwLCAwIH0K LSNkZWZpbmUgTU9QVF9HUk9VUFFVT1RBCQl7ICJncm91cHF1b3RhIiwJMCwgMCwgMCB9Ci0jZGVm aW5lIE1PUFRfTk9DTFVTVEVSUgkJeyAiY2x1c3RlcnIiLAkxLCBNTlRfTk9DTFVTVEVSUiwgMCB9 Ci0jZGVmaW5lIE1PUFRfTk9DTFVTVEVSVwkJeyAiY2x1c3RlcnciLAkxLCBNTlRfTk9DTFVTVEVS VywgMCB9Ci0jZGVmaW5lIE1PUFRfU1VJRERJUgkJeyAic3VpZGRpciIsCTAsIE1OVF9TVUlERElS LCAwIH0KLSNkZWZpbmUgTU9QVF9TTkFQU0hPVAkJeyAic25hcHNob3QiLAkwLCBNTlRfU05BUFNI T1QsIDAgfQotI2RlZmluZSBNT1BUX01VTFRJTEFCRUwJCXsgIm11bHRpbGFiZWwiLAkwLCBNTlRf TVVMVElMQUJFTCwgMCB9Ci0jZGVmaW5lIE1PUFRfQUNMUwkJeyAiYWNscyIsCTAsIE1OVF9BQ0xT LCAwIH0KLSNkZWZpbmUgTU9QVF9ORlM0QUNMUwkJeyAibmZzdjRhY2xzIiwJMCwgTU5UX05GUzRB Q0xTLCAwIH0KLQotLyogQ29udHJvbCBmbGFncy4gKi8KLSNkZWZpbmUgTU9QVF9GT1JDRQkJeyAi Zm9yY2UiLAkwLCBNTlRfRk9SQ0UsIDAgfQotI2RlZmluZSBNT1BUX1VQREFURQkJeyAidXBkYXRl IiwJMCwgTU5UX1VQREFURSwgMCB9Ci0jZGVmaW5lIE1PUFRfUk8JCQl7ICJybyIsCQkwLCBNTlRf UkRPTkxZLCAwIH0KLSNkZWZpbmUgTU9QVF9SVwkJCXsgInJ3IiwJCTEsIE1OVF9SRE9OTFksIDAg fQotCi0vKiBUaGlzIGlzIHBhcnNlZCBieSBtb3VudCg4KSwgYnV0IGlzIGlnbm9yZWQgYnkgc3Bl Y2lmaWMgbW91bnRfKig4KXMuICovCi0jZGVmaW5lIE1PUFRfQVVUTwkJeyAiYXV0byIsCTAsIDAs IDAgfQotCi0vKiBBIGhhbmR5IG1hY3JvIGFzIHRlcm1pbmF0b3Igb2YgTU5UXyBhcnJheS4gKi8K LSNkZWZpbmUgTU9QVF9FTkQJCXsgTlVMTCwJCTAsIDAsIDAgfQotCi0jZGVmaW5lIE1PUFRfRlNU QUJfQ09NUEFUCQkJCQkJXAotCU1PUFRfUk8sCQkJCQkJCVwKLQlNT1BUX1JXLAkJCQkJCQlcCi0J TU9QVF9BVVRPCi0KLS8qIFN0YW5kYXJkIG9wdGlvbnMgd2hpY2ggYWxsIG1vdW50cyBjYW4gdW5k ZXJzdGFuZC4gKi8KLSNkZWZpbmUgTU9QVF9TVERPUFRTCQkJCQkJCVwKLQlNT1BUX1VTRVJRVU9U QSwJCQkJCQkJXAotCU1PUFRfR1JPVVBRVU9UQSwJCQkJCQlcCi0JTU9QVF9GU1RBQl9DT01QQVQs CQkJCQkJXAotCU1PUFRfTk9BVElNRSwJCQkJCQkJXAotCU1PUFRfTk9FWEVDLAkJCQkJCQlcCi0J TU9QVF9TVUlERElSLAkJLyogbXVzdCBiZSBiZWZvcmUgTU9QVF9OT1NVSUQgKi8JXAotCU1PUFRf Tk9TVUlELAkJCQkJCQlcCi0JTU9QVF9OT1NZTUZPTExPVywJCQkJCQlcCi0JTU9QVF9SRE9OTFks CQkJCQkJCVwKLQlNT1BUX1VOSU9OLAkJCQkJCQlcCi0JTU9QVF9OT0NMVVNURVJSLAkJCQkJCVwK LQlNT1BUX05PQ0xVU1RFUlcsCQkJCQkJXAotCU1PUFRfTVVMVElMQUJFTCwJCQkJCQlcCi0JTU9Q VF9BQ0xTLAkJCQkJCQlcCi0JTU9QVF9ORlM0QUNMUwotCi12b2lkIGdldG1udG9wdHMoY29uc3Qg Y2hhciAqLCBjb25zdCBzdHJ1Y3QgbW50b3B0ICosIGludCAqLCBpbnQgKik7Ci12b2lkIHJtc2xh c2hlcyhjaGFyICosIGNoYXIgKik7Ci1pbnQgY2hlY2twYXRoKGNvbnN0IGNoYXIgKiwgY2hhciBy ZXNvbHZlZF9wYXRoW10pOwotZXh0ZXJuIGludCBnZXRtbnRfc2lsZW50Owotdm9pZCBidWlsZF9p b3ZlYyhzdHJ1Y3QgaW92ZWMgKippb3YsIGludCAqaW92bGVuLCBjb25zdCBjaGFyICpuYW1lLCB2 b2lkICp2YWwsIHNpemVfdCBsZW4pOwotdm9pZCBidWlsZF9pb3ZlY19hcmdmKHN0cnVjdCBpb3Zl YyAqKmlvdiwgaW50ICppb3ZsZW4sIGNvbnN0IGNoYXIgKm5hbWUsIGNvbnN0IGNoYXIgKmZtdCwg Li4uKTsKSW5kZXg6IHNiaW4vbW91bnQvbW91bnQuYwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzYmluL21vdW50 L21vdW50LmMJKHJldmlzaW9uIDI0NzE0OSkKKysrIHNiaW4vbW91bnQvbW91bnQuYwkod29ya2lu ZyBjb3B5KQpAQCAtNDgsNiArNDgsNyBAQAogI2luY2x1ZGUgPGVyci5oPgogI2luY2x1ZGUgPGVy cm5vLmg+CiAjaW5jbHVkZSA8ZnN0YWIuaD4KKyNpbmNsdWRlIDxtbnRvcHRzLmg+CiAjaW5jbHVk ZSA8cGF0aHMuaD4KICNpbmNsdWRlIDxwd2QuaD4KICNpbmNsdWRlIDxzaWduYWwuaD4KQEAgLTU5 LDcgKzYwLDYgQEAKICNpbmNsdWRlIDxsaWJ1dGlsLmg+CiAKICNpbmNsdWRlICJleHRlcm4uaCIK LSNpbmNsdWRlICJtbnRvcHRzLmgiCiAjaW5jbHVkZSAicGF0aG5hbWVzLmgiCiAKIC8qIGBtZXRh JyBvcHRpb25zICovCkluZGV4OiBzYmluL21vdW50L21vdW50X2ZzLmMKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g c2Jpbi9tb3VudC9tb3VudF9mcy5jCShyZXZpc2lvbiAyNDcxNDkpCisrKyBzYmluL21vdW50L21v dW50X2ZzLmMJKHdvcmtpbmcgY29weSkKQEAgLTUwLDEzICs1MCwxMyBAQAogI2luY2x1ZGUgPGVy ci5oPgogI2luY2x1ZGUgPGdldG9wdC5oPgogI2luY2x1ZGUgPGxpYmdlbi5oPgorI2luY2x1ZGUg PG1udG9wdHMuaD4KICNpbmNsdWRlIDxzdGRpby5oPgogI2luY2x1ZGUgPHN0ZGxpYi5oPgogI2lu Y2x1ZGUgPHN0cmluZy5oPgogI2luY2x1ZGUgPHVuaXN0ZC5oPgogCiAjaW5jbHVkZSAiZXh0ZXJu LmgiCi0jaW5jbHVkZSAibW50b3B0cy5oIgogCiBzdGF0aWMgc3RydWN0IG1udG9wdCBtb3B0c1td ID0gewogCU1PUFRfU1RET1BUUywKSW5kZXg6IHNiaW4vbW91bnRfY2Q5NjYwL01ha2VmaWxlCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIHNiaW4vbW91bnRfY2Q5NjYwL01ha2VmaWxlCShyZXZpc2lvbiAyNDcxNDkp CisrKyBzYmluL21vdW50X2NkOTY2MC9NYWtlZmlsZQkod29ya2luZyBjb3B5KQpAQCAtMiwxOCAr MiwxMiBAQAogIyAkRnJlZUJTRCQKIAogUFJPRz0JbW91bnRfY2Q5NjYwCi1TUkNTPQltb3VudF9j ZDk2NjAuYyBnZXRtbnRvcHRzLmMKIE1BTj0JbW91bnRfY2Q5NjYwLjgKLURQQUREPQkke0xJQktJ Q09OVn0KLUxEQUREPQktbGtpY29udgorRFBBREQ9CSR7TElCS0lDT05WfSAke0xJQlVUSUx9CitM REFERD0JLWxraWNvbnYgLWx1dGlsCiAKLU1PVU5UPQkkey5DVVJESVJ9Ly4uL21vdW50Ci1DRkxB R1MrPSAtSSR7TU9VTlR9Ci0KICMgTmVlZHMgdG8gYmUgZHluYW1pY2FsbHkgbGlua2VkIGZvciBv cHRpb25hbCBkbG9wZW4oKSBhY2Nlc3MgdG8KICMgdXNlcmxhbmQgbGliaWNvbnYKIE5PX1NIQVJF RD89CU5PCiAKLS5QQVRIOgkke01PVU5UfQotCiAuaW5jbHVkZSA8YnNkLnByb2cubWs+CkluZGV4 OiBzYmluL21vdW50X2NkOTY2MC9tb3VudF9jZDk2NjAuYwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzYmluL21v dW50X2NkOTY2MC9tb3VudF9jZDk2NjAuYwkocmV2aXNpb24gMjQ3MTQ5KQorKysgc2Jpbi9tb3Vu dF9jZDk2NjAvbW91bnRfY2Q5NjYwLmMJKHdvcmtpbmcgY29weSkKQEAgLTYwLDE0ICs2MCwxMyBA QAogCiAjaW5jbHVkZSA8ZXJyLmg+CiAjaW5jbHVkZSA8ZXJybm8uaD4KKyNpbmNsdWRlIDxtbnRv cHRzLmg+CiAjaW5jbHVkZSA8c3RkbGliLmg+CiAjaW5jbHVkZSA8c3RkaW8uaD4KICNpbmNsdWRl IDxzdHJpbmcuaD4KICNpbmNsdWRlIDxzeXNleGl0cy5oPgogI2luY2x1ZGUgPHVuaXN0ZC5oPgog Ci0jaW5jbHVkZSAibW50b3B0cy5oIgotCiBzdGF0aWMgc3RydWN0IG1udG9wdCBtb3B0c1tdID0g ewogCU1PUFRfU1RET1BUUywKIAlNT1BUX1VQREFURSwKSW5kZXg6IHNiaW4vbW91bnRfZXh0MmZz L01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIHNiaW4vbW91bnRfZXh0MmZzL01ha2VmaWxlCShyZXZp c2lvbiAyNDcxNDkpCisrKyBzYmluL21vdW50X2V4dDJmcy9NYWtlZmlsZQkod29ya2luZyBjb3B5 KQpAQCAtMiwxMyArMiwxMSBAQAogIyAkRnJlZUJTRCQKIAogUFJPRz0JbW91bnRfZXh0MmZzCi1T UkNTPQltb3VudF9leHQyZnMuYyBnZXRtbnRvcHRzLmMKIE1BTj0JbW91bnRfZXh0MmZzLjgKIAog V0FSTlM/PQkyCi1NT1VOVD0JJHsuQ1VSRElSfS8uLi9tb3VudAotQ0ZMQUdTKz0gLUkke01PVU5U fQogCi0uUEFUSDoJJHtNT1VOVH0KK0RQQUREPQkke0xJQlVUSUx9CitMREFERD0JLWx1dGlsCiAK IC5pbmNsdWRlIDxic2QucHJvZy5taz4KSW5kZXg6IHNiaW4vbW91bnRfZXh0MmZzL21vdW50X2V4 dDJmcy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIHNiaW4vbW91bnRfZXh0MmZzL21vdW50X2V4dDJmcy5jCShy ZXZpc2lvbiAyNDcxNDkpCisrKyBzYmluL21vdW50X2V4dDJmcy9tb3VudF9leHQyZnMuYwkod29y a2luZyBjb3B5KQpAQCAtNDYsMTQgKzQ2LDEzIEBACiAjaW5jbHVkZSA8c3lzL3Vpby5oPgogCiAj aW5jbHVkZSA8ZXJyLmg+CisjaW5jbHVkZSA8bW50b3B0cy5oPgogI2luY2x1ZGUgPHN0ZGlvLmg+ CiAjaW5jbHVkZSA8c3RkbGliLmg+CiAjaW5jbHVkZSA8c3RyaW5nLmg+CiAjaW5jbHVkZSA8c3lz ZXhpdHMuaD4KICNpbmNsdWRlIDx1bmlzdGQuaD4KIAotI2luY2x1ZGUgIm1udG9wdHMuaCIKLQog c3RhdGljIHZvaWQJdXNhZ2Uodm9pZCk7CiAKIGludApJbmRleDogc2Jpbi9tb3VudF9mdXNlZnMv TWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9tb3VudF9mdXNlZnMvTWFrZWZpbGUJKHJldmlz aW9uIDI0NzE0OSkKKysrIHNiaW4vbW91bnRfZnVzZWZzL01ha2VmaWxlCSh3b3JraW5nIGNvcHkp CkBAIC0yMSwxMyArMjEsMTAgQEAKIC5lbmRpZgogCiBQUk9HPQltb3VudF9mdXNlZnMKLVNSQ1M9 CW1vdW50X2Z1c2Vmcy5jIGdldG1udG9wdHMuYwogTUFOOD0JbW91bnRfZnVzZWZzLjgKIE5PX01B TkNPTVBSRVNTPz0JeWVzCiAKLU1PVU5UPQkkey5DVVJESVJ9Ly4uL21vdW50Ci1DRkxBR1MrPQkt SSR7TU9VTlR9CitEUEFERD0JJHtMSUJVVElMfQorTERBREQ9CS1sdXRpbAogCi0uUEFUSDogJHtN T1VOVH0KLQogLmluY2x1ZGUgPGJzZC5wcm9nLm1rPgpJbmRleDogc2Jpbi9tb3VudF9mdXNlZnMv bW91bnRfZnVzZWZzLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9tb3VudF9mdXNlZnMvbW91bnRfZnVz ZWZzLmMJKHJldmlzaW9uIDI0NzE0OSkKKysrIHNiaW4vbW91bnRfZnVzZWZzL21vdW50X2Z1c2Vm cy5jCSh3b3JraW5nIGNvcHkpCkBAIC0zNiw2ICszNiw3IEBACiAjaW5jbHVkZSA8c3lzL3N5c2N0 bC5oPgogCiAjaW5jbHVkZSA8ZXJyLmg+CisjaW5jbHVkZSA8bW50b3B0cy5oPgogI2luY2x1ZGUg PHN0ZGlvLmg+CiAjaW5jbHVkZSA8c3RkbGliLmg+CiAjaW5jbHVkZSA8c3RyaW5nLmg+CkBAIC00 OCw4ICs0OSw2IEBACiAjaW5jbHVkZSA8b3NyZWxkYXRlLmg+CiAjaW5jbHVkZSA8cGF0aHMuaD4K IAotI2luY2x1ZGUgIm1udG9wdHMuaCIKLQogI2lmbmRlZiBGVVNFNEJTRF9WRVJTSU9OCiAjZGVm aW5lCUZVU0U0QlNEX1ZFUlNJT04JIjAuMy45LXByZTEiCiAjZW5kaWYKSW5kZXg6IHNiaW4vbW91 bnRfaHBmcy9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzYmluL21vdW50X2hwZnMvTWFrZWZpbGUJ KHJldmlzaW9uIDI0NzE0OSkKKysrIHNiaW4vbW91bnRfaHBmcy9NYWtlZmlsZQkod29ya2luZyBj b3B5KQpAQCAtMywxMiArMywxMSBAQAogIwogCiBQUk9HPQltb3VudF9ocGZzCi1TUkNTPQltb3Vu dF9ocGZzLmMgZ2V0bW50b3B0cy5jCiBNQU49CW1vdW50X2hwZnMuOAogCi1NT1VOVD0JJHsuQ1VS RElSfS8uLi9tb3VudAotQ0ZMQUdTKz0gLUkke01PVU5UfSAtREhQRlMKK0NGTEFHUys9IC1ESFBG UwogCi0uUEFUSDoJJHtNT1VOVH0KK0RQQUREPQkke0xJQlVUSUx9CitMREFERD0JLWx1dGlsCiAK IC5pbmNsdWRlIDxic2QucHJvZy5taz4KSW5kZXg6IHNiaW4vbW91bnRfaHBmcy9tb3VudF9ocGZz LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQotLS0gc2Jpbi9tb3VudF9ocGZzL21vdW50X2hwZnMuYwkocmV2aXNpb24g MjQ3MTQ5KQorKysgc2Jpbi9tb3VudF9ocGZzL21vdW50X2hwZnMuYwkod29ya2luZyBjb3B5KQpA QCAtMzksNiArMzksNyBAQAogI2luY2x1ZGUgPGN0eXBlLmg+CiAjaW5jbHVkZSA8ZXJyLmg+CiAj aW5jbHVkZSA8Z3JwLmg+CisjaW5jbHVkZSA8bW50b3B0cy5oPgogI2luY2x1ZGUgPHB3ZC5oPgog I2luY2x1ZGUgPHN0ZGlvLmg+CiAjaW5jbHVkZSA8c3RkbGliLmg+CkBAIC00Niw4ICs0Nyw2IEBA CiAjaW5jbHVkZSA8c3lzZXhpdHMuaD4KICNpbmNsdWRlIDx1bmlzdGQuaD4KIAotI2luY2x1ZGUg Im1udG9wdHMuaCIKLQogc3RhdGljIHN0cnVjdCBtbnRvcHQgbW9wdHNbXSA9IHsKIAlNT1BUX1NU RE9QVFMsCiAJTU9QVF9FTkQKSW5kZXg6IHNiaW4vbW91bnRfbXNkb3Nmcy9NYWtlZmlsZQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBzYmluL21vdW50X21zZG9zZnMvTWFrZWZpbGUJKHJldmlzaW9uIDI0NzE0OSkK KysrIHNiaW4vbW91bnRfbXNkb3Nmcy9NYWtlZmlsZQkod29ya2luZyBjb3B5KQpAQCAtMywxOCAr MywxMiBAQAogIwogCiBQUk9HPQltb3VudF9tc2Rvc2ZzCi1TUkNTPQltb3VudF9tc2Rvc2ZzLmMg Z2V0bW50b3B0cy5jCiBNQU49CW1vdW50X21zZG9zZnMuOAotRFBBREQ9CSR7TElCS0lDT05WfQot TERBREQ9CS1sa2ljb252CitEUEFERD0JJHtMSUJLSUNPTlZ9ICR7TElCVVRJTH0KK0xEQUREPQkt bGtpY29udiAtbHV0aWwKIAotTU9VTlQ9CSR7LkNVUkRJUn0vLi4vbW91bnQKLUNGTEFHUys9IC1J JHtNT1VOVH0KLQogIyBOZWVkcyB0byBiZSBkeW5hbWljYWxseSBsaW5rZWQgZm9yIG9wdGlvbmFs IGRsb3BlbigpIGFjY2VzcyB0bwogIyB1c2VybGFuZCBsaWJpY29udgogTk9fU0hBUkVEPz0JTk8K IAotLlBBVEg6CSR7TU9VTlR9Ci0KIC5pbmNsdWRlIDxic2QucHJvZy5taz4KSW5kZXg6IHNiaW4v bW91bnRfbXNkb3Nmcy9tb3VudF9tc2Rvc2ZzLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9tb3VudF9t c2Rvc2ZzL21vdW50X21zZG9zZnMuYwkocmV2aXNpb24gMjQ3MTQ5KQorKysgc2Jpbi9tb3VudF9t c2Rvc2ZzL21vdW50X21zZG9zZnMuYwkod29ya2luZyBjb3B5KQpAQCAtNDYsNiArNDYsNyBAQAog I2luY2x1ZGUgPGVyci5oPgogI2luY2x1ZGUgPGdycC5oPgogI2luY2x1ZGUgPGxvY2FsZS5oPgor I2luY2x1ZGUgPG1udG9wdHMuaD4KICNpbmNsdWRlIDxwd2QuaD4KICNpbmNsdWRlIDxzdGRpby5o PgogLyogbXVzdCBiZSBhZnRlciBzdGRpbyB0byBkZWNsYXJlIGZwYXJzZWxuICovCkBAIC01NSw4 ICs1Niw2IEBACiAjaW5jbHVkZSA8c3lzZXhpdHMuaD4KICNpbmNsdWRlIDx1bmlzdGQuaD4KIAot I2luY2x1ZGUgIm1udG9wdHMuaCIKLQogc3RhdGljIGdpZF90CWFfZ2lkKGNoYXIgKik7CiBzdGF0 aWMgdWlkX3QJYV91aWQoY2hhciAqKTsKIHN0YXRpYyBtb2RlX3QJYV9tYXNrKGNoYXIgKik7Cklu ZGV4OiBzYmluL21vdW50X25mcy9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzYmluL21vdW50X25m cy9NYWtlZmlsZQkocmV2aXNpb24gMjQ3MTQ5KQorKysgc2Jpbi9tb3VudF9uZnMvTWFrZWZpbGUJ KHdvcmtpbmcgY29weSkKQEAgLTMsMTcgKzMsMTkgQEAKICMgJEZyZWVCU0QkCiAKIFBST0c9CW1v dW50X25mcwotU1JDUz0JbW91bnRfbmZzLmMgZ2V0bW50b3B0cy5jIG1vdW50dGFiLmMKK1NSQ1M9 CW1vdW50X25mcy5jIG1vdW50dGFiLmMKIE1BTj0JbW91bnRfbmZzLjgKIE1MSU5LUz0JbW91bnRf bmZzLjggbW91bnRfb2xkbmZzLjgKIAotTU9VTlQ9CSR7LkNVUkRJUn0vLi4vbW91bnQKIFVNTlRB TEw9ICR7LkNVUkRJUn0vLi4vLi4vdXNyLnNiaW4vcnBjLnVtbnRhbGwKLUNGTEFHUys9IC1ETkZT IC1JJHtNT1VOVH0gLUkke1VNTlRBTEx9CitDRkxBR1MrPSAtRE5GUyAtSSR7VU1OVEFMTH0KIFdB Uk5TPz0JMwogCitEUEFERD0JJHtMSUJVVElMfQorTERBREQ9CS1sdXRpbAorCiBMSU5LUz0JJHtC SU5ESVJ9L21vdW50X25mcyAke0JJTkRJUn0vbW91bnRfb2xkbmZzCiAKLS5QQVRIOiAke01PVU5U fSAke1VNTlRBTEx9CisuUEFUSDogJHtVTU5UQUxMfQogCiAuaW5jbHVkZSA8YnNkLnByb2cubWs+ CkluZGV4OiBzYmluL21vdW50X25mcy9tb3VudF9uZnMuYwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzYmluL21v dW50X25mcy9tb3VudF9uZnMuYwkocmV2aXNpb24gMjQ3MTQ5KQorKysgc2Jpbi9tb3VudF9uZnMv bW91bnRfbmZzLmMJKHdvcmtpbmcgY29weSkKQEAgLTY3LDYgKzY3LDcgQEAKICNpbmNsdWRlIDxl cnIuaD4KICNpbmNsdWRlIDxlcnJuby5oPgogI2luY2x1ZGUgPGZjbnRsLmg+CisjaW5jbHVkZSA8 bW50b3B0cy5oPgogI2luY2x1ZGUgPG5ldGRiLmg+CiAjaW5jbHVkZSA8c3RkaW8uaD4KICNpbmNs dWRlIDxzdGRsaWIuaD4KQEAgLTc1LDcgKzc2LDYgQEAKICNpbmNsdWRlIDxzeXNleGl0cy5oPgog I2luY2x1ZGUgPHVuaXN0ZC5oPgogCi0jaW5jbHVkZSAibW50b3B0cy5oIgogI2luY2x1ZGUgIm1v dW50dGFiLmgiCiAKIC8qIFRhYmxlIGZvciBhZixzb3R5cGUgLT4gbmV0aWQgY29udmVyc2lvbnMu ICovCkluZGV4OiBzYmluL21vdW50X250ZnMvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9t b3VudF9udGZzL01ha2VmaWxlCShyZXZpc2lvbiAyNDcxNDkpCisrKyBzYmluL21vdW50X250ZnMv TWFrZWZpbGUJKHdvcmtpbmcgY29weSkKQEAgLTMsMTggKzMsMTIgQEAKICMKIAogUFJPRz0JbW91 bnRfbnRmcwotU1JDUz0JbW91bnRfbnRmcy5jIGdldG1udG9wdHMuYwogTUFOPQltb3VudF9udGZz LjgKLURQQUREPQkke0xJQktJQ09OVn0KLUxEQUREPQktbGtpY29udgorRFBBREQ9CSR7TElCS0lD T05WfSAke0xJQlVUSUx9CitMREFERD0JLWxraWNvbnYgLWx1dGlsCiAKLU1PVU5UPQkkey5DVVJE SVJ9Ly4uL21vdW50Ci1DRkxBR1MrPSAtSSR7TU9VTlR9Ci0KICMgTmVlZHMgdG8gYmUgZHluYW1p Y2FsbHkgbGlua2VkIGZvciBvcHRpb25hbCBkbG9wZW4oKSBhY2Nlc3MgdG8KICMgdXNlcmxhbmQg bGliaWNvbnYKIE5PX1NIQVJFRD89CU5PCiAKLS5QQVRIOgkke01PVU5UfQotCiAuaW5jbHVkZSA8 YnNkLnByb2cubWs+CkluZGV4OiBzYmluL21vdW50X250ZnMvbW91bnRfbnRmcy5jCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIHNiaW4vbW91bnRfbnRmcy9tb3VudF9udGZzLmMJKHJldmlzaW9uIDI0NzE0OSkKKysr IHNiaW4vbW91bnRfbnRmcy9tb3VudF9udGZzLmMJKHdvcmtpbmcgY29weSkKQEAgLTQ0LDYgKzQ0 LDcgQEAKICNpbmNsdWRlIDxjdHlwZS5oPgogI2luY2x1ZGUgPGVyci5oPgogI2luY2x1ZGUgPGdy cC5oPgorI2luY2x1ZGUgPG1udG9wdHMuaD4KICNpbmNsdWRlIDxwd2QuaD4KICNpbmNsdWRlIDxz dGRpby5oPgogI2luY2x1ZGUgPHN0ZGxpYi5oPgpAQCAtNTIsOCArNTMsNiBAQAogI2luY2x1ZGUg PHVuaXN0ZC5oPgogI2luY2x1ZGUgPGxpYnV0aWwuaD4KIAotI2luY2x1ZGUgIm1udG9wdHMuaCIK LQogI2RlZmluZSBUUkFOU0lUSU9OX1BFUklPRF9IQUNLCiAKIHN0YXRpYyBzdHJ1Y3QgbW50b3B0 IG1vcHRzW10gPSB7CkluZGV4OiBzYmluL21vdW50X251bGxmcy9NYWtlZmlsZQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0tLSBzYmluL21vdW50X251bGxmcy9NYWtlZmlsZQkocmV2aXNpb24gMjQ3MTQ5KQorKysgc2Jp bi9tb3VudF9udWxsZnMvTWFrZWZpbGUJKHdvcmtpbmcgY29weSkKQEAgLTIsMTIgKzIsOSBAQAog IyAkRnJlZUJTRCQKIAogUFJPRz0JbW91bnRfbnVsbGZzCi1TUkNTPQltb3VudF9udWxsZnMuYyBn ZXRtbnRvcHRzLmMKIE1BTj0JbW91bnRfbnVsbGZzLjgKIAotTU9VTlQ9CSR7LkNVUkRJUn0vLi4v bW91bnQKLUNGTEFHUys9LUkke01PVU5UfQorRFBBREQ9CSR7TElCVVRJTH0KK0xEQUREPQktbHV0 aWwKIAotLlBBVEg6CSR7TU9VTlR9Ci0KIC5pbmNsdWRlIDxic2QucHJvZy5taz4KSW5kZXg6IHNi aW4vbW91bnRfbnVsbGZzL21vdW50X251bGxmcy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHNiaW4vbW91bnRf bnVsbGZzL21vdW50X251bGxmcy5jCShyZXZpc2lvbiAyNDcxNDkpCisrKyBzYmluL21vdW50X251 bGxmcy9tb3VudF9udWxsZnMuYwkod29ya2luZyBjb3B5KQpAQCAtNDksMTQgKzQ5LDEzIEBACiAj aW5jbHVkZSA8c3lzL3Vpby5oPgogCiAjaW5jbHVkZSA8ZXJyLmg+CisjaW5jbHVkZSA8bW50b3B0 cy5oPgogI2luY2x1ZGUgPHN0ZGlvLmg+CiAjaW5jbHVkZSA8c3RkbGliLmg+CiAjaW5jbHVkZSA8 c3RyaW5nLmg+CiAjaW5jbHVkZSA8c3lzZXhpdHMuaD4KICNpbmNsdWRlIDx1bmlzdGQuaD4KIAot I2luY2x1ZGUgIm1udG9wdHMuaCIKLQogaW50CXN1YmRpcihjb25zdCBjaGFyICosIGNvbnN0IGNo YXIgKik7CiBzdGF0aWMgdm9pZAl1c2FnZSh2b2lkKSBfX2RlYWQyOwogCkluZGV4OiBzYmluL21v dW50X3JlaXNlcmZzL01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHNiaW4vbW91bnRfcmVpc2VyZnMv TWFrZWZpbGUJKHJldmlzaW9uIDI0NzE0OSkKKysrIHNiaW4vbW91bnRfcmVpc2VyZnMvTWFrZWZp bGUJKHdvcmtpbmcgY29weSkKQEAgLTEsMTMgKzEsOSBAQAogIyAkRnJlZUJTRCQKIAogUFJPRyA9 IG1vdW50X3JlaXNlcmZzCi1TUkNTID0gbW91bnRfcmVpc2VyZnMuYyBnZXRtbnRvcHRzLmMKIE1B TiAgPSBtb3VudF9yZWlzZXJmcy44CiAKLSMgbW91bnRfcmVpc2VyZnMgbmVlZHMgbW50b3B0cy5o IGFuZCBnZXRtbnRvcHRzLmMgZnJvbSBzcmMvc2Jpbi9tb3VudC8KLU1PVU5UICA/PSAkey5DVVJE SVJ9Ly4uL21vdW50Ci1DRkxBR1MgKz0gLUkke01PVU5UfQorRFBBREQ9CSR7TElCVVRJTH0KK0xE QUREPQktbHV0aWwKIAotLlBBVEg6ICR7TU9VTlR9Ci0KIC5pbmNsdWRlIDxic2QucHJvZy5taz4K SW5kZXg6IHNiaW4vbW91bnRfcmVpc2VyZnMvbW91bnRfcmVpc2VyZnMuYwo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBzYmluL21vdW50X3JlaXNlcmZzL21vdW50X3JlaXNlcmZzLmMJKHJldmlzaW9uIDI0NzE0OSkK KysrIHNiaW4vbW91bnRfcmVpc2VyZnMvbW91bnRfcmVpc2VyZnMuYwkod29ya2luZyBjb3B5KQpA QCAtMzEsMTQgKzMxLDEzIEBACiAjaW5jbHVkZSA8c3lzL3Vpby5oPgogCiAjaW5jbHVkZSA8ZXJy Lmg+CisjaW5jbHVkZSA8bW50b3B0cy5oPgogI2luY2x1ZGUgPHN0ZGlvLmg+CiAjaW5jbHVkZSA8 c3RkbGliLmg+CiAjaW5jbHVkZSA8c3RyaW5nLmg+CiAjaW5jbHVkZSA8c3lzZXhpdHMuaD4KICNp bmNsdWRlIDx1bmlzdGQuaD4KIAotI2luY2x1ZGUgIm1udG9wdHMuaCIKLQogc3RydWN0IG1udG9w dCBtb3B0c1tdID0gewogCU1PUFRfU1RET1BUUywKIAlNT1BUX0VORApJbmRleDogc2Jpbi9tb3Vu dF9zdGQvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9tb3VudF9zdGQvTWFrZWZpbGUJKHJl dmlzaW9uIDI0NzE0OSkKKysrIHNiaW4vbW91bnRfc3RkL01ha2VmaWxlCSh3b3JraW5nIGNvcHkp CkBAIC0yLDE4ICsyLDE2IEBACiAjCSRGcmVlQlNEJAogCiBQUk9HPQltb3VudF9zdGQKLVNSQ1M9 CW1vdW50X3N0ZC5jIGdldG1udG9wdHMuYwogTUFOPQltb3VudF9zdGQuOAogTUxJTktTPQltb3Vu dF9zdGQuOCBtb3VudF9kZXZmcy44IFwKIAltb3VudF9zdGQuOCBtb3VudF9mZGVzY2ZzLjggXAog CW1vdW50X3N0ZC44IG1vdW50X2xpbnByb2Nmcy44IFwKIAltb3VudF9zdGQuOCBtb3VudF9wcm9j ZnMuOAogCi1NT1VOVD0JJHsuQ1VSRElSfS8uLi9tb3VudAotQ0ZMQUdTKz0gLUkke01PVU5UfQog V0FSTlM/PQkzCiAKLS5QQVRIOgkke01PVU5UfQorRFBBREQ9CSR7TElCVVRJTH0KK0xEQUREPQkt bHV0aWwKIAogTElOS1M9CSR7QklORElSfS9tb3VudF9zdGQgJHtCSU5ESVJ9L21vdW50X2RldmZz IFwKIAkke0JJTkRJUn0vbW91bnRfc3RkICR7QklORElSfS9tb3VudF9mZGVzY2ZzIFwKSW5kZXg6 IHNiaW4vbW91bnRfc3RkL21vdW50X3N0ZC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHNiaW4vbW91bnRfc3Rk L21vdW50X3N0ZC5jCShyZXZpc2lvbiAyNDcxNDkpCisrKyBzYmluL21vdW50X3N0ZC9tb3VudF9z dGQuYwkod29ya2luZyBjb3B5KQpAQCAtNDYsNiArNDYsNyBAQAogCiAjaW5jbHVkZSA8ZXJyLmg+ CiAjaW5jbHVkZSA8ZXJybm8uaD4KKyNpbmNsdWRlIDxtbnRvcHRzLmg+CiAjaW5jbHVkZSA8c3Rk aW8uaD4KICNpbmNsdWRlIDxzaWduYWwuaD4KICNpbmNsdWRlIDxzdGRsaWIuaD4KQEAgLTUzLDgg KzU0LDYgQEAKICNpbmNsdWRlIDxzeXNleGl0cy5oPgogI2luY2x1ZGUgPHVuaXN0ZC5oPgogCi0j aW5jbHVkZSAibW50b3B0cy5oIgotCiBzdGF0aWMgc3RydWN0IG1udG9wdCBtb3B0c1tdID0gewog CU1PUFRfU1RET1BUUywKIAlNT1BUX0VORApJbmRleDogc2Jpbi9tb3VudF91ZGYvTWFrZWZpbGUK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gc2Jpbi9tb3VudF91ZGYvTWFrZWZpbGUJKHJldmlzaW9uIDI0NzE0OSkK KysrIHNiaW4vbW91bnRfdWRmL01ha2VmaWxlCSh3b3JraW5nIGNvcHkpCkBAIC0xLDE0ICsxLDEx IEBACiAjICRGcmVlQlNEJAogCiBQUk9HPQltb3VudF91ZGYKLVNSQ1M9CW1vdW50X3VkZi5jIGdl dG1udG9wdHMuYwogTUFOPQltb3VudF91ZGYuOAotRFBBREQ9CSR7TElCS0lDT05WfQotTERBREQ9 CS1sa2ljb252CitEUEFERD0JJHtMSUJLSUNPTlZ9ICR7TElCVVRJTH0KK0xEQUREPQktbGtpY29u diAtbHV0aWwKIAotTU9VTlQ9CSR7LkNVUkRJUn0vLi4vbW91bnQKLUNGTEFHUys9IC1JJHtNT1VO VH0gLUkkey5DVVJESVJ9Ly4uLy4uL3N5cwotLlBBVEg6CSR7TU9VTlR9CitDRkxBR1MrPSAtSSR7 LkNVUkRJUn0vLi4vLi4vc3lzCiBXQVJOUz89IDEKIAogIyBOZWVkcyB0byBiZSBkeW5hbWljYWxs eSBsaW5rZWQgZm9yIG9wdGlvbmFsIGRsb3BlbigpIGFjY2VzcyB0bwpJbmRleDogc2Jpbi9tb3Vu dF91ZGYvbW91bnRfdWRmLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9tb3VudF91ZGYvbW91bnRfdWRm LmMJKHJldmlzaW9uIDI0NzE0OSkKKysrIHNiaW4vbW91bnRfdWRmL21vdW50X3VkZi5jCSh3b3Jr aW5nIGNvcHkpCkBAIC01MywxNCArNTMsMTMgQEAKIAogI2luY2x1ZGUgPGVyci5oPgogI2luY2x1 ZGUgPGVycm5vLmg+CisjaW5jbHVkZSA8bW50b3B0cy5oPgogI2luY2x1ZGUgPHN0ZGxpYi5oPgog I2luY2x1ZGUgPHN0ZGlvLmg+CiAjaW5jbHVkZSA8c3RyaW5nLmg+CiAjaW5jbHVkZSA8c3lzZXhp dHMuaD4KICNpbmNsdWRlIDx1bmlzdGQuaD4KIAotI2luY2x1ZGUgIm1udG9wdHMuaCIKLQogc3Rh dGljIHN0cnVjdCBtbnRvcHQgbW9wdHNbXSA9IHsKIAlNT1BUX1NURE9QVFMsCiAJTU9QVF9VUERB VEUsCkluZGV4OiBzYmluL21vdW50X3VuaW9uZnMvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jp bi9tb3VudF91bmlvbmZzL01ha2VmaWxlCShyZXZpc2lvbiAyNDcxNDkpCisrKyBzYmluL21vdW50 X3VuaW9uZnMvTWFrZWZpbGUJKHdvcmtpbmcgY29weSkKQEAgLTIsMTIgKzIsOSBAQAogIyAkRnJl ZUJTRCQKIAogUFJPRz0JbW91bnRfdW5pb25mcwotU1JDUz0JbW91bnRfdW5pb25mcy5jIGdldG1u dG9wdHMuYwogTUFOPQltb3VudF91bmlvbmZzLjgKIAotTU9VTlQ9CSR7LkNVUkRJUn0vLi4vbW91 bnQKLUNGTEFHUys9LUkke01PVU5UfQorRFBBREQ9CSR7TElCVVRJTH0KK0xEQUREPQktbHV0aWwK IAotLlBBVEg6CSR7TU9VTlR9Ci0KIC5pbmNsdWRlIDxic2QucHJvZy5taz4KSW5kZXg6IHNiaW4v bW91bnRfdW5pb25mcy9tb3VudF91bmlvbmZzLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9tb3VudF91 bmlvbmZzL21vdW50X3VuaW9uZnMuYwkocmV2aXNpb24gMjQ3MTQ5KQorKysgc2Jpbi9tb3VudF91 bmlvbmZzL21vdW50X3VuaW9uZnMuYwkod29ya2luZyBjb3B5KQpAQCAtNTQsNiArNTQsNyBAQAog I2luY2x1ZGUgPHN5cy9lcnJuby5oPgogCiAjaW5jbHVkZSA8ZXJyLmg+CisjaW5jbHVkZSA8bW50 b3B0cy5oPgogI2luY2x1ZGUgPHN0ZGlvLmg+CiAjaW5jbHVkZSA8c3RkbGliLmg+CiAjaW5jbHVk ZSA8c3RyaW5nLmg+CkBAIC02Miw4ICs2Myw2IEBACiAjaW5jbHVkZSA8Z3JwLmg+CiAjaW5jbHVk ZSA8cHdkLmg+CiAKLSNpbmNsdWRlICJtbnRvcHRzLmgiCi0KIHN0YXRpYyBpbnQgCiBzdWJkaXIo Y29uc3QgY2hhciAqcCwgY29uc3QgY2hhciAqZGlyKQogewpJbmRleDogdXNyLnNiaW4vbW91bnRf bndmcy9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3Iuc2Jpbi9tb3VudF9ud2ZzL01ha2VmaWxl CShyZXZpc2lvbiAyNDcxNDkpCisrKyB1c3Iuc2Jpbi9tb3VudF9ud2ZzL01ha2VmaWxlCSh3b3Jr aW5nIGNvcHkpCkBAIC0xLDE1ICsxLDExIEBACiAjICRGcmVlQlNEJAogCiBQUk9HPQltb3VudF9u d2ZzCi1TUkNTPQltb3VudF9ud2ZzLmMgZ2V0bW50b3B0cy5jCiBNQU49CW1vdW50X253ZnMuOAog Ci1NT1VOVD0JJHsuQ1VSRElSfS8uLi8uLi9zYmluL21vdW50Ci1DRkxBR1MrPSAtRE5XRlMgLUkk e01PVU5UfQorQ0ZMQUdTKz0gLUROV0ZTCiAKLS5QQVRIOgkke01PVU5UfQorRFBBREQ9CSR7TElC TkNQfSAke0xJQklQWH0gJHtMSUJVVElMfQorTERBREQ9CS1sbmNwIC1saXB4IC1sdXRpbAogCi1E UEFERD0JJHtMSUJOQ1B9ICR7TElCSVBYfQotTERBREQ9CS1sbmNwIC1saXB4Ci0KIC5pbmNsdWRl IDxic2QucHJvZy5taz4KSW5kZXg6IHVzci5zYmluL21vdW50X253ZnMvbW91bnRfbndmcy5jCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIHVzci5zYmluL21vdW50X253ZnMvbW91bnRfbndmcy5jCShyZXZpc2lvbiAy NDcxNDkpCisrKyB1c3Iuc2Jpbi9tb3VudF9ud2ZzL21vdW50X253ZnMuYwkod29ya2luZyBjb3B5 KQpAQCAtNDgsMTEgKzQ4LDExIEBACiAjaW5jbHVkZSA8ZXJyLmg+CiAjaW5jbHVkZSA8c3lzZXhp dHMuaD4KICNpbmNsdWRlIDx0aW1lLmg+CisjaW5jbHVkZSA8bW50b3B0cy5oPgogCiAjaW5jbHVk ZSA8bmV0bmNwL25jcF9saWIuaD4KICNpbmNsdWRlIDxuZXRuY3AvbmNwX3JjZmlsZS5oPgogI2lu Y2x1ZGUgPGZzL253ZnMvbndmc19tb3VudC5oPgotI2luY2x1ZGUgIm1udG9wdHMuaCIKIAogI2Rl ZmluZQlOV0ZTX1ZGU05BTUUJIm53ZnMiCiAKSW5kZXg6IHVzci5zYmluL21vdW50X3BvcnRhbGZz L01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIHVzci5zYmluL21vdW50X3BvcnRhbGZzL01ha2VmaWxl CShyZXZpc2lvbiAyNDcxNDkpCisrKyB1c3Iuc2Jpbi9tb3VudF9wb3J0YWxmcy9NYWtlZmlsZQko d29ya2luZyBjb3B5KQpAQCAtMiwxNCArMiwxMyBAQAogIyAkRnJlZUJTRCQKIAogUFJPRz0JbW91 bnRfcG9ydGFsZnMKLVNSQ1M9CW1vdW50X3BvcnRhbGZzLmMgYWN0aXZhdGUuYyBjb25mLmMgY3Jl ZC5jIGdldG1udG9wdHMuYyBwdF9jb25mLmMgXAorU1JDUz0JbW91bnRfcG9ydGFsZnMuYyBhY3Rp dmF0ZS5jIGNvbmYuYyBjcmVkLmMgcHRfY29uZi5jIFwKIAlwdF9leGVjLmMgcHRfZmlsZS5jIHB0 X3BpcGUuYyBwdF90Y3AuYyBwdF90Y3BsaXN0ZW4uYwogTUFOPQltb3VudF9wb3J0YWxmcy44CiAK LU1PVU5UPQkkey5DVVJESVJ9Ly4uLy4uL3NiaW4vbW91bnQKLUNGTEFHUys9LUkke01PVU5UfQog V0FSTlM/PQkzCiAKLS5QQVRIOgkke01PVU5UfQorRFBBREQ9CSR7TElCVVRJTH0KK0xEQUREPQkt bHV0aWwKIAogLmluY2x1ZGUgPGJzZC5wcm9nLm1rPgpJbmRleDogdXNyLnNiaW4vbW91bnRfcG9y dGFsZnMvbW91bnRfcG9ydGFsZnMuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3Iuc2Jpbi9tb3VudF9wb3J0 YWxmcy9tb3VudF9wb3J0YWxmcy5jCShyZXZpc2lvbiAyNDcxNDkpCisrKyB1c3Iuc2Jpbi9tb3Vu dF9wb3J0YWxmcy9tb3VudF9wb3J0YWxmcy5jCSh3b3JraW5nIGNvcHkpCkBAIC01MywxMyArNTMs MTMgQEAKIAogI2luY2x1ZGUgPGVyci5oPgogI2luY2x1ZGUgPGVycm5vLmg+CisjaW5jbHVkZSA8 bW50b3B0cy5oPgogI2luY2x1ZGUgPHN0ZGlvLmg+CiAjaW5jbHVkZSA8c3RkbGliLmg+CiAjaW5j bHVkZSA8c3RyaW5nLmg+CiAjaW5jbHVkZSA8c3lzZXhpdHMuaD4KICNpbmNsdWRlIDx1bmlzdGQu aD4KIAotI2luY2x1ZGUgIm1udG9wdHMuaCIKICNpbmNsdWRlICJwYXRobmFtZXMuaCIKICNpbmNs dWRlICJwb3J0YWxkLmgiCiAKSW5kZXg6IHVzci5zYmluL21vdW50X3NtYmZzL01ha2VmaWxlCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIHVzci5zYmluL21vdW50X3NtYmZzL01ha2VmaWxlCShyZXZpc2lvbiAyNDcx NDkpCisrKyB1c3Iuc2Jpbi9tb3VudF9zbWJmcy9NYWtlZmlsZQkod29ya2luZyBjb3B5KQpAQCAt MSwxNSArMSwxMyBAQAogIyAkRnJlZUJTRCQKIAogUFJPRz0JbW91bnRfc21iZnMKLVNSQ1M9CW1v dW50X3NtYmZzLmMgZ2V0bW50b3B0cy5jCiBNQU49CW1vdW50X3NtYmZzLjgKIAotTU9VTlRESVI9 CSR7LkNVUkRJUn0vLi4vLi4vc2Jpbi9tb3VudAogQ09OVFJJQkRJUj0JJHsuQ1VSRElSfS8uLi8u Li9jb250cmliL3NtYmZzCi1DRkxBR1MrPQktRFNNQkZTIC1JJHtNT1VOVERJUn0gLUkke0NPTlRS SUJESVJ9L2luY2x1ZGUKK0NGTEFHUys9CS1EU01CRlMgLUkke0NPTlRSSUJESVJ9L2luY2x1ZGUK IAotTERBREQ9CS1sc21iIC1sa2ljb252Ci1EUEFERD0JJHtMSUJTTUJ9ICR7TElCS0lDT05WfQor TERBREQ9CS1sc21iIC1sa2ljb252IC1sdXRpbAorRFBBREQ9CSR7TElCU01CfSAke0xJQktJQ09O Vn0gJHtMSUJVVElMfQogCiAjIE5lZWRzIHRvIGJlIGR5bmFtaWNhbGx5IGxpbmtlZCBmb3Igb3B0 aW9uYWwgZGxvcGVuKCkgYWNjZXNzIHRvCiAjIHVzZXJsYW5kIGxpYmljb252IChzZWUgdGhlIC1F IG9wdGlvbikuCkBAIC0xNyw2ICsxNSw1IEBACiBOT19TSEFSRUQ/PQlOTwogCiAuUEFUSDoJJHtD T05UUklCRElSfS9tb3VudF9zbWJmcwotLlBBVEg6ICAke01PVU5URElSfQogCiAuaW5jbHVkZSA8 YnNkLnByb2cubWs+CkluZGV4OiB1c3Iuc2Jpbi9tb3VudGQvTWFrZWZpbGUKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gdXNyLnNiaW4vbW91bnRkL01ha2VmaWxlCShyZXZpc2lvbiAyNDcxNDkpCisrKyB1c3Iuc2Jp bi9tb3VudGQvTWFrZWZpbGUJKHdvcmtpbmcgY29weSkKQEAgLTIsMTUgKzIsMTAgQEAKICMgJEZy ZWVCU0QkCiAKIFBST0c9CW1vdW50ZAotU1JDUz0JbW91bnRkLmMgZ2V0bW50b3B0cy5jCiBNQU49 CWV4cG9ydHMuNSBuZXRncm91cC41IG1vdW50ZC44CiAKLU1PVU5UPSAgJHsuQ1VSRElSfS8uLi8u Li9zYmluL21vdW50Ci1DRkxBR1MrPSAtSSR7TU9VTlR9CiBXQVJOUz89IDIKIAotLlBBVEg6ICR7 TU9VTlR9Ci0KIERQQUREPQkke0xJQlVUSUx9CiBMREFERD0JLWx1dGlsCiAKSW5kZXg6IHVzci5z YmluL21vdW50ZC9tb3VudGQuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3Iuc2Jpbi9tb3VudGQvbW91bnRk LmMJKHJldmlzaW9uIDI0NzE0OSkKKysrIHVzci5zYmluL21vdW50ZC9tb3VudGQuYwkod29ya2lu ZyBjb3B5KQpAQCAtNzMsNiArNzMsNyBAQAogI2luY2x1ZGUgPGdycC5oPgogI2luY2x1ZGUgPGxp YnV0aWwuaD4KICNpbmNsdWRlIDxsaW1pdHMuaD4KKyNpbmNsdWRlIDxtbnRvcHRzLmg+CiAjaW5j bHVkZSA8bmV0ZGIuaD4KICNpbmNsdWRlIDxwd2QuaD4KICNpbmNsdWRlIDxzaWduYWwuaD4KQEAg LTgxLDcgKzgyLDYgQEAKICNpbmNsdWRlIDxzdHJpbmcuaD4KICNpbmNsdWRlIDx1bmlzdGQuaD4K ICNpbmNsdWRlICJwYXRobmFtZXMuaCIKLSNpbmNsdWRlICJtbnRvcHRzLmgiCiAKICNpZmRlZiBE RUJVRwogI2luY2x1ZGUgPHN0ZGFyZy5oPgo= --047d7b5d2e2022af2f04d69f1c80-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 12:20:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 694CE871 for ; Tue, 26 Feb 2013 12:20:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0BCCDF0D for ; Tue, 26 Feb 2013 12:20:43 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1QCKdGc017757; Tue, 26 Feb 2013 14:20:39 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1QCKdGc017757 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1QCKduo017756; Tue, 26 Feb 2013 14:20:39 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 26 Feb 2013 14:20:39 +0200 From: Konstantin Belousov To: Sergey Kandaurov Subject: Re: [patch] Proposal: move getmntopts(3) into libutil Message-ID: <20130226122039.GN2454@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxzxec4+BSbG6TGA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 12:20:44 -0000 --Dxzxec4+BSbG6TGA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 26, 2013 at 02:39:26PM +0300, Sergey Kandaurov wrote: > Hi. >=20 > The functions from sbin/mount/getmntopts.c are used in a bunch of other > stuff like mount_* utilities which have to suck them in as their own > functions in quite a hackish way. getmntopts.c copies are compiled in to > an every utility-consumer instead of being present in one place. Looks > like getmntopts.c was brought together with mount_ufs.c in 4.4BSD-Lite. > After that other mount_* were converted to use getmntopts(). Yes, this is ugly. On the other hand, compiling the functions into mount binaries makes them not to depend on the yet another library. It cannot be an argument for rejecting your patch, only a point to consider. >=20 > The utilities consuming getmntopts.c as currently present in HEAD: > mount_smbfs > fsck_ffs > growfs > mksnap_ffs > mount > mount_cd9660 > mount_ext2fs > mount_fusefs > mount_hpfs > mount_msdosfs > mount_nfs > mount_nullfs > mount_reiserfs > mount_std > mount_udf > mount_unionfs > mount_nwfs > mount_portalfs > mount_smbfs > mountd >=20 > External mount-like utilities may also have difficulties with building > to get getmntopts.c source as this requires /usr/src presence which is > in sync with installed world. Look how mount_fusefs from ports compiles: > # mount_fusefs needs mntopts.h and getmntopts.c from src/sbin/mount/ >=20 > The attached patch moves them to the IMHO architecturally more correct > place: a separate library -lutil. > sbin/mount/mntopts.h -> include/mntopts.h I think the mntopts.h should be moved to lib/libutil then, and installed by libutil Makefile. > sbin/mount/getmntopts.[3c] -> lib/libutil/getmntopts.[3c] I assume that the move is done by 'svn mv' to preserve the history. --Dxzxec4+BSbG6TGA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRLKiXAAoJEJDCuSvBvK1BixgP/3rkFl+/NGrGh6Di2GYUAYu5 FyvlfVbtHsiPQcL3fKOXAFnRTetq3HvB2LIeJceIehSG5XKCiHNqS8R4+DekLEAy wmkNJnyf6TBZvWSzEJ4d4LWrfvdgcHp5BqykDJfknLZ9t3L4FPwR9znOpltv7ga3 zqkT0wkSkEZBmr0KDki6GXp8SxYnQOUVEgOD7qC6kPgpSvpDkzRUWEEAjY1JGSYc Ms9TgWnNLM6ZjQ4IIB5BmGNpgpswh/RqYzoJqw37HQlDUaViP0EJcUllcX0nz201 DTiuuTZM4MBgACVSHi1eW0Uptiv1yMMGSN8z2RDXT2eNFFJigQenJQPoOdTWZn2d FdcqSLeklxPcjG//0kWizphHDDyXV9n4LqBcJ+r074fzMCFPhNV0DlGwR38VyNij 4KU81oPRIUHe89jtgYisH8rtoNqEWlRxUCBCBpdR/S1tTVd8dai0aFo6W2fThYV+ qJ1tyHZI6sMJQh+54ih+opdPAkXHOrr7Js0imRR7PmCpixbTu4BVAKtsuFuHEM/u E1khWyWJXefePx7ZtHqCKH3zZ9zKDRY7PQgFgxmKZD+J38Xn5BkATKD+tRDwczOa fVtVFywwqywxLrkr+rO3mgmxSC1ILqjstj8Z3lg8nsNHhblW4FnvJCX4Cx/XrT1q eJCeIA3ryr9yB0IiIYX0 =yyso -----END PGP SIGNATURE----- --Dxzxec4+BSbG6TGA-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 12:39:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CCA34C4D; Tue, 26 Feb 2013 12:39:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 29D39FAF; Tue, 26 Feb 2013 12:39:14 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1QCd5Sn020384; Tue, 26 Feb 2013 14:39:05 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1QCd5Sn020384 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1QCd4j3020383; Tue, 26 Feb 2013 14:39:04 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 26 Feb 2013 14:39:04 +0200 From: Konstantin Belousov To: Andrew Turner Subject: Re: ARM pcpu changes, was Re: [patch] i386 pmap sysmaps_pcpu[] atomic access Message-ID: <20130226123904.GO2454@kib.kiev.ua> References: <201302201022.29294.jhb@freebsd.org> <201302211043.49906.jhb@freebsd.org> <20130225190920.1b7d348d@bender> <20130225124747.GA21027@ci0.org> <20130226210651.580c46a7@bender> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ECcIMtargrIi2fbc" Content-Disposition: inline In-Reply-To: <20130226210651.580c46a7@bender> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org, Olivier Houchard , Svatopluk Kraus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 12:39:16 -0000 --ECcIMtargrIi2fbc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 26, 2013 at 09:06:51PM +1300, Andrew Turner wrote: > Does anyone know if it is only curthread that needs to be atomic? If so > this should work. Reading the cpuid from the system currently is a > single instruction, however it appears the code will need to be reworked > for use with multiple levels of affinity, for example when there > are clusters of cores the current code will number two cores on > different clusters with the same id. >=20 > I don't think we need to use ldrex/strex to read/write the values, my > understanding is the rest should be safe to access without atomic > functions. I read about ARM architecture some time ago. What I am saying below is not a proposal, but rather a way for me to learn more about the architecture. =46rom my reading of the docs, ARM has the shadow registers, in particular, the r13 (stack pointer) is shadowed for all privileged modes. Is the shadow used by our kernel, is it correctly restored on the context switch ? If yes, you can easily recover the pcb address from the current sp, without accessing any coprocessor registers, and even without any assignment of the global register for curthread (which needs to be done at the kernel entry). Just align the stack start on the 2*PAGE_SIZE boundary (like it is already done for MIPS), and do the mask operation on the sp value to get the end of pcb. This is atomic and context-switch safe. pcb us already per-thread, and can store the thread pointer. More, you can store the curcpu or cpuid pointer into pcb too, and update it on the context switch. amd64 has an architecturally-defined special register (k)gsbase, which effectively must be correctly initialized at each kernel entry, and restored on the return to usermode. Since the initialization on entry and restoration on exit is not atomic wrt the entry/exit itself, amd64 periodically gets a bugs which cause kernel running with user gsbase. This is the fatal bug, destroying the kernel structures and allowing the CPU privilege mode switch for normal user. Using the shadow registers for this purpose eliminate the whole source of the bugs. --ECcIMtargrIi2fbc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRLKznAAoJEJDCuSvBvK1Bm8AP/iYSJSEjXFFSYJRQNrbqdBoF 1eG3YiNNRfy9Kx9AprbX9k80wAQ/GjcfsUJQqDZvooqnW2tSMD2vp7DboGAWiIrH CPcwpZ0P8yXBzn3pnKwnThH8/S5jtRnlvAOls2S0Z3pLxn/XAgeTase8jzOinndF WirQ0igP833EWqSXK5JHwOln96+zvH/3VYRYvSAk931xa1JY3nWMEGB7il/afwRH bpykijqpAoakVZccC0GFxFv+hIKhJDjFIzh2ds4QuDKyErzV57l48m0r2IHbPN8H jXCXgO5N0gjnLAQT3fAAVK0jFgKg9KlLH2EPz7QSfjnG/Z/dRhb41HOze6AP3yU9 +AjpLeSHRj51NcQwydbLg2RrQp+UdeRgPiidYe83c7XSYK4KJJWwRNS2+Xq724gY NWYE6IbOL3v3PIVyPo7OvRz2D7CyhAwevsrhusnm7F0q2be1wzmcbartTvDjnAcv DJ7jibwqsqo2ewgBWiHrWSIDkbHEvSEhh2kWRKHPSH8TP7syXSK+IuP2ntxQQhMm Nqpc4R8+YlaXCJNgqXuzlWoXfiYVr9AsFfqI7ppAtTYPI6ZRagDOdXVP4ySUYVzb Tmm/pWRUCeMQAlHxrpELlrQM3STGBDerQ7QDayONHhpe2ZsVsqXahkQY/BY3Clwr s+4cdWwUpBVL2fbOSzr4 =TI8c -----END PGP SIGNATURE----- --ECcIMtargrIi2fbc-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 12:47:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 96594DE8 for ; Tue, 26 Feb 2013 12:47:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4340D7C for ; Tue, 26 Feb 2013 12:47:14 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A934FB95D; Tue, 26 Feb 2013 07:47:12 -0500 (EST) From: John Baldwin To: Olivier Houchard Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access Date: Mon, 25 Feb 2013 16:26:14 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130225190920.1b7d348d@bender> <20130225124747.GA21027@ci0.org> In-Reply-To: <20130225124747.GA21027@ci0.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302251626.14793.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 26 Feb 2013 07:47:13 -0500 (EST) Cc: Konstantin Belousov , freebsd-current@freebsd.org, Andrew Turner , Svatopluk Kraus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 12:47:14 -0000 On Monday, February 25, 2013 7:47:47 am Olivier Houchard wrote: > On Mon, Feb 25, 2013 at 07:09:20PM +1300, Andrew Turner wrote: > > On Thu, 21 Feb 2013 10:43:49 -0500 > > John Baldwin wrote: > > > > > On Thursday, February 21, 2013 7:53:52 am Svatopluk Kraus wrote: > > > > On Wed, Feb 20, 2013 at 4:22 PM, John Baldwin > > > > wrote: > > > > > On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus wrote: > > > > >> On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov > > > > >> wrote: > > > > >> > On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus > > > > >> > wrote: > > > > >> >> On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov > > > > >> >> wrote: > > > > >> >> Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP > > > > >> >> case was simple. SMP case is more complex and rather new for > > > > >> >> me. Recently, I was solving a problem with PCPU stuff. For > > > > >> >> example, PCPU_GET is implemented by one instruction on i386 > > > > >> >> arch. So, a need of atomicity with respect to interrupts can > > > > >> >> be overlooked. On load-store archs, the implementation which > > > > >> >> works in SMP case is not so simple. And what works in UP case > > > > >> >> (single PCPU), not works in SMP case. Believe me, mysterious > > > > >> >> and sporadic 'mutex not owned' assertions and others ones > > > > >> >> caused by curthreads mess, it takes a while ... > > > > >> > Note that PCPU_GET() is not needed to be atomic. The reason is > > > > >> > that the code which uses its result would not be atomic > > > > >> > (single-instruction or whatever, see below). Thus, either the > > > > >> > preemption should not matter since the action with the per-cpu > > > > >> > data is advisory, as is in the case of i386 pmap you noted. or > > > > >> > some external measures should be applied in advance to the > > > > >> > containing region (which you proposed, by bracing with > > > > >> > sched_pin()). > > > > >> > > > > >> So, it's advisory in the case of i386 pmap... Well, if you can > > > > >> live with that, I can too. > > > > >> > > > > >> > > > > > >> > Also, note that it is not interrupts but preemption which is > > > > >> > concern. > > > > >> > > > > >> Yes and no. In theory, yes, a preemption is a concern. In > > > > >> FreeBSD, however, sched_pin() and critical_enter() and their > > > > >> counterparts are implemented with help of curthread. And > > > > >> curthread definition falls to PCPU_GET(curthread) if not defined > > > > >> in other way. So, curthread should be atomic with respect to > > > > >> interrupts and in general, PCPU_GET() should be too. Note that > > > > >> spinlock_enter() definitions often (always) use curthread too. > > > > >> Anyhow, it's defined in MD code and can be defined for each arch > > > > >> separately. > > > > > > > > > > curthread is a bit magic. :) If you perform a context switch > > > > > during an interrupt (which will change 'curthread') you also > > > > > change your register state. When you resume, the register state > > > > > is also restored. This means that while something like > > > > > 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread' > > > > > never is. However, it is true that actually reading curthread > > > > > has to be atomic. If your read of curthread looks like: > > > > > > > > > > mov , r0 > > > > > add , r0 > > > > > ld r0, r1 > > > > > > > > > > Then that will indeed break. Alpha used a fixed register for > > > > > 'pcpu_reg' (as does ia64 IIRC). OTOH, you might also be able to > > > > > depend on the fact that pc_curthread is the first thing in > > > > > 'struct pcpu' (and always will be, you could add a CTASSERT to > > > > > future-proof). In that case, you can remove the 'add' > > > > > instruction and instead just do: > > > > > > > > > > ld , r1 > > > > > > > > > > which is fine. > > > > > > > > Just for the record. There are three extra (coprocessor) registers > > > > per a core in arm11mpcore (armv6k). Unfortunately only one is > > > > Privileged. The other ones are respectively User Read only and User > > > > Read Write. For now, we are using the Privileged one to store pcpu > > > > pointer (curthread is correctly set during each context switch). > > > > Thus, using a coprocessor register means that reading of curthread > > > > is not a single instruction implementation now. After we figured > > > > out the curthread issue in SMP case, using a fixed (processor) > > > > register for pcpu is an option. Meanwhile, we disable interrupts > > > > before reading of curthread and enable them after. The same is done > > > > for other PCPU stuff. For now we have not stable system enough for > > > > profiling, however, when it will be, it would be interesting to > > > > learn how various implementations of curthread reading impact > > > > system performance. > > > > > > curthread is read _a lot_, so I would expect this to hurt. What we > > > did on Alpha was to use a fixed register for pcpu access, but we used > > > the equivalent of a coprocessor register to also store the value so > > > we could set that fixed register on entry to the kernel (userland was > > > free to use the register for its own purposes). > > > > > > > The current code on ARM is not atomic, it loads the base address of the > > pcpu data from the coprocessor then loads curthread from this address. > > One solution I discussed with Olivier Houchard is to keep the data in > > the coprocessor but to then load it into a dedicated register when we > > enter the kernel. > > > > Reading curthread would then be a single load instruction thanks to > > ARM's ldr using an immediate offset [1], e.g. to load from r12 into r1 > > it would be 'ldr r1, [r12]'. > > > > Wouldn't it be doable to either use the extra coprocessor register for > curthread, setting it when entering the kernel as John suggested, or just > using the privileged one for curthread, and changing get_pcpu() to be > __pcpu[cpuid], and then making sure pcpu accesses are atomic, either by > disabling interrupts or using ldrex/strex ? I take it curthread (and curpcb, > which we can get from curthread) is by far the most used, and it wouldn't hurt > that badly to pessimize the other pcpu variables ? I think you can store pcpu in the coprocessor register. If you always copy it to a dedicated register on kernel entry (say r12) then 'ldr r1, [r12]' to read curthread should be atomic. (Just put a CTASSERT() that offsetof(struct pcpu, pc_curthread) == 0 in arm's machdep.c along with a comment that 'curthread' depends on this. You can then use a custom curthread function like we do on amd64, etc. to hardcode it as a single instruction (and mark it __pure2 while you are at it). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 13:08:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6A4B54D5; Tue, 26 Feb 2013 13:08:04 +0000 (UTC) (envelope-from cognet@ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:150:ca0a:a9ff:fef1:a4c9]) by mx1.freebsd.org (Postfix) with ESMTP id D53991C4; Tue, 26 Feb 2013 13:08:03 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.5/8.14.5) with ESMTP id r1QD7erQ046536; Tue, 26 Feb 2013 14:07:40 +0100 (CET) (envelope-from cognet@ci0.org) Received: (from doginou@localhost) by kanar.ci0.org (8.14.5/8.14.5/Submit) id r1QD7ehU046535; Tue, 26 Feb 2013 14:07:40 +0100 (CET) (envelope-from cognet@ci0.org) X-Authentication-Warning: kanar.ci0.org: doginou set sender to cognet@ci0.org using -f Date: Tue, 26 Feb 2013 14:07:39 +0100 From: Olivier Houchard To: John Baldwin Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access Message-ID: <20130226130739.GA46356@ci0.org> References: <20130225190920.1b7d348d@bender> <20130225124747.GA21027@ci0.org> <201302251626.14793.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201302251626.14793.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 26 Feb 2013 13:55:12 +0000 Cc: Konstantin Belousov , freebsd-current@freebsd.org, Andrew Turner , Svatopluk Kraus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 13:08:04 -0000 On Mon, Feb 25, 2013 at 04:26:14PM -0500, John Baldwin wrote: > On Monday, February 25, 2013 7:47:47 am Olivier Houchard wrote: > > On Mon, Feb 25, 2013 at 07:09:20PM +1300, Andrew Turner wrote: > > > On Thu, 21 Feb 2013 10:43:49 -0500 > > > John Baldwin wrote: > > > > > > > On Thursday, February 21, 2013 7:53:52 am Svatopluk Kraus wrote: > > > > > On Wed, Feb 20, 2013 at 4:22 PM, John Baldwin > > > > > wrote: > > > > > > On Wednesday, February 20, 2013 7:31:08 am Svatopluk Kraus wrote: > > > > > >> On Tue, Feb 19, 2013 at 7:51 PM, Konstantin Belousov > > > > > >> wrote: > > > > > >> > On Mon, Feb 18, 2013 at 11:18:16PM +0100, Svatopluk Kraus > > > > > >> > wrote: > > > > > >> >> On Mon, Feb 18, 2013 at 9:36 PM, Konstantin Belousov > > > > > >> >> wrote: > > > > > >> >> Well, I'm taking a part on porting FreeBSD to ARM11mpcore. UP > > > > > >> >> case was simple. SMP case is more complex and rather new for > > > > > >> >> me. Recently, I was solving a problem with PCPU stuff. For > > > > > >> >> example, PCPU_GET is implemented by one instruction on i386 > > > > > >> >> arch. So, a need of atomicity with respect to interrupts can > > > > > >> >> be overlooked. On load-store archs, the implementation which > > > > > >> >> works in SMP case is not so simple. And what works in UP case > > > > > >> >> (single PCPU), not works in SMP case. Believe me, mysterious > > > > > >> >> and sporadic 'mutex not owned' assertions and others ones > > > > > >> >> caused by curthreads mess, it takes a while ... > > > > > >> > Note that PCPU_GET() is not needed to be atomic. The reason is > > > > > >> > that the code which uses its result would not be atomic > > > > > >> > (single-instruction or whatever, see below). Thus, either the > > > > > >> > preemption should not matter since the action with the per-cpu > > > > > >> > data is advisory, as is in the case of i386 pmap you noted. or > > > > > >> > some external measures should be applied in advance to the > > > > > >> > containing region (which you proposed, by bracing with > > > > > >> > sched_pin()). > > > > > >> > > > > > >> So, it's advisory in the case of i386 pmap... Well, if you can > > > > > >> live with that, I can too. > > > > > >> > > > > > >> > > > > > > >> > Also, note that it is not interrupts but preemption which is > > > > > >> > concern. > > > > > >> > > > > > >> Yes and no. In theory, yes, a preemption is a concern. In > > > > > >> FreeBSD, however, sched_pin() and critical_enter() and their > > > > > >> counterparts are implemented with help of curthread. And > > > > > >> curthread definition falls to PCPU_GET(curthread) if not defined > > > > > >> in other way. So, curthread should be atomic with respect to > > > > > >> interrupts and in general, PCPU_GET() should be too. Note that > > > > > >> spinlock_enter() definitions often (always) use curthread too. > > > > > >> Anyhow, it's defined in MD code and can be defined for each arch > > > > > >> separately. > > > > > > > > > > > > curthread is a bit magic. :) If you perform a context switch > > > > > > during an interrupt (which will change 'curthread') you also > > > > > > change your register state. When you resume, the register state > > > > > > is also restored. This means that while something like > > > > > > 'PCPU_GET(cpuid)' might be stale after you read it, 'curthread' > > > > > > never is. However, it is true that actually reading curthread > > > > > > has to be atomic. If your read of curthread looks like: > > > > > > > > > > > > mov , r0 > > > > > > add , r0 > > > > > > ld r0, r1 > > > > > > > > > > > > Then that will indeed break. Alpha used a fixed register for > > > > > > 'pcpu_reg' (as does ia64 IIRC). OTOH, you might also be able to > > > > > > depend on the fact that pc_curthread is the first thing in > > > > > > 'struct pcpu' (and always will be, you could add a CTASSERT to > > > > > > future-proof). In that case, you can remove the 'add' > > > > > > instruction and instead just do: > > > > > > > > > > > > ld , r1 > > > > > > > > > > > > which is fine. > > > > > > > > > > Just for the record. There are three extra (coprocessor) registers > > > > > per a core in arm11mpcore (armv6k). Unfortunately only one is > > > > > Privileged. The other ones are respectively User Read only and User > > > > > Read Write. For now, we are using the Privileged one to store pcpu > > > > > pointer (curthread is correctly set during each context switch). > > > > > Thus, using a coprocessor register means that reading of curthread > > > > > is not a single instruction implementation now. After we figured > > > > > out the curthread issue in SMP case, using a fixed (processor) > > > > > register for pcpu is an option. Meanwhile, we disable interrupts > > > > > before reading of curthread and enable them after. The same is done > > > > > for other PCPU stuff. For now we have not stable system enough for > > > > > profiling, however, when it will be, it would be interesting to > > > > > learn how various implementations of curthread reading impact > > > > > system performance. > > > > > > > > curthread is read _a lot_, so I would expect this to hurt. What we > > > > did on Alpha was to use a fixed register for pcpu access, but we used > > > > the equivalent of a coprocessor register to also store the value so > > > > we could set that fixed register on entry to the kernel (userland was > > > > free to use the register for its own purposes). > > > > > > > > > > The current code on ARM is not atomic, it loads the base address of the > > > pcpu data from the coprocessor then loads curthread from this address. > > > One solution I discussed with Olivier Houchard is to keep the data in > > > the coprocessor but to then load it into a dedicated register when we > > > enter the kernel. > > > > > > Reading curthread would then be a single load instruction thanks to > > > ARM's ldr using an immediate offset [1], e.g. to load from r12 into r1 > > > it would be 'ldr r1, [r12]'. > > > > > > > Wouldn't it be doable to either use the extra coprocessor register for > > curthread, setting it when entering the kernel as John suggested, or just > > using the privileged one for curthread, and changing get_pcpu() to be > > __pcpu[cpuid], and then making sure pcpu accesses are atomic, either by > > disabling interrupts or using ldrex/strex ? I take it curthread (and curpcb, > > which we can get from curthread) is by far the most used, and it wouldn't hurt > > that badly to pessimize the other pcpu variables ? > > I think you can store pcpu in the coprocessor register. If you always copy > it to a dedicated register on kernel entry (say r12) then 'ldr r1, [r12]' to > read curthread should be atomic. (Just put a CTASSERT() that > offsetof(struct pcpu, pc_curthread) == 0 in arm's machdep.c along with a comment > that 'curthread' depends on this. You can then use a custom curthread function > like we do on amd64, etc. to hardcode it as a single instruction (and mark it > __pure2 while you are at it). > Yes I was just trying to avoid dedicating a register to pcpu :) I have no clue if performances-wise it's better to dedicate a register, or to just optimize curthread/curpcb, and make access to other pcpu vars more expensive. Regards, Olivier From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 14:04:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D1EB8245 for ; Tue, 26 Feb 2013 14:04:55 +0000 (UTC) (envelope-from zaphod@berentweb.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id B28876B8 for ; Tue, 26 Feb 2013 14:04:55 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UAL9E-0005UJ-PA for freebsd-current@freebsd.org; Tue, 26 Feb 2013 06:04:48 -0800 Date: Tue, 26 Feb 2013 06:04:48 -0800 (PST) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1361887488759-5790612.post@n5.nabble.com> Subject: distcc does not work with clang MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 14:04:55 -0000 On FreeBSD 10.0-CURRENT #5 r247234 If I try to compile world, or any clang-dependent port, distcc returns an error: # make buildworld CC=distcc -------------------------------------------------------------- >>> Building an up-to-date make(1) -------------------------------------------------------------- "/usr/share/mk/bsd.compiler.mk", line 17: Unable to determine compiler type for distcc *** [make] Error code 1 # make CC=distcc -C ports-mgmt/pkg ===> License BSD accepted by the user .....code output... ===> Building for pkg-1.0.8 "/usr/share/mk/bsd.compiler.mk", line 17: Unable to determine compiler type for distcc *** [do-build] Error code 1 If, on the other hand I try to build a gcc-based port, no problems: # make -j8 CC=distcc -C lang/gcc completes nicely. No special CC/GCC settings in make.conf. All ccache references disabled for distcc debugging. Anyone have thoughts about this problem? Thanks. -- View this message in context: http://freebsd.1045724.n5.nabble.com/distcc-does-not-work-with-clang-tp5790612.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 16:39:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2760C397 for ; Tue, 26 Feb 2013 16:39:38 +0000 (UTC) (envelope-from zaphod@berentweb.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id EDB42E95 for ; Tue, 26 Feb 2013 16:39:37 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UANZ2-0007cE-Vz for freebsd-current@freebsd.org; Tue, 26 Feb 2013 08:39:36 -0800 Date: Tue, 26 Feb 2013 08:39:36 -0800 (PST) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1361896776985-5790640.post@n5.nabble.com> In-Reply-To: <1361887488759-5790612.post@n5.nabble.com> References: <1361887488759-5790612.post@n5.nabble.com> Subject: Re: distcc does not work with clang MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:39:38 -0000 *UPDATE:* I got DISTCC to "partially" work by setting environment variable as CCACHE_PREFIX=/usr/local/bin/distcc It works partially, because it does not distribute compile requests correctly: - If the compiler is gcc46, compile orders get correctly distributed to build-farm - If the compiler is clang, compile orders only get accepted by localhost (127.0.0.1) but not members of the build-farm. Outsource compile orders return with "connection refused" message. I should note that the build-farm consists only of diskless clients PXE booting from semi-jail environment on host. After this find, I logged into one of the client machines to check for clang: # c -v FreeBSD clang version 3.2 etc... # gcc -v gcc: Command not found On the host machine I do not get this gcc error. -- View this message in context: http://freebsd.1045724.n5.nabble.com/distcc-does-not-work-with-clang-tp5790612p5790640.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 18:35:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 52B7BE02 for ; Tue, 26 Feb 2013 18:35:53 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3755E1714 for ; Tue, 26 Feb 2013 18:35:53 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id E16D41A3C19 for ; Tue, 26 Feb 2013 10:35:44 -0800 (PST) Message-ID: <512D0080.9050208@mu.org> Date: Tue, 26 Feb 2013 10:35:44 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [patch] Proposal: move getmntopts(3) into libutil References: <20130226122039.GN2454@kib.kiev.ua> In-Reply-To: <20130226122039.GN2454@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 18:35:53 -0000 On 2/26/13 4:20 AM, Konstantin Belousov wrote: > On Tue, Feb 26, 2013 at 02:39:26PM +0300, Sergey Kandaurov wrote: >> Hi. >> >> The functions from sbin/mount/getmntopts.c are used in a bunch of other >> stuff like mount_* utilities which have to suck them in as their own >> functions in quite a hackish way. getmntopts.c copies are compiled in to >> an every utility-consumer instead of being present in one place. Looks >> like getmntopts.c was brought together with mount_ufs.c in 4.4BSD-Lite. >> After that other mount_* were converted to use getmntopts(). > Yes, this is ugly. On the other hand, compiling the functions into > mount binaries makes them not to depend on the yet another library. > It cannot be an argument for rejecting your patch, only a point to > consider. > >> The utilities consuming getmntopts.c as currently present in HEAD: >> mount_smbfs >> fsck_ffs >> growfs >> mksnap_ffs >> mount >> mount_cd9660 >> mount_ext2fs >> mount_fusefs >> mount_hpfs >> mount_msdosfs >> mount_nfs >> mount_nullfs >> mount_reiserfs >> mount_std >> mount_udf >> mount_unionfs >> mount_nwfs >> mount_portalfs >> mount_smbfs >> mountd >> >> External mount-like utilities may also have difficulties with building >> to get getmntopts.c source as this requires /usr/src presence which is >> in sync with installed world. Look how mount_fusefs from ports compiles: >> # mount_fusefs needs mntopts.h and getmntopts.c from src/sbin/mount/ >> >> The attached patch moves them to the IMHO architecturally more correct >> place: a separate library -lutil. >> sbin/mount/mntopts.h -> include/mntopts.h > I think the mntopts.h should be moved to lib/libutil then, and installed > by libutil Makefile. > >> sbin/mount/getmntopts.[3c] -> lib/libutil/getmntopts.[3c] > I assume that the move is done by 'svn mv' to preserve the history. Agree with all of Konstantin's review. Looks very good. -Alfred From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 18:53:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BB0D7968; Tue, 26 Feb 2013 18:53:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 98E4218DC; Tue, 26 Feb 2013 18:53:03 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 124A5B958; Tue, 26 Feb 2013 13:53:03 -0500 (EST) From: John Baldwin To: matt Subject: Re: Fixing X220 Video The Right Way Date: Tue, 26 Feb 2013 13:46:46 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <512A6FFF.2060603@gmail.com> <512C380D.5030506@gmail.com> In-Reply-To: <512C380D.5030506@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201302261346.46197.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 26 Feb 2013 13:53:03 -0500 (EST) Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 18:53:03 -0000 On Monday, February 25, 2013 11:20:29 pm matt wrote: > On 02/25/13 18:33, Adrian Chadd wrote: > > [101232] acpi_video0: on vgapci0 > > found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 > > > > And what do I do with acpi_get_handle ? > > > > > > > > > I threw printfs into acpi_video, not sure if that would work for both > vgapci or not. > I'm not sure if I wiped out my debug patches yet, I may have a patch. > Basically the idea is to figure out which paths in the DSDT are getting > attached to the vgapci devices. devinfo -v already tells you that. For example: nexus0 acpi0 pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0 pci0 hostb0 pnpinfo vendor=0x8086 device=0x0100 subvendor=0x8086 subdevice=0x2010 class=0x060000 at slot=0 function=0 pcib1 pnpinfo vendor=0x8086 device=0x0101 subvendor=0x8086 subdevice=0x2010 class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.PEG1 pci1 vgapci0 pnpinfo vendor=0x10de device=0x0605 subvendor=0x3842 subdevice=0xc973 class=0x030000 at slot=0 function=0 (My desktop doesn't have acpi_video and doesn't have an ACPI handle for the vgapci device, but you can see how it displays the handle for other PCI devices like pcib1 which are in the ACPI namespace.) > It seems like we could either try to find these paths on affected > models, or have a tunable override for acpi_video. Note that the Linux discussion you posted seems a bit off. The _ADR is not supposed to be unique to the entire system. For PCI devices, _ADR contains the PCI device (slot) and function (as slot << 16 | func), and the domain:bus portion of the address is implied by the parent PCI bus device in the ACPI namespace. Thus, the specific handle assigned by ACPI is for the exact PCI location of the requisite vgapci device. If your BIOS lies it is hard for us to do anything useful, at least automatically. Do the other devices in your system that have _DOD or _DOS methods show up as unknown ACPI devices in your devinfo -v output? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 19:11:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EE38DF61 for ; Tue, 26 Feb 2013 19:11:26 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 7E80B19C0 for ; Tue, 26 Feb 2013 19:11:26 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id gw10so4303445lab.27 for ; Tue, 26 Feb 2013 11:11:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TGvqfoyusu/0N3vhYZLhZN+p1E+Kj4WKAtebD2zhspw=; b=tGubtp7kGUufQH3a6OluY9DWVJvKpoulXc3CvlkB0LhKNgV32tezzf0XI0L5lAIckX yGMe1pcCbA0vkXcshtCzDR88QrdnZU8we+ox53DKjGQIPtBlCEHLZw9MZLQZJfsxclHu y34i/xwOjIaOUo+8g7pkuWZe9tHniudaXJLOtVZLqTMBk7vv/CxbCMSDo0l3LYtRU/hA mh3oPbEUjYopZOxFTFznRJfSTXaiq9zV7rm8klLNItH0efDfg9USyJV+sRsRtEo/zH7/ pfhk9cAGbOcCxDK5sKPxA34/vrE9j0cQqNXSZbHIUukhxrZ+mk2nU3DGVrjn1PdaOucJ 5Law== MIME-Version: 1.0 X-Received: by 10.112.36.168 with SMTP id r8mr992884lbj.131.1361905885419; Tue, 26 Feb 2013 11:11:25 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.85.198 with HTTP; Tue, 26 Feb 2013 11:11:25 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Feb 2013 11:11:25 -0800 X-Google-Sender-Auth: EvaB89FGACIEetETdiUBkzeHFiA Message-ID: Subject: Re: [patch] Proposal: move getmntopts(3) into libutil From: Craig Rodrigues To: Sergey Kandaurov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 19:11:27 -0000 On Tue, Feb 26, 2013 at 3:39 AM, Sergey Kandaurov wrote: > Hi. > > > External mount-like utilities may also have difficulties with building > to get getmntopts.c source as this requires /usr/src presence which is > in sync with installed world. Look how mount_fusefs from ports compiles: > # mount_fusefs needs mntopts.h and getmntopts.c from src/sbin/mount/ > I have no object in moving getmntopts.c to libutil. I'll give some history to some of this stuff, to the best of my ability. A few years ago, phk@ made a big change by introducing the nmount() system call to replace mount(). Look at all mount-related commits around this time: http://lists.freebsd.org/pipermail/cvs-src/2004-December/author.html#36373 This required changing every file system, and for old file systems which supported the "classic mount" cmount(), in each file system, the cmount() call had to internally call the nmount() code. In addition, phk made a pass to clean up all the userland mount programs to use nmount(). There was a lot of duplicated ("copy and pasted") code in various mount programs. I helped in the effort to clean up some of the userland mount() programs. pjd@ proposed to make the main /sbin/mount load a shared library for each specific file system, and each shared library would have file-system specific mount logic. For example: mount -t newfoofs /dev/blah /mnt would internally do something like: dlopen("libmount_newfoofs",.....); phk@ opposed this approach, saying that it could lead to ABI/API problems, library mismatches, etc. So we kept the existing approach. I modified /sbin/mount to by default use nmount() and only for certain file systems, exec an external mount program. phk's ideas for getmntopts.c was always to keep it as a place where "library-like" functions for mounting file systems would be kept. To avoid library mismatch problems, it was kept has a C file directly compiled into the mount programs. I have no problems keeping getmntopts.c in a separate library. libutil is fine, or even a separate libmntutil (or whatever). Just keep in mind the issues that could possibly come up if there is a mismatch between the userland mount programs, and the library which contains getmntopts.c Other than that, you proposal is quite reasonable, and I have no issue with it. Thanks! -- Craig -- Craig From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 22:42:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0AD9A853 for ; Tue, 26 Feb 2013 22:42:06 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from vps.van-laarhoven.org (www.hibma.org [178.21.117.90]) by mx1.freebsd.org (Postfix) with ESMTP id AA41C705 for ; Tue, 26 Feb 2013 22:42:05 +0000 (UTC) Received: from [192.168.178.106] (thuis.van-laarhoven.org [80.100.41.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by vps.van-laarhoven.org (Postfix) with ESMTPSA id 5AA465F22C6 for ; Tue, 26 Feb 2013 23:40:14 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: No console, not even serial, does not work (init fails) - init from HEAD works From: Nick Hibma In-Reply-To: Date: Tue, 26 Feb 2013 23:41:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2820BD0B-BCFA-4068-AFE7-D123630828E4@van-laarhoven.org> References: <96A2B40B-4191-4C4F-8AA5-39526E252D40@van-laarhoven.org> To: =?windows-1252?Q?=93FreeBSD_Current_Mailing_List=94?= X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 22:42:06 -0000 [feels like I am talking to myself in this thread ...] After copying the /usr/src/sbin/init/ directory from HEAD to 8.3-RELEASE = and building init there (without changes), things started working again, = and the image now succesfully boots. Thanks for that. The downside of this approach is the lack of logging of the output of = the console output. I've tried quickly to throw together a 'null' = console which would make the console output at least appear in the = output of 'dmesg -a', but that change requires a tty device, which I = couldn' be asked to throw together. Ed was going to think this over, = especially because a null console might come in handy in jails. Hope this is of use to anyone. Nick Hibma nick@van-laarhoven.org How many todos are on YOUR To Do lists? - GTD On 19 Feb 2013, at 10:03, Nick Hibma wrote: > Ed sent me a answer to my ramblings: >=20 > "It is indeed true that init(8) is a bit picky when you don't have a > console. If /dev/console cannot be opened, init(8) will just break > completely. This has been fixed in FreeBSD -HEAD, where I've extended > init(8) to handle this gracefully, specifically for cases where you > have hardware without a console or potentially want to run init(8) in > a jail (though we're not there yet)." >=20 > http://svnweb.freebsd.org/base?view=3Drevision&revision=3D232977 >=20 > I'll try that, and will follow up here. >=20 > Nick Hibma > nick@van-laarhoven.org >=20 > Collect, process, organize, review and do. - GTD >=20 > On 18 Feb 2013, at 20:30, Nick Hibma wrote: >=20 >> We run our NanoBSD images on Soekris and ALIX hardware. In some cases = we need all available serial ports for other hardware like GPS, and = modems. The boards have no video, so with all serial ports unavailable = as a console no other console is available. >>=20 >> The problem is that FreeBSD does not handle well the case where there = is no console at all: >>=20 >> 1) http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dbin/102515 >>=20 >> fsck_ufs crashes (6.1-STABLE). Because of the unitialised console = libc somehow gets corrupted and crashes fsck_ufs. This problem can be = circumvented by replacing 'fsck -p' with 'fsck < /dev/null > /dev/null'. >>=20 >> 2) In 8.3-RELEASE init exits prematurely because it cannot open = /dev/console for reading and writing in setctty(). Removing the calls to = _exit(1) in that function makes the boot complete. I haven't checked = whether the fsck_ufs problem still appears as our builds run with a = patched rc.d script. >>=20 >>=20 >> As far as I can see this is still a problem in CURRENT. >>=20 >>=20 >> My attempt at resolving this was to create a null terminal in = dev/null/null.c, see the patch below, but that did not work as expected. = After booting the system with a modified init the response to 'echo > = /dev/console' was 'Device not configured'. I've added another CN_* = priority to make sure a null console does not take precedence over for = example gdb console. >>=20 >>=20 >> Any pointers as to who/how to resolve this issue? Any reason why the = null console approach does not work? >>=20 >> Nick Hibma >> nick@van-laarhoven.org >>=20 >> GTD: Time management for chaotic people. >>=20 >> Index: /usr/src/sys/sys/cons.h >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/sys/sys/cons.h (revision 242660) >> +++ /usr/src/sys/sys/cons.h (working copy) >> @@ -69,10 +69,11 @@ >>=20 >> /* values for cn_pri - reflect our policy for console selection */ >> #define CN_DEAD 0 /* device doesn't exist */ >> -#define CN_LOW 1 /* device is a last restort only = */ >> -#define CN_NORMAL 2 /* device exists but is nothing special = */ >> -#define CN_INTERNAL 3 /* "internal" bit-mapped display */ >> -#define CN_REMOTE 4 /* serial interface with remote bit set = */ >> +#define CN_NULL 1 /* no console at all */ >> +#define CN_LOW 2 /* device is a last restort only = */ >> +#define CN_NORMAL 3 /* device exists but is nothing special = */ >> +#define CN_INTERNAL 4 /* "internal" bit-mapped display */ >> +#define CN_REMOTE 5 /* serial interface with remote bit set = */ >>=20 >> /* Values for cn_flags. */ >> #define CN_FLAG_NODEBUG 0x00000001 /* Not supported with = debugger. */ >> Index: /usr/src/sys/dev/null/null.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/sys/dev/null/null.c (revision 242660) >> +++ /usr/src/sys/dev/null/null.c (working copy) >> @@ -41,6 +41,9 @@ >> #include >> #include >>=20 >> +#include >> +#include >> + >> #include >>=20 >> /* For use with destroy_dev(9). */ >> @@ -173,3 +176,45 @@ >>=20 >> DEV_MODULE(null, null_modevent, NULL); >> MODULE_VERSION(null, 1); >> + >> +static cn_probe_t null_cnprobe; >> +static cn_init_t null_cninit; >> +static cn_term_t null_cnterm; >> +static cn_getc_t null_cngetc; >> +static cn_putc_t null_cnputc; >> + >> +CONSOLE_DRIVER(null); >> + >> +static void >> +null_cnprobe(struct consdev *cp) >> +{ >> + sprintf(cp->cn_name, "null"); >> + cp->cn_pri =3D CN_NULL; >> +} >> + >> +static void >> +null_cninit(struct consdev *cp) >> +{ >> +} >> + >> + >> +static void >> +null_cnputc(struct consdev *cp, int c) >> +{ >> + (void) cp; >> + >> + (void) c; >> +} >> + >> +static int >> +null_cngetc(struct consdev * cp) >> +{ >> + (void) cp; >> +=09 >> + return -1; >> +} >> + >> +static void >> +null_cnterm(struct consdev * cp) >> +{ >> +} >>=20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 01:39:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F0497E16 for ; Wed, 27 Feb 2013 01:39:56 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by mx1.freebsd.org (Postfix) with ESMTP id A5A8BFF7 for ; Wed, 27 Feb 2013 01:39:56 +0000 (UTC) Received: by mail-ve0-f170.google.com with SMTP id 14so34328vea.15 for ; Tue, 26 Feb 2013 17:39:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=NXc0zAJ18re//XDkkuGXBUDJuXwu9n4InVv4mfayNv0=; b=ThQyhLa+YRe4yj2zxj7kAIx8ghEG/b2GZfX1qET82dkrAwUlligqjSks2szjUljqaf IBC7L/Gv7GQQcAYZMNDaqK177wf/NiZcO3srCi24aT3KTcCvpdvdquKXsr4xX9geC8SU C8wvFCWFB/Q2mCvhEpRnJXmqe/BpJfa/fFHMNtuvYcnhR+0rhWbriS1RQ9YUGvGX/7hz TQlRlIMdPz0A++Qfb0zUlg2PP/tdhB3HGlEP/5wmyFKhOH7Z7tJpUKkjlMG6fKkSY+ZQ GVsPIYp1C25Go0V5aYO6zLsJNylI3+d7h6r+Iv5wvWTLxJVH7MjvBkZWCWixjzE/8XUd LCxA== MIME-Version: 1.0 X-Received: by 10.58.154.229 with SMTP id vr5mr193617veb.11.1361929195939; Tue, 26 Feb 2013 17:39:55 -0800 (PST) Received: by 10.58.170.36 with HTTP; Tue, 26 Feb 2013 17:39:55 -0800 (PST) Date: Tue, 26 Feb 2013 17:39:55 -0800 Message-ID: Subject: Response of *.freebsd.org websites are very slow From: Mehmet Erol Sanliturk To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 01:39:57 -0000 Dear All , I have installed https://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/10.0-HEAD-r247266-JPSNAP with a very nice steps flow and it has booted very well . During pkg_add -rv xorg it become necessary to try many times , and for other packages the action is the similar . The response of pkg_add is "Address could not be found ." . Actually , this situation is started after security incident occurrence . Access to *.freebsd.org sites are so slow that many times , web browsers Firefox , Chromium are displaying a message to tell : "Site is not found ... Try once more ..." To access to other sites in US may be considered instantaneous here in Turkey . I think a solution may be supplied for this problem . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 02:33:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9524538C; Wed, 27 Feb 2013 02:33:46 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5D710280; Wed, 27 Feb 2013 02:33:46 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id kq12so112925pab.15 for ; Tue, 26 Feb 2013 18:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8LiL99Bmq+xNM42JSz8TEHPxIx/BMzvsPekUfb/OxSQ=; b=L+K/0iocCn76PA6UsCXnTUfhSLwRqtANzB8Dme6pEQkIg1SjKlBZj6HRT0ErMM5o4W /W6ToTlGtK5QjmgWXJf53+0F78ZnnaDrilz8NvqLPhQvLoM0E+IZAZRnWpnFwLsy4XTE g51+7quBNfKvmNYqEwWp1rc9lPwD06K2e0N6v1tyC/W/hgGWTyDnowL2IxRjzLssPgQa sO+dK+np6ZVgRVxIN3HBzcgtI12QSiVogBJq5DWdnqs48uS3ztkI4EKtXDANp6GYrje6 7OQHghGzCoBc/CTlAx1BTPMgwl+HMM8QLIWzuXGGSQz+Ucos6oTtsu+SrrMVNrzQF3V0 wQwA== X-Received: by 10.66.122.74 with SMTP id lq10mr4902075pab.189.1361932420532; Tue, 26 Feb 2013 18:33:40 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id 1sm2845981pbg.18.2013.02.26.18.33.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 18:33:39 -0800 (PST) Message-ID: <512D7041.50608@gmail.com> Date: Tue, 26 Feb 2013 18:32:33 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130224 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Baldwin Subject: Re: Fixing X220 Video The Right Way References: <512A6FFF.2060603@gmail.com> <512C380D.5030506@gmail.com> <201302261346.46197.jhb@freebsd.org> In-Reply-To: <201302261346.46197.jhb@freebsd.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 02:33:46 -0000 On 02/26/13 10:46, John Baldwin wrote: > On Monday, February 25, 2013 11:20:29 pm matt wrote: >> On 02/25/13 18:33, Adrian Chadd wrote: >>> [101232] acpi_video0: on vgapci0 >>> found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 >>> >>> And what do I do with acpi_get_handle ? >>> >>> >>> >>> >> I threw printfs into acpi_video, not sure if that would work for both >> vgapci or not. >> I'm not sure if I wiped out my debug patches yet, I may have a patch. >> Basically the idea is to figure out which paths in the DSDT are getting >> attached to the vgapci devices. > devinfo -v already tells you that. > > For example: > > nexus0 > acpi0 > pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0 > pci0 > hostb0 pnpinfo vendor=0x8086 device=0x0100 subvendor=0x8086 > subdevice=0x2010 class=0x060000 at slot=0 function=0 > pcib1 pnpinfo vendor=0x8086 device=0x0101 subvendor=0x8086 > subdevice=0x2010 class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.PEG1 > pci1 > vgapci0 pnpinfo vendor=0x10de device=0x0605 subvendor=0x3842 > subdevice=0xc973 class=0x030000 at slot=0 function=0 > > (My desktop doesn't have acpi_video and doesn't have an ACPI handle for the > vgapci device, but you can see how it displays the handle for other PCI > devices like pcib1 which are in the ACPI namespace.) > >> It seems like we could either try to find these paths on affected >> models, or have a tunable override for acpi_video. > Note that the Linux discussion you posted seems a bit off. The _ADR is > not supposed to be unique to the entire system. For PCI devices, _ADR > contains the PCI device (slot) and function (as slot << 16 | func), and > the domain:bus portion of the address is implied by the parent PCI bus > device in the ACPI namespace. Thus, the specific handle assigned by ACPI > is for the exact PCI location of the requisite vgapci device. If your > BIOS lies it is hard for us to do anything useful, at least automatically. > > Do the other devices in your system that have _DOD or _DOS methods show > up as unknown ACPI devices in your devinfo -v output? It's not in devinfo at all for me, Adrian may have a different situation. So my laptop has _SB.PCI0.PEG.VID and _SB.PCI0.VID Only _SB.PCI0.VID is represented in devinfo -rv. As far as I know, PEG is not a "real" device, but an abstraction, possibly for Optimus use. It makes calls to \VIGD (integrated graphics?) and \ISOP (isOptimus?) This is potentially the broken bios part of things. I think I have multiple ACPI devices for a single physical device, and pci is attaching the wrong ACPI device to the physical device in an ivar. acpi_video happily uses this ivar to attempt to control video brightness. I could be entirely wrong on that, all I do know is that the working handle doesn't get used and the useless handle does. Matt Matt From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 10:23:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8D702F91 for ; Wed, 27 Feb 2013 10:23:45 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0AF765 for ; Wed, 27 Feb 2013 10:23:44 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id eb20so378492lab.31 for ; Wed, 27 Feb 2013 02:23:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yGArckeRvR6mA2LPxKZrSWGtOQAGxlGNH2sS+KmqkfA=; b=MHBjW8fdLCykjZpCqvfH2oFyvB7V9e+CowQnDpUOeiCgc+ZJYUzY91Q0MUbYL6vrSB EqBvWCBU9j74ncbwdKG3bfVNFXboVSnBlaVanrYjyCkj3wVMSPd3GsEi3OSqdVxpClrj EwFgLx5dHeeco6bh0TogJrqP0kjMFF56rA6H74RatD859SCyN5hlbh65i3mgTi37owlA pZgmltqTzdzU29/T1IdI8/ZXc2RwFm/ZIEuQucl+z4QENQcivBZsaJW4QaehfHSDMDeP 4WROIEL7TIJe8DVB2oBIigZaHdagC5xW6IksB3cDKzBKJ5BswKSBhm5cn6srqfazwOjC 6k6w== MIME-Version: 1.0 X-Received: by 10.112.54.6 with SMTP id f6mr1875393lbp.104.1361960623414; Wed, 27 Feb 2013 02:23:43 -0800 (PST) Received: by 10.112.80.133 with HTTP; Wed, 27 Feb 2013 02:23:43 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Feb 2013 11:23:43 +0100 Message-ID: Subject: Re: Response of *.freebsd.org websites are very slow From: Daniel Nebdal To: Mehmet Erol Sanliturk Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 10:23:45 -0000 I think you're supposed to be automatically sent to the mirror that is closest to you - for some value of "closest". If the mirror you're getting has issues, that might show up like this. Could you post the output of "traceroute ftp.freebsd.org" ? It should show which mirror you're getting, and perhaps if there are any obvious problems on the way. Also, you can try setting PACKAGEROOT to e.g. ftp://ftp.beastie.tdk.net , to see if that makes pkg_add work better. That's the mirror closest to me - if that one works ok for you, it's another sign that the problem is with your local mirror. :) -- Daniel Nebdal On Wed, Feb 27, 2013 at 2:39 AM, Mehmet Erol Sanliturk wrote: > Dear All , > > I have installed > > https://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/10.0-HEAD-r247266-JPSNAP > > with a very nice steps flow and it has booted very well . > > During > > pkg_add -rv xorg > > it become necessary to try many times , and for other packages the action > is the similar . > > The response of pkg_add is "Address could not be found ." . > > Actually , this situation is started after security incident occurrence . > > Access to *.freebsd.org sites are so slow that many times , web browsers > Firefox , Chromium are displaying a message to tell : > "Site is not found ... Try once more ..." > > To access to other sites in US may be considered instantaneous here in > Turkey . > > > I think a solution may be supplied for this problem . > > > Thank you very much . > > Mehmet Erol Sanliturk > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 10:38:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8B6D22DB for ; Wed, 27 Feb 2013 10:38:09 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 082B07F0 for ; Wed, 27 Feb 2013 10:38:08 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.5/8.14.5) with ESMTP id r1RAbvN5046350 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 27 Feb 2013 12:37:58 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <512DE205.4010202@digsys.bg> Date: Wed, 27 Feb 2013 12:37:57 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.12) Gecko/20130125 Thunderbird/10.0.12 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Response of *.freebsd.org websites are very slow References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 10:38:09 -0000 On 27.02.13 12:23, Daniel Nebdal wrote: > I think you're supposed to be automatically sent to the mirror that is > closest to you - for some value of "closest". If the mirror you're > getting has issues, that might show up like this. Could you post the > output of "traceroute ftp.freebsd.org" ? It should show which mirror > you're getting, and perhaps if there are any obvious problems on the > way. I believe, in his case that would be "traceroute ftp.tr.freebsd.org". The list of mirrors is here http://www.freebsd.org/doc/handbook/mirrors-ftp.html in any case, "anything *.freebsd.org" actually refers to plenty of hosts all over the world -- some might be slow, some very fast. On the other hand, "Address could not be found" type of errors indicates something else than "fast" or "slow". Daniel From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 10:52:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AC47C584 for ; Wed, 27 Feb 2013 10:52:49 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id 35DBB862 for ; Wed, 27 Feb 2013 10:52:49 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id fo12so404596lab.14 for ; Wed, 27 Feb 2013 02:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qTfTBWXHw6IA+DS+isqISzgE4rq80wHZ+jlBSerBNYA=; b=PEDJzYhxDQ9Gs1hDJiX6KDJjk7K9uxWduXfMkQgT1c3T1VGHpxe3Mf5u+j+Syax4Wo c8IMWriPqFhXKM0m5WbZyiRc+IJUak/G/uRjITW2nS1O3tkIi/Svj2p1OPP+TWFg23zR wKKRGK87IUk+QWvJijyN2UF9U5AQWrp9Eby6h32/8NYdMvFH1m5GiyfOXsFSrjnnGxWd cJ2rVlEfxgIF6dJ8V+PjkK9nhDBhWuQsk+s4HRNA/bmzY0QjPbYvblA48Sleynvpq0aD UKKcqi2HNelN5SPM+UIMtdDT5C+mjXX7WEjV2mteDqAuZh4gEz7sfB/0O8aDCptjddsi ZuxA== MIME-Version: 1.0 X-Received: by 10.152.123.34 with SMTP id lx2mr1525157lab.52.1361962367853; Wed, 27 Feb 2013 02:52:47 -0800 (PST) Received: by 10.112.80.133 with HTTP; Wed, 27 Feb 2013 02:52:47 -0800 (PST) In-Reply-To: <512DE205.4010202@digsys.bg> References: <512DE205.4010202@digsys.bg> Date: Wed, 27 Feb 2013 11:52:47 +0100 Message-ID: Subject: Re: Response of *.freebsd.org websites are very slow From: Daniel Nebdal To: Daniel Kalchev Content-Type: text/plain; charset=ISO-8859-1 Cc: Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 10:52:49 -0000 On Wed, Feb 27, 2013 at 11:37 AM, Daniel Kalchev wrote: > > > On 27.02.13 12:23, Daniel Nebdal wrote: >> >> I think you're supposed to be automatically sent to the mirror that is >> closest to you - for some value of "closest". If the mirror you're >> getting has issues, that might show up like this. Could you post the >> output of "traceroute ftp.freebsd.org" ? It should show which mirror >> you're getting, and perhaps if there are any obvious problems on the >> way. > > > I believe, in his case that would be "traceroute ftp.tr.freebsd.org". The > list of mirrors is here http://www.freebsd.org/doc/handbook/mirrors-ftp.html > > in any case, "anything *.freebsd.org" actually refers to plenty of hosts all > over the world -- some might be slow, some very fast. > > On the other hand, "Address could not be found" type of errors indicates > something else than "fast" or "slow". > > Daniel > That sounds likely, yes - and interestingly, it seems to be down: djnebdal@login2 ~> traceroute -w 1 ftp.tr.freebsd.org traceroute to ftp.tr.freebsd.org (193.140.143.151), 30 hops max, 40 byte packets 1 mrom-gw1.uio.no (129.240.12.3) 0.881 ms 0.922 ms 0.981 ms 2 uio-gw7.uio.no (129.240.25.5) 0.387 ms 0.437 ms 0.492 ms 3 uio-gw8.uio.no (129.240.25.190) 0.336 ms 0.400 ms 0.419 ms 4 oslo-gw.uninett.no (128.39.65.17) 0.316 ms 0.355 ms 0.378 ms 5 se-tug.nordu.net (109.105.102.21) 7.947 ms 23.017 ms 23.080 ms 6 dk-uni.nordu.net (109.105.97.10) 16.457 ms 16.471 ms 16.456 ms 7 nordunet-bckp2.rt1.ams.nl.geant.net (62.40.125.205) 29.590 ms 29.631 ms 29.662 ms 8 so-2-0-0.rt1.fra.de.geant2.net (62.40.112.9) 36.480 ms 36.476 ms 36.473 ms 9 so-2-1-0.rt1.pra.cz.geant2.net (62.40.112.37) 42.983 ms 42.986 ms 42.944 ms 10 as0.rt1.bud.hu.geant2.net (62.40.112.42) 49.833 ms 49.594 ms 51.680 ms 11 so-2-0-0.rt1.sof.bg.geant2.net (62.40.112.201) 62.857 ms 62.901 ms 62.742 ms 12 ulakbim-gw.rt1.sof.bg.geant.net (62.40.125.130) 73.853 ms 73.985 ms 73.390 ms 13 * * * (...) 30 * * * djnebdal@login2 ~> ping ftp.tr.freebsd.org PING ftpfreebsd.marmara.edu.tr (193.140.143.151) 56(84) bytes of data. --- ftpfreebsd.marmara.edu.tr ping statistics --- 28 packets transmitted, 0 received, 100% packet loss, time 27001ms From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 05:18:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DF736B0E for ; Wed, 27 Feb 2013 05:18:12 +0000 (UTC) (envelope-from vvs@indorsoft.ru) Received: from forward18.mail.yandex.net (forward18.mail.yandex.net [IPv6:2a02:6b8:0:1402::3]) by mx1.freebsd.org (Postfix) with ESMTP id 9CFA09F1 for ; Wed, 27 Feb 2013 05:18:12 +0000 (UTC) Received: from web10g.yandex.ru (web10g.yandex.ru [95.108.252.110]) by forward18.mail.yandex.net (Yandex) with ESMTP id D8C7D1781F51; Wed, 27 Feb 2013 09:18:10 +0400 (MSK) Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by web10g.yandex.ru (Yandex) with ESMTP id 93A94270011; Wed, 27 Feb 2013 09:18:10 +0400 (MSK) Received: from user-79-136-172-172.tomtelnet.ru (user-79-136-172-172.tomtelnet.ru [79.136.172.172]) by web10g.yandex.ru with HTTP; Wed, 27 Feb 2013 09:18:10 +0400 From: vvs@indorsoft.ru To: Mehmet Erol Sanliturk , freebsd-current In-Reply-To: References: Subject: Re: Response of *.freebsd.org websites are very slow Message-Id: <292191361942290@web10g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Wed, 27 Feb 2013 12:18:10 +0700 X-Mailman-Approved-At: Wed, 27 Feb 2013 12:23:47 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 05:18:12 -0000 27.02.2013, 08:40, "Mehmet Erol Sanliturk" : The response of pkg_add is "Address could not be found." Access to *.freebsd.org sites are so slow that many times, web browsers Firefox , Chromium are displaying a message to tell : "Site is not found ... Try once more ..." To access to other sites in US may be considered instantaneous here in Turkey. I cannot reproduce this. Can you try Google's DNS?: [router]/root(22): dig @8.8.8.8 www.freebsd.org ; <<>> DiG 9.6.2-P2 <<>> @8.8.8.8 www.freebsd.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3186 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.freebsd.org. IN A ;; ANSWER SECTION: www.freebsd.org. 48 IN CNAME wfe0.ysv.freebsd.org. wfe0.ysv.freebsd.org. 1119 IN A 8.8.178.110 ;; Query time: 123 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Feb 27 11:08:27 2013 ;; MSG SIZE rcvd: 72 BTW, is there a mailing list where this is not offtopic? -www is deprecated. -questions? -- Victor Snezhko From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 12:52:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C29FCCE5 for ; Wed, 27 Feb 2013 12:52:30 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id A3804E02 for ; Wed, 27 Feb 2013 12:52:30 +0000 (UTC) Received: from [10.0.10.1] ([173.88.202.176]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Feb 2013 04:52:31 -0800 Message-ID: <512E018D.5040705@a1poweruser.com> Date: Wed, 27 Feb 2013 07:52:29 -0500 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Mehmet Erol Sanliturk Subject: Re: Response of *.freebsd.org websites are very slow References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Feb 2013 12:52:31.0804 (UTC) FILETIME=[4E8BBFC0:01CE14E9] X-Sender: fbsd8@a1poweruser.com X-Authenticated-Sender: fbsd8@a1poweruser.com X-EchoSenderHash: [fbsd8]-[a1poweruser*com] Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 12:52:30 -0000 Mehmet Erol Sanliturk wrote: > Dear All , > > I have installed > > https://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/10.0-HEAD-r247266-JPSNAP > > with a very nice steps flow and it has booted very well . > > During > > pkg_add -rv xorg > > it become necessary to try many times , and for other packages the action > is the similar . > > The response of pkg_add is "Address could not be found ." . > > Actually , this situation is started after security incident occurrence . > > Access to *.freebsd.org sites are so slow that many times , web browsers > Firefox , Chromium are displaying a message to tell : > "Site is not found ... Try once more ..." > > To access to other sites in US may be considered instantaneous here in > Turkey . > > > I think a solution may be supplied for this problem . > > > Thank you very much . > > Mehmet Erol Sanliturk Well I am in cleveland ohio usa and I have noticed that http://www.freebsd.org/handbook/ is slow or in most cases just times out. So this is bigger problem that some mirror being down in turkey. It started about 10 days ago. From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 12:59:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CEF4298 for ; Wed, 27 Feb 2013 12:59:52 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id AEC38E52 for ; Wed, 27 Feb 2013 12:59:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:Cc:To:Content-Type; bh=+5qShqext99TNLq8SQSz7Ae4dN1L/Nu4Bjz3Ui+Rbck=; b=NdMYOQo8RqRL42f975dfJRxb+7I4KmNX0Dm47wDyovdzbm/WiCC2OuYCEHLu2qrlSmQ9OJirqbO4KJOo6nIcNdKDFlJsQa+XoT1TxCc5xEfnHuRX1SD1EyM09HuiYFxC; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UAgbs-0007St-CD; Wed, 27 Feb 2013 06:59:48 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1361969982-84357-79462/5/1; Wed, 27 Feb 2013 12:59:42 +0000 Content-Type: text/plain; format=flowed; delsp=yes To: Mehmet Erol Sanliturk , fbsd8@a1poweruser.com Subject: Re: Response of *.freebsd.org websites are very slow References: <512E018D.5040705@a1poweruser.com> Date: Wed, 27 Feb 2013 06:59:42 -0600 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <512E018D.5040705@a1poweruser.com> User-Agent: Opera Mail/12.13 (FreeBSD) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 12:59:52 -0000 On Wed, 27 Feb 2013 06:52:29 -0600, wrote: > Well I am in cleveland ohio usa and I have noticed that > http://www.freebsd.org/handbook/ is slow or in most cases just times > out. So this is bigger problem that some mirror being down in turkey. > It started about 10 days ago. I can't reproduce this myself. Can you provide a traceroute? From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 13:13:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7A686557 for ; Wed, 27 Feb 2013 13:13:29 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id 59621F2B for ; Wed, 27 Feb 2013 13:13:29 +0000 (UTC) Received: from [10.0.10.1] ([173.88.202.176]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Feb 2013 05:13:30 -0800 Message-ID: <512E0677.30306@a1poweruser.com> Date: Wed, 27 Feb 2013 08:13:27 -0500 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Mark Felder Subject: Re: Response of *.freebsd.org websites are very slow References: <512E018D.5040705@a1poweruser.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Feb 2013 13:13:30.0737 (UTC) FILETIME=[3CEDAE10:01CE14EC] X-Sender: fbsd8@a1poweruser.com X-Authenticated-Sender: fbsd8@a1poweruser.com X-EchoSenderHash: [fbsd8]-[a1poweruser*com] Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 13:13:29 -0000 Mark Felder wrote: > On Wed, 27 Feb 2013 06:52:29 -0600, wrote: > >> Well I am in cleveland ohio usa and I have noticed that >> http://www.freebsd.org/handbook/ is slow or in most cases just times >> out. So this is bigger problem that some mirror being down in turkey. >> It started about 10 days ago. > > I can't reproduce this myself. Can you provide a traceroute? Script started on Wed Feb 27 08:09:20 2013 # /root >dated Wed Feb 27 08:09:28 EST 2013 # /root >traceroute www.freebsd.org traceroute to wfe0.ysv.freebsd.org (8.8.178.110), 64 hops max, 40 byte packets traceroute: sendto: Network is unreachable 1 traceroute: wrote wfe0.ysv.freebsd.org 40 chars, ret=-1 *traceroute: sendto: Network is unreachable traceroute: wrote wfe0.ysv.freebsd.org 40 chars, ret=-1 *traceroute: sendto: Network is unreachable traceroute: wrote wfe0.ysv.freebsd.org 40 chars, ret=-1 ^C # /root >date Wed Feb 27 08:10:05 EST 2013 # /root >exit exit Script done on Wed Feb 27 08:10:15 2013 From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 13:18:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 59E356E4 for ; Wed, 27 Feb 2013 13:18:04 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 13FC4F62 for ; Wed, 27 Feb 2013 13:18:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:Cc:To:Content-Type; bh=nIZ9rthcTJ2ebKNYk4PPKU0WFU+9mZHCWpQ8nGd5wjs=; b=NXlMzjFivRVsqkUHyawXxNjtupQPasWhrwTC/ugmWCeNHN9WDCiM466UCjgXclLB6ggjDIiA59bqlcTbPuw1Wtg8c/rJIHe+IpDWZc3I2xMsSZtG8RmnRq+53hr2mChp; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UAgtV-00088m-CU; Wed, 27 Feb 2013 07:18:01 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1361971075-84357-79462/5/2; Wed, 27 Feb 2013 13:17:55 +0000 Content-Type: text/plain; format=flowed; delsp=yes To: fbsd8@a1poweruser.com Subject: Re: Response of *.freebsd.org websites are very slow References: <512E018D.5040705@a1poweruser.com> <512E0677.30306@a1poweruser.com> Date: Wed, 27 Feb 2013 07:17:54 -0600 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <512E0677.30306@a1poweruser.com> User-Agent: Opera Mail/12.13 (FreeBSD) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 13:18:04 -0000 On Wed, 27 Feb 2013 07:13:27 -0600, wrote: > traceroute www.freebsd.org Here's mine going to the same destination without issue. # traceroute www.freebsd.org traceroute to wfe0.ysv.freebsd.org (8.8.178.110), 64 hops max, 52 byte packets 1 192.168.93.1 (192.168.93.1) 0.494 ms 0.472 ms 0.459 ms 2 vl80-vrrp.switch01.excelsior.supranet.net (66.170.8.3) 0.804 ms 0.734 ms 0.950 ms 3 r3-em0.excelsior.supranet.net (66.170.0.138) 0.775 ms 0.753 ms 0.755 ms 4 vlan607.car2.chicago2.level3.net (4.26.46.169) 7.195 ms 6.638 ms 7.244 ms 5 ae-1-51.edge3.chicago3.level3.net (4.69.138.136) 6.590 ms 6.299 ms 6.304 ms 6 gblx-level3-10g.chicago3.level3.net (4.68.62.202) 5.991 ms gblx-level3-10g.chicago3.level3.net (4.68.63.66) 6.216 ms 7.515 ms 7 xe9-1-2-10g.scr4.snv2.gblx.net (67.16.160.34) 54.299 ms ae14.scr4.snv2.gblx.net (67.16.164.153) 54.490 ms 55.534 ms 8 e5-3-40g.ar5.sjc2.gblx.net (67.17.72.14) 69.572 ms 60.789 ms 55.438 ms 9 yahoo-san-jose.tengig2-3.1189.ar3.sjc2.gblx.net (64.211.206.210) 57.978 ms yahoo.tengigabitethernet2-4.1189.ar3.sjc2.gblx.net (208.48.239.254) 56.148 ms yahoo-san-jose.tengig2-3.1189.ar3.sjc2.gblx.net (64.211.206.210) 57.467 ms 10 ae-4.pat1.sjc.yahoo.com (216.115.105.16) 58.248 ms 58.448 ms routerer-ext.freebsd.org (216.115.101.225) 59.220 ms 11 wfe0.ysv.freebsd.org (8.8.178.110) 58.955 ms routerer-ext.freebsd.org (216.115.101.225) 59.339 ms wfe0.ysv.freebsd.org (8.8.178.110) 59.474 ms So you can't get past the first hop? Are you blocking ICMP anywhere? Because that will destroy PMTU-D and cause all kinds of havoc. From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 13:39:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 11BC5DD4 for ; Wed, 27 Feb 2013 13:39:43 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id E50E3103 for ; Wed, 27 Feb 2013 13:39:42 +0000 (UTC) Received: from [10.0.10.1] ([173.88.202.176]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Feb 2013 05:39:43 -0800 Message-ID: <512E0C9C.9000509@a1poweruser.com> Date: Wed, 27 Feb 2013 08:39:40 -0500 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Mark Felder Subject: Re: Response of *.freebsd.org websites are very slow References: <512E018D.5040705@a1poweruser.com> <512E0677.30306@a1poweruser.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Feb 2013 13:39:43.0974 (UTC) FILETIME=[E6A69860:01CE14EF] X-Sender: fbsd8@a1poweruser.com X-Authenticated-Sender: fbsd8@a1poweruser.com X-EchoSenderHash: [fbsd8]-[a1poweruser*com] Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 13:39:43 -0000 Mark Felder wrote: > On Wed, 27 Feb 2013 07:13:27 -0600, wrote: > >> traceroute www.freebsd.org > > Here's mine going to the same destination without issue. > > # traceroute www.freebsd.org > traceroute to wfe0.ysv.freebsd.org (8.8.178.110), 64 hops max, 52 byte > packets > 1 192.168.93.1 (192.168.93.1) 0.494 ms 0.472 ms 0.459 ms > 2 vl80-vrrp.switch01.excelsior.supranet.net (66.170.8.3) 0.804 ms > 0.734 ms 0.950 ms > 3 r3-em0.excelsior.supranet.net (66.170.0.138) 0.775 ms 0.753 ms > 0.755 ms > 4 vlan607.car2.chicago2.level3.net (4.26.46.169) 7.195 ms 6.638 ms > 7.244 ms > 5 ae-1-51.edge3.chicago3.level3.net (4.69.138.136) 6.590 ms 6.299 > ms 6.304 ms > 6 gblx-level3-10g.chicago3.level3.net (4.68.62.202) 5.991 ms > gblx-level3-10g.chicago3.level3.net (4.68.63.66) 6.216 ms 7.515 ms > 7 xe9-1-2-10g.scr4.snv2.gblx.net (67.16.160.34) 54.299 ms > ae14.scr4.snv2.gblx.net (67.16.164.153) 54.490 ms 55.534 ms > 8 e5-3-40g.ar5.sjc2.gblx.net (67.17.72.14) 69.572 ms 60.789 ms > 55.438 ms > 9 yahoo-san-jose.tengig2-3.1189.ar3.sjc2.gblx.net (64.211.206.210) > 57.978 ms > yahoo.tengigabitethernet2-4.1189.ar3.sjc2.gblx.net (208.48.239.254) > 56.148 ms > yahoo-san-jose.tengig2-3.1189.ar3.sjc2.gblx.net (64.211.206.210) > 57.467 ms > 10 ae-4.pat1.sjc.yahoo.com (216.115.105.16) 58.248 ms 58.448 ms > routerer-ext.freebsd.org (216.115.101.225) 59.220 ms > 11 wfe0.ysv.freebsd.org (8.8.178.110) 58.955 ms > routerer-ext.freebsd.org (216.115.101.225) 59.339 ms > wfe0.ysv.freebsd.org (8.8.178.110) 59.474 ms > > > > So you can't get past the first hop? Are you blocking ICMP anywhere? > Because that will destroy PMTU-D and cause all kinds of havoc. > > Lets change the test from traceroute to pointing your browser at www.freebsd.org and see what your response time is if at all. From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 13:45:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E3E5A3CB for ; Wed, 27 Feb 2013 13:45:55 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 57E75153 for ; Wed, 27 Feb 2013 13:45:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:Cc:To:Content-Type; bh=k6VeBEu9YQ/sucXZ/5ZysjvhQXz3uTlSxbM6524JXf4=; b=ONH4Y4ghbEGbF6vknJirvFHsxiUfRNzsQ8kNC/r7BNgDMNGg6PA9hX6MusXWLn3rotu4ijWtSoZBNTdTQuA125YpDz6XK/Am5pbkMv6iREabqFvwW4KKnZe3ZRWFQrgf; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UAhKN-0006Wq-Gw; Wed, 27 Feb 2013 07:45:47 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1361972741-84357-79462/5/3; Wed, 27 Feb 2013 13:45:41 +0000 Content-Type: text/plain; format=flowed; delsp=yes To: fbsd8@a1poweruser.com Subject: Re: Response of *.freebsd.org websites are very slow References: <512E018D.5040705@a1poweruser.com> <512E0677.30306@a1poweruser.com> <512E0C9C.9000509@a1poweruser.com> Date: Wed, 27 Feb 2013 07:45:41 -0600 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <512E0C9C.9000509@a1poweruser.com> User-Agent: Opera Mail/12.13 (FreeBSD) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 13:45:55 -0000 On Wed, 27 Feb 2013 07:39:40 -0600, wrote: >> > Lets change the test from traceroute to pointing your browser at > www.freebsd.org and see what your response time is if at all. > Screenshots showing latency via Chromium's developer tools: http://i.imgur.com/DaSNc6b.png http://i.imgur.com/pvXEGgo.png From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 13:48:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AE52A501 for ; Wed, 27 Feb 2013 13:48:31 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 2AB7E180 for ; Wed, 27 Feb 2013 13:48:30 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.5/8.14.5) with ESMTP id r1RDmM9K047480 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 27 Feb 2013 15:48:23 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <512E0EA6.4080406@digsys.bg> Date: Wed, 27 Feb 2013 15:48:22 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.12) Gecko/20130125 Thunderbird/10.0.12 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Response of *.freebsd.org websites are very slow References: <512E018D.5040705@a1poweruser.com> <512E0677.30306@a1poweruser.com> In-Reply-To: <512E0677.30306@a1poweruser.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 13:48:31 -0000 On 27.02.13 15:13, Fbsd8 wrote: > Mark Felder wrote: >> On Wed, 27 Feb 2013 06:52:29 -0600, wrote: >> >>> Well I am in cleveland ohio usa and I have noticed that >>> http://www.freebsd.org/handbook/ is slow or in most cases just >>> times out. So this is bigger problem that some mirror being down in >>> turkey. >>> It started about 10 days ago. >> >> I can't reproduce this myself. Can you provide a traceroute? > > > > Script started on Wed Feb 27 08:09:20 2013 > > # /root >dated > Wed Feb 27 08:09:28 EST 2013 > # /root >traceroute www.freebsd.org > traceroute to wfe0.ysv.freebsd.org (8.8.178.110), 64 hops max, 40 byte > packets > traceroute: sendto: Network is unreachable > 1 traceroute: wrote wfe0.ysv.freebsd.org 40 chars, ret=-1 > *traceroute: sendto: Network is unreachable > traceroute: wrote wfe0.ysv.freebsd.org 40 chars, ret=-1 > *traceroute: sendto: Network is unreachable > traceroute: wrote wfe0.ysv.freebsd.org 40 chars, ret=-1 > ^C > # /root >date > Wed Feb 27 08:10:05 EST 2013 > # /root >exit > exit > > Script done on Wed Feb 27 08:10:15 2013 > It seems you have some network filter for this address (perhaps anything 8.8/16) at your router or on your computer. traceroute should have at least worked past your network... Daniel From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 14:05:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 33E069F4 for ; Wed, 27 Feb 2013 14:05:04 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by mx1.freebsd.org (Postfix) with ESMTP id D73EE254 for ; Wed, 27 Feb 2013 14:05:03 +0000 (UTC) Received: by mail-ve0-f182.google.com with SMTP id ox1so585659veb.13 for ; Wed, 27 Feb 2013 06:05:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=KlddzW2uhLKhvFLkxF7maSBW5inWopAmx4aCPDTmbSA=; b=b/BE4C0RnP9AM4pgxYvbOUlX9p0N7PS6BOUBdi4q0u0my5uuIJHHYKZestCPVR/CvO aIzXLyo98toJbuN84GQUs7CM9LEm6Pe5lhzat2WunESFHOobA8Zn4+pFv8MA095sZKCb VysAg6gQ+AaathVfOdjqIUZxRUlO2qWrSLj1Spzpt4ZtQyXjDXqAs8IZB3Aexu2jP5Jp +jEHaXVB7depcABLfHXcB182k2sokMMMFd31+7g9e1btDxnh0jxlHr7LGBWRjAxFrmY6 ZKqO70Xp8pgh6ggi+Wib3xJgaMW/NOTbT5gfBrS8592Fq0agPftHc9I+hcekyyypa5cB Zrtg== MIME-Version: 1.0 X-Received: by 10.52.29.116 with SMTP id j20mr856811vdh.16.1361973903064; Wed, 27 Feb 2013 06:05:03 -0800 (PST) Received: by 10.58.170.36 with HTTP; Wed, 27 Feb 2013 06:05:02 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Feb 2013 06:05:02 -0800 Message-ID: Subject: Re: Response of *.freebsd.org websites are very slow From: Mehmet Erol Sanliturk To: Daniel Nebdal Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 14:05:04 -0000 On Wed, Feb 27, 2013 at 2:23 AM, Daniel Nebdal wrote: > I think you're supposed to be automatically sent to the mirror that is > closest to you - for some value of "closest". If the mirror you're > getting has issues, that might show up like this. Could you post the > output of "traceroute ftp.freebsd.org" ? It should show which mirror > you're getting, and perhaps if there are any obvious problems on the > way. > > Also, you can try setting PACKAGEROOT to e.g. > ftp://ftp.beastie.tdk.net , to see if that makes pkg_add work better. > That's the mirror closest to me - if that one works ok for you, it's > another sign that the problem is with your local mirror. :) > > -- > Daniel Nebdal > > On Wed, Feb 27, 2013 at 2:39 AM, Mehmet Erol Sanliturk > wrote: > > Dear All , > > > > I have installed > > > > > https://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/10.0-HEAD-r247266-JPSNAP > > > > with a very nice steps flow and it has booted very well . > > > > During > > > > pkg_add -rv xorg > > > > it become necessary to try many times , and for other packages the action > > is the similar . > > > > The response of pkg_add is "Address could not be found ." . > > > > Actually , this situation is started after security incident occurrence . > > > > Access to *.freebsd.org sites are so slow that many times , web > browsers > > Firefox , Chromium are displaying a message to tell : > > "Site is not found ... Try once more ..." > > > > To access to other sites in US may be considered instantaneous here in > > Turkey . > > > > > > I think a solution may be supplied for this problem . > > > > > > Thank you very much . > > > > Mehmet Erol Sanliturk > > _______________________________________________ > > Over FreeBSD 10.0 I have installed another operating system , because after startx , fluxbox did not start and there is no any desk top environment available as KDE or Gnome in packages . >From Linux : traceroute ftp.freebsd.org The response is : ftp.freebsd.org : Name or service not known . Can not handle "host" cmdline arg 'ftp.freebsd.org' on position 1 ( argc1 ) I tried netbsd , dragonflybsd , openbsd : All of the have responded . I tried freebsd more than five times , no one of them succeeded . When www is used instead of ftp , the above results are the similar . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 14:11:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1B410D56 for ; Wed, 27 Feb 2013 14:11:47 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by mx1.freebsd.org (Postfix) with ESMTP id CAB822F2 for ; Wed, 27 Feb 2013 14:11:46 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id n10so414420vcn.0 for ; Wed, 27 Feb 2013 06:11:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PiWlbXty1Hc/RMROziptQvxjm3aRRAAebmaNdO4hOBk=; b=AUnAVawIVV5BCxwAXjQct2VoRRSH8IKAcdFM2OITPehNdqkCZjiTIlaqak6U9YqP1J hJzFZFTioArRGXtSAx9LUZZr6iwSpFdP0M5Hmx1epKFo/JGFtFHyBZr+NlT1FSZE8Ys8 M74PlFwW2yYizu3KQcJ3hbFTu8dfZLuHCnAQwDRE3kg4jr2tIKUx7c2JwMn+AjCjbWov qjEIkXXaRSQWKIgTLUiHb9eaG9F78i9dSlOr9NnH9aEmt+NSQAAneAT4qnACT59OsovV o2HxNFo77HueVZKGEyZRTVJkg3eMDCwgx0FcXwSlwavc2DIbwzXCHVs1GBGPkaV/WYzR MwHg== MIME-Version: 1.0 X-Received: by 10.58.154.229 with SMTP id vr5mr969642veb.11.1361974306112; Wed, 27 Feb 2013 06:11:46 -0800 (PST) Received: by 10.58.170.36 with HTTP; Wed, 27 Feb 2013 06:11:46 -0800 (PST) In-Reply-To: <512DE205.4010202@digsys.bg> References: <512DE205.4010202@digsys.bg> Date: Wed, 27 Feb 2013 06:11:46 -0800 Message-ID: Subject: Re: Response of *.freebsd.org websites are very slow From: Mehmet Erol Sanliturk To: Daniel Kalchev Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 14:11:47 -0000 On Wed, Feb 27, 2013 at 2:37 AM, Daniel Kalchev wrote: > > > On 27.02.13 12:23, Daniel Nebdal wrote: > >> I think you're supposed to be automatically sent to the mirror that is >> closest to you - for some value of "closest". If the mirror you're >> getting has issues, that might show up like this. Could you post the >> output of "traceroute ftp.freebsd.org" ? It should show which mirror >> you're getting, and perhaps if there are any obvious problems on the >> way. >> > > I believe, in his case that would be "traceroute ftp.tr.freebsd.org". The > list of mirrors is here http://www.freebsd.org/doc/** > handbook/mirrors-ftp.html > > in any case, "anything *.freebsd.org" actually refers to plenty of hosts > all over the world -- some might be slow, some very fast. > > On the other hand, "Address could not be found" type of errors indicates > something else than "fast" or "slow". > > Daniel > "traceroute ftp.tr.freebsd.org" is working . "traceroute ftp.freebsd.org " is NOT working . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 14:22:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BDD532D7 for ; Wed, 27 Feb 2013 14:22:56 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 502DE3DD for ; Wed, 27 Feb 2013 14:22:56 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id fe20so621042lab.29 for ; Wed, 27 Feb 2013 06:22:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=c2VoGHJ/Kfhj6nqkWNkuba/FY4qqEunzbSwLbAQUSL8=; b=hs4jOJszMBtFvNqiROYQXGBwxMOXpImZiujrFqdubFegNDNF85LMjYsxargOdipR9M q8GaXvUPXCcqk13Rqe5r92Iq5GG5qzgtofkmQmFTf9Lj11LP0LFU73TyEl7fNgYJ7+MF m6Fk9wzUHbWdhRcJGWhqkHoltetqdvaaiOYNRKUwkZAx3xeIaIaTNBmugCihGqQz6w+1 mmjcLfPAJGl78/0U/mtP4oRb8E163ht2Cr1hDZPRij9/mTimdZOK4ikmEGNr4iU57SgO l325Y5L1yEQUXscqS+a2KmzXIzApymaLuyymAsnF3rwl761W0k/9Sj9ETeQXA5qEr/Uc /+4g== MIME-Version: 1.0 X-Received: by 10.112.84.164 with SMTP id a4mr2163690lbz.10.1361974975237; Wed, 27 Feb 2013 06:22:55 -0800 (PST) Received: by 10.112.80.133 with HTTP; Wed, 27 Feb 2013 06:22:55 -0800 (PST) In-Reply-To: References: <512DE205.4010202@digsys.bg> Date: Wed, 27 Feb 2013 15:22:55 +0100 Message-ID: Subject: Re: Response of *.freebsd.org websites are very slow From: Daniel Nebdal To: Mehmet Erol Sanliturk Content-Type: text/plain; charset=ISO-8859-1 Cc: Current , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 14:22:56 -0000 Ok, that's weird. What does a simple "nslookup ftp.freebsd.org" give you? On Wed, Feb 27, 2013 at 3:11 PM, Mehmet Erol Sanliturk wrote: > On Wed, Feb 27, 2013 at 2:37 AM, Daniel Kalchev wrote: > >> >> >> On 27.02.13 12:23, Daniel Nebdal wrote: >> >>> I think you're supposed to be automatically sent to the mirror that is >>> closest to you - for some value of "closest". If the mirror you're >>> getting has issues, that might show up like this. Could you post the >>> output of "traceroute ftp.freebsd.org" ? It should show which mirror >>> you're getting, and perhaps if there are any obvious problems on the >>> way. >>> >> >> I believe, in his case that would be "traceroute ftp.tr.freebsd.org". The >> list of mirrors is here http://www.freebsd.org/doc/** >> handbook/mirrors-ftp.html >> >> in any case, "anything *.freebsd.org" actually refers to plenty of hosts >> all over the world -- some might be slow, some very fast. >> >> On the other hand, "Address could not be found" type of errors indicates >> something else than "fast" or "slow". >> >> Daniel >> > > > "traceroute ftp.tr.freebsd.org" > > is working . > > > "traceroute ftp.freebsd.org " > > is NOT working . > > > Thank you very much . > > Mehmet Erol Sanliturk > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 14:28:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 08F52513 for ; Wed, 27 Feb 2013 14:28:17 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by mx1.freebsd.org (Postfix) with ESMTP id BEC9462B for ; Wed, 27 Feb 2013 14:28:16 +0000 (UTC) Received: by mail-vc0-f174.google.com with SMTP id n11so407314vch.19 for ; Wed, 27 Feb 2013 06:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=q+a9+B+htg9slLK36rFQiGHH3RhtSebrjvsyHaJXNGI=; b=POiwrC1JzVtGLTbQ3pJ/73uLs9mDkuKTVzD4nDaBe05wHu7u1gIqWb3lmbXAPROfJM cq818ElGH1mq3a01c+cQzKXdTAL4ZI9ONwhdXvKAPecT5eefjTy8wGeaspXzuTp22PjT zI+fA7VRq/IMQ5M58jCnZGWwsAIgqhb95385MsMpM3w4PcCefpLyd7kZBAUG8PS3fJAk BJtx1fC5eG2BFm7/U2zI53NoRytkW6O9OfwSsQPdznXH99oHk8Rubcej46LScbO4TSoZ S94sO5aT1bvIl9TqNmLUFpwfylTNWzBepdE4q8gEWIQ2nwixseFIcUCXSqgCYCpPcHQ5 5zFg== MIME-Version: 1.0 X-Received: by 10.220.222.8 with SMTP id ie8mr944923vcb.27.1361975295942; Wed, 27 Feb 2013 06:28:15 -0800 (PST) Received: by 10.58.170.36 with HTTP; Wed, 27 Feb 2013 06:28:15 -0800 (PST) In-Reply-To: References: <512DE205.4010202@digsys.bg> Date: Wed, 27 Feb 2013 06:28:15 -0800 Message-ID: Subject: Re: Response of *.freebsd.org websites are very slow From: Mehmet Erol Sanliturk To: Daniel Nebdal Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Current , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 14:28:17 -0000 On Wed, Feb 27, 2013 at 6:22 AM, Daniel Nebdal wrote: > Ok, that's weird. What does a simple "nslookup ftp.freebsd.org" give you? > > On Wed, Feb 27, 2013 at 3:11 PM, Mehmet Erol Sanliturk > wrote: > > On Wed, Feb 27, 2013 at 2:37 AM, Daniel Kalchev > wrote: > > > >> > >> > >> On 27.02.13 12:23, Daniel Nebdal wrote: > >> > >>> I think you're supposed to be automatically sent to the mirror that is > >>> closest to you - for some value of "closest". If the mirror you're > >>> getting has issues, that might show up like this. Could you post the > >>> output of "traceroute ftp.freebsd.org" ? It should show which mirror > >>> you're getting, and perhaps if there are any obvious problems on the > >>> way. > >>> > >> > >> I believe, in his case that would be "traceroute ftp.tr.freebsd.org". > The > >> list of mirrors is here http://www.freebsd.org/doc/** > >> handbook/mirrors-ftp.html< > http://www.freebsd.org/doc/handbook/mirrors-ftp.html> > >> > >> in any case, "anything *.freebsd.org" actually refers to plenty of > hosts > >> all over the world -- some might be slow, some very fast. > >> > >> On the other hand, "Address could not be found" type of errors indicates > >> something else than "fast" or "slow". > >> > >> Daniel > >> > > > > > > "traceroute ftp.tr.freebsd.org" > > > > is working . > > > > > > "traceroute ftp.freebsd.org " > > > > is NOT working . > > > > > nslookup ftp.freebsd.org ;; connection timed out ; trying next origin ;; connection timed out ; no servers could be reached netbsd , openbsd , dragonflybsd is working . ftp.tr.freebsd.org is working . > > Thank you very much . > > > > Mehmet Erol Sanliturk > > > From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 14:58:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B0788EE9 for ; Wed, 27 Feb 2013 14:58:28 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id 7D19781B for ; Wed, 27 Feb 2013 14:58:28 +0000 (UTC) Received: from [10.0.10.1] ([173.88.202.176]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Feb 2013 06:58:29 -0800 Message-ID: <512E1F12.6010405@a1poweruser.com> Date: Wed, 27 Feb 2013 09:58:26 -0500 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Mark Felder Subject: Re: Response of *.freebsd.org websites are very slow References: <512E018D.5040705@a1poweruser.com> <512E0677.30306@a1poweruser.com> <512E0C9C.9000509@a1poweruser.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Feb 2013 14:58:29.0388 (UTC) FILETIME=[E7378CC0:01CE14FA] X-Sender: fbsd8@a1poweruser.com X-Authenticated-Sender: fbsd8@a1poweruser.com X-EchoSenderHash: [fbsd8]-[a1poweruser*com] Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 14:58:28 -0000 Mark Felder wrote: > On Wed, 27 Feb 2013 07:39:40 -0600, wrote: > >>> >> Lets change the test from traceroute to pointing your browser at >> www.freebsd.org and see what your response time is if at all. >> > > Screenshots showing latency via Chromium's developer tools: > > http://i.imgur.com/DaSNc6b.png > http://i.imgur.com/pvXEGgo.png > > The speed of accessing the www.freebsd.org/handbook is now back to normal. Had to turn off my firewall for this traceroute test Script started on Wed Feb 27 09:48:43 2013 # /root >date Feb 27 09:48:56 EST 2013 # /root >traceroute www.freebsd.org traceroute to wfe0.ysv.freebsd.org (8.8.178.110), 64 hops max, 40 byte packets 1 cpe-173-88-192-1.neo.res.rr.com (173.88.192.1) 251.456 ms 88.794 ms 21.813 ms 2 gig2-1.charoh1-rtr1.neo.rr.com (24.164.104.149) 8.145 ms 8.933 ms 28.981 ms 3 tge4-0-0.clvhoh1-rtr2.neo.rr.com (24.164.117.138) 9.821 ms 9.072 ms 9.467 ms 4 tge2-1.clvhoh1-rtr1.neo.rr.com (24.164.115.171) 9.869 ms 13.331 ms 28.720 ms 5 tge0-9-0-0.clevohek-ccr03.midwest.rr.com (24.164.117.127) 20.174 ms 12.905 ms 15.966 ms 6 network-065-029-001-032.midwest.rr.com (65.29.1.32) 9.862 ms 13.677 ms 15.960 ms 7 ae-3-0.cr0.dca20.tbone.rr.com (66.109.6.70) 38.211 ms 39.014 ms 32.389 ms 8 107.14.19.135 (107.14.19.135) 36.441 ms ae-1-0.pr0.dca10.tbone.rr.com (66.109.6.165) 52.941 ms 107.14.19.135 (107.14.19.135) 64.563 ms 9 TeG1-4.ar4.DCA3.gblx.net (208.49.195.129) 34.018 ms 42.869 ms 33.511 ms 10 ae0-30G.scr1.WDC2.gblx.net (67.17.107.197) 34.560 ms 34.648 ms 33.490 ms 11 ae5.scr3.SNV2.gblx.net (67.16.139.94) 90.794 ms 128.477 ms 91.257 ms 12 e8-1-20G.ar5.SJC2.gblx.net (67.16.145.118) 102.588 ms 98.564 ms 90.114 ms 13 YAHOO-SAN-JOSE.TenGig2-3.1189.ar3.SJC2.gblx.net (64.211.206.210) 112.699 ms 100.178 ms 113.808 ms 14 routerer-ext.freebsd.org (216.115.101.225) 83.708 ms 83.041 ms ae-4.pat1.sjc.yahoo.com (216.115.105.16) 82.672 ms 15 routerer-ext.freebsd.org (216.115.101.225) 83.174 ms 82.521 ms 81.904 ms 16 wfe0.ysv.FreeBSD.org (8.8.178.110) 84.524 ms 99.475 ms 83.776 ms # /root >date Wed Feb 27 09:49:23 EST 2013 # /root >exit exit Script done on Wed Feb 27 09:49:26 2013 From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 15:02:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A8652F5 for ; Wed, 27 Feb 2013 15:02:39 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by mx1.freebsd.org (Postfix) with ESMTP id 1B655865 for ; Wed, 27 Feb 2013 15:02:38 +0000 (UTC) Received: by mail-bk0-f52.google.com with SMTP id jk13so312730bkc.39 for ; Wed, 27 Feb 2013 07:02:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=j3lxifMCyrDzJz4lv7BVkjF5YqbfdTCu4fEuYPlNpq0=; b=UOR7BvK4aUBpi8pr4ZDc4xxK06C2IEABOuKvMywePlz70FrSTknjVaIK7j+LKGHuSn EVhXhzrccoDIMicywrCIPXXSQGieO/WP6uP0FpxC5Gu+FxInZLTqlGFcwPLYKtvdpIjL QxShn/jYgAObYy0gdhdhKo3LhIiFLa8ylDbaf23uYlQkbLDTDsWzo5777UHaj+7rvvLJ cDE4E8DTgmtdH0rOdV+e0F0RqonUu+jfPzPzVmKNSIEN3DnBRDrHrsiXxZHakMXdvd0/ A7zJWeTHGnStc2PN4qfd8b3lUrRKdnwstoD91oYbDVf8KPL0qDhdovuHBMkB9dDdgrxc FKAw== X-Received: by 10.204.145.83 with SMTP id c19mr951969bkv.69.1361977351739; Wed, 27 Feb 2013 07:02:31 -0800 (PST) Received: from [192.168.1.80] (dsl51B65532.pool.t-online.hu. [81.182.85.50]) by mx.google.com with ESMTPS id g28sm732357bkv.17.2013.02.27.07.02.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 07:02:30 -0800 (PST) Message-ID: <512E2001.1040305@gmail.com> Date: Wed, 27 Feb 2013 16:02:25 +0100 From: deeptech71 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:18.0) Gecko/20100101 SeaMonkey/2.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: CC in /etc/make.conf and headers in ${WORLDTMP} Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 15:02:39 -0000 Recently, I've posted several build errors that only I seemed to run into. The errors were based on "incompatible/missing declarations". The bottom line of those is actually the following, as I gather: I, without any compilers in /usr/bin, was trying to build the world and kernel by setting CC to basically /home/me/my_compilers/bin/clang. As the handbook says, the FreeBSD build system uses the compiler in /usr/obj, ie., the one "just built for further purposes". As I can see, that compiler is specifically crafted to use the include files in ${WORLDTMP}, ie., in /usr/obj/usr/src/tmp/usr/include (not /usr/include), where "new" headers are placed in an early phase of the build process. This is required for when the source tree has been "significantly" changed since the last installworld -- the new code won't build with the headers in /usr/include. In such cases, of course compilation breaks when an unaware compiler (eg., /usr/bin/cc, /home/me/my_compilers/bin/clang, etc.) is used. I was able to compile the world and kernel by changing CC from /home/me/my_compilers/bin/clang to /usr/obj/usr/src/tmp/usr/bin/cc upon the first compilation error, by which time the latter compiler was available. However, after a successful build and install, and no following update of the source tree, an external compiler can be used, because by then, the new headers will have been installed in /usr/include. So it appears that specifying an external compiler as CC in /etc/make.conf is not supposed to work in general. Life sux. Is there any intention to remedy this? From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 15:04:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1D341259 for ; Wed, 27 Feb 2013 15:04:44 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by mx1.freebsd.org (Postfix) with ESMTP id AD43A88D for ; Wed, 27 Feb 2013 15:04:43 +0000 (UTC) Received: by mail-bk0-f52.google.com with SMTP id jk13so314027bkc.39 for ; Wed, 27 Feb 2013 07:04:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Fu7heu1/gfv+bNzqirnNEFYVv6G5H9HRLBgimCHTjqA=; b=R5zL+Zup+INS4wdhvpdZBk+xSSoJAXMg6ICvmdQQtexOB+dem8OMkuQB2Tuou/q38Z G23s0z1L9QDW5oMO+LigMCTYg0jlJE4axE4gZrLi8IjpzXgHJYQNIyYizT5Nv16YrIE6 JPSUul7Q23TZlv24qXbVJYiD//nL+SH/yOItb0ruIDfavEhLP1Fo+MGBzYzT1Vv4J9Vr S4TpUNfYvB5rdQI24l9rcvuHd2rbriq+Pm5vhB6hlKFYlfLMF7Xj3Jdgnu6iedfmGQBg nnBo/EN3weER96KOHQQXYU2+q1Rhb4KCN/6OfHcQPPtvo8dpc3PaOaRWmOi42tzpvchz rITA== X-Received: by 10.204.6.82 with SMTP id 18mr979337bky.24.1361977482840; Wed, 27 Feb 2013 07:04:42 -0800 (PST) Received: from [192.168.1.80] (dsl51B65532.pool.t-online.hu. [81.182.85.50]) by mx.google.com with ESMTPS id gi19sm739252bkc.2.2013.02.27.07.04.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 07:04:41 -0800 (PST) Message-ID: <512E2084.5030601@gmail.com> Date: Wed, 27 Feb 2013 16:04:36 +0100 From: deeptech71 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:18.0) Gecko/20100101 SeaMonkey/2.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: CC in /etc/make.conf and headers in ${WORLDTMP} References: <512E2001.1040305@gmail.com> In-Reply-To: <512E2001.1040305@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 15:04:44 -0000 For reference, my e-mails related to the build errors were: http://lists.freebsd.org/pipermail/freebsd-current/2013-February/039672.html http://lists.freebsd.org/pipermail/freebsd-current/2013-February/039675.html http://lists.freebsd.org/pipermail/freebsd-current/2013-February/039857.html From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 15:10:36 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 093E34A0 for ; Wed, 27 Feb 2013 15:10:36 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id D89258DA for ; Wed, 27 Feb 2013 15:10:35 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UAieQ-000BF6-QI; Wed, 27 Feb 2013 15:10:34 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1RFAVDl083738; Wed, 27 Feb 2013 08:10:31 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+AUWOrp5mYXr7MUlc1j3oG Subject: Re: CC in /etc/make.conf and headers in ${WORLDTMP} From: Ian Lepore To: deeptech71 In-Reply-To: <512E2001.1040305@gmail.com> References: <512E2001.1040305@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Feb 2013 08:10:31 -0700 Message-ID: <1361977831.16937.161.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 15:10:36 -0000 On Wed, 2013-02-27 at 16:02 +0100, deeptech71 wrote: > Recently, I've posted several build errors that only I seemed to run into. The errors were based on "incompatible/missing declarations". The bottom line of those is actually the following, as I gather: > > I, without any compilers in /usr/bin, was trying to build the world and kernel by setting CC to basically /home/me/my_compilers/bin/clang. > > As the handbook says, the FreeBSD build system uses the compiler in /usr/obj, ie., the one "just built for further purposes". As I can see, that compiler is specifically crafted to use the include files in ${WORLDTMP}, ie., in /usr/obj/usr/src/tmp/usr/include (not /usr/include), where "new" headers are placed in an early phase of the build process. This is required for when the source tree has been "significantly" changed since the last installworld -- the new code won't build with the headers in /usr/include. In such cases, of course compilation breaks when an unaware compiler (eg., /usr/bin/cc, /home/me/my_compilers/bin/clang, etc.) is used. > > I was able to compile the world and kernel by changing CC from /home/me/my_compilers/bin/clang to /usr/obj/usr/src/tmp/usr/bin/cc upon the first compilation error, by which time the latter compiler was available. > > However, after a successful build and install, and no following update of the source tree, an external compiler can be used, because by then, the new headers will have been installed in /usr/include. > > So it appears that specifying an external compiler as CC in /etc/make.conf is not supposed to work in general. Life sux. Is there any intention to remedy this? > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" It appears that you may be just slightly ahead of the curve. You'll probably be interested in this: http://lists.freebsd.org/pipermail/freebsd-arch/2013-February/014055.html -- Ian From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 15:20:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D5D0C6EA for ; Wed, 27 Feb 2013 15:20:26 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 34AFC942 for ; Wed, 27 Feb 2013 15:20:26 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id ec20so691290lab.37 for ; Wed, 27 Feb 2013 07:20:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=f6P/XtubSLxBVq/OK6A57TUD0x/2E8REJFmi8CdyEUg=; b=vIydbKYMy0ivFt7+298vgFh0ucoDpFGO7HkuFbMi1lQ3D1MyTOfdX1varWtQQUdasa RM0hpb6bvpSsV52jQqgcQ0BBJPzIUkQ7i6VEN9Xgg1XmBIz/s+yAy8oYxb0z9LObtYlB AnBqnBrbNnCzuO0PisEiFalk6W2LKTmMT8LMf1Nr8R2/x8XJSAaTwkJXNfzvQ8l4vZMd paFKh6LKDT/L6P/MmfG9Fa0o0LZFczSBsM0ZvyIUgyGBnea4l/ecNf0N5/ZMLrvrw1aO UuRQIdsi90smlAx4MVCWmsRj8bXWTO1FZfkeoMJoRx+KALag+oRrUQ0OFKNd0euJUz+/ Uu2A== MIME-Version: 1.0 X-Received: by 10.112.43.38 with SMTP id t6mr2263350lbl.69.1361978425137; Wed, 27 Feb 2013 07:20:25 -0800 (PST) Received: by 10.112.80.133 with HTTP; Wed, 27 Feb 2013 07:20:25 -0800 (PST) In-Reply-To: References: <512DE205.4010202@digsys.bg> Date: Wed, 27 Feb 2013 16:20:25 +0100 Message-ID: Subject: Re: Response of *.freebsd.org websites are very slow From: Daniel Nebdal To: Mehmet Erol Sanliturk Content-Type: text/plain; charset=ISO-8859-1 Cc: Current , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 15:20:26 -0000 On Wed, Feb 27, 2013 at 3:28 PM, Mehmet Erol Sanliturk wrote: > > > On Wed, Feb 27, 2013 at 6:22 AM, Daniel Nebdal wrote: >> >> Ok, that's weird. What does a simple "nslookup ftp.freebsd.org" give you? >> >> On Wed, Feb 27, 2013 at 3:11 PM, Mehmet Erol Sanliturk >> wrote: >> > On Wed, Feb 27, 2013 at 2:37 AM, Daniel Kalchev >> > wrote: >> > >> >> >> >> >> >> On 27.02.13 12:23, Daniel Nebdal wrote: >> >> >> >>> I think you're supposed to be automatically sent to the mirror that is >> >>> closest to you - for some value of "closest". If the mirror you're >> >>> getting has issues, that might show up like this. Could you post the >> >>> output of "traceroute ftp.freebsd.org" ? It should show which mirror >> >>> you're getting, and perhaps if there are any obvious problems on the >> >>> way. >> >>> >> >> >> >> I believe, in his case that would be "traceroute ftp.tr.freebsd.org". >> >> The >> >> list of mirrors is here http://www.freebsd.org/doc/** >> >> >> >> handbook/mirrors-ftp.html >> >> >> >> in any case, "anything *.freebsd.org" actually refers to plenty of >> >> hosts >> >> all over the world -- some might be slow, some very fast. >> >> >> >> On the other hand, "Address could not be found" type of errors >> >> indicates >> >> something else than "fast" or "slow". >> >> >> >> Daniel >> >> >> > >> > >> > "traceroute ftp.tr.freebsd.org" >> > >> > is working . >> > >> > >> > "traceroute ftp.freebsd.org " >> > >> > is NOT working . >> > >> > > > > > nslookup ftp.freebsd.org > > ;; connection timed out ; trying next origin > ;; connection timed out ; no servers could be reached > > > > netbsd , openbsd , dragonflybsd is working . > ftp.tr.freebsd.org is working . > > > > > >> >> > Thank you very much . >> > >> > Mehmet Erol Sanliturk >> > So nslookup (of ftp.freeebsd.org) fails on FreeBSD, but not the other BSDs? That's very strange. Is /etc/resolv.conf the same in FreeBSD and one of the working ones? Have you set up a firewall on the FreeBSD install? Does it have IPv6? -- Daniel Nebdal From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 15:25:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 549D3996 for ; Wed, 27 Feb 2013 15:25:37 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) by mx1.freebsd.org (Postfix) with ESMTP id CEF909A9 for ; Wed, 27 Feb 2013 15:25:36 +0000 (UTC) Received: by mail-bk0-f50.google.com with SMTP id jg9so329544bkc.37 for ; Wed, 27 Feb 2013 07:25:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=SQV61IQAVUCgPqAEsOLTsdlIyR3Bq4G8/b08BOHGIHU=; b=GswIh0BoCPrKSJPC6Zc6ETniXIlaRhso7hKfAEvwH7EtU7w5l9OYSvhsakVujw6Nn8 h4LFvjsFe+xC6JOxscnAMIOk36TIBJ9wV5dMt+Zkewiye/z4aiYWG/YTN7jna1UKqYe/ xgtbccEMCpPj/FLd2N/uecmeuX+/E66Q++TflgYvEYU38g8/mwuD7gOFXQbYX7le2IzE hG6qMcW/5us8g/04ot80C0BEq6HT7BJpRPcPXHxSN0+q/UCSspsdoQa7BkK7pgF1ajFn zLJCN7E1wQ/ayopQ6iOI7IXJ8+gFUws+D1EC2FzCpRvRW66cgHpl9FFee33iiIuPjQBl 5/fA== X-Received: by 10.204.145.135 with SMTP id d7mr999939bkv.64.1361978730148; Wed, 27 Feb 2013 07:25:30 -0800 (PST) Received: from [192.168.1.80] (dsl51B65532.pool.t-online.hu. [81.182.85.50]) by mx.google.com with ESMTPS id fy17sm764547bkc.6.2013.02.27.07.25.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 07:25:28 -0800 (PST) Message-ID: <512E2563.6060507@gmail.com> Date: Wed, 27 Feb 2013 16:25:23 +0100 From: deeptech71 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:18.0) Gecko/20100101 SeaMonkey/2.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: the latest version of Clang/LLVM for the world and kernel References: <511E378E.3090200@gmail.com> <511E5B05.5050402@FreeBSD.org> In-Reply-To: <511E5B05.5050402@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 15:25:37 -0000 Excluding the build errors arising from code becoming incompatible with old headers [1], the use of the latest version of Clang/LLVM for the world and kernel is mostly hitch-free, if I (1)remove, from the Clang installation, the headers that are already available in /usr/include, ie., $ cd /home/me/my_compilers/lib/clang/3.3/include $ rm float.h iso646.h limits.h tgmath.h and varargs.h $ rm stdalign.h stdarg.h stdbool.h stddef.h stdint.h stdnoreturn.h and (2) replace -fformat-extensions with -Wno-error-format in sys/conf/kern.mk. On 02/15/2013 16:57, Dimitry Andric wrote: > On 2013-02-15 14:26, deeptech71 wrote: >> During ``make installworld'': >> * btxld: Command not found. >> I had to append not only ``btxld'', but also ``ls dd cp'', to the ITOOLS variable in Makefile.inc1. > > There are apparently several things that can trigger that btxld error, > but the usual one is that your system clock is out of whack. I have > never researched it too deeply; maybe somebody else can chip in here. I did find my system clock "out of whack", but I've already fixed that weeks ago. I get the same error now. I don't recall getting the error when I was using the compiler in ${WORLDTMP} [1]. Also, there are still some eye-popping warnings (-Warray-bounds, -Wsizeof-pointer-memaccess, -Wuninitialized, -Wunsequenced) not apparently "fixed" yet. [1] http://lists.freebsd.org/pipermail/freebsd-current/2013-February/040160.html From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 16:08:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3874E409 for ; Wed, 27 Feb 2013 16:08:37 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id D0861B43 for ; Wed, 27 Feb 2013 16:08:36 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id z53so662377wey.1 for ; Wed, 27 Feb 2013 08:08:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=RsYbZd/eBQ6u3v4vW/e++zNmBkid8FTp1cwcRR/qG5I=; b=XH5+ReIDbS2sYZwRMwR9YQnYJh9eqgmOQKimLsUReXVJlpW0HUXKIi71qWOQvrD7nz r6Fp77r/XteLCtPhyQcMm9OFq5jGNBEMrVRasE/kcyqEuSSOpFO4bbsiMrU8xFujGqZ6 t8aUAEOco0JULflpr8yYXPmxchoJ0nMlRsm6mNAtZcvoLYfXQEhpVp5U0np6DiadD1Al 9d/7/7WY6Y24W8zOo4RtZTEgySlVpspoqV0Tylw9AswPE6PoWBGFbT0fUg/Sq+fpnq3H W7s7L+AQs7+okePul991MZwqGG/Y74Iz3M8lGzP8GnHTjgOb1EaWivzJl+VIBzLmuv1H n1Ig== MIME-Version: 1.0 X-Received: by 10.181.12.103 with SMTP id ep7mr27291912wid.12.1361981315789; Wed, 27 Feb 2013 08:08:35 -0800 (PST) Received: by 10.194.86.167 with HTTP; Wed, 27 Feb 2013 08:08:35 -0800 (PST) In-Reply-To: <20130226122039.GN2454@kib.kiev.ua> References: <20130226122039.GN2454@kib.kiev.ua> Date: Wed, 27 Feb 2013 19:08:35 +0300 Message-ID: Subject: Re: [patch] Proposal: move getmntopts(3) into libutil From: Sergey Kandaurov To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 16:08:37 -0000 On 26 February 2013 16:20, Konstantin Belousov wrote: > On Tue, Feb 26, 2013 at 02:39:26PM +0300, Sergey Kandaurov wrote: >> Hi. >> >> The functions from sbin/mount/getmntopts.c are used in a bunch of other >> stuff like mount_* utilities which have to suck them in as their own >> functions in quite a hackish way. getmntopts.c copies are compiled in to >> an every utility-consumer instead of being present in one place. Looks >> like getmntopts.c was brought together with mount_ufs.c in 4.4BSD-Lite. >> After that other mount_* were converted to use getmntopts(). > Yes, this is ugly. On the other hand, compiling the functions into > mount binaries makes them not to depend on the yet another library. > It cannot be an argument for rejecting your patch, only a point to > consider. I'm afraid this is the price for the change. No better thoughts. >> The attached patch moves them to the IMHO architecturally more correct >> place: a separate library -lutil. >> sbin/mount/mntopts.h -> include/mntopts.h > I think the mntopts.h should be moved to lib/libutil then, and installed > by libutil Makefile. That's reasonable, thanks. Patch is updated with your correction. I have put it on freefall for convenience. http://people.freebsd.org/~pluknet/patches/getmntopts.2.patch > >> sbin/mount/getmntopts.[3c] -> lib/libutil/getmntopts.[3c] > I assume that the move is done by 'svn mv' to preserve the history. Yes. Unfortunately svn stat cannot nicely represent 'svn mv' ops. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 16:09:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 87455529 for ; Wed, 27 Feb 2013 16:09:58 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by mx1.freebsd.org (Postfix) with ESMTP id 440BDB67 for ; Wed, 27 Feb 2013 16:09:57 +0000 (UTC) Received: by mail-ve0-f178.google.com with SMTP id db10so741230veb.37 for ; Wed, 27 Feb 2013 08:09:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=V88v/opiAj+pmezD4VraUfm6SvWQplCOMlr4L80LyWU=; b=eBYiQOGkgVV1dVvne5Cd/4F2TI4G8c22+1ycL5bf9ceBkXlpMAf/YQSeGNCCe7FSad PgkZ/xp4ok6WJdJT3yHVRmtRMEYPrDNjfzoCD0eCQ8hFXqvgZFnDmJekaa3Z4IiqRanB 1NwefL2TE+baqHk80LcTC6bSu6dzbRkyoJC83QM3hcfyTsR0GuGBZUZNtxo1fL30osqx ajI4VKx1IgW6yBwr03EZpplx1aq944JAtrzEV6ojyPMeyFN8sj26H5IkGULh/wYkTlLx Hrl8I8lLzc9Ds65Um8m0hLPPic9EfRMUGNcbGHfbT0+JsrfFzdu4KVi9LBzEjF5wtCik VAeg== MIME-Version: 1.0 X-Received: by 10.220.154.148 with SMTP id o20mr1056585vcw.54.1361981397249; Wed, 27 Feb 2013 08:09:57 -0800 (PST) Received: by 10.58.170.36 with HTTP; Wed, 27 Feb 2013 08:09:57 -0800 (PST) In-Reply-To: References: <512DE205.4010202@digsys.bg> Date: Wed, 27 Feb 2013 08:09:57 -0800 Message-ID: Subject: Re: Response of *.freebsd.org websites are very slow From: Mehmet Erol Sanliturk To: Daniel Nebdal Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Current , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 16:09:58 -0000 On Wed, Feb 27, 2013 at 7:20 AM, Daniel Nebdal wrote: > On Wed, Feb 27, 2013 at 3:28 PM, Mehmet Erol Sanliturk > wrote: > > > > > > On Wed, Feb 27, 2013 at 6:22 AM, Daniel Nebdal > wrote: > >> > >> Ok, that's weird. What does a simple "nslookup ftp.freebsd.org" give > you? > >> > >> On Wed, Feb 27, 2013 at 3:11 PM, Mehmet Erol Sanliturk > >> wrote: > >> > On Wed, Feb 27, 2013 at 2:37 AM, Daniel Kalchev > >> > wrote: > >> > > >> >> > >> >> > >> >> On 27.02.13 12:23, Daniel Nebdal wrote: > >> >> > >> >>> I think you're supposed to be automatically sent to the mirror that > is > >> >>> closest to you - for some value of "closest". If the mirror you're > >> >>> getting has issues, that might show up like this. Could you post the > >> >>> output of "traceroute ftp.freebsd.org" ? It should show which > mirror > >> >>> you're getting, and perhaps if there are any obvious problems on the > >> >>> way. > >> >>> > >> >> > >> >> I believe, in his case that would be "traceroute ftp.tr.freebsd.org > ". > >> >> The > >> >> list of mirrors is here http://www.freebsd.org/doc/** > >> >> > >> >> handbook/mirrors-ftp.html< > http://www.freebsd.org/doc/handbook/mirrors-ftp.html> > >> >> > >> >> in any case, "anything *.freebsd.org" actually refers to plenty of > >> >> hosts > >> >> all over the world -- some might be slow, some very fast. > >> >> > >> >> On the other hand, "Address could not be found" type of errors > >> >> indicates > >> >> something else than "fast" or "slow". > >> >> > >> >> Daniel > >> >> > >> > > >> > > >> > "traceroute ftp.tr.freebsd.org" > >> > > >> > is working . > >> > > >> > > >> > "traceroute ftp.freebsd.org " > >> > > >> > is NOT working . > >> > > >> > > > > > > > > > nslookup ftp.freebsd.org > > > > ;; connection timed out ; trying next origin > > ;; connection timed out ; no servers could be reached > > > > > > > > netbsd , openbsd , dragonflybsd is working . > > ftp.tr.freebsd.org is working . > > > > > > > > > > > >> > >> > Thank you very much . > >> > > >> > Mehmet Erol Sanliturk > >> > > > So nslookup (of ftp.freeebsd.org) fails on FreeBSD, but not the other > BSDs? That's very strange. Is /etc/resolv.conf the same in FreeBSD and > one of the working ones? Have you set up a firewall on the FreeBSD > install? Does it have IPv6? > > -- > Daniel Nebdal > There is no any *BSD installed at present and used . ( Problem is not related to FreeBSD operating system itself .) The commands are used from Linux . It is possible to access netbsd , openbsd , dragonflybsd sites by these commands from Linux , but freebsd sites are not accessible due to very late response . There is no any firewall , there is no IPv6 . When Linux $ traceroute -4 ftp.freebsd.org is used , it is mostly accessible ( 4 successes , 1 failure ) . When Linux $ traceroute -6 ftp.freebsd.org is used , it is NOT accessible ( 5 failures ) . When Linux $ traceroute ftp.freebsd.org is used , it is mostly accessible now . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 16:17:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AF13DAE0 for ; Wed, 27 Feb 2013 16:17:57 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by mx1.freebsd.org (Postfix) with ESMTP id 51F5EC3D for ; Wed, 27 Feb 2013 16:17:57 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id fn15so627737wgb.32 for ; Wed, 27 Feb 2013 08:17:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bpRrSCh9o913RvYAQaEfFncGmmZNd1tGneZd9Lp2QDk=; b=Melx2n/NGIY9GJqm3nzzcC1D7ZdzTbsnks05olm9luybYUpco20Dah1EPKgpOqUQX9 YU8Rxtem8hH7Q9lwbdoHbDOn47D4c9zI98qCOwnYb/qEl9Iq42gWvwhm4FRJIyeGk1LE CWU+MalKDa0wGAm7Pv+vEzwiGW/TSBBLHK+siZulAbxbguMyyJ7F0GXx1xK3AqwBaUq1 HT7NYYHoA3EubDXbTX5RACdVSrd6sziwPTQ1XvbTFtfDqWLMxvlF6p19y5yTX61n1Vwx xgOrKh5IhdQUoJIqyscv2iuVpOEd3zw3Mpt2S8DxkECpyYTQZgsjqJ/+cu1uMBUgoBYI A0DA== MIME-Version: 1.0 X-Received: by 10.194.6.2 with SMTP id w2mr5159526wjw.10.1361981876291; Wed, 27 Feb 2013 08:17:56 -0800 (PST) Received: by 10.194.86.167 with HTTP; Wed, 27 Feb 2013 08:17:56 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Feb 2013 19:17:56 +0300 Message-ID: Subject: Re: [patch] Proposal: move getmntopts(3) into libutil From: Sergey Kandaurov To: Craig Rodrigues Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 16:17:57 -0000 On 26 February 2013 23:11, Craig Rodrigues wrote: > On Tue, Feb 26, 2013 at 3:39 AM, Sergey Kandaurov wrote: >> >> Hi. >> >> >> >> External mount-like utilities may also have difficulties with building >> to get getmntopts.c source as this requires /usr/src presence which is >> in sync with installed world. Look how mount_fusefs from ports compiles: >> # mount_fusefs needs mntopts.h and getmntopts.c from src/sbin/mount/ > > > I have no object in moving getmntopts.c to libutil. > > I'll give some history to some of this stuff, to the best of my ability. > A few years ago, phk@ made a big change by introducing the nmount() system > call to replace mount(). > Look at all mount-related commits around this time: > http://lists.freebsd.org/pipermail/cvs-src/2004-December/author.html#36373 > > This required changing every file system, and for old file systems which > supported the "classic mount" cmount(), > in each file system, the cmount() call had to internally call the nmount() > code. > > In addition, phk made a pass to clean up all the userland mount programs to > use nmount(). There was a lot > of duplicated ("copy and pasted") code in various mount programs. I helped > in the effort to clean up some of the userland mount() programs. > > pjd@ proposed to make the main /sbin/mount load a shared library for each > specific file system, > and each shared library would have file-system specific mount logic. For > example: > > mount -t newfoofs /dev/blah /mnt > > would internally do something like: > > dlopen("libmount_newfoofs",.....); > > > phk@ opposed this approach, saying that it could lead to ABI/API problems, > library mismatches, etc. > So we kept the existing approach. I modified /sbin/mount to by default use > nmount() and only > for certain file systems, exec an external mount program. > > phk's ideas for getmntopts.c was always to keep it as a place where > "library-like" functions for mounting > file systems would be kept. To avoid library mismatch problems, it was kept > has a C file directly compiled > into the mount programs. Sure, keeping it directly compiled has its own benefits. Reading your mail is very educational, thank you. > > I have no problems keeping getmntopts.c in a separate library. libutil is > fine, or even a separate libmntutil (or whatever). > Just keep in mind the issues that could possibly come up if there is a > mismatch between > the userland mount programs, and the library which contains getmntopts.c > > Other than that, you proposal is quite reasonable, and I have no issue with > it. Although libutil is already used with such binaries like mount and mountd, library mismatch is a real concern. I will need to think somewhat more. Thanks for looking at this. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 17:12:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1106D9B2; Wed, 27 Feb 2013 17:12:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D5CB7F77; Wed, 27 Feb 2013 17:12:50 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3E588B976; Wed, 27 Feb 2013 12:12:50 -0500 (EST) From: John Baldwin To: matt Subject: Re: Fixing X220 Video The Right Way Date: Wed, 27 Feb 2013 12:00:22 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <512A6FFF.2060603@gmail.com> <201302261346.46197.jhb@freebsd.org> <512D7041.50608@gmail.com> In-Reply-To: <512D7041.50608@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201302271200.22976.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Feb 2013 12:12:50 -0500 (EST) Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 17:12:51 -0000 On Tuesday, February 26, 2013 9:32:33 pm matt wrote: > On 02/26/13 10:46, John Baldwin wrote: > > On Monday, February 25, 2013 11:20:29 pm matt wrote: > >> On 02/25/13 18:33, Adrian Chadd wrote: > >>> [101232] acpi_video0: on vgapci0 > >>> found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 > >>> > >>> And what do I do with acpi_get_handle ? > >>> > >>> > >>> > >>> > >> I threw printfs into acpi_video, not sure if that would work for both > >> vgapci or not. > >> I'm not sure if I wiped out my debug patches yet, I may have a patch. > >> Basically the idea is to figure out which paths in the DSDT are getting > >> attached to the vgapci devices. > > devinfo -v already tells you that. > > > > For example: > > > > nexus0 > > acpi0 > > pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0 > > pci0 > > hostb0 pnpinfo vendor=0x8086 device=0x0100 subvendor=0x8086 > > subdevice=0x2010 class=0x060000 at slot=0 function=0 > > pcib1 pnpinfo vendor=0x8086 device=0x0101 subvendor=0x8086 > > subdevice=0x2010 class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.PEG1 > > pci1 > > vgapci0 pnpinfo vendor=0x10de device=0x0605 subvendor=0x3842 > > subdevice=0xc973 class=0x030000 at slot=0 function=0 > > > > (My desktop doesn't have acpi_video and doesn't have an ACPI handle for the > > vgapci device, but you can see how it displays the handle for other PCI > > devices like pcib1 which are in the ACPI namespace.) > > > >> It seems like we could either try to find these paths on affected > >> models, or have a tunable override for acpi_video. > > Note that the Linux discussion you posted seems a bit off. The _ADR is > > not supposed to be unique to the entire system. For PCI devices, _ADR > > contains the PCI device (slot) and function (as slot << 16 | func), and > > the domain:bus portion of the address is implied by the parent PCI bus > > device in the ACPI namespace. Thus, the specific handle assigned by ACPI > > is for the exact PCI location of the requisite vgapci device. If your > > BIOS lies it is hard for us to do anything useful, at least automatically. > > > > Do the other devices in your system that have _DOD or _DOS methods show > > up as unknown ACPI devices in your devinfo -v output? > It's not in devinfo at all for me, Adrian may have a different situation. > > So my laptop has _SB.PCI0.PEG.VID and _SB.PCI0.VID > Only _SB.PCI0.VID is represented in devinfo -rv. > As far as I know, PEG is not a "real" device, but an abstraction, > possibly for Optimus use. > It makes calls to \VIGD (integrated graphics?) and \ISOP (isOptimus?) > This is potentially the broken bios part of things. > > I think I have multiple ACPI devices for a single physical device, and > pci is attaching the wrong ACPI device to the physical device in an ivar. > acpi_video happily uses this ivar to attempt to control video brightness. > > I could be entirely wrong on that, all I do know is that the working > handle doesn't get used and the useless handle does. If that is true, it's because your BIOS is lying. Do you have a URL to your ASL lying around already? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 17:12:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 46F3B9B4 for ; Wed, 27 Feb 2013 17:12:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 22139F79 for ; Wed, 27 Feb 2013 17:12:52 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7932DB91E; Wed, 27 Feb 2013 12:12:51 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: CPU0: Local APIC error 0x80 Date: Wed, 27 Feb 2013 12:08:39 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <512A70AC.6050906@gmail.com> In-Reply-To: <512A70AC.6050906@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302271208.39119.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Feb 2013 12:12:51 -0500 (EST) Cc: matt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 17:12:52 -0000 On Sunday, February 24, 2013 2:57:32 pm matt wrote: > What does this mean exactly? > > Whenever I call/evaluate certain ACPI paths, this gets printed on console. > > I assume it's a concurrent access issue or something, or perhaps just a > bios/uefi problem? #define APIC_ESR_ILLEGAL_REGISTER 0x00000080 It means something wrote to an invalid lapic register. It is probably a bug in your BIOS, yes. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 18:16:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7D3A5146 for ; Wed, 27 Feb 2013 18:16:38 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by mx1.freebsd.org (Postfix) with ESMTP id 57164396 for ; Wed, 27 Feb 2013 18:16:38 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id bh2so587486pad.30 for ; Wed, 27 Feb 2013 10:16:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8YQ/+frtYSExJWm8LMjiSXJ0WsNwNQatqBJ/rkgT8Yo=; b=d3UZlNvALCCiupOOy6M6ZaBgW2DNyZrkBaP8E559nSdy8iEzo3CGiOve6ogaRP7otR FdQD43BJMYOg+xdykCHwYFE2TMjXUYOwa8pIj2wU11ROSxrDNScrDDUfu6LiF0Z+Una/ pQx5CnKm4pOJxMiGCAMS8Azpo6wEjKS025z3KTee9nebSdPDqcg7ZGjKZk8wV5zkNXuf i7r/tn34+u8Or37W0MaLe/izAvv8opP+nbVUh4q4PTVcVhukh+EoSJ2Vaye+QcOa+12G WKjjgJAV8YNN5i1P498NICYdCC3BTVPW0WTc07Qx2dN/xG75/3RKgUintXftUrx7jAs6 OmTg== X-Received: by 10.66.12.73 with SMTP id w9mr8645249pab.208.1361988992636; Wed, 27 Feb 2013 10:16:32 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id kl4sm5390774pbc.31.2013.02.27.10.16.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 10:16:31 -0800 (PST) Message-ID: <512E4D3F.6050900@gmail.com> Date: Wed, 27 Feb 2013 10:15:27 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130224 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mehmet Erol Sanliturk Subject: Re: Response of *.freebsd.org websites are very slow References: <512DE205.4010202@digsys.bg> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Current , Daniel Nebdal , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:16:38 -0000 On 02/27/13 06:28, Mehmet Erol Sanliturk wrote: > > > nslookup ftp.freebsd.org > > ;; connection timed out ; trying next origin > ;; connection timed out ; no servers could be reached > > > > netbsd , openbsd , dragonflybsd is working . > ftp.tr.freebsd.org is working . > > > > What is `cat /etc/resolv.conf` (any of those OS) Matt From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 18:18:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B7E3A396; Wed, 27 Feb 2013 18:18:44 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8F85C3EA; Wed, 27 Feb 2013 18:18:44 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id kq12so586271pab.29 for ; Wed, 27 Feb 2013 10:18:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=upWSxYYqK3oWoMK8SumUlNdfXHwUYr46MIb2sEfGOuE=; b=AdYrPDqIaF79OLhtbDaZqwZLOLUTyhsCjhLecuWYUPxk20ifo3ZxNheSXkr2VyW62r F7W11MMZers7Jhbo+Bbe+v+Nm5s8imgoS4Q43G/5cIp1fnUXg/fhT8Ao+kqk0DblNz7l 8N8k+ygQ/kaaVp6H+kCNgpUdZTppfJQUqK1Juso4KiDJs48mYMk5AkeDaVPU0AhWGgQR DM3UYOLCw1deHY2er2mULYGKFV5yExEm5VqJz1OkwPYMcqqTG7XuG6Ztl3Z+TCDiJbTe DdkmNHPNoAZ4AiK7rdRZiRliYNOWGBJCo5jG6GpB+YxHhOkd8VnXbCfNTovpgfMbZU8J s7NA== X-Received: by 10.66.163.104 with SMTP id yh8mr8842198pab.170.1361989124062; Wed, 27 Feb 2013 10:18:44 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id u10sm6125928pax.14.2013.02.27.10.18.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 10:18:43 -0800 (PST) Message-ID: <512E4DC4.5070608@gmail.com> Date: Wed, 27 Feb 2013 10:17:40 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130224 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Baldwin Subject: Re: CPU0: Local APIC error 0x80 References: <512A70AC.6050906@gmail.com> <201302271208.39119.jhb@freebsd.org> In-Reply-To: <201302271208.39119.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:18:44 -0000 On 02/27/13 09:08, John Baldwin wrote: > On Sunday, February 24, 2013 2:57:32 pm matt wrote: >> What does this mean exactly? >> >> Whenever I call/evaluate certain ACPI paths, this gets printed on console. >> >> I assume it's a concurrent access issue or something, or perhaps just a >> bios/uefi problem? > #define APIC_ESR_ILLEGAL_REGISTER 0x00000080 > > It means something wrote to an invalid lapic register. It is probably a bug > in your BIOS, yes. > Not surprising, is there any potential damage from allowing it to continue? Thanks, Matt From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 18:25:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8661278F for ; Wed, 27 Feb 2013 18:25:11 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by mx1.freebsd.org (Postfix) with ESMTP id 4600F661 for ; Wed, 27 Feb 2013 18:25:11 +0000 (UTC) Received: by mail-ve0-f181.google.com with SMTP id d10so922410vea.12 for ; Wed, 27 Feb 2013 10:25:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=p0xCO4qjNZW2rNEZ6EQFTkiZZHkP2u44gwVjVdQTCEc=; b=EJ459aYbxA/2ryqxBBLJLYXX6TXojRlWTlR16wJJHmcmnLC94LjKbTlSx0NLoTDiDq 39nWyVOHnkJMkRs6rdqef+zxWUIejFexCvDEXdfJxqnxCXnJR2WmFkdO4hlssyRo3aME ihX0lFVzhhnZvP0wFRRa/L3P4ReyopMKy6B/rB9gSf/t+RO3kiS0jVHGMDjxoLBRHj5m f0NI3PKIlLxrm7fTIqpMH6+fJ+rfz7AbuH6mYaNbDsxMzI4TMaqBS4LglYZbl/QqvsRD BjJAioQnrlctSUzECufVd4Ynj754xiiC47d5BurRKUcomzNo62tO4ooV6v/XkcgM6R48 ErCQ== MIME-Version: 1.0 X-Received: by 10.220.40.9 with SMTP id i9mr1279438vce.23.1361989510223; Wed, 27 Feb 2013 10:25:10 -0800 (PST) Received: by 10.58.170.36 with HTTP; Wed, 27 Feb 2013 10:25:10 -0800 (PST) In-Reply-To: <512E4D3F.6050900@gmail.com> References: <512DE205.4010202@digsys.bg> <512E4D3F.6050900@gmail.com> Date: Wed, 27 Feb 2013 10:25:10 -0800 Message-ID: Subject: Re: Response of *.freebsd.org websites are very slow From: Mehmet Erol Sanliturk To: matt Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Current , Daniel Nebdal , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:25:11 -0000 On Wed, Feb 27, 2013 at 10:15 AM, matt wrote: > On 02/27/13 06:28, Mehmet Erol Sanliturk wrote: > > > > > > nslookup ftp.freebsd.org > > > > ;; connection timed out ; trying next origin > > ;; connection timed out ; no servers could be reached > > > > > > > > netbsd , openbsd , dragonflybsd is working . > > ftp.tr.freebsd.org is working . > > > > > > > > > What is `cat /etc/resolv.conf` (any of those OS) > > Matt > Unfortunately , I did not mention that these are the related web sites , not operating systems . They are used for comparison to understand whether problem belong to my side or to the FreeBSD web sites . I was using Linux for tests , because there is no any installed BSD operating system now . Within a few hours I will try to install latest 9.1 snapshot from ftp.freebsd.org . It is not the subject of this message but there is one very unfortunate situation that at present there is no any BSD operating system distribution which installs , works and can be used like Fedora , Mageia , Ubuntu , OpenSuse , Mint , PCLinuxOS , etc. . Thank you very much . Mehmet Erol Sanliturk . From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 18:36:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A78D8AE3; Wed, 27 Feb 2013 18:36:53 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by mx1.freebsd.org (Postfix) with ESMTP id 5CBD26F4; Wed, 27 Feb 2013 18:36:53 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id hz10so596853pad.7 for ; Wed, 27 Feb 2013 10:36:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xMKxkaPCNudB3g5ea+qbCl8PotRXE2vhXm1vyKsnB1w=; b=IUM1wlPDAPjlJ1OdH/Mvakbk1INczJitTsEasflGCZxQuf2fCIc3AYxR8P8RlVHTo/ S8KW5CLjEteuI0KduJI07eNkI6NIb0m4S4mGKQkO/d88jGbBAbCxBiy//L5W9dBsEgCj aOFwjBWdEOFqOFuKMNRR6bjb5z+jAvriysc2Z7DizsBnV6dV/LGh3qebPH+x9/ZsQPMN xCpw1PHx5YMcqJs24vm+YH+dfjY8Wk8lvAfY+G0koMbFsKEQv/9O3tC+KJdEOxqSkTkY QF+4a5tPT22w5VyktFM2U1M27pD5si7yNd1XrpIO3degWugP3nqfnk45zAaMhMAepOhb s0Uw== X-Received: by 10.66.157.100 with SMTP id wl4mr9236167pab.84.1361990207614; Wed, 27 Feb 2013 10:36:47 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id mz8sm2799529pbc.9.2013.02.27.10.36.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 10:36:46 -0800 (PST) Message-ID: <512E51FF.5010701@gmail.com> Date: Wed, 27 Feb 2013 10:35:43 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130224 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Baldwin Subject: Re: Fixing X220 Video The Right Way References: <512A6FFF.2060603@gmail.com> <201302261346.46197.jhb@freebsd.org> <512D7041.50608@gmail.com> <201302271200.22976.jhb@freebsd.org> In-Reply-To: <201302271200.22976.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:36:53 -0000 On 02/27/13 09:00, John Baldwin wrote: > If that is true, it's because your BIOS is lying. Do you have a URL to > your ASL lying around already? Too big for pastebin :( +500k https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing Thanks, Matt From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 18:43:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5B4FEF34 for ; Wed, 27 Feb 2013 18:43:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id A30EF75D for ; Wed, 27 Feb 2013 18:43:05 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1RIh1w1058194; Wed, 27 Feb 2013 20:43:01 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r1RIh1w1058194 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1RIh1kt058193; Wed, 27 Feb 2013 20:43:01 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 27 Feb 2013 20:43:01 +0200 From: Konstantin Belousov To: Sergey Kandaurov Subject: Re: [patch] Proposal: move getmntopts(3) into libutil Message-ID: <20130227184301.GB2454@kib.kiev.ua> References: <20130226122039.GN2454@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fh+fyCUbzktHKe74" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:43:06 -0000 --Fh+fyCUbzktHKe74 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Feb 27, 2013 at 07:08:35PM +0300, Sergey Kandaurov wrote: > I have put it on freefall for convenience. > http://people.freebsd.org/~pluknet/patches/getmntopts.2.patch Should the synopsis for getmntopts(3) use #include , instead of '"', as well as the example ? For the mntopts.h itself, I suggest to add an include guard, it is required for system header. I would also take an opportunity and wrapped long lines in mntopts.h in the same change. --Fh+fyCUbzktHKe74 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRLlO0AAoJEJDCuSvBvK1Bf9sP/RGV0Gj+nv0YDxiiWXCCjp7C f62MfSL+yW7VRvsPUe8W3tXmUkqyn3ln+ESLsylely+e+QupIaprozYsJ6mHjcGC M0/v+DQq7HbI6pzRiGc2v1US+qw3j/bo9dE5qMnd3ij2Ze50NtPq0HIuKJ0t6+9B S2zYDJYz8SyOIGBskwF33rbWU18TNn9FjNfRTuNr2py2b48zMED+3R1mTelbuNxg /jCALjgOBqhrpB+vkMCv4d0JqNoYwGNL3FA0WWxpIkMW2KL/q3/rkJhMdEH4nJjE zr8A/R/kGYNxV4YUJj2Fykjs7fyItliZuL4gT1MnoZq/EfUhVXNwotP16eTazAeg m9IBzMoRrXibTFkj+1kij1AQRKcS1jd/5dAE7sBswyxIAv7yigkmV8aG0DMj4vId /nCHUDbHbOBd4xe6UzS60xtgea6D4PqV5nW1lXJ87qN9EzPA5Nua/2LQ+T6GvYMc 0BDB7EWU3lMHp5QOQ36itlsdqr0csO0uKz62VM8OHTQjZ4D3l/L8ApfYq/G+vpem 9/ei6eyKmD1XLEIoBXqMCC9XgdlX/jGUes2HZs739was3cXUpYeAwdrvxE34PQuT gNYD4iN90dTxiHuvTIeOx8KsxXIjjqKT6yYj2Dyr/dXo/p0G9baQ96hESfXtnWGj d6sFl9S0IQz8xuph8tzF =5P87 -----END PGP SIGNATURE----- --Fh+fyCUbzktHKe74-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 19:26:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B5EC3D28 for ; Wed, 27 Feb 2013 19:26:06 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by mx1.freebsd.org (Postfix) with ESMTP id 777DE961 for ; Wed, 27 Feb 2013 19:26:06 +0000 (UTC) Received: by mail-ve0-f177.google.com with SMTP id m1so985644ves.36 for ; Wed, 27 Feb 2013 11:26:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jeaONzbXPOcsAgv9yuOIeyNQ6Z9sFDxuhqTGAFOzGYs=; b=VfyZI8wWZ7Uifu1raG6xTNgUh9eXGa00ayTSHoP7v63KCfVlxlQrh7Jy7l9YUwBK3r Ned4up3iXmpTHcalvoZU/6OQot/Ldt1vL9S4uL3SzRUnP6JTzW+O6vYxs5RSSKFPctTT QWnxgT8vMOsXZpnxwjdT2jq5Td8H8tlJ9/JqdJYeANzSbf8nIbffa7CYmett6GH8F/NO aDP8YbCfDwb5lBtBIBtGrTd6DfiEG8y+SuB1yqXlYdv8isOcs/gT18D7XoWFrnjX9XGz nHU8kNu6i07b4jE8rM61R4xWBSm+fMp1VovrX7OlD1YcXBbwjvTULTxynsg5Yt+2qfyq ko4g== MIME-Version: 1.0 X-Received: by 10.220.40.9 with SMTP id i9mr1359135vce.23.1361993159966; Wed, 27 Feb 2013 11:25:59 -0800 (PST) Received: by 10.58.170.36 with HTTP; Wed, 27 Feb 2013 11:25:59 -0800 (PST) In-Reply-To: <512E4D3F.6050900@gmail.com> References: <512DE205.4010202@digsys.bg> <512E4D3F.6050900@gmail.com> Date: Wed, 27 Feb 2013 11:25:59 -0800 Message-ID: Subject: Re: Response of *.freebsd.org websites are very slow From: Mehmet Erol Sanliturk To: matt Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Current , Daniel Nebdal , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 19:26:06 -0000 I have installed snapshot FreeBSD-9.1-STABLE-amd64-20130223-r247167-release.iso # traceroute ftp.freebsd.org 3 failures : traceroute : unknown host ftp.freebsd.org 2 successes : Route is Izmir ( Turkey ) -> Frankfurt -> New York -> San Jose -> freebsd.isc.org ( 204.152.184.73 ) and pkg_add is not able to find package site . Perhaps for many tries it may find in some of the tries , but this will not be a feasible way . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 20:00:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A07AADCE for ; Wed, 27 Feb 2013 20:00:29 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by mx1.freebsd.org (Postfix) with ESMTP id 27839B0B for ; Wed, 27 Feb 2013 20:00:29 +0000 (UTC) Received: by mail-ve0-f180.google.com with SMTP id jx10so1027497veb.11 for ; Wed, 27 Feb 2013 12:00:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=ftnXSAbAmTdhrSNorawzB4h80J12XHQ/p++nDHYWoIE=; b=Tf+T3yIeJmm4SgeeHx/gruFClKywzjqkNEWhFXtavFQdTDfORyXrHDlMPfubefIb4B UPUpKKi4bhFQQwOIY39NwEUKYkzmkt1OciDiOx0EMp0HCrbv5xUpUOmo0p73HtIkOibJ pr1+Gxv9suhBDZzby0L3/3okU/jQveawE5aQgrpV3caTHpXYLlpbGWSZByXRm5C0a+Se FzxNMjGqcGFzdMZnm+KPLSCXYULuQbYEjeN2l0939Rhw/bOiLwaT6krJ8BVg37POl82a 1h6Zz7txX4TpAzDDdOns4jXLW/qZdS5FvaUsAmr35wfLjiBDK5zXKcaO/GaLTpb8x/N3 +nkA== MIME-Version: 1.0 X-Received: by 10.220.107.210 with SMTP id c18mr1426324vcp.5.1361995228382; Wed, 27 Feb 2013 12:00:28 -0800 (PST) Received: by 10.58.170.36 with HTTP; Wed, 27 Feb 2013 12:00:28 -0800 (PST) Date: Wed, 27 Feb 2013 12:00:28 -0800 Message-ID: Subject: Re: Response of *.freebsd.org websites are very slow From: Mehmet Erol Sanliturk To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 20:00:29 -0000 Dear All , I have set PACKAGESITE to ftp1.freebsd.org where its destination is moss.cse.buffalo.edu ( 128.205.32.24 ) : It is working very well . I tried a download for testing from mirrors.isc.org : ~300 kb/sec ( some times more slow . I am not using this mirror because it is consistently slow . ) mirror.hs-esslingen.de : ~2000 kb/sec . It seems that the trouble point is *.isc.org . It is very likely that , if any one reaches to *.isc.org , his/her access is slow , others may be fast , if it is not slow accidentally . Therefore , access speed will depend on mirror speed . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 20:01:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 33DB5EFF for ; Wed, 27 Feb 2013 20:01:15 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by mx1.freebsd.org (Postfix) with ESMTP id E3815B31 for ; Wed, 27 Feb 2013 20:01:14 +0000 (UTC) Received: by mail-ve0-f181.google.com with SMTP id d10so1003515vea.26 for ; Wed, 27 Feb 2013 12:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nkFjereRjHrq9pPIp8WrmLuqIf94wxDI+269Ijt6ZgY=; b=wh/j44/+OCpDyMJYfc1lW7tN/N8w4lmtJWauPPG8M2jB48kN9QIhIPfYYU/zq+xLey ZxYeZusEEJbyZz0DJGU/OjDxCnqQrc51gYaDxBlRP6L+HlW/Xdg0ng0IppB2hWmfGH65 DbFvuALngtcdikxK/ANu0xT4tqPUiEUpB84GU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=nkFjereRjHrq9pPIp8WrmLuqIf94wxDI+269Ijt6ZgY=; b=cn2U/ND50K3ugfm5ViLcCeZ2KdtmPdpktMl1OMFDslahbEHQO3/dI8x15GZouK90Id b3w575TdBu/WPnQcNfYROYK4twxpf9W0YxWnOQrJcIgXsa/YklS10sgIsoKKD+5k8RYs 5PbAm69/N0AeyrauZoGDkiZN2XTrlklSI0V1zFiKa0n5Tcyq6y/yugGFjT2mDBPD23Ot e1+eHHQZ/HdzgPnCMT4r/E5VrRHQueuPyLgRB6dZQAifUbChdusb+QXfgbDNjvg8Ygx1 p/8n0ilIdt5Mbd8P/Koqkov865TKjavI2aSAWIHilQHhHr/9oDRsjh46XisX39EulkNH Lz5A== MIME-Version: 1.0 X-Received: by 10.58.220.229 with SMTP id pz5mr1443626vec.30.1361995274167; Wed, 27 Feb 2013 12:01:14 -0800 (PST) Received: by 10.220.163.198 with HTTP; Wed, 27 Feb 2013 12:01:14 -0800 (PST) In-Reply-To: References: <512DE205.4010202@digsys.bg> <512E4D3F.6050900@gmail.com> Date: Wed, 27 Feb 2013 12:01:14 -0800 Message-ID: Subject: Re: Response of *.freebsd.org websites are very slow From: Peter Wemm To: Mehmet Erol Sanliturk Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnOLR/543LcAyeHFzVv7xwUyJW2CLH32o8n+IgT/WdwuB51OHez0pznV4jsZQ95P+QthyDn Cc: matt , Current , Daniel Nebdal , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 20:01:15 -0000 On Wed, Feb 27, 2013 at 11:25 AM, Mehmet Erol Sanliturk wrote: > I have installed snapshot > > FreeBSD-9.1-STABLE-amd64-20130223-r247167-release.iso > > # traceroute ftp.freebsd.org > > 3 failures : traceroute : unknown host ftp.freebsd.org > 2 successes : > > Route is Izmir ( Turkey ) -> Frankfurt -> New York -> San Jose -> > freebsd.isc.org ( 204.152.184.73 ) > > and pkg_add is not able to find package site . > > Perhaps for many tries it may find in some of the tries , but this will not > be a feasible way . Clearly you are having dns problems. First, try a dig with the +trace flag, eg: $ dig +trace www.freebsd.org. ; <<>> DiG 9.8.3-P1 <<>> +trace www.freebsd.org. ;; global options: +cmd . 518400 IN NS e.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS l.root-servers.net. ;; Received 512 bytes from 10.0.0.1#53(10.0.0.1) in 234 ms org. 172800 IN NS a2.org.afilias-nst.info. org. 172800 IN NS d0.org.afilias-nst.org. org. 172800 IN NS c0.org.afilias-nst.info. org. 172800 IN NS b0.org.afilias-nst.org. org. 172800 IN NS a0.org.afilias-nst.info. org. 172800 IN NS b2.org.afilias-nst.org. ;; Received 435 bytes from 2001:500:2d::d#53(2001:500:2d::d) in 1469 ms freebsd.org. 86400 IN NS ns1.isc-sns.net. freebsd.org. 86400 IN NS ns2.isc-sns.com. freebsd.org. 86400 IN NS ns3.isc-sns.info. ;; Received 132 bytes from 199.19.56.1#53(199.19.56.1) in 1165 ms www.freebsd.org. 120 IN CNAME wfe0.ysv.freebsd.org. wfe0.ysv.freebsd.org. 3600 IN A 8.8.178.110 freebsd.org. 3600 IN NS ns2.isc-sns.com. freebsd.org. 3600 IN NS ns1.isc-sns.net. freebsd.org. 3600 IN NS ns3.isc-sns.info. ;; Received 264 bytes from 63.243.194.1#53(63.243.194.1) in 27 ms Note the isc-sns.com/net/info addresses. These are our public-facing DNS servers and are distributed around the world. You should see something like this: $ host ns1.isc-sns.net ns1.isc-sns.net has address 72.52.71.1 ... ns2.isc-sns.com has address 38.103.2.1 ns3.isc-sns.info has address 63.243.194.1 It would be interesting to see traceroutes to these IP addresses. You had problems above with the nslookup commands. You might try this: $ nslookup www.freebsd.org ns1.isc-sns.net Server: ns1.isc-sns.net Address: 2001:470:1a::1#53 www.freebsd.org canonical name = wfe0.ysv.freebsd.org. Name: wfe0.ysv.freebsd.org Address: 8.8.178.110 or even: $ nslookup www.freebsd.org 72.52.71.1 Server: 72.52.71.1 Address: 72.52.71.1#53 www.freebsd.org canonical name = wfe0.ysv.freebsd.org. Name: wfe0.ysv.freebsd.org Address: 8.8.178.110 What does your /etc/resolv.conf file look like? What happens if you change it to (as a debugging aid): $ cat /etc/resolf.conf nameserver 8.8.8.8 nameserver 8.8.4.4 Does that change anything? -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 20:07:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DA0D7123 for ; Wed, 27 Feb 2013 20:07:24 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by mx1.freebsd.org (Postfix) with ESMTP id 6870DBD6 for ; Wed, 27 Feb 2013 20:07:24 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id p16so679306vcq.29 for ; Wed, 27 Feb 2013 12:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=G2LCQ0gOM+2uv9mIxMyAtyAJNSdWvW9cxN/hg8aO/Mg=; b=qJiCeeR7VL4lGXhTlQnVobohV+YTEkc+jxdM49vN0QsQUr8liA2/M0IfU9c3ldhbKx kAbfBAcV0bA8JmP0hLe/648MYx93SiIv1BPK9oTOtIv/egXXx1D1kYIDJSYrlm4Spo8Q tosbSunsRy+H2z/L0C8QMT7ni09hGIG/NxfUDo3fuQsq5R4uqGUefkVaykeDwz7SmEwd Usav3cV9APATXvVNzq9CrX9ehSU+Efe+VULFX3zns8CV/Ezq4Ux+eIqYVLXBc8PpRZJ3 jXltP6qPrSjs0PV7rRiZsqMN62Or9pkyjoTMLw2Yw2FSns+YN+dmgBymwYJxxHRZGAOF iBrw== MIME-Version: 1.0 X-Received: by 10.52.68.116 with SMTP id v20mr1195480vdt.126.1361995636879; Wed, 27 Feb 2013 12:07:16 -0800 (PST) Received: by 10.58.170.36 with HTTP; Wed, 27 Feb 2013 12:07:16 -0800 (PST) In-Reply-To: <512E64CA.6030408@daemonic.se> References: <512DE205.4010202@digsys.bg> <512E4D3F.6050900@gmail.com> <512E64CA.6030408@daemonic.se> Date: Wed, 27 Feb 2013 12:07:16 -0800 Message-ID: Subject: Re: Response of *.freebsd.org websites are very slow From: Mehmet Erol Sanliturk To: Niclas Zeising Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: matt , Current , Daniel Nebdal , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 20:07:24 -0000 On Wed, Feb 27, 2013 at 11:55 AM, Niclas Zeising wrote: > On 2013-02-27 20:25, Mehmet Erol Sanliturk wrote: > > I have installed snapshot > > > > FreeBSD-9.1-STABLE-amd64-20130223-r247167-release.iso > > > > # traceroute ftp.freebsd.org > > > > 3 failures : traceroute : unknown host ftp.freebsd.org > > 2 successes : > > > > Route is Izmir ( Turkey ) -> Frankfurt -> New York -> San Jose -> > > freebsd.isc.org ( 204.152.184.73 ) > > > > and pkg_add is not able to find package site . > > > > Perhaps for many tries it may find in some of the tries , but this will > not > > be a feasible way . > > Does Turkey (or your ISP) have any sort of great firewall or other > restrictions on network traffic? Do you have a firewall somewhere? > I have no trouble reaching www.freebsd.org and ftp.freebsd.org from 3 > different ASes using both IPv4 and IPv6. > Regards! > -- > Niclas > After the above message , I have sent the following message : http://lists.freebsd.org/pipermail/freebsd-current/2013-February/040176.html This means that there is no any restriction in Turkey : The problem source is response time of the destination mirror server . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 20:12:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0D823450 for ; Wed, 27 Feb 2013 20:12:30 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by mx1.freebsd.org (Postfix) with ESMTP id B1540C47 for ; Wed, 27 Feb 2013 20:12:29 +0000 (UTC) Received: by mail-ve0-f171.google.com with SMTP id b10so1023482vea.16 for ; Wed, 27 Feb 2013 12:12:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jYEp/gAhWGw9kiwOot3UrIvZtBYI82sygKF7BL8zQnQ=; b=o2mojIBnb97RvQ230Jm7qBCS0G4HZjH9qN1/xq1vqGfMHJvyFuA9YAohSGhiSfXgjI xauFouA3y+tjjqyuL6s9k9qg8yIH+BHVF/NHpw25W+qRkBPJqPI2vIeivwUSnhat4mBn cE9R7+U83u2Dmbmbcejwrb1jB24smooUUT9u6u68V5udIhRcStsREJ/SdWUbYR0VtO1f aWOhDnc+/vI1TbxMFDTVoXvTnNuBx9rhCqlpOB3uCtFxKkOWCXV9Xm5MGWFPk2mSh8K0 LqqLHMXv5cd7D5P4/rDac2CHc//ptikG6m0K5Xh8T71zfT2x19Yg6+5d1pmp1mTlTA93 Qt0A== MIME-Version: 1.0 X-Received: by 10.52.23.238 with SMTP id p14mr1215882vdf.86.1361995948817; Wed, 27 Feb 2013 12:12:28 -0800 (PST) Received: by 10.58.170.36 with HTTP; Wed, 27 Feb 2013 12:12:28 -0800 (PST) In-Reply-To: References: <512DE205.4010202@digsys.bg> <512E4D3F.6050900@gmail.com> Date: Wed, 27 Feb 2013 12:12:28 -0800 Message-ID: Subject: Re: Response of *.freebsd.org websites are very slow From: Mehmet Erol Sanliturk To: Peter Wemm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: matt , Current , Daniel Nebdal , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 20:12:30 -0000 On Wed, Feb 27, 2013 at 12:01 PM, Peter Wemm wrote: > On Wed, Feb 27, 2013 at 11:25 AM, Mehmet Erol Sanliturk > wrote: > > I have installed snapshot > > > > FreeBSD-9.1-STABLE-amd64-20130223-r247167-release.iso > > > > # traceroute ftp.freebsd.org > > > > 3 failures : traceroute : unknown host ftp.freebsd.org > > 2 successes : > > > > Route is Izmir ( Turkey ) -> Frankfurt -> New York -> San Jose -> > > freebsd.isc.org ( 204.152.184.73 ) > > > > and pkg_add is not able to find package site . > > > > Perhaps for many tries it may find in some of the tries , but this will > not > > be a feasible way . > > Clearly you are having dns problems. > > First, try a dig with the +trace flag, eg: > > $ dig +trace www.freebsd.org. > > ; <<>> DiG 9.8.3-P1 <<>> +trace www.freebsd.org. > ;; global options: +cmd > . 518400 IN NS e.root-servers.net. > . 518400 IN NS j.root-servers.net. > . 518400 IN NS h.root-servers.net. > . 518400 IN NS d.root-servers.net. > . 518400 IN NS f.root-servers.net. > . 518400 IN NS b.root-servers.net. > . 518400 IN NS i.root-servers.net. > . 518400 IN NS g.root-servers.net. > . 518400 IN NS c.root-servers.net. > . 518400 IN NS k.root-servers.net. > . 518400 IN NS a.root-servers.net. > . 518400 IN NS m.root-servers.net. > . 518400 IN NS l.root-servers.net. > ;; Received 512 bytes from 10.0.0.1#53(10.0.0.1) in 234 ms > > org. 172800 IN NS a2.org.afilias-nst.info. > org. 172800 IN NS d0.org.afilias-nst.org. > org. 172800 IN NS c0.org.afilias-nst.info. > org. 172800 IN NS b0.org.afilias-nst.org. > org. 172800 IN NS a0.org.afilias-nst.info. > org. 172800 IN NS b2.org.afilias-nst.org. > ;; Received 435 bytes from 2001:500:2d::d#53(2001:500:2d::d) in 1469 ms > > freebsd.org. 86400 IN NS ns1.isc-sns.net. > freebsd.org. 86400 IN NS ns2.isc-sns.com. > freebsd.org. 86400 IN NS ns3.isc-sns.info. > ;; Received 132 bytes from 199.19.56.1#53(199.19.56.1) in 1165 ms > > www.freebsd.org. 120 IN CNAME wfe0.ysv.freebsd.org. > wfe0.ysv.freebsd.org. 3600 IN A 8.8.178.110 > freebsd.org. 3600 IN NS ns2.isc-sns.com. > freebsd.org. 3600 IN NS ns1.isc-sns.net. > freebsd.org. 3600 IN NS ns3.isc-sns.info. > ;; Received 264 bytes from 63.243.194.1#53(63.243.194.1) in 27 ms > > Note the isc-sns.com/net/info addresses. These are our public-facing > DNS servers and are distributed around the world. > > You should see something like this: > $ host ns1.isc-sns.net > ns1.isc-sns.net has address 72.52.71.1 > ... > ns2.isc-sns.com has address 38.103.2.1 > ns3.isc-sns.info has address 63.243.194.1 > > It would be interesting to see traceroutes to these IP addresses. > > You had problems above with the nslookup commands. You might try this: > $ nslookup www.freebsd.org ns1.isc-sns.net > Server: ns1.isc-sns.net > Address: 2001:470:1a::1#53 > > www.freebsd.org canonical name = wfe0.ysv.freebsd.org. > Name: wfe0.ysv.freebsd.org > Address: 8.8.178.110 > > or even: > $ nslookup www.freebsd.org 72.52.71.1 > Server: 72.52.71.1 > Address: 72.52.71.1#53 > > www.freebsd.org canonical name = wfe0.ysv.freebsd.org. > Name: wfe0.ysv.freebsd.org > Address: 8.8.178.110 > > What does your /etc/resolv.conf file look like? > > > What happens if you change it to (as a debugging aid): > $ cat /etc/resolf.conf > nameserver 8.8.8.8 > nameserver 8.8.4.4 > > Does that change anything? > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; > KI6FJV > bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE > Please see the following message : http://lists.freebsd.org/pipermail/freebsd-current/2013-February/040178.html ftp1.freebsd.org is working wonderfully now . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 19:56:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 10E1A9FB for ; Wed, 27 Feb 2013 19:56:07 +0000 (UTC) (envelope-from zeising@daemonic.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id B7A95AC6 for ; Wed, 27 Feb 2013 19:56:06 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 3DF0340005 for ; Wed, 27 Feb 2013 20:56:05 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 3025840008; Wed, 27 Feb 2013 20:56:05 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (h-45-105.a163.priv.bahnhof.se [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id A9DA440005; Wed, 27 Feb 2013 20:56:03 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3ZGSLq267Wz8hVm; Wed, 27 Feb 2013 20:56:03 +0100 (CET) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([IPv6:2001:470:dca9:0:1::3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) (amavisd-new, port 10025) with ESMTPS id RQF0-DzWoyE9; Wed, 27 Feb 2013 20:56:01 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 3ZGSLn1kX3z8hVt; Wed, 27 Feb 2013 20:56:01 +0100 (CET) Received: from [IPv6:2001:470:dca9:1::3] (celes.daemonic.se [IPv6:2001:470:dca9:1::3]) by mail.daemonic.se (Postfix) with ESMTPSA id 3ZGSLn0tXGz9CwY; Wed, 27 Feb 2013 20:56:01 +0100 (CET) Message-ID: <512E64CA.6030408@daemonic.se> Date: Wed, 27 Feb 2013 20:55:54 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Mehmet Erol Sanliturk Subject: Re: Response of *.freebsd.org websites are very slow References: <512DE205.4010202@digsys.bg> <512E4D3F.6050900@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Wed, 27 Feb 2013 20:57:30 +0000 Cc: matt , Current , Daniel Nebdal , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 19:56:07 -0000 On 2013-02-27 20:25, Mehmet Erol Sanliturk wrote: > I have installed snapshot > > FreeBSD-9.1-STABLE-amd64-20130223-r247167-release.iso > > # traceroute ftp.freebsd.org > > 3 failures : traceroute : unknown host ftp.freebsd.org > 2 successes : > > Route is Izmir ( Turkey ) -> Frankfurt -> New York -> San Jose -> > freebsd.isc.org ( 204.152.184.73 ) > > and pkg_add is not able to find package site . > > Perhaps for many tries it may find in some of the tries , but this will not > be a feasible way . Does Turkey (or your ISP) have any sort of great firewall or other restrictions on network traffic? Do you have a firewall somewhere? I have no trouble reaching www.freebsd.org and ftp.freebsd.org from 3 different ASes using both IPv4 and IPv6. Regards! -- Niclas From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 21:56:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7E3065E3 for ; Wed, 27 Feb 2013 21:56:54 +0000 (UTC) (envelope-from dantavious313@gmail.com) Received: from mail-gg0-x22c.google.com (mail-gg0-x22c.google.com [IPv6:2607:f8b0:4002:c02::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 40AB12D2 for ; Wed, 27 Feb 2013 21:56:54 +0000 (UTC) Received: by mail-gg0-f172.google.com with SMTP id f4so169405ggn.17 for ; Wed, 27 Feb 2013 13:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:user-agent:mime-version :content-transfer-encoding:content-type; bh=LsWj6RxWJxU0nMKA/T2RoLFA+3R28F1MWx84pCKyphA=; b=v45uqPv+tIH4UuVnL4XnKWf6qSUPs+Z312ysmxKQF/MdEjpLhE20WDQxhQVeZiO3lq hJ7aanrwrA++3PSM30SaMvIAFWLotpHhEblaPPWuPjwCbqykQgYmVgRRN9loMTzU/cGN cemtpsXjLxJZb6hFWjBD/uxIW+CrVR4FKnFaktnkXCBWJ8w66O3WWeBoL4/4bhE90Rk4 InQtoz7NwQAEaRD+ZbMPlh9aibbdzUWal2wPXpP5pnPLeOAM6X9GLGz/hoR2VdRKOMq1 XU9pq7FM83RBL1uUwlHxyHt4T3s1VIcb917C501rrg9gTE5/7jY47BgJf7Wz1PZsfYdd JotQ== X-Received: by 10.236.153.131 with SMTP id f3mr2869090yhk.145.1362002213477; Wed, 27 Feb 2013 13:56:53 -0800 (PST) Received: from zeus.localnet (c-71-226-137-213.hsd1.ga.comcast.net. [71.226.137.213]) by mx.google.com with ESMTPS id d80sm9900374yhg.4.2013.02.27.13.56.52 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 13:56:52 -0800 (PST) From: Derrick Dantavious Edwards To: freebsd-current Subject: ZFS problems Date: Wed, 27 Feb 2013 16:56:50 -0500 Message-ID: <1953411.keAzGZcpTL@zeus> User-Agent: KMail/4.9.5 (FreeBSD/10.0-CURRENT; KDE/4.9.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 21:56:54 -0000 I updated sources a couple of days ago and when I rebooted to continue to the upgrade process I received errors when I attempted to mount zfs filesystem. The error looked like this. zpool mount -a internal error: Invalid arugment pid 25 (zfs), uid 0, exited on signal 6 Abort trap I get the same error if I just type zpool status -v, except the (zfs) is replace with (zpool). The kernel module is loaded and visible by kldstat. Any ideas? From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 22:08:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5FC33D6B; Wed, 27 Feb 2013 22:08:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3D5803C9; Wed, 27 Feb 2013 22:08:53 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 747FAB97C; Wed, 27 Feb 2013 17:08:52 -0500 (EST) From: John Baldwin To: matt Subject: Re: Fixing X220 Video The Right Way Date: Wed, 27 Feb 2013 15:27:36 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <512A6FFF.2060603@gmail.com> <201302271200.22976.jhb@freebsd.org> <512E51FF.5010701@gmail.com> In-Reply-To: <512E51FF.5010701@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302271527.37079.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Feb 2013 17:08:52 -0500 (EST) Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 22:08:53 -0000 On Wednesday, February 27, 2013 1:35:43 pm matt wrote: > On 02/27/13 09:00, John Baldwin wrote: > > If that is true, it's because your BIOS is lying. Do you have a URL to > > your ASL lying around already? > Too big for pastebin :( +500k > > https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing Here is where I find _DOD and _DOS methods: Device (PCI0) Device (VID) Name (_ADR, 0x00020000) // _ADR: Address Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices Device (PEG) Name (_ADR, 0x00010000) // _ADR: Address Device (VID) Name (_ADR, 0x00) // _ADR: Address Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices PCI0.VID is a PCI device at pci0:0:2:0. PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0. It would have a child device at 0:0 that would be PCI0.PEG.VID. Does the X220 have a switchable GPU (e.g. it has built-in Intel graphics, but also has an Nvidia GPU or some such?). If so, I imagine that PCI0.VID is the Intel graphics and PEG is the non-Intel. The output of 'pciconf -lcv' would be useful to determine that. If both PCI devices exist you shoudl have both acpi_video0 and acpi_video1. However, it may be that the acpi_video driver doesn't cope well with having multiple devices. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 22:08:55 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 01B59D6D for ; Wed, 27 Feb 2013 22:08:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D54CD3CA for ; Wed, 27 Feb 2013 22:08:54 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2738CB97D; Wed, 27 Feb 2013 17:08:54 -0500 (EST) From: John Baldwin To: matt Subject: Re: CPU0: Local APIC error 0x80 Date: Wed, 27 Feb 2013 15:27:55 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <512A70AC.6050906@gmail.com> <201302271208.39119.jhb@freebsd.org> <512E4DC4.5070608@gmail.com> In-Reply-To: <512E4DC4.5070608@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302271527.55519.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Feb 2013 17:08:54 -0500 (EST) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 22:08:55 -0000 On Wednesday, February 27, 2013 1:17:40 pm matt wrote: > On 02/27/13 09:08, John Baldwin wrote: > > On Sunday, February 24, 2013 2:57:32 pm matt wrote: > >> What does this mean exactly? > >> > >> Whenever I call/evaluate certain ACPI paths, this gets printed on console. > >> > >> I assume it's a concurrent access issue or something, or perhaps just a > >> bios/uefi problem? > > #define APIC_ESR_ILLEGAL_REGISTER 0x00000080 > > > > It means something wrote to an invalid lapic register. It is probably a bug > > in your BIOS, yes. > > > Not surprising, is there any potential damage from allowing it to continue? Probably not. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 22:44:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0BA09A2D for ; Wed, 27 Feb 2013 22:44:36 +0000 (UTC) (envelope-from prvs=17707c68ac=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id A482C801 for ; Wed, 27 Feb 2013 22:44:35 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50002438974.msg for ; Wed, 27 Feb 2013 22:44:31 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 27 Feb 2013 22:44:31 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=17707c68ac=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-current@freebsd.org Message-ID: <46832A2E33D240EABA0FBCF5F9C404C2@multiplay.co.uk> From: "Steven Hartland" To: "Derrick Dantavious Edwards" , "freebsd-current" References: <1953411.keAzGZcpTL@zeus> Subject: Re: ZFS problems Date: Wed, 27 Feb 2013 22:44:55 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 22:44:36 -0000 ----- Original Message ----- From: "Derrick Dantavious Edwards" > I updated sources a couple of days ago and when I rebooted to continue to > the upgrade process I received errors when I attempted to mount zfs > filesystem. The error looked like this. > > zpool mount -a > > internal error: Invalid arugment > pid 25 (zfs), uid 0, exited on signal 6 > Abort trap Is your world and kernel out of sync? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 22:59:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 00202E5B for ; Wed, 27 Feb 2013 22:59:22 +0000 (UTC) (envelope-from seanwbruno@gmail.com) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by mx1.freebsd.org (Postfix) with ESMTP id 982B48DD for ; Wed, 27 Feb 2013 22:59:22 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hm6so1377993wib.2 for ; Wed, 27 Feb 2013 14:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0hD7lkw/xnqXPrAxp/74lCe5AbDNx8Wa/n23KacGQRM=; b=d2xxexDhSA/YLKBR4+E/TJjAe4xWvClRismb0rm1nhqTrmntvSlCXEvyx6coocGytw rg+m6u+DoP2OA/OpEZyKM7ArtUO5+JZqQgq6/t1RhIP75Qk1Fs1JaHk/Ze13tTg83nAJ 2NxW82DFq7YsbKhikQT1xLhOnT2Me+XpQuUFsDmpSJjhvbt4d7sQJ8zkTFjTHXpEHkkk PCFI7HuhYJ4LWFxwyYjPKXZNm2Di6kx3A/tIUJmsYFsUwxmaF5cc2nEPRHFuMDxe4d1p t8QHMH2L1+Ukd9vaMVlFHxiHAL4WzDHSX6DkqwOVDHMHovbl3nxSVoNp+YaZlAujhQVh /Czg== MIME-Version: 1.0 X-Received: by 10.194.103.72 with SMTP id fu8mr7121922wjb.42.1362005956677; Wed, 27 Feb 2013 14:59:16 -0800 (PST) Received: by 10.194.139.193 with HTTP; Wed, 27 Feb 2013 14:59:16 -0800 (PST) In-Reply-To: <46832A2E33D240EABA0FBCF5F9C404C2@multiplay.co.uk> References: <1953411.keAzGZcpTL@zeus> <46832A2E33D240EABA0FBCF5F9C404C2@multiplay.co.uk> Date: Wed, 27 Feb 2013 14:59:16 -0800 Message-ID: Subject: Re: ZFS problems From: sean bruno To: Steven Hartland Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current , Derrick Dantavious Edwards X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 22:59:23 -0000 On Wed, Feb 27, 2013 at 2:44 PM, Steven Hartland wrote: > ----- Original Message ----- From: "Derrick Dantavious Edwards" > > >> I updated sources a couple of days ago and when I rebooted to continue to >> the upgrade process I received errors when I attempted to mount zfs >> filesystem. The error looked like this. >> >> zpool mount -a >> >> internal error: Invalid arugment >> pid 25 (zfs), uid 0, exited on signal 6 >> Abort trap > > > Is your world and kernel out of sync? > > > Regards > Steve > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. and the > person or entity to whom it is addressed. In the event of misdirection, the > recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Yup, totally hit this today and was yelling at various people about it. the Kernel and the ZFS tools in userland need to be updated at the same time. Boot back into the old kernel and (cd /usr/src/cddl && make install) to update the tools to a compatible version. sean From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 23:06:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ED04A16D; Wed, 27 Feb 2013 23:06:03 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id C40A892F; Wed, 27 Feb 2013 23:06:03 +0000 (UTC) Received: from glenbarber.us (75-146-225-65-Philadelphia.hfc.comcastbusiness.net [75.146.225.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 903F323F645; Wed, 27 Feb 2013 18:06:01 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.8.0 onyx.glenbarber.us 903F323F645 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Wed, 27 Feb 2013 18:05:59 -0500 From: Glen Barber To: sbruno@freebsd.org Subject: Re: ZFS problems Message-ID: <20130227230559.GD82833@glenbarber.us> References: <1953411.keAzGZcpTL@zeus> <46832A2E33D240EABA0FBCF5F9C404C2@multiplay.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pQhZXvAqiZgbeUkD" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current , Steven Hartland , Derrick Dantavious Edwards X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 23:06:04 -0000 --pQhZXvAqiZgbeUkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2013 at 02:59:16PM -0800, sean bruno wrote: > Yup, totally hit this today and was yelling at various people about it. >=20 > the Kernel and the ZFS tools in userland need to be updated at the same t= ime. >=20 > Boot back into the old kernel and (cd /usr/src/cddl && make install) > to update the tools to a compatible version. >=20 To make sure you are loading the _old_ zfs/opensolaris modules, this should work at the loader prompt: unload /boot/kernel/zfs.ko unload /boot/kernel/opensolaris.ko unload /boot/kernel/kernel set kernelname=3D/boot/kernel.old/kernel set module_path=3D/boot/kernel.old boot kernel.old Glen --pQhZXvAqiZgbeUkD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRLpFXAAoJEFJPDDeguUajBjEH/3ymGCjAztm8jPuatNOXTEj2 DdzHqDoS0RMGEhZp7cHhPvV0fOUDEyrh3UBJXQnWpvEcuGyy72Au1YHbYbw1tHTJ UypatzfWSdS+7WcTFIZncU2fhsbtYdjEaWyuxzhp2r9YEZUFKaRWTLR8+0S/3kFB PQ//RktJpzbWyTKAHylMxfGWtc24MQH0c3DMIREq/8aB2wDZnw9kfVnOA9sD9U6O K0M2kxDBofLnirEn6a+hDinZasangWKuEQdGyix2D4rOlGB+s0wMWlJxoBPT+hPA q+eqj63Csf/hWuPOcLer0K1LMurMqtKTrLHKNmRDmkoLKTCuoRb6dO7NiyqYsFI= =Pxki -----END PGP SIGNATURE----- --pQhZXvAqiZgbeUkD-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 00:20:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1082B575; Thu, 28 Feb 2013 00:20:04 +0000 (UTC) (envelope-from dantavious313@gmail.com) Received: from mail-gg0-x233.google.com (mail-gg0-x233.google.com [IPv6:2607:f8b0:4002:c02::233]) by mx1.freebsd.org (Postfix) with ESMTP id BDDCEC0F; Thu, 28 Feb 2013 00:20:03 +0000 (UTC) Received: by mail-gg0-f179.google.com with SMTP id h4so187744ggn.24 for ; Wed, 27 Feb 2013 16:20:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding:content-type; bh=5hdR7+oNtIeJCErFJcFcx3ct7CBaa2K4M1p+i5ikPQk=; b=rm/Yv752ZUIki6znShQQMfBFtF/9FrYxa+wgz/+EbYBx0Mo13QIJ9uv1JlOCNtljzq CFDpVWcNlE7rzFm410fnZNdtur+M9LtlQT8XD/7gdOplFC8q2MYWNjt6/vRqgb7fYpRf kkvLe+zj7N4H+v6FdR55i1i0fZ436jOJqf4WppGBKQ+KHKY56goZGFZFIqVG3L+TDwU8 WNRTJDGWlkaDc2R23iaJ68iWCtuxTMTKSYG2kEe9YMyKqq7oPWwewiDH6+QuLOJxa/XO n8UEH5nR8gEyO/Abb541HNcMU0xsqGwo6WU9PiOc3u5LqdSMA4OsOybCDMBJw70arRuf kztA== X-Received: by 10.236.136.132 with SMTP id w4mr3180064yhi.152.1362010365185; Wed, 27 Feb 2013 16:12:45 -0800 (PST) Received: from zeus.localnet (c-71-226-137-213.hsd1.ga.comcast.net. [71.226.137.213]) by mx.google.com with ESMTPS id d3sm6410642yhh.25.2013.02.27.16.12.43 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 16:12:44 -0800 (PST) From: Derrick Dantavious Edwards To: sbruno@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS problems Date: Wed, 27 Feb 2013 19:12:42 -0500 Message-ID: <1923057.4uIrUH7rzG@zeus> User-Agent: KMail/4.9.5 (FreeBSD/10.0-CURRENT; KDE/4.9.5; amd64; ; ) In-Reply-To: References: <1953411.keAzGZcpTL@zeus> <46832A2E33D240EABA0FBCF5F9C404C2@multiplay.co.uk> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 00:20:04 -0000 On Wednesday, February 27, 2013 02:59:16 PM you wrote: > On Wed, Feb 27, 2013 at 2:44 PM, Steven Hartland > > wrote: > > ----- Original Message ----- From: "Derrick Dantavious Edwards" > > > >> I updated sources a couple of days ago and when I rebooted to continue to > >> the upgrade process I received errors when I attempted to mount zfs > >> filesystem. The error looked like this. > >> > >> zpool mount -a > >> > >> internal error: Invalid arugment > >> pid 25 (zfs), uid 0, exited on signal 6 > >> Abort trap > > > > Is your world and kernel out of sync? > > > > Regards > > Steve > > > > ================================================ > > This e.mail is private and confidential between Multiplay (UK) Ltd. and > > the > > person or entity to whom it is addressed. In the event of misdirection, > > the > > recipient is prohibited from using, copying, printing or otherwise > > disseminating it or any information contained in it. > > In the event of misdirection, illegible or incomplete transmission please > > telephone +44 845 868 1337 > > or return the E.mail to postmaster@multiplay.co.uk. > > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > Yup, totally hit this today and was yelling at various people about it. > > the Kernel and the ZFS tools in userland need to be updated at the same > time. > > Boot back into the old kernel and (cd /usr/src/cddl && make install) > to update the tools to a compatible version. > > sean From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 00:21:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C20EE6E1; Thu, 28 Feb 2013 00:21:43 +0000 (UTC) (envelope-from dantavious313@gmail.com) Received: from mail-gg0-x230.google.com (mail-gg0-x230.google.com [IPv6:2607:f8b0:4002:c02::230]) by mx1.freebsd.org (Postfix) with ESMTP id 64FE9C38; Thu, 28 Feb 2013 00:21:43 +0000 (UTC) Received: by mail-gg0-f176.google.com with SMTP id q6so187820ggc.21 for ; Wed, 27 Feb 2013 16:21:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding:content-type; bh=CUd1sk0gFpNDI84WTeJnDhIzkMbbZBEeTG+a3OkNaDg=; b=gYFwnvxJzUXkpyXKavFtKxB5Dvz78834PfggaDFgj0npjY7QjvSYIteq/B5RnKvCnP vwQ0oI+/l+Mec2jtXMbBZA+zNIWRHf47vNajGhVNm7XQzkDRQT+XiMVfQ6dKDDe6FiTX f21x3k5Gh+r6+tdRDJMtlxtxteqBWLi+fy3+jMIlLRw36EhPMt4jeyxemEb2KaewbHec g9kidplb1U+ey2n54/13F0b3JSX4Mb36L3RKAQqtku0s029FYrEw9F4merzEx9BHsqee 4c+kwLmQ4AR6k2K1+4aPgmFukQyip67X3hf69iNat0dEWuz1C3XlJwx19n/XJjdr/U1g udyA== X-Received: by 10.236.139.230 with SMTP id c66mr3164000yhj.168.1362010902006; Wed, 27 Feb 2013 16:21:42 -0800 (PST) Received: from zeus.localnet (c-71-226-137-213.hsd1.ga.comcast.net. [71.226.137.213]) by mx.google.com with ESMTPS id e8sm6445366yhh.16.2013.02.27.16.21.40 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 16:21:41 -0800 (PST) From: Derrick Dantavious Edwards To: sbruno@freebsd.org, freebsd-current@freebsd.org Subject: Re: ZFS problems Date: Wed, 27 Feb 2013 19:21:39 -0500 Message-ID: <9083248.zOq17M83H4@zeus> User-Agent: KMail/4.9.5 (FreeBSD/10.0-CURRENT; KDE/4.9.5; amd64; ; ) In-Reply-To: References: <1953411.keAzGZcpTL@zeus> <46832A2E33D240EABA0FBCF5F9C404C2@multiplay.co.uk> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 00:21:43 -0000 On Wednesday, February 27, 2013 02:59:16 PM you wrote: > On Wed, Feb 27, 2013 at 2:44 PM, Steven Hartland > > wrote: > > ----- Original Message ----- From: "Derrick Dantavious Edwards" > > > >> I updated sources a couple of days ago and when I rebooted to continue to > >> the upgrade process I received errors when I attempted to mount zfs > >> filesystem. The error looked like this. > >> > >> zpool mount -a > >> > >> internal error: Invalid arugment > >> pid 25 (zfs), uid 0, exited on signal 6 > >> Abort trap > > > > Is your world and kernel out of sync? > > > > Regards > > Steve > > > > ================================================ > > This e.mail is private and confidential between Multiplay (UK) Ltd. and > > the > > person or entity to whom it is addressed. In the event of misdirection, > > the > > recipient is prohibited from using, copying, printing or otherwise > > disseminating it or any information contained in it. > > In the event of misdirection, illegible or incomplete transmission please > > telephone +44 845 868 1337 > > or return the E.mail to postmaster@multiplay.co.uk. > > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > Yup, totally hit this today and was yelling at various people about it. > > the Kernel and the ZFS tools in userland need to be updated at the same > time. > > Boot back into the old kernel and (cd /usr/src/cddl && make install) > to update the tools to a compatible version. > > sean Thanks so much, this fix the issue for me. Derrick From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 00:33:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 30058E73; Thu, 28 Feb 2013 00:33:51 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id CB723D34; Thu, 28 Feb 2013 00:33:50 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 5006B23F645; Wed, 27 Feb 2013 19:33:48 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.8.0 onyx.glenbarber.us 5006B23F645 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Wed, 27 Feb 2013 19:33:46 -0500 From: Glen Barber To: Martin Matuska Subject: Re: ZFS problems Message-ID: <20130228003346.GE82833@glenbarber.us> References: <1953411.keAzGZcpTL@zeus> <46832A2E33D240EABA0FBCF5F9C404C2@multiplay.co.uk> <9083248.zOq17M83H4@zeus> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="47eKBCiAZYFK5l32" Content-Disposition: inline In-Reply-To: <9083248.zOq17M83H4@zeus> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 00:33:51 -0000 --47eKBCiAZYFK5l32 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Martin, On Wed, Feb 27, 2013 at 07:21:39PM -0500, Derrick Dantavious Edwards wrote: > > >> [...] > > >> I updated sources a couple of days ago and when I rebooted to contin= ue to > > >> the upgrade process I received errors when I attempted to mount zfs > > >> filesystem. The error looked like this. > > >>=20 > > >> zpool mount -a > > >>=20 > > >> internal error: Invalid arugment > >=20 > > [...] > > the Kernel and the ZFS tools in userland need to be updated at the same > > time. > >=20 > > Boot back into the old kernel and (cd /usr/src/cddl && make install) > > to update the tools to a compatible version. > >=20 In mid-February, zpool version was upgraded to include lz4_compress. My understanding was that changing from the OpenSolaris ZFS version number scheme (i.e., "v28") to what we have on -CURRENT (i.e., "5000") was so that we can track crossing the point of no return with pool version upgrades. On my system, vfs.zfs.version.spa has been at 5000 since this original change. Is my understanding incorrect? Or should vfs.zfs.version.spa be incremented with major, non-backwards-compatible changes? Thanks in advance. Glen --47eKBCiAZYFK5l32 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRLqXqAAoJEFJPDDeguUajNF4H/2X6la58Z9858N6yd/B/cwxY ByzGgbyaN8kqvN3XT4MkQRkekM3XyjlKHRa9Pbs9QBt1kQaszTQ9H7soURqflCM+ KrwcX0xRpS8Bm6Xnj8Ma+XnY+IYmPIYKEsYuRoPL6+JisPHWwWAGEaZ2fxai5Jng HBTkWShN1fHensDDNepFf4x72/eYxkJqykkp+gay6LMd3jrXnEd3bEuUKl4j43Mk r6l8Gr+OGIe34l8GmLLpQiGQ2m4eTFDtw5wIvYTstqXuCasqyJzjaff34xu9mSIa 3A9AmfW93I9Q30/+yUhzFA6Fn39PesnrPEPX7bQri4LI3RHMc4Gcmy74cCMW18M= =ZSSX -----END PGP SIGNATURE----- --47eKBCiAZYFK5l32-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 00:37:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E40C1FB5; Thu, 28 Feb 2013 00:37:48 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id CEEA8D6A; Thu, 28 Feb 2013 00:37:48 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 3FB62AFCD; Wed, 27 Feb 2013 16:37:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1362011868; bh=nCQPV1yG7AUiUV7Okvznpwg/uDf6C/sgHvOiOXz6u3k=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=2UwD7a8lNo07tRJqsszV5E+7/RwIhbydKu9ZjAtCztVg7B9L5urwTvjU/boZ8LOA2 g6Ix7aHC18/ll+lyL6MdZqC+S8Une1Ymvftf5t1YDJ1UdfXIyBzNxmmDD8WYoCkIla 6891FfLvyGlJM7Xmv+wBR1cauL4iPWLxYfZG6PRk= Message-ID: <512EA6DB.3040502@delphij.net> Date: Wed, 27 Feb 2013 16:37:47 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Glen Barber Subject: Re: ZFS problems References: <1953411.keAzGZcpTL@zeus> <46832A2E33D240EABA0FBCF5F9C404C2@multiplay.co.uk> <9083248.zOq17M83H4@zeus> <20130228003346.GE82833@glenbarber.us> In-Reply-To: <20130228003346.GE82833@glenbarber.us> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Martin Matuska X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 00:37:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/27/13 16:33, Glen Barber wrote: > Hi Martin, > > On Wed, Feb 27, 2013 at 07:21:39PM -0500, Derrick Dantavious > Edwards wrote: >>>>> [...] I updated sources a couple of days ago and when I >>>>> rebooted to continue to the upgrade process I received >>>>> errors when I attempted to mount zfs filesystem. The error >>>>> looked like this. >>>>> >>>>> zpool mount -a >>>>> >>>>> internal error: Invalid arugment >>> >>> [...] the Kernel and the ZFS tools in userland need to be >>> updated at the same time. >>> >>> Boot back into the old kernel and (cd /usr/src/cddl && make >>> install) to update the tools to a compatible version. >>> > > In mid-February, zpool version was upgraded to include > lz4_compress. My understanding was that changing from the > OpenSolaris ZFS version number scheme (i.e., "v28") to what we have > on -CURRENT (i.e., "5000") was so that we can track crossing the > point of no return with pool version upgrades. > > On my system, vfs.zfs.version.spa has been at 5000 since this > original change. > > Is my understanding incorrect? Or should vfs.zfs.version.spa be > incremented with major, non-backwards-compatible changes? That's incorrect. In theory vfs.zfs.version.spa will never ever change in the future, and all new features will be denoted by feature flags, which is an extensible way of representing features and whether they are compatible with the running system. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJRLqbbAAoJEG80Jeu8UPuzSC0IAKasVsGlPKhjTl7Eu/Ocmdxz ZnWC1hUEt6MJxrLPprRvDBZRMnGMD5YoQ8maMshy27FzxnKXJ3kHpX60gMCkkRFX aRI4cPTHm6w+935KOMjA/Mso7rM8MUmr6b4qhf0Ar/E55sThAvy3BO1R/KVWYRro 4LuwfHGIg6z/vNYo4SDAtw7SOcD43Wk5JTPb1WlAUJOgMiTK+ceFx7mpd5EYCPvb p6DWttzQ5yqxhmCayvBKLjpLBntdD4/88qRuMn5+TQBOZBrGoiK+9GZTwPMVu2U3 MT+hsUJ6uO8oPwKNSz6BgpP9BwyxreWEI/C7Wk0lbZkNeaauiPyN6qUiDD2di9g= =R5LQ -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 00:44:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5C1F3190; Thu, 28 Feb 2013 00:44:07 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 30EAFDA6; Thu, 28 Feb 2013 00:44:07 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 0247423F645; Wed, 27 Feb 2013 19:44:05 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.8.0 onyx.glenbarber.us 0247423F645 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Wed, 27 Feb 2013 19:44:04 -0500 From: Glen Barber To: d@delphij.net Subject: Re: ZFS problems Message-ID: <20130228004404.GF82833@glenbarber.us> References: <1953411.keAzGZcpTL@zeus> <46832A2E33D240EABA0FBCF5F9C404C2@multiplay.co.uk> <9083248.zOq17M83H4@zeus> <20130228003346.GE82833@glenbarber.us> <512EA6DB.3040502@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cz6wLo+OExbGG7q/" Content-Disposition: inline In-Reply-To: <512EA6DB.3040502@delphij.net> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Martin Matuska X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 00:44:07 -0000 --cz6wLo+OExbGG7q/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2013 at 04:37:47PM -0800, Xin Li wrote: > > In mid-February, zpool version was upgraded to include > > lz4_compress. My understanding was that changing from the > > OpenSolaris ZFS version number scheme (i.e., "v28") to what we have > > on -CURRENT (i.e., "5000") was so that we can track crossing the > > point of no return with pool version upgrades. > >=20 > > On my system, vfs.zfs.version.spa has been at 5000 since this > > original change. > >=20 > > Is my understanding incorrect? Or should vfs.zfs.version.spa be=20 > > incremented with major, non-backwards-compatible changes? >=20 > That's incorrect. In theory vfs.zfs.version.spa will never ever > change in the future, and all new features will be denoted by feature > flags, which is an extensible way of representing features and whether > they are compatible with the running system. >=20 Thank you for clarifying. As there does not seem to be a specific sysctl that we can look for, I am inclined to say there should be UPDATING entries for such changes to note (at least for now) that 'make -C /usr/src/cddl install' can help prevent foot shooting. Thoughts? Glen --cz6wLo+OExbGG7q/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRLqhUAAoJEFJPDDeguUajAPwH/j3P/pL0RiqmHN31t6aqvN8g O6rEgqHD41z8bFZaBvFax6iKgzMvu2XmhPTaOsxRxDCcRWQOnfE4PLipXdBHe4ri vhvOy9JWtqLOQOSoyXhAAIyoZ72ak3RCHgYrz55oaUo31zXA6WUz8wDgmXzCv2o2 i1GdTDcg7LNtVrxqgspBD/3jDQWhuUiqE43HRIOa+b036naiFfdBgoXG4P9CWaph 9+uXfDhakA4T2e1VOwxpEph4JnBGNpak6TolNk9ctqaIafSp71GuLEzLX53YGYKD eaAf4ghhLp8oQmZWHdjp9C4H6l/vgKQk14SGgf5tG88vmTYvAm0PpwbV/J7Qw20= =Oh+C -----END PGP SIGNATURE----- --cz6wLo+OExbGG7q/-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 00:54:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9576F8A8; Thu, 28 Feb 2013 00:54:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by mx1.freebsd.org (Postfix) with ESMTP id D77D3E30; Thu, 28 Feb 2013 00:54:58 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id dr13so973291wgb.26 for ; Wed, 27 Feb 2013 16:54:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yCgCqUxiYjEvQWOoqPXzCV6uPTMmMZvnQgVWrW0PO9w=; b=VbtNdn6Vq4GgDfmEmbuYHDDIGXEEHafQjwkgEI2Hj1W/rZK2pmJDYgPC/tPJ32F7JW Dni1Ec3/aUmKr/MuYOz97GHsvJTHUuofGI28OW6AW9Xc8kgJs/XsxuJWImGwqNB8+tTH HkyM1nvIKLrYa9W17NrlgVnv5Q2fMcrd25qMjJLdc3AVMSdc/ICWU4H588f+kawsCJFX SOyjXfuCeZXmzZ2K7/w1BFQxlTVEJ5rDD1XH6TNupRcSXhcm7u/XfTeMrbniY7D5cNic PsJ8DnILvvuRGDM+1orhyCENa+YL52o/QB1CVSos0GdkY46e4wWpKRXZtkFt9GIPLI0L E4QA== MIME-Version: 1.0 X-Received: by 10.194.110.69 with SMTP id hy5mr7636507wjb.1.1362012897696; Wed, 27 Feb 2013 16:54:57 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.114.201 with HTTP; Wed, 27 Feb 2013 16:54:57 -0800 (PST) In-Reply-To: <201302271527.37079.jhb@freebsd.org> References: <512A6FFF.2060603@gmail.com> <201302271200.22976.jhb@freebsd.org> <512E51FF.5010701@gmail.com> <201302271527.37079.jhb@freebsd.org> Date: Wed, 27 Feb 2013 16:54:57 -0800 X-Google-Sender-Auth: 10Le-jUNLA285hl3EjvWs9YXCoA Message-ID: Subject: Re: Fixing X220 Video The Right Way From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: matt , freebsd-acpi@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 00:54:59 -0000 I'll email later, but I do have two PCI devices show up in pciconf -lv; but acpi_video() only attaches to one. I don't know why two PCI devices show up.. guess there's more digging to do. ADrian From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 01:09:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E82D1F41; Thu, 28 Feb 2013 01:09:03 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id B7256ED1; Thu, 28 Feb 2013 01:09:03 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 37E3C24120; Wed, 27 Feb 2013 17:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1362013743; bh=t6PS+VS2+2byn6iUWUZ6Tp/ZG7ffEqhK0v++FQm/sPQ=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=VDBQEgtjpkoHUF0LxpG8BG6zBhKhHOKbe36iN4j5t3HbCTxYd6sGT6prWdvhsfBXz QV/oJJfohYJMnVVP+EcEKPz9oNbdpnxqWYGX9YTwJm+ieUbGLCaPyP+d15o1ZLFsoI ToB5k/RK/dvqu93cKiuXdsPlOO5jsj9l9BbhT598= Message-ID: <512EAE2E.9010903@delphij.net> Date: Wed, 27 Feb 2013 17:09:02 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Glen Barber Subject: Re: ZFS problems References: <1953411.keAzGZcpTL@zeus> <46832A2E33D240EABA0FBCF5F9C404C2@multiplay.co.uk> <9083248.zOq17M83H4@zeus> <20130228003346.GE82833@glenbarber.us> <512EA6DB.3040502@delphij.net> <20130228004404.GF82833@glenbarber.us> In-Reply-To: <20130228004404.GF82833@glenbarber.us> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, d@delphij.net, Martin Matuska X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 01:09:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/27/13 16:44, Glen Barber wrote: > On Wed, Feb 27, 2013 at 04:37:47PM -0800, Xin Li wrote: >>> In mid-February, zpool version was upgraded to include >>> lz4_compress. My understanding was that changing from the >>> OpenSolaris ZFS version number scheme (i.e., "v28") to what we >>> have on -CURRENT (i.e., "5000") was so that we can track >>> crossing the point of no return with pool version upgrades. >>> >>> On my system, vfs.zfs.version.spa has been at 5000 since this >>> original change. >>> >>> Is my understanding incorrect? Or should vfs.zfs.version.spa >>> be incremented with major, non-backwards-compatible changes? >> >> That's incorrect. In theory vfs.zfs.version.spa will never ever >> change in the future, and all new features will be denoted by >> feature flags, which is an extensible way of representing >> features and whether they are compatible with the running >> system. >> > > Thank you for clarifying. > > As there does not seem to be a specific sysctl that we can look > for, I am inclined to say there should be UPDATING entries for such > changes to note (at least for now) that 'make -C /usr/src/cddl > install' can help prevent foot shooting. Grrr I should have noticed this when doing code review for the change. No, this is not intentional and has to be fixed, the issue was introduced in r247265 ("deadman" feature). Martin actually have done very good job maintaining ioctl compatibility when we jumped from v15 to v28 that most people didn't even notice that the ioctl was changed. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJRLq4uAAoJEG80Jeu8UPuzlKAIAKPpCInGW6cIUXrrVkY11xMW IK49TAUrxbBECpgo86gNtUZjWt7ik7nYRjxvocR4qKK5yM35fKsAInEN6LOYLCJm ho4AIUex40sDr3K7avKMzi09Flsb3LfVtOYeAiZNk+oTPWRMj4vnw+VGxDMUq4/2 MXnaOpwI1mWDqnyBvtqspYh6dcUrqTX5+WrmucYuMgVHa7jsmJkorfhDp2ZBDjaM afbvuVxcWV0aCajg44EHfKwQxTKGSNPIs7x3BTxBkao+TVuT1KJHbebF4EapNhe9 7jwM6XJhnSKIgXYgy8hpUPZB81mvxtvLuimTXi7c2rA9vs7sFu05wXgjbmKNLyQ= =hW3e -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 01:32:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1372B985; Thu, 28 Feb 2013 01:32:58 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id A870AFD1; Thu, 28 Feb 2013 01:32:57 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 422AA23F645; Wed, 27 Feb 2013 20:32:56 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.8.0 onyx.glenbarber.us 422AA23F645 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Wed, 27 Feb 2013 20:32:54 -0500 From: Glen Barber To: d@delphij.net Subject: Re: ZFS problems Message-ID: <20130228013254.GA70215@glenbarber.us> References: <1953411.keAzGZcpTL@zeus> <46832A2E33D240EABA0FBCF5F9C404C2@multiplay.co.uk> <9083248.zOq17M83H4@zeus> <20130228003346.GE82833@glenbarber.us> <512EA6DB.3040502@delphij.net> <20130228004404.GF82833@glenbarber.us> <512EAE2E.9010903@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <512EAE2E.9010903@delphij.net> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Martin Matuska X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 01:32:58 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2013 at 05:09:02PM -0800, Xin Li wrote: > Martin actually have done very good job maintaining ioctl > compatibility when we jumped from v15 to v28 that most people didn't > even notice that the ioctl was changed. >=20 As one who has gone through that upgrade on head/, stable/9/, and stable/8/, I could not agree more. This is why I was a bit confused about vfs.zfs.version.spa, to be honest - I did not see any "version changes" associated, but only user reports about "old zfs tools" not working. Thanks for all the info. Glen --SUOF0GtieIMvvwua Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRLrPGAAoJEFJPDDeguUaj82oH+wQjwdDq98TwNmQNYr7k11AL K8int+cw6czRzEWGpkwTasR5gwj6Ow2aBHNuh5dHSrmjp/ZrgORT98cSlVrtmSTA m5CS+DaRIkXSJAF5iz/rUg2BxXQwWrQsigdSQSwTb3q9Ztf80y3bYs4RPeWM/6Ro /rrDm1Jan0FbYX2+cOqxNFqSvC7pOogR7sVYDmoUq/r+VM8VmITXTgTbFP2Ip6Rb tzumBBQ4aRjvP5oo3nPhDF5FmPGgEx5Wpp62/mNyA0h0z2BTC9dKRHa/VP3sT/X1 6hp6EbQBix1C5SkhZf1b+ZY+8CIIYiU44oGvnzKj8RfGFV/NaD5Q/fN6YQ5B25I= =8sKx -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 02:07:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8BE01488; Thu, 28 Feb 2013 02:07:12 +0000 (UTC) (envelope-from erich@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id B78AF1B0; Thu, 28 Feb 2013 02:07:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=AKwR7iI059Jq3kJy6WTnv83JYf70UOw4BKDdgQj2h+M=; b=PArHlRHYD+vttBmCRk+TMOwp1YLqny0pqxaDB/eleAeJf5zZERCx0GdBCrZVShv+47VsbRdq7AJdC1Kq9bkynUZGzoR/UoMmQKc42WN53fHOEYtQ/eQzFrXfnI37SgdI; Received: from [122.129.203.50] (port=50591 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UAsTK-00244A-SC; Wed, 27 Feb 2013 18:39:49 -0700 Date: Thu, 28 Feb 2013 08:39:22 +0700 From: Erich Dollansky To: John Baldwin Subject: Re: Fixing X220 Video The Right Way Message-ID: <20130228083922.31229fe0@X220.ovitrap.com> In-Reply-To: <201302271527.37079.jhb@freebsd.org> References: <512A6FFF.2060603@gmail.com> <201302271200.22976.jhb@freebsd.org> <512E51FF.5010701@gmail.com> <201302271527.37079.jhb@freebsd.org> Organization: ALO Green Technologies X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erich@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Thu, 28 Feb 2013 02:32:55 +0000 Cc: matt , Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 02:07:12 -0000 Hi, On Wed, 27 Feb 2013 15:27:36 -0500 John Baldwin wrote: > On Wednesday, February 27, 2013 1:35:43 pm matt wrote: > > On 02/27/13 09:00, John Baldwin wrote: > > > If that is true, it's because your BIOS is lying. Do you have a > > > URL to your ASL lying around already? > > Too big for pastebin :( +500k > > > > https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing > > the X220 have a switchable GPU (e.g. it has built-in Intel graphics, it has. > but also has an Nvidia GPU or some such?). If so, I imagine that No, it does not. > PCI0.VID is the Intel graphics and PEG is the non-Intel. The output > of 'pciconf -lcv' would be useful to determine that. If both PCI > devices exist you shoudl have both acpi_video0 and acpi_video1. > However, it may be that the acpi_video driver doesn't cope well with > having multiple devices. > Erich PS Here is the output: hostb0@pci0:0:0:0: class=0x060000 card=0x21da17aa chip=0x01048086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family DRAM Controller' class = bridge subclass = HOST-PCI cap 09[e0] = vendor (length 12) Intel cap 0 version 1 vgapci0@pci0:0:2:0: class=0x030000 card=0x21da17aa chip=0x01268086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family Integrated Graphics Controller' class = display subclass = VGA cap 05[90] = MSI supports 1 message enabled with 1 message cap 01[d0] = powerspec 2 supports D0 D3 current D0 cap 13[a4] = PCI Advanced Features: FLR TP none0@pci0:0:22:0: class=0x078000 card=0x21da17aa chip=0x1c3a8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family MEI Controller' class = simple comms cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[8c] = MSI supports 1 message, 64 bit uart2@pci0:0:22:3: class=0x070002 card=0x21da17aa chip=0x1c3d8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family KT Controller' class = simple comms subclass = UART cap 01[c8] = powerspec 3 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit em0@pci0:0:25:0: class=0x020000 card=0x21ce17aa chip=0x15028086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82579LM Gigabit Network Connection' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP ehci0@pci0:0:26:0: class=0x0c0320 card=0x21da17aa chip=0x1c2d8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family USB Enhanced Host Controller' class = serial bus subclass = USB cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] = PCI Advanced Features: FLR TP hdac0@pci0:0:27:0: class=0x040300 card=0x21da17aa chip=0x1c208086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family High Definition Audio Controller' class = multimedia subclass = HDA cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 05[60] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[70] = PCI-Express 1 root endpoint max data 128(128) FLR link x0(x0) ecap 0002[100] = VC 1 max VC1 ecap 0005[130] = Root Complex Link Declaration 1 pcib1@pci0:0:28:0: class=0x060400 card=0x21da17aa chip=0x1c108086 rev=0xb4 hdr=0x01 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family PCI Express Root Port 1' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 2 root port slot max data 128(128) link x0(x1) speed 0.0(5.0) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x21da17aa cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib2@pci0:0:28:1: class=0x060400 card=0x21da17aa chip=0x1c128086 rev=0xb4 hdr=0x01 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family PCI Express Root Port 2' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 2 root port slot max data 128(128) link x1(x1) speed 2.5(5.0) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x21da17aa cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib3@pci0:0:28:3: class=0x060400 card=0x21da17aa chip=0x1c168086 rev=0xb4 hdr=0x01 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family PCI Express Root Port 4' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 2 root port slot max data 128(128) link x0(x1) speed 0.0(5.0) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x21da17aa cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib4@pci0:0:28:4: class=0x060400 card=0x21da17aa chip=0x1c188086 rev=0xb4 hdr=0x01 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family PCI Express Root Port 5' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 2 root port slot max data 128(128) link x1(x1) speed 2.5(5.0) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x21da17aa cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib5@pci0:0:28:6: class=0x060400 card=0x21da17aa chip=0x1c1c8086 rev=0xb4 hdr=0x01 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family PCI Express Root Port 7' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 2 root port slot max data 128(128) link x1(x1) speed 5.0(5.0) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x21da17aa cap 01[a0] = powerspec 2 supports D0 D3 current D0 ehci1@pci0:0:29:0: class=0x0c0320 card=0x21da17aa chip=0x1c268086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family USB Enhanced Host Controller' class = serial bus subclass = USB cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] = PCI Advanced Features: FLR TP isab0@pci0:0:31:0: class=0x060100 card=0x21da17aa chip=0x1c4f8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'QM67 Express Chipset Family LPC Controller' class = bridge subclass = PCI-ISA cap 09[e0] = vendor (length 12) Intel cap 1 version 0 features: AMT, 4 PCI-e x1 slots ahci0@pci0:0:31:2: class=0x010601 card=0x21da17aa chip=0x1c038086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller' class = mass storage subclass = SATA cap 05[80] = MSI supports 1 message enabled with 1 message cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 12[a8] = SATA Index-Data Pair cap 13[b0] = PCI Advanced Features: FLR TP none1@pci0:0:31:3: class=0x0c0500 card=0x21da17aa chip=0x1c228086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '6 Series/C200 Series Chipset Family SMBus Controller' class = serial bus subclass = SMBus iwn0@pci0:3:0:0: class=0x028000 card=0x13118086 chip=0x00858086 rev=0x34 hdr=0x00 vendor = 'Intel Corporation' device = 'Centrino Advanced-N 6205 [Taylor Peak]' class = network cap 01[c8] = powerspec 3 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(128) FLR link x1(x1) speed 2.5(2.5) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[140] = Serial 1 100ba9ffffa36ef0 sdhci_pci0@pci0:13:0:0: class=0x088001 card=0x21da17aa chip=0xe8231180 rev=0x04 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'PCIe SDXC/MMC Host Controller' class = base peripheral cap 05[50] = MSI supports 1 message, 64 bit cap 01[78] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 10[80] = PCI-Express 1 endpoint max data 128(128) link x1(x1) speed 2.5(2.5) ecap 0002[100] = VC 1 max VC0 ecap 0001[800] = AER 1 0 fatal 0 non-fatal 4 corrected xhci0@pci0:14:0:0: class=0x0c0330 card=0x21da17aa chip=0x01941033 rev=0x04 hdr=0x00 vendor = 'NEC Corporation' device = 'uPD720200 USB 3.0 Host Controller' class = serial bus subclass = USB cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[70] = MSI supports 8 messages, 64 bit cap 11[90] = MSI-X supports 8 messages in map 0x10 cap 10[a0] = PCI-Express 2 endpoint max data 128(128) link x1(x1) speed 5.0(5.0) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[140] = Serial 1 ffffffffffffffff ecap 0018[150] = LTR 1 From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 02:46:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1F0AF215 for ; Thu, 28 Feb 2013 02:46:22 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id B42EF32B for ; Thu, 28 Feb 2013 02:46:21 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id 16so267451obc.33 for ; Wed, 27 Feb 2013 18:46:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=plJy0uWXIsnKGagI6U55eIsY46jn8qfamIfKDF4F9Ko=; b=FMJASiSY3zv0bz8ZXdpWLxC1SyVa3e5wghegeCIH1MiGseWASqlEO27rsEnl8KeFMv RHjDwnEck8g6solEqgxJ/v46y0RcUCVjvLDcKTNTIGonvAxyS9wZB97ybj0uItxJylx4 dLJlZ62aKwfZTHYZp16UW1917dfrTTU8Ik/QRlJo1NjH8cd4OVKlIa7Hl40sQnvptHhB CzwcEWoraLwuCyzsy9w53LN9u0dsUGAyOliL2w210Q5Tu8j2V7lpV4k5m1KJkfJNRx3l 4/2WVtuasAJs+ptDg1bhMr+OSI/ZRp+s6wJ1Fh5pKnlxEup5aVigRcWgopK3s+W+nUvL /rNg== MIME-Version: 1.0 X-Received: by 10.60.19.3 with SMTP id a3mr4404622oee.11.1362019581076; Wed, 27 Feb 2013 18:46:21 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.76.34.197 with HTTP; Wed, 27 Feb 2013 18:46:20 -0800 (PST) In-Reply-To: <512E64CA.6030408@daemonic.se> References: <512DE205.4010202@digsys.bg> <512E4D3F.6050900@gmail.com> <512E64CA.6030408@daemonic.se> Date: Wed, 27 Feb 2013 18:46:20 -0800 X-Google-Sender-Auth: EJEP5PvIYfv3KeuwWDzcxTGZHpc Message-ID: Subject: Re: Response of *.freebsd.org websites are very slow From: Kevin Oberman To: Niclas Zeising Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: matt , Daniel Kalchev , Daniel Nebdal , Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 02:46:22 -0000 On Wed, Feb 27, 2013 at 11:55 AM, Niclas Zeising wrote: > On 2013-02-27 20:25, Mehmet Erol Sanliturk wrote: > > I have installed snapshot > > > > FreeBSD-9.1-STABLE-amd64-20130223-r247167-release.iso > > > > # traceroute ftp.freebsd.org > > > > 3 failures : traceroute : unknown host ftp.freebsd.org > > 2 successes : > > > > Route is Izmir ( Turkey ) -> Frankfurt -> New York -> San Jose -> > > freebsd.isc.org ( 204.152.184.73 ) > > > > and pkg_add is not able to find package site . > > > > Perhaps for many tries it may find in some of the tries , but this will > not > > be a feasible way . > > Does Turkey (or your ISP) have any sort of great firewall or other > restrictions on network traffic? Do you have a firewall somewhere? > I have no trouble reaching www.freebsd.org and ftp.freebsd.org from 3 > different ASes using both IPv4 and IPv6. > Regards! > Just in case it is relevant ot someone else, www.freebsd.com is currently unreachable via IPv6 from Level(3). While the address is announced by Yahoo!, it is from an address block belonging to Level(3) but is being announced by Yahoo!. This works fine as long as you are NOT using Level(3). IPv4 is not involved. NOTE: This may be a problem caused by n error on the part of Level(3), Yahoo!, or FreeBSD. Without knowing details of how FreeBSD got the address and what arrangements Yahoo! made for announcing it to peers, there is no way to tell for sure. I can only say that ARIN shows no assignment from L3 to Yahoo or FreeBSD and the same situation is present for another /48 in the same L3 /32. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 04:51:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E32059B3 for ; Thu, 28 Feb 2013 04:51:20 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9F51D9CD for ; Thu, 28 Feb 2013 04:51:20 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fl17so920520vcb.41 for ; Wed, 27 Feb 2013 20:51:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GDD/6K+wTsziJ/qxf9TmmONQuhp5tW/CtB07qGlytt4=; b=qWXLMxAGXfze6WfJo6Xt/nJreffa7rYh+LJ4MeRtR/kRrsO2UQVJRQe5nGSD4gR7/p aZbSlW3kFHotN0slr04ZiFMKKpt2qvI1RBMrZD4/aw5HktVB2asRGxxqGkQ9Okrliyjp Y0e0mE10WwnxOv1e/4732eGvkJd2RXwMXgxcc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=GDD/6K+wTsziJ/qxf9TmmONQuhp5tW/CtB07qGlytt4=; b=YDdwUrfbKuXyZ6Qji4FKnkSCd8IYa2HIx4WAdjVF8r9G7l5LDpsGxPDlHxE4oPyXrC Vz0VxVj6cvOw6j9/wskAvFsyO/Pev2cBTskaCUMJaFPAdjhwOgfFiKXmU8LB0hGdRfni brDVtEI27Jy2sNXp8gk1e+VVmcwlVzmgMPJlz67lmUg8lWZsV+0aowpqi0rG16wbRYrW xAN7r1irZCe2d5WNPKNupb7sZIRkk1UdJUpdwzm0F5dr5WNn7icG28oztkFRNJA+UwHO bxskwZn/J3x7D4pnSUtb7pi8a2EVYCoy3uC93erDMLMm7SNmNGj6CtxtAsANymjUSazK EfHg== MIME-Version: 1.0 X-Received: by 10.220.116.5 with SMTP id k5mr1949592vcq.55.1362027073819; Wed, 27 Feb 2013 20:51:13 -0800 (PST) Received: by 10.220.163.198 with HTTP; Wed, 27 Feb 2013 20:51:13 -0800 (PST) In-Reply-To: References: <512DE205.4010202@digsys.bg> <512E4D3F.6050900@gmail.com> <512E64CA.6030408@daemonic.se> Date: Wed, 27 Feb 2013 20:51:13 -0800 Message-ID: Subject: Re: Response of *.freebsd.org websites are very slow From: Peter Wemm To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk+RQnHDXMFXby6nsTai/u6k6YxZfp+v5hOGe3BFgHaL6TWkZjvJGaxI2Kxcm66chlJ+tK9 Cc: Niclas Zeising , matt , Current , Daniel Nebdal , Daniel Kalchev X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 04:51:21 -0000 On Wed, Feb 27, 2013 at 6:46 PM, Kevin Oberman wrote: > On Wed, Feb 27, 2013 at 11:55 AM, Niclas Zeising wrote: > >> On 2013-02-27 20:25, Mehmet Erol Sanliturk wrote: >> > I have installed snapshot >> > >> > FreeBSD-9.1-STABLE-amd64-20130223-r247167-release.iso >> > >> > # traceroute ftp.freebsd.org >> > >> > 3 failures : traceroute : unknown host ftp.freebsd.org >> > 2 successes : >> > >> > Route is Izmir ( Turkey ) -> Frankfurt -> New York -> San Jose -> >> > freebsd.isc.org ( 204.152.184.73 ) >> > >> > and pkg_add is not able to find package site . >> > >> > Perhaps for many tries it may find in some of the tries , but this will >> not >> > be a feasible way . >> >> Does Turkey (or your ISP) have any sort of great firewall or other >> restrictions on network traffic? Do you have a firewall somewhere? >> I have no trouble reaching www.freebsd.org and ftp.freebsd.org from 3 >> different ASes using both IPv4 and IPv6. >> Regards! >> > > Just in case it is relevant ot someone else, www.freebsd.com is currently > unreachable via IPv6 from Level(3). While the address is announced by > Yahoo!, it is from an address block belonging to Level(3) but is being > announced by Yahoo!. This works fine as long as you are NOT using Level(3). > IPv4 is not involved. > > NOTE: This may be a problem caused by n error on the part of Level(3), > Yahoo!, or FreeBSD. Without knowing details of how FreeBSD got the address > and what arrangements Yahoo! made for announcing it to peers, there is no > way to tell for sure. I can only say that ARIN shows no assignment from L3 > to Yahoo or FreeBSD and the same situation is present for another /48 in > the same L3 /32. I will ask about this tomorrow. There is supposed to be L3->Yahoo->FreeBSD ipv6 connectivity. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 05:15:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C6D2D3E5; Thu, 28 Feb 2013 05:15:57 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 63DE9ABD; Thu, 28 Feb 2013 05:15:57 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rr4so839152pbb.41 for ; Wed, 27 Feb 2013 21:15:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vcHuXRbQzGqGK8WDMgXub26s45yCbS+b6a1SmNNamD8=; b=XVe1qAQvhuaIfpxcgGymfCZu4oUT9r/cJop6TK3UkpGgyBfHZGEmBSuNQunnt2SLme up52l26YPt53+cDqXTRopEZZXrO5dNvbFh1FKjZI1wBq91PTB/t+7Llrki4oBUVyEIXD zKbgDVn5+8ow8pF8P61ewt+xsx5zq3nLZGRsfqUyzyw4SM1g8lVhTT2Owjc/jhVOhnmJ bGVQTvyiEoOEdRorA5Iv67fQ7hZCawGMRCjdIcXYThbtEtBJiP/qEVm8YhOBKyr9qHCg FXraDhjCd5UkQgnvMvtTmY8osqp494xXSMq1r5GU43+pBktR1wQf0muhBs4P8ZkcVuqY lePg== X-Received: by 10.66.88.164 with SMTP id bh4mr11397218pab.41.1362028551377; Wed, 27 Feb 2013 21:15:51 -0800 (PST) Received: from ghost.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id bi8sm7849292pab.15.2013.02.27.21.15.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 21:15:50 -0800 (PST) Message-ID: <512F5882.7080004@gmail.com> Date: Thu, 28 Feb 2013 05:15:46 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130228 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Baldwin Subject: Re: Fixing X220 Video The Right Way References: <512A6FFF.2060603@gmail.com> <201302271200.22976.jhb@freebsd.org> <512E51FF.5010701@gmail.com> <201302271527.37079.jhb@freebsd.org> In-Reply-To: <201302271527.37079.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 05:15:57 -0000 On 02/27/13 12:27, John Baldwin wrote: > On Wednesday, February 27, 2013 1:35:43 pm matt wrote: >> On 02/27/13 09:00, John Baldwin wrote: >>> If that is true, it's because your BIOS is lying. Do you have a URL to >>> your ASL lying around already? >> Too big for pastebin :( +500k >> >> https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing > Here is where I find _DOD and _DOS methods: > > Device (PCI0) > Device (VID) > Name (_ADR, 0x00020000) // _ADR: Address > Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching > Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices > Device (PEG) > Name (_ADR, 0x00010000) // _ADR: Address > Device (VID) > Name (_ADR, 0x00) // _ADR: Address > Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching > Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices > > PCI0.VID is a PCI device at pci0:0:2:0. > PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0. > It would have a child device at 0:0 that would be PCI0.PEG.VID. Does the X220 > have a switchable GPU (e.g. it has built-in Intel graphics, but also has an > Nvidia GPU or some such?). If so, I imagine that PCI0.VID is the Intel graphics > and PEG is the non-Intel. The output of 'pciconf -lcv' would be useful to determine > that. If both PCI devices exist you shoudl have both acpi_video0 and acpi_video1. > However, it may be that the acpi_video driver doesn't cope well with having multiple > devices. Only Intel graphics, there is no option for switchable graphics. I initially thought that PEG was for Optimus usage, and left in the bios by accident (i.e. Lenovo using a generic DSDT for many machines) Here is pciconf -lcf, truncated hostb0@pci0:0:0:0: class=0x060000 card=0x21da17aa chip=0x01048086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family DRAM Controller' class = bridge subclass = HOST-PCI cap 09[e0] = vendor (length 12) Intel cap 0 version 1 vgapci0@pci0:0:2:0: class=0x030000 card=0x21da17aa chip=0x01268086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family Integrated Graphics Controller' class = display subclass = VGA cap 05[90] = MSI supports 1 message enabled with 1 message cap 01[d0] = powerspec 2 supports D0 D3 current D0 cap 13[a4] = PCI Advanced Features: FLR TP none0@pci0:0:22:0: class=0x078000 card=0x21da17aa chip=0x1c3a8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' As you can see there is no device at pci0:0:1:0. So no dev_t with for acpi_video to probe or attach to. Nonetheless, only PEGs ACPI methods work, which is quite broken. This is true for a large number of Lenovo devices, back to x61 (non-attaching AGP adr) and probably including some other x series and t series. Unfortunately the ASL will not compile which makes fixing the DSDT an exercise in fixing broken ACPI. What I find interesting is that as far as I can tell, there's no special case handling for this device in Linux, yet backlight controls work out of the box since about 3.0. Installing Linux as the OSI via loader.conf is not the issue, unfortunately, nor Windows 2006 (/WVIS) or Windows 2009 (/WIN7). I get correct (for platform) behavior when I call PEGs _BCM... :( Is Linux getting this to work by doing it wrong, essentially? Matt From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 08:06:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E9B976C2; Thu, 28 Feb 2013 08:06:46 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id B22961111; Thu, 28 Feb 2013 08:06:46 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9421:367:9d7d:512b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id BCF1B4AC57; Thu, 28 Feb 2013 12:06:35 +0400 (MSK) Date: Thu, 28 Feb 2013 12:06:30 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1796551389.20130228120630@serebryakov.spb.ru> To: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS! MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 08:06:47 -0000 Hello, Freebsd-fs. My server runs 9.1-STABLE and have 8Tb UFS2 SU+J FS. It crashed a several minutes ago (I don't know reason yet) and fsck says "Unexpected SU+J inconsistency" (Inode mode/directory tyme mismatch) and requested full check (which will take more than hour on such FS). All drives are perfectly healthy according to SMART, it is SATA WD20EARS/EARX mix. In my experience, SU/SU+J fsck never completes successful on this FS :( Does SU+J work at all? Here was topic in closed mailing list about it, started as topic about using CURRENT on FreeBSD's cluster, but it was shifted to ZFS discussion without changing "Subject" line after several iterations without any conclusion. Could I do something to help debug this problem? Please, don't give advices like "Convert to ZFS". ZFS is great, but, I think, we should have robust "native" and simple FS too. -- // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 08:33:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 45C925F6; Thu, 28 Feb 2013 08:33:32 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 06A9912C2; Thu, 28 Feb 2013 08:33:31 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9421:367:9d7d:512b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id C90034AC57; Thu, 28 Feb 2013 12:33:30 +0400 (MSK) Date: Thu, 28 Feb 2013 12:33:25 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1238720635.20130228123325@serebryakov.spb.ru> To: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS! In-Reply-To: <1796551389.20130228120630@serebryakov.spb.ru> References: <1796551389.20130228120630@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 08:33:32 -0000 Hello, Lev. You wrote 28 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 12:06= :30: LS> Hello, Freebsd-fs. LS> My server runs 9.1-STABLE and have 8Tb UFS2 SU+J FS. LS> It crashed a several minutes ago (I don't know reason yet) and fsck LS> says "Unexpected SU+J inconsistency" (Inode mode/directory tyme LS> mismatch) and requested full check (which will take more than hour on LS> such FS). Full fsck found "INTERNAL ERROR: DUPS WITH SOFTUPDATES" and keeps running.= .. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 09:07:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 29F7FF98; Thu, 28 Feb 2013 09:07:42 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-da0-f46.google.com (mail-da0-f46.google.com [209.85.210.46]) by mx1.freebsd.org (Postfix) with ESMTP id C90031611; Thu, 28 Feb 2013 09:07:41 +0000 (UTC) Received: by mail-da0-f46.google.com with SMTP id z8so763294dad.5 for ; Thu, 28 Feb 2013 01:07:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1aba5cCFpfKeW8SjF9cANZJnEbpLg/20UUidbpyvFEk=; b=GVlFmIuD4i9UcfhuRKz5vYOPfeBo/T/EtW5mddH1YZAlGgWdl8rfmxd88J6YJqooaz F5SZkGffUTE6zRdEV5+c4D0kB4H63QIBLHqnyW1ECsOcAF9xa4DDuGKZCiy2NVfSe7nv 1sCAL12O2O/NV1KPI3JwUYzlCeCqINLW8wNLl1FWjsmv8raKaChAWpN3rF6HooT0HJw7 PoMMCl1aSK0MNSTQXszA0ORvM4OqEizwj3p/iBpAtFvTgE0gFax4Spv6nTgLk4U5hfV1 uDSMKyOtW2MEdxukbjLBMjthqByDlT9T558yCyaFizNyrrpVaruLlbWxDZESwL8Fms0k bDsg== MIME-Version: 1.0 X-Received: by 10.68.134.3 with SMTP id pg3mr8171454pbb.51.1362042455545; Thu, 28 Feb 2013 01:07:35 -0800 (PST) Received: by 10.68.36.69 with HTTP; Thu, 28 Feb 2013 01:07:35 -0800 (PST) In-Reply-To: <1238720635.20130228123325@serebryakov.spb.ru> References: <1796551389.20130228120630@serebryakov.spb.ru> <1238720635.20130228123325@serebryakov.spb.ru> Date: Thu, 28 Feb 2013 11:07:35 +0200 Message-ID: Subject: Re: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS! From: Alexander Yerenkow To: lev@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 09:07:42 -0000 How about tell us 9.1-STABLE from which date you run? Do you use any dumps/snapshots in this FS? In past, that could broke things. -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 09:11:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 29071466; Thu, 28 Feb 2013 09:11:08 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id DEE65164F; Thu, 28 Feb 2013 09:11:07 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9421:367:9d7d:512b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 5B5614AC57; Thu, 28 Feb 2013 13:11:00 +0400 (MSK) Date: Thu, 28 Feb 2013 13:10:55 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <376897409.20130228131055@serebryakov.spb.ru> To: Alexander Yerenkow Subject: Re: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS! In-Reply-To: References: <1796551389.20130228120630@serebryakov.spb.ru> <1238720635.20130228123325@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 09:11:08 -0000 Hello, Alexander. You wrote 28 =F4=E5=E2=F0=E0=EB=FF 2013 =E3., 13:07:35: AY> How about tell us 9.1-STABLE from which date you run? r244957 AY> Do you use any dumps/snapshots in this FS? Nope.=20 --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 10:13:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 953552D8; Thu, 28 Feb 2013 10:13:31 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 3E6C4192F; Thu, 28 Feb 2013 10:13:30 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9421:367:9d7d:512b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 254904AC57; Thu, 28 Feb 2013 14:13:29 +0400 (MSK) Date: Thu, 28 Feb 2013 14:13:23 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1158712592.20130228141323@serebryakov.spb.ru> To: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS! In-Reply-To: <1238720635.20130228123325@serebryakov.spb.ru> References: <1796551389.20130228120630@serebryakov.spb.ru> <1238720635.20130228123325@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 10:13:31 -0000 Hello, Lev. You wrote 28 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 12:33= :25: LS>> My server runs 9.1-STABLE and have 8Tb UFS2 SU+J FS. LS>> It crashed a several minutes ago (I don't know reason yet) and fsck LS>> says "Unexpected SU+J inconsistency" (Inode mode/directory tyme LS>> mismatch) and requested full check (which will take more than hour on LS>> such FS). LS> Full fsck found "INTERNAL ERROR: DUPS WITH SOFTUPDATES" and keeps runn= ing... full fsck reconnected about 1000 files, which was written in time of crash. Really, sever crashed when SVN mirror seed was been unpacking on this FS, so there was massive file creation at this time. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 10:23:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 39F2B655; Thu, 28 Feb 2013 10:23:07 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by mx1.freebsd.org (Postfix) with ESMTP id CD1001999; Thu, 28 Feb 2013 10:23:06 +0000 (UTC) Received: by mail-ve0-f172.google.com with SMTP id cz11so1625961veb.17 for ; Thu, 28 Feb 2013 02:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=U1qrMep/B2zkWGFqSiR44X5W1nJtQfi9GHLLAWZEmeM=; b=rgD5KWyyblHVQlxiBqYY39KXGc7UwVdQwNvA8oXrP8miDJEstNaoy366mErGEpGnk8 kTF6KRZ/ixkwAKjWCNFvEZ9kFsf4YMTJFcxE0g9Kl//85PA/QuEeEYrAVmtahpU2mM72 3Lewu1McNDTGyb9L870rTbhbXoBCwLYz9sQAAZ6tMxGNyDwbc1CcNtIkNJ8/NNDWtond fvAxvKvdQaxZNoafZBBfIkcahPqoLS22CekkZpryrPw3xa3J188v2e08K9DxsMi4xXUN Tgi3tPav9Lu5b6KisdullGbF4lO0cSSYxLgilxtaYvj92QmY7ebW36fIIHvurU2dlf4h 7a1g== MIME-Version: 1.0 X-Received: by 10.52.96.163 with SMTP id dt3mr2042152vdb.11.1362046980062; Thu, 28 Feb 2013 02:23:00 -0800 (PST) Received: by 10.52.228.163 with HTTP; Thu, 28 Feb 2013 02:22:59 -0800 (PST) In-Reply-To: <1158712592.20130228141323@serebryakov.spb.ru> References: <1796551389.20130228120630@serebryakov.spb.ru> <1238720635.20130228123325@serebryakov.spb.ru> <1158712592.20130228141323@serebryakov.spb.ru> Date: Thu, 28 Feb 2013 12:22:59 +0200 Message-ID: Subject: Re: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS! From: Alexander Yerenkow To: lev@freebsd.org Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 10:23:07 -0000 2013/2/28 Lev Serebryakov > Hello, Lev. > You wrote 28 =C6=C5=D7=D2=C1=CC=D1 2013 =C7., 12:33:25: > > LS>> My server runs 9.1-STABLE and have 8Tb UFS2 SU+J FS. > LS>> It crashed a several minutes ago (I don't know reason yet) and fsck > LS>> says "Unexpected SU+J inconsistency" (Inode mode/directory tyme > LS>> mismatch) and requested full check (which will take more than hour o= n > LS>> such FS). > LS> Full fsck found "INTERNAL ERROR: DUPS WITH SOFTUPDATES" and keeps > running... > full fsck reconnected about 1000 files, which was written in time of > crash. > Really, sever crashed when SVN mirror seed was been unpacking on > this FS, so there was massive file creation at this time. > > Could you afford reproducing this? :) Also, would be nice to know how look your setup (CPUs, how much disks, how they connected, is it hw raid, etc). > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 10:31:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 925509C8; Thu, 28 Feb 2013 10:31:36 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 3782E1A07; Thu, 28 Feb 2013 10:31:36 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9421:367:9d7d:512b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id AF6BF4AC57; Thu, 28 Feb 2013 14:31:34 +0400 (MSK) Date: Thu, 28 Feb 2013 14:31:29 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <583012022.20130228143129@serebryakov.spb.ru> To: Alexander Yerenkow Subject: Re: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS! In-Reply-To: References: <1796551389.20130228120630@serebryakov.spb.ru> <1238720635.20130228123325@serebryakov.spb.ru> <1158712592.20130228141323@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 10:31:36 -0000 Hello, Alexander. You wrote 28 =C6=C5=D7=D2=C1=CC=D1 2013 =C7., 14:22:59: AY> Could you afford reproducing this? :) After half a day of memtest86+ :) I want to be sure, that it is not memory problem first. AY> Also, would be nice to know how look your setup (CPUs, how much disks, = how AY> they connected, is it hw raid, etc). Simple E4500 CPU on Q35-based desktop (ASUS) MoBo, 6GiB memory (under test now!), Samsung 500GiB SATA HDD for system, 5x2Tb WD Green (4xWD20EARS, 1xWD20EARX which replace failed WD20EARS), all disks are connected to 6 SATA ports of chipset (no RAID controller), WD disks are in software RAID5 with geom_raid5 (from ports, but I'm active maintainer of it). Disks are in "Default" configuration: WC and NCQ are enabled. I know, that FS guys could blame geom_raid5, as it could delay real write up to 15 seconds, but it never "lies" about writes (it doesn't mark BIOs complete till they are really sent to disk) and I could not reproduce any problems with it on many hours tests on VMs (and I don't want to experiment a lot on real hardware, as it contains my real data). Maybe, it is subtile interference between raid5 implementation and SU+J, but in such case I want to understand what does raid5 do wrong. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 11:44:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D176F129 for ; Thu, 28 Feb 2013 11:44:38 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id A52851CBC for ; Thu, 28 Feb 2013 11:44:38 +0000 (UTC) Received: from [10.0.10.1] ([173.88.202.176]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Feb 2013 03:44:33 -0800 Message-ID: <512F431E.7080507@a1poweruser.com> Date: Thu, 28 Feb 2013 06:44:30 -0500 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Peter Wemm Subject: Re: Response of *.freebsd.org websites are very slow References: <512DE205.4010202@digsys.bg> <512E4D3F.6050900@gmail.com> <512E64CA.6030408@daemonic.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2013 11:44:33.0749 (UTC) FILETIME=[FA3FB050:01CE15A8] X-Sender: fbsd8@a1poweruser.com X-Authenticated-Sender: fbsd8@a1poweruser.com X-EchoSenderHash: [fbsd8]-[a1poweruser*com] Cc: matt , Kevin Oberman , Current , Daniel Kalchev , Niclas Zeising , Daniel Nebdal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 11:44:38 -0000 Peter Wemm wrote: > On Wed, Feb 27, 2013 at 6:46 PM, Kevin Oberman wrote: >> On Wed, Feb 27, 2013 at 11:55 AM, Niclas Zeising wrote: >> >>> On 2013-02-27 20:25, Mehmet Erol Sanliturk wrote: >>>> I have installed snapshot >>>> >>>> FreeBSD-9.1-STABLE-amd64-20130223-r247167-release.iso >>>> >>>> # traceroute ftp.freebsd.org >>>> >>>> 3 failures : traceroute : unknown host ftp.freebsd.org >>>> 2 successes : >>>> >>>> Route is Izmir ( Turkey ) -> Frankfurt -> New York -> San Jose -> >>>> freebsd.isc.org ( 204.152.184.73 ) >>>> >>>> and pkg_add is not able to find package site . >>>> >>>> Perhaps for many tries it may find in some of the tries , but this will >>> not >>>> be a feasible way . >>> Does Turkey (or your ISP) have any sort of great firewall or other >>> restrictions on network traffic? Do you have a firewall somewhere? >>> I have no trouble reaching www.freebsd.org and ftp.freebsd.org from 3 >>> different ASes using both IPv4 and IPv6. >>> Regards! >>> >> Just in case it is relevant ot someone else, www.freebsd.com is currently >> unreachable via IPv6 from Level(3). While the address is announced by >> Yahoo!, it is from an address block belonging to Level(3) but is being >> announced by Yahoo!. This works fine as long as you are NOT using Level(3). >> IPv4 is not involved. >> >> NOTE: This may be a problem caused by n error on the part of Level(3), >> Yahoo!, or FreeBSD. Without knowing details of how FreeBSD got the address >> and what arrangements Yahoo! made for announcing it to peers, there is no >> way to tell for sure. I can only say that ARIN shows no assignment from L3 >> to Yahoo or FreeBSD and the same situation is present for another /48 in >> the same L3 /32. > > I will ask about this tomorrow. There is supposed to be > L3->Yahoo->FreeBSD ipv6 connectivity. > From cleveland ohio and www.freebsd.org is un-reachable again. It comes and gos. To me it's acting like someone high up is making dns changes. Some freebsd official better contact yahoo and put a stop to what ever there fooling around with. From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 12:48:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 80F7832A; Thu, 28 Feb 2013 12:48:36 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2AD4E214; Thu, 28 Feb 2013 12:48:36 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9421:367:9d7d:512b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id C3CFF4AC57; Thu, 28 Feb 2013 16:48:26 +0400 (MSK) Date: Thu, 28 Feb 2013 16:48:21 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1698593972.20130228164821@serebryakov.spb.ru> To: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Panic in ffs_valloc (Was: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS!) In-Reply-To: <1158712592.20130228141323@serebryakov.spb.ru> References: <1796551389.20130228120630@serebryakov.spb.ru> <1238720635.20130228123325@serebryakov.spb.ru> <1158712592.20130228141323@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 12:48:36 -0000 Hello, Lev. You wrote 28 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 14:13= :23: LS>>> My server runs 9.1-STABLE and have 8Tb UFS2 SU+J FS. LS>>> It crashed a several minutes ago (I don't know reason yet) and fsck LS>>> says "Unexpected SU+J inconsistency" (Inode mode/directory tyme LS>>> mismatch) and requested full check (which will take more than hour on LS>>> such FS). LS>> Full fsck found "INTERNAL ERROR: DUPS WITH SOFTUPDATES" and keeps run= ning... LS> full fsck reconnected about 1000 files, which was written in time of LS> crash. LS> Really, sever crashed when SVN mirror seed was been unpacking on LS> this FS, so there was massive file creation at this time. Ok, I've checked memory, and now I have booted system with crashlog (!) Here it is (please note, that panic() was called by ffs_valloc): #0 doadump (textdump=3D) at pcpu.h:229 229 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=3D) at pcpu.h:229 #1 0xffffffff80431494 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0xffffffff80431997 in panic (fmt=3D0x1
) at /usr/src/sys/kern/kern_shutdown.c:636 #3 0xffffffff80573d8c in ffs_valloc (pvp=3D0xfffffe0024d68000, mode=3D3320= 4, cred=3D0xfffffe0023d52700, vpp=3D0xffffff81c35586b8) at /usr/src/sys/ufs/ffs/ffs_alloc.c:995 #4 0xffffffff805aa126 in ufs_makeinode (mode=3D33204, dvp=3D0xfffffe0024d6= 8000, vpp=3D0xffffff81c3558a10, cnp=3D0xffffff81c3558a38) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2614 #5 0xffffffff80634391 in VOP_CREATE_APV (vop=3D, a=3D0xffffff81c3558920) at vnode_if.c:252 #6 0xffffffff804d389a in vn_open_cred (ndp=3D0xffffff81c35589d0, flagp=3D0xffffff81c35589cc, cmode=3D, vn_open_flags=3D, cred=3D0xfffffe0023d52700, fp=3D0xfffffe00ae9cf370) at vnode_if.h:109 #7 0xffffffff804cc0d9 in kern_openat (td=3D0xfffffe012d095000, fd=3D-100, path=3D0x801c951e0
, pathseg=3DUIO_USERSPACE, flags=3D2562, mode=3D) at /usr/src/sys/kern/vfs_syscalls.c:1132 #8 0xffffffff805f1400 in amd64_syscall (td=3D0xfffffe012d095000, traced=3D= 0) at subr_syscall.c:135 #9 0xffffffff805dbfc7 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #10 0x000000080177ce5c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Full textdump: http://lev.serebryakov.spb.ru/crashes/core-ffs-crash.txt.1 Please note, that FS was loaded by torrent client (40Mbit/s outbound traffic) and unpacking of svnmirror-base-r238500.tar.xz from this FS to itself. So, it was really high multistream load. I'll try to reproduce this on SINGLE disk, without geom_radi5 :) --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 13:35:49 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D067A898; Thu, 28 Feb 2013 13:35:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A73F63FA; Thu, 28 Feb 2013 13:35:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1SDZheF072522; Thu, 28 Feb 2013 08:35:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1SDZhX8072521; Thu, 28 Feb 2013 13:35:43 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 28 Feb 2013 13:35:43 GMT Message-Id: <201302281335.r1SDZhX8072521@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 13:35:49 -0000 TB --- 2013-02-28 13:09:36 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-28 13:09:37 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-28 13:09:37 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-02-28 13:09:37 - cleaning the object tree TB --- 2013-02-28 13:09:37 - /usr/local/bin/svn stat /src TB --- 2013-02-28 13:09:46 - At svn revision 247447 TB --- 2013-02-28 13:09:47 - building world TB --- 2013-02-28 13:09:47 - CROSS_BUILD_TESTING=YES TB --- 2013-02-28 13:09:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-28 13:09:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-28 13:09:47 - SRCCONF=/dev/null TB --- 2013-02-28 13:09:47 - TARGET=sparc64 TB --- 2013-02-28 13:09:47 - TARGET_ARCH=sparc64 TB --- 2013-02-28 13:09:47 - TZ=UTC TB --- 2013-02-28 13:09:47 - __MAKE_CONF=/dev/null TB --- 2013-02-28 13:09:47 - cd /src TB --- 2013-02-28 13:09:47 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 28 13:09:52 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] c++ -O2 -pipe -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/src/gnu/lib/libstdc++ -I/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/src/gnu/lib/libstdc++/../../../contrib/gcc -I/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I/src/gnu/lib/libstdc++/../../../contrib/gcclibs/include -I/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I. -frandom-seed=RepeatabilityConsideredGood -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -Wno-deprecated -c /src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/streambuf-inst.cc -o streambuf-inst.o c++ -O2 -pipe -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/src/gnu/lib/libstdc++ -I/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/src/gnu/lib/libstdc++/../../../contrib/gcc -I/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I/src/gnu/lib/libstdc++/../../../contrib/gcclibs/include -I/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I. -frandom-seed=RepeatabilityConsideredGood -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -Wno-deprecated -c /src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/streambuf.cc -o streambuf.o c++ -O2 -pipe -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/src/gnu/lib/libstdc++ -I/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/src/gnu/lib/libstdc++/../../../contrib/gcc -I/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I/src/gnu/lib/libstdc++/../../../contrib/gcclibs/include -I/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I. -frandom-seed=RepeatabilityConsideredGood -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -Wno-deprecated -c /src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/string-inst.cc -o string-inst.o /src/gnu/lib/libstdc++/../../../contrib/libstdc++/include/bits/basic_string.tcc: In member function 'std::basic_string<_CharT, _Traits, _Alloc>& std::basic_string<_CharT, _Traits, _Alloc>::replace(typename _Alloc::rebind<_CharT>::other::size_type, typename _Alloc::rebind<_CharT>::other::size_type, const _CharT*, typename _Alloc::rebind<_CharT>::other::size_type) [with _CharT = char, _Traits = std::char_traits, _Alloc = std::allocator]': /src/gnu/lib/libstdc++/../../../contrib/libstdc++/include/bits/basic_string.tcc:397: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** [string-inst.o] Error code 1 Stop in /src/gnu/lib/libstdc++. *** [all] Error code 1 Stop in /src/gnu/lib. *** [gnu/lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-28 13:35:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-28 13:35:43 - ERROR: failed to build world TB --- 2013-02-28 13:35:43 - 1190.68 user 211.16 system 1566.06 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 14:19:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B7458499 for ; Thu, 28 Feb 2013 14:19:59 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 71CAF804 for ; Thu, 28 Feb 2013 14:19:58 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UB4LF-0004DE-8J for freebsd-current@freebsd.org; Thu, 28 Feb 2013 15:20:13 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Feb 2013 15:20:13 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Feb 2013 15:20:13 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Subject: Re: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS! Date: Thu, 28 Feb 2013 15:19:38 +0100 Lines: 44 Message-ID: References: <1796551389.20130228120630@serebryakov.spb.ru> <1238720635.20130228123325@serebryakov.spb.ru> <1158712592.20130228141323@serebryakov.spb.ru> <583012022.20130228143129@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig98A32AB29871B72452708C01" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120812 Thunderbird/14.0 In-Reply-To: <583012022.20130228143129@serebryakov.spb.ru> X-Enigmail-Version: 1.4.3 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 14:19:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig98A32AB29871B72452708C01 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 28/02/2013 11:31, Lev Serebryakov wrote: > WD disks are in software RAID5 with geom_raid5 (from ports, but I'm > active maintainer of it). > Disks are in "Default" configuration: WC and NCQ are enabled. > > I know, that FS guys could blame geom_raid5, as it could delay real > write up to 15 seconds, but it never "lies" about writes (it doesn't > mark BIOs complete till they are really sent to disk) and I could > not reproduce any problems with it on many hours tests on VMs (and I > don't want to experiment a lot on real hardware, as it contains my > real data). >=20 > Maybe, it is subtile interference between raid5 implementation and > SU+J, but in such case I want to understand what does raid5 do > wrong. You guessed correctly, I was going to blame geom_raid5 :) Is this a production setup you have? Can you afford to destroy it and re-create it for the purpose of testing, this time with geom_raid3 (which should be synchronous with respect to writes)? --------------enig98A32AB29871B72452708C01 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEvZ3oACgkQ/QjVBj3/HSyFKACfV8HYl5TsfYf2Zx48xxQnClEX 4rsAnRd5VSb35co21+ol3qCfTk9TpMbW =KjTe -----END PGP SIGNATURE----- --------------enig98A32AB29871B72452708C01-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 14:57:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 74FFFB0E; Thu, 28 Feb 2013 14:57:02 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1ABF19A1; Thu, 28 Feb 2013 14:57:02 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9421:367:9d7d:512b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 858794AC57; Thu, 28 Feb 2013 18:56:53 +0400 (MSK) Date: Thu, 28 Feb 2013 18:56:47 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1502041051.20130228185647@serebryakov.spb.ru> To: Ivan Voras Subject: Re: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS! In-Reply-To: References: <1796551389.20130228120630@serebryakov.spb.ru> <1238720635.20130228123325@serebryakov.spb.ru> <1158712592.20130228141323@serebryakov.spb.ru> <583012022.20130228143129@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 14:57:02 -0000 Hello, Ivan. You wrote 28 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 18:19= :38: >> Maybe, it is subtile interference between raid5 implementation and >> SU+J, but in such case I want to understand what does raid5 do >> wrong. IV> You guessed correctly, I was going to blame geom_raid5 :) It is not first time :( But every time such discussion ends without any practical results. One time, Kirk say, that delayed writes are Ok for SU until bottom layer doesn't lie about operation completeness. geom_raid5 could delay writes (in hope that next writes will combine nicely and allow not to do read-calculate-write cycle for read alone), but it never mark BIO complete until it is really completed (layers down to geom_raid5 returns completion). So, every BIO in wait queue is "in flight" from GEOM/VFS point of view. Maybe, it is fatal for journal :( And want I really want to see is "SYNC" flag for BIO and that all journal-related writes will be marked with it. Also all commits originated with fsync() MUST be marked in same way, really. Alexander Motin (ahci driver author) assured me, that he'll add support for such flag in driver to flush drive cache too, if it will be introduced. IMHO, lack of this (or similar) flag is bad idea even without geom_raid5 with its optimistic behavior. There was commit r246876, but I don't understand exactly what it means, as no real FS or driver's code was touched. But I'm writing about this idea for 3rd or 4th time without any results :( And I don't mean, that it should be implemented ASAP by someone, I mean I didn't see any support from FS guys (Kirk and somebody else, I don't remember exactly participants of these old thread, but he was not you) like "go ahead and send your patch". All these threads was very defensive from FS guru side, like "we don't need it, fix hardware, disable caches". IV> Is this a production setup you have? Can you afford to destroy it and IV> re-create it for the purpose of testing, this time with geom_raid3 IV> (which should be synchronous with respect to writes)? Unfortunately, it is production setup and I don't have any spare hardware for second one :( I've posted panic stacktrace -- and it is FFS-related too -- and now preparing setup with only one HDD and same high load to try reproduce it without geom_raid5. But I don't have enough hardware (3 spare HDDs at least!) to reproduce it with geom_raid3 or other copy of geiom_radi5. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 15:00:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A5BAFCFA; Thu, 28 Feb 2013 15:00:57 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 67FD79EA; Thu, 28 Feb 2013 15:00:57 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9421:367:9d7d:512b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 06C084AC58; Thu, 28 Feb 2013 19:00:54 +0400 (MSK) Date: Thu, 28 Feb 2013 19:00:49 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1843530475.20130228190049@serebryakov.spb.ru> To: Ivan Voras Subject: Re: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS! In-Reply-To: <1502041051.20130228185647@serebryakov.spb.ru> References: <1796551389.20130228120630@serebryakov.spb.ru> <1238720635.20130228123325@serebryakov.spb.ru> <1158712592.20130228141323@serebryakov.spb.ru> <583012022.20130228143129@serebryakov.spb.ru> <1502041051.20130228185647@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 15:00:57 -0000 Hello, Ivan. You wrote 28 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 18:56= :47: LS> There was commit r246876, but I don't understand exactly what it LS> means, as no real FS or driver's code was touched. And, yes, barriers are much stronger than "sync writes", as they should flush all previous writes, even that is not related to journal or metadata and could wait more (simple file data could be fixed on plates out of order without destroying filesystem structure). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 15:43:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E47E5F87 for ; Thu, 28 Feb 2013 15:43:33 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by mx1.freebsd.org (Postfix) with ESMTP id 9F45CCF7 for ; Thu, 28 Feb 2013 15:43:33 +0000 (UTC) Received: by mail-ve0-f171.google.com with SMTP id b10so1932803vea.2 for ; Thu, 28 Feb 2013 07:43:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ihYs8wjQryEGtTW7Y1+9Tz6Gk1ByOe5oef9CKyfnbfw=; b=LxPPIn/bSvEenPlkbH5Q+CIJBh3UTItw2d02iN5uF4EJ2goauK08CquGQ1zfSLOndh uNdcwttWSK5ubLBtbsXIUBFoKovOTyog1qqCA+sWyoH29UUIz7Ny+hcHGvdBMPsUIuaZ GZ3Xc5niMwcxVjWlXnFdOdii0/Bzp/j+3K9TM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=ihYs8wjQryEGtTW7Y1+9Tz6Gk1ByOe5oef9CKyfnbfw=; b=hNg7EUufpc2Vt7sGJhHKNX5ac5YV89voPXbseKL6PPpGXbKrYEYtHqGte35+b3xk9I 5YRZ03Fu7my82WOsYRMGDAPeRlAKQg/iBfXsc4B7IA3vfs550lLV8M3Cm2adnuTKJ2DV k6jv8yaU2lEgYok9Bf3hl05zkcf2IBgT+6om7Ms04REDGckuY/bl14v+hwQVMd2ynm0o VCTbnBZIcbBSOQ3fUspSCmNH7NlxBzXZ3iL/2jpxiM/waVkp7h8HNa6+qE/2oI7k1e/8 McaAT2EDyspLzLUMucrZLu+C9mi3H0nzwWm2NrixKuVSgFbOKbWtTI2Lnu8K3ZYPUHw2 gOhw== MIME-Version: 1.0 X-Received: by 10.52.24.205 with SMTP id w13mr2352074vdf.61.1362066207366; Thu, 28 Feb 2013 07:43:27 -0800 (PST) Received: by 10.221.11.72 with HTTP; Thu, 28 Feb 2013 07:43:27 -0800 (PST) In-Reply-To: <512F431E.7080507@a1poweruser.com> References: <512DE205.4010202@digsys.bg> <512E4D3F.6050900@gmail.com> <512E64CA.6030408@daemonic.se> <512F431E.7080507@a1poweruser.com> Date: Thu, 28 Feb 2013 07:43:27 -0800 Message-ID: Subject: Re: Response of *.freebsd.org websites are very slow From: Peter Wemm To: Fbsd8 Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlXfraixJIMTYMG83HPiCx8YDUoHA4zRGGOYAQgI7upRDbLJCTz6Q9LegdrjVdpN4rZeEgl Cc: matt , Kevin Oberman , Current , Daniel Kalchev , Niclas Zeising , Daniel Nebdal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 15:43:34 -0000 On Thu, Feb 28, 2013 at 3:44 AM, Fbsd8 wrote: [..] > > From cleveland ohio and www.freebsd.org is un-reachable again. It comes and > gos. To me it's acting like someone high up is making dns changes. > Some freebsd official better contact yahoo and put a stop to what ever there > fooling around with. Nope. It isn't DNS, but there is a routing issue for ipv6 space between Level-3 and and Yahoo. I'm working on it. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 17:09:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BA1C1C12; Thu, 28 Feb 2013 17:09:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7EBAA280; Thu, 28 Feb 2013 17:09:56 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B1B93B94F; Thu, 28 Feb 2013 12:09:55 -0500 (EST) From: John Baldwin To: matt Subject: Re: Fixing X220 Video The Right Way Date: Thu, 28 Feb 2013 12:09:44 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <512A6FFF.2060603@gmail.com> <201302271527.37079.jhb@freebsd.org> <512F5882.7080004@gmail.com> In-Reply-To: <512F5882.7080004@gmail.com> MIME-Version: 1.0 Message-Id: <201302281209.45170.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 28 Feb 2013 12:09:55 -0500 (EST) Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 17:09:56 -0000 On Thursday, February 28, 2013 8:15:46 am matt wrote: > On 02/27/13 12:27, John Baldwin wrote: > > On Wednesday, February 27, 2013 1:35:43 pm matt wrote: > >> On 02/27/13 09:00, John Baldwin wrote: > >>> If that is true, it's because your BIOS is lying. Do you have a URL to > >>> your ASL lying around already? > >> Too big for pastebin :( +500k > >> > >> https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing > > Here is where I find _DOD and _DOS methods: > > > > Device (PCI0) > > Device (VID) > > Name (_ADR, 0x00020000) // _ADR: Address > > Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching > > Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices > > Device (PEG) > > Name (_ADR, 0x00010000) // _ADR: Address > > Device (VID) > > Name (_ADR, 0x00) // _ADR: Address > > Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching > > Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices > > > > PCI0.VID is a PCI device at pci0:0:2:0. > > PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0. > > It would have a child device at 0:0 that would be PCI0.PEG.VID. Does the X220 > > have a switchable GPU (e.g. it has built-in Intel graphics, but also has an > > Nvidia GPU or some such?). If so, I imagine that PCI0.VID is the Intel graphics > > and PEG is the non-Intel. The output of 'pciconf -lcv' would be useful to determine > > that. If both PCI devices exist you shoudl have both acpi_video0 and acpi_video1. > > However, it may be that the acpi_video driver doesn't cope well with having multiple > > devices. > Only Intel graphics, there is no option for switchable graphics. > I initially thought that PEG was for Optimus usage, and left in the bios > by accident (i.e. Lenovo using a generic DSDT for many machines) > > Here is pciconf -lcf, truncated > hostb0@pci0:0:0:0: class=0x060000 card=0x21da17aa chip=0x01048086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '2nd Generation Core Processor Family DRAM Controller' > class = bridge > subclass = HOST-PCI > cap 09[e0] = vendor (length 12) Intel cap 0 version 1 > vgapci0@pci0:0:2:0: class=0x030000 card=0x21da17aa chip=0x01268086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '2nd Generation Core Processor Family Integrated > Graphics Controller' > class = display > subclass = VGA > cap 05[90] = MSI supports 1 message enabled with 1 message > cap 01[d0] = powerspec 2 supports D0 D3 current D0 > cap 13[a4] = PCI Advanced Features: FLR TP > none0@pci0:0:22:0: class=0x078000 card=0x21da17aa chip=0x1c3a8086 > rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > > As you can see there is no device at pci0:0:1:0. So no dev_t with for > acpi_video to probe or attach to. > > Nonetheless, only PEGs ACPI methods work, which is quite broken. This is > true for a large number of Lenovo devices, back to x61 (non-attaching > AGP adr) and probably including some other x series and t series. > > Unfortunately the ASL will not compile which makes fixing the DSDT an > exercise in fixing broken ACPI. > > What I find interesting is that as far as I can tell, there's no special > case handling for this device in Linux, yet backlight controls work out > of the box since about 3.0. Installing Linux as the OSI via loader.conf > is not the issue, unfortunately, nor Windows 2006 (/WVIS) or Windows > 2009 (/WIN7). I get correct (for platform) behavior when I call PEGs > _BCM... :( > > Is Linux getting this to work by doing it wrong, essentially? Yes. I think the best way to fix this is to add a way to specify a hint to override the ACPI path associated with a PCI device. Something like: hw.pci0.0.2.0.handle="\_SB_.PCI0.PEG.VID" I think this patch should do the trick: Index: sys/dev/acpica/acpi_pci.c =================================================================== --- acpi_pci.c (revision 247320) +++ acpi_pci.c (working copy) @@ -264,6 +264,40 @@ acpi_pci_save_handle(ACPI_HANDLE handle, UINT32 le return_ACPI_STATUS (AE_OK); } +static void +acpi_pci_override_handles(device_t dev) +{ + struct acpi_pci_devinfo *dinfo; + device_t *devlist; + int error, i, numdevs; + char tunable_name[64], *path; + ACPI_HANDLE handle; + + error = device_get_children(dev, &devlist, &numdevs); + if (error) + return; + for (i = 0; i < numdevs; i++) { + dinfo = device_get_ivars(devlist[i]); + snprintf(tunable_name, sizeof(tunable_name), + "hw.pci%d.%d.%d.%d.handle", dinfo->ap_dinfo.cfg.domain, + dinfo->ap_dinfo.cfg.bus, dinfo->ap_dinfo.cfg.slot, + dinfo->ap_dinfo.cfg.func); + path = getenv(tunable_name); + if (path == NULL) + continue; + if (ACPI_SUCCESS(AcpiGetHandle(NULL, path, &handle))) { + device_printf(dev, + "Forcing device at %d.%d to use path %s\n", + dinfo->ap_dinfo.cfg.slot, + dinfo->ap_dinfo.cfg.func, path); + dinfo->ap_handle = handle; + acpi_pci_update_device(handle, devlist[i]); + } + freeenv(path); + } + free(devlist, M_TEMP); +} + static int acpi_pci_probe(device_t dev) { @@ -306,5 +340,10 @@ acpi_pci_attach(device_t dev) AcpiWalkNamespace(ACPI_TYPE_DEVICE, acpi_get_handle(dev), 1, acpi_pci_save_handle, NULL, dev, NULL); + /* + * Perform another pass over child devices to allow their + * handles to be overridden via a hint from the user. + */ + acpi_pci_override_handles(dev); return (bus_generic_attach(dev)); } -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Mar 1 00:44:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3FDEBB6A for ; Fri, 1 Mar 2013 00:44:56 +0000 (UTC) (envelope-from cvaruneng04@gmail.com) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by mx1.freebsd.org (Postfix) with ESMTP id ADD9CB5E for ; Fri, 1 Mar 2013 00:44:55 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id m4so1858331lbo.14 for ; Thu, 28 Feb 2013 16:44:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=xc+kZ//RoHoVkETxzI8FNGYjuSNEbRGLAnwBpW2hJmY=; b=gxjwUaGEkfIn0JUSgTWgc8wYFuDRRW3GZvgSEJicm+xqDfHW/N0eFggNnW7uga+iy1 mh4n5gCNWaSFaUQarAZPFTXHPqD/EMVlHmN9MOhrADE3K+yDrsiKxzH920QIOOmD9fXR rpOsGAe0c/vqYYY0VAWzmPKaeUq5lgzyTlkAzw+FxqhRN1qGq9wsqIaW6yqgk8AnuruF inDU6drAdqrzMki+XN6iBvE6TlEKVrfmU1ttlc5zpq9iPPxmXpLxq0VtMY3/etL65N2r wblwGZqaj0AqKDgOA1cx3w8U0e6OmONMO5GMeZMRpHUlI6fWbHK+nXARhKQhik9lyLv0 Pjgw== MIME-Version: 1.0 X-Received: by 10.112.42.37 with SMTP id k5mr13796lbl.49.1362098688912; Thu, 28 Feb 2013 16:44:48 -0800 (PST) Received: by 10.112.76.167 with HTTP; Thu, 28 Feb 2013 16:44:48 -0800 (PST) Date: Fri, 1 Mar 2013 11:44:48 +1100 Message-ID: Subject: Divert socket issues. From: Varun Chandramohan To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 00:44:56 -0000 Hi All, I sent this email to net group, unfortunately I got no response. Iam sorry if that was the wrong group. Trying it again in this group. I wrote a small program using divert sockets to capture packets using ipfw at outgoing. The packets that are captured is for application mangling (mostly http headers) and resent it back to browser. That means I need to reinject it back in incoming instead of outgoing. I believe this is possible based on what is said in the man pages. Man page: if sendto(2) is used with a destination IP address of INADDR_ANY, then the packet is treated as if it were outgoing, i.e., destined for a non-local address. Otherwise, the packet is assumed to be incoming and full packet routing is done. In the latter case, the IP address specified must match the address of some local interface, or an interface name must be found after the IP address. If an interface name is found, that interface will be used and the value of the IP address will be ignored (other than the fact that it is not INADDR_ANY). This is to indicate on which interface the packet ``arrived.'' According to these instructions, I want my packet In-bound so I set my local ip address for the sendto data structure using the below code. ssize_t divert_get(int sd, struct sockaddr_in *sa, char *pkt_buf, int buflen){ ssize_t len; unsigned int addrlen; addrlen = sizeof(*sa); len = recvfrom(sd, pkt_buf, buflen, 0, (struct sockaddr *) sa, &addrlen); if(len == -1) { bps_log(LOG_ERR, "Unable to recieve message from socket", errno); } return(len);} /* addr is passed &sa from the above code */ rebuild_header(void *ptr, struct sockaddr_in *addr) { ssize_t new_len = change_header(ptr);struct ip *ip = (struct ip*)ptr; /* this is to divert it to input instead of output */ addr->sin_addr.s_addr = ip->ip_src.s_addr; /* Recompute checksums */ ip->ip_len = htons(new_len); cal_ip_cksum(ptr); cal_tcp_cksum(ptr); if(divert_send(sd, addr, ptr, pkt_len) < 0) { printf("No data sent from divert socket %d", errno); } } I expect the packet to now be inbound but my application is not getting the response sent by me. The possible case could be kernel dropping the packet. I even set the port number which is the rule I want to match for example, I have only two rules 1 and 65535. I tried setting port number to 0,1 and even 65535 but still the kernel drops the packet. addr->sin_port = htons(65535); sento seems to work fine but the packet does not go through. If I re-inject the packet back in the outgoing path (same place I took the packet) things seem to work fine. Can someone please tell me whats wrong here? I don't seem to understand. The man page is not very clear. I looked a bit into divert code and it seem to call ip_input() for the packet I re-injected. If thats the case, won't my packet get dropped because it has src address as my local address (it expects it to be other way around if server has responded)? Can someone please clarify this? If I have to still do it, do I need to modify TCP/IP header fields as well? Regards, Varun From owner-freebsd-current@FreeBSD.ORG Fri Mar 1 05:11:47 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A524AB8A; Fri, 1 Mar 2013 05:11:47 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 6F80D7FC; Fri, 1 Mar 2013 05:11:47 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id r215BWoU092532; Thu, 28 Feb 2013 21:11:36 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201303010511.r215BWoU092532@gw.catspoiler.org> Date: Thu, 28 Feb 2013 21:11:32 -0800 (PST) From: Don Lewis Subject: Re: Panic in ffs_valloc (Was: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS!) To: lev@FreeBSD.org In-Reply-To: <1698593972.20130228164821@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=iso-8859-5 Content-Transfer-Encoding: 8BIT Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 05:11:47 -0000 On 28 Feb, Lev Serebryakov wrote: > Hello, Lev. > You wrote 28 äŐŇŕĐŰď 2013 Ó., 14:13:23: > > LS>>> My server runs 9.1-STABLE and have 8Tb UFS2 SU+J FS. > LS>>> It crashed a several minutes ago (I don't know reason yet) and fsck > LS>>> says "Unexpected SU+J inconsistency" (Inode mode/directory tyme > LS>>> mismatch) and requested full check (which will take more than hour on > LS>>> such FS). > LS>> Full fsck found "INTERNAL ERROR: DUPS WITH SOFTUPDATES" and keeps running... > LS> full fsck reconnected about 1000 files, which was written in time of > LS> crash. > LS> Really, sever crashed when SVN mirror seed was been unpacking on > LS> this FS, so there was massive file creation at this time. > Ok, I've checked memory, and now I have booted system with crashlog > (!) > > Here it is (please note, that panic() was called by ffs_valloc): > > #0 doadump (textdump=) at pcpu.h:229 > 229 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=) at pcpu.h:229 > #1 0xffffffff80431494 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:448 > #2 0xffffffff80431997 in panic (fmt=0x1
) > at /usr/src/sys/kern/kern_shutdown.c:636 > #3 0xffffffff80573d8c in ffs_valloc (pvp=0xfffffe0024d68000, mode=33204, > cred=0xfffffe0023d52700, vpp=0xffffff81c35586b8) > at /usr/src/sys/ufs/ffs/ffs_alloc.c:995 > #4 0xffffffff805aa126 in ufs_makeinode (mode=33204, dvp=0xfffffe0024d68000, > vpp=0xffffff81c3558a10, cnp=0xffffff81c3558a38) > at /usr/src/sys/ufs/ufs/ufs_vnops.c:2614 > #5 0xffffffff80634391 in VOP_CREATE_APV (vop=, > a=0xffffff81c3558920) at vnode_if.c:252 > #6 0xffffffff804d389a in vn_open_cred (ndp=0xffffff81c35589d0, > flagp=0xffffff81c35589cc, cmode=, > vn_open_flags=, cred=0xfffffe0023d52700, > fp=0xfffffe00ae9cf370) at vnode_if.h:109 > #7 0xffffffff804cc0d9 in kern_openat (td=0xfffffe012d095000, fd=-100, > path=0x801c951e0
, > pathseg=UIO_USERSPACE, flags=2562, mode=) > at /usr/src/sys/kern/vfs_syscalls.c:1132 > #8 0xffffffff805f1400 in amd64_syscall (td=0xfffffe012d095000, traced=0) > at subr_syscall.c:135 > #9 0xffffffff805dbfc7 in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:387 > #10 0x000000080177ce5c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > Full textdump: http://lev.serebryakov.spb.ru/crashes/core-ffs-crash.txt.1 > > Please note, that FS was loaded by torrent client (40Mbit/s outbound > traffic) and unpacking of svnmirror-base-r238500.tar.xz from this FS > to itself. So, it was really high multistream load. > > I'll try to reproduce this on SINGLE disk, without geom_radi5 :) The fact that the filesystem code called panic() indicates that the filesystem was already corrupt by that point. That's a likely reason for fsck complaining about the unexpected SU+J inconsistency. Incorrect write ordering that allowed the filesystem to become inconsistent because some pending writes were lost because of the panic might not be necessary, but this might have allowed an earlier crash where a full fsck was skipped to leave the filesystem in this state. This panic might also be a result of the bug fixed in 246877, but I have my doubts about that. From owner-freebsd-current@FreeBSD.ORG Fri Mar 1 06:22:51 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7AACA312; Fri, 1 Mar 2013 06:22:51 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2501C9DE; Fri, 1 Mar 2013 06:22:51 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9421:367:9d7d:512b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id E0E064AC57; Fri, 1 Mar 2013 10:22:43 +0400 (MSK) Date: Fri, 1 Mar 2013 10:22:37 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <352538988.20130301102237@serebryakov.spb.ru> To: Don Lewis Subject: Re: Panic in ffs_valloc (Was: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS!) In-Reply-To: <201303010511.r215BWoU092532@gw.catspoiler.org> References: <1698593972.20130228164821@serebryakov.spb.ru> <201303010511.r215BWoU092532@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-5 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 06:22:51 -0000 Hello, Don. You wrote 1 =DC=D0=E0=E2=D0 2013 =D3., 9:11:32: DL> The fact that the filesystem code called panic() indicates that the DL> filesystem was already corrupt by that point. That's a likely reason DL> for fsck complaining about the unexpected SU+J inconsistency. DL> Incorrect write ordering that allowed the filesystem to become DL> inconsistent because some pending writes were lost because of the panic DL> might not be necessary, but this might have allowed an earlier crash DL> where a full fsck was skipped to leave the filesystem in this state. As far, as I understand, if this theory is right (file system corruption which left unnoticed by "standard" fsck), it is bug in FFS SU+J too, as it should not be corrupted by reordered writes (if writes is properly reported as completed even if they were reordered). DL> This panic might also be a result of the bug fixed in 246877, but I have DL> my doubts about that. It was not MFCed :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Fri Mar 1 09:45:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 00054A09 for ; Fri, 1 Mar 2013 09:45:08 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [176.9.45.25]) by mx1.freebsd.org (Postfix) with ESMTP id B7344295 for ; Fri, 1 Mar 2013 09:45:08 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id 7AB2A28205; Fri, 1 Mar 2013 10:45:06 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id 243-pwVSLZmt; Fri, 1 Mar 2013 10:45:04 +0100 (CET) Received: from [10.9.8.1] (chello085216226145.chello.sk [85.216.226.145]) by mail.vx.sk (Postfix) with ESMTPSA id B1C8E281F9; Fri, 1 Mar 2013 10:45:04 +0100 (CET) Message-ID: <513078A0.9020408@FreeBSD.org> Date: Fri, 01 Mar 2013 10:45:04 +0100 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Derrick Dantavious Edwards Subject: Re: ZFS problems References: <1953411.keAzGZcpTL@zeus> In-Reply-To: <1953411.keAzGZcpTL@zeus> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 09:45:09 -0000 Fixed in r247540. If you are using a post-247265 zfs module please install the new module first. On 27.2.2013 22:56, Derrick Dantavious Edwards wrote: > I updated sources a couple of days ago and when I rebooted to continue to > the upgrade process I received errors when I attempted to mount zfs > filesystem. The error looked like this. > > zpool mount -a > > internal error: Invalid arugment > pid 25 (zfs), uid 0, exited on signal 6 > Abort trap > > I get the same error if I just type zpool status -v, except the (zfs) is > replace with (zpool). The kernel module is loaded and visible by kldstat. > Any ideas? > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Martin Matuska FreeBSD committer http://blog.vx.sk From owner-freebsd-current@FreeBSD.ORG Fri Mar 1 13:20:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 513B263B; Fri, 1 Mar 2013 13:20:18 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id CA9CAD1F; Fri, 1 Mar 2013 13:20:17 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id v28so317670qcm.25 for ; Fri, 01 Mar 2013 05:20:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MtlF7AyjrtSFAqN0QgKNr3mJV9yAbLMsp9xWXVE9lDQ=; b=0iAwiQOA/bFGZAnKHUrk/NlIAoi1Gs8DqvpljMCUZYcHc1XOyM5Nf30uNhMkxt/rHv Q1n01deQlP7MD4DppPLijAWmYG5KumBXyYde1DOwtQIJYjrb9XRXI62yQDC5bSZt0R+1 8Dq+5GtQkICtGtrb2zfgxijFIXBLFtmxWjB8RAm0vZtQUlNZw665veQRqOmWdnd2RxBC VNlaJJxTgtJIE78r84OmJ0q+xd3EidR0nkt9HBAZNT3+cxD7qs+/8xMBMUWpj0K9uVIO 1Xpjz7yaCOotguMFlTFD1me0vxUIzdhMSKw2hwdsEpi781psDexZpWalcN5TkmYsD/Dn ixEg== MIME-Version: 1.0 X-Received: by 10.224.33.14 with SMTP id f14mr19597959qad.69.1362144016379; Fri, 01 Mar 2013 05:20:16 -0800 (PST) Received: by 10.49.121.198 with HTTP; Fri, 1 Mar 2013 05:20:16 -0800 (PST) In-Reply-To: <20130226123904.GO2454@kib.kiev.ua> References: <201302201022.29294.jhb@freebsd.org> <201302211043.49906.jhb@freebsd.org> <20130225190920.1b7d348d@bender> <20130225124747.GA21027@ci0.org> <20130226210651.580c46a7@bender> <20130226123904.GO2454@kib.kiev.ua> Date: Fri, 1 Mar 2013 14:20:16 +0100 Message-ID: Subject: Re: ARM pcpu changes, was Re: [patch] i386 pmap sysmaps_pcpu[] atomic access From: Svatopluk Kraus To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Olivier Houchard , Andrew Turner X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 13:20:18 -0000 On Tue, Feb 26, 2013 at 1:39 PM, Konstantin Belousov wrote: > On Tue, Feb 26, 2013 at 09:06:51PM +1300, Andrew Turner wrote: >> Does anyone know if it is only curthread that needs to be atomic? If so >> this should work. Reading the cpuid from the system currently is a >> single instruction, however it appears the code will need to be reworked >> for use with multiple levels of affinity, for example when there >> are clusters of cores the current code will number two cores on >> different clusters with the same id. >> >> I don't think we need to use ldrex/strex to read/write the values, my >> understanding is the rest should be safe to access without atomic >> functions. > > I read about ARM architecture some time ago. What I am saying below is not > a proposal, but rather a way for me to learn more about the architecture. > > From my reading of the docs, ARM has the shadow registers, in particular, > the r13 (stack pointer) is shadowed for all privileged modes. Is the shadow > used by our kernel, is it correctly restored on the context switch ? > > If yes, you can easily recover the pcb address from the current sp, > without accessing any coprocessor registers, and even without any > assignment of the global register for curthread (which needs to be > done at the kernel entry). Just align the stack > start on the 2*PAGE_SIZE boundary (like it is already done for MIPS), > and do the mask operation on the sp value to get the end of pcb. > This is atomic and context-switch safe. > > pcb us already per-thread, and can store the thread pointer. > More, you can store the curcpu or cpuid pointer into pcb too, > and update it on the context switch. > > amd64 has an architecturally-defined special register (k)gsbase, which > effectively must be correctly initialized at each kernel entry, and > restored on the return to usermode. Since the initialization on entry > and restoration on exit is not atomic wrt the entry/exit itself, amd64 > periodically gets a bugs which cause kernel running with user gsbase. > This is the fatal bug, destroying the kernel structures and allowing the > CPU privilege mode switch for normal user. > > Using the shadow registers for this purpose eliminate the whole source > of the bugs. Well, IMHO, the both kernel and user thread stacks must correctly be set for current threads, otherwise it doesn't work. So, the idea to save things on a thread stack and update them on a context switch will work in general. However, the stack must be aligned to its size. And this is the price. I have no idea how this kernel stack alignment can impact kernel virtual space fragmentation. OTOH, as you say, this kernel stack storage can be used for many things. Svata From owner-freebsd-current@FreeBSD.ORG Fri Mar 1 13:25:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 327F2801 for ; Fri, 1 Mar 2013 13:25:03 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id A99CBD60 for ; Fri, 1 Mar 2013 13:25:02 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r21DOBeo031416; Fri, 1 Mar 2013 17:24:11 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r21DNnJo031414; Fri, 1 Mar 2013 17:23:49 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 1 Mar 2013 17:23:49 +0400 From: Gleb Smirnoff To: Varun Chandramohan Subject: Re: Divert socket issues. Message-ID: <20130301132349.GA31353@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 13:25:03 -0000 On Fri, Mar 01, 2013 at 11:44:48AM +1100, Varun Chandramohan wrote: V> I sent this email to net group, unfortunately I got no response. Iam sorry V> if that was the wrong group. Trying it again in this group. I wrote a small V> program using divert sockets to capture packets using ipfw at outgoing. The V> packets that are captured is for application mangling (mostly http headers) V> and resent it back to browser. That means I need to reinject it back in V> incoming instead of outgoing. I believe this is possible based on what is V> said in the man pages. V> V> Man page: V> V> if sendto(2) is used with a destination IP address of INADDR_ANY, then the V> packet is treated as if it were outgoing, i.e., destined for a non-local V> address. Otherwise, the packet is assumed to be incoming and full packet V> routing is done. V> V> In the latter case, the IP address specified must match the address of some V> local interface, or an interface name must be found after the IP address. V> If an interface name is found, that interface will be used and the value V> of the IP V> address will be ignored (other than the fact that it is not INADDR_ANY). V> This is to indicate on which interface the packet ``arrived.'' V> V> According to these instructions, I want my packet In-bound so I set my V> local ip address for the sendto data structure using the below code. V> V> ssize_t V> divert_get(int sd, struct sockaddr_in *sa, char *pkt_buf, int buflen){ V> ssize_t len; V> unsigned int addrlen; V> V> addrlen = sizeof(*sa); V> len = recvfrom(sd, pkt_buf, buflen, 0, V> (struct sockaddr *) sa, &addrlen); V> if(len == -1) { V> bps_log(LOG_ERR, "Unable to recieve message from socket", errno); V> } V> return(len);} V> V> V> /* addr is passed &sa from the above code */ V> rebuild_header(void *ptr, struct sockaddr_in *addr) { V> ssize_t new_len = change_header(ptr);struct ip *ip = (struct ip*)ptr; V> /* this is to divert it to input instead of output */ V> addr->sin_addr.s_addr = ip->ip_src.s_addr; V> V> /* Recompute checksums */ V> ip->ip_len = htons(new_len); V> V> cal_ip_cksum(ptr); V> cal_tcp_cksum(ptr); V> V> if(divert_send(sd, addr, ptr, pkt_len) < 0) { V> printf("No data sent from divert socket %d", errno); V> } V> } V> V> V> I expect the packet to now be inbound but my application is not getting the V> response sent by me. The possible case could be kernel dropping the packet. V> I even set the port number which is the rule I want to match for example, I V> have only two rules 1 and 65535. I tried setting port number to 0,1 and V> even 65535 but still the kernel drops the packet. V> V> addr->sin_port = htons(65535); V> V> sento seems to work fine but the packet does not go through. If I re-inject V> the packet back in the outgoing path (same place I took the packet) things V> seem to work fine. Can someone please tell me whats wrong here? I don't V> seem to understand. The man page is not very clear. I looked a bit into V> divert code and it seem to call ip_input() for the packet I re-injected. If V> thats the case, won't my packet get dropped because it has src address as V> my local address (it expects it to be other way around if server has V> responded)? Can someone please clarify this? If I have to still do it, do I V> need to modify TCP/IP header fields as well? Right, the packet is dropped due to its destination in IP header doesn't match any local addresses. Rewriting IP header to your destionation address of any random TCP packet won't be enough, though, since in this case packet still would be dropped due to it doesn't match any existing connection. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Fri Mar 1 15:32:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2EBBDC88; Fri, 1 Mar 2013 15:32:42 +0000 (UTC) (envelope-from cognet@ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:150:ca0a:a9ff:fef1:a4c9]) by mx1.freebsd.org (Postfix) with ESMTP id BCE5E36D; Fri, 1 Mar 2013 15:32:41 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.5/8.14.5) with ESMTP id r21FWAYU024819; Fri, 1 Mar 2013 16:32:10 +0100 (CET) (envelope-from cognet@ci0.org) Received: (from doginou@localhost) by kanar.ci0.org (8.14.5/8.14.5/Submit) id r21FWA6I024818; Fri, 1 Mar 2013 16:32:10 +0100 (CET) (envelope-from cognet@ci0.org) X-Authentication-Warning: kanar.ci0.org: doginou set sender to cognet@ci0.org using -f Date: Fri, 1 Mar 2013 16:32:10 +0100 From: Olivier Houchard To: Svatopluk Kraus Subject: Re: ARM pcpu changes, was Re: [patch] i386 pmap sysmaps_pcpu[] atomic access Message-ID: <20130301153210.GA24802@ci0.org> References: <201302201022.29294.jhb@freebsd.org> <201302211043.49906.jhb@freebsd.org> <20130225190920.1b7d348d@bender> <20130225124747.GA21027@ci0.org> <20130226210651.580c46a7@bender> <20130226123904.GO2454@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 01 Mar 2013 16:21:49 +0000 Cc: Konstantin Belousov , freebsd-current@freebsd.org, Olivier Houchard , Andrew Turner X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 15:32:42 -0000 On Fri, Mar 01, 2013 at 02:20:16PM +0100, Svatopluk Kraus wrote: > On Tue, Feb 26, 2013 at 1:39 PM, Konstantin Belousov > wrote: > > On Tue, Feb 26, 2013 at 09:06:51PM +1300, Andrew Turner wrote: > >> Does anyone know if it is only curthread that needs to be atomic? If so > >> this should work. Reading the cpuid from the system currently is a > >> single instruction, however it appears the code will need to be reworked > >> for use with multiple levels of affinity, for example when there > >> are clusters of cores the current code will number two cores on > >> different clusters with the same id. > >> > >> I don't think we need to use ldrex/strex to read/write the values, my > >> understanding is the rest should be safe to access without atomic > >> functions. > > > > I read about ARM architecture some time ago. What I am saying below is not > > a proposal, but rather a way for me to learn more about the architecture. > > > > From my reading of the docs, ARM has the shadow registers, in particular, > > the r13 (stack pointer) is shadowed for all privileged modes. Is the shadow > > used by our kernel, is it correctly restored on the context switch ? > > > > If yes, you can easily recover the pcb address from the current sp, > > without accessing any coprocessor registers, and even without any > > assignment of the global register for curthread (which needs to be > > done at the kernel entry). Just align the stack > > start on the 2*PAGE_SIZE boundary (like it is already done for MIPS), > > and do the mask operation on the sp value to get the end of pcb. > > This is atomic and context-switch safe. > > > > pcb us already per-thread, and can store the thread pointer. > > More, you can store the curcpu or cpuid pointer into pcb too, > > and update it on the context switch. > > > > amd64 has an architecturally-defined special register (k)gsbase, which > > effectively must be correctly initialized at each kernel entry, and > > restored on the return to usermode. Since the initialization on entry > > and restoration on exit is not atomic wrt the entry/exit itself, amd64 > > periodically gets a bugs which cause kernel running with user gsbase. > > This is the fatal bug, destroying the kernel structures and allowing the > > CPU privilege mode switch for normal user. > > > > Using the shadow registers for this purpose eliminate the whole source > > of the bugs. > > Well, IMHO, the both kernel and user thread stacks must correctly be > set for current threads, otherwise it doesn't work. So, the idea to > save things on a thread stack and update them on a context switch will > work in general. However, the stack must be aligned to its size. And > this is the price. I have no idea how this kernel stack alignment can > impact kernel virtual space fragmentation. > OTOH, as you say, this kernel stack storage can be used for many things. > Hi, FWIW, I have a proof-of-ooncept patch that does just that, and it seems to work well. Regards, Olivier From owner-freebsd-current@FreeBSD.ORG Fri Mar 1 18:12:44 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 755DF69D for ; Fri, 1 Mar 2013 18:12:44 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 4BECFE01 for ; Fri, 1 Mar 2013 18:12:44 +0000 (UTC) Received: from pool-96-250-5-62.nycmny.fios.verizon.net ([96.250.5.62]:54077 helo=minion.home) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UBURi-0004FZ-NP for current@freebsd.org; Fri, 01 Mar 2013 13:12:38 -0500 From: George Neville-Neil Content-Type: multipart/signed; boundary="Apple-Mail=_73DCBB55-1E50-4781-B197-5E12073A1BCF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <79750FDF-8ADF-4F2A-AF75-71AE29639901@neville-neil.com> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Boot crash with HEAD on Thinkpad X220... Date: Fri, 1 Mar 2013 13:12:39 -0500 References: <13054114-EE88-44D7-AC3F-2B40CDB87113@neville-neil.com> To: current@freebsd.org In-Reply-To: <13054114-EE88-44D7-AC3F-2B40CDB87113@neville-neil.com> X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 18:12:44 -0000 --Apple-Mail=_73DCBB55-1E50-4781-B197-5E12073A1BCF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 25, 2013, at 21:33 , George Neville-Neil = wrote: > Howdy, >=20 > This has been happening since I updated on Saturday. I updated my = tree today (Monday) as well: >=20 > http://people.freebsd.org/~gnn/X220bootcrash25Feb2013.jpg >=20 > The system boots and works well enough to connect to the network and = build a new kernel > if I use safe mode. >=20 > Thoughts? >=20 Happily jhb@ pointed out that there was an issue in binutils recently. = A buildworld plus buildkernel on bits from HEAD on 28 Feb did the trick and all is well = again. Best, George --Apple-Mail=_73DCBB55-1E50-4781-B197-5E12073A1BCF 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.19 (Darwin) iEYEARECAAYFAlEw75cACgkQYdh2wUQKM9KsZQCeP6nP3vXDSnG+yjxFOQt051BU VKYAn3OPZ2dMGNNSXd1YlhhVotBTTv8d =oMOe -----END PGP SIGNATURE----- --Apple-Mail=_73DCBB55-1E50-4781-B197-5E12073A1BCF-- From owner-freebsd-current@FreeBSD.ORG Fri Mar 1 18:35:31 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 47859A16 for ; Fri, 1 Mar 2013 18:35:31 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7D8D1EF5 for ; Fri, 1 Mar 2013 18:35:29 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA11023; Fri, 01 Mar 2013 20:35:24 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <5130F4EB.3040903@FreeBSD.org> Date: Fri, 01 Mar 2013 20:35:23 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Eggert, Lars" Subject: Re: Dtrace: Module is no longer loaded References: <508E98E1.7010502@FreeBSD.org> <51239437.2020503@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Monthadar Al Jaberi , freebsd-current , Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 18:35:31 -0000 on 21/02/2013 11:12 Eggert, Lars said the following: > Hi, > > On Feb 19, 2013, at 16:03, Andriy Gapon wrote: >> Couple of thoughts: >> - is your kernel installed in the typical location? > > yup. > >> - what does the following produce? >> readelf -a -W /boot/kernel/kernel | fgrep shstrtab >> readelf -a -W /boot/kernel/kernel | fgrep SUNW_ctf > > # readelf -a -W /boot/kernel/kernel | fgrep shstrtab > [24] .shstrtab STRTAB 0000000000000000 7975ee 000124 00 0 0 1 > > # readelf -a -W /boot/kernel/kernel | fgrep SUNW_ctf > [22] .SUNW_ctf PROGBITS 0000000000000000 74ed68 048872 00 0 0 4 > > And then: > > # dtrace -n 'syscall:::' > dtrace: invalid probe specifier syscall:::: "/usr/lib/dtrace/psinfo.d", line 90: failed to resolve type kernel`struct thread * for identifier curthread: Module is no longer loaded How does kldstat output look on that machine? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Mar 1 21:49:30 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E1D20308; Fri, 1 Mar 2013 21:49:30 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id A7D491940; Fri, 1 Mar 2013 21:49:30 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 260F324ECC; Fri, 1 Mar 2013 13:49:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1362174570; bh=l+jUj6YnsfuuPZLlTA3XKM0/4R0iZp23OZrIGWZBbBA=; h=Date:From:Reply-To:To:Subject; b=xi6LZ2+97m9RsYjGEDohGjgyTUFXdBeDYqtx3yKqTxrSENLfeFZDJ+5f3+Woja/34 JMK67iwj+Tp4BV99LluXVnEvjsuYPw9GUWqwofNPm2UDVGzIrPD/Ad9dRAOXAXQRwD t40u1LGPhf5js6E+2wVLeMO9moup1Q5aNxgHRYh4= Message-ID: <51312269.9050502@delphij.net> Date: Fri, 01 Mar 2013 13:49:29 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: marius@freebsd.org, current@freebsd.org Subject: [PATCH] Fix build after r247570 X-Enigmail-Version: 1.5.1 Content-Type: multipart/mixed; boundary="------------040401040606010803030302" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 21:49:30 -0000 This is a multi-part message in MIME format. --------------040401040606010803030302 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, Marius, The attached patch fixes two places where 'count' is not properly initialized. They should be merged together when 247570 is merged. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJRMSJpAAoJEG80Jeu8UPuzsxsH/2cArvN1kjTXod8IlSVh3ImV 81pjIcBoNRDAOes6lptsdOOdOeNg4/MweG2PT1ZpxQ5yUQHdBld9eIsaruYnD2/y RcfGeMdSJCZ216yaFHLu54nxvlJJXK1lsO1R1cdeBDdSoQChXulVv38FnKiB9J1m ldFCC8oBdPX6yCRR5ZIuLXHXYXZjGw0Vyvta74NFTNwysrUcgtLT/1tpDpcVtDdd Kd+hJtBif4+3zk4py6IS9qiiiO5wC2YkCC5oNhKy2Dh48l/QIagj0Fx/dWRNW8Q4 VUnKJMn4wnnrEmXAFxKMECaFWXKMmI7pQ/dxLMCaMSl2WJgVxHt5skv4iLKcgxc= =Ah/7 -----END PGP SIGNATURE----- --------------040401040606010803030302 Content-Type: text/plain; charset=UTF-8; name="aac-bce-build-fix.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="aac-bce-build-fix.diff" Index: sys/dev/aac/aac_pci.c =================================================================== --- sys/dev/aac/aac_pci.c (revision 247583) +++ sys/dev/aac/aac_pci.c (working copy) @@ -340,7 +340,7 @@ aac_pci_attach(device_t dev) { struct aac_softc *sc; const struct aac_ident *id; - int count, error, reg, rid; + int count = 0, error, reg, rid; fwprintf(NULL, HBA_FLAGS_DBG_FUNCTION_ENTRY_B, ""); Index: sys/dev/bce/if_bce.c =================================================================== --- sys/dev/bce/if_bce.c (revision 247583) +++ sys/dev/bce/if_bce.c (working copy) @@ -1039,7 +1039,7 @@ bce_attach(device_t dev) struct bce_softc *sc; struct ifnet *ifp; u32 val; - int count, error, rc = 0, rid; + int count = 0, error, rc = 0, rid; sc = device_get_softc(dev); sc->bce_dev = dev; --------------040401040606010803030302-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 2 00:33:48 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 707B6896; Sat, 2 Mar 2013 00:33:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BC6B61E8D; Sat, 2 Mar 2013 00:33:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r220Xfrm023516; Fri, 1 Mar 2013 19:33:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r220XeTM023510; Sat, 2 Mar 2013 00:33:40 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 2 Mar 2013 00:33:40 GMT Message-Id: <201303020033.r220XeTM023510@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 00:33:48 -0000 TB --- 2013-03-01 21:40:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-01 21:40:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-01 21:40:18 - starting HEAD tinderbox run for i386/i386 TB --- 2013-03-01 21:40:18 - cleaning the object tree TB --- 2013-03-01 21:40:18 - /usr/local/bin/svn stat /src TB --- 2013-03-01 21:40:23 - At svn revision 247583 TB --- 2013-03-01 21:40:24 - building world TB --- 2013-03-01 21:40:24 - CROSS_BUILD_TESTING=YES TB --- 2013-03-01 21:40:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-01 21:40:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-01 21:40:24 - SRCCONF=/dev/null TB --- 2013-03-01 21:40:24 - TARGET=i386 TB --- 2013-03-01 21:40:24 - TARGET_ARCH=i386 TB --- 2013-03-01 21:40:24 - TZ=UTC TB --- 2013-03-01 21:40:24 - __MAKE_CONF=/dev/null TB --- 2013-03-01 21:40:24 - cd /src TB --- 2013-03-01 21:40:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Mar 1 21:40:28 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 2 00:26:38 UTC 2013 TB --- 2013-03-02 00:26:38 - generating LINT kernel config TB --- 2013-03-02 00:26:38 - cd /src/sys/i386/conf TB --- 2013-03-02 00:26:38 - /usr/bin/make -B LINT TB --- 2013-03-02 00:26:38 - cd /src/sys/i386/conf TB --- 2013-03-02 00:26:38 - /usr/sbin/config -m LINT TB --- 2013-03-02 00:26:38 - building LINT kernel TB --- 2013-03-02 00:26:38 - CROSS_BUILD_TESTING=YES TB --- 2013-03-02 00:26:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-02 00:26:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-02 00:26:38 - SRCCONF=/dev/null TB --- 2013-03-02 00:26:38 - TARGET=i386 TB --- 2013-03-02 00:26:38 - TARGET_ARCH=i386 TB --- 2013-03-02 00:26:38 - TZ=UTC TB --- 2013-03-02 00:26:38 - __MAKE_CONF=/dev/null TB --- 2013-03-02 00:26:38 - cd /src TB --- 2013-03-02 00:26:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 2 00:26:38 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/aac/aac_pci.c:397:6: note: remove the '&&' if its condition is always true if (aac_enable_msi != 0 && pci_find_cap(dev, PCIY_MSI, ®) == 0) { ^~~~~~~~~~~~~~~~~~~~~~ /src/sys/dev/aac/aac_pci.c:343:11: note: initialize the variable 'count' to silence this warning int count, error, reg, rid; ^ = 0 2 errors generated. *** [aac_pci.o] Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-02 00:33:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-02 00:33:40 - ERROR: failed to build LINT kernel TB --- 2013-03-02 00:33:40 - 8410.23 user 1279.35 system 10402.19 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 2 01:06:34 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4866BEE2; Sat, 2 Mar 2013 01:06:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1FD8D1FF0; Sat, 2 Mar 2013 01:06:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r2216Xh7008074; Fri, 1 Mar 2013 20:06:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r2216XgU008073; Sat, 2 Mar 2013 01:06:33 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 2 Mar 2013 01:06:33 GMT Message-Id: <201303020106.r2216XgU008073@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on amd64/amd64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 01:06:34 -0000 TB --- 2013-03-01 21:40:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-01 21:40:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-01 21:40:18 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-03-01 21:40:18 - cleaning the object tree TB --- 2013-03-01 21:40:18 - /usr/local/bin/svn stat /src TB --- 2013-03-01 21:40:23 - At svn revision 247583 TB --- 2013-03-01 21:40:24 - building world TB --- 2013-03-01 21:40:24 - CROSS_BUILD_TESTING=YES TB --- 2013-03-01 21:40:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-01 21:40:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-01 21:40:24 - SRCCONF=/dev/null TB --- 2013-03-01 21:40:24 - TARGET=amd64 TB --- 2013-03-01 21:40:24 - TARGET_ARCH=amd64 TB --- 2013-03-01 21:40:24 - TZ=UTC TB --- 2013-03-01 21:40:24 - __MAKE_CONF=/dev/null TB --- 2013-03-01 21:40:24 - cd /src TB --- 2013-03-01 21:40:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Mar 1 21:40:28 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Mar 2 01:00:13 UTC 2013 TB --- 2013-03-02 01:00:13 - generating LINT kernel config TB --- 2013-03-02 01:00:13 - cd /src/sys/amd64/conf TB --- 2013-03-02 01:00:13 - /usr/bin/make -B LINT TB --- 2013-03-02 01:00:13 - cd /src/sys/amd64/conf TB --- 2013-03-02 01:00:13 - /usr/sbin/config -m LINT TB --- 2013-03-02 01:00:13 - building LINT kernel TB --- 2013-03-02 01:00:13 - CROSS_BUILD_TESTING=YES TB --- 2013-03-02 01:00:13 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-02 01:00:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-02 01:00:13 - SRCCONF=/dev/null TB --- 2013-03-02 01:00:13 - TARGET=amd64 TB --- 2013-03-02 01:00:13 - TARGET_ARCH=amd64 TB --- 2013-03-02 01:00:13 - TZ=UTC TB --- 2013-03-02 01:00:13 - __MAKE_CONF=/dev/null TB --- 2013-03-02 01:00:13 - cd /src TB --- 2013-03-02 01:00:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 2 01:00:13 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/aac/aac_pci.c:397:6: note: remove the '&&' if its condition is always true if (aac_enable_msi != 0 && pci_find_cap(dev, PCIY_MSI, ®) == 0) { ^~~~~~~~~~~~~~~~~~~~~~ /src/sys/dev/aac/aac_pci.c:343:11: note: initialize the variable 'count' to silence this warning int count, error, reg, rid; ^ = 0 2 errors generated. *** [aac_pci.o] Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-02 01:06:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-02 01:06:33 - ERROR: failed to build LINT kernel TB --- 2013-03-02 01:06:33 - 9763.39 user 1658.08 system 12374.78 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 2 01:36:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 63ACE48B; Sat, 2 Mar 2013 01:36:53 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-da0-f46.google.com (mail-da0-f46.google.com [209.85.210.46]) by mx1.freebsd.org (Postfix) with ESMTP id E51A8167; Sat, 2 Mar 2013 01:36:52 +0000 (UTC) Received: by mail-da0-f46.google.com with SMTP id z8so1664781dad.19 for ; Fri, 01 Mar 2013 17:36:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WINdfxl1BDHFpdoQjwESYbHPe/rOzpSWMepdfeFmUfU=; b=t6IkzkKZonWPFi0dbh36Z0gShCMT+zNh8cepZ70Bd7ny8UPSZgWw0R1WWhPRzxAUvw bQg11znj9C/mlV2KChGjhULdi3pdSyewy6cVyReNs03k7VT45cMw5StnxtvrUvhxQz2c QZEQ6I/1JGuAZFPBytRxU0bAhiXExOE11uOlUd8XrSwDdbLoTDtwtq6RptuvA08kmuZ4 iR7fBNuzy0BEq0TaL2iBVFIEp/F5MRsHHwj/AfEwOTWoIdN3RzNEO5Zs+DQUDHD2ptN6 t2GEkHrBSLw8X8txrHqwbsHQwG89jbeB2oL9YSTYMVC+LNlIwJ0LHpOKYe+bHLD5/mvM SKnQ== X-Received: by 10.66.151.226 with SMTP id ut2mr21489306pab.53.1362188206527; Fri, 01 Mar 2013 17:36:46 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id hs8sm13757378pbc.27.2013.03.01.17.36.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Mar 2013 17:36:45 -0800 (PST) Message-ID: <5131576E.2080403@gmail.com> Date: Fri, 01 Mar 2013 17:35:42 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130224 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Baldwin Subject: Re: Fixing X220 Video The Right Way References: <512A6FFF.2060603@gmail.com> <201302271527.37079.jhb@freebsd.org> <512F5882.7080004@gmail.com> <201302281209.45170.jhb@freebsd.org> In-Reply-To: <201302281209.45170.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 01:36:53 -0000 On 02/28/13 09:09, John Baldwin wrote: > On Thursday, February 28, 2013 8:15:46 am matt wrote: >> On 02/27/13 12:27, John Baldwin wrote: >>> On Wednesday, February 27, 2013 1:35:43 pm matt wrote: >>>> On 02/27/13 09:00, John Baldwin wrote: >>>>> If that is true, it's because your BIOS is lying. Do you have a URL to >>>>> your ASL lying around already? >>>> Too big for pastebin :( +500k >>>> >>>> https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing >>> Here is where I find _DOD and _DOS methods: >>> >>> Device (PCI0) >>> Device (VID) >>> Name (_ADR, 0x00020000) // _ADR: Address >>> Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching >>> Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices >>> Device (PEG) >>> Name (_ADR, 0x00010000) // _ADR: Address >>> Device (VID) >>> Name (_ADR, 0x00) // _ADR: Address >>> Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching >>> Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices >>> >>> PCI0.VID is a PCI device at pci0:0:2:0. >>> PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0. >>> It would have a child device at 0:0 that would be PCI0.PEG.VID. Does the X220 >>> have a switchable GPU (e.g. it has built-in Intel graphics, but also has an >>> Nvidia GPU or some such?). If so, I imagine that PCI0.VID is the Intel graphics >>> and PEG is the non-Intel. The output of 'pciconf -lcv' would be useful to determine >>> that. If both PCI devices exist you shoudl have both acpi_video0 and acpi_video1. >>> However, it may be that the acpi_video driver doesn't cope well with having multiple >>> devices. >> Only Intel graphics, there is no option for switchable graphics. >> I initially thought that PEG was for Optimus usage, and left in the bios >> by accident (i.e. Lenovo using a generic DSDT for many machines) >> >> Here is pciconf -lcf, truncated >> hostb0@pci0:0:0:0: class=0x060000 card=0x21da17aa chip=0x01048086 >> rev=0x09 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '2nd Generation Core Processor Family DRAM Controller' >> class = bridge >> subclass = HOST-PCI >> cap 09[e0] = vendor (length 12) Intel cap 0 version 1 >> vgapci0@pci0:0:2:0: class=0x030000 card=0x21da17aa chip=0x01268086 >> rev=0x09 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '2nd Generation Core Processor Family Integrated >> Graphics Controller' >> class = display >> subclass = VGA >> cap 05[90] = MSI supports 1 message enabled with 1 message >> cap 01[d0] = powerspec 2 supports D0 D3 current D0 >> cap 13[a4] = PCI Advanced Features: FLR TP >> none0@pci0:0:22:0: class=0x078000 card=0x21da17aa chip=0x1c3a8086 >> rev=0x04 hdr=0x00 >> vendor = 'Intel Corporation' >> >> As you can see there is no device at pci0:0:1:0. So no dev_t with for >> acpi_video to probe or attach to. >> >> Nonetheless, only PEGs ACPI methods work, which is quite broken. This is >> true for a large number of Lenovo devices, back to x61 (non-attaching >> AGP adr) and probably including some other x series and t series. >> >> Unfortunately the ASL will not compile which makes fixing the DSDT an >> exercise in fixing broken ACPI. >> >> What I find interesting is that as far as I can tell, there's no special >> case handling for this device in Linux, yet backlight controls work out >> of the box since about 3.0. Installing Linux as the OSI via loader.conf >> is not the issue, unfortunately, nor Windows 2006 (/WVIS) or Windows >> 2009 (/WIN7). I get correct (for platform) behavior when I call PEGs >> _BCM... :( >> >> Is Linux getting this to work by doing it wrong, essentially? > Yes. I think the best way to fix this is to add a way to specify a > hint to override the ACPI path associated with a PCI device. Something > like: > > hw.pci0.0.2.0.handle="\_SB_.PCI0.PEG.VID" > > I think this patch should do the trick: > > Index: sys/dev/acpica/acpi_pci.c > =================================================================== > --- acpi_pci.c (revision 247320) > +++ acpi_pci.c (working copy) > @@ -264,6 +264,40 @@ acpi_pci_save_handle(ACPI_HANDLE handle, UINT32 le > return_ACPI_STATUS (AE_OK); > } > > +static void > +acpi_pci_override_handles(device_t dev) > +{ > + struct acpi_pci_devinfo *dinfo; > + device_t *devlist; > + int error, i, numdevs; > + char tunable_name[64], *path; > + ACPI_HANDLE handle; > + > + error = device_get_children(dev, &devlist, &numdevs); > + if (error) > + return; > + for (i = 0; i < numdevs; i++) { > + dinfo = device_get_ivars(devlist[i]); > + snprintf(tunable_name, sizeof(tunable_name), > + "hw.pci%d.%d.%d.%d.handle", dinfo->ap_dinfo.cfg.domain, > + dinfo->ap_dinfo.cfg.bus, dinfo->ap_dinfo.cfg.slot, > + dinfo->ap_dinfo.cfg.func); > + path = getenv(tunable_name); > + if (path == NULL) > + continue; > + if (ACPI_SUCCESS(AcpiGetHandle(NULL, path, &handle))) { > + device_printf(dev, > + "Forcing device at %d.%d to use path %s\n", > + dinfo->ap_dinfo.cfg.slot, > + dinfo->ap_dinfo.cfg.func, path); > + dinfo->ap_handle = handle; > + acpi_pci_update_device(handle, devlist[i]); > + } > + freeenv(path); > + } > + free(devlist, M_TEMP); > +} > + > static int > acpi_pci_probe(device_t dev) > { > @@ -306,5 +340,10 @@ acpi_pci_attach(device_t dev) > AcpiWalkNamespace(ACPI_TYPE_DEVICE, acpi_get_handle(dev), 1, > acpi_pci_save_handle, NULL, dev, NULL); > > + /* > + * Perform another pass over child devices to allow their > + * handles to be overridden via a hint from the user. > + */ > + acpi_pci_override_handles(dev); > return (bus_generic_attach(dev)); > } > > Initial attempt with this patch failed to change the result in devinfo -rv...I will hopefully have more info tonight. Thanks, Matt From owner-freebsd-current@FreeBSD.ORG Sat Mar 2 02:04:31 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0A5F1850 for ; Sat, 2 Mar 2013 02:04:31 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id C1CCD1FF for ; Sat, 2 Mar 2013 02:04:30 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id AB1DEEA9 for ; Sat, 2 Mar 2013 03:01:26 +0100 (CET) Date: Sat, 2 Mar 2013 03:05:44 +0100 From: Pawel Jakub Dawidek To: current@FreeBSD.org Subject: HEADS UP: Capsicum overhaul. Message-ID: <20130302020544.GF16664@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4f28nU6agdXSinmL" Content-Disposition: inline X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 02:04:31 -0000 --4f28nU6agdXSinmL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I just committed pretty large change that affects not only Capsicum, but also descriptor handling code in the kernel. If you will find some strange problems after r243611 (like panics, unexpected application errors, etc.) I may be at fault. I'll be looking at current@ mailing list closly, so report here if you find problems that look related to my change. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --4f28nU6agdXSinmL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlExXngACgkQForvXbEpPzRSeQCgkG5Cd8/qdlL5m36QaOIRXq/t rHgAoPcnlnKFOSjlTM1HRyCbqu/X+IO8 =6xPD -----END PGP SIGNATURE----- --4f28nU6agdXSinmL-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 2 02:47:58 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3B321CB; Sat, 2 Mar 2013 02:47:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 11B2332A; Sat, 2 Mar 2013 02:47:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r222luf7079574; Fri, 1 Mar 2013 21:47:57 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r222luDv079570; Sat, 2 Mar 2013 02:47:56 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 2 Mar 2013 02:47:56 GMT Message-Id: <201303020247.r222luDv079570@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 02:47:58 -0000 TB --- 2013-03-01 23:48:55 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-01 23:48:55 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-01 23:48:55 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-03-01 23:48:55 - cleaning the object tree TB --- 2013-03-01 23:48:55 - /usr/local/bin/svn stat /src TB --- 2013-03-01 23:48:58 - At svn revision 247583 TB --- 2013-03-01 23:48:59 - building world TB --- 2013-03-01 23:48:59 - CROSS_BUILD_TESTING=YES TB --- 2013-03-01 23:48:59 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-01 23:48:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-01 23:48:59 - SRCCONF=/dev/null TB --- 2013-03-01 23:48:59 - TARGET=pc98 TB --- 2013-03-01 23:48:59 - TARGET_ARCH=i386 TB --- 2013-03-01 23:48:59 - TZ=UTC TB --- 2013-03-01 23:48:59 - __MAKE_CONF=/dev/null TB --- 2013-03-01 23:48:59 - cd /src TB --- 2013-03-01 23:48:59 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Mar 1 23:49:03 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 2 02:41:33 UTC 2013 TB --- 2013-03-02 02:41:33 - generating LINT kernel config TB --- 2013-03-02 02:41:33 - cd /src/sys/pc98/conf TB --- 2013-03-02 02:41:33 - /usr/bin/make -B LINT TB --- 2013-03-02 02:41:33 - cd /src/sys/pc98/conf TB --- 2013-03-02 02:41:33 - /usr/sbin/config -m LINT TB --- 2013-03-02 02:41:33 - building LINT kernel TB --- 2013-03-02 02:41:33 - CROSS_BUILD_TESTING=YES TB --- 2013-03-02 02:41:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-02 02:41:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-02 02:41:33 - SRCCONF=/dev/null TB --- 2013-03-02 02:41:33 - TARGET=pc98 TB --- 2013-03-02 02:41:33 - TARGET_ARCH=i386 TB --- 2013-03-02 02:41:33 - TZ=UTC TB --- 2013-03-02 02:41:33 - __MAKE_CONF=/dev/null TB --- 2013-03-02 02:41:33 - cd /src TB --- 2013-03-02 02:41:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 2 02:41:33 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/bce/if_bce.c:1108:29: error: variable 'count' is uninitialized when used here [-Werror,-Wuninitialized] (bce_msi_enable >= 1) && (count == 0)) { ^~~~~ /src/sys/dev/bce/if_bce.c:1042:11: note: initialize the variable 'count' to silence this warning int count, error, rc = 0, rid; ^ = 0 1 error generated. *** [if_bce.o] Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-02 02:47:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-02 02:47:56 - ERROR: failed to build LINT kernel TB --- 2013-03-02 02:47:56 - 8541.73 user 1329.06 system 10741.77 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 2 03:24:04 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 280A27A4; Sat, 2 Mar 2013 03:24:04 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id DFDF4713; Sat, 2 Mar 2013 03:24:03 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id ABD8760DB; Fri, 1 Mar 2013 22:24:02 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=eYKtpEZ4FSr2jhMlOlGRp7vPzbTCRu3LAFgFznmvLZjFgfpEWKBMP5XKxgCYvNIG8 AfU8AUyShwlnziLknEPKtvxFhfXSxiA1eJ4olzJXmXe7NHb2P2fmfP2JgFjkqsc Message-ID: <513170D1.9000801@protected-networks.net> Date: Fri, 01 Mar 2013 22:24:01 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130227 Thunderbird/17.0.3 MIME-Version: 1.0 To: Pawel Jakub Dawidek Subject: Re: HEADS UP: Capsicum overhaul. References: <20130302020544.GF16664@garage.freebsd.pl> In-Reply-To: <20130302020544.GF16664@garage.freebsd.pl> X-Enigmail-Version: 1.5.1 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 03:24:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/01/13 21:05, Pawel Jakub Dawidek wrote: > I just committed pretty large change that affects not only Capsicum, but > also descriptor handling code in the kernel. If you will find some > strange problems after r243611 (like panics, unexpected application > errors, etc.) I may be at fault. I'll be looking at current@ mailing > list closly, so report here if you find problems that look related to my > change. > Two things I noted with a kernel @ SVN r247608: On reboot .. newsyslog: can't mv /var/log/debug.log.zGwQSBb to /var/log/debug.log: Capabilities insufficient .. and X/intel/KMS fails to start reverting to SVN r247497 (my previous compilation) performs as expected, imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEARECAAYFAlExcNEACgkQQv9rrgRC1JIJNgCfR6QOCb/lFDqh4yRfmGEoDJ4l y3wAoIc1unEGPyUADUQmf5pkVR8b1V16 =fMvc -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Mar 2 03:45:07 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 220CEB23; Sat, 2 Mar 2013 03:45:07 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id EB3BD7C5; Sat, 2 Mar 2013 03:45:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:cc:To:Sender:From:Date; bh=+uuufetDAqVX3k/12LqGXb9LF4Zs7k199xJEtuSC4hU=; b=qOtbSWF/AocGGsqHRkV+59iS1Ap9ZTdUXsLzPUlCRbuqMpLWpfYHAnmt7dNne28fJOhjxaVJT3SEFmJlEY7s5yu36HSpe17v3vScbEt1r6LaIR1SQxeeIGdhBMukSxExXRAm7Lk0ZC+ryHr0MEC+FBvNGFmINR/GCHIF9vwE6ek=; Received: from cpe-72-182-19-162.austin.res.rr.com ([72.182.19.162]:46227 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UBdNh-0004Ms-Oa; Fri, 01 Mar 2013 21:45:06 -0600 Date: Fri, 1 Mar 2013 21:45:02 -0600 (CST) From: Larry Rosenman Sender: ler@borg To: Pawel Jakub Dawidek Subject: Re: HEADS UP: Capsicum overhaul. In-Reply-To: <20130302020544.GF16664@garage.freebsd.pl> Message-ID: References: <20130302020544.GF16664@garage.freebsd.pl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 03:45:07 -0000 On Sat, 2 Mar 2013, Pawel Jakub Dawidek wrote: > I just committed pretty large change that affects not only Capsicum, but > also descriptor handling code in the kernel. If you will find some > strange problems after r243611 (like panics, unexpected application > errors, etc.) I may be at fault. I'll be looking at current@ mailing > list closly, so report here if you find problems that look related to my > change. > > Similar to another post: vn up Updating '.': U databases/py-sqlite3/Makefile U databases/py-sqlite3/files/setup.py U databases/py-sqlite3/files/setup3.py svn: E000093: Can't move '/usr/ports/.svn/tmp/svn-X6U5KQ' to '/usr/ports/databases/py-sqlite3/Makefile': Capabilities insufficient # svn up svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted # svn cleanup svn: E000093: Can't move '/usr/ports/.svn/tmp/svn-Bb1iSM' to '/usr/ports/databases/py-sqlite3/Makefile': Capabilities insufficient # -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Sat Mar 2 10:00:14 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3139D1CC for ; Sat, 2 Mar 2013 10:00:14 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id F231E301 for ; Sat, 2 Mar 2013 10:00:13 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 4AD97F44; Sat, 2 Mar 2013 10:57:09 +0100 (CET) Date: Sat, 2 Mar 2013 11:01:30 +0100 From: Pawel Jakub Dawidek To: Michael Butler Subject: Re: HEADS UP: Capsicum overhaul. Message-ID: <20130302100130.GB1883@garage.freebsd.pl> References: <20130302020544.GF16664@garage.freebsd.pl> <513170D1.9000801@protected-networks.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wq9mPyueHGvFACwf" Content-Disposition: inline In-Reply-To: <513170D1.9000801@protected-networks.net> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 10:00:14 -0000 --wq9mPyueHGvFACwf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 01, 2013 at 10:24:01PM -0500, Michael Butler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 03/01/13 21:05, Pawel Jakub Dawidek wrote: > > I just committed pretty large change that affects not only Capsicum, but > > also descriptor handling code in the kernel. If you will find some > > strange problems after r243611 (like panics, unexpected application > > errors, etc.) I may be at fault. I'll be looking at current@ mailing > > list closly, so report here if you find problems that look related to my > > change. > >=20 >=20 > Two things I noted with a kernel @ SVN r247608: >=20 > On reboot .. >=20 > newsyslog: can't mv /var/log/debug.log.zGwQSBb to /var/log/debug.log: > Capabilities insufficient >=20 > .. and X/intel/KMS fails to start >=20 > reverting to SVN r247497 (my previous compilation) performs as expected, I've fixed the rename problem in r247616. Not sure if this will fix X. Could you give it a try? Thank you for the report! --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --wq9mPyueHGvFACwf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlExzfoACgkQForvXbEpPzRkEACg+fr9CRkniHEyk2gT+a9ID7/P yqUAnjv7HfxEmqEhLrK0L0oXHbnnb57w =uS3i -----END PGP SIGNATURE----- --wq9mPyueHGvFACwf-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 2 10:00:51 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 86C8F2D5 for ; Sat, 2 Mar 2013 10:00:51 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 53F6B327 for ; Sat, 2 Mar 2013 10:00:51 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id D759CF46; Sat, 2 Mar 2013 10:57:47 +0100 (CET) Date: Sat, 2 Mar 2013 11:02:09 +0100 From: Pawel Jakub Dawidek To: Larry Rosenman Subject: Re: HEADS UP: Capsicum overhaul. Message-ID: <20130302100209.GC1883@garage.freebsd.pl> References: <20130302020544.GF16664@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oJ71EGRlYNjSvfq7" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 10:00:51 -0000 --oJ71EGRlYNjSvfq7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 01, 2013 at 09:45:02PM -0600, Larry Rosenman wrote: > On Sat, 2 Mar 2013, Pawel Jakub Dawidek wrote: >=20 > > I just committed pretty large change that affects not only Capsicum, but > > also descriptor handling code in the kernel. If you will find some > > strange problems after r243611 (like panics, unexpected application > > errors, etc.) I may be at fault. I'll be looking at current@ mailing > > list closly, so report here if you find problems that look related to my > > change. > > > > >=20 > Similar to another post: > vn up > Updating '.': > U databases/py-sqlite3/Makefile > U databases/py-sqlite3/files/setup.py > U databases/py-sqlite3/files/setup3.py > svn: E000093: Can't move '/usr/ports/.svn/tmp/svn-X6U5KQ' to '/usr/ports/= databases/py-sqlite3/Makefile': Capabilities insufficient > # svn up > svn: E155037: Previous operation has not finished; run 'cleanup' if it wa= s interrupted > # svn cleanup > svn: E000093: Can't move '/usr/ports/.svn/tmp/svn-Bb1iSM' to '/usr/ports/= databases/py-sqlite3/Makefile': Capabilities insufficient This should be now fixed in r247616. Thank you for the report! --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --oJ71EGRlYNjSvfq7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlExziEACgkQForvXbEpPzTdmQCgty74OygsFyC7kritokNFGEsV SSAAn2zy0HQG4bI7qPXOSRnovVNDuRvL =uGBA -----END PGP SIGNATURE----- --oJ71EGRlYNjSvfq7-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 2 14:54:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 96029AB1 for ; Sat, 2 Mar 2013 14:54:30 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id 7C6F9F58 for ; Sat, 2 Mar 2013 14:54:30 +0000 (UTC) Received: from [10.0.10.1] ([173.88.202.176]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 2 Mar 2013 06:54:26 -0800 Message-ID: <5132129F.1020108@a1poweruser.com> Date: Sat, 02 Mar 2013 09:54:23 -0500 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Peter Wemm Subject: Re: Response of *.freebsd.org websites are very slow References: <512DE205.4010202@digsys.bg> <512E4D3F.6050900@gmail.com> <512E64CA.6030408@daemonic.se> <512F431E.7080507@a1poweruser.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Mar 2013 14:54:26.0155 (UTC) FILETIME=[D57A63B0:01CE1755] X-Sender: fbsd8@a1poweruser.com X-Authenticated-Sender: fbsd8@a1poweruser.com X-EchoSenderHash: [fbsd8]-[a1poweruser*com] Cc: matt , Kevin Oberman , Current , Daniel Kalchev , Niclas Zeising , Daniel Nebdal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 14:54:30 -0000 Peter Wemm wrote: > On Thu, Feb 28, 2013 at 3:44 AM, Fbsd8 wrote: > [..] >> From cleveland ohio and www.freebsd.org is un-reachable again. It comes and >> gos. To me it's acting like someone high up is making dns changes. >> Some freebsd official better contact yahoo and put a stop to what ever there >> fooling around with. > > Nope. It isn't DNS, but there is a routing issue for ipv6 space > between Level-3 and and Yahoo. I'm working on it. > Peter Wemm; Just to keep you up to date, it's now March 02 and the same slowness / time out problem still exists. What ever your doing is causing it. Please don't leave your trial ipv6 fix in effect when your not actively working on the problem. Your trial fix is effecting all the "freebsd" sites. Leaving your nonworking trial fix in live production status is NOT the correct way of testing it. Restoring the environment to the known working condition in between cycles of testing your trial fix is the normal accepted method of testing such production level fixes to limit the un-desirable effects of said production level testing. From owner-freebsd-current@FreeBSD.ORG Sat Mar 2 14:55:56 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9919EF00; Sat, 2 Mar 2013 14:55:56 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6EB78F85; Sat, 2 Mar 2013 14:55:56 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 7890660DE; Sat, 2 Mar 2013 09:55:46 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=LwSwUTo0SFZBdes2lk7IE80xrxNi05x2FrPLHXLkDHIBXqzI+ipe2Fi/QZFO5JZRb bbJaINSOC+JzabkEjRsdtFaL2LjG0efA6r46DQ0X97LOmsaSouhHzj3INAk0kgC Message-ID: <513212F0.2040400@protected-networks.net> Date: Sat, 02 Mar 2013 09:55:44 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130227 Thunderbird/17.0.3 MIME-Version: 1.0 To: Pawel Jakub Dawidek Subject: Re: HEADS UP: Capsicum overhaul. References: <20130302020544.GF16664@garage.freebsd.pl> <513170D1.9000801@protected-networks.net> <20130302100130.GB1883@garage.freebsd.pl> In-Reply-To: <20130302100130.GB1883@garage.freebsd.pl> X-Enigmail-Version: 1.5.1 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 14:55:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/02/13 05:01, Pawel Jakub Dawidek wrote: > > I've fixed the rename problem in r247616. Not sure if this will fix X. > Could you give it a try? That fixes X as well - thanks! imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEARECAAYFAlEyEvAACgkQQv9rrgRC1JJM3wCfT2sg9yMRzrx/zU0DSz3ABhnT GW0AoMTwBTNoNuULkWIJIkXRhFWEuWtY =LTSA -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Mar 2 16:52:44 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9839631D; Sat, 2 Mar 2013 16:52:44 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 16E4F790; Sat, 2 Mar 2013 16:52:43 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id ez12so553838wid.17 for ; Sat, 02 Mar 2013 08:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:subject:message-id:mime-version :content-type:content-disposition:user-agent; bh=MmoXJz7jLtSlaQ7zU8aE7ChTlXcjG2pAgDCExVhyUdo=; b=LZfJWHXQNpQp/ybD4ENkXGqywy3XkIfps9F+ISB95Nml05Ae67SVxCvuRw9GsPXH/5 WBJ8y3EIPubEYjA35BlOz6K3h8uvFy/7vy5bHbfTTbKO+h+LwkhUOfzpMMs/PCkO9h7w qcApKVSHIHQY6ETStezGCMijodM2kH/66LLzBPHYXMburlnQ4m8tQbrTvNiqL4A5ciD7 kFCkLk2PNdtZvqH9E5nEtH4582YR5bov8GXiRVLazMnf5QYt7KAaxS6tHQ9EXjni+7TL FxPtP22ARLxYpuHN3Llei0CrmWH14TRCYNgW+rxWqeAraAWUCYTR7pRyFuud9pSZkiiP KLmQ== X-Received: by 10.194.87.229 with SMTP id bb5mr23405414wjb.32.1362243162906; Sat, 02 Mar 2013 08:52:42 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPS id fx5sm4567525wib.11.2013.03.02.08.52.41 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 02 Mar 2013 08:52:41 -0800 (PST) Sender: Baptiste Daroussin Date: Sat, 2 Mar 2013 17:52:39 +0100 From: Baptiste Daroussin To: arch@FreeBSD.org, current@FreeBSD.org Subject: Import libyaml into base Message-ID: <20130302165239.GB27078@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jq0ap7NbKX2Kqbes" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 16:52:44 -0000 --jq0ap7NbKX2Kqbes Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi, I want to import libyaml into base as libbsdyml so that no ports will use it like we do for expat. I need it for the pkg bootstrap, so it it can parse pkg.conf. I know that some of the bhyve people will also be glad to use it. libyaml is MIT licensed, it is stable: no abi/api revolution in it for a while. Does anyone have an objection? regards, Bapt --jq0ap7NbKX2Kqbes Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEyLlcACgkQ8kTtMUmk6Ew8BwCfexYVs8FgtiANTz0IP7smTCA3 CvUAn2xgeyxOvvts+2qhLJPq5lGAOFfa =cTMW -----END PGP SIGNATURE----- --jq0ap7NbKX2Kqbes-- From owner-freebsd-current@FreeBSD.ORG Sat Mar 2 17:19:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0DE191A6 for ; Sat, 2 Mar 2013 17:19:34 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by mx1.freebsd.org (Postfix) with ESMTP id A34C389B for ; Sat, 2 Mar 2013 17:19:33 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id k1so7338543oag.33 for ; Sat, 02 Mar 2013 09:19:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=zvC4MIlKq6CnrDIdPuzB11mQb53ry/TcV+uKCiM5BGw=; b=xfuhV4luA09Mq9lQNcV8iPHDmNEYvIp3E5jR3ddw6Eds7jHOYqTD8+SYK/kxTbUhgD lG2ogNdvli407V0ceVhctTPo8gTZ2Cs6UJIEXk7uBH9ush3fQU8ac4JWCQ0JM7FBgIpt HOkIWItpYdHvR9qjQmrANdb0LaRaRkFrAALcPHDk1DiJ+VxX+3kZZs/YptWCmyHdBjiE veGbBC/0Otmsgaxwbqk0gA8ifU4uHEE8lDSFiU4RT8jqIm+DuRmHixkvIaLmkDWeFcum PcwYHYorYPRqkqFxc3RX88s6uP+tFkn7pk3zkiWmPly6CZMnjG4La2Maq6jqpgUYGRFi EAvQ== MIME-Version: 1.0 X-Received: by 10.182.156.103 with SMTP id wd7mr11747912obb.33.1362244767020; Sat, 02 Mar 2013 09:19:27 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.76.34.197 with HTTP; Sat, 2 Mar 2013 09:19:26 -0800 (PST) In-Reply-To: <5132129F.1020108@a1poweruser.com> References: <512DE205.4010202@digsys.bg> <512E4D3F.6050900@gmail.com> <512E64CA.6030408@daemonic.se> <512F431E.7080507@a1poweruser.com> <5132129F.1020108@a1poweruser.com> Date: Sat, 2 Mar 2013 09:19:26 -0800 X-Google-Sender-Auth: B1nM3yUAfYz9zAEC7eGDMz0TQUQ Message-ID: Subject: Re: Response of *.freebsd.org websites are very slow From: Kevin Oberman To: Fbsd8 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: matt , Peter Wemm , Current , Daniel Kalchev , Niclas Zeising , Daniel Nebdal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 17:19:34 -0000 On Sat, Mar 2, 2013 at 6:54 AM, Fbsd8 wrote: > Peter Wemm wrote: > >> On Thu, Feb 28, 2013 at 3:44 AM, Fbsd8 wrote: >> [..] >> >>> From cleveland ohio and www.freebsd.org is un-reachable again. It comes >>> and >>> gos. To me it's acting like someone high up is making dns changes. >>> Some freebsd official better contact yahoo and put a stop to what ever >>> there >>> fooling around with. >>> >> >> Nope. It isn't DNS, but there is a routing issue for ipv6 space >> between Level-3 and and Yahoo. I'm working on it. >> >> > Peter Wemm; > Just to keep you up to date, it's now March 02 and the same slowness / > time out problem still exists. What ever your doing is causing it. Please > don't leave your trial ipv6 fix in effect when your not actively working on > the problem. Your trial fix is effecting all the "freebsd" sites. Leaving > your nonworking trial fix in live production status is NOT the correct way > of testing it. Restoring the environment to the known working condition in > between cycles of testing your trial fix is the normal accepted method of > testing such production level fixes to limit the un-desirable effects of > said production level testing. > As of this time there is NO IPv6 address for www.freebsd.org. I assume that it was removed until the issues of routing between Y! and Level(3) are resolved. I'm not at all sure why you refer to the IPv6 support as a "trial". As far as I know, the IPv6 was intended to be normal, production service and, for almost everyone, it worked fine, Unfortunately, the routing via Level(3) was not set up correctly and freebsd.org could not be reached via Level(3). It was NOT an IPv6 issue. The same thing has caused the same sort of problems with IPv4 and will continue to do so as it is simply two parties not understanding what the other expects in terms of routing. Also, please don't blame either side unless you know more details of the address assignment than are publicly available. I do find it disturbing that it is taking so long to fix, though. It really is not rocket science for people who understand BGP and routing policy. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Mar 2 17:30:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3E28BA71 for ; Sat, 2 Mar 2013 17:30:09 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id BFCD3913 for ; Sat, 2 Mar 2013 17:30:08 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c41so3124562eek.13 for ; Sat, 02 Mar 2013 09:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=bpeBo918wXvu6zdL5xm29eeNqpgflGN5qzZkExmtrRg=; b=R7mlNy9Kz/ER8Cr85zSlGOpByl/HxxGZEgFCLAbRStVVRsk/6BifyBRTOG7zCESweW yKlEczg6YdMUfyO1+o598l7chPRyQqJBH8Z1BwaLPHqRIEys1cBfa8AraJrswqoWNGKl SYjfvhvEbzGoyltSNRN9VJks65UVFDQJ0VYVCYHqU2w6nxJjrqF3D2U4Xfn3LJJbAvsU A45yghJVLihIhxdXDkhbTp8AiOGmsct6S0IBsad618fekNWdDiFxLWrac/dPYUHJ31Ex O+yodE18fWYhFK4F1LkYxp7A6pSj7rqUVn445h0tR8elLdCnZ7ESArWyq/Rmn4qCSYys X8HA== X-Received: by 10.14.207.200 with SMTP id n48mr40488741eeo.4.1362245401661; Sat, 02 Mar 2013 09:30:01 -0800 (PST) Received: from [192.168.1.80] (dsl91EC79C6.pool.t-online.hu. [145.236.121.198]) by mx.google.com with ESMTPS id k7sm23066756een.8.2013.03.02.09.29.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Mar 2013 09:30:00 -0800 (PST) Message-ID: <51323712.5000406@gmail.com> Date: Sat, 02 Mar 2013 18:29:54 +0100 From: deeptech71 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:18.0) Gecko/20100101 SeaMonkey/2.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: access to hard drives is "blocked" by writes to a flash drive Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 17:30:09 -0000 When one of my flash drives is being heavily written to; typically by ``svn update'' on /usr/src, located on the flash drive; the following can be said about filesystem behavior: - ``svn update'' seems to be able to quickly update a bunch of files, but is then unable to continue for a period of time. This behavior is cyclical, and cycles several times, depending on the amount of updating work to be done for a particular run of ``svn update''. - Access to any filesystem, whether on the said flash drive or not, seems to be hindered a lot, typically during the said "unable to continue" time. Reading of a file on a hard drive was once delayed for more than 10 seconds. Seemingly as a consequence, the starting of top(1) is also typically delayed. SU is enabled on all UFS filesystems, including the ones on the hard drives and the flash drive. From owner-freebsd-current@FreeBSD.ORG Sat Mar 2 20:46:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D81241EC for ; Sat, 2 Mar 2013 20:46:44 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by mx1.freebsd.org (Postfix) with ESMTP id 1C06F1A3 for ; Sat, 2 Mar 2013 20:46:43 +0000 (UTC) Received: by mail-bk0-f52.google.com with SMTP id jk13so1803479bkc.25 for ; Sat, 02 Mar 2013 12:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=Q8dHNBz1TjRR2kNtB1EPjKIRENdoC+D1fNZ6y8KNU/4=; b=v9WYyvW63y9REKuaU4ISXfOkAh/9KjWDzqRm2WWg7z8Z/sXmJud50VzRyhjaW2AK0W IliktVUnfG849cM20OYNT5voB6pBHs7Xfv9jfVsGchqajSBVtztYmXrZSHRsouk2Ym/o DlJXDiQ2DGXk718wotbNztNmqcRE+Fx6sfttiGPyatBaN2mc61UhdIgMhGged1v8UmQU 4ZN/j4xylFdkQdbqvFh8tg9JxDGxU5gTWVCZx8vyEw7X3lWp14koFUPTWHGWdmN2rXdA fsRGlWwLtbGGNGfbOZ3f6LgBtDJ/0kQj9L9CMbxcsagYV64PY0EjDyid2s5u3o3+tcgU cThQ== X-Received: by 10.205.136.205 with SMTP id il13mr5424559bkc.93.1362257202646; Sat, 02 Mar 2013 12:46:42 -0800 (PST) Received: from [192.168.1.104] (45.81.datacomsa.pl. [195.34.81.45]) by mx.google.com with ESMTPS id x10sm4166447bkv.13.2013.03.02.12.46.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Mar 2013 12:46:41 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: access to hard drives is "blocked" by writes to a flash drive Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <51323712.5000406@gmail.com> Date: Sat, 2 Mar 2013 21:46:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <42B72A5B-A363-426B-9F6C-7F8B3B7E7543@FreeBSD.org> References: <51323712.5000406@gmail.com> To: deeptech71 X-Mailer: Apple Mail (2.1283) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 20:46:44 -0000 Wiadomo=B6=E6 napisana przez deeptech71 w dniu 2 mar 2013, o godz. = 18:29: > When one of my flash drives is being heavily written to; typically by = ``svn update'' on /usr/src, located on the flash drive; the following = can be said about filesystem behavior: >=20 > - ``svn update'' seems to be able to quickly update a bunch of files, = but is then unable to continue for a period of time. This behavior is = cyclical, and cycles several times, depending on the amount of updating = work to be done for a particular run of ``svn update''. > - Access to any filesystem, whether on the said flash drive or not, = seems to be hindered a lot, typically during the said "unable to = continue" time. Reading of a file on a hard drive was once delayed for = more than 10 seconds. Seemingly as a consequence, the starting of top(1) = is also typically delayed. When that happens, could you do "ps axl" and see the WCHAN column for the affected processes? Is it "wdrain"? --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-current@FreeBSD.ORG Sat Mar 2 18:20:27 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BE99974D; Sat, 2 Mar 2013 18:20:27 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) by mx1.freebsd.org (Postfix) with ESMTP id 74600B39; Sat, 2 Mar 2013 18:20:27 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id r22IJWSA041214; Sat, 2 Mar 2013 10:19:32 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201303021819.r22IJWSA041214@chez.mckusick.com> To: Sergey Kandaurov , David Wolfskill Subject: Re: [PATCH] Fix sbin/fsdb/fsdbutil.c for r247212 In-reply-to: Date: Sat, 02 Mar 2013 10:19:32 -0800 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com X-Mailman-Approved-At: Sat, 02 Mar 2013 22:04:23 +0000 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 18:20:27 -0000 > Date: Sun, 24 Feb 2013 22:41:21 +0300 > Subject: Re: [PATCH] Fix sbin/fsdb/fsdbutil.c for r247212 > From: Sergey Kandaurov > To: David Wolfskill > Cc: current@freebsd.org, Kirk McKusick > > On 24 February 2013 19:25, David Wolfskill wrote: >> On Sun, Feb 24, 2013 at 07:05:34AM -0800, David Wolfskill wrote: >>> ...hine was: >>> Simple patch attached; world is still building, but at least it got >>> through the "make dependencies" phase this time. >>> ... >> >> That was incomplete, as it didn't (also) address the change to >> getdatablk(). >> >> The attached patch actually made it through buildworld. >> >> Note that it is entirely possible that I erred in specifying >> "BT_UNKNOWN" for the additional "type" argument. > > Hi David. > > Thank you for the proposed fix. I committed it with r247234. > I'm not sure regarding BT_UNKNOWN value either. Well.. at least > it should be not worse that it is now, and it should fix the build. > I have not found any (regressive) changes in fsdb -d `blocks' output. > > -- > wbr, > pluknet Sorry, I am bad about keeping up with my mckusick@freebsd.org email. I do need to watch it right after making commits. I also had no idea that sbin/fsdb shared code with sbin/fsck_ffs. I really do need to get back in the habit of buildworlds before doing any commits. All that said, the changes that you have made are correct. The type is only used for collecting statistics. So, if you do not know the type, using DT_UNKNOWN is correct. If there is ever a desire to collect type-of-I/O statistics in fsdb then that choice will need to be revisited. But, I doubt that type-of-I/O statistics are ever likely to be interesting in fsdb. Kirk McKusick From owner-freebsd-current@FreeBSD.ORG Sat Mar 2 22:08:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4ED9F6FA; Sat, 2 Mar 2013 22:08:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1121865A; Sat, 2 Mar 2013 22:08:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r22M8eNY020375; Sat, 2 Mar 2013 17:08:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r22M8eWg020347; Sat, 2 Mar 2013 22:08:40 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 2 Mar 2013 22:08:40 GMT Message-Id: <201303022208.r22M8eWg020347@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 22:08:42 -0000 TB --- 2013-03-02 16:10:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-02 16:10:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-03-02 16:10:18 - starting HEAD tinderbox run for i386/i386 TB --- 2013-03-02 16:10:18 - cleaning the object tree TB --- 2013-03-02 16:10:18 - /usr/local/bin/svn stat /src TB --- 2013-03-02 16:10:22 - At svn revision 247633 TB --- 2013-03-02 16:10:23 - building world TB --- 2013-03-02 16:10:23 - CROSS_BUILD_TESTING=YES TB --- 2013-03-02 16:10:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-02 16:10:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-02 16:10:23 - SRCCONF=/dev/null TB --- 2013-03-02 16:10:23 - TARGET=i386 TB --- 2013-03-02 16:10:23 - TARGET_ARCH=i386 TB --- 2013-03-02 16:10:23 - TZ=UTC TB --- 2013-03-02 16:10:23 - __MAKE_CONF=/dev/null TB --- 2013-03-02 16:10:23 - cd /src TB --- 2013-03-02 16:10:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 2 16:10:28 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Mar 2 18:55:38 UTC 2013 TB --- 2013-03-02 18:55:38 - generating LINT kernel config TB --- 2013-03-02 18:55:38 - cd /src/sys/i386/conf TB --- 2013-03-02 18:55:38 - /usr/bin/make -B LINT TB --- 2013-03-02 18:55:38 - cd /src/sys/i386/conf TB --- 2013-03-02 18:55:38 - /usr/sbin/config -m LINT TB --- 2013-03-02 18:55:38 - building LINT kernel TB --- 2013-03-02 18:55:38 - CROSS_BUILD_TESTING=YES TB --- 2013-03-02 18:55:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-02 18:55:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-02 18:55:38 - SRCCONF=/dev/null TB --- 2013-03-02 18:55:38 - TARGET=i386 TB --- 2013-03-02 18:55:38 - TARGET_ARCH=i386 TB --- 2013-03-02 18:55:38 - TZ=UTC TB --- 2013-03-02 18:55:38 - __MAKE_CONF=/dev/null TB --- 2013-03-02 18:55:38 - cd /src TB --- 2013-03-02 18:55:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 2 18:55:38 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Mar 2 19:26:40 UTC 2013 TB --- 2013-03-02 19:26:40 - cd /src/sys/i386/conf TB --- 2013-03-02 19:26:40 - /usr/sbin/config -m LINT-NOINET TB --- 2013-03-02 19:26:40 - building LINT-NOINET kernel TB --- 2013-03-02 19:26:40 - CROSS_BUILD_TESTING=YES TB --- 2013-03-02 19:26:40 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-02 19:26:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-02 19:26:40 - SRCCONF=/dev/null TB --- 2013-03-02 19:26:40 - TARGET=i386 TB --- 2013-03-02 19:26:40 - TARGET_ARCH=i386 TB --- 2013-03-02 19:26:40 - TZ=UTC TB --- 2013-03-02 19:26:40 - __MAKE_CONF=/dev/null TB --- 2013-03-02 19:26:40 - cd /src TB --- 2013-03-02 19:26:40 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Sat Mar 2 19:26:40 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Sat Mar 2 19:55:37 UTC 2013 TB --- 2013-03-02 19:55:37 - cd /src/sys/i386/conf TB --- 2013-03-02 19:55:37 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-03-02 19:55:37 - building LINT-NOINET6 kernel TB --- 2013-03-02 19:55:37 - CROSS_BUILD_TESTING=YES TB --- 2013-03-02 19:55:37 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-02 19:55:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-02 19:55:37 - SRCCONF=/dev/null TB --- 2013-03-02 19:55:37 - TARGET=i386 TB --- 2013-03-02 19:55:37 - TARGET_ARCH=i386 TB --- 2013-03-02 19:55:37 - TZ=UTC TB --- 2013-03-02 19:55:37 - __MAKE_CONF=/dev/null TB --- 2013-03-02 19:55:37 - cd /src TB --- 2013-03-02 19:55:37 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Sat Mar 2 19:55:38 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Sat Mar 2 20:24:56 UTC 2013 TB --- 2013-03-02 20:24:56 - cd /src/sys/i386/conf TB --- 2013-03-02 20:24:56 - /usr/sbin/config -m LINT-NOIP TB --- 2013-03-02 20:24:56 - building LINT-NOIP kernel TB --- 2013-03-02 20:24:56 - CROSS_BUILD_TESTING=YES TB --- 2013-03-02 20:24:56 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-02 20:24:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-02 20:24:56 - SRCCONF=/dev/null TB --- 2013-03-02 20:24:56 - TARGET=i386 TB --- 2013-03-02 20:24:56 - TARGET_ARCH=i386 TB --- 2013-03-02 20:24:56 - TZ=UTC TB --- 2013-03-02 20:24:56 - __MAKE_CONF=/dev/null TB --- 2013-03-02 20:24:56 - cd /src TB --- 2013-03-02 20:24:56 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Sat Mar 2 20:24:56 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Sat Mar 2 20:52:38 UTC 2013 TB --- 2013-03-02 20:52:38 - cd /src/sys/i386/conf TB --- 2013-03-02 20:52:38 - /usr/sbin/config -m LINT-VIMAGE TB --- 2013-03-02 20:52:38 - building LINT-VIMAGE kernel TB --- 2013-03-02 20:52:38 - CROSS_BUILD_TESTING=YES TB --- 2013-03-02 20:52:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-02 20:52:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-02 20:52:38 - SRCCONF=/dev/null TB --- 2013-03-02 20:52:38 - TARGET=i386 TB --- 2013-03-02 20:52:38 - TARGET_ARCH=i386 TB --- 2013-03-02 20:52:38 - TZ=UTC TB --- 2013-03-02 20:52:38 - __MAKE_CONF=/dev/null TB --- 2013-03-02 20:52:38 - cd /src TB --- 2013-03-02 20:52:38 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Sat Mar 2 20:52:38 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Sat Mar 2 21:22:39 UTC 2013 TB --- 2013-03-02 21:22:39 - cd /src/sys/i386/conf TB --- 2013-03-02 21:22:39 - /usr/sbin/config -m GENERIC TB --- 2013-03-02 21:22:39 - building GENERIC kernel TB --- 2013-03-02 21:22:39 - CROSS_BUILD_TESTING=YES TB --- 2013-03-02 21:22:39 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-02 21:22:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-02 21:22:39 - SRCCONF=/dev/null TB --- 2013-03-02 21:22:39 - TARGET=i386 TB --- 2013-03-02 21:22:39 - TARGET_ARCH=i386 TB --- 2013-03-02 21:22:39 - TZ=UTC TB --- 2013-03-02 21:22:39 - __MAKE_CONF=/dev/null TB --- 2013-03-02 21:22:39 - cd /src TB --- 2013-03-02 21:22:39 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Mar 2 21:22:39 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sat Mar 2 21:51:04 UTC 2013 TB --- 2013-03-02 21:51:04 - cd /src/sys/i386/conf TB --- 2013-03-02 21:51:04 - /usr/sbin/config -m PAE TB --- 2013-03-02 21:51:04 - building PAE kernel TB --- 2013-03-02 21:51:04 - CROSS_BUILD_TESTING=YES TB --- 2013-03-02 21:51:04 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-02 21:51:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-02 21:51:04 - SRCCONF=/dev/null TB --- 2013-03-02 21:51:04 - TARGET=i386 TB --- 2013-03-02 21:51:04 - TARGET_ARCH=i386 TB --- 2013-03-02 21:51:04 - TZ=UTC TB --- 2013-03-02 21:51:04 - __MAKE_CONF=/dev/null TB --- 2013-03-02 21:51:04 - cd /src TB --- 2013-03-02 21:51:04 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sat Mar 2 21:51:04 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Sat Mar 2 22:00:03 UTC 2013 TB --- 2013-03-02 22:00:03 - cd /src/sys/i386/conf TB --- 2013-03-02 22:00:03 - /usr/sbin/config -m XBOX TB --- 2013-03-02 22:00:03 - building XBOX kernel TB --- 2013-03-02 22:00:03 - CROSS_BUILD_TESTING=YES TB --- 2013-03-02 22:00:03 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-02 22:00:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-02 22:00:03 - SRCCONF=/dev/null TB --- 2013-03-02 22:00:03 - TARGET=i386 TB --- 2013-03-02 22:00:03 - TARGET_ARCH=i386 TB --- 2013-03-02 22:00:03 - TZ=UTC TB --- 2013-03-02 22:00:03 - __MAKE_CONF=/dev/null TB --- 2013-03-02 22:00:03 - cd /src TB --- 2013-03-02 22:00:03 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Sat Mar 2 22:00:03 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Sat Mar 2 22:03:05 UTC 2013 TB --- 2013-03-02 22:03:05 - cd /src/sys/i386/conf TB --- 2013-03-02 22:03:05 - /usr/sbin/config -m XEN TB --- 2013-03-02 22:03:05 - building XEN kernel TB --- 2013-03-02 22:03:05 - CROSS_BUILD_TESTING=YES TB --- 2013-03-02 22:03:05 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-02 22:03:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-02 22:03:05 - SRCCONF=/dev/null TB --- 2013-03-02 22:03:05 - TARGET=i386 TB --- 2013-03-02 22:03:05 - TARGET_ARCH=i386 TB --- 2013-03-02 22:03:05 - TZ=UTC TB --- 2013-03-02 22:03:05 - __MAKE_CONF=/dev/null TB --- 2013-03-02 22:03:05 - cd /src TB --- 2013-03-02 22:03:05 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Sat Mar 2 22:03:05 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/i386/xen/pmap.c:2244:36: error: no member named 'pv_list' in 'struct pv_entry' TAILQ_REMOVE(&pvh->pv_list, pv, pv_list); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~ /src/sys/sys/queue.h:615:29: note: expanded from macro 'TAILQ_REMOVE' (head)->tqh_last = (elm)->field.tqe_prev; \ ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. *** [pmap.o] Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-02 22:08:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-02 22:08:40 - ERROR: failed to build XEN kernel TB --- 2013-03-02 22:08:40 - 16888.56 user 2855.30 system 21501.81 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Mar 2 23:14:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 71D18B19 for ; Sat, 2 Mar 2013 23:14:40 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by mx1.freebsd.org (Postfix) with ESMTP id EFB5989D for ; Sat, 2 Mar 2013 23:14:39 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id e49so3214157eek.33 for ; Sat, 02 Mar 2013 15:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=MY28nyEEpbA82BklOGe0VHBVW9P92CDPf/UJakErwwA=; b=Vp/XluH2kc87hBL/+n9ZulkqJzWdRzxNArlIcIlp89iJ2uqPuRfzkBLpAtD6RW8KE3 lGnS93hOpaKqse4MDBsaL/0zXT97Y1OQV4GxsThAsXyGHaERID9OhPAoZA3nkpVxU/OV EltgrB9Hk8Th/Dj82lHZKApzArQWYI+QJrmJ5krZ7BXKb6cnRAmlAuXkDIo2BZDFQgu+ IP2Po4xLsBrK7GGB0Nv+4hEiwZPT+c3V95o2+CY61PojMTXqYc4nOOt+L4FmPXcoE84t 5fsfo/uuj8S+5IPm9b4DofeOZU2crIPw9yLiLzmqyLbautiBGRjoknkN7Uwi5tfi9siW aK7Q== X-Received: by 10.14.193.134 with SMTP id k6mr42523371een.37.1362265642198; Sat, 02 Mar 2013 15:07:22 -0800 (PST) Received: from [192.168.1.80] (1F2E5890.dsl.pool.telekom.hu. [31.46.88.144]) by mx.google.com with ESMTPS id m46sm24285284eeo.16.2013.03.02.15.07.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Mar 2013 15:07:21 -0800 (PST) Message-ID: <51328622.10409@gmail.com> Date: Sun, 03 Mar 2013 00:07:14 +0100 From: deeptech71 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:18.0) Gecko/20100101 SeaMonkey/2.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: access to hard drives is "blocked" by writes to a flash drive References: <51323712.5000406@gmail.com> <42B72A5B-A363-426B-9F6C-7F8B3B7E7543@FreeBSD.org> In-Reply-To: <42B72A5B-A363-426B-9F6C-7F8B3B7E7543@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 23:14:40 -0000 On 03/02/2013 21:46, Edward Tomasz Napierała wrote: > Wiadomość napisana przez deeptech71 w dniu 2 mar 2013, o godz. 18:29: >> When one of my flash drives is being heavily written to; typically by ``svn update'' on /usr/src, located on the flash drive; the following can be said about filesystem behavior: >> >> - ``svn update'' seems to be able to quickly update a bunch of files, but is then unable to continue for a period of time. This behavior is cyclical, and cycles several times, depending on the amount of updating work to be done for a particular run of ``svn update''. >> - Access to any filesystem, whether on the said flash drive or not, seems to be hindered a lot, typically during the said "unable to continue" time. Reading of a file on a hard drive was once delayed for more than 10 seconds. Seemingly as a consequence, the starting of top(1) is also typically delayed. > > When that happens, could you do "ps axl" and see the WCHAN column > for the affected processes? Is it "wdrain"? What do you mean by "the affected processes"? The MWCHAN of an ``svn update'' contained long "wdrain" periods (but included "getblk", "drainvp", etc.). ``[bufdaemon]'' sometimes seemed to somewhat follow the "wdrain" state of ``svn update''. I've also found out that the inability for top(1) or ps(1) to start immediately has something to do with X -- in the virtual terminals, there was never a delay.