From owner-freebsd-current@FreeBSD.ORG Sun Oct 4 01:47:21 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42A611065672 for ; Sun, 4 Oct 2009 01:47:21 +0000 (UTC) (envelope-from faber@zod.isi.edu) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by mx1.freebsd.org (Postfix) with ESMTP id 2584E8FC0C for ; Sun, 4 Oct 2009 01:47:20 +0000 (UTC) Received: from zod.isi.edu (localhost [127.0.0.1]) by zod.isi.edu (8.14.3/8.14.3) with ESMTP id n941lKGl023112; Sat, 3 Oct 2009 18:47:20 -0700 (PDT) (envelope-from faber@zod.isi.edu) Received: (from faber@localhost) by zod.isi.edu (8.14.3/8.14.3/Submit) id n941lKew023111; Sat, 3 Oct 2009 18:47:20 -0700 (PDT) (envelope-from faber) Date: Sat, 3 Oct 2009 18:47:20 -0700 From: Ted Faber To: Gavin Atkinson Message-ID: <20091004014720.GA23086@zod.isi.edu> References: <20090929041407.GA92280@zod.isi.edu> <20091002213116.GH88191@zod.isi.edu> <20091003142303.L14313@ury.york.ac.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: <20091003142303.L14313@ury.york.ac.uk> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber Cc: freebsd-current@FreeBSD.org Subject: Re: FreeBSD8-RELENG (sources from this morning) deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Oct 2009 01:47:21 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 03, 2009 at 02:24:11PM +0100, Gavin Atkinson wrote: > Do you have options GDB/DDB/KDB in your kernel? On the target but not the debugging host. Do both need it? --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkrH/qgACgkQaUz3f+Zf+XuHzgCgzynlPnhT5SXO0GmZOJE+Y1o9 q3EAoLeMQlDrkYu/RcyeMmPUTgqP35r9 =2HGW -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 4 07:48:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B0D81065670 for ; Sun, 4 Oct 2009 07:48:36 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout7.freenet.de (mout7.freenet.de [IPv6:2001:748:100:40::2:9]) by mx1.freebsd.org (Postfix) with ESMTP id D6C758FC0C for ; Sun, 4 Oct 2009 07:48:35 +0000 (UTC) Received: from [195.4.92.20] (helo=10.mx.freenet.de) by mout7.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1MuLpa-0006Ve-9T; Sun, 04 Oct 2009 09:48:34 +0200 Received: from t98a1.t.pppool.de ([89.55.152.161]:20321 helo=ernst.jennejohn.org) by 10.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1MuLpa-0006Tt-3W; Sun, 04 Oct 2009 09:48:34 +0200 Date: Sun, 4 Oct 2009 09:48:33 +0200 From: Gary Jennejohn To: freebsd-current@freebsd.org, ggajic@afrodita.rcub.bg.ac.rs Message-ID: <20091004094833.2a28c12f@ernst.jennejohn.org> In-Reply-To: References: <54980020@bb.ipt.ru> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Re: 8.0RC1: Can't mount usb stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 07:48:36 -0000 On Sat, 3 Oct 2009 19:01:35 +0200 (CEST) Goran Gajic wrote: > No this one is formated in XP style, so there is no /dev/da0s1. But that > is not the only problem I have noticed. I wanted to take image of USB > stick just in case I might need it, since I did newfs_msdos /dev/da0.. However > during cat /dev/da0 > usb.img read seems to hang.. Also, when I have tried > to put some image (in FreeBSD 8.0RC1) on that same stick, when I did > cat usb_old.img > /dev/da0 same happens - system hangs. When I have tried > same thing under Linux it worked with no problems. > cat is the wrong thing to use for making/copying images. Use dd instead with e.g. conv=sync. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sun Oct 4 12:41:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACEB41065694; Sun, 4 Oct 2009 12:41:31 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 4268A8FC08; Sun, 4 Oct 2009 12:41:30 +0000 (UTC) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id n94CfQiJ008869; Sun, 4 Oct 2009 13:41:26 +0100 (BST) Received: from ury.york.ac.uk ([144.32.108.81]) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MuQP0-0007WG-LX; Sun, 04 Oct 2009 13:41:26 +0100 Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.14.3/8.14.3) with ESMTP id n94CfQb2000255; Sun, 4 Oct 2009 13:41:26 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id n94CfQGs000252; Sun, 4 Oct 2009 13:41:26 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Sun, 4 Oct 2009 13:41:26 +0100 (BST) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Ted Faber In-Reply-To: <20091004014720.GA23086@zod.isi.edu> Message-ID: <20091004133702.L14313@ury.york.ac.uk> References: <20090929041407.GA92280@zod.isi.edu> <20091002213116.GH88191@zod.isi.edu> <20091003142303.L14313@ury.york.ac.uk> <20091004014720.GA23086@zod.isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: Gavin Atkinson , freebsd-current@freebsd.org Subject: Re: FreeBSD8-RELENG (sources from this morning) deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Oct 2009 12:41:31 -0000 On Sat, 3 Oct 2009, Ted Faber wrote: > On Sat, Oct 03, 2009 at 02:24:11PM +0100, Gavin Atkinson wrote: >> Do you have options GDB/DDB/KDB in your kernel? > > On the target but not the debugging host. Do both need it? No, just the target should be fine. Last time I needed to do anything like this, I just followed the instructions at http://wiki.freebsd.org/DebugWithDcons and it worked fine. I'm guessing that's the article you also followed? Sorry I can't help more! Gavin From owner-freebsd-current@FreeBSD.ORG Sun Oct 4 13:50:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8B831065676 for ; Sun, 4 Oct 2009 13:50:05 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id 589138FC1E for ; Sun, 4 Oct 2009 13:50:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 08A041074E for ; Sun, 4 Oct 2009 22:50:04 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost ([127.0.0.1]) by localhost (basalt.tackymt.homeip.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPdMoWTbTDI7 for ; Sun, 4 Oct 2009 22:50:01 +0900 (JST) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by basalt.tackymt.homeip.net (Postfix) with ESMTP for ; Sun, 4 Oct 2009 22:50:01 +0900 (JST) Date: Sun, 4 Oct 2009 22:50:00 +0900 From: Taku YAMAMOTO To: freebsd-current@freebsd.org Message-Id: <20091004225000.6a1a6262.taku@tackymt.homeip.net> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.16.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: pam_ssh no longer works after r197679 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Oct 2009 13:50:05 -0000 Greetings, After the upgrade to OpenSSH 5.3p1 in r197679, pam_ssh doesn't seem to work any longer. In /var/log/messages: Oct 4 10:39:09 basalt xdm: in openpam_load_module(): no pam_ssh.so found # I use pam_ssh for graphical login. A quick investigation revailed that libssh.so.5 had some symbols undefined, which prevented pam_ssh.so.5 from being loaded. # FYI: openpam dlopen()s modules with RTLD_NOW. Here's interesting bits from nm -D /usr/lib/libssh.so.5 | fgrep U U roaming_read U roaming_write Virtually yours, -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From owner-freebsd-current@FreeBSD.ORG Sun Oct 4 13:58:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F8C11065670 for ; Sun, 4 Oct 2009 13:58:19 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id B7E488FC08 for ; Sun, 4 Oct 2009 13:58:18 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1MuRbN-000ERC-EZ for freebsd-current@freebsd.org; Sun, 04 Oct 2009 15:58:17 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Oct 2009 15:58:17 +0200 From: Daniel Braniss Message-ID: Subject: 8.0RC1 and BOOTP_NFSV3 regression? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Oct 2009 13:58:19 -0000 I'm not sure when this happened, but a kernel compiled with BOOTP_NFSV3 fails when the server is not FreeBSD (ie NetAPP). before, with the option set, only when kernel_options="nfsv3" was set it would fail/panic, this way, I could control which diskless, shearing the same kernel, would boot with nfsv3 and which not, dependig on the server. there is hope! before it would panic when receiving a v3 file handle, now it fails, but panics later when no init is found :-) is anyone with enough nfs v2/v3 knowledge willing to fix this? cheers, danny From owner-freebsd-current@FreeBSD.ORG Sun Oct 4 14:44:59 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDECE1065670; Sun, 4 Oct 2009 14:44:58 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.rulez.sk (services.rulez.sk [92.240.234.125]) by mx1.freebsd.org (Postfix) with ESMTP id 87BB28FC1C; Sun, 4 Oct 2009 14:44:58 +0000 (UTC) Received: from localhost (services.rulez.sk [92.240.234.125]) by services.rulez.sk (Postfix) with ESMTP id C2CBB13345FC; Sun, 4 Oct 2009 16:44:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.rulez.sk ([92.240.234.125]) by localhost (services.rulez.sk [92.240.234.125]) (amavisd-new, port 10024) with ESMTP id 3KtaBh01K0EX; Sun, 4 Oct 2009 16:44:56 +0200 (CEST) Received: from [10.50.0.2] (danger.mcrn.sk [84.16.37.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.rulez.sk (Postfix) with ESMTPSA id DB194133453E; Sun, 4 Oct 2009 16:44:56 +0200 (CEST) Message-ID: <4AC8B4E8.7080106@FreeBSD.org> Date: Sun, 04 Oct 2009 16:44:56 +0200 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: current@freebsd.org, hackers@freebsd.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: [Fwd: HEADSUP: Call for FreeBSD Status Reports] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Oct 2009 14:44:59 -0000 Hello guys, I would like to remind you about the FreeBSD Status Reports. The deadline is set to October 7th, and to date I have received only 5 reports, which is very little (considering the fact we are now covering almost 6 months). If you think you have anything to share with the community through the status report entry, please email us at monthly@freebsd.org as soon as possible. It really doesn't have to be a whole article, just a few lines about what you are working on. Thank you! -------- Original Message -------- Subject: HEADSUP: Call for FreeBSD Status Reports Date: Thu, 24 Sep 2009 17:07:29 +0200 From: Daniel Gerzo Organization: The FreeBSD Project To: current@freebsd.org, hackers@freebsd.org, stable@freebsd.org Dear all, I would like to remind you to submit your status reports as soon as possible. Long time has passed since the last status reports were released; and surely a lot has had happened since then. Our developers are relaxed after DevSummit and EuroBSDCon in Cambridge, which both were great! I believe a lot of stuff has been discussed during these events (I hope we will have reports covering this too) and since the last report a lot of things have happened. During that time, two other conferences have been held (BSDCan and AsiaBSDCon), we have released 7.2, not to mention that 8.0 is behind the door. Google Summer of Code should be finished by now too, and we would like to hear about its results. Surely there are a lot more projects which are currently being worked on, so please do not hesitate and write us a few lines - a short description about what you are working on, what are the plans and goals, so we can inform our community about your great work! It's useful for you as well as our users! Please note, the submissions for this quarter (well...rather halfyear, because we should now cover 4-9/2009) are due by October 7th, 2009. Please post the filled-in XML template to be found at http://www.freebsd.org/news/status/report-sample.xml to monthly@FreeBSD.org, or alternatively use our web based form at http://www.freebsd.org/cgi/monthly.cgi. We are looking forward to see your submissions! -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Sun Oct 4 15:14:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58D6D1065676; Sun, 4 Oct 2009 15:14:06 +0000 (UTC) (envelope-from vinnix.bsd@gmail.com) Received: from mail-pz0-f201.google.com (mail-pz0-f201.google.com [209.85.222.201]) by mx1.freebsd.org (Postfix) with ESMTP id 1EC018FC56; Sun, 4 Oct 2009 15:14:06 +0000 (UTC) Received: by pzk39 with SMTP id 39so365948pzk.15 for ; Sun, 04 Oct 2009 08:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=H+BPl6cMVcDBTgiPO46NrVG9ef5xZSixhCZt+/Ylmv4=; b=uicsga0lEidJiIt3Zj6AXvWMCv1EGNvjkFwsE1njfVuti/8payn1GzJ2zPF0CE4HPf 474/ZvNSbHHJ83r5dF4B2YaPZolxyGaJFXsPa1V6Np1/9zEgvXSCZx18SAkpUOV4+/Fj nU2/w5L5CKsW9ZwBZ8AzAYX9KUN8/TKHUypZ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JwS24sq/ugcjf2DRHztZOm/h/bhOMu8+nVlpFB5lc4DdfZKzhen+h4MCYNfzd99q4s jldkUSLpl4a0DCR99rvKrB3j6VkyLfYTRCqx399vD7ojYeAu10mKm8UDh/TEzLN6F/Fu bF5wpIiKFmztW01M7rBNpDMrwmY9uS1/tIZ4I= MIME-Version: 1.0 Received: by 10.140.157.5 with SMTP id f5mr841109rve.242.1254669244502; Sun, 04 Oct 2009 08:14:04 -0700 (PDT) In-Reply-To: <200909131508.05025.hselasky@c2i.net> References: <20090908201713.GD41185@e.0x20.net> <1e31c7980909130516g1b3cb9fn5df77c23ec072413@mail.gmail.com> <200909131508.05025.hselasky@c2i.net> Date: Sun, 4 Oct 2009 12:14:04 -0300 Message-ID: <1e31c7980910040814o48a1a57bgde86571fa3265c4c@mail.gmail.com> From: Vinicius Abrahao To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: luigi@freebsd.org, freebsd-current , lars.engels@0x20.net, freebsd-usb@freebsd.org, Florent Thoumie Subject: Re: CFH: fix multimedia/pwcbsd with usb2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Oct 2009 15:14:06 -0000 Hi Hans, Thanks for your help! I try to do exactly what you say, but without success= . When I attach my camera I see at dmesg: ugen2.3: at usbus2 Trying pwcview: #./pwcview -d /dev/ugen2.3 Failed to access webcam: Operation not supported by device *********************************************************** Make sure you have connected your webcam to the root hub or to a USB 1.1 hub, also check your dmesg for any errors. *********************************************************** What I'm doing wrong? Thanks again, Best regards, Vin=EDcius On 9/13/09, Hans Petter Selasky wrote: > On Sunday 13 September 2009 14:16:10 Vinicius Abrahao wrote: >> Thanks Florent, >> >> That's it for sure. I recompile my kernel yesterday and now pwcbsd is >> loading normally. >> Therefore, now I see that pwc is the wrong driver for me. My webcam is >> a Philips SPC500NC. >> ID 093a:2603 Pixart Imaging, Inc. >> >> At Google I found that linux-gspca-kmod is the right driver for me. >> But this seen broken as >> pwcbsd was in the past. > > Hi, > > The closes you will currently get is: > > svn --username anonsvn --password anonsvn \ > checkout svn://svn.turbocat.net/i4b/trunk/usbcam/ulinux > > As root: > > make fetch > make patch > make > > You manually have to patch: > > ee libv4l/v4l2-apps/libv4l/libv4lconvert/control/libv4lcontrol.c > > control/libv4lcontrol.c: In function 'v4lcontrol_vidioc_queryctrl': > control/libv4lcontrol.c:586: error: '__u32' undeclared (first use in this > function) > control/libv4lcontrol.c:586: error: (Each undeclared identifier is report= ed > only once > control/libv4lcontrol.c:586: error: for each function it appears in.) > control/libv4lcontrol.c:586: error: expected ';' before 'orig_id' > control/libv4lcontrol.c:600: error: 'orig_id' undeclared (first use in th= is > function) > > __u32 to uint32_t > > In the end: > > cd pwcview > > ./pwcview > > > Should bring your webcam right up in userland though. > > --HPS > > From owner-freebsd-current@FreeBSD.ORG Sun Oct 4 15:15:16 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC1201065672 for ; Sun, 4 Oct 2009 15:15:16 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from mail-qy0-f192.google.com (mail-qy0-f192.google.com [209.85.221.192]) by mx1.freebsd.org (Postfix) with ESMTP id 784B98FC62 for ; Sun, 4 Oct 2009 15:15:16 +0000 (UTC) Received: by qyk30 with SMTP id 30so2682203qyk.7 for ; Sun, 04 Oct 2009 08:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=qm2y3mHLM7N1cCU2u4J+9W8uALrZNM+6Rz5JY+uPrhQ=; b=Vz3YfufyvBXINGK956sYVDyM9ES3epAV9lpXXQAvylnwcq6CMgl+LZzPHffUPJtFim cj2iDf1qry7Lf+CDUmr0zjyxwLBR7NF7N7YwPL6Y8MmfnA4K/UV8F37GFYiSDdtojLCB 3a6UCWprAQCf4Oa0iJmpF45H8zggXjvFZfsn8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=s5iAfZV2ro6L1lbEc+n6S4B68+2LlDiuLVa40o6JcQek5wsEl/l7hq0UnwvGjm1Dw0 NHY98vTc1WIFGThQ1jFx6QerFvOJMeJdoNWVgSc0CzXALVxNVTiXbjFX2id0lGkJL7nq oe1HfyHwEATZOGcwNMwXicZ9rKV+aTbZ5p2xI= MIME-Version: 1.0 Received: by 10.229.36.195 with SMTP id u3mr3570642qcd.61.1254669315833; Sun, 04 Oct 2009 08:15:15 -0700 (PDT) In-Reply-To: <20091003014251.GI1454@weongyo> References: <90a5caac0907120353k69fb4f23q5e2f0eff35cfa2c5@mail.gmail.com> <20091003014251.GI1454@weongyo> Date: Sun, 4 Oct 2009 17:15:15 +0200 Message-ID: <90a5caac0910040815l1f8a4d8dj3352568227c3c386@mail.gmail.com> From: Lucius Windschuh To: Weongyo Jeong , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: uath0 issues: eject-caused panic, won't work after a restart. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Oct 2009 15:15:16 -0000 Hi. 2009/10/3 Weongyo Jeong : > On Sun, Jul 12, 2009 at 12:53:38PM +0200, Lucius Windschuh wrote: >> Hi guys, >> I'm using CURRENT r195362MP and have two issues with it. >> >> 1st: Pulling the device while the kernel was nearly finished shutting >> down shutting down resulted in a kernel panic: >> > [...] > Already passed about 3 months. =A0:-) > > Could you please test with CURRENT to reproduce this problem? =A0On my > environment it doesn't happen anymore. =A0I'd like to know this issue is > still valid. I can't reproduce this problem either. It seems that this problem is fixed: Pulling the device out in different stages of the shutdown process did not result in a panic. Fine, when time destroys bugs. :-D >> 2nd issue: >> >> With an plugged and firmware-loaded uath device (TRENDnet TEW-504UB in >> my case), reboot the system. It is not initialized by uath until you >> pull and plug it back in. >> The USB descriptors, obtained by usbconfig dump_device_desc, are the >> same before pulling and after reinitializing the device. >> >> Is there anything I can do to help fixing these issues? > > I tried to solve this issue on my amd64 machine but could not find a way > to fix. =A0It looks HAL interface doesn't have a API to reset full H/W an= d > endpoint 0 also don't have a such feature. =A0Only a way looks a bus rese= t > event (EHCI_STS_RESET) currently depending on the system for example, > powerpc I have seems it hasn't this problem but amd64 has. If a bus reset only affects the device and not a whole bus, this is worth a= try. Regards Lucius From owner-freebsd-current@FreeBSD.ORG Sun Oct 4 15:33:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36B18106568B for ; Sun, 4 Oct 2009 15:33:53 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id A21F88FC36 for ; Sun, 4 Oct 2009 15:33:52 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id n94FDP4D037655 ; Sun, 4 Oct 2009 17:13:25 +0200 (CEST) X-Ids: 164 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id n94FDOCk082476; Sun, 4 Oct 2009 17:13:24 +0200 (CEST) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id n94FDOUQ082473; Sun, 4 Oct 2009 17:13:24 +0200 (CEST) (envelope-from arno) To: Dmitry Marakasov From: "Arno J. Klaassen" References: <20090123221826.GB30982@deprived.panopticon> <20090126144044.GB6054@hades.panopticon> <20090127164617.GA93440@hades.panopticon> <20090128042148.GA1256@hades.panopticon> <20090814021340.GA1275@hades.panopticon> Date: Sun, 04 Oct 2009 17:13:23 +0200 In-Reply-To: <20090814021340.GA1275@hades.panopticon> (Dmitry Marakasov's message of "Fri\, 14 Aug 2009 06\:13\:40 +0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.94.2/9866/Sat Oct 3 16:49:15 2009 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail2.jussieu.fr with ID 4AC8BB95.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4AC8BB95.001/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: freebsd-current@freebsd.org Subject: Re: Data corruption with checksum offloading enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Oct 2009 15:33:53 -0000 Hello, Dmitry Marakasov writes: > * Dmitry Marakasov (amdmi3@amdmi3.ru) wrote: > >> 3. 512MB random bytes with NFS: 2/5 correct > > Just for the record: this no longer seems to be a problem. Recent > 8-STABLE, ale works fine with rxcsum/txcsum, at least I could not > reproduce the problem with similar tests as before. bon, I upgraded the box with this problem to *7*-STABLE this weekend, and no luck, the problem still persists. To refresh memory, nfs-client has data corrupt in a particular way : - just one byte (per file) in my case, a single 128 byte block for Dimitry - independent of network driver and NFS-[options|client versions] - seems nfs-limited (netcat file transfers work OK (zero-only nfs as well)) - disabling checksum offloading at least makes it much harder to provoke (cann't remembre whether everyone confirmed this) - disabling cpufreq makes it impossible to provoke (at least for me) So far the bad news, the better news is that I cannot reproduce this problem on a similar setup running *8*-STABLE indeed. The 7-STABLE box is in production, but involved in some maintenaince/upgrade-shuffle I am responsable for, I will try to let it at least boot a 8-kernel and 7-world sometime next week and see if I can still reproduce the problem. Best, Arno From owner-freebsd-current@FreeBSD.ORG Sun Oct 4 16:26:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7F2E106566B; Sun, 4 Oct 2009 16:26:14 +0000 (UTC) (envelope-from vinnix.bsd@gmail.com) Received: from mail-px0-f192.google.com (mail-px0-f192.google.com [209.85.216.192]) by mx1.freebsd.org (Postfix) with ESMTP id 8BD598FC18; Sun, 4 Oct 2009 16:26:14 +0000 (UTC) Received: by pxi30 with SMTP id 30so3492734pxi.7 for ; Sun, 04 Oct 2009 09:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zW2Ad4nKDwC6og3v6NiaeLeVJyHjHG+7kccTlqLcnOo=; b=qqMGjlxf934gUCE64Wh4EgOBs/ntMTwZ23ntbAKwPZLwQSrpD5+wlJo+D5nmsilmW7 U7S0KT40fgsHCKRjM14ZPemKDHahyEWGIzYrzGuxpJryJJiYEu6y2chIVIiHWy+Df3So Dxq/K1ugdcXj91bWf1+JMx2OTsFNqjDgtoPcI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FUPCt75p5eAjXnuCBtIJv+PlXSgNJy2IB6srPJJmoCxV37RXfSauVBjk0LgeFA5vXx SoGz0fqxVyAJWtAPMw3EbQ3w9UlL79c5SQxqp3oMBWqhq5AvQjqHvYDVJ/gR6n8H5YpX FeBRPNP9+iEd5VURDaj6tlv6YdWpVLs11Eh6M= MIME-Version: 1.0 Received: by 10.140.136.5 with SMTP id j5mr136238rvd.0.1254673573286; Sun, 04 Oct 2009 09:26:13 -0700 (PDT) In-Reply-To: <1e31c7980910040814o48a1a57bgde86571fa3265c4c@mail.gmail.com> References: <20090908201713.GD41185@e.0x20.net> <1e31c7980909130516g1b3cb9fn5df77c23ec072413@mail.gmail.com> <200909131508.05025.hselasky@c2i.net> <1e31c7980910040814o48a1a57bgde86571fa3265c4c@mail.gmail.com> Date: Sun, 4 Oct 2009 13:26:13 -0300 Message-ID: <1e31c7980910040926s35b01c5dn3e31d6b1509d1c76@mail.gmail.com> From: Vinicius Abrahao To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: luigi@freebsd.org, freebsd-current , lars.engels@0x20.net, freebsd-usb@freebsd.org, Florent Thoumie Subject: Re: CFH: fix multimedia/pwcbsd with usb2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Oct 2009 16:26:15 -0000 Trying multimedia/pwcbwd-1.4.1_6 I added a line at multimedia/pwcbsd/work/pwcbsd/pwc.c # diff pwc.c /root/pwc.c --normal 94a95 > {USB_VPI(0x093a, 0x2603, 720)}, /* Philips SPC500NC */ But the problem now is that pwcview don't recognize and "operation" mode for this camera. I try setting 720, but I'll try with others. # /usr/local/bin/pwcview Failed to access webcam: Not a directory *********************************************************** Make sure you have connected your webcam to the root hub or to a USB 1.1 hub, also check your dmesg for any errors. *********************************************************** At /var/log/messages: vinnix kernel: pwc0: Failed to set video mode to SIF@10 fps; return code = =3D 20 vinnix kernel: pwc0: Failed to set video mode to QSIF@10 fps; return code = =3D 20 Thanks, Vin=EDcius On 10/4/09, Vinicius Abrahao wrote: > Hi Hans, > > Thanks for your help! I try to do exactly what you say, but without > success. > When I attach my camera I see at dmesg: > ugen2.3: at usbus2 > > Trying pwcview: > > #./pwcview -d /dev/ugen2.3 > Failed to access webcam: Operation not supported by device > *********************************************************** > Make sure you have connected your webcam to the root hub > or to a USB 1.1 hub, also check your dmesg for any errors. > *********************************************************** > > > What I'm doing wrong? > > Thanks again, > Best regards, > Vin=EDcius > > On 9/13/09, Hans Petter Selasky wrote: >> On Sunday 13 September 2009 14:16:10 Vinicius Abrahao wrote: >>> Thanks Florent, >>> >>> That's it for sure. I recompile my kernel yesterday and now pwcbsd is >>> loading normally. >>> Therefore, now I see that pwc is the wrong driver for me. My webcam is >>> a Philips SPC500NC. >>> ID 093a:2603 Pixart Imaging, Inc. >>> >>> At Google I found that linux-gspca-kmod is the right driver for me. >>> But this seen broken as >>> pwcbsd was in the past. >> >> Hi, >> >> The closes you will currently get is: >> >> svn --username anonsvn --password anonsvn \ >> checkout svn://svn.turbocat.net/i4b/trunk/usbcam/ulinux >> >> As root: >> >> make fetch >> make patch >> make >> >> You manually have to patch: >> >> ee libv4l/v4l2-apps/libv4l/libv4lconvert/control/libv4lcontrol.c >> >> control/libv4lcontrol.c: In function 'v4lcontrol_vidioc_queryctrl': >> control/libv4lcontrol.c:586: error: '__u32' undeclared (first use in thi= s >> function) >> control/libv4lcontrol.c:586: error: (Each undeclared identifier is >> reported >> only once >> control/libv4lcontrol.c:586: error: for each function it appears in.) >> control/libv4lcontrol.c:586: error: expected ';' before 'orig_id' >> control/libv4lcontrol.c:600: error: 'orig_id' undeclared (first use in >> this >> function) >> >> __u32 to uint32_t >> >> In the end: >> >> cd pwcview >> >> ./pwcview >> >> >> Should bring your webcam right up in userland though. >> >> --HPS >> >> > From owner-freebsd-current@FreeBSD.ORG Sun Oct 4 16:52:20 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 314ED1065670; Sun, 4 Oct 2009 16:52:20 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id BFA988FC12; Sun, 4 Oct 2009 16:52:19 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n94GqIh2075909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Oct 2009 18:52:18 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n94GqIpX075908; Sun, 4 Oct 2009 18:52:18 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Sun, 4 Oct 2009 18:52:18 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Dag-Erling Smorgrav , current@freebsd.org Message-ID: <20091004165217.GS69612@acme.spoerlein.net> Mail-Followup-To: Dag-Erling Smorgrav , current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Update to OpenSSH 5.3p1 broke pam_ssh.so ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Oct 2009 16:52:20 -0000 Hi Dag-Erling, is it possible, that the recent update causes my -CURRENT box to no longer allow for pam_ssh.so references in /etc/pam.d/{login,sshd}? I usually use auth sufficient pam_ssh.so no_warn try_first_pass session optional pam_ssh.so want_agent which results in the login aborting/breaking with strange pam_ssh errors. Could someone try this, not sure if I messed something up at my end, though the config has not changed in years. Regards, Uli From owner-freebsd-current@FreeBSD.ORG Sun Oct 4 17:20:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A811106566B; Sun, 4 Oct 2009 17:20:08 +0000 (UTC) (envelope-from faber@zod.isi.edu) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by mx1.freebsd.org (Postfix) with ESMTP id DF6C68FC17; Sun, 4 Oct 2009 17:20:07 +0000 (UTC) Received: from zod.isi.edu (localhost [127.0.0.1]) by zod.isi.edu (8.14.3/8.14.3) with ESMTP id n94HK7DF028947; Sun, 4 Oct 2009 10:20:07 -0700 (PDT) (envelope-from faber@zod.isi.edu) Received: (from faber@localhost) by zod.isi.edu (8.14.3/8.14.3/Submit) id n94HK6al028946; Sun, 4 Oct 2009 10:20:06 -0700 (PDT) (envelope-from faber) Date: Sun, 4 Oct 2009 10:20:06 -0700 From: Ted Faber To: Gavin Atkinson Message-ID: <20091004172006.GA28914@zod.isi.edu> References: <20090929041407.GA92280@zod.isi.edu> <20091002213116.GH88191@zod.isi.edu> <20091003142303.L14313@ury.york.ac.uk> <20091004014720.GA23086@zod.isi.edu> <20091004133702.L14313@ury.york.ac.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <20091004133702.L14313@ury.york.ac.uk> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber Cc: Gavin Atkinson , freebsd-current@freebsd.org Subject: Re: FreeBSD8-RELENG (sources from this morning) deadlock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Oct 2009 17:20:08 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 04, 2009 at 01:41:26PM +0100, Gavin Atkinson wrote: > On Sat, 3 Oct 2009, Ted Faber wrote: >=20 > >On Sat, Oct 03, 2009 at 02:24:11PM +0100, Gavin Atkinson wrote: > >>Do you have options GDB/DDB/KDB in your kernel? > > > >On the target but not the debugging host. Do both need it? >=20 > No, just the target should be fine. >=20 > Last time I needed to do anything like this, I just followed the=20 > instructions at http://wiki.freebsd.org/DebugWithDcons and it worked fine= .=20 > I'm guessing that's the article you also followed? That and the examples in the dcons/dconschat man pages, yeah. >=20 > Sorry I can't help more! Thanks for looking at it. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkrI2UYACgkQaUz3f+Zf+XuH7gCg7EYeiyjn4tSrZYYdOyuPqLva IcAAn3HiAsxPYbQlhR5y8ouhoUucnB6w =MW2K -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 4 18:10:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CD25106568D; Sun, 4 Oct 2009 18:10:03 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 3A5268FC17; Sun, 4 Oct 2009 18:10:01 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=uRDWFtAGNAUA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=bvIxxGM5OkfLVrZCnukA:9 a=BHQk4mzU4VyoRCSf6AoToKLvfNUA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1308394159; Sun, 04 Oct 2009 20:10:00 +0200 From: Hans Petter Selasky To: Vinicius Abrahao Date: Sun, 4 Oct 2009 20:10:46 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20090908201713.GD41185@e.0x20.net> <200909131508.05025.hselasky@c2i.net> <1e31c7980910040814o48a1a57bgde86571fa3265c4c@mail.gmail.com> In-Reply-To: <1e31c7980910040814o48a1a57bgde86571fa3265c4c@mail.gmail.com> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910042010.49054.hselasky@c2i.net> Cc: luigi@freebsd.org, freebsd-current , lars.engels@0x20.net, freebsd-usb@freebsd.org, Florent Thoumie Subject: Re: CFH: fix multimedia/pwcbsd with usb2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Oct 2009 18:10:06 -0000 On Sunday 04 October 2009 17:14:04 Vinicius Abrahao wrote: > ./pwcview Try to run without -d /dev/ugenX.Y. Which pwcview did you build? The one from ports or I4B SVN? --HPS From owner-freebsd-current@FreeBSD.ORG Sun Oct 4 19:03:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 233761065858 for ; Sun, 4 Oct 2009 19:03:51 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [92.53.104.116]) by mx1.freebsd.org (Postfix) with ESMTP id D091F8FC1C for ; Sun, 4 Oct 2009 19:03:50 +0000 (UTC) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MuWN1-0002bO-NE; Sun, 04 Oct 2009 15:03:47 -0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 83ACDB84D; Sun, 4 Oct 2009 23:03:47 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id E5E1DB849; Sun, 4 Oct 2009 23:03:47 +0400 (MSD) Date: Sun, 4 Oct 2009 23:03:47 +0400 From: Dmitry Marakasov To: "Arno J. Klaassen" Message-ID: <20091004190347.GC64567@hades.panopticon> References: <20090123221826.GB30982@deprived.panopticon> <20090126144044.GB6054@hades.panopticon> <20090127164617.GA93440@hades.panopticon> <20090128042148.GA1256@hades.panopticon> <20090814021340.GA1275@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: Data corruption with checksum offloading enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Oct 2009 19:03:51 -0000 * Arno J. Klaassen (arno@heho.snv.jussieu.fr) wrote: I had no problems since my previous message, however I've just noticed that rxcsum is disabled by default on 8.x. So this should really be tested after explicitely enabling it with ifconfig +rxcsum. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-current@FreeBSD.ORG Sun Oct 4 19:05:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 985F3106568B for ; Sun, 4 Oct 2009 19:05:31 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 48F938FC20 for ; Sun, 4 Oct 2009 19:05:31 +0000 (UTC) Received: from gate.ipt.ru ([194.62.233.123] helo=h30.sp.ipt.ru) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1MuWOf-0000bD-8V; Sun, 04 Oct 2009 23:05:29 +0400 From: Boris Samorodov To: Goran Gajic References: <54980020@bb.ipt.ru> Date: Sun, 04 Oct 2009 23:05:28 +0400 In-Reply-To: (Goran Gajic's message of "Sat, 3 Oct 2009 19:01:35 +0200 (CEST)") Message-ID: <12071447@h30.sp.ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: 8.0RC1: Can't mount usb stick X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Oct 2009 19:05:31 -0000 (reformatted, please don't top-post) On Sat, 3 Oct 2009 19:01:35 +0200 (CEST) Goran Gajic wrote: > On Fri, 2 Oct 2009, Boris Samorodov wrote: > > On Fri, 2 Oct 2009 10:25:16 +0200 (CEST) Goran Gajic wrote: > > > >> da0 at umass-sim0 bus 0 target 0 lun 0 > >> da0: < USB FLASH DRIVE PMAP> Removable Direct Access SCSI-0 device > >> da0: 40.000MB/s transfers > >> da0: 1968MB (4030464 512 byte sectors: 255H 63S/T 250C) > > > >> # mount -t msdosfs /dev/da0 /mnt > >> mount_msdosfs: /dev/da0: Invalid argument > > > > Take a look at /dev/da0*. MS DOS usually uses partition s1, > > so your command should be: > > ----- > > # mount -t msdosfs /dev/da0s1 /mnt > > ----- > > > No this one is formated in XP style, so there is no /dev/da0s1. But Sorry, I'm unaware of this disk styles. Google seems to not be very helpful. Can you post an URL? > that is not the only problem I have noticed. I wanted to take image > of USB stick just in case I might need it, since I did newfs_msdos > /dev/da0.. However Hm, what was the actual command? I'm not sure if one can newfs a disk but not slice. I would say that at least /dev/ad0a is needed. > during cat /dev/da0 > usb.img read seems to hang.. Also, when I have tried > to put some image (in FreeBSD 8.0RC1) on that same stick, when I did > cat usb_old.img > /dev/da0 same happens - system hangs. When I have > tried same thing under Linux it worked with no problems. Don't know if cat should work but dd should. Can you try one? -- WBR, bsam From owner-freebsd-current@FreeBSD.ORG Sun Oct 4 21:39:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6912A1065670 for ; Sun, 4 Oct 2009 21:39:30 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id ECE248FC12 for ; Sun, 4 Oct 2009 21:39:29 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id n94LdRMp080982 ; Sun, 4 Oct 2009 23:39:27 +0200 (CEST) X-Ids: 164 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id n94LdQ8h086376; Sun, 4 Oct 2009 23:39:26 +0200 (CEST) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id n94LdQcj086373; Sun, 4 Oct 2009 23:39:26 +0200 (CEST) (envelope-from arno) To: Dmitry Marakasov From: "Arno J. Klaassen" References: <20090123221826.GB30982@deprived.panopticon> <20090126144044.GB6054@hades.panopticon> <20090127164617.GA93440@hades.panopticon> <20090128042148.GA1256@hades.panopticon> <20090814021340.GA1275@hades.panopticon> <20091004190347.GC64567@hades.panopticon> Date: Sun, 04 Oct 2009 23:39:26 +0200 In-Reply-To: <20091004190347.GC64567@hades.panopticon> (Dmitry Marakasov's message of "Sun\, 4 Oct 2009 23\:03\:47 +0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.94.2/9866/Sat Oct 3 16:49:15 2009 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail2.jussieu.fr with ID 4AC9160F.005 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4AC9160F.005/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: freebsd-current@freebsd.org Subject: Re: Data corruption with checksum offloading enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Oct 2009 21:39:30 -0000 Hello, Dmitry Marakasov writes: > * Arno J. Klaassen (arno@heho.snv.jussieu.fr) wrote: > > I had no problems since my previous message, however I've just noticed > that rxcsum is disabled by default on 8.x. So this should really be > tested after explicitely enabling it with ifconfig +rxcsum. it is on on my 8-box : [root@siamesetwins ~]# uname -a FreeBSD siamesetwins 8.0-RC1 FreeBSD 8.0-RC1 #0: Sat Oct 3 19:22:51 CEST 2009 toor@siamesetwins:/zfiles/obj/raid1/bsd/8/src/sys/S3992-E amd64 [root@siamesetwins ~]# ifconfig bge0 bge0: flags=8843 metric 0 mtu 1500 options=9b That said, I will test with explicit enabling and disabling ?xcsum on my troublesome box (which is a lab-fileserver, I doubt a bit the performance penalty (though most clients are 100Mbps linux)) Best, Arno From owner-freebsd-current@FreeBSD.ORG Sun Oct 4 22:45:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7F1C1065695 for ; Sun, 4 Oct 2009 22:45:58 +0000 (UTC) (envelope-from michio.jinbo@gmail.com) Received: from mail-pz0-f201.google.com (mail-pz0-f201.google.com [209.85.222.201]) by mx1.freebsd.org (Postfix) with ESMTP id 8A84D8FC1F for ; Sun, 4 Oct 2009 22:45:58 +0000 (UTC) Received: by pzk39 with SMTP id 39so532589pzk.15 for ; Sun, 04 Oct 2009 15:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :in-reply-to:references:message-id:mime-version:content-type :content-transfer-encoding:x-mailer; bh=b9aeIWky1+DsRbtvST8aimruDuHJqmBFSLVCtvL+Alk=; b=pYzhHPckbhzxaQl5yB67rkgQa0PtZmXRqVqYi/GRktm5fye6ar3Jyvrr4WYGnBG8Wr WYAGo17FrjwVVN4QKiGhk65igm85LS3+mbwMm8vw1npL+HahbIudyJ2mvV+7CvgrEXvF DKIpgiIn8MrHeFpPe16/ri6QZbCQap3aeh/vY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:in-reply-to:references:message-id:mime-version :content-type:content-transfer-encoding:x-mailer; b=n9aMoEyqmSeafb+Fyi813kpnnxCj0rQGUCjufYmK5Gju+NkFIG5Xl6elMPD2NP4ATu j/50QnUsoSih42z4dGbB4WWf/6051VHelx+gbGkKetpyznlr7F9TEZYqs5yEi2FPFuEb XJedHhGEYDsCzC+zl5hIo6xk+loPEsWFXonpM= Received: by 10.114.69.13 with SMTP id r13mr7854516waa.16.1254695118164; Sun, 04 Oct 2009 15:25:18 -0700 (PDT) Received: from ?192.168.4.101? (router.jinbo.jp [210.229.61.161]) by mx.google.com with ESMTPS id 23sm2239155pzk.0.2009.10.04.15.25.16 (version=SSLv3 cipher=RC4-MD5); Sun, 04 Oct 2009 15:25:17 -0700 (PDT) Date: Mon, 05 Oct 2009 07:25:18 +0900 From: "Michio \"Karl\" Jinbo" To: freebsd-current@freebsd.org In-Reply-To: <200910041220.n94CKxTH073639@svn.freebsd.org> References: <200910041220.n94CKxTH073639@svn.freebsd.org> Message-Id: <20091005072515.3622.22FF24F1@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.51.07 [ja] Subject: pmap_invalidate_cache_range() panic on Xen Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Oct 2009 22:45:58 -0000 On Sun, 4 Oct 2009 12:20:59 +0000 (UTC) Konstantin Belousov wrote: > Log: > MFC r197663: > As a workaround, for Intel CPUs, do not use CLFLUSH in > pmap_invalidate_cache_range() when self-snoop is apparently not reported > in cpu features. > > Approved by: re (bz, kensmith) I was tested r197663/r197744, but kernel panic again on Citrix Xen Server. using 8.0-RC1 install cd, results are 1. INTEL SU9400+HYPER-V(Windows2008 R2) -> boot OK. 2. AMD Athlon X2 TK-55+HYPER-V(Windows2008 R2) -> boot NG. 3. AMD PhenomII 940BK+Citrix Xen Server -> boot NG. I think INTEL CPUs are no problem, but AMD CPUs appear the problem. So I tested the following patch, kernel boot was successed on recent 9-CURRENT and environment 3. sorry, poor English. --- sys/i386/i386/initcpu.c.original 2009-10-01 21:52:48.000000000 +0900 +++ sys/i386/i386/initcpu.c 2009-10-05 08:29:45.000000000 +0900 @@ -721,7 +721,7 @@ * XXXKIB: (temporary) hack to work around traps generated when * CLFLUSHing APIC registers window. */ - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS)) + if (cpu_vendor_id == CPU_VENDOR_AMD && !(cpu_feature & CPUID_SS)) cpu_feature &= ~CPUID_CLFSH; #if defined(PC98) && !defined(CPU_UPGRADE_HW_CACHE) -- Michio Jinbo From owner-freebsd-current@FreeBSD.ORG Sun Oct 4 23:07:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1B6B1065670; Sun, 4 Oct 2009 23:07:37 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id 33CFA8FC14; Sun, 4 Oct 2009 23:07:37 +0000 (UTC) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n94N7NCa028013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Oct 2009 10:07:24 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1254697644; bh=QKyTuDW+vVGKOf7jSsAtxME/E5bqZo/ubF0mo2Lr0aE=; h=Date:From:To:Cc:Subject:Message-ID:References:Mime-Version: Content-Type:In-Reply-To; b=hSPCPSnK3EDZS2mY6kg1e/GXS+p94EGwKrJAKzfXWWIlp5judv6Bpqv7Nvvp12YML CdcsIMU3/wHNX9Bk0dIKdQuTaJdHvw/QOmZmRmpJYwG8oegczYnf0XgXwe8ZuHrTg9 /dsTLXxfPuQTrTFHEzLA55mVY6Euc2Vjtl5tT8FE= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n94N7NU7001767; Mon, 5 Oct 2009 10:07:23 +1100 (AEDT) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id n94N7KBU001766; Mon, 5 Oct 2009 10:07:20 +1100 (AEDT) (envelope-from john) Date: Mon, 5 Oct 2009 10:07:20 +1100 From: John Marshall To: John Baldwin Message-ID: <20091004230720.GA1086@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: John Baldwin , freebsd-current@freebsd.org, George Mamalakis , Doug Rabson , Rick Macklem References: <4AB27FB6.4010806@eng.auth.gr> <20090921222241.GF1001@rwpc12.mby.riverwillow.net.au> <20091002081319.GN37304@rwpc12.mby.riverwillow.net.au> <200910020824.15488.john@baldwin.cx> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <200910020824.15488.john@baldwin.cx> User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Cc: Doug Rabson , freebsd-current@freebsd.org, George Mamalakis , Rick Macklem Subject: 8.0 Dynamic Linker Broken? (Was: [PATCH] SASL problems with spnego on 8.0-BETA4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Oct 2009 23:07:38 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 02 Oct 2009, 08:24 -0400, John Baldwin wrote: > On Friday 02 October 2009 4:13:19 am John Marshall wrote: > > On Tue, 22 Sep 2009, 08:22 +1000, John Marshall wrote: > > > On Mon, 21 Sep 2009, 11:26 -0400, Rick Macklem wrote: > > > [snip] > > > > > > > > Now, hopefully someone who understands enough about dynamic linking= will > > > > know if this is the correct fix for 8.0? (I'm going on a couple of = weeks > > > > vacation at the end of this week, so I won't be around to commit=20 > > > > anything > > > > and don't understand it well enough to know if this is the correct = way > > > > to fix it.) > > > >=20 > > > > So, hopefully someone else can pick this one up? > > > >=20 [snip] > > >=20 > > > I have submitted a patch to the FreeBSD Makefile which patches the > > > vendor-supplied template for krb5-config. I should be grateful if df= r@ > > > or another src committer would please review this with a view to > > > obtaining re@ approval to commit it before 8.0-RC2. > > >=20 > > > > >=20 > > Any src committers able to help with this? >=20 > Hmmm, I thought that libgssapi was supposed to use dlopen to load the pro= per=20 > back-end libraries using /etc/gss/mech rather than having applications=20 > directly link against them. OK, so if my proposed solution is, in fact, only masking a symptom of a broken dynamic linker, would somebody who understands this stuff please weigh in on this with some debugging suggestions or with a patch to address this problem? I'm able to help with testing but I'm not a programmer and know nothing about the FreeBSD dynamic linker. Thanks. --=20 John Marshall --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkrJKqcACgkQw/tAaKKahKLlvQCfVbZmiiixTHVkhA3tYO++zvXY zYoAoKM9V+RxQIlFCa3hq1Cih948coG5 =Ffyd -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 4 23:35:20 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E581106566B for ; Sun, 4 Oct 2009 23:35:20 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id B40888FC0C for ; Sun, 4 Oct 2009 23:35:19 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id n94NZHhl006147 ; Mon, 5 Oct 2009 01:35:17 +0200 (CEST) X-Ids: 164 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id n94NZGQ8087552; Mon, 5 Oct 2009 01:35:16 +0200 (CEST) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id n94NZGru087549; Mon, 5 Oct 2009 01:35:16 +0200 (CEST) (envelope-from arno) To: Dmitry Marakasov From: "Arno J. Klaassen" References: <20090123221826.GB30982@deprived.panopticon> <20090126144044.GB6054@hades.panopticon> <20090127164617.GA93440@hades.panopticon> <20090128042148.GA1256@hades.panopticon> <20090814021340.GA1275@hades.panopticon> <20091004190347.GC64567@hades.panopticon> Date: Mon, 05 Oct 2009 01:35:15 +0200 In-Reply-To: <20091004190347.GC64567@hades.panopticon> (Dmitry Marakasov's message of "Sun\, 4 Oct 2009 23\:03\:47 +0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.94.2/9866/Sat Oct 3 16:49:15 2009 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail2.jussieu.fr with ID 4AC93135.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4AC93135.001/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: current@freebsd.org Subject: Re: Data corruption with checksum offloading enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Oct 2009 23:35:20 -0000 Dmitry Marakasov writes: > * Arno J. Klaassen (arno@heho.snv.jussieu.fr) wrote: > > I had no problems since my previous message, however I've just noticed > that rxcsum is disabled by default on 8.x. So this should really be > tested after explicitely enabling it with ifconfig +rxcsum. if ever this helps, I just came accross these messages on a (7-stable) nfs-client against my 8-stable server which passes the test : Oct 3 17:25:05 push kernel: nfs_getpages: error 1433597680 Oct 3 17:25:05 push kernel: vm_fault: pager read error, pid 26821 (cmp) Oct 3 17:28:25 push kernel: nfs_getpages: error 1435664464 Oct 3 17:28:25 push kernel: vm_fault: pager read error, pid 27017 (cp) IMHO looks like some rare nfs-miss-communication which passes silently against a 7-nfssrver but gets noticed (and corrected ..) against a 8-nfsserver /disclaimer it is late (here) and I need sleep Arno From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 03:54:21 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7289106566B; Mon, 5 Oct 2009 03:54:21 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4653C8FC16; Mon, 5 Oct 2009 03:54:21 +0000 (UTC) Received: from delta.allbsd.org (p4206-ipbf1902funabasi.chiba.ocn.ne.jp [114.146.107.206]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id n953s9MJ064231; Mon, 5 Oct 2009 12:54:19 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id n953s1rm067623; Mon, 5 Oct 2009 12:54:03 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 05 Oct 2009 12:34:27 +0900 (JST) Message-Id: <20091005.123427.227628092.hrs@allbsd.org> To: freebsd-rc@FreeBSD.org From: Hiroki Sato In-Reply-To: <20090920.224018.16368211.hrs@allbsd.org> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.2.52 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Oct__5_12_34_27_2009_085)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Mon, 05 Oct 2009 12:54:19 +0900 (JST) Cc: freebsd-current@FreeBSD.org Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration (was: Re: svn commit: r197145 - in head: etc/defaults share/man/man5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 03:54:21 -0000 ----Security_Multipart(Mon_Oct__5_12_34_27_2009_085)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I would like your comments about merging the network_ipv6 -> netif integration to stable/8. The issue of this rc.d script change is it involves user-visible changes in rc.conf(5) variables as described in UPDATING. I still want to do so before 8.0-R because the ND6 change in -CURRENT needs updating IPv6-related rc.d scripts first. While the ND6 change is not harmful from viewpoint of compatibility because basically it just converts a global knob to a per-interface flag, handling it in the rc.d scripts needs a kind of overhaul of rc.d/network_ipv6 and rc.d/netif. The necessary changes have already been committed into -CURRENT. It displays a warning to inform the users what is old in the rc.conf if the user uses rc.d variables that have been changed, and at the same time it keeps backward compatibility so that the old variables also work. So, I think the impact is small enough, and this sort of visible changes should be included in the .0 release rather than in the middle of future 8.x releases. The patch for stable/8 can be found at: http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff This includes both of the ND6 kernel change and the rc.d script change. If there is an objection from someone here I will put off the merge until after 8.0-R. -- Hiroki ----Security_Multipart(Mon_Oct__5_12_34_27_2009_085)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkrJaUMACgkQTyzT2CeTzy2BNACfRv08FD2cfo6x0w9Cfj+0KovS VEMAnip3sEDFKh6cNfeoCO1OTxL8vf9K =jBPP -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Oct__5_12_34_27_2009_085)---- From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 05:08:24 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9672106568D; Mon, 5 Oct 2009 05:08:24 +0000 (UTC) (envelope-from bland@FreeBSD.org) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id 7F4D28FC14; Mon, 5 Oct 2009 05:08:24 +0000 (UTC) Received: from hub.bbnest.net (w133033.ppp.asahi-net.or.jp [121.1.133.33]) by mail2.asahi-net.or.jp (Postfix) with ESMTP id 5EF1A800B4; Mon, 5 Oct 2009 13:50:45 +0900 (JST) Received: from hub.bbnest.net (localhost [127.0.0.1]) by hub.bbnest.net (8.14.3/8.14.3) with ESMTP id n954oi4r080864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Oct 2009 13:50:44 +0900 (JST) (envelope-from bland@FreeBSD.org) Received: (from www@localhost) by hub.bbnest.net (8.14.3/8.14.3/Submit) id n954oiLW080863; Mon, 5 Oct 2009 13:50:44 +0900 (JST) (envelope-from bland@FreeBSD.org) X-Authentication-Warning: hub.bbnest.net: www set sender to bland@FreeBSD.org using -f To: John Marshall MIME-Version: 1.0 Date: Mon, 05 Oct 2009 13:50:44 +0900 From: Alexander Nedotsukov Message-ID: <54ee35ff63fa25ea4c082134892835fb@mail> X-Sender: bland@FreeBSD.org User-Agent: RoundCube Webmail/0.2a Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon Oct 5 13:50:45 2009 X-DSPAM-Confidence: 0.9994 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4ac97b25808651564613231 Cc: John Baldwin , Doug Rabson , freebsd-current@FreeBSD.org, George Mamalakis , Rick Macklem Subject: Re: 8.0 Dynamic Linker Broken? (Was: [PATCH] SASL problems with spnego on 8.0-BETA4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 05:08:24 -0000 Actually this may mean quite otherwise. What I saying is if some code (eg. libsasl) dlopen() libgssapi as RTLD_LOCAL then later attempt to load libgssapi_xxx inside libgssapi may fail because of this: $ldd /usr/lib/libgssapi_spnego.so /usr/lib/libgssapi_spnego.so: libasn1.so.10 => /usr/lib/libasn1.so.10 (0x28300000) libc.so.7 => /lib/libc.so.7 (0x2808f000) I would expect to see libgssapi.so.10 dependency here. On Mon, 5 Oct 2009 10:07:20 +1100, John Marshall wrote: > On Fri, 02 Oct 2009, 08:24 -0400, John Baldwin wrote: >> On Friday 02 October 2009 4:13:19 am John Marshall wrote: >> > On Tue, 22 Sep 2009, 08:22 +1000, John Marshall wrote: >> > > On Mon, 21 Sep 2009, 11:26 -0400, Rick Macklem wrote: >> > > > [snip] >> > > > >> > > > Now, hopefully someone who understands enough about dynamic >> > > > linking will >> > > > know if this is the correct fix for 8.0? (I'm going on a couple of >> > > > weeks >> > > > vacation at the end of this week, so I won't be around to commit >> > > > anything >> > > > and don't understand it well enough to know if this is the correct >> > > > way >> > > > to fix it.) >> > > > >> > > > So, hopefully someone else can pick this one up? >> > > > > [snip] >> > > >> > > I have submitted a patch to the FreeBSD Makefile which patches the >> > > vendor-supplied template for krb5-config. I should be grateful if >> > > dfr@ >> > > or another src committer would please review this with a view to >> > > obtaining re@ approval to commit it before 8.0-RC2. >> > > >> > > >> > >> > Any src committers able to help with this? >> >> Hmmm, I thought that libgssapi was supposed to use dlopen to load the >> proper >> back-end libraries using /etc/gss/mech rather than having applications >> directly link against them. > > OK, so if my proposed solution is, in fact, only masking a symptom of a > broken dynamic linker, would somebody who understands this stuff please > weigh in on this with some debugging suggestions or with a patch to > address this problem? > > I'm able to help with testing but I'm not a programmer and know nothing > about the FreeBSD dynamic linker. > > Thanks. From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 05:58:09 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2F2C1065670; Mon, 5 Oct 2009 05:58:08 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2A0728FC0C; Mon, 5 Oct 2009 05:58:07 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 58B7839830; Mon, 5 Oct 2009 07:58:06 +0200 (SAST) Date: Mon, 5 Oct 2009 07:58:06 +0200 From: John Hay To: Hiroki Sato Message-ID: <20091005055806.GB58246@zibbi.meraka.csir.co.za> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091005.123427.227628092.hrs@allbsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org, freebsd-rc@FreeBSD.org Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration (was: Re: svn commit: r197145 - in head: etc/defaults share/man/man5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 05:58:09 -0000 On Mon, Oct 05, 2009 at 12:34:27PM +0900, Hiroki Sato wrote: > Hi, > > I would like your comments about merging the network_ipv6 -> netif > integration to stable/8. The issue of this rc.d script change is it > involves user-visible changes in rc.conf(5) variables as described in > UPDATING. > > I still want to do so before 8.0-R because the ND6 change in -CURRENT > needs updating IPv6-related rc.d scripts first. While the ND6 change > is not harmful from viewpoint of compatibility because basically it > just converts a global knob to a per-interface flag, handling it in > the rc.d scripts needs a kind of overhaul of rc.d/network_ipv6 and > rc.d/netif. > > The necessary changes have already been committed into -CURRENT. It > displays a warning to inform the users what is old in the rc.conf if > the user uses rc.d variables that have been changed, and at the same > time it keeps backward compatibility so that the old variables also > work. So, I think the impact is small enough, and this sort of > visible changes should be included in the .0 release rather than in > the middle of future 8.x releases. > > The patch for stable/8 can be found at: > > http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff > > This includes both of the ND6 kernel change and the rc.d script > change. If there is an objection from someone here I will put off > the merge until after 8.0-R. Is there a good reason why we still ship with ipv6 off by default? Most others seem to ship with ipv6 on. At least Windows, most linux flavours and Mac OS X which make out the rest of the machines on our network here at Meraka Institute. One thing that I have against the way the stuff in -current is done at the moment, is that it seems to be a lot more work to just get ipv6 to work. Either I did things wrong or we are taking a step backward. Make no mistake, I like the idea of being able to control it per interface, but it seems that you have to enable it per interface with a long string for each... I would rather that it is enabled everywhere by default and then you disbale it where you do not want it. John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 07:30:10 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 320561065672; Mon, 5 Oct 2009 07:30:10 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (router.rabson.org [80.177.232.241]) by mx1.freebsd.org (Postfix) with ESMTP id AAFC68FC08; Mon, 5 Oct 2009 07:30:09 +0000 (UTC) Received: from [IPv6:2001:470:909f:1:225:ff:feed:9426] (unknown [IPv6:2001:470:909f:1:225:ff:feed:9426]) by itchy.rabson.org (Postfix) with ESMTP id EEA1D5C2F; Mon, 5 Oct 2009 08:29:37 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Doug Rabson In-Reply-To: <54ee35ff63fa25ea4c082134892835fb@mail> Date: Mon, 5 Oct 2009 08:29:37 +0100 Content-Transfer-Encoding: 7bit Message-Id: <0EA2E119-29DF-4DDE-84C3-432E35D61C76@rabson.org> References: <54ee35ff63fa25ea4c082134892835fb@mail> To: Alexander Nedotsukov X-Mailer: Apple Mail (2.1076) Cc: Doug Rabson , Rick Macklem , John Baldwin , freebsd-current@FreeBSD.org, John Marshall , George Mamalakis Subject: Re: 8.0 Dynamic Linker Broken? (Was: [PATCH] SASL problems with spnego on 8.0-BETA4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 07:30:10 -0000 This is the core of the problem, I think. There are two possible solutions: 1. Link libgssapi_foo.so against libgssapi.so. I'm not a fan of this because it will encourage people to link with libgssapi_krb5.so when they really ought to be linking with libgssapi.so to give them mechanism independance. 2. Split the various mechanism libs in to two parts, mech_foo.so which will contain the actual mechanism implementation (this can link with libgssapi.so to handle the RTLD_LOCAL issue) and optionally libgssapi_foo.so to contain any mechanism-specific extensions. Clearly (2) is unsuitable for 8.0 but could happen in current. I guess we could use (1) as a band-aid fix for 8.0. On 5 Oct 2009, at 05:50, Alexander Nedotsukov wrote: > > Actually this may mean quite otherwise. > What I saying is if some code (eg. libsasl) dlopen() libgssapi as > RTLD_LOCAL then later attempt to load libgssapi_xxx inside libgssapi > may > fail because of this: > > $ldd /usr/lib/libgssapi_spnego.so > /usr/lib/libgssapi_spnego.so: > libasn1.so.10 => /usr/lib/libasn1.so.10 (0x28300000) > libc.so.7 => /lib/libc.so.7 (0x2808f000) > > I would expect to see libgssapi.so.10 dependency here. > > On Mon, 5 Oct 2009 10:07:20 +1100, John Marshall > wrote: >> On Fri, 02 Oct 2009, 08:24 -0400, John Baldwin wrote: >>> On Friday 02 October 2009 4:13:19 am John Marshall wrote: >>>> On Tue, 22 Sep 2009, 08:22 +1000, John Marshall wrote: >>>>> On Mon, 21 Sep 2009, 11:26 -0400, Rick Macklem wrote: >>>>> >> [snip] >>>>>> >>>>>> Now, hopefully someone who understands enough about dynamic >>>>>> linking will >>>>>> know if this is the correct fix for 8.0? (I'm going on a couple > of >>>>>> weeks >>>>>> vacation at the end of this week, so I won't be around to commit >>>>>> anything >>>>>> and don't understand it well enough to know if this is the > correct >>>>>> way >>>>>> to fix it.) >>>>>> >>>>>> So, hopefully someone else can pick this one up? >>>>>> >> [snip] >>>>> >>>>> I have submitted a patch to the FreeBSD Makefile which patches the >>>>> vendor-supplied template for krb5-config. I should be grateful if >>>>> dfr@ >>>>> or another src committer would please review this with a view to >>>>> obtaining re@ approval to commit it before 8.0-RC2. >>>>> >>>>> >>>> >>>> Any src committers able to help with this? >>> >>> Hmmm, I thought that libgssapi was supposed to use dlopen to load >>> the >>> proper >>> back-end libraries using /etc/gss/mech rather than having >>> applications >>> directly link against them. >> >> OK, so if my proposed solution is, in fact, only masking a symptom >> of a >> broken dynamic linker, would somebody who understands this stuff >> please >> weigh in on this with some debugging suggestions or with a patch to >> address this problem? >> >> I'm able to help with testing but I'm not a programmer and know >> nothing >> about the FreeBSD dynamic linker. >> >> Thanks. From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 09:21:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FFB0106568D; Mon, 5 Oct 2009 09:21:52 +0000 (UTC) (envelope-from vinnix.bsd@gmail.com) Received: from mail-pz0-f201.google.com (mail-pz0-f201.google.com [209.85.222.201]) by mx1.freebsd.org (Postfix) with ESMTP id D7E7B8FC21; Mon, 5 Oct 2009 09:21:51 +0000 (UTC) Received: by pzk39 with SMTP id 39so886362pzk.15 for ; Mon, 05 Oct 2009 02:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Jc/A+BGtmYJLEIcQPHyJJi7WFrluR93N/ZLNANzCJh4=; b=Wq2gl4ytFByhzb3qB4+1t6BHFQz71uPVkcH9SPNIzDUqw7c4MYPyvoAl1dDGNNrLzp +pGQJzRHzdOfMOLkb/rYTgwlVVzbnTl2nb8c8+vyfKOIMgWIgXGKRg5ehGUw+fd71BIu 24YxkOlaGX3NvbIjmqrK1kdH4I6DATr/dEZj4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lP40MCRX61ft9DVVn0AKKVIp5p+eAx8ER/kOuvJAdHVusBq1amEiMne6yJ8N2WKQT/ EB+xYMR5k1Dx2+fyj1y9URyj6VrzrldnpfBGqx3rWJ55Sk1s49J1WQbtmP9rjtu/dkta YDg9mbJCnyKphW3OKoGX/KLxm2hpGhYc06cPc= MIME-Version: 1.0 Received: by 10.141.3.16 with SMTP id f16mr859460rvi.261.1254734509463; Mon, 05 Oct 2009 02:21:49 -0700 (PDT) In-Reply-To: <200910042010.49054.hselasky@c2i.net> References: <20090908201713.GD41185@e.0x20.net> <200909131508.05025.hselasky@c2i.net> <1e31c7980910040814o48a1a57bgde86571fa3265c4c@mail.gmail.com> <200910042010.49054.hselasky@c2i.net> Date: Mon, 5 Oct 2009 10:21:49 +0100 Message-ID: <1e31c7980910050221u11b93be9ye390bad8b6857c0b@mail.gmail.com> From: Vinicius Abrahao To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: luigi@freebsd.org, freebsd-current , lars.engels@0x20.net, freebsd-usb@freebsd.org, Florent Thoumie Subject: Re: CFH: fix multimedia/pwcbsd with usb2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 09:21:52 -0000 Hi Hans, With the pwcview from I4B SVN: Did not recognize my device at all, with or without -d option. With pwcbsd from ports: The pwc.ko only recognize my cam If I apply this patch in pwc.c: 94a95 > {USB_VPI(0x093a, 0x2603, 675)}, /* Philips SPC500NC */ Note that 675 (type field) is just my guess. I try some others without success. But only appears a green or black screen. Research more about this cam I found that it uses a sensor: PAC7311 [1]. Cause this problems I'm wondering buy a new camera (better quality) and default support by pwc.ko. For the other side, put this camera to work, seens a cool opportunity to learn more about drivers at FreeBSD environment. [1] http://www.pixart.com.tw/upload/PAC7311%20Spec%20V15_20051122092509.pdf Thanks for your help, Vinnix On 10/4/09, Hans Petter Selasky wrote: > On Sunday 04 October 2009 17:14:04 Vinicius Abrahao wrote: >> ./pwcview > > Try to run without -d /dev/ugenX.Y. > > Which pwcview did you build? The one from ports or I4B SVN? > > --HPS > > From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 09:22:15 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA156106568D for ; Mon, 5 Oct 2009 09:22:15 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 7D0A08FC1A for ; Mon, 5 Oct 2009 09:22:15 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 23FC06D44C for ; Mon, 5 Oct 2009 09:22:14 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 088B18450B; Mon, 5 Oct 2009 11:22:14 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: current@freebsd.org References: <20091004165217.GS69612@acme.spoerlein.net> Date: Mon, 05 Oct 2009 11:22:13 +0200 In-Reply-To: <20091004165217.GS69612@acme.spoerlein.net> ("Ulrich =?utf-8?Q?Sp=C3=B6rlein=22's?= message of "Sun, 4 Oct 2009 18:52:18 +0200") Message-ID: <86my46xkje.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Update to OpenSSH 5.3p1 broke pam_ssh.so ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 09:22:15 -0000 Ulrich Sp=C3=B6rlein writes: > is it possible, that the recent update causes my -CURRENT box to no > longer allow for pam_ssh.so references in /etc/pam.d/{login,sshd}? Weird, can you send me the error messages? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 09:24:33 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3863E1065693; Mon, 5 Oct 2009 09:24:33 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5F51A8FC14; Mon, 5 Oct 2009 09:24:32 +0000 (UTC) Received: from delta.allbsd.org (p4206-ipbf1902funabasi.chiba.ocn.ne.jp [114.146.107.206]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id n959OI7g070812; Mon, 5 Oct 2009 18:24:29 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id n959O9SN068663; Mon, 5 Oct 2009 18:24:12 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 05 Oct 2009 18:23:42 +0900 (JST) Message-Id: <20091005.182342.167950100.hrs@allbsd.org> To: jhay@meraka.org.za From: Hiroki Sato In-Reply-To: <20091005055806.GB58246@zibbi.meraka.csir.co.za> References: <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <20091005055806.GB58246@zibbi.meraka.csir.co.za> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.2.52 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Oct__5_18_23_42_2009_632)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Mon, 05 Oct 2009 18:24:31 +0900 (JST) Cc: freebsd-current@FreeBSD.org, freebsd-rc@FreeBSD.org Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 09:24:33 -0000 ----Security_Multipart(Mon_Oct__5_18_23_42_2009_632)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Hay wrote in <20091005055806.GB58246@zibbi.meraka.csir.co.za>: jh> Is there a good reason why we still ship with ipv6 off by default? Most jh> others seem to ship with ipv6 on. At least Windows, most linux flavours jh> and Mac OS X which make out the rest of the machines on our network here jh> at Meraka Institute. What do you mean by "off by default"? I think IPv6 is not disabled by default with the patch. Re-enabling of "automatic assignment of a link-local address by default" has been a big step for IPv6 ready out of the box. jh> One thing that I have against the way the stuff in -current is done at jh> the moment, is that it seems to be a lot more work to just get ipv6 to jh> work. Either I did things wrong or we are taking a step backward. Make jh> no mistake, I like the idea of being able to control it per interface, jh> but it seems that you have to enable it per interface with a long string jh> for each... I would rather that it is enabled everywhere by default and jh> then you disbale it where you do not want it. The initial patch had several regressions to mistakenly disable the functionality, but the current one should work by just adding an $ifconfig_IF_ipv6 line to rc.conf. The intention of my patch is to set $ipv6_enable=YES automatically (in more modular manner) when an IPv6 configuration is specified for an interface. Even with no per-interface configuration, when $ipv6_prefer=YES, IPv6 communication by using link-local addresses works. I believe it does not make it so complex compared with the old $ipv6_enable=YES model. I feel there is some difference between my understanding of "enable by default" and yours. Do you elaborate the word "enable" a bit more, please? -- Hiroki ----Security_Multipart(Mon_Oct__5_18_23_42_2009_632)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkrJux4ACgkQTyzT2CeTzy035gCgjUDOcAz37N2ERnkD07NYvedM CoMAn0AFy6WDTTWqSZQ7NMLgQqa4j/xg =wP4G -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Oct__5_18_23_42_2009_632)---- From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 09:30:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1F5410656B0; Mon, 5 Oct 2009 09:30:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6BF748FC1D; Mon, 5 Oct 2009 09:30:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 34B5E41C729; Mon, 5 Oct 2009 11:30:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id vEWQZ1L3bTzE; Mon, 5 Oct 2009 11:30:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 80DBA41C71D; Mon, 5 Oct 2009 11:30:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id C57A54448E6; Mon, 5 Oct 2009 09:25:19 +0000 (UTC) Date: Mon, 5 Oct 2009 09:25:18 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: John Hay In-Reply-To: <20091005055806.GB58246@zibbi.meraka.csir.co.za> Message-ID: <20091005091708.J26486@maildrop.int.zabbadoz.net> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <20091005055806.GB58246@zibbi.meraka.csir.co.za> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org, Hiroki Sato , freebsd-rc@FreeBSD.org Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration (was: Re: svn commit: r197145 - in head: etc/defaults share/man/man5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 09:30:08 -0000 On Mon, 5 Oct 2009, John Hay wrote: Hi, > On Mon, Oct 05, 2009 at 12:34:27PM +0900, Hiroki Sato wrote: >> Hi, >> >> I would like your comments about merging the network_ipv6 -> netif >> integration to stable/8. The issue of this rc.d script change is it >> involves user-visible changes in rc.conf(5) variables as described in >> UPDATING. >> >> I still want to do so before 8.0-R because the ND6 change in -CURRENT >> needs updating IPv6-related rc.d scripts first. While the ND6 change >> is not harmful from viewpoint of compatibility because basically it >> just converts a global knob to a per-interface flag, handling it in >> the rc.d scripts needs a kind of overhaul of rc.d/network_ipv6 and >> rc.d/netif. >> >> The necessary changes have already been committed into -CURRENT. It >> displays a warning to inform the users what is old in the rc.conf if >> the user uses rc.d variables that have been changed, and at the same >> time it keeps backward compatibility so that the old variables also >> work. So, I think the impact is small enough, and this sort of >> visible changes should be included in the .0 release rather than in >> the middle of future 8.x releases. >> >> The patch for stable/8 can be found at: >> >> http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff >> >> This includes both of the ND6 kernel change and the rc.d script >> change. If there is an objection from someone here I will put off >> the merge until after 8.0-R. > > Is there a good reason why we still ship with ipv6 off by default? Most > others seem to ship with ipv6 on. At least Windows, most linux flavours > and Mac OS X which make out the rest of the machines on our network here > at Meraka Institute. > > One thing that I have against the way the stuff in -current is done at > the moment, is that it seems to be a lot more work to just get ipv6 to > work. Either I did things wrong or we are taking a step backward. Make > no mistake, I like the idea of being able to control it per interface, > but it seems that you have to enable it per interface with a long string > for each... I would rather that it is enabled everywhere by default and > then you disbale it where you do not want it. link-local had been enabled by default in the past and I am not sure if we had a SA or EN for that or that it was just preemptively disabled. The problem is that if it is enabled by default you are exposing yourself to others on the same network. That is of course especially bad if you are in untrusted environments like conferences, ... or on a public LAN. If we'd support IPv4 link-local addresses by default we would have to apply the same logic there. I am not sure about OSX but at least Windows has a firewall set to deny any unrelated incoming things by default these days. Just because others haven't yet (really) thought about the problems doesn't mean they aren't there. If you want to use IPv4 you either add an address or start DHCP or .. and you have to configure that. If you want IPv6, you configure that as well. You shall not have anything enbaled by default that people can use to attack you and you don't know about because you didn't configure. While (we) IPv6 people know that it would be there a lot of people are still totally unaware of IPv6 and they would be surprised. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 11:05:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A0A81065692 for ; Mon, 5 Oct 2009 11:05:07 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 2B6478FC0A for ; Mon, 5 Oct 2009 11:05:07 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 5CADD6D41B; Mon, 5 Oct 2009 11:05:06 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id AB4B7844E4; Mon, 5 Oct 2009 13:05:04 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Taku YAMAMOTO References: <20091004225000.6a1a6262.taku@tackymt.homeip.net> Date: Mon, 05 Oct 2009 13:05:04 +0200 In-Reply-To: <20091004225000.6a1a6262.taku@tackymt.homeip.net> (Taku YAMAMOTO's message of "Sun, 4 Oct 2009 22:50:00 +0900") Message-ID: <86fx9yxfrz.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: pam_ssh no longer works after r197679 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 11:05:07 -0000 Taku YAMAMOTO writes: > A quick investigation revailed that libssh.so.5 had some symbols undefine= d, > which prevented pam_ssh.so.5 from being loaded. > # FYI: openpam dlopen()s modules with RTLD_NOW. > > Here's interesting bits from nm -D /usr/lib/libssh.so.5 | fgrep U > U roaming_read > U roaming_write This is weird - I understand what the problem is, but I don't understand why it didn't break the build. As a workaround, try adding roaming_dummy.c to SRCS in pam_ssh's Makefile. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 11:07:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F29E6106570E; Mon, 5 Oct 2009 11:07:26 +0000 (UTC) (envelope-from bland@freebsd.org) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 9F6CA8FC1A; Mon, 5 Oct 2009 11:07:26 +0000 (UTC) Received: from hub.bbnest.net (w133033.ppp.asahi-net.or.jp [121.1.133.33]) by mail1.asahi-net.or.jp (Postfix) with ESMTP id 9CAFE860F9; Mon, 5 Oct 2009 20:07:23 +0900 (JST) Received: from nest.bbnest.net (nest.bbnest.net [10.0.0.249]) by hub.bbnest.net (8.14.3/8.14.3) with ESMTP id n95B78TA095839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Oct 2009 20:07:09 +0900 (JST) (envelope-from bland@freebsd.org) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Alexander Nedotsukov In-Reply-To: <0EA2E119-29DF-4DDE-84C3-432E35D61C76@rabson.org> Date: Mon, 5 Oct 2009 20:07:08 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: <54ee35ff63fa25ea4c082134892835fb@mail> <0EA2E119-29DF-4DDE-84C3-432E35D61C76@rabson.org> To: Doug Rabson X-Mailer: Apple Mail (2.1076) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Oct 5 20:07:23 2009 X-DSPAM-Confidence: 0.9994 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4ac9d36b958401856066157 Cc: Doug Rabson , Rick Macklem , John Baldwin , freebsd-current@freebsd.org, John Marshall , George Mamalakis Subject: Re: 8.0 Dynamic Linker Broken? (Was: [PATCH] SASL problems with spnego on 8.0-BETA4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 11:07:27 -0000 Doug, I share your concerns about wrong libgssapi_foo usage. Do you see any possible drawbacks of: 3) Move libgssapi_foo into gssapi/libfoo_mech and link libgoo_mech against libgssapi Thanks, Alexander On 05.10.2009, at 16:29, Doug Rabson wrote: > This is the core of the problem, I think. There are two possible > solutions: > > 1. Link libgssapi_foo.so against libgssapi.so. I'm not a fan of this > because it will encourage people to link with libgssapi_krb5.so when > they really ought to be linking with libgssapi.so to give them > mechanism independance. > > 2. Split the various mechanism libs in to two parts, mech_foo.so > which will contain the actual mechanism implementation (this can > link with libgssapi.so to handle the RTLD_LOCAL issue) and > optionally libgssapi_foo.so to contain any mechanism-specific > extensions. > > Clearly (2) is unsuitable for 8.0 but could happen in current. I > guess we could use (1) as a band-aid fix for 8.0. > > On 5 Oct 2009, at 05:50, Alexander Nedotsukov wrote: > >> >> Actually this may mean quite otherwise. >> What I saying is if some code (eg. libsasl) dlopen() libgssapi as >> RTLD_LOCAL then later attempt to load libgssapi_xxx inside >> libgssapi may >> fail because of this: >> >> $ldd /usr/lib/libgssapi_spnego.so >> /usr/lib/libgssapi_spnego.so: >> libasn1.so.10 => /usr/lib/libasn1.so.10 (0x28300000) >> libc.so.7 => /lib/libc.so.7 (0x2808f000) >> >> I would expect to see libgssapi.so.10 dependency here. >> >> On Mon, 5 Oct 2009 10:07:20 +1100, John Marshall >> wrote: >>> On Fri, 02 Oct 2009, 08:24 -0400, John Baldwin wrote: >>>> On Friday 02 October 2009 4:13:19 am John Marshall wrote: >>>>> On Tue, 22 Sep 2009, 08:22 +1000, John Marshall wrote: >>>>>> On Mon, 21 Sep 2009, 11:26 -0400, Rick Macklem wrote: >>>>>> >>> [snip] >>>>>>> >>>>>>> Now, hopefully someone who understands enough about dynamic >>>>>>> linking will >>>>>>> know if this is the correct fix for 8.0? (I'm going on a couple >> of >>>>>>> weeks >>>>>>> vacation at the end of this week, so I won't be around to commit >>>>>>> anything >>>>>>> and don't understand it well enough to know if this is the >> correct >>>>>>> way >>>>>>> to fix it.) >>>>>>> >>>>>>> So, hopefully someone else can pick this one up? >>>>>>> >>> [snip] >>>>>> >>>>>> I have submitted a patch to the FreeBSD Makefile which patches >>>>>> the >>>>>> vendor-supplied template for krb5-config. I should be grateful >>>>>> if >>>>>> dfr@ >>>>>> or another src committer would please review this with a view to >>>>>> obtaining re@ approval to commit it before 8.0-RC2. >>>>>> >>>>>> >>>>> >>>>> Any src committers able to help with this? >>>> >>>> Hmmm, I thought that libgssapi was supposed to use dlopen to load >>>> the >>>> proper >>>> back-end libraries using /etc/gss/mech rather than having >>>> applications >>>> directly link against them. >>> >>> OK, so if my proposed solution is, in fact, only masking a symptom >>> of a >>> broken dynamic linker, would somebody who understands this stuff >>> please >>> weigh in on this with some debugging suggestions or with a patch to >>> address this problem? >>> >>> I'm able to help with testing but I'm not a programmer and know >>> nothing >>> about the FreeBSD dynamic linker. >>> >>> Thanks. > > _______________________________________________ > 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 Mon Oct 5 11:17:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C7201065672 for ; Mon, 5 Oct 2009 11:17:25 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 1E4828FC17 for ; Mon, 5 Oct 2009 11:17:24 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=aQey1_VUwUUA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=r3FW1PXw6K5yLqXbgiQA:9 a=tJZeuZmK-B1_kZr8qR9xwGcEuoYA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1307561789; Mon, 05 Oct 2009 13:17:22 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 5 Oct 2009 13:18:10 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20091002150931.K35591@pooker.samsco.org> <200910032306.01529.hselasky@c2i.net> In-Reply-To: <200910032306.01529.hselasky@c2i.net> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910051318.11111.hselasky@c2i.net> Cc: Marcel Moolenaar Subject: Re: [PATCH] Fix for USB media not found at boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 11:17:25 -0000 On Saturday 03 October 2009 23:06:00 Hans Petter Selasky wrote: > On Saturday 03 October 2009 20:51:07 Marcel Moolenaar wrote: > > On Oct 3, 2009, at 9:00 AM, Hans Petter Selasky wrote: > > > > An approach like this also allows one to indefinitely wait for the root > > device, which is a good feature to have... > > Here is a patch you can try: > > http://perforce.freebsd.org/chv.cgi?CH=169183 > > NOTE: I was not able to get any characters from gets() nor cncheckc(), so > there seems to be a bug somewhere. This used to work before at mount-root > time. > Hi, I currently only see one problem. If any partitions that should be automounted by /etc/fstab are not on the root disk, then /etc/fstab will fail, because the current code will only wait for for the root mount partition. Probably the script executing /etc/fstab should be updated to wait for disks aswell. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 11:39:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1536B1065693; Mon, 5 Oct 2009 11:39:24 +0000 (UTC) (envelope-from michio.jinbo@gmail.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id A6BA38FC21; Mon, 5 Oct 2009 11:39:23 +0000 (UTC) Received: by pzk40 with SMTP id 40so2959630pzk.7 for ; Mon, 05 Oct 2009 04:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject:cc :in-reply-to:references:message-id:mime-version:content-type :content-transfer-encoding:x-mailer; bh=61EaWSTH8BcxFKJ8T3sO4fC2OMYKqHj05IJ+BvEbavc=; b=eKKM8kh2wsvSTnP68CjPSXP6JGzJ6D/+GXDqHDGUi1DvdDPtHMSQ8SdLUQQBl2yEnC Gl5RB/EIPdRPbX8wv9Ei/deDVgVcenPG0tQjrprBqxqsBT2BmfHmuSy9qQGm+TgZvCiy K3CrMqF+lmqAxeUshEc1uw1rRugIVD3/a/SLM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:cc:in-reply-to:references:message-id :mime-version:content-type:content-transfer-encoding:x-mailer; b=TDXYVFLZ0RvOWXVEa6B8TMM2p6bYI3wy+GCYinO0Os3IaPbae/KcFyKPPo1d7dxeID QRyYAIduVKD9FpV4k6+yA98M/fUDjXlWnWOYp6l/xESOltY1AKjjnxNpx289Ii/TT8uq pAe+c7Iz8i5uKRSA/IXpGGtO6NXy1xo2Q5MGs= Received: by 10.115.85.6 with SMTP id n6mr8890167wal.74.1254742763257; Mon, 05 Oct 2009 04:39:23 -0700 (PDT) Received: from ?192.168.4.100? (router.jinbo.jp [210.229.61.161]) by mx.google.com with ESMTPS id 22sm712946pzk.6.2009.10.05.04.39.21 (version=SSLv3 cipher=RC4-MD5); Mon, 05 Oct 2009 04:39:22 -0700 (PDT) Date: Mon, 05 Oct 2009 20:39:23 +0900 From: "Michio \"Karl\" Jinbo" To: Konstantin Belousov In-Reply-To: <200910041220.n94CKxTH073639@svn.freebsd.org> References: <200910041220.n94CKxTH073639@svn.freebsd.org> Message-Id: <20091005203920.1278.22FF24F1@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.51.07 [ja] Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, freebsd-current@freebsd.org, src-committers@freebsd.org, svn-src-stable-8@freebsd.org Subject: Re: svn commit: r197744 - in stable/8/sys: . amd64/amd64 amd64/include/xen cddl/contrib/opensolaris contrib/dev/acpica contrib/pf dev/xen/xenpci i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 11:39:24 -0000 On Sun, 4 Oct 2009 12:20:59 +0000 (UTC) Konstantin Belousov wrote: > Log: > MFC r197663: > As a workaround, for Intel CPUs, do not use CLFLUSH in > pmap_invalidate_cache_range() when self-snoop is apparently not reported > in cpu features. > > Approved by: re (bz, kensmith) I was tested r197663/r197744, but kernel panic again on Citrix Xen Server. using 8.0-RC1 install cd, results are 1. INTEL SU9400+HYPER-V(Windows2008 R2) -> boot OK. 2. AMD Athlon X2 TK-55+HYPER-V(Windows2008 R2) -> boot NG. 3. AMD PhenomII 940BK+Citrix Xen Server -> boot NG. I think INTEL CPUs are no problem, but AMD CPUs appear the problem. So I tested the following patch, kernel boot was successed on recent 9-CURRENT and environment 3. sorry, poor English. --- sys/i386/i386/initcpu.c.original 2009-10-01 21:52:48.000000000 +0900 +++ sys/i386/i386/initcpu.c 2009-10-05 08:29:45.000000000 +0900 @@ -721,7 +721,7 @@ * XXXKIB: (temporary) hack to work around traps generated when * CLFLUSHing APIC registers window. */ - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS)) + if (cpu_vendor_id == CPU_VENDOR_AMD && !(cpu_feature & CPUID_SS)) cpu_feature &= ~CPUID_CLFSH; #if defined(PC98) && !defined(CPU_UPGRADE_HW_CACHE) -- Michio "Karl" Jinbo From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 13:06:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 211761065672 for ; Mon, 5 Oct 2009 13:06:45 +0000 (UTC) (envelope-from minotaur@crete.org.ua) Received: from relay.padonki.org.ua (relay.padonki.org.ua [193.0.227.26]) by mx1.freebsd.org (Postfix) with ESMTP id CF6CB8FC1B for ; Mon, 5 Oct 2009 13:06:44 +0000 (UTC) Received: from minotaur by crow.padonki.org.ua with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuMya-000MM4-3g; Sun, 04 Oct 2009 12:01:56 +0300 Date: Sun, 4 Oct 2009 12:01:56 +0300 From: Alexander Shikoff To: freebsd-current@freebsd.org Message-ID: <20091004090156.GA85409@crete.org.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-u Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: Alexander Shikoff Subject: 'ee' editor prints cyrillic characters on white background X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@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: Mon, 05 Oct 2009 13:06:45 -0000 Hello, I've upgraded my 7.2-RELEASE to 8.0-RC1. ee editor began to highlight cyrillic characters (locale uk_UA.KOI8-U) with white background and underscoring. Does anyone know how to disable this? Thanks. -- MINO-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 14:37:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 110231065679 for ; Mon, 5 Oct 2009 14:37:50 +0000 (UTC) (envelope-from nyan@jp.FreeBSD.org) Received: from sakura.ccs.furiru.org (sakura.ccs.furiru.org [IPv6:2001:2f0:104:8060::1]) by mx1.freebsd.org (Postfix) with ESMTP id A9B648FC15 for ; Mon, 5 Oct 2009 14:37:49 +0000 (UTC) Received: from localhost (authenticated bits=0) by sakura.ccs.furiru.org (unknown) with ESMTP id n95EbkH4013619; Mon, 5 Oct 2009 23:37:48 +0900 (JST) (envelope-from nyan@jp.FreeBSD.org) Date: Mon, 05 Oct 2009 23:36:48 +0900 (JST) Message-Id: <20091005.233648.263895250.nyan@jp.FreeBSD.org> To: pyunyh@gmail.com From: Takahashi Yoshihiro In-Reply-To: <20090924175312.GA5572@michelle.cdnetworks.com> References: <20090924112533.1377D83D2D@mail1.asahi-net.or.jp> <20090924.210712.162012268.nyan@jp.FreeBSD.org> <20090924175312.GA5572@michelle.cdnetworks.com> X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, CQG00620@nifty.ne.jp Subject: Re: de(4) does not work on 8.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 14:37:50 -0000 In article <20090924175312.GA5572@michelle.cdnetworks.com> Pyun YongHyeon writes: >> > Thanks for your reply. They works well again on 8.0-RC1 with your >> > patch. >> >> I also use a NIC supported by de(4). The patch works fine for it. > > Thanks for testing! Patch committed to HEAD(r197465). Do you have a plan to merge this patch into stable/8? I wish that the de(4) works in 8.0R. --- TAKAHASHI Yoshihiro From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 14:40:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15F6E1065693 for ; Mon, 5 Oct 2009 14:40:46 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id CE48D8FC15 for ; Mon, 5 Oct 2009 14:40:45 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id E4B0F48997 for ; Mon, 5 Oct 2009 15:40:44 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMnbdGjXikfe for ; Mon, 5 Oct 2009 15:40:42 +0100 (BST) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 628DE48988 for ; Mon, 5 Oct 2009 15:40:42 +0100 (BST) Message-ID: <4ACA0549.7030404@tomjudge.com> Date: Mon, 05 Oct 2009 14:40:09 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 14:40:46 -0000 Hi, Does anyone know of a patch that will add per jail memory limits so that a jail can't swallow the resources of the entire box? Thanks Tom From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 13:54:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E84361065697; Mon, 5 Oct 2009 13:54:28 +0000 (UTC) (envelope-from john@baldwin.cx) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B5AD08FC0C; Mon, 5 Oct 2009 13:54:28 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 64E3646B49; Mon, 5 Oct 2009 09:54:28 -0400 (EDT) Received: from John-Baldwins-Macbook-Pro.local (localhost [IPv6:::1]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 07C968A021; Mon, 5 Oct 2009 09:54:26 -0400 (EDT) Message-ID: <4AC9FA92.70903@baldwin.cx> Date: Mon, 05 Oct 2009 09:54:26 -0400 From: John Baldwin User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: John Baldwin , freebsd-current@freebsd.org, George Mamalakis , Doug Rabson , Rick Macklem References: <4AB27FB6.4010806@eng.auth.gr> <20090921222241.GF1001@rwpc12.mby.riverwillow.net.au> <20091002081319.GN37304@rwpc12.mby.riverwillow.net.au> <200910020824.15488.john@baldwin.cx> <20091004230720.GA1086@rwpc12.mby.riverwillow.net.au> In-Reply-To: <20091004230720.GA1086@rwpc12.mby.riverwillow.net.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 05 Oct 2009 09:54:27 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx X-Mailman-Approved-At: Mon, 05 Oct 2009 15:21:57 +0000 Cc: Subject: Re: 8.0 Dynamic Linker Broken? (Was: [PATCH] SASL problems with spnego on 8.0-BETA4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 13:54:29 -0000 John Marshall wrote: > On Fri, 02 Oct 2009, 08:24 -0400, John Baldwin wrote: >> On Friday 02 October 2009 4:13:19 am John Marshall wrote: >>> On Tue, 22 Sep 2009, 08:22 +1000, John Marshall wrote: >>>> On Mon, 21 Sep 2009, 11:26 -0400, Rick Macklem wrote: >>>> > [snip] >>>>> Now, hopefully someone who understands enough about dynamic linking will >>>>> know if this is the correct fix for 8.0? (I'm going on a couple of weeks >>>>> vacation at the end of this week, so I won't be around to commit >>>>> anything >>>>> and don't understand it well enough to know if this is the correct way >>>>> to fix it.) >>>>> >>>>> So, hopefully someone else can pick this one up? >>>>> > [snip] >>>> I have submitted a patch to the FreeBSD Makefile which patches the >>>> vendor-supplied template for krb5-config. I should be grateful if dfr@ >>>> or another src committer would please review this with a view to >>>> obtaining re@ approval to commit it before 8.0-RC2. >>>> >>>> >>> Any src committers able to help with this? >> Hmmm, I thought that libgssapi was supposed to use dlopen to load the proper >> back-end libraries using /etc/gss/mech rather than having applications >> directly link against them. > > OK, so if my proposed solution is, in fact, only masking a symptom of a > broken dynamic linker, would somebody who understands this stuff please > weigh in on this with some debugging suggestions or with a patch to > address this problem? > > I'm able to help with testing but I'm not a programmer and know nothing > about the FreeBSD dynamic linker. I don't think the dynamic linker is broken. I would suspect a bug in libgssapi itself instead. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 17:34:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1D951065704 for ; Mon, 5 Oct 2009 17:34:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outL.internet-mail-service.net (outl.internet-mail-service.net [216.240.47.235]) by mx1.freebsd.org (Postfix) with ESMTP id DBD7B8FC1B for ; Mon, 5 Oct 2009 17:34:04 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id AE45DB9859; Mon, 5 Oct 2009 10:34:38 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 43A222D601A; Mon, 5 Oct 2009 10:34:04 -0700 (PDT) Message-ID: <4ACA2E0F.5010800@elischer.org> Date: Mon, 05 Oct 2009 10:34:07 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Tom Judge References: <4ACA0549.7030404@tomjudge.com> In-Reply-To: <4ACA0549.7030404@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 17:34:05 -0000 Tom Judge wrote: > Hi, > > Does anyone know of a patch that will add per jail memory limits so that > a jail can't swallow the resources of the entire box? > > > Thanks > > Tom > _______________________________________________ > 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" not yet.. From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 17:33:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B19EE1065692 for ; Mon, 5 Oct 2009 17:33:35 +0000 (UTC) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [78.111.72.186]) by mx1.freebsd.org (Postfix) with SMTP id 16EDF8FC1C for ; Mon, 5 Oct 2009 17:33:34 +0000 (UTC) Received: (qmail 85725 invoked by uid 89); 5 Oct 2009 17:33:32 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (78.111.72.187) by avocado.salatschuessel.net with SMTP; 5 Oct 2009 17:33:32 -0000 Date: Mon, 5 Oct 2009 19:33:40 +0200 From: Oliver Lehmann To: Pawel Jakub Dawidek Message-Id: <20091005193340.cd84f0ec.lehmann@ans-netz.de> In-Reply-To: <20090928184926.GA2016@garage.freebsd.pl> References: <20090927170244.0980d699.lehmann@ans-netz.de> <20090927223725.5893371f.lehmann@ans-netz.de> <20090928084035.GB1659@garage.freebsd.pl> <20090928203756.ef70e0c6.lehmann@ans-netz.de> <20090928184926.GA2016@garage.freebsd.pl> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; amd64-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 05 Oct 2009 17:38:26 +0000 Cc: =?UTF-8?B?U23DuHJncmF2?= , Dag-Erling, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: glabel+gmirror (8.0-RC1 problem) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 17:33:35 -0000 Pawel Jakub Dawidek wrote: > On Mon, Sep 28, 2009 at 08:37:56PM +0200, Oliver Lehmann wrote: > > Hi Pawel, > > > > Pawel Jakub Dawidek wrote: > > > > > Does anything change between you upgrade from BETA3 and RC1? For example > > > gmirror was compiled into the kernel before and now is loaded as module > > > or something similar? > > > > Nope, it was a clean BETA3 installation with the default GENERIC kernel > > which has afaik geom_label in kernel, but not geom_mirror (nevertheless I > > loaded geom_label.ko at boottime as well as geom_mirror) > > The same with RC1 - clean and fresh installation with the default GENERIC > > kernel and geom_label in kernel (default), but still loaded as module at > > boottime as well as geom_mirror. > > > > > Could you test this patch: > > > > > > http://people.freebsd.org/~pjd/patches/improved_taste.patch > > > > This makes gmirror+glabel work again on RC1 > > Thanks for confirmation. gjorunal is also affected. I tried to use one partition of my gmirror disk as journal device for my 3ware raid-5 device which works until I reboot - the journal is then gone as well. Is this patch likly to fix this as well? Will it be included in a future RC? Until now I've stayed away using glabel+gmirror but I didn't knew that gjournal is affected as well so I'm now left with warning that the journal provider is gone wile booting - and more tragically I'm left without journaling at all (which hurts on a 2.7TB partition when the system was not cleanly shut down) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 17:48:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CF3D106566B for ; Mon, 5 Oct 2009 17:48:28 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id C434B8FC08 for ; Mon, 5 Oct 2009 17:48:27 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id CD317489C3; Mon, 5 Oct 2009 18:48:26 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2C0jFYG-ujp; Mon, 5 Oct 2009 18:48:23 +0100 (BST) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id D5617489C2; Mon, 5 Oct 2009 18:48:22 +0100 (BST) Message-ID: <4ACA3146.9090402@tomjudge.com> Date: Mon, 05 Oct 2009 17:47:50 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Julian Elischer References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> In-Reply-To: <4ACA2E0F.5010800@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 17:48:28 -0000 Julian Elischer wrote: > Tom Judge wrote: >> Hi, >> >> Does anyone know of a patch that will add per jail memory limits so >> that a jail can't swallow the resources of the entire box? >> >> >> Thanks >> >> Tom >> _______________________________________________ >> 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" > > > not yet.. > I started to port this to 7.1 today: http://wiki.freebsd.org/JailResourceLimits What are the peoples opinions on this patch? Tom From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 18:08:42 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B275106566B for ; Mon, 5 Oct 2009 18:08:42 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id EA8678FC1B for ; Mon, 5 Oct 2009 18:08:41 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id B4CC76D41B; Mon, 5 Oct 2009 18:08:40 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 85072844DE; Mon, 5 Oct 2009 20:08:40 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Hiroki Sato References: <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <20091005055806.GB58246@zibbi.meraka.csir.co.za> <20091005.182342.167950100.hrs@allbsd.org> Date: Mon, 05 Oct 2009 20:08:40 +0200 In-Reply-To: <20091005.182342.167950100.hrs@allbsd.org> (Hiroki Sato's message of "Mon, 05 Oct 2009 18:23:42 +0900 (JST)") Message-ID: <86my45vhlj.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: jhay@meraka.org.za, freebsd-current@FreeBSD.org, freebsd-rc@FreeBSD.org Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 18:08:42 -0000 Hiroki Sato writes: > John Hay writes: > > Is there a good reason why we still ship with ipv6 off by default? > What do you mean by "off by default"? I think IPv6 is not disabled by > default with the patch. % ident /usr/src/etc/defaults/rc.conf=20 /usr/src/etc/defaults/rc.conf: $FreeBSD: head/etc/defaults/rc.conf 197619 2009-09-29 16:49:10Z dougb $ % grep ipv6_network_interfaces /usr/src/etc/defaults/rc.conf ipv6_network_interfaces=3D"none" # List of IPv6 network interfaces #ipv6_network_interfaces=3D"ed0 ep0" # Examples for router % grep ipv6_prefer /usr/src/etc/defaults/rc.conf=20 ipv6_prefer=3D"NO" # Use IPv6 when both IPv4 and IPv6 can be used Does mean that IPv6 is disabled by default? Who knows? There is no coherent explanation *anywhere* of what these variables mean, and rc.conf(5) does not mention them at all. In fact, the first hit for "ipv6" in rc.conf(5) is this: ipv6_enable (bool) Enable support for IPv6 networking. Note that this requires that the kernel has been compiled with options INET6. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 18:29:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61D861065672 for ; Mon, 5 Oct 2009 18:29:58 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id E48218FC08 for ; Mon, 5 Oct 2009 18:29:57 +0000 (UTC) Received: by fxm22 with SMTP id 22so3223839fxm.36 for ; Mon, 05 Oct 2009 11:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=8UTDun93m0kpoU9rgWFDDEcVeQI3QuiBySiFH40mbbk=; b=g+I4n012ABPH0EqNjzVa7aSyX9ew1wDcg1QJq4Ct1R3WhpADxrou1L/skhFnWbYmQs TMWyp7qyMM830UscEVk6qTIhXixOvVBdoVk1NkBWiXzgAIZM+ZTnb+G0ZZdpnmn2Pnw6 1X/FMwNpLLcQ+oLw+o9lulhfCWFqOIS6H4x1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=fVLfaWfXm14OZTtooat+FIxNh1d/bJbmnwhsvWV/pZvjEqK3RJcuauMHsivHkJiLLX a5uv1B9ot4F9VhPuPQ72YAgXPIqr5PoTaoLbNevO9cD8ZxXoyyeVXbS/xcbWewt9cWFH UbdDN0u56q0drL9aV4YX0ZO+Q0UNCU4fyC7+w= Received: by 10.204.157.21 with SMTP id z21mr4164197bkw.160.1254767396725; Mon, 05 Oct 2009 11:29:56 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 18sm192966fks.10.2009.10.05.11.29.55 (version=SSLv3 cipher=RC4-MD5); Mon, 05 Oct 2009 11:29:55 -0700 (PDT) Sender: Alexander Motin Message-ID: <4ACA3B21.40700@FreeBSD.org> Date: Mon, 05 Oct 2009 21:29:53 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Hans Petter Selasky References: <200909261239.52792.hselasky@c2i.net> In-Reply-To: <200909261239.52792.hselasky@c2i.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 8-current + USB CD-ROM drive + CAM layer audio extraction from CD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 18:29:58 -0000 Hi. Hans Petter Selasky wrote: > It turns out the xmms is not able to read audio from CD's due to a removed > IOCTL. cdparanoia is however able to read audio from CD's after a recompile > including libcam. > > The "CDIOCREADAUDIO" is not implemented in the FreeBSD 8/9-current kernel from > what I can see. cdio.h Revision 1.25 Mon Oct 20 09:29:40 2003 UTC (5 years, 11 months ago) by sos Remove no longer existant CDIOCREADAUDIO ioctl. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 18:35:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A130E1065676 for ; Mon, 5 Oct 2009 18:35:35 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2E8AA8FC13 for ; Mon, 5 Oct 2009 18:35:35 +0000 (UTC) Received: from elmar.spoerlein.net (e180136248.adsl.alicedsl.de [85.180.136.248]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n95IZREY070272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Oct 2009 20:35:28 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: from elmar.spoerlein.net (localhost [127.0.0.1]) by elmar.spoerlein.net (8.14.3/8.14.3) with ESMTP id n95IZRUK003461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Oct 2009 20:35:27 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by elmar.spoerlein.net (8.14.3/8.14.3/Submit) id n95IZQrD003460; Mon, 5 Oct 2009 20:35:26 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Mon, 5 Oct 2009 20:35:26 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Dag-Erling =?utf-8?B?U23DuHJncmF2?= Message-ID: <20091005183526.GA3230@elmar.spoerlein.net> Mail-Followup-To: Dag-Erling =?utf-8?B?U23DuHJncmF2?= , Taku YAMAMOTO , freebsd-current@freebsd.org References: <20091004225000.6a1a6262.taku@tackymt.homeip.net> <86fx9yxfrz.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86fx9yxfrz.fsf@ds4.des.no> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Taku YAMAMOTO , freebsd-current@freebsd.org Subject: Re: pam_ssh no longer works after r197679 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 18:35:35 -0000 On Mon, 05.10.2009 at 13:05:04 +0200, Dag-Erling Smørgrav wrote: > Taku YAMAMOTO writes: > > A quick investigation revailed that libssh.so.5 had some symbols undefined, > > which prevented pam_ssh.so.5 from being loaded. > > # FYI: openpam dlopen()s modules with RTLD_NOW. > > > > Here's interesting bits from nm -D /usr/lib/libssh.so.5 | fgrep U > > U roaming_read > > U roaming_write > > This is weird - I understand what the problem is, but I don't understand > why it didn't break the build. > > As a workaround, try adding roaming_dummy.c to SRCS in pam_ssh's > Makefile. Did the following and everything is back to normal: # cd /usr/src/lib/libpam/modules/pam_ssh # make "SRCS=pam_ssh.c roaming_dummy.c" # make "SRCS=pam_ssh.c roaming_dummy.c" install Cheers, Uli From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 18:42:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37D01106568B for ; Mon, 5 Oct 2009 18:42:08 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-yx0-f184.google.com (mail-yx0-f184.google.com [209.85.210.184]) by mx1.freebsd.org (Postfix) with ESMTP id 974E18FC16 for ; Mon, 5 Oct 2009 18:42:07 +0000 (UTC) Received: by yxe14 with SMTP id 14so4226867yxe.7 for ; Mon, 05 Oct 2009 11:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=f7TF4NPbiPtHTqcm6tjaVIhM39TB6totroU4ftcGr1U=; b=TLBs6FlOYRnBjMziwj6PGw47UL3kmixipPjeWl8TY1ZoAWfUmD+1uuj51tvuQe7ynp b7FovQydDs1iWlvXMJQdr3wszikbcQz0KRgeQTflK6A541AcY65HhDmgpRpoAb3TDmmv qWpgNV4Y/ZPlCXSDsi2zzMWSaVbiYoWYFysCQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=J81eOpR3K1C/szqXY6/H+TFOm3M0MMcByxIVm5pKvTtjqWe4hehuQGpMcgIhTxGp91 tzbzxzMwaDEcnDeNpSRfh93aKiWZBUPuHNdzlE08UQWGJ/hjnkdJMhrHLMegozCRJvRl vpNEKgfY2EjWBo9kHv9VTeEVbfpaTj9hYmEzw= MIME-Version: 1.0 Received: by 10.150.238.1 with SMTP id l1mr604205ybh.68.1254768126907; Mon, 05 Oct 2009 11:42:06 -0700 (PDT) In-Reply-To: <4ACA3146.9090402@tomjudge.com> References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> Date: Mon, 5 Oct 2009 13:42:06 -0500 Message-ID: <6201873e0910051142q58e7563fqc7735261ea9ab3c6@mail.gmail.com> From: Adam Vande More To: Tom Judge Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Julian Elischer Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 18:42:08 -0000 On Mon, Oct 5, 2009 at 12:47 PM, Tom Judge wrote: > Julian Elischer wrote: > >> Tom Judge wrote: >> >>> Hi, >>> >>> Does anyone know of a patch that will add per jail memory limits so that >>> a jail can't swallow the resources of the entire box? >>> >>> >>> Thanks >>> >>> Tom >>> _______________________________________________ >>> 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" >>> >> >> >> not yet.. >> >> > I started to port this to 7.1 today: > > http://wiki.freebsd.org/JailResourceLimits > > > What are the peoples opinions on this patch? > > > Tom > If you're soliciting opinions if this will be used and is needed, I would love to see this functionality. This is the main reason I've had to chose XEN over jails. If you need some help testing, let me know. -- Adam Vande More From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 18:46:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28DD2106568F for ; Mon, 5 Oct 2009 18:46:37 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id D6F7F8FC24 for ; Mon, 5 Oct 2009 18:46:36 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id BB1FA6D44C; Mon, 5 Oct 2009 18:46:35 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id A1B95844E4; Mon, 5 Oct 2009 20:46:35 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Taku YAMAMOTO References: <20091004225000.6a1a6262.taku@tackymt.homeip.net> <86fx9yxfrz.fsf@ds4.des.no> <20091005183526.GA3230@elmar.spoerlein.net> Date: Mon, 05 Oct 2009 20:46:35 +0200 In-Reply-To: <20091005183526.GA3230@elmar.spoerlein.net> ("Ulrich =?utf-8?Q?Sp=C3=B6rlein=22's?= message of "Mon, 5 Oct 2009 20:35:26 +0200") Message-ID: <86iqetvfuc.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: pam_ssh no longer works after r197679 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 18:46:37 -0000 Ulrich Sp=C3=B6rlein writes: > Did the following and everything is back to normal: > > # cd /usr/src/lib/libpam/modules/pam_ssh > # make "SRCS=3Dpam_ssh.c roaming_dummy.c" > # make "SRCS=3Dpam_ssh.c roaming_dummy.c" install Thanks, I'll commit the proper fix right away. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 18:46:53 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3274F106568D for ; Mon, 5 Oct 2009 18:46:53 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id E19F48FC08 for ; Mon, 5 Oct 2009 18:46:52 +0000 (UTC) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1MusaB-000Hhq-N6 for freebsd-current@FreeBSD.org; Mon, 05 Oct 2009 22:46:51 +0400 From: Boris Samorodov To: freebsd-current@FreeBSD.org Date: Mon, 05 Oct 2009 22:46:51 +0400 Message-ID: <78132948@bb.ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: abort acroread at today's -current, but OK at 03-Oct -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 18:46:53 -0000 Hello List, today I updated my computer from 03-Oct CURRENT to -current and some ports were updated. And have got an error: ----- % acroread zsh: abort acroread % /bin/sh -x `which acroread` + echo '' + tr a-z A-Z + ADOBE_LANG='' + : ENU + BN=acroread + VN='' + [ -d /usr/local/Adobe/Reader8 ] + ADOBE_VER=8 + [ -d /usr/local/Adobe/Reader9 ] + ACROBASE=Adobe/Reader8 + BINPREFIX=Adobe/Reader8/bin + MOZILLA_COMP_PATH=/..//usr/local/lib/linux-nvu + export MOZILLA_COMP_PATH + GTK_IM_MODULE=xim + export GTK_IM_MODULE + UNAME_s=Linux + export UNAME_s + [ -x /usr/local/Adobe/Reader8/ENU/Adobe/Reader8/bin/acroread ] + exec /compat/linux/bin/sh /usr/local/Adobe/Reader8/ENU/Adobe/Reader8/bin/acroread zsh: abort /bin/sh -x `which acroread` ----- Loading old kernel gives a working acroread. What did I miss? Thanks. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 18:54:13 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03BAB1065672; Mon, 5 Oct 2009 18:54:13 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id DB4EE8FC16; Mon, 5 Oct 2009 18:54:12 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n95Is8Lb016473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Oct 2009 11:54:08 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 728471CC0E; Mon, 5 Oct 2009 11:54:08 -0700 (PDT) To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= In-reply-to: Your message of "Mon, 05 Oct 2009 20:08:40 +0200." <86my45vhlj.fsf@ds4.des.no> Date: Mon, 05 Oct 2009 11:54:08 -0700 From: "Kevin Oberman" Message-Id: <20091005185408.728471CC0E@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-10-05_12:2009-09-29, 2009-10-05, 2009-10-05 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-0910050111 Cc: jhay@meraka.org.za, freebsd-current@FreeBSD.org, Hiroki Sato , freebsd-rc@FreeBSD.org Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 18:54:13 -0000 > From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= > Date: Mon, 05 Oct 2009 20:08:40 +0200 > Sender: owner-freebsd-current@freebsd.org > > Hiroki Sato writes: > > John Hay writes: > > > Is there a good reason why we still ship with ipv6 off by default? > > What do you mean by "off by default"? I think IPv6 is not disabled by > > default with the patch. > > % ident /usr/src/etc/defaults/rc.conf > /usr/src/etc/defaults/rc.conf: > $FreeBSD: head/etc/defaults/rc.conf 197619 2009-09-29 16:49:10Z dougb $ > % grep ipv6_network_interfaces /usr/src/etc/defaults/rc.conf > ipv6_network_interfaces="none" # List of IPv6 network interfaces > #ipv6_network_interfaces="ed0 ep0" # Examples for router > % grep ipv6_prefer /usr/src/etc/defaults/rc.conf > ipv6_prefer="NO" # Use IPv6 when both IPv4 and IPv6 can be used > > Does mean that IPv6 is disabled by default? Who knows? There is no > coherent explanation *anywhere* of what these variables mean, and > rc.conf(5) does not mention them at all. In fact, the first hit for > "ipv6" in rc.conf(5) is this: > > ipv6_enable > (bool) Enable support for IPv6 networking. Note that this > requires that the kernel has been compiled with options > INET6. Am I missing something here? From the same /etc/defaults/rc.conf: ### IPv6 options: ### ipv6_enable="NO" # Set to YES to set up for IPv6. That looks about a "disabled out of the box" as it gets. As far as I can see (which may not be far), ipv6_network_interfaces is only relevant to IPv6 routing. I believe that ipv6_prefer controls the default behavior when DNS returns both IPv4 and IPv6 addresses for a host. If it is set to "NO", IPv4 will be tried first (preferred). If set to "YES", the IPv6 address will be preferred. I strongly recommend keeping ipv6_prefer set to "NO". -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 18:55:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84EDF106568B for ; Mon, 5 Oct 2009 18:55:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 405BA8FC1A for ; Mon, 5 Oct 2009 18:55:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id BC7B341C70C; Mon, 5 Oct 2009 20:55:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id pHLU5+IRVI93; Mon, 5 Oct 2009 20:55:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id E1BD741C712; Mon, 5 Oct 2009 20:55:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id C216F4448E6; Mon, 5 Oct 2009 18:53:18 +0000 (UTC) Date: Mon, 5 Oct 2009 18:53:18 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Boris Samorodov In-Reply-To: <78132948@bb.ipt.ru> Message-ID: <20091005185230.K5956@maildrop.int.zabbadoz.net> References: <78132948@bb.ipt.ru> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: abort acroread at today's -current, but OK at 03-Oct -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 18:55:08 -0000 On Mon, 5 Oct 2009, Boris Samorodov wrote: Hi, > today I updated my computer from 03-Oct CURRENT to -current and > some ports were updated. And have got an error: > ----- > % acroread > zsh: abort acroread > % /bin/sh -x `which acroread` > + echo '' > + tr a-z A-Z > + ADOBE_LANG='' > + : ENU > + BN=acroread > + VN='' > + [ -d /usr/local/Adobe/Reader8 ] > + ADOBE_VER=8 > + [ -d /usr/local/Adobe/Reader9 ] > + ACROBASE=Adobe/Reader8 > + BINPREFIX=Adobe/Reader8/bin > + MOZILLA_COMP_PATH=/..//usr/local/lib/linux-nvu > + export MOZILLA_COMP_PATH > + GTK_IM_MODULE=xim > + export GTK_IM_MODULE > + UNAME_s=Linux > + export UNAME_s > + [ -x /usr/local/Adobe/Reader8/ENU/Adobe/Reader8/bin/acroread ] > + exec /compat/linux/bin/sh /usr/local/Adobe/Reader8/ENU/Adobe/Reader8/bin/acroread > zsh: abort /bin/sh -x `which acroread` > ----- > > Loading old kernel gives a working acroread. What did I miss? > Thanks. The euqivalent patch of: http://security.freebsd.org/advisories/FreeBSD-EN-09:05.null.asc See the thread on stable@ for more background. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 19:00:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E3661065670; Mon, 5 Oct 2009 19:00:07 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe13.swipnet.se [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id B21368FC15; Mon, 5 Oct 2009 19:00:05 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=XHM-INoyEekA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=BWEx_hUbjVuLrdGuXS4A:9 a=NHhx7jvhs4r8Q2R__SEA:7 a=rC4LTO0MGupdbnHq2h2LzEBPLZkA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe13.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 928336322; Mon, 05 Oct 2009 21:00:02 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 5 Oct 2009 21:00:52 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200909261239.52792.hselasky@c2i.net> <4ACA3B21.40700@FreeBSD.org> In-Reply-To: <4ACA3B21.40700@FreeBSD.org> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910052100.53186.hselasky@c2i.net> Cc: Alexander Motin Subject: Re: 8-current + USB CD-ROM drive + CAM layer audio extraction from CD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 19:00:07 -0000 On Monday 05 October 2009 20:29:53 Alexander Motin wrote: > Hi. > > Hans Petter Selasky wrote: > > It turns out the xmms is not able to read audio from CD's due to a > > removed IOCTL. cdparanoia is however able to read audio from CD's after a > > recompile including libcam. > > > > The "CDIOCREADAUDIO" is not implemented in the FreeBSD 8/9-current kernel > > from what I can see. > > cdio.h Revision 1.25 > Mon Oct 20 09:29:40 2003 UTC (5 years, 11 months ago) by sos > > Remove no longer existant CDIOCREADAUDIO ioctl. Ok, maybe I have some old sources left in my tree then :-) --HPS From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 19:00:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6D1B10656C6 for ; Mon, 5 Oct 2009 19:00:14 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id 680D98FC0A for ; Mon, 5 Oct 2009 19:00:14 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 27881489C9; Mon, 5 Oct 2009 20:00:13 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaxSpm1Cn6nD; Mon, 5 Oct 2009 20:00:08 +0100 (BST) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id A69A4489C7; Mon, 5 Oct 2009 20:00:07 +0100 (BST) Message-ID: <4ACA4216.9060008@tomjudge.com> Date: Mon, 05 Oct 2009 18:59:34 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Adam Vande More References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> <6201873e0910051142q58e7563fqc7735261ea9ab3c6@mail.gmail.com> In-Reply-To: <6201873e0910051142q58e7563fqc7735261ea9ab3c6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 19:00:14 -0000 Adam Vande More wrote: > On Mon, Oct 5, 2009 at 12:47 PM, Tom Judge > wrote: > > Julian Elischer wrote: > > Tom Judge wrote: > > Hi, > > Does anyone know of a patch that will add per jail memory > limits so that a jail can't swallow the resources of the > entire box? > > > Thanks > > Tom > _______________________________________________ > 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 > " > > > > not yet.. > > > I started to port this to 7.1 today: > > http://wiki.freebsd.org/JailResourceLimits > > > What are the peoples opinions on this patch? > > > Tom > > > If you're soliciting opinions if this will be used and is needed, I > would love to see this functionality. This is the main reason I've > had to chose XEN over jails. If you need some help testing, let me know. > > -- > Adam Vande More Hi Adam, I have a patch against 7.1 here: http://svn.tomjudge.com/freebsd/patches/jail-resource-limits/jail-limits.patch I will try to bring the patch up to current when I get a chance but I have no real need to do this as we use 7.1 in production. Notes: * CPU limiting is not support is not supported unless you use shecd_4bsd. * I have not tested this on any system yet, just compile tested, I am putting it though its paces right now. Tom From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 19:02:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 725181065694 for ; Mon, 5 Oct 2009 19:02:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id C08388FC1B for ; Mon, 5 Oct 2009 19:02:25 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n95J2DDr045925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Oct 2009 22:02:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n95J2Dc7094613; Mon, 5 Oct 2009 22:02:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n95J2DLu094612; Mon, 5 Oct 2009 22:02:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 5 Oct 2009 22:02:13 +0300 From: Kostik Belousov To: Tom Judge Message-ID: <20091005190213.GV2259@deviant.kiev.zoral.com.ua> References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r+TdwuXy+OXS8TUs" Content-Disposition: inline In-Reply-To: <4ACA3146.9090402@tomjudge.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, Julian Elischer Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 19:02:26 -0000 --r+TdwuXy+OXS8TUs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 05, 2009 at 05:47:50PM +0000, Tom Judge wrote: > Julian Elischer wrote: > >Tom Judge wrote: > >>Hi, > >> > >>Does anyone know of a patch that will add per jail memory limits so=20 > >>that a jail can't swallow the resources of the entire box? > >> > >> > >>Thanks > >> > >>Tom > >>_______________________________________________ > >>freebsd-current@freebsd.org mailing list > >>http://lists.freebsd.org/mailman/listinfo/freebsd-current > >>To unsubscribe, send any mail to=20 > >>"freebsd-current-unsubscribe@freebsd.org" > > > > > >not yet.. > > >=20 > I started to port this to 7.1 today: >=20 > http://wiki.freebsd.org/JailResourceLimits >=20 >=20 > What are the peoples opinions on this patch? Since r194766, we have precise accounting for the anonymous memory, both globally and per-uid. If current jails infrastructure allows to set per-jail limits (and I suspect that it is), then you should just match these two facilities. The seemingly problematic thing is processes changing their jails. It can be done similar to how the uid accounting is done currently, by remembering which jail was charged in corresponding vm map entry and object. --r+TdwuXy+OXS8TUs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrKQrQACgkQC3+MBN1Mb4jzcwCeP/t+PM0oHHSpULzh8sAJxJ51 9PYAmwenDGcBWDinZcZ2nU2v8kRtKsZ2 =kyp7 -----END PGP SIGNATURE----- --r+TdwuXy+OXS8TUs-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 19:02:26 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ED181065696 for ; Mon, 5 Oct 2009 19:02:26 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 49DCA8FC1C for ; Mon, 5 Oct 2009 19:02:26 +0000 (UTC) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1MuspF-000HtP-8B; Mon, 05 Oct 2009 23:02:25 +0400 From: Boris Samorodov To: "Bjoern A. Zeeb" References: <78132948@bb.ipt.ru> <20091005185230.K5956@maildrop.int.zabbadoz.net> Date: Mon, 05 Oct 2009 23:02:24 +0400 In-Reply-To: <20091005185230.K5956@maildrop.int.zabbadoz.net> (Bjoern A. Zeeb's message of "Mon, 5 Oct 2009 18:53:18 +0000 (UTC)") Message-ID: <12055407@bb.ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org Subject: Re: abort acroread at today's -current, but OK at 03-Oct -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 19:02:26 -0000 On Mon, 5 Oct 2009 18:53:18 +0000 (UTC) Bjoern A. Zeeb wrote: > The euqivalent patch of: > http://security.freebsd.org/advisories/FreeBSD-EN-09:05.null.asc > See the thread on stable@ for more background. Well, I've read about it at stable@, security@, etc. Couldn't imagine that that's the case here. Setting security.bsd.map_at_zero=1 helps here. Thanks for the quick answer! -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 19:06:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A10AB1065672 for ; Mon, 5 Oct 2009 19:06:31 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id 627228FC1A for ; Mon, 5 Oct 2009 19:06:31 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id B8061489D2; Mon, 5 Oct 2009 20:06:29 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MI3wsWWRjc3S; Mon, 5 Oct 2009 20:06:27 +0100 (BST) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 89C34489D0; Mon, 5 Oct 2009 20:06:26 +0100 (BST) Message-ID: <4ACA4391.6020607@tomjudge.com> Date: Mon, 05 Oct 2009 19:05:53 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Kostik Belousov References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> <20091005190213.GV2259@deviant.kiev.zoral.com.ua> In-Reply-To: <20091005190213.GV2259@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 19:06:31 -0000 Kostik Belousov wrote: > On Mon, Oct 05, 2009 at 05:47:50PM +0000, Tom Judge wrote: > >> I started to port this to 7.1 today: >> >> http://wiki.freebsd.org/JailResourceLimits >> >> >> What are the peoples opinions on this patch? >> > > Since r194766, we have precise accounting for the anonymous memory, > both globally and per-uid. If current jails infrastructure allows to > set per-jail limits (and I suspect that it is), then you should > just match these two facilities. > > The seemingly problematic thing is processes changing their jails. > It can be done similar to how the uid accounting is done currently, > by remembering which jail was charged in corresponding vm map > entry and object. > Did this get MFC'd to stable/7? I have a requirement to implement this for 7.1. Thanks From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 19:07:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A4D710656A8 for ; Mon, 5 Oct 2009 19:07:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id F185A8FC16 for ; Mon, 5 Oct 2009 19:07:16 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n95J7AmK046217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Oct 2009 22:07:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n95J7AKI094630; Mon, 5 Oct 2009 22:07:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n95J7Ahx094629; Mon, 5 Oct 2009 22:07:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 5 Oct 2009 22:07:10 +0300 From: Kostik Belousov To: Boris Samorodov Message-ID: <20091005190710.GW2259@deviant.kiev.zoral.com.ua> References: <78132948@bb.ipt.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8bLSEqNM5P+Jqlqx" Content-Disposition: inline In-Reply-To: <78132948@bb.ipt.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: abort acroread at today's -current, but OK at 03-Oct -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 19:07:17 -0000 --8bLSEqNM5P+Jqlqx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 05, 2009 at 10:46:51PM +0400, Boris Samorodov wrote: > Hello List, >=20 > today I updated my computer from 03-Oct CURRENT to -current and > some ports were updated. And have got an error: > ----- > % acroread > zsh: abort acroread > % /bin/sh -x `which acroread` > + echo '' > + tr a-z A-Z > + ADOBE_LANG=3D'' > + : ENU > + BN=3Dacroread > + VN=3D'' > + [ -d /usr/local/Adobe/Reader8 ] > + ADOBE_VER=3D8 > + [ -d /usr/local/Adobe/Reader9 ] > + ACROBASE=3DAdobe/Reader8 > + BINPREFIX=3DAdobe/Reader8/bin > + MOZILLA_COMP_PATH=3D/..//usr/local/lib/linux-nvu > + export MOZILLA_COMP_PATH > + GTK_IM_MODULE=3Dxim > + export GTK_IM_MODULE > + UNAME_s=3DLinux > + export UNAME_s > + [ -x /usr/local/Adobe/Reader8/ENU/Adobe/Reader8/bin/acroread ] > + exec /compat/linux/bin/sh /usr/local/Adobe/Reader8/ENU/Adobe/Reader8/bi= n/acroread > zsh: abort /bin/sh -x `which acroread` > ----- >=20 > Loading old kernel gives a working acroread. What did I miss? > Thanks. Try this. diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c index 4ed7382..e958214 100644 --- a/sys/kern/imgact_elf.c +++ b/sys/kern/imgact_elf.c @@ -635,7 +635,8 @@ __elfN(load_file)(struct proc *p, const char *file, u_l= ong *addr, } =20 for (i =3D 0, numsegs =3D 0; i < hdr->e_phnum; i++) { - if (phdr[i].p_type =3D=3D PT_LOAD) { /* Loadable segment */ + if (phdr[i].p_type =3D=3D PT_LOAD && phdr[i].p_memsz !=3D 0) { + /* Loadable segment */ prot =3D 0; if (phdr[i].p_flags & PF_X) prot |=3D VM_PROT_EXECUTE; @@ -764,6 +768,8 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *im= gp) for (i =3D 0; i < hdr->e_phnum; i++) { switch (phdr[i].p_type) { case PT_LOAD: /* Loadable segment */ + if (phdr[i].p_memsz =3D=3D 0) + break; prot =3D 0; if (phdr[i].p_flags & PF_X) prot |=3D VM_PROT_EXECUTE; --8bLSEqNM5P+Jqlqx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrKQ90ACgkQC3+MBN1Mb4gU+QCfVFyhQ3HwL8V9dh7ud/BJ0adn HsEAoJngsGVAq/q/GTR6Je270uQImlIr =9gYq -----END PGP SIGNATURE----- --8bLSEqNM5P+Jqlqx-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 19:09:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 073E8106566B for ; Mon, 5 Oct 2009 19:09:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 44F778FC14 for ; Mon, 5 Oct 2009 19:09:39 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n95J9Z7k046325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Oct 2009 22:09:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n95J9YIN094674; Mon, 5 Oct 2009 22:09:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n95J9Y1Q094673; Mon, 5 Oct 2009 22:09:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 5 Oct 2009 22:09:34 +0300 From: Kostik Belousov To: Tom Judge Message-ID: <20091005190934.GX2259@deviant.kiev.zoral.com.ua> References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> <20091005190213.GV2259@deviant.kiev.zoral.com.ua> <4ACA4391.6020607@tomjudge.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="21/Vc5rId7THQcsT" Content-Disposition: inline In-Reply-To: <4ACA4391.6020607@tomjudge.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 19:09:40 -0000 --21/Vc5rId7THQcsT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 05, 2009 at 07:05:53PM +0000, Tom Judge wrote: > Kostik Belousov wrote: > >On Mon, Oct 05, 2009 at 05:47:50PM +0000, Tom Judge wrote: > > =20 > >>I started to port this to 7.1 today: > >> > >>http://wiki.freebsd.org/JailResourceLimits > >> > >> > >>What are the peoples opinions on this patch? > >> =20 > > > >Since r194766, we have precise accounting for the anonymous memory, > >both globally and per-uid. If current jails infrastructure allows to > >set per-jail limits (and I suspect that it is), then you should > >just match these two facilities. > > > >The seemingly problematic thing is processes changing their jails. > >It can be done similar to how the uid accounting is done currently, > >by remembering which jail was charged in corresponding vm map > >entry and object. > > =20 >=20 > Did this get MFC'd to stable/7? No, and never will be. >=20 > I have a requirement to implement this for 7.1. >=20 > Thanks --21/Vc5rId7THQcsT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrKRG4ACgkQC3+MBN1Mb4g+yACgrRE88p4H/OTIWfTDeNaXJSba PwAAnAlBqDP2YsAaRVaRAEKfikJyQX74 =EX+Z -----END PGP SIGNATURE----- --21/Vc5rId7THQcsT-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 19:12:35 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61A08106566B; Mon, 5 Oct 2009 19:12:35 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 19EDB8FC1D; Mon, 5 Oct 2009 19:12:34 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id F38366D41B; Mon, 5 Oct 2009 19:12:33 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id C84A4844EF; Mon, 5 Oct 2009 21:12:33 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Kevin Oberman" References: <20091005185408.728471CC0E@ptavv.es.net> Date: Mon, 05 Oct 2009 21:12:33 +0200 In-Reply-To: <20091005185408.728471CC0E@ptavv.es.net> (Kevin Oberman's message of "Mon, 05 Oct 2009 11:54:08 -0700") Message-ID: <86ab05ven2.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: jhay@meraka.org.za, freebsd-current@FreeBSD.org, Hiroki Sato , freebsd-rc@FreeBSD.org Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 19:12:35 -0000 "Kevin Oberman" writes: > Am I missing something here? From the same /etc/defaults/rc.conf: > ### IPv6 options: ### > ipv6_enable=3D"NO" # Set to YES to set up for IPv6. > > That looks about a "disabled out of the box" as it gets. AFAIK, ipv6_enable has no effect. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 19:13:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3A651065693 for ; Mon, 5 Oct 2009 19:13:29 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id 848038FC27 for ; Mon, 5 Oct 2009 19:13:29 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 87181489D2; Mon, 5 Oct 2009 20:13:28 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOfO6JFEWE7M; Mon, 5 Oct 2009 20:13:25 +0100 (BST) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 8EE0F489C9; Mon, 5 Oct 2009 20:13:23 +0100 (BST) Message-ID: <4ACA4532.5000303@tomjudge.com> Date: Mon, 05 Oct 2009 19:12:50 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Kostik Belousov References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> <20091005190213.GV2259@deviant.kiev.zoral.com.ua> <4ACA4391.6020607@tomjudge.com> <20091005190934.GX2259@deviant.kiev.zoral.com.ua> In-Reply-To: <20091005190934.GX2259@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 19:13:29 -0000 Kostik Belousov wrote: > On Mon, Oct 05, 2009 at 07:05:53PM +0000, Tom Judge wrote: > >> Kostik Belousov wrote: >> >>> On Mon, Oct 05, 2009 at 05:47:50PM +0000, Tom Judge wrote: >>> >>> >>>> I started to port this to 7.1 today: >>>> >>>> http://wiki.freebsd.org/JailResourceLimits >>>> >>>> >>>> What are the peoples opinions on this patch? >>>> >>>> >>> Since r194766, we have precise accounting for the anonymous memory, >>> both globally and per-uid. If current jails infrastructure allows to >>> set per-jail limits (and I suspect that it is), then you should >>> just match these two facilities. >>> >>> The seemingly problematic thing is processes changing their jails. >>> It can be done similar to how the uid accounting is done currently, >>> by remembering which jail was charged in corresponding vm map >>> entry and object. >>> >>> >> Did this get MFC'd to stable/7? >> > No, and never will be. > Could you possibly expand on the reasons why this will never be MFC'd? Thanks Tom From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 19:17:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD770106566B for ; Mon, 5 Oct 2009 19:17:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id DE2CD8FC16 for ; Mon, 5 Oct 2009 19:17:58 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n95JHrGV046863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Oct 2009 22:17:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n95JHriE094743; Mon, 5 Oct 2009 22:17:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n95JHrIK094742; Mon, 5 Oct 2009 22:17:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 5 Oct 2009 22:17:53 +0300 From: Kostik Belousov To: Tom Judge Message-ID: <20091005191753.GZ2259@deviant.kiev.zoral.com.ua> References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> <20091005190213.GV2259@deviant.kiev.zoral.com.ua> <4ACA4391.6020607@tomjudge.com> <20091005190934.GX2259@deviant.kiev.zoral.com.ua> <4ACA4532.5000303@tomjudge.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kUmJ0kIGcKOYePjT" Content-Disposition: inline In-Reply-To: <4ACA4532.5000303@tomjudge.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 19:17:59 -0000 --kUmJ0kIGcKOYePjT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 05, 2009 at 07:12:50PM +0000, Tom Judge wrote: > Kostik Belousov wrote: > >On Mon, Oct 05, 2009 at 07:05:53PM +0000, Tom Judge wrote: > > =20 > >>Kostik Belousov wrote: > >> =20 > >>>On Mon, Oct 05, 2009 at 05:47:50PM +0000, Tom Judge wrote: > >>>=20 > >>> =20 > >>>>I started to port this to 7.1 today: > >>>> > >>>>http://wiki.freebsd.org/JailResourceLimits > >>>> > >>>> > >>>>What are the peoples opinions on this patch? > >>>> =20 > >>>> =20 > >>>Since r194766, we have precise accounting for the anonymous memory, > >>>both globally and per-uid. If current jails infrastructure allows to > >>>set per-jail limits (and I suspect that it is), then you should > >>>just match these two facilities. > >>> > >>>The seemingly problematic thing is processes changing their jails. > >>>It can be done similar to how the uid accounting is done currently, > >>>by remembering which jail was charged in corresponding vm map > >>>entry and object. > >>>=20 > >>> =20 > >>Did this get MFC'd to stable/7? > >> =20 > >No, and never will be. > > =20 >=20 > Could you possibly expand on the reasons why this will never be MFC'd? One reason is that r194766 is intrusive patch. Another issue is that some VM algorithms are different in 7 and 8/HEAD, and I have no intent or incentive to do backporting. --kUmJ0kIGcKOYePjT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrKRmAACgkQC3+MBN1Mb4jr6QCfdji0cXBcH4027YxTsOTNtzlN SgkAoKKsoAlkW4zixxYy8xV63ak7coc2 =oWJH -----END PGP SIGNATURE----- --kUmJ0kIGcKOYePjT-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 19:19:59 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05E21106568B for ; Mon, 5 Oct 2009 19:19:59 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id ABCC58FC1A for ; Mon, 5 Oct 2009 19:19:58 +0000 (UTC) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id n95JJvnI071479; Mon, 5 Oct 2009 13:19:58 -0600 (MDT) Message-ID: <4ACA46D8.8010504@FreeBSD.org> Date: Mon, 05 Oct 2009 13:19:52 -0600 From: Jamie Gritton User-Agent: Thunderbird 2.0.0.19 (X11/20090109) MIME-Version: 1.0 To: Tom Judge References: <4ACA0549.7030404@tomjudge.com> In-Reply-To: <4ACA0549.7030404@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 19:19:59 -0000 Tom Judge wrote: > Does anyone know of a patch that will add per jail memory limits so that > a jail can't swallow the resources of the entire box? Edward Tomasz Napierala has been working on a general resource limit framework, including jails and memory limits. You can find it at: http://p4db.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2009/trasz_limits - Jamie From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 19:21:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2165A1065670 for ; Mon, 5 Oct 2009 19:21:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 140E58FC20 for ; Mon, 5 Oct 2009 19:21:49 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n95JLiYM047061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Oct 2009 22:21:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n95JLiwf094776; Mon, 5 Oct 2009 22:21:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n95JLi4P094775; Mon, 5 Oct 2009 22:21:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 5 Oct 2009 22:21:44 +0300 From: Kostik Belousov To: Jilles Tjoelker Message-ID: <20091005192144.GA2259@deviant.kiev.zoral.com.ua> References: <20091001120730.GR3130@deviant.kiev.zoral.com.ua> <20091002201213.GA16633@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCPLy5NpE1Kdjj9y" Content-Disposition: inline In-Reply-To: <20091002201213.GA16633@stack.nl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, Justin Teller Subject: Re: Signals and an exiting thread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 19:21:51 -0000 --FCPLy5NpE1Kdjj9y Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 02, 2009 at 10:12:13PM +0200, Jilles Tjoelker wrote: > On Thu, Oct 01, 2009 at 03:07:30PM +0300, Kostik Belousov wrote: > > On Wed, Sep 30, 2009 at 11:02:19AM -0700, Justin Teller wrote: > > > We're trying to control one process from another process through > > > signals (I know, revolutionary ;-), and we've found that a signal > > > occasionally gets lost. =9AThe process we're signaling is > > > multi-threaded. =9AIt looks like the signal is lost when the kernel > > > decides to post the signal to a thread that is in the process of dying > > > (calling pthread_exit, etc). >=20 > > > Is this expected behavior that we should just handle, or is it a race > > > in the kernel that should be/will be/already is fixed? >=20 > > > It may be that a fix is already in current, and I just haven't found > > > it in my searches through the source code (I'm working off of source > > > code for an older 8.0 image). If it is fixed, I'd appreciate a > > > pointer to the code that fixes it. >=20 > > When thread enters the kernel last time to be killed, it is very much > > bad idea to allow it to return to usermode to handle directed signal. > > And, there would always be window between entering the kernel and > > marking the thread as exiting. >=20 > > Moving the thread-directed signals back to the process queue is hard > > and there is no way to distinguish which signals were sent to process > > or to the thread. >=20 > > Possibly, we could clear the thread signal mask while still in user mod= e. > > I think it would still leave a very narrow window when a process > > signal could be directed to the dying thread and not be delivered to > > usermode; this happens when signal is generated while sigsetmask already > > entered the kernel, but did not changed the mask yet. This is worked > > around by rechecking the pending signals after setting the block mask > > and releasing it if needed. >=20 > SIGKILL cannot be masked. Is it possible that a kill(SIGKILL) is > assigned to a dying thread and lost? >=20 > (SIGSTOP cannot be masked either, but its processing is done by the > sending thread, so it should be safe.) >=20 > I suppose that race can also occur in other uses of pthread_sigmask(). > If a thread masks a signal for a while, and that signal is assigned to > that thread just as it is executing pthread_sigmask(), it will only be > processed when that thread unblocks or accepts it, even though other > threads may have the signal unmasked or be in a sigwait() for it. > Signals sent after pthread_sigmask() has changed the signal mask are > likely processed sooner because they will be assigned to a different > thread or left in the process queue. >=20 > POSIX seems to say that signals generated for the process should remain > queued for the process and should only be assigned to a thread at time > of delivery. >=20 > This could be implemented by leaving signals in the process queue or by > tracking for each signal in the thread queue whether it was directed at > the thread and moving the process signals back at sigmask/thr_exit. > Either way I am not sure of all the consequences at this time. I agree that postponing assignment of the thread for signal delivery till the actual delivery occurs is the proper fix. I tried to cheat in my previous patch. Below is an experimental change that did very minimal testing. diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index 0386fc4..abd9714 100644 --- a/sys/kern/kern_sig.c +++ b/sys/kern/kern_sig.c @@ -581,20 +581,11 @@ void signotify(struct thread *td) { struct proc *p; - sigset_t set; =20 p =3D td->td_proc; =20 PROC_LOCK_ASSERT(p, MA_OWNED); =20 - /* - * If our mask changed we may have to move signal that were - * previously masked by all threads to our sigqueue. - */ - set =3D p->p_sigqueue.sq_signals; - SIGSETNAND(set, td->td_sigmask); - if (! SIGISEMPTY(set)) - sigqueue_move_set(&p->p_sigqueue, &td->td_sigqueue, &set); if (SIGPENDING(td)) { thread_lock(td); td->td_flags |=3D TDF_NEEDSIGCHK | TDF_ASTPENDING; @@ -1985,17 +1976,9 @@ tdsignal(struct proc *p, struct thread *td, int sig,= ksiginfo_t *ksi) KNOTE_LOCKED(&p->p_klist, NOTE_SIGNAL | sig); prop =3D sigprop(sig); =20 - /* - * If the signal is blocked and not destined for this thread, then - * assign it to the process so that we can find it later in the first - * thread that unblocks it. Otherwise, assign it to this thread now. - */ if (td =3D=3D NULL) { td =3D sigtd(p, sig, prop); - if (SIGISMEMBER(td->td_sigmask, sig)) - sigqueue =3D &p->p_sigqueue; - else - sigqueue =3D &td->td_sigqueue; + sigqueue =3D &p->p_sigqueue; } else { KASSERT(td->td_proc =3D=3D p, ("invalid thread")); sigqueue =3D &td->td_sigqueue; @@ -2409,8 +2392,9 @@ issignal(struct thread *td, int stop_allowed) { struct proc *p; struct sigacts *ps; + struct sigqueue *queue; sigset_t sigpending; - int sig, prop, newsig; + int sig, prop, newsig, signo; =20 p =3D td->td_proc; ps =3D p->p_sigacts; @@ -2420,6 +2404,7 @@ issignal(struct thread *td, int stop_allowed) int traced =3D (p->p_flag & P_TRACED) || (p->p_stops & S_SIG); =20 sigpending =3D td->td_sigqueue.sq_signals; + SIGSETOR(sigpending, p->p_sigqueue.sq_signals); SIGSETNAND(sigpending, td->td_sigmask); =20 if (p->p_flag & P_PPWAIT) @@ -2440,6 +2425,7 @@ issignal(struct thread *td, int stop_allowed) */ if (SIGISMEMBER(ps->ps_sigignore, sig) && (traced =3D=3D 0)) { sigqueue_delete(&td->td_sigqueue, sig); + sigqueue_delete(&p->p_sigqueue, sig); continue; } if (p->p_flag & P_TRACED && (p->p_flag & P_PPWAIT) =3D=3D 0) { @@ -2452,12 +2438,18 @@ issignal(struct thread *td, int stop_allowed) =20 if (sig !=3D newsig) { ksiginfo_t ksi; + + queue =3D &td->td_sigqueue; /* * clear old signal. * XXX shrug off debugger, it causes siginfo to * be thrown away. */ - sigqueue_get(&td->td_sigqueue, sig, &ksi); + if (sigqueue_get(queue, sig, &ksi) =3D=3D 0) { + queue =3D &p->p_sigqueue; + signo =3D sigqueue_get(queue, sig, &ksi); + KASSERT(signo =3D=3D sig, ("signo !=3D sig")); + } =20 /* * If parent wants us to take the signal, @@ -2472,7 +2464,7 @@ issignal(struct thread *td, int stop_allowed) * Put the new signal into td_sigqueue. If the * signal is being masked, look for other signals. */ - SIGADDSET(td->td_sigqueue.sq_signals, sig); + SIGADDSET(queue->sq_signals, sig); if (SIGISMEMBER(td->td_sigmask, sig)) continue; signotify(td); @@ -2567,6 +2559,7 @@ issignal(struct thread *td, int stop_allowed) return (sig); } sigqueue_delete(&td->td_sigqueue, sig); /* take the signal! */ + sigqueue_delete(&p->p_sigqueue, sig); } /* NOTREACHED */ } @@ -2613,7 +2606,9 @@ postsig(sig) ps =3D p->p_sigacts; mtx_assert(&ps->ps_mtx, MA_OWNED); ksiginfo_init(&ksi); - sigqueue_get(&td->td_sigqueue, sig, &ksi); + if (sigqueue_get(&td->td_sigqueue, sig, &ksi) =3D=3D 0 && + sigqueue_get(&p->p_sigqueue, sig, &ksi) =3D=3D 0) + return; ksi.ksi_signo =3D sig; if (ksi.ksi_code =3D=3D SI_TIMER) itimer_accept(p, ksi.ksi_timerid, &ksi); diff --git a/sys/kern/subr_trap.c b/sys/kern/subr_trap.c index 6d60ddb..ccf6479 100644 --- a/sys/kern/subr_trap.c +++ b/sys/kern/subr_trap.c @@ -90,6 +90,7 @@ userret(struct thread *td, struct trapframe *frame) =20 CTR3(KTR_SYSC, "userret: thread %p (pid %d, %s)", td, p->p_pid, td->td_name); +#if 0 #ifdef DIAGNOSTIC /* Check that we called signotify() enough. */ PROC_LOCK(p); @@ -100,6 +101,7 @@ userret(struct thread *td, struct trapframe *frame) thread_unlock(td); PROC_UNLOCK(p); #endif +#endif #ifdef KTRACE KTRUSERRET(td); #endif @@ -218,7 +220,14 @@ ast(struct trapframe *framep) ktrcsw(0, 1); #endif } - if (flags & TDF_NEEDSIGCHK) { + + /* + * Check for signals. Unlocked reads of p_pendingcnt or + * p_siglist might cause process-directed signal to be handled + * later. + */ + if (flags & TDF_NEEDSIGCHK || p->p_pendingcnt > 0 || + !SIGISEMPTY(p->p_siglist)) { PROC_LOCK(p); mtx_lock(&p->p_sigacts->ps_mtx); while ((sig =3D cursig(td, SIG_STOP_ALLOWED)) !=3D 0) diff --git a/sys/sys/signalvar.h b/sys/sys/signalvar.h index 89b40f0..680da40 100644 --- a/sys/sys/signalvar.h +++ b/sys/sys/signalvar.h @@ -252,9 +252,10 @@ typedef struct sigqueue { =20 /* Return nonzero if process p has an unmasked pending signal. */ #define SIGPENDING(td) \ - (!SIGISEMPTY((td)->td_siglist) && \ - !sigsetmasked(&(td)->td_siglist, &(td)->td_sigmask)) - + ((!SIGISEMPTY((td)->td_siglist) && \ + !sigsetmasked(&(td)->td_siglist, &(td)->td_sigmask)) || \ + (!SIGISEMPTY((td)->td_proc->p_siglist) && \ + !sigsetmasked(&(td)->td_proc->p_siglist, &(td)->td_sigmask))) /* * Return the value of the pseudo-expression ((*set & ~*mask) !=3D 0). Th= is * is an optimized version of SIGISEMPTY() on a temporary variable diff --git a/tools/regression/sigqueue/sigqtest1/sigqtest1.c b/tools/regres= sion/sigqueue/sigqtest1/sigqtest1.c index 0f40021..f0201c3 100644 --- a/tools/regression/sigqueue/sigqtest1/sigqtest1.c +++ b/tools/regression/sigqueue/sigqtest1/sigqtest1.c @@ -1,12 +1,14 @@ /* $FreeBSD$ */ -#include -#include #include #include +#include +#include +#include =20 int received; =20 -void handler(int sig, siginfo_t *si, void *ctx) +void +handler(int sig, siginfo_t *si, void *ctx) { if (si->si_code !=3D SI_QUEUE) errx(1, "si_code !=3D SI_QUEUE"); @@ -15,7 +17,8 @@ void handler(int sig, siginfo_t *si, void *ctx) received++; } =20 -int main() +int +main() { struct sigaction sa; union sigval val; diff --git a/tools/regression/sigqueue/sigqtest2/sigqtest2.c b/tools/regres= sion/sigqueue/sigqtest2/sigqtest2.c index 078ea81..50b579d 100644 --- a/tools/regression/sigqueue/sigqtest2/sigqtest2.c +++ b/tools/regression/sigqueue/sigqtest2/sigqtest2.c @@ -1,24 +1,29 @@ /* $FreeBSD$ */ -#include -#include -#include -#include #include #include +#include +#include +#include +#include +#include +#include =20 int stop_received; int exit_received; int cont_received; =20 -void job_handler(int sig, siginfo_t *si, void *ctx) +void +job_handler(int sig, siginfo_t *si, void *ctx) { int status; int ret; =20 if (si->si_code =3D=3D CLD_STOPPED) { + printf("%d: stop received\n", si->si_pid); stop_received =3D 1; kill(si->si_pid, SIGCONT); } else if (si->si_code =3D=3D CLD_EXITED) { + printf("%d: exit received\n", si->si_pid); ret =3D waitpid(si->si_pid, &status, 0); if (ret =3D=3D -1) errx(1, "waitpid"); @@ -26,11 +31,13 @@ void job_handler(int sig, siginfo_t *si, void *ctx) errx(1, "!WIFEXITED(status)"); exit_received =3D 1; } else if (si->si_code =3D=3D CLD_CONTINUED) { + printf("%d: cont received\n", si->si_pid); cont_received =3D 1; } } =20 -void job_control_test() +void +job_control_test(void) { struct sigaction sa; pid_t pid; @@ -43,9 +50,12 @@ void job_control_test() stop_received =3D 0; cont_received =3D 0; exit_received =3D 0; + fflush(stdout); pid =3D fork(); if (pid =3D=3D 0) { + printf("child %d\n", getpid()); kill(getpid(), SIGSTOP); + sleep(2); exit(1); } =20 @@ -60,11 +70,13 @@ void job_control_test() printf("job control test OK.\n"); } =20 -void rtsig_handler(int sig, siginfo_t *si, void *ctx) +void +rtsig_handler(int sig, siginfo_t *si, void *ctx) { } =20 -int main() +int +main() { struct sigaction sa; sigset_t set; --FCPLy5NpE1Kdjj9y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrKR0gACgkQC3+MBN1Mb4gzYgCg4iGI9vSCMedPF3wn73LzKV56 Y2sAoJjnIer2nkgQLMpa2dwQSskC3whJ =J0CC -----END PGP SIGNATURE----- --FCPLy5NpE1Kdjj9y-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 19:38:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E285106568D for ; Mon, 5 Oct 2009 19:38:57 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1DBA88FC14 for ; Mon, 5 Oct 2009 19:38:56 +0000 (UTC) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 89D4619E019; Mon, 5 Oct 2009 21:38:55 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id D2BA719E023; Mon, 5 Oct 2009 21:38:49 +0200 (CEST) Message-ID: <4ACA4B49.70702@quip.cz> Date: Mon, 05 Oct 2009 21:38:49 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Tom Judge References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> In-Reply-To: <4ACA3146.9090402@tomjudge.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Julian Elischer Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 19:38:57 -0000 Tom Judge wrote: > Julian Elischer wrote: > >> Tom Judge wrote: >> >>> >>> Does anyone know of a patch that will add per jail memory limits so >>> that a jail can't swallow the resources of the entire box? >> >> not yet.. >> > > I started to port this to 7.1 today: > > http://wiki.freebsd.org/JailResourceLimits > > > What are the peoples opinions on this patch? The original JailResourceLimits patch was never 100% functional. Please see this page http://wiki.freebsd.org/Jails with links to newer attempts for 7.x and 8.x. It is also better to discuss it on Jail mailinglist freebsd-jail@freebsd.org and you can find some useful informations in archive http://lists.freebsd.org/pipermail/freebsd-jail/ I am unhappy that there are people with some interest in to jail resource limits, some patches floating around, but it never arive at final stage and production quality, and never get committed. :( It would be nice to have jails with CPU / memory / FD / disk IO / bandwidth limits connected to SNMP monitoring of these resources. Unfortunately I have zero C coding skills, so I can just wait if somebody... Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 19:39:40 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD3CC1065695; Mon, 5 Oct 2009 19:39:40 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 827C28FC1C; Mon, 5 Oct 2009 19:39:40 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:3902:3a2:c54b:fed5] (unknown [IPv6:2001:7b8:3a7:0:3902:3a2:c54b:fed5]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id AD34A5C59; Mon, 5 Oct 2009 21:39:39 +0200 (CEST) Message-ID: <4ACA4B81.3090105@andric.com> Date: Mon, 05 Oct 2009 21:39:45 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.4pre) Gecko/20091003 Shredder/3.0pre MIME-Version: 1.0 To: Hiroki Sato References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> In-Reply-To: <20091005.123427.227628092.hrs@allbsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-rc@FreeBSD.org Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 19:39:40 -0000 On 2009-10-05 05:34, Hiroki Sato wrote: > The patch for stable/8 can be found at: > > http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff Hmm, build bombs out at sbin/ifconfig: ===> sbin/ifconfig (depend) make: don't know how to make af_nd6.c. Stop *** Error code 2 This is because the patch doesn't seem to contain sbin/ifconfig/af_nd6.c. Can I just use the version from head? From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 19:42:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9460B1065692 for ; Mon, 5 Oct 2009 19:42:54 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f192.google.com (mail-qy0-f192.google.com [209.85.221.192]) by mx1.freebsd.org (Postfix) with ESMTP id 489A78FC19 for ; Mon, 5 Oct 2009 19:42:54 +0000 (UTC) Received: by qyk30 with SMTP id 30so3719555qyk.7 for ; Mon, 05 Oct 2009 12:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=WfZR0chk2dMnbKmGeI7xwzb7RDWqIhn+em3MXKvLVWs=; b=f+0TlaVZBGVQnL0FN0wl1tyqhiN1U+pQXHhVOvl7f5mWJnL0afpyNuZNO4vmbXx5ef 6OX/JUck1h7/xk0YM2fsEAgWCWUzFi+ZV+rkIwkZwWgh1K5w8PpBO6i83Qwt4PkbysJM CDUyO81IPgIMd0TB6PRy/+hOSdklaZ/wBLzpE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=jQKDLi5/VHfxK7SHIE2vYnY6Dw9Oznxkn11/F7HYkQfPuZybKa+BOaXGBkuhV9qsUX GSpoxra6wYv4oa78isyzx7CDoFB7EE+MkBvMDYRS3MvfsHjAd4x9q+SbK85hVLLBAPFF RdbaDIfHbjuAendes1+N/dI0QxIm/QLiriaug= Received: by 10.224.96.88 with SMTP id g24mr506319qan.361.1254771773626; Mon, 05 Oct 2009 12:42:53 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 7sm53706qwb.56.2009.10.05.12.42.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 05 Oct 2009 12:42:45 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 5 Oct 2009 12:41:34 -0700 From: Pyun YongHyeon Date: Mon, 5 Oct 2009 12:41:34 -0700 To: Takahashi Yoshihiro Message-ID: <20091005194134.GF1406@michelle.cdnetworks.com> References: <20090924112533.1377D83D2D@mail1.asahi-net.or.jp> <20090924.210712.162012268.nyan@jp.FreeBSD.org> <20090924175312.GA5572@michelle.cdnetworks.com> <20091005.233648.263895250.nyan@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091005.233648.263895250.nyan@jp.FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, CQG00620@nifty.ne.jp Subject: Re: de(4) does not work on 8.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Oct 2009 19:42:54 -0000 On Mon, Oct 05, 2009 at 11:36:48PM +0900, Takahashi Yoshihiro wrote: > In article <20090924175312.GA5572@michelle.cdnetworks.com> > Pyun YongHyeon writes: > > >> > Thanks for your reply. They works well again on 8.0-RC1 with your > >> > patch. > >> > >> I also use a NIC supported by de(4). The patch works fine for it. > > > > Thanks for testing! Patch committed to HEAD(r197465). > > Do you have a plan to merge this patch into stable/8? > I wish that the de(4) works in 8.0R. > MFC done(r197787). > --- > TAKAHASHI Yoshihiro From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 19:59:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14D0F1065672 for ; Mon, 5 Oct 2009 19:59:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 80D0E8FC0C for ; Mon, 5 Oct 2009 19:59:17 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n95Jwtcv049392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Oct 2009 22:58:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n95JwtAj095048; Mon, 5 Oct 2009 22:58:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n95Jwt4q095047; Mon, 5 Oct 2009 22:58:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 5 Oct 2009 22:58:55 +0300 From: Kostik Belousov To: Michio Karl Jinbo Message-ID: <20091005195855.GC2259@deviant.kiev.zoral.com.ua> References: <200910041220.n94CKxTH073639@svn.freebsd.org> <20091005072515.3622.22FF24F1@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5wdX5gfZV4kojQYf" Content-Disposition: inline In-Reply-To: <20091005072515.3622.22FF24F1@gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: pmap_invalidate_cache_range() panic on Xen Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 19:59:19 -0000 --5wdX5gfZV4kojQYf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 05, 2009 at 07:25:18AM +0900, Michio Karl Jinbo wrote: > On Sun, 4 Oct 2009 12:20:59 +0000 (UTC) > Konstantin Belousov wrote: >=20 > > Log: > > MFC r197663: > > As a workaround, for Intel CPUs, do not use CLFLUSH in > > pmap_invalidate_cache_range() when self-snoop is apparently not repor= ted > > in cpu features. > > =20 > > Approved by: re (bz, kensmith) >=20 > I was tested r197663/r197744, but kernel panic again on Citrix Xen Server. >=20 > using 8.0-RC1 install cd, results are > 1. INTEL SU9400+HYPER-V(Windows2008 R2) -> boot OK. > 2. AMD Athlon X2 TK-55+HYPER-V(Windows2008 R2) -> boot NG. > 3. AMD PhenomII 940BK+Citrix Xen Server -> boot NG. >=20 > I think INTEL CPUs are no problem, but AMD CPUs appear the problem. So I = tested > the following patch, kernel boot was successed on recent 9-CURRENT and en= vironment 3. >=20 > sorry, poor English. Does the GENERIC kernel after r197744 boots on your plain hardware, without any hypervisor ? Also, please provide the lines from dmesg with CPU features lists, both from boot on plain hardware and under XEN. --5wdX5gfZV4kojQYf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrKT/8ACgkQC3+MBN1Mb4jOEwCfVs0jXDaMjfTRkvzQZ/PmEIB+ D+QAnRuyD/Hsgbdrvx8uCqjB/FxRRaio =WBCb -----END PGP SIGNATURE----- --5wdX5gfZV4kojQYf-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 20:03:52 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E5311065672; Mon, 5 Oct 2009 20:03:52 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 399D58FC19; Mon, 5 Oct 2009 20:03:51 +0000 (UTC) Received: from delta.allbsd.org (p4206-ipbf1902funabasi.chiba.ocn.ne.jp [114.146.107.206]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id n95K3WP5085097; Tue, 6 Oct 2009 05:03:43 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id n95K3MT3071002; Tue, 6 Oct 2009 05:03:25 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 06 Oct 2009 04:50:43 +0900 (JST) Message-Id: <20091006.045043.187164797.hrs@allbsd.org> To: des@des.no From: Hiroki Sato In-Reply-To: <86my45vhlj.fsf@ds4.des.no> References: <20091005055806.GB58246@zibbi.meraka.csir.co.za> <20091005.182342.167950100.hrs@allbsd.org> <86my45vhlj.fsf@ds4.des.no> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.2.52 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Oct__6_04_50_43_2009_396)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Tue, 06 Oct 2009 05:03:44 +0900 (JST) Cc: jhay@meraka.org.za, freebsd-current@FreeBSD.org, freebsd-rc@FreeBSD.org Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 20:03:52 -0000 ----Security_Multipart(Tue_Oct__6_04_50_43_2009_396)-- Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dag-Erling Sm=F8rgrav wrote in <86my45vhlj.fsf@ds4.des.no>: de> Hiroki Sato writes: de> > John Hay writes: de> > > Is there a good reason why we still ship with ipv6 off by defau= lt? de> > What do you mean by "off by default"? I think IPv6 is not disabl= ed by de> > default with the patch. de> = de> % ident /usr/src/etc/defaults/rc.conf = de> /usr/src/etc/defaults/rc.conf: de> $FreeBSD: head/etc/defaults/rc.conf 197619 2009-09-29 16:49:10= Z dougb $ de> % grep ipv6_network_interfaces /usr/src/etc/defaults/rc.conf de> ipv6_network_interfaces=3D"none" # List of IPv6 network interfaces de> #ipv6_network_interfaces=3D"ed0 ep0" # Examples for router de> % grep ipv6_prefer /usr/src/etc/defaults/rc.conf = de> ipv6_prefer=3D"NO" # Use IPv6 when both IPv4 and IPv6 can be used de> = de> Does mean that IPv6 is disabled by default? Who knows? There is n= o de> coherent explanation *anywhere* of what these variables mean, and de> rc.conf(5) does not mention them at all. In fact, the first hit fo= r de> "ipv6" in rc.conf(5) is this: de> = de> ipv6_enable de> (bool) Enable support for IPv6 networking. Note t= hat this de> requires that the kernel has been compiled with op= tions de> INET6. No, the rc.conf(5) has been updated in r197526: ipv6_enable (bool) If the variable is ``YES'', ``inet6 accept_rtad= v'' is added to all of ifconfig__ipv6 and the ipv6= _prefer is defined as ``YES''. This variable is deprecated. Use ipv6_prefer and ifconfig__ipv6. and UPDATING also explains the relationship between the $ipv6_enable and the other variables. IMHO "Enabling (or disabling) IPv6" is not a correct expression for $ipv6_enable and $ipv6_prefer. If you use a kernel with "options INET6" (GENERIC has it) IPv6 is enabled, and $ipv6_enable=3DNO in the old releases does not disable the functionality. It just controlled whether $ipv6_* in rc.conf are ignored or not. -- Hiroki ----Security_Multipart(Tue_Oct__6_04_50_43_2009_396)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkrKThMACgkQTyzT2CeTzy29fwCeM8VpJjt2YI1voNdec3kHVlGS AecAmgI52ETW3Q/PDEQW1h7FsZRkENfc =gvTH -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Oct__6_04_50_43_2009_396)---- From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 20:06:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65679106566B for ; Mon, 5 Oct 2009 20:06:26 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id 282B98FC16 for ; Mon, 5 Oct 2009 20:06:26 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 195E4489A4; Mon, 5 Oct 2009 21:06:25 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6BJ21UHDt6v; Mon, 5 Oct 2009 21:06:20 +0100 (BST) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 771A04896C; Mon, 5 Oct 2009 21:06:20 +0100 (BST) Message-ID: <4ACA519B.1040907@tomjudge.com> Date: Mon, 05 Oct 2009 20:05:47 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz> References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> <4ACA4B49.70702@quip.cz> In-Reply-To: <4ACA4B49.70702@quip.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 20:06:26 -0000 Miroslav Lachman wrote: > > The original JailResourceLimits patch was never 100% functional. > > Please see this page http://wiki.freebsd.org/Jails with links to newer > attempts for 7.x and 8.x. > > It is also better to discuss it on Jail mailinglist > freebsd-jail@freebsd.org and you can find some useful informations in > archive http://lists.freebsd.org/pipermail/freebsd-jail/ > > I am unhappy that there are people with some interest in to jail > resource limits, some patches floating around, but it never arive at > final stage and production quality, and never get committed. :( > > It would be nice to have jails with CPU / memory / FD / disk IO / > bandwidth limits connected to SNMP monitoring of these resources. > Unfortunately I have zero C coding skills, so I can just wait if > somebody... > > Miroslav Lachman Thanks, I will take a look at the patches here (just testing the 7.0 patch on 7.1 now). It would be nice to see some of this functionality, in the base system. Tom From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 20:17:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D914106568D for ; Mon, 5 Oct 2009 20:17:04 +0000 (UTC) (envelope-from swehack@gmail.com) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id EB4F18FC18 for ; Mon, 5 Oct 2009 20:17:03 +0000 (UTC) Received: by ewy4 with SMTP id 4so3207394ewy.7 for ; Mon, 05 Oct 2009 13:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=hj5z5u2O4dHDDOuUIEQ0vWKsBjQ5wONEZlkGPniE/w8=; b=p/b5nkwm8lGKae8dfTCdNMGqoSq5LaWeaaqgsrjCX+i/1hiTjhNQW1sTeCK0snf0X9 pTsH5XqNbScVekZPLBCqiBUG2vkJiqvgcxMHhEQGVttY2TElsoxV3Yo600JBHTMKxX+4 2lFwc4gcWN0cun2rXQIYbapXJzoP1C1BCRZ6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=I5ETcYsnjOa5GdaAfki52/TjGROo5Yc1vnNMlvfZIRVDxvurfjc1oflpwpBZD+3fI3 0Jd+FvQLVyknkHMXMcOQcDccqKg75zx3FCOWyOWCPcOAFo1wscJ95BKWx8Kw65oqpJxq TFrcuy0Hz1Cui5ikAAI344wauXtrcR0yNiwbQ= MIME-Version: 1.0 Received: by 10.210.9.7 with SMTP id 7mr506290ebi.5.1254772196926; Mon, 05 Oct 2009 12:49:56 -0700 (PDT) Date: Mon, 5 Oct 2009 21:49:56 +0200 Message-ID: <9aed80930910051249ocfcf946o2341c653d16b8e24@mail.gmail.com> From: nocturnal To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Updating FreeBSD 7.0-RELEASE i386 to 7.2 amd64? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 20:17:04 -0000 Can it be done with a simple cvs or binary update of FreeBSD or must i re-install using some media? If i kept my /usr partition intact and just overwrote the important stuff with new files from the CD it wouldn't be so bad with a re-install but it would be nice if large parts of it could be done remote. What is your suggestion for this? --=20 Med v=E4nliga h=E4lsningar Stefan Midjich aka nocturnal [SWEHACK] http://swehack.se From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 20:28:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98EC91065697 for ; Mon, 5 Oct 2009 20:28:50 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outw.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id 7A8638FC1B for ; Mon, 5 Oct 2009 20:28:50 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 763A4961D8; Mon, 5 Oct 2009 13:29:05 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 6FDEB2D6012; Mon, 5 Oct 2009 13:28:49 -0700 (PDT) Message-ID: <4ACA5704.2070404@elischer.org> Date: Mon, 05 Oct 2009 13:28:52 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Tom Judge References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> <6201873e0910051142q58e7563fqc7735261ea9ab3c6@mail.gmail.com> <4ACA4216.9060008@tomjudge.com> In-Reply-To: <4ACA4216.9060008@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Vande More , freebsd-current@freebsd.org, Jamie Gritton , FreeBSD virtualization mailing list Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 20:28:50 -0000 Tom Judge wrote: > Adam Vande More wrote: >> On Mon, Oct 5, 2009 at 12:47 PM, Tom Judge > > wrote: >> >> Julian Elischer wrote: >> >> Tom Judge wrote: >> >> Hi, >> >> Does anyone know of a patch that will add per jail memory >> limits so that a jail can't swallow the resources of the >> entire box? >> >> >> Thanks >> >> Tom >> _______________________________________________ >> 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 >> " >> >> >> >> not yet.. >> >> >> I started to port this to 7.1 today: >> >> http://wiki.freebsd.org/JailResourceLimits >> >> >> What are the peoples opinions on this patch? >> >> >> Tom >> >> >> If you're soliciting opinions if this will be used and is needed, I >> would love to see this functionality. This is the main reason I've >> had to chose XEN over jails. If you need some help testing, let me know. >> >> -- >> Adam Vande More > Hi Adam, > > I have a patch against 7.1 here: > http://svn.tomjudge.com/freebsd/patches/jail-resource-limits/jail-limits.patch probably the person who should work with this in -current is james (CC'd) > > > I will try to bring the patch up to current when I get a chance but I > have no real need to do this as we use 7.1 in production. > > Notes: > > * CPU limiting is not support is not supported unless you use > shecd_4bsd. > * I have not tested this on any system yet, just compile tested, I am > putting it though its paces right now. > > Tom > > _______________________________________________ > 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 Mon Oct 5 20:36:59 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ED481065672; Mon, 5 Oct 2009 20:36:59 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 13CC98FC13; Mon, 5 Oct 2009 20:36:58 +0000 (UTC) Received: from delta.allbsd.org (p4206-ipbf1902funabasi.chiba.ocn.ne.jp [114.146.107.206]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id n95Kagj9085774; Tue, 6 Oct 2009 05:36:52 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id n95KaYqn071095; Tue, 6 Oct 2009 05:36:36 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 06 Oct 2009 05:36:11 +0900 (JST) Message-Id: <20091006.053611.25963972.hrs@allbsd.org> To: dimitry@andric.com From: Hiroki Sato In-Reply-To: <4ACA4B81.3090105@andric.com> References: <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <4ACA4B81.3090105@andric.com> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.2.52 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Oct__6_05_36_11_2009_099)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Tue, 06 Oct 2009 05:36:53 +0900 (JST) Cc: freebsd-current@FreeBSD.org, freebsd-rc@FreeBSD.org Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 20:36:59 -0000 ----Security_Multipart(Tue_Oct__6_05_36_11_2009_099)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dimitry Andric wrote in <4ACA4B81.3090105@andric.com>: di> On 2009-10-05 05:34, Hiroki Sato wrote: di> > The patch for stable/8 can be found at: di> > di> > http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff di> di> Hmm, build bombs out at sbin/ifconfig: di> di> ===> sbin/ifconfig (depend) di> make: don't know how to make af_nd6.c. Stop di> *** Error code 2 di> di> This is because the patch doesn't seem to contain di> sbin/ifconfig/af_nd6.c. Can I just use the version from head? Yes, you can use the file in HEAD. I do not know why but "svn diff" seems not to generate a diff delta for a newly-added file by "svn merge"... The missing delta can also be found at: http://people.freebsd.org/~hrs/af_nd6.c.diff -- Hiroki ----Security_Multipart(Tue_Oct__6_05_36_11_2009_099)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkrKWLsACgkQTyzT2CeTzy0S9wCdHYc9uNxPsZoAnzy87TM/aXot kdkAnjL9VoY15vN8fU9uNiQDvjUzc0Gd =l5Pe -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Oct__6_05_36_11_2009_099)---- From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 20:52:20 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AD36106568B; Mon, 5 Oct 2009 20:52:20 +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 216558FC14; Mon, 5 Oct 2009 20:52:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n95KqIPB010981; Mon, 5 Oct 2009 16:52:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n95KqIg7010977; Mon, 5 Oct 2009 20:52:18 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 5 Oct 2009 20:52:18 GMT Message-Id: <200910052052.n95KqIg7010977@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 20:52:20 -0000 TB --- 2009-10-05 19:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-05 19:15:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-10-05 19:15:00 - cleaning the object tree TB --- 2009-10-05 19:15:26 - cvsupping the source tree TB --- 2009-10-05 19:15:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-10-05 19:15:42 - building world TB --- 2009-10-05 19:15:42 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-05 19:15:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-05 19:15:42 - TARGET=amd64 TB --- 2009-10-05 19:15:42 - TARGET_ARCH=amd64 TB --- 2009-10-05 19:15:42 - TZ=UTC TB --- 2009-10-05 19:15:42 - __MAKE_CONF=/dev/null TB --- 2009-10-05 19:15:42 - cd /src TB --- 2009-10-05 19:15:42 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 5 19:15:42 UTC 2009 >>> 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 Mon Oct 5 20:42:07 UTC 2009 TB --- 2009-10-05 20:42:07 - generating LINT kernel config TB --- 2009-10-05 20:42:07 - cd /src/sys/amd64/conf TB --- 2009-10-05 20:42:07 - /usr/bin/make -B LINT TB --- 2009-10-05 20:42:07 - building LINT kernel TB --- 2009-10-05 20:42:07 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-05 20:42:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-05 20:42:07 - TARGET=amd64 TB --- 2009-10-05 20:42:07 - TARGET_ARCH=amd64 TB --- 2009-10-05 20:42:07 - TZ=UTC TB --- 2009-10-05 20:42:07 - __MAKE_CONF=/dev/null TB --- 2009-10-05 20:42:07 - cd /src TB --- 2009-10-05 20:42:07 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Oct 5 20:42:07 UTC 2009 >>> 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 [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/uipc_shm.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/uipc_sockbuf.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/uipc_socket.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/uipc_syscalls.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/uipc_usrreq.c cc1: warnings being treated as errors /src/sys/kern/uipc_usrreq.c: In function 'unp_pcblist': /src/sys/kern/uipc_usrreq.c:1471: warning: format '%d' expects type 'int', but argument 2 has type 'long int' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-05 20:52:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-05 20:52:18 - ERROR: failed to build lint kernel TB --- 2009-10-05 20:52:18 - 4321.98 user 988.80 system 5838.36 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 21:06:03 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78484106566B; Mon, 5 Oct 2009 21:06:03 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 302118FC08; Mon, 5 Oct 2009 21:06:02 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 1C2EC6D41C; Mon, 5 Oct 2009 21:06:02 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id E00AF844DE; Mon, 5 Oct 2009 23:06:00 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Hiroki Sato References: <20091005055806.GB58246@zibbi.meraka.csir.co.za> <20091005.182342.167950100.hrs@allbsd.org> <86my45vhlj.fsf@ds4.des.no> <20091006.045043.187164797.hrs@allbsd.org> Date: Mon, 05 Oct 2009 23:06:00 +0200 In-Reply-To: <20091006.045043.187164797.hrs@allbsd.org> (Hiroki Sato's message of "Tue, 06 Oct 2009 04:50:43 +0900 (JST)") Message-ID: <8663atv9dz.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: jhay@meraka.org.za, freebsd-current@FreeBSD.org, freebsd-rc@FreeBSD.org Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 21:06:03 -0000 Hiroki Sato writes: > No, the rc.conf(5) has been updated in r197526: > > ipv6_enable > (bool) If the variable is ``YES'', ``inet6 accept_rtadv'= ' is > added to all of ifconfig__ipv6 and the ipv6_p= refer > is defined as ``YES''. > > This variable is deprecated. Use ipv6_prefer and > ifconfig__ipv6. Still not very helpful. If I install FreeBSD from a release CD and use the GENERIC kernel and do *not* want to use IPv6, what do I do? Please don't answer "compile a custom kernel". DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 21:33:50 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F14A106568B; Mon, 5 Oct 2009 21:33:50 +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 0847A8FC18; Mon, 5 Oct 2009 21:33:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n95LXn38013670; Mon, 5 Oct 2009 17:33:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n95LXnNQ013666; Mon, 5 Oct 2009 21:33:49 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 5 Oct 2009 21:33:49 GMT Message-Id: <200910052133.n95LXnNQ013666@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 21:33:50 -0000 TB --- 2009-10-05 20:04:20 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-05 20:04:20 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-10-05 20:04:20 - cleaning the object tree TB --- 2009-10-05 20:04:41 - cvsupping the source tree TB --- 2009-10-05 20:04:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-10-05 20:04:55 - building world TB --- 2009-10-05 20:04:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-05 20:04:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-05 20:04:55 - TARGET=ia64 TB --- 2009-10-05 20:04:55 - TARGET_ARCH=ia64 TB --- 2009-10-05 20:04:55 - TZ=UTC TB --- 2009-10-05 20:04:55 - __MAKE_CONF=/dev/null TB --- 2009-10-05 20:04:55 - cd /src TB --- 2009-10-05 20:04:55 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 5 20:04:56 UTC 2009 >>> 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 Mon Oct 5 21:22:27 UTC 2009 TB --- 2009-10-05 21:22:27 - generating LINT kernel config TB --- 2009-10-05 21:22:27 - cd /src/sys/ia64/conf TB --- 2009-10-05 21:22:27 - /usr/bin/make -B LINT TB --- 2009-10-05 21:22:27 - building LINT kernel TB --- 2009-10-05 21:22:27 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-05 21:22:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-05 21:22:27 - TARGET=ia64 TB --- 2009-10-05 21:22:27 - TARGET_ARCH=ia64 TB --- 2009-10-05 21:22:27 - TZ=UTC TB --- 2009-10-05 21:22:27 - __MAKE_CONF=/dev/null TB --- 2009-10-05 21:22:27 - cd /src TB --- 2009-10-05 21:22:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Oct 5 21:22:27 UTC 2009 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/uipc_shm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/uipc_sockbuf.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/uipc_socket.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/uipc_syscalls.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/uipc_usrreq.c cc1: warnings being treated as errors /src/sys/kern/uipc_usrreq.c: In function 'unp_pcblist': /src/sys/kern/uipc_usrreq.c:1471: warning: format '%d' expects type 'int', but argument 2 has type 'long int' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-05 21:33:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-05 21:33:49 - ERROR: failed to build lint kernel TB --- 2009-10-05 21:33:49 - 4262.91 user 700.97 system 5368.50 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 22:09:37 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12598106566B; Mon, 5 Oct 2009 22:09:37 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3DA9D8FC0A; Mon, 5 Oct 2009 22:09:36 +0000 (UTC) Received: from delta.allbsd.org (p4206-ipbf1902funabasi.chiba.ocn.ne.jp [114.146.107.206]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id n95M9E6A087618; Tue, 6 Oct 2009 07:09:25 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id n95M95pr071371; Tue, 6 Oct 2009 07:09:07 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 06 Oct 2009 07:07:14 +0900 (JST) Message-Id: <20091006.070714.233607520.hrs@allbsd.org> To: des@des.no From: Hiroki Sato In-Reply-To: <8663atv9dz.fsf@ds4.des.no> References: <86my45vhlj.fsf@ds4.des.no> <20091006.045043.187164797.hrs@allbsd.org> <8663atv9dz.fsf@ds4.des.no> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.2.52 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Oct__6_07_07_14_2009_906)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Tue, 06 Oct 2009 07:09:28 +0900 (JST) Cc: jhay@meraka.org.za, freebsd-current@FreeBSD.org, freebsd-rc@FreeBSD.org Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 22:09:37 -0000 ----Security_Multipart(Tue_Oct__6_07_07_14_2009_906)-- Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dag-Erling Sm=F8rgrav wrote in <8663atv9dz.fsf@ds4.des.no>: de> Hiroki Sato writes: de> > No, the rc.conf(5) has been updated in r197526: de> > de> > ipv6_enable de> > (bool) If the variable is ``YES'', ``inet6 accep= t_rtadv'' is de> > added to all of ifconfig__ipv6 and th= e ipv6_prefer de> > is defined as ``YES''. de> > de> > This variable is deprecated. Use ipv6_prefer an= d de> > ifconfig__ipv6. de> = de> Still not very helpful. de> = de> If I install FreeBSD from a release CD and use the GENERIC kernel a= nd do de> *not* want to use IPv6, what do I do? de> = de> Please don't answer "compile a custom kernel". It depends on the definition of "use", but the answer is "do not put any $ifconfig_IF_ipv6 or $ipv6_prefer to your rc.conf". If so, IPv6 will be "disabled" (including communication using link-local addresses) on all of interfaces except lo0. It is the default behavior now. I do not think this means "IPv6 is disabled by default". By adding an IPv6 address by using ifconfig(8) after boot you can still use IPv6 on that interface. This is almost the same as IPv4 does. When I do not want to use IPv4, I do not put any IPv4 addresses to $ifconfig_IF. Strictly speaking the address ::1/128 on lo0 cannot be removed because it is assigned by the kernel itself unlike IPv4's 127.0.0.1, so you can use the loopback address without knowing it. If you do not want to use it, you can disable IPv6 on lo0 manually by "ifconfig lo0 inet6 ifdisabled". Anyway, the existence of this loopback address has not been changed for a long time. -- Hiroki ----Security_Multipart(Tue_Oct__6_07_07_14_2009_906)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkrKbhIACgkQTyzT2CeTzy2PLwCgzqxq1QeRWzxOraPLRqJ0MH4M +osAn25+WBBnoJRbzp7LQ20XJC1hvIIB =SYvh -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Oct__6_07_07_14_2009_906)---- From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 22:16:47 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE0291065670; Mon, 5 Oct 2009 22:16:47 +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 92EDC8FC13; Mon, 5 Oct 2009 22:16:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n95MGk8Y079647; Mon, 5 Oct 2009 18:16:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n95MGkrU079646; Mon, 5 Oct 2009 22:16:46 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 5 Oct 2009 22:16:46 GMT Message-Id: <200910052216.n95MGkrU079646@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 22:16:48 -0000 TB --- 2009-10-05 21:12:52 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-05 21:12:52 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-10-05 21:12:52 - cleaning the object tree TB --- 2009-10-05 21:13:13 - cvsupping the source tree TB --- 2009-10-05 21:13:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-10-05 21:13:26 - building world TB --- 2009-10-05 21:13:26 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-05 21:13:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-05 21:13:26 - TARGET=sparc64 TB --- 2009-10-05 21:13:26 - TARGET_ARCH=sparc64 TB --- 2009-10-05 21:13:26 - TZ=UTC TB --- 2009-10-05 21:13:26 - __MAKE_CONF=/dev/null TB --- 2009-10-05 21:13:26 - cd /src TB --- 2009-10-05 21:13:26 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 5 21:13:26 UTC 2009 >>> 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 Mon Oct 5 22:08:54 UTC 2009 TB --- 2009-10-05 22:08:54 - generating LINT kernel config TB --- 2009-10-05 22:08:54 - cd /src/sys/sparc64/conf TB --- 2009-10-05 22:08:54 - /usr/bin/make -B LINT TB --- 2009-10-05 22:08:54 - building LINT kernel TB --- 2009-10-05 22:08:54 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-05 22:08:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-05 22:08:54 - TARGET=sparc64 TB --- 2009-10-05 22:08:54 - TARGET_ARCH=sparc64 TB --- 2009-10-05 22:08:54 - TZ=UTC TB --- 2009-10-05 22:08:54 - __MAKE_CONF=/dev/null TB --- 2009-10-05 22:08:54 - cd /src TB --- 2009-10-05 22:08:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Oct 5 22:08:54 UTC 2009 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_shm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_sockbuf.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_socket.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_syscalls.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_usrreq.c cc1: warnings being treated as errors /src/sys/kern/uipc_usrreq.c: In function 'unp_pcblist': /src/sys/kern/uipc_usrreq.c:1471: warning: format '%d' expects type 'int', but argument 2 has type 'long int' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-05 22:16:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-05 22:16:46 - ERROR: failed to build lint kernel TB --- 2009-10-05 22:16:46 - 2986.88 user 636.63 system 3834.07 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 22:23:22 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34D381065757 for ; Mon, 5 Oct 2009 22:23:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 101778FC13 for ; Mon, 5 Oct 2009 22:23:19 +0000 (UTC) Received: (qmail 2121 invoked by uid 399); 5 Oct 2009 22:23:18 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 5 Oct 2009 22:23:18 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4ACA71D4.6010502@FreeBSD.org> Date: Mon, 05 Oct 2009 15:23:16 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Hiroki Sato References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> In-Reply-To: <20091005.123427.227628092.hrs@allbsd.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-rc@FreeBSD.org Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 22:23:22 -0000 Hiroki Sato wrote: > Hi, > > I would like your comments about merging the network_ipv6 -> netif > integration to stable/8. I maintain my objection to MFC'ing this prior to the 8.0-RELEASE. As stated previously my objections are as follows (in decreasing order of general importance): 1. It is a fairly significant change happening too late in the release cycle. IMO that is reason enough to not allow the change. 2. Although 8.0 seems to be getting more beta/rc testing than previous .0 releases, the overall number of users testing it is still a small percentage of the userbase. 3. A dramatically smaller percentage of those users who are actually doing the testing is also using IPv6. 4. There are still rough edges to the changes. 5. I personally disagree with some of the choices you've made and would like to see more discussion about them. (More about 4 and 5 below.) The rough edges I've noticed have to do with the various problems people have reported to the lists, including what seems to be a lack of testing without IPv6 in the kernel, continuing evolution of how to deal with the afnet tests, and personally I've noticed the following on my console, although I haven't had time to research yet whether it's definitely coming from your changes: in6_ifattach_linklocal: failed to add a link-local addr to wpi0 In terms of design decisions you've made, I am still confused about why you insist on deprecating ipv6_enable. Recent discussion on the lists indicates to me that I'm not alone in thinking that this is a valuable mechanism and that there is not only no reason to deprecate it, to do so is not desirable. I'd also like to explore further the idea that I suggested in a previous thread that it should not be necessary to specify ifconfig_IF_ipv6 at all. The vast majority of users will be using RA for the next couple of years at least, so in my mind it makes sense to default to using ipv6_network_interfaces=$network_interfaces and RA by default. If the user has a need to configure something explicitly then you've provided the mechanism for them to do that, but they shouldn't be forced to use it. This is another reason that I think ipv6_enable should be the "master" knob. I like the idea of the ipv6_prefer knob, but I do not like the idea of overloading it with the function of ipv6_enable too. I can certainly understand why you are eager to get these changes into 8.0, however if we do a proper job of maintaining backwards compatibility (which I think we should do anyway) I don't see any reason that they cannot be merged after 8.0, and more importantly after they have had a proper opportunity to shake out in HEAD. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 22:30:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 667ED1065670 for ; Mon, 5 Oct 2009 22:30:45 +0000 (UTC) (envelope-from justin.teller@gmail.com) Received: from mail-qy0-f192.google.com (mail-qy0-f192.google.com [209.85.221.192]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0988FC0C for ; Mon, 5 Oct 2009 22:30:44 +0000 (UTC) Received: by qyk30 with SMTP id 30so3913406qyk.7 for ; Mon, 05 Oct 2009 15:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=yk4Af6dGNtB2GBv2Knf6rzmiZtd3Uk2ysPt+T63ItGU=; b=IvipC2jezEipNQFHbscm/1imiOeZx+f8rO1/xbK2odwVOturKCG2LSBrVY/skzhsGt yjVwyTvTuE91/35SX76dH0+U/cOnGkTlCkq6uRrRItjrZjlm/HOnSFVE6KwC684XcL5O XZn8HNztPtg3oSyv3dLs1X258FOIfVodQyEaQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dkxyMQDBkaq4/2R6fHDBov4VFAQYeJ6cEvi3ztci5SWc9j0Cny6wubpB0TnKpWZBZ9 djT3DcyZCjfRXJOPzGb7picw6msSOg/d2ZL+ZO9owJGFXVA7EqBn6EKA2OtCYusK8W3c hisjq2OBGUhmwNRc/QwgIBtNUvudHYr4MgU3Q= MIME-Version: 1.0 Received: by 10.224.40.137 with SMTP id k9mr675753qae.262.1254781844377; Mon, 05 Oct 2009 15:30:44 -0700 (PDT) In-Reply-To: <20091005192144.GA2259@deviant.kiev.zoral.com.ua> References: <20091001120730.GR3130@deviant.kiev.zoral.com.ua> <20091002201213.GA16633@stack.nl> <20091005192144.GA2259@deviant.kiev.zoral.com.ua> Date: Mon, 5 Oct 2009 15:30:44 -0700 Message-ID: From: Justin Teller To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Jilles Tjoelker Subject: Re: Signals and an exiting thread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 22:30:45 -0000 2009/10/5 Kostik Belousov : -- snip -- > > I agree that postponing assignment of the thread for signal delivery > till the actual delivery occurs is the proper fix. I tried to cheat > in my previous patch. Below is an experimental change that did very > minimal testing. > -- snip diff -- I like where you're going with the patch. I'll test it out as well and let you know what I find. Thanks! -Justin From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 22:35:33 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A08E9106566B; Mon, 5 Oct 2009 22:35:33 +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 7992A8FC1B; Mon, 5 Oct 2009 22:35:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n95MZW0B024808; Mon, 5 Oct 2009 18:35:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n95MZWlA024807; Mon, 5 Oct 2009 22:35:32 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 5 Oct 2009 22:35:32 GMT Message-Id: <200910052235.n95MZWlA024807@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 22:35:33 -0000 TB --- 2009-10-05 21:33:49 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-05 21:33:49 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-10-05 21:33:49 - cleaning the object tree TB --- 2009-10-05 21:34:02 - cvsupping the source tree TB --- 2009-10-05 21:34:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-10-05 21:34:15 - building world TB --- 2009-10-05 21:34:15 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-05 21:34:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-05 21:34:15 - TARGET=sun4v TB --- 2009-10-05 21:34:15 - TARGET_ARCH=sparc64 TB --- 2009-10-05 21:34:15 - TZ=UTC TB --- 2009-10-05 21:34:15 - __MAKE_CONF=/dev/null TB --- 2009-10-05 21:34:15 - cd /src TB --- 2009-10-05 21:34:15 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 5 21:34:15 UTC 2009 >>> 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 Mon Oct 5 22:27:48 UTC 2009 TB --- 2009-10-05 22:27:48 - generating LINT kernel config TB --- 2009-10-05 22:27:48 - cd /src/sys/sun4v/conf TB --- 2009-10-05 22:27:48 - /usr/bin/make -B LINT TB --- 2009-10-05 22:27:48 - building LINT kernel TB --- 2009-10-05 22:27:48 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-05 22:27:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-05 22:27:48 - TARGET=sun4v TB --- 2009-10-05 22:27:48 - TARGET_ARCH=sparc64 TB --- 2009-10-05 22:27:48 - TZ=UTC TB --- 2009-10-05 22:27:48 - __MAKE_CONF=/dev/null TB --- 2009-10-05 22:27:48 - cd /src TB --- 2009-10-05 22:27:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Oct 5 22:27:48 UTC 2009 >>> 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_shm.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_sockbuf.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_socket.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_syscalls.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_usrreq.c cc1: warnings being treated as errors /src/sys/kern/uipc_usrreq.c: In function 'unp_pcblist': /src/sys/kern/uipc_usrreq.c:1471: warning: format '%d' expects type 'int', but argument 2 has type 'long int' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-05 22:35:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-05 22:35:32 - ERROR: failed to build lint kernel TB --- 2009-10-05 22:35:32 - 2979.51 user 611.90 system 3703.13 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Mon Oct 5 22:57:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5772F1065697; Mon, 5 Oct 2009 22:57:18 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 32DF08FC19; Mon, 5 Oct 2009 22:57:17 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n95MvHNt018431; Mon, 5 Oct 2009 15:57:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Oct 2009 15:56:36 -0700 Message-ID: In-Reply-To: <4ACA71D4.6010502@FreeBSD.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration Thread-Index: AcpGCoKEgAr2qKR3TbeREfjG/EmULwAASLlw References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org><20091005.123427.227628092.hrs@allbsd.org> <4ACA71D4.6010502@FreeBSD.org> From: "Li, Qing" To: "Doug Barton" , "Hiroki Sato" , Cc: freebsd-current@freebsd.org, freebsd-rc@freebsd.org Subject: RE: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Oct 2009 22:57:18 -0000 I agree with Doug and I'd prefer getting more runtime cycles out of these changes before MFC into stable/8.=20 On a semi-related topic, I like the features developed in r197138. The changes are significant enough that having a MFC of 3 days is way too short. This changelist should also be postponed to post REL_8. -- Qing > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Doug Barton > Sent: Monday, October 05, 2009 3:23 PM > To: Hiroki Sato > Cc: freebsd-current@freebsd.org; freebsd-rc@freebsd.org > Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration >=20 > Hiroki Sato wrote: > > Hi, > > > > I would like your comments about merging the network_ipv6 -> netif > > integration to stable/8. >=20 > I maintain my objection to MFC'ing this prior to the 8.0-RELEASE. As > stated previously my objections are as follows (in decreasing order of > general importance): >=20 > 1. It is a fairly significant change happening too late in the release > cycle. IMO that is reason enough to not allow the change. > 2. Although 8.0 seems to be getting more beta/rc testing than previous > .0 releases, the overall number of users testing it is still a small > percentage of the userbase. > 3. A dramatically smaller percentage of those users who are actually > doing the testing is also using IPv6. > 4. There are still rough edges to the changes. > 5. I personally disagree with some of the choices you've made and > would like to see more discussion about them. (More about 4 and 5 > below.) >=20 > The rough edges I've noticed have to do with the various problems > people have reported to the lists, including what seems to be a lack > of testing without IPv6 in the kernel, continuing evolution of how to > deal with the afnet tests, and personally I've noticed the following > on my console, although I haven't had time to research yet whether > it's definitely coming from your changes: >=20 > in6_ifattach_linklocal: failed to add a link-local addr to wpi0 >=20 > In terms of design decisions you've made, I am still confused about > why you insist on deprecating ipv6_enable. Recent discussion on the > lists indicates to me that I'm not alone in thinking that this is a > valuable mechanism and that there is not only no reason to deprecate > it, to do so is not desirable. >=20 > I'd also like to explore further the idea that I suggested in a > previous thread that it should not be necessary to specify > ifconfig_IF_ipv6 at all. The vast majority of users will be using RA > for the next couple of years at least, so in my mind it makes sense to > default to using ipv6_network_interfaces=3D$network_interfaces and RA = by > default. If the user has a need to configure something explicitly then > you've provided the mechanism for them to do that, but they shouldn't > be forced to use it. This is another reason that I think ipv6_enable > should be the "master" knob. I like the idea of the ipv6_prefer knob, > but I do not like the idea of overloading it with the function of > ipv6_enable too. >=20 > I can certainly understand why you are eager to get these changes into > 8.0, however if we do a proper job of maintaining backwards > compatibility (which I think we should do anyway) I don't see any > reason that they cannot be merged after 8.0, and more importantly > after they have had a proper opportunity to shake out in HEAD. >=20 >=20 > Doug >=20 > -- >=20 > This .signature sanitized for your protection >=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 Tue Oct 6 05:59:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E68B1065670 for ; Tue, 6 Oct 2009 05:59:08 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id EF3838FC0A for ; Tue, 6 Oct 2009 05:59:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 3FEFB10748; Tue, 6 Oct 2009 14:59:06 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost ([127.0.0.1]) by localhost (basalt.tackymt.homeip.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5kQog2R2F7e; Tue, 6 Oct 2009 14:58:53 +0900 (JST) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by basalt.tackymt.homeip.net (Postfix) with ESMTP; Tue, 6 Oct 2009 14:58:51 +0900 (JST) Date: Tue, 6 Oct 2009 14:58:51 +0900 From: Taku YAMAMOTO To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= Message-Id: <20091006145851.ef531ab9.taku@tackymt.homeip.net> In-Reply-To: <86iqetvfuc.fsf@ds4.des.no> References: <20091004225000.6a1a6262.taku@tackymt.homeip.net> <86fx9yxfrz.fsf@ds4.des.no> <20091005183526.GA3230@elmar.spoerlein.net> <86iqetvfuc.fsf@ds4.des.no> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.16.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: pam_ssh no longer works after r197679 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 05:59:08 -0000 On Mon, 05 Oct 2009 20:46:35 +0200 Dag-Erling Sm=F8rgrav wrote: > Ulrich Sp=F6rlein writes: > > Did the following and everything is back to normal: > > > > # cd /usr/src/lib/libpam/modules/pam_ssh > > # make "SRCS=3Dpam_ssh.c roaming_dummy.c" > > # make "SRCS=3Dpam_ssh.c roaming_dummy.c" install >=20 > Thanks, I'll commit the proper fix right away. Cherry-picking r197785 and r197786 fixed the problem. Thanks! --=20 -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 07:15:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D401C1065696 for ; Tue, 6 Oct 2009 07:15:08 +0000 (UTC) (envelope-from kenyon@kenyonralph.com) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.123]) by mx1.freebsd.org (Postfix) with ESMTP id 8C2758FC14 for ; Tue, 6 Oct 2009 07:15:08 +0000 (UTC) Received: from voodoo.kenyonralph.com ([76.176.200.148]) by cdptpa-omta03.mail.rr.com with ESMTP id <20091006062256589.JMTD26368@cdptpa-omta03.mail.rr.com> for ; Tue, 6 Oct 2009 06:22:56 +0000 Received: from voodoo.kenyonralph.com (localhost [127.0.0.1]) by voodoo.kenyonralph.com (Postfix) with ESMTP id 6E06B181CC1 for ; Mon, 5 Oct 2009 23:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=kenyonralph.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=postfix; bh=Q/XqweOE1eF2FozN/Tg9xLK6kdMsfCJD1eEA EAAVi38=; b=k7FvSunlyZvdF6mxUUilZsT8L8yMETP/Y9t622UexsBtwU2oi0am ApAk7H2dp5StcsdelysBgctrxmPa1eMPoJAla+uxtlW21uBvzNSzbBsIJahBhhYv 1xb3rkf31V+36oCW+OCj9LrStkmUkN3TMIaxmE3o1qDq7VZL86ghz2A= Received: by voodoo.kenyonralph.com (Postfix, from userid 1000) id 36166181EFC; Mon, 5 Oct 2009 23:22:54 -0700 (PDT) Date: Mon, 5 Oct 2009 23:22:53 -0700 From: Kenyon Ralph To: freebsd-current@freebsd.org Message-ID: <20091006062253.GZ17603@kenyonralph.com> Mail-Followup-To: freebsd-current@freebsd.org References: <20090924112533.1377D83D2D@mail1.asahi-net.or.jp> <20090924.210712.162012268.nyan@jp.FreeBSD.org> <20090924175312.GA5572@michelle.cdnetworks.com> <20091005.233648.263895250.nyan@jp.FreeBSD.org> <20091005194134.GF1406@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NctWKJLgDreUm1FS" Content-Disposition: inline In-Reply-To: <20091005194134.GF1406@michelle.cdnetworks.com> X-Operating-System: Ubuntu 9.04 Linux 2.6.28-15-generic on i686 User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: de(4) does not work on 8.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 07:15:08 -0000 --NctWKJLgDreUm1FS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-10-05T12:41:34-0700, Pyun YongHyeon wrote: > On Mon, Oct 05, 2009 at 11:36:48PM +0900, Takahashi Yoshihiro wrote: > > In article <20090924175312.GA5572@michelle.cdnetworks.com> > > Pyun YongHyeon writes: > >=20 > > >> > Thanks for your reply. They works well again on 8.0-RC1 with your > > >> > patch. > > >>=20 > > >> I also use a NIC supported by de(4). The patch works fine for it. > > >=20 > > > Thanks for testing! Patch committed to HEAD(r197465). > >=20 > > Do you have a plan to merge this patch into stable/8? > > I wish that the de(4) works in 8.0R. > >=20 >=20 > MFC done(r197787). This is not working for me: de0: port 0xa400-0xa47f mem 0xf1000000-0xf10= 0007f irq 23 at device 7.0 on pci2 de0: can't read ENET ROM (why=3D-4) (ff7fffffffffffffffffffffffffffffffffff= ffffffffffffffffffffffffff de0: 21140A [10-100Mb/s] pass 2.2 de0: address unknown Also, ifconfig does not show de0. FreeBSD ohm.kenyonralph.com 8.0-RC1 FreeBSD 8.0-RC1 #0 r197797: Mon Oct 5 = 21:40:16 PDT 2009 root@ohm.kenyonralph.com:/usr/obj/usr/src/sys/KRZFSOH= M i386 de0 did appear in ifconfig on this machine with a stable/8 kernel and world built sometime in the past, but I don't know when exactly it stopped working (I haven't been using de0, but am planning to). Thanks, Kenyon Ralph --NctWKJLgDreUm1FS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkrK4j0ACgkQmFtUtJKnbnXZoACg5T7m6e1r5+3AEUv9V6J2OGRB I+0AoI2PPSlrGKyh638PxhFo9wa4IRT6 =K3IA -----END PGP SIGNATURE----- --NctWKJLgDreUm1FS-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 07:34:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17A2A1065670 for ; Tue, 6 Oct 2009 07:34:18 +0000 (UTC) (envelope-from kenyon@kenyonralph.com) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by mx1.freebsd.org (Postfix) with ESMTP id C37B18FC19 for ; Tue, 6 Oct 2009 07:34:17 +0000 (UTC) Received: from voodoo.kenyonralph.com ([76.176.200.148]) by cdptpa-omta03.mail.rr.com with ESMTP id <20091006073417078.JVYT26368@cdptpa-omta03.mail.rr.com> for ; Tue, 6 Oct 2009 07:34:17 +0000 Received: from voodoo.kenyonralph.com (localhost [127.0.0.1]) by voodoo.kenyonralph.com (Postfix) with ESMTP id 0D198181CC1 for ; Tue, 6 Oct 2009 00:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=kenyonralph.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=postfix; bh=UdUZgjV32wU1Sl25V5Z4sVulzD99r5faOxMx kVAn61g=; b=KN6Ux55DI2td5HK6OEJyu+bbTez/0KWX0rZpsISwxGEK2H03KM99 NDW9nknCTyWuicDQEk2ub7PZGIkBa+8k2MWffxLAoYus1IQJz9a4Oqqqtl4SoPSx kbkU3oE9bw8GulacqdYnNNlVZm081XYC9d5bN3tvRKV0KSUfeux01e8= Received: by voodoo.kenyonralph.com (Postfix, from userid 1000) id A692F181EFC; Tue, 6 Oct 2009 00:34:15 -0700 (PDT) Date: Tue, 6 Oct 2009 00:34:15 -0700 From: Kenyon Ralph To: freebsd-current@freebsd.org Message-ID: <20091006073415.GA17603@kenyonralph.com> Mail-Followup-To: freebsd-current@freebsd.org References: <20090924112533.1377D83D2D@mail1.asahi-net.or.jp> <20090924.210712.162012268.nyan@jp.FreeBSD.org> <20090924175312.GA5572@michelle.cdnetworks.com> <20091005.233648.263895250.nyan@jp.FreeBSD.org> <20091005194134.GF1406@michelle.cdnetworks.com> <20091006062253.GZ17603@kenyonralph.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9uNR01GrImESOVvg" Content-Disposition: inline In-Reply-To: <20091006062253.GZ17603@kenyonralph.com> X-Operating-System: Ubuntu 9.04 Linux 2.6.28-15-generic on i686 User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: de(4) does not work on 8.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 07:34:18 -0000 --9uNR01GrImESOVvg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-10-05T23:22:53-0700, Kenyon Ralph wrote: > de0: port 0xa400-0xa47f mem 0xf1000000-0xf= 100007f irq 23 at device 7.0 on pci2 > de0: can't read ENET ROM (why=3D-4) (ff7fffffffffffffffffffffffffffffffff= ffffffffffffffffffffffffffff > de0: 21140A [10-100Mb/s] pass 2.2 > de0: address unknown >=20 > Also, ifconfig does not show de0. >=20 > FreeBSD ohm.kenyonralph.com 8.0-RC1 FreeBSD 8.0-RC1 #0 r197797: Mon > Oct 5 21:40:16 PDT 2009 > root@ohm.kenyonralph.com:/usr/obj/usr/src/sys/KRZFSOHM i386 Nevermind, I think this box has hardware problems. I plugged an Ethernet cable into de0 and the system locked up hard after a few minutes. Now the system won't even boot, even without the de0 card installed in the PCI slot. Kenyon --9uNR01GrImESOVvg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkrK8vcACgkQmFtUtJKnbnVpjwCeNdYoVn38/YvkoWyoN9o9EArl dkQAoIrKoJbrvONA5Vv+/dLQavEor55p =U1fw -----END PGP SIGNATURE----- --9uNR01GrImESOVvg-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 08:19:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28363106568B for ; Tue, 6 Oct 2009 08:19:13 +0000 (UTC) (envelope-from christian@nertenher.de) Received: from mail-bw0-f227.google.com (mail-bw0-f227.google.com [209.85.218.227]) by mx1.freebsd.org (Postfix) with ESMTP id B84548FC18 for ; Tue, 6 Oct 2009 08:19:12 +0000 (UTC) Received: by bwz27 with SMTP id 27so2853858bwz.43 for ; Tue, 06 Oct 2009 01:19:11 -0700 (PDT) MIME-Version: 1.0 Sender: christian@nertenher.de Received: by 10.223.22.81 with SMTP id m17mr332714fab.28.1254815695167; Tue, 06 Oct 2009 00:54:55 -0700 (PDT) From: Christian Schmidt Date: Tue, 6 Oct 2009 09:54:35 +0200 X-Google-Sender-Auth: 16b5af64f0922c71 Message-ID: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Boot issues with a Dell Inspiron 530 and 8.0 RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 08:19:13 -0000 Hello list, I am seeing a strange issue with my Dell Inspiron 530 with 8.0 RC1-p1 at around 50-75% percent of all boots. It all boils down to GENERIC throwing the following: AP #1 (PHY #1) failed! panic y/n? [y] panic: bye-bye cpuid = 0 However, this only happens when booting from the hard disk. A boot from the install CD works perfectly every time. Testing the machine with 7.2 last night revealed the same issue, so this is not specific to 8.0 As an interesting side-note: the odds of a successful boot increase dramtically when cold-booting. Rebooting from e.g. Linux or Windows seems to push the failure-rate to around a 100% every time. The system itself is almost completely Intel. Some specifications: Intel 82801 PCI Bridge Intel G33/G31/P35/P31 PCIe Intel ICH9 SMBus If anyone needs any more information just let me know. My incentive to provide the information that is needed to get a fix for this is rather high as this problem stops me from using FreeBSD on a machine that shows no other problems with either Linux or Windows. :-) Thank you, Christian From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 08:26:13 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ED9D1065670; Tue, 6 Oct 2009 08:26:13 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3E9E68FC15; Tue, 6 Oct 2009 08:26:13 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 5025E6D41B; Tue, 6 Oct 2009 08:26:12 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 1774F8449F; Tue, 6 Oct 2009 10:26:12 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Hiroki Sato References: <86my45vhlj.fsf@ds4.des.no> <20091006.045043.187164797.hrs@allbsd.org> <8663atv9dz.fsf@ds4.des.no> <20091006.070714.233607520.hrs@allbsd.org> Date: Tue, 06 Oct 2009 10:26:12 +0200 In-Reply-To: <20091006.070714.233607520.hrs@allbsd.org> (Hiroki Sato's message of "Tue, 06 Oct 2009 07:07:14 +0900 (JST)") Message-ID: <864oqd9bdn.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: jhay@meraka.org.za, freebsd-current@FreeBSD.org, freebsd-rc@FreeBSD.org Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 08:26:13 -0000 Hiroki Sato writes: > Dag-Erling Sm=C3=B8rgrav writes: > > If I install FreeBSD from a release CD and use the GENERIC kernel > > and do *not* want to use IPv6, what do I do? > It depends on the definition of "use", but the answer is "do not put > any $ifconfig_IF_ipv6 or $ipv6_prefer to your rc.conf". If so, IPv6 > will be "disabled" (including communication using link-local > addresses) on all of interfaces except lo0. It is the default > behavior now. > > I do not think this means "IPv6 is disabled by default". Close enough from my POV... thanks. Network configuration is complicated enough that I think we should have a separate man page for it; rc.conf is pretty much useless unless you already know what you're looking for. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 08:49:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC0D51065672 for ; Tue, 6 Oct 2009 08:49:11 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id A68BC8FC22 for ; Tue, 6 Oct 2009 08:49:11 +0000 (UTC) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1Mv5jJ-0001pw-Oq; Tue, 06 Oct 2009 12:49:09 +0400 From: Boris Samorodov To: Kostik Belousov References: <78132948@bb.ipt.ru> <20091005190710.GW2259@deviant.kiev.zoral.com.ua> Date: Tue, 06 Oct 2009 12:49:09 +0400 In-Reply-To: <20091005190710.GW2259@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Mon, 5 Oct 2009 22:07:10 +0300") Message-ID: <22767770@bb.ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: abort acroread at today's -current, but OK at 03-Oct -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 08:49:12 -0000 On Mon, 5 Oct 2009 22:07:10 +0300 Kostik Belousov wrote: > On Mon, Oct 05, 2009 at 10:46:51PM +0400, Boris Samorodov wrote: > > > > today I updated my computer from 03-Oct CURRENT to -current and > > some ports were updated. And have got an error: > > ----- > > % acroread > > zsh: abort acroread > > % /bin/sh -x `which acroread` > > + echo '' > > + tr a-z A-Z > > + ADOBE_LANG='' > > + : ENU > > + BN=acroread > > + VN='' > > + [ -d /usr/local/Adobe/Reader8 ] > > + ADOBE_VER=8 > > + [ -d /usr/local/Adobe/Reader9 ] > > + ACROBASE=Adobe/Reader8 > > + BINPREFIX=Adobe/Reader8/bin > > + MOZILLA_COMP_PATH=/..//usr/local/lib/linux-nvu > > + export MOZILLA_COMP_PATH > > + GTK_IM_MODULE=xim > > + export GTK_IM_MODULE > > + UNAME_s=Linux > > + export UNAME_s > > + [ -x /usr/local/Adobe/Reader8/ENU/Adobe/Reader8/bin/acroread ] > > + exec /compat/linux/bin/sh /usr/local/Adobe/Reader8/ENU/Adobe/Reader8/bin/acroread > > zsh: abort /bin/sh -x `which acroread` > > ----- > > > > Loading old kernel gives a working acroread. What did I miss? > > Thanks. > Try this. > diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c > index 4ed7382..e958214 100644 > --- a/sys/kern/imgact_elf.c > +++ b/sys/kern/imgact_elf.c > @@ -635,7 +635,8 @@ __elfN(load_file)(struct proc *p, const char *file, u_long *addr, > } > > for (i = 0, numsegs = 0; i < hdr->e_phnum; i++) { > - if (phdr[i].p_type == PT_LOAD) { /* Loadable segment */ > + if (phdr[i].p_type == PT_LOAD && phdr[i].p_memsz != 0) { > + /* Loadable segment */ > prot = 0; > if (phdr[i].p_flags & PF_X) > prot |= VM_PROT_EXECUTE; > @@ -764,6 +768,8 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *imgp) > for (i = 0; i < hdr->e_phnum; i++) { > switch (phdr[i].p_type) { > case PT_LOAD: /* Loadable segment */ > + if (phdr[i].p_memsz == 0) > + break; > prot = 0; > if (phdr[i].p_flags & PF_X) > prot |= VM_PROT_EXECUTE; Thanks. Unfortunately there is no changes. Acroread works only with security.bsd.map_at_zero=1. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 09:08:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11D361065692 for ; Tue, 6 Oct 2009 09:08:10 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id 988878FC20 for ; Tue, 6 Oct 2009 09:08:09 +0000 (UTC) Received: by fxm22 with SMTP id 22so3643114fxm.36 for ; Tue, 06 Oct 2009 02:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MU5h0ndnDpbsyUzizE4hAoBCLRB8wQpNXfGMa2PGadA=; b=tJxsTFJizBZbBDiTeOMlcrfmOCQWqkkH2/NG/25YKPHKkjAgQwfReAwsH+kn3zDE0Z 8d43BzExW1tRszzahljggi7ec8eenN0tWUsaXnCBIGJ0DtNkuVbth/fA7UhirXT9cDSS esxRB0MpZ2hVg995fFgceJKSzGp2dNuSZbeYA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=elu+AkqcA7ACaKi0bjs+Ay9mEOryTc++f7aHHM1We9uk0HtkLMLL8zAnBS7Tsg0DPt fPBAdvmk6EGvzIGIBYUWqCcO2NZZjhpruwRIymBU8EwdNZqwt8YD4Az0PVP83YzcuArN m/KFGRNaZ6ZcrDKswZs8bG0kdDMvDSzrUHA98= MIME-Version: 1.0 Received: by 10.204.20.82 with SMTP id e18mr4923475bkb.168.1254820088551; Tue, 06 Oct 2009 02:08:08 -0700 (PDT) In-Reply-To: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> References: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> Date: Tue, 6 Oct 2009 13:08:08 +0400 Message-ID: From: pluknet To: Christian Schmidt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Boot issues with a Dell Inspiron 530 and 8.0 RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 09:08:10 -0000 2009/10/6 Christian Schmidt : > Hello list, > > I am seeing a strange issue with my Dell Inspiron 530 with 8.0 RC1-p1 > at around 50-75% percent of all boots. It all boils down to GENERIC > throwing the following: > > AP #1 (PHY #1) failed! > panic y/n? [y] panic: bye-bye > cpuid = 0 > > However, this only happens when booting from the hard disk. A boot > from the install CD works perfectly every time. Testing the machine > with 7.2 last night revealed the same issue, so this is not specific > to 8.0 > As an interesting side-note: the odds of a successful boot increase > dramtically when cold-booting. Rebooting from e.g. Linux or Windows > seems to push the failure-rate to around a 100% every time. > > The system itself is almost completely Intel. Some specifications: > Intel 82801 PCI Bridge > Intel G33/G31/P35/P31 PCIe > Intel ICH9 SMBus > I got an advice to try to update BIOS for a similar problem (visible in 6.x). Unfortunately it's not easy in my environment. Could you try that way and report? -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 09:18:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14EAF1065679 for ; Tue, 6 Oct 2009 09:18:16 +0000 (UTC) (envelope-from christian@nertenher.de) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id A61C08FC18 for ; Tue, 6 Oct 2009 09:18:15 +0000 (UTC) Received: by fxm22 with SMTP id 22so3647969fxm.36 for ; Tue, 06 Oct 2009 02:18:14 -0700 (PDT) MIME-Version: 1.0 Sender: christian@nertenher.de Received: by 10.223.27.79 with SMTP id h15mr356936fac.23.1254820694331; Tue, 06 Oct 2009 02:18:14 -0700 (PDT) In-Reply-To: References: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> From: Christian Schmidt Date: Tue, 6 Oct 2009 11:17:54 +0200 X-Google-Sender-Auth: d63b2fd54767e379 Message-ID: <309b65830910060217m51d18e8do5224aabb66ee0182@mail.gmail.com> To: pluknet Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: Boot issues with a Dell Inspiron 530 and 8.0 RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 09:18:16 -0000 On Tue, Oct 6, 2009 at 11:08, pluknet wrote: [...] > > I got an advice to try to update BIOS for a similar problem (visible in 6.x). > Unfortunately it's not easy in my environment. > Could you try that way and report? The BIOS is on the newest possible version. If it was that simple, I wouldn't have bothered writing to the list. :-) Thank you anyway. From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 10:50:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 951BB1065670; Tue, 6 Oct 2009 10:50:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 214DD8FC08; Tue, 6 Oct 2009 10:50:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id D5DFD41C6A1; Tue, 6 Oct 2009 12:50:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id Zyxxf0TrUv+O; Tue, 6 Oct 2009 12:50:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 3B51741C69F; Tue, 6 Oct 2009 12:50:06 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 5D55A4448E6; Tue, 6 Oct 2009 10:45:55 +0000 (UTC) Date: Tue, 6 Oct 2009 10:45:55 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Julian Elischer In-Reply-To: <4ACA5704.2070404@elischer.org> Message-ID: <20091006104529.B5956@maildrop.int.zabbadoz.net> References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> <6201873e0910051142q58e7563fqc7735261ea9ab3c6@mail.gmail.com> <4ACA4216.9060008@tomjudge.com> <4ACA5704.2070404@elischer.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Adam Vande More , FreeBSD virtualization mailing list , freebsd-current@freebsd.org, Jamie Gritton , Tom Judge , freebsd-jail@FreeBSD.org Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 10:50:08 -0000 On Mon, 5 Oct 2009, Julian Elischer wrote: > Tom Judge wrote: >> Adam Vande More wrote: >>> On Mon, Oct 5, 2009 at 12:47 PM, Tom Judge >> > wrote: >>> >>> Julian Elischer wrote: >>> >>> Tom Judge wrote: >>> >>> Hi, >>> >>> Does anyone know of a patch that will add per jail memory >>> limits so that a jail can't swallow the resources of the >>> entire box? >>> >>> >>> Thanks >>> >>> Tom >>> >>> not yet.. >>> >>> >>> I started to port this to 7.1 today: >>> >>> http://wiki.freebsd.org/JailResourceLimits >>> >>> >>> What are the peoples opinions on this patch? >>> >>> >>> Tom >>> >>> >>> If you're soliciting opinions if this will be used and is needed, I would >>> love to see this functionality. This is the main reason I've had to chose >>> XEN over jails. If you need some help testing, let me know. >>> >>> -- >>> Adam Vande More >> Hi Adam, >> >> I have a patch against 7.1 here: >> http://svn.tomjudge.com/freebsd/patches/jail-resource-limits/jail-limits.patch > > > > probably the person who should work with this in -current is james (CC'd) Probably the person who should be contacted is trasz who worked on hierachical resource limit per .., jail in p4. Though this is slightly different. I think it's ok if people need those things to update the pathes but I doubt any will probably ever make it into FreeBSD as those things are kind of contrary to the V_ plans. BTW, I think the patch referenced is not the latest I had seen and I thought that we also had one for 7.x or even for 8 already floating around. Maybe some investigation on list archives etc. might be helpful before starting to hack things. Maybe also check the links on http://wiki.freebsd.org/Jails >> >> >> I will try to bring the patch up to current when I get a chance but I have >> no real need to do this as we use 7.1 in production. >> >> Notes: >> >> * CPU limiting is not support is not supported unless you use >> shecd_4bsd. >> * I have not tested this on any system yet, just compile tested, I am >> putting it though its paces right now. >> >> Tom -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 11:04:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CDAB106566B; Tue, 6 Oct 2009 11:04:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id EC0538FC19; Tue, 6 Oct 2009 11:04:03 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n96B3xh6016246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Oct 2009 14:04:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n96B3xoh007745; Tue, 6 Oct 2009 14:03:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n96B3xVC007744; Tue, 6 Oct 2009 14:03:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 6 Oct 2009 14:03:59 +0300 From: Kostik Belousov To: Boris Samorodov Message-ID: <20091006110359.GH2259@deviant.kiev.zoral.com.ua> References: <78132948@bb.ipt.ru> <20091005190710.GW2259@deviant.kiev.zoral.com.ua> <22767770@bb.ipt.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nwn6wlxaqfRJxJFc" Content-Disposition: inline In-Reply-To: <22767770@bb.ipt.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: bz@freebsd.org, freebsd-current@freebsd.org Subject: Re: abort acroread at today's -current, but OK at 03-Oct -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 11:04:04 -0000 --Nwn6wlxaqfRJxJFc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 06, 2009 at 12:49:09PM +0400, Boris Samorodov wrote: > On Mon, 5 Oct 2009 22:07:10 +0300 Kostik Belousov wrote: > > On Mon, Oct 05, 2009 at 10:46:51PM +0400, Boris Samorodov wrote: > > >=20 > > > today I updated my computer from 03-Oct CURRENT to -current and > > > some ports were updated. And have got an error: > > > ----- > > > % acroread > > > zsh: abort acroread > > > % /bin/sh -x `which acroread` > > > + echo '' > > > + tr a-z A-Z > > > + ADOBE_LANG=3D'' > > > + : ENU > > > + BN=3Dacroread > > > + VN=3D'' > > > + [ -d /usr/local/Adobe/Reader8 ] > > > + ADOBE_VER=3D8 > > > + [ -d /usr/local/Adobe/Reader9 ] > > > + ACROBASE=3DAdobe/Reader8 > > > + BINPREFIX=3DAdobe/Reader8/bin > > > + MOZILLA_COMP_PATH=3D/..//usr/local/lib/linux-nvu > > > + export MOZILLA_COMP_PATH > > > + GTK_IM_MODULE=3Dxim > > > + export GTK_IM_MODULE > > > + UNAME_s=3DLinux > > > + export UNAME_s > > > + [ -x /usr/local/Adobe/Reader8/ENU/Adobe/Reader8/bin/acroread ] > > > + exec /compat/linux/bin/sh /usr/local/Adobe/Reader8/ENU/Adobe/Reader= 8/bin/acroread > > > zsh: abort /bin/sh -x `which acroread` > > > ----- > > >=20 > > > Loading old kernel gives a working acroread. What did I miss? > > > Thanks. >=20 > > Try this. >=20 > > diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c > > index 4ed7382..e958214 100644 > > --- a/sys/kern/imgact_elf.c > > +++ b/sys/kern/imgact_elf.c > > @@ -635,7 +635,8 @@ __elfN(load_file)(struct proc *p, const char *file,= u_long *addr, > > } > > =20 > > for (i =3D 0, numsegs =3D 0; i < hdr->e_phnum; i++) { > > - if (phdr[i].p_type =3D=3D PT_LOAD) { /* Loadable segment */ > > + if (phdr[i].p_type =3D=3D PT_LOAD && phdr[i].p_memsz !=3D 0) { > > + /* Loadable segment */ > > prot =3D 0; > > if (phdr[i].p_flags & PF_X) > > prot |=3D VM_PROT_EXECUTE; > > @@ -764,6 +768,8 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params= *imgp) > > for (i =3D 0; i < hdr->e_phnum; i++) { > > switch (phdr[i].p_type) { > > case PT_LOAD: /* Loadable segment */ > > + if (phdr[i].p_memsz =3D=3D 0) > > + break; > > prot =3D 0; > > if (phdr[i].p_flags & PF_X) > > prot |=3D VM_PROT_EXECUTE; >=20 > Thanks. Unfortunately there is no changes. Acroread works only with > security.bsd.map_at_zero=3D1. I see, with the help from bz@. Do you have amd64 or i386 system ? Anyway, please try http://people.freebsd.org/~kib/misc/pie.3.patch --Nwn6wlxaqfRJxJFc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrLJB0ACgkQC3+MBN1Mb4gH+wCeINesfp8Ee4WEpfsL3qEeLsOB NToAn2blq3kBdBlvqt7GcWMtXNXdPn00 =5nO9 -----END PGP SIGNATURE----- --Nwn6wlxaqfRJxJFc-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 12:26:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA7DE1065676 for ; Tue, 6 Oct 2009 12:26:34 +0000 (UTC) (envelope-from michio.jinbo@gmail.com) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id 986FA8FC18 for ; Tue, 6 Oct 2009 12:26:33 +0000 (UTC) Received: by fxm22 with SMTP id 22so3751674fxm.36 for ; Tue, 06 Oct 2009 05:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject:cc :in-reply-to:references:message-id:mime-version:content-type :content-transfer-encoding:x-mailer; bh=/2gjNK+qCBGBXIQN7GFqVg01wYdljL/jm7p+/a5oROY=; b=RWNU9F/9QQP15GgsD/bCaUDelgtNkwb6VbijESI4RnK1BszRkcLslvaWJaS+gdUV7a WQS0IJSJyNzbEHOKCX+fJD1vn5ccbvnpUSmjrFiiq6URycUH+eQaPsYLN+ZOFjU/MpOy fcw4hPcNdQU1FRbGcRtA5UfpwRqk2AlUm11VE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:cc:in-reply-to:references:message-id :mime-version:content-type:content-transfer-encoding:x-mailer; b=YN03W94Nbb02HYc/Z0fIrXRknOA9xMb2tBuiTpjtJ51epT6YvakpHynMDwIlW8i5+M ZLWv2hsVDT7hnkfyk9I4UUBjS/TV4MfvE5S1Y+022U4yxFya/kitYMCxNU1EzY1pwxWC ddKnYuqSjrORY1h0NRFa0/DKoPv0E/8HrZtrU= Received: by 10.86.208.2 with SMTP id f2mr482783fgg.16.1254831992514; Tue, 06 Oct 2009 05:26:32 -0700 (PDT) Received: from ?192.168.4.100? (router.jinbo.jp [210.229.61.161]) by mx.google.com with ESMTPS id d4sm182989fga.14.2009.10.06.05.26.23 (version=SSLv3 cipher=RC4-MD5); Tue, 06 Oct 2009 05:26:30 -0700 (PDT) Date: Tue, 06 Oct 2009 21:26:28 +0900 From: "Michio \"Karl\" Jinbo" To: Kostik Belousov In-Reply-To: <20091005195855.GC2259@deviant.kiev.zoral.com.ua> References: <20091005072515.3622.22FF24F1@gmail.com> <20091005195855.GC2259@deviant.kiev.zoral.com.ua> Message-Id: <20091006212622.0699.22FF24F1@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------_4ACB35D7000000000694_MULTIPART_MIXED_" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.51.07 [ja] Cc: freebsd-current@freebsd.org Subject: Re: pmap_invalidate_cache_range() panic on Xen Server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 12:26:34 -0000 --------_4ACB35D7000000000694_MULTIPART_MIXED_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit On Mon, 5 Oct 2009 22:58:55 +0300 Kostik Belousov wrote: > On Mon, Oct 05, 2009 at 07:25:18AM +0900, Michio Karl Jinbo wrote: > > On Sun, 4 Oct 2009 12:20:59 +0000 (UTC) > > Konstantin Belousov wrote: > > > > > Log: > > > MFC r197663: > > > As a workaround, for Intel CPUs, do not use CLFLUSH in > > > pmap_invalidate_cache_range() when self-snoop is apparently not reported > > > in cpu features. > > > > > > Approved by: re (bz, kensmith) > > > > I was tested r197663/r197744, but kernel panic again on Citrix Xen Server. > > > > using 8.0-RC1 install cd, results are > > 1. INTEL SU9400+HYPER-V(Windows2008 R2) -> boot OK. > > 2. AMD Athlon X2 TK-55+HYPER-V(Windows2008 R2) -> boot NG. > > 3. AMD PhenomII 940BK+Citrix Xen Server -> boot NG. > > > > I think INTEL CPUs are no problem, but AMD CPUs appear the problem. So I tested > > the following patch, kernel boot was successed on recent 9-CURRENT and environment 3. > > > > sorry, poor English. > Does the GENERIC kernel after r197744 boots on your plain hardware, > without any hypervisor ? > > Also, please provide the lines from dmesg with CPU features lists, > both from boot on plain hardware and under XEN. See attached 3files. as3810t.log is environment 1. vostro1000.log is environment 2. m4a78pro.log is environment 3. -- Michio "Karl" Jinbo --------_4ACB35D7000000000694_MULTIPART_MIXED_ Content-Type: application/octet-stream; name="as3810t.log" Content-Disposition: attachment; filename="as3810t.log" Content-Transfer-Encoding: base64 Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA5LjAtQ1VSUkVOVCAjMDogVHVlIE9jdCAgNiAwNzox MzoyNiBKU1QgMjAwOQogICAga2FybEBiZWVmLmppbmJvLmpwOi91c3Ivb2JqL3Vzci9zcmMvc3lz L0dFTkVSSUMgaTM4NgpXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3QgcmVk dWNlZCBwZXJmb3JtYW5jZS4KUHJlbG9hZGVkIGVsZiBrZXJuZWwgIi9ib290L2tlcm5lbC9rZXJu ZWwiIGF0IDB4YzExMjAwMDAuClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIg SHogcXVhbGl0eSAwCkNhbGlicmF0aW5nIFRTQyBjbG9jayAuLi4gVFNDIGNsb2NrOiAxNDAyMjU3 MzE4IEh6CkNQVTogSW50ZWwoUikgQ29yZShUTSkyIER1byBDUFUgICAgIFU5NDAwICBAIDEuNDBH SHogKDE0MDIuMjYtTUh6IDY4Ni1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIg IElkID0gMHgxMDY3YSAgU3RlcHBpbmcgPSAxMAogIEZlYXR1cmVzPTB4YmZlYmZiZmY8RlBVLFZN RSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQ QVQsUFNFMzYsQ0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixTU0UsU1NFMixTUyxIVFQsVE0sUEJF PgogIEZlYXR1cmVzMj0weDQwOGUzZmQ8U1NFMyxEVEVTNjQsTU9OLERTX0NQTCxWTVgsU01YLEVT VCxUTTIsU1NTRTMsQ1gxNix4VFBSLFBEQ00sU1NFNC4xLFhTQVZFPgogIEFNRCBGZWF0dXJlcz0w eDIwMTAwMDAwPE5YLExNPgogIEFNRCBGZWF0dXJlczI9MHgxPExBSEY+CiAgVFNDOiBQLXN0YXRl IGludmFyaWFudAoKSW5zdHJ1Y3Rpb24gVExCOiA0IEtCIFBhZ2VzLCA0LXdheSBzZXQgYXNzb2Np YXRpdmUsIDEyOCBlbnRyaWVzCjFzdC1sZXZlbCBpbnN0cnVjdGlvbiBjYWNoZTogMzIgS0IsIDgt d2F5IHNldCBhc3NvY2lhdGl2ZSwgNjQgYnl0ZSBsaW5lIHNpemUKMXN0LWxldmVsIGRhdGEgY2Fj aGU6IDMyIEtCLCA4LXdheSBzZXQgYXNzb2NpYXRpdmUsIDY0IGJ5dGUgbGluZSBzaXplCkwyIGNh Y2hlOiAzMDcyIGtieXRlcywgOC13YXkgYXNzb2NpYXRpdmUsIDY0IGJ5dGVzL2xpbmUKcmVhbCBt ZW1vcnkgID0gNDI5NDk2NzI5NiAoNDA5NiBNQikKUGh5c2ljYWwgbWVtb3J5IGNodW5rKHMpOgow eDAwMDAwMDAwMDAwMDEwMDAgLSAweDAwMDAwMDAwMDAwOWNmZmYsIDYzODk3NiBieXRlcyAoMTU2 IHBhZ2VzKQoweDAwMDAwMDAwMDAxMDAwMDAgLSAweDAwMDAwMDAwMDAzZmZmZmYsIDMxNDU3Mjgg Ynl0ZXMgKDc2OCBwYWdlcykKMHgwMDAwMDAwMDAxNDI2MDAwIC0gMHgwMDAwMDAwMGI2OWJlZmZm LCAzMDQyNTQ1NjY0IGJ5dGVzICg3NDI4MDkgcGFnZXMpCjB4MDAwMDAwMDBiOWViZjAwMCAtIDB4 MDAwMDAwMDBiOWY3MGZmZiwgNzI5MDg4IGJ5dGVzICgxNzggcGFnZXMpCjB4MDAwMDAwMDBiOWZi ZjAwMCAtIDB4MDAwMDAwMDBiOWZjZWZmZiwgNjU1MzYgYnl0ZXMgKDE2IHBhZ2VzKQphdmFpbCBt ZW1vcnkgPSAzMDQxODgyMTEyICgyOTAwIE1CKQpUYWJsZSAnRkFDUCcgYXQgMHhiOWZmNDAwMApU YWJsZSAnRE1BUicgYXQgMHhiOWZmNTAwMApUYWJsZSAnSFBFVCcgYXQgMHhiOWZmMzAwMApUYWJs ZSAnQVBJQycgYXQgMHhiOWZmMjAwMApBUElDOiBGb3VuZCB0YWJsZSBhdCAweGI5ZmYyMDAwCkFQ SUM6IFVzaW5nIHRoZSBNQURUIGVudW1lcmF0b3IuCk1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDAg QUNQSSBJRCAxOiBlbmFibGVkClNNUDogQWRkZWQgQ1BVIDAgKEFQKQpNQURUOiBGb3VuZCBDUFUg QVBJQyBJRCAxIEFDUEkgSUQgMjogZW5hYmxlZApTTVA6IEFkZGVkIENQVSAxIChBUCkKTUFEVDog Rm91bmQgQ1BVIEFQSUMgSUQgMCBBQ1BJIElEIDM6IGRpc2FibGVkCk1BRFQ6IEZvdW5kIENQVSBB UElDIElEIDAgQUNQSSBJRCA0OiBkaXNhYmxlZApBQ1BJIEFQSUMgVGFibGU6IDxBQ1JTWVMgQUNS UFJEQ1Q+CklOVFI6IEFkZGluZyBsb2NhbCBBUElDIDEgYXMgYSB0YXJnZXQKRnJlZUJTRC9TTVA6 IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogMiBDUFVzCkZyZWVCU0QvU01QOiAxIHBh Y2thZ2UocykgeCAyIGNvcmUocykKIGNwdTAgKEJTUCk6IEFQSUMgSUQ6ICAwCiBjcHUxIChBUCk6 IEFQSUMgSUQ6ICAxCnBucGJpb3M6IEZvdW5kIFBuUCBCSU9TIGRhdGEgYXQgMHhjMDBmZTBmMApw bnBiaW9zOiBFbnRyeSA9IGYwMDAwOmJhMDQgIFJldiA9IDEuMApwbnBiaW9zOiBPRU0gSUQgODIy NDc0NGUKT3RoZXIgQklPUyBzaWduYXR1cmVzIGZvdW5kOgpBUElDOiBDUFUgMCBoYXMgQUNQSSBJ RCAxCkFQSUM6IENQVSAxIGhhcyBBQ1BJIElEIDIKVUxFOiBzZXR1cCBjcHUgMApVTEU6IHNldHVw IGNwdSAxCkFDUEk6IFJTRFAgMHhmZTAyMCAwMDAyNCAodjIgQUNSU1lTKQpBQ1BJOiBYU0RUIDB4 YjlmZjYxMjAgMDAwODQgKHYxIEFDUlNZUyBBQ1JQUkRDVCAwMDAwMDAwMSAgICAgIDAxMDAwMDEz KQpBQ1BJOiBGQUNQIDB4YjlmZjQwMDAgMDAwRjQgKHY0IEFDUlNZUyBBQ1JQUkRDVCAwMDAwMDAw MSAxMDI1IDAxMDAwMDEzKQpBQ1BJOiBEU0RUIDB4YjlmZTcwMDAgMDhFNzAgKHYxIEFDUlNZUyBB Q1JQUkRDVCAwMDAwMDAwMSAxMDI1IDAxMDAwMDEzKQpBQ1BJOiBGQUNTIDB4YjlmN2UwMDAgMDAw NDAKQUNQSTogRE1BUiAweGI5ZmY1MDAwIDAwMEY4ICh2MSAgICAgICAgICAgICAgID8gMDAwMDAw MDEgICAgICAwMDAwMDAwMCkKQUNQSTogSFBFVCAweGI5ZmYzMDAwIDAwMDM4ICh2MSBBQ1JTWVMg QUNSUFJEQ1QgMDAwMDAwMDEgMTAyNSAwMTAwMDAxMykKQUNQSTogQVBJQyAweGI5ZmYyMDAwIDAw MDZDICh2MiBBQ1JTWVMgQUNSUFJEQ1QgMDAwMDAwMDEgMTAyNSAwMTAwMDAxMykKQUNQSTogTUNG RyAweGI5ZmYxMDAwIDAwMDNDICh2MSBBQ1JTWVMgQUNSUFJEQ1QgMDAwMDAwMDEgMTAyNSAwMTAw MDAxMykKQUNQSTogQVNGISAweGI5ZmYwMDAwIDAwMEE1ICh2MzIgQUNSU1lTIEFDUlBSRENUIDAw MDAwMDAxIDEwMjUgMDEwMDAwMTMpCkFDUEk6IFNMSUMgMHhiOWZlNjAwMCAwMDE3NiAodjEgQUNS U1lTIEFDUlBSRENUIDAwMDAwMDAxIDEwMjUgMDEwMDAwMTMpCkFDUEk6IEJPT1QgMHhiOWZlNTAw MCAwMDAyOCAodjEgQUNSU1lTIEFDUlBSRENUIDAwMDAwMDAxIDEwMjUgMDEwMDAwMTMpCkFDUEk6 IFNTRFQgMHhiOWZlNDAwMCAwMDBBNyAodjEgQUNSU1lTIEFDUlBSRENUIDAwMDAxMDAwIDEwMjUg MjAwNTExMTcpCkFDUEk6IFNTRFQgMHhiOWZlMTAwMCAwMDY1NSAodjEgIFBtUmVmICAgIENwdVBt IDAwMDAzMDAwIElOVEwgMjAwNTExMTcpCkFDUEk6IFNTRFQgMHhiOWZlMDAwMCAwMDI1OSAodjEg IFBtUmVmICBDcHUwVHN0IDAwMDAzMDAwIElOVEwgMjAwNTExMTcpCkFDUEk6IFNTRFQgMHhiOWZk ZjAwMCAwMDIwRiAodjEgIFBtUmVmICAgIEFwVHN0IDAwMDAzMDAwIElOVEwgMjAwNTExMTcpCk1B RFQ6IEZvdW5kIElPIEFQSUMgSUQgNCwgSW50ZXJydXB0IDAgYXQgMHhmZWMwMDAwMAppb2FwaWMw OiBDaGFuZ2luZyBBUElDIElEIHRvIDQKaW9hcGljMDogUm91dGluZyBleHRlcm5hbCA4MjU5QSdz IC0+IGludHBpbiAwCk1BRFQ6IEludGVycnVwdCBvdmVycmlkZTogc291cmNlIDAsIGlycSAyCmlv YXBpYzA6IFJvdXRpbmcgSVJRIDAgLT4gaW50cGluIDIKTUFEVDogSW50ZXJydXB0IG92ZXJyaWRl OiBzb3VyY2UgOSwgaXJxIDkKaW9hcGljMDogaW50cGluIDkgdHJpZ2dlcjogbGV2ZWwKaW9hcGlj MCA8VmVyc2lvbiAyLjA+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZApjcHUwIEJTUDoKICAgICBJ RDogMHgwMDAwMDAwMCAgIFZFUjogMHgwMDA1MDAxNCBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZm ZmZmZmZmCiAgbGludDA6IDB4MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAw MDAwIFNWUjogMHgwMDAwMDFmZgogIHRpbWVyOiAweDAwMDEwMGVmIHRoZXJtOiAweDAwMDAwMjAw IGVycjogMHgwMDAxMDAwMCBwY206IDB4MDAwMTA0MDAKd2xhbjogPDgwMi4xMSBMaW5rIExheWVy PgpyYW5kb206IDxlbnRyb3B5IHNvdXJjZSwgU29mdHdhcmUsIFlhcnJvdz4KbmZzbG9jazogcHNl dWRvLWRldmljZQprYmQ6IG5ldyBhcnJheSBzaXplIDQKa2JkMSBhdCBrYmRtdXgwCm1lbTogPG1l bW9yeT4KUGVudGl1bSBQcm8gTVRSUiBzdXBwb3J0IGVuYWJsZWQKaW86IDxJL08+Cm51bGw6IDxu dWxsIGRldmljZSwgemVybyBkZXZpY2U+CmhwdHJyOiBSb2NrZXRSQUlEIDE3eHgvMnh4eCBTQVRB IGNvbnRyb2xsZXIgZHJpdmVyIHYxLjIKbnB4MDogSU5UIDE2IGludGVyZmFjZQphY3BpMDogPEFD UlNZUyBBQ1JQUkRDVD4gb24gbW90aGVyYm9hcmQKUENJZTogTWVtb3J5IE1hcHBlZCBjb25maWd1 cmF0aW9uIGJhc2UgQCAweGY4MDAwMDAwCnBjaWJpb3M6IE5vIGNhbGwgZW50cnkgcG9pbnQKaW9h cGljMDogcm91dGluZyBpbnRwaW4gOSAoSVNBIElSUSA5KSB0byBsYXBpYyAwIHZlY3RvciA0OAph Y3BpMDogW01QU0FGRV0KYWNwaTA6IFtJVEhSRUFEXQpBQ1BJOiBFeGVjdXRlZCAxIGJsb2NrcyBv ZiBtb2R1bGUtbGV2ZWwgZXhlY3V0YWJsZSBBTUwgY29kZQphY3BpMDogUG93ZXIgQnV0dG9uIChm aXhlZCkKYWNwaTA6IHdha2V1cCBjb2RlIHZhIDB4YzY1MWQwMDAgcGEgMHgxMDAwCkFjcGlPc0Rl cml2ZVBjaUlkOiBcXF9TQl8uUENJMC5IQlVTIC0+IGJ1cyAwIGRldiAwIGZ1bmMgMApBY3BpT3NE ZXJpdmVQY2lJZDogXFxfU0JfLlBDSTAuTFBDXy5QUlIwIC0+IGJ1cyAwIGRldiAzMSBmdW5jIDAK QWNwaU9zRGVyaXZlUGNpSWQ6IFxcX1NCXy5QQ0kwLkxQQ18uUFJSMSAtPiBidXMgMCBkZXYgMzEg ZnVuYyAwCkFDUEkgdGltZXI6IDAvMyAwLzMgMC8zIDAvMyAwLzMgMC8zIDAvMyAwLzMgMC8zIDAv MyAtPiAwClRpbWVjb3VudGVyICJBQ1BJLXNhZmUiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxp dHkgODUwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4 NDA4LTB4NDBiIG9uIGFjcGkwCmFjcGlfZWMwOiA8RW1iZWRkZWQgQ29udHJvbGxlcjogR1BFIDB4 MTg+IHBvcnQgMHg2MiwweDY2IG9uIGFjcGkwCnBjaV9saW5rMDogICAgICAgIEluZGV4ICBJUlEg IFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAgICAwICAz IDQgNSA3IDkgMTAgMTEgMTIKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMSAgIE4gICAgIDAg IDMgNCA1IDcgOSAxMCAxMSAxMgogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAg MCAgMyA0IDUgNyA5IDEwIDExIDEyCnBjaV9saW5rMTogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAg UmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA3 IDkgMTAgMTEgMTIKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1 IDcgOSAxMCAxMSAxMgogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0 IDUgNyA5IDEwIDExIDEyCnBjaV9saW5rMjogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJ UlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA3IDkgMTAg MTEgMTIKICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDcgOSAx MCAxMSAxMgogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5 IDEwIDExIDEyCnBjaV9saW5rMzogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAg SW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIK ICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAx MgogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDEx IDEyCnBjaV9saW5rNDogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlh bCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBWYWxp ZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgogIEFm dGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCnBj aV9saW5rNTogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9i ZSAgICAgICAwICAgMTAgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBWYWxpZGF0aW9u ICAgICAgICAgIDAgICAxMCAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgogIEFmdGVyIERp c2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCnBjaV9saW5r NjogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAg ICAwICAgMTEgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBWYWxpZGF0aW9uICAgICAg ICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgogIEFmdGVyIERpc2FibGUg ICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCnBjaV9saW5rNzogICAg ICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAg MTEgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBWYWxpZGF0aW9uICAgICAgICAgIDAg ICAxMSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgogIEFmdGVyIERpc2FibGUgICAgICAg MCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCmFjcGlfaHBldDA6IDxIaWdoIFBy ZWNpc2lvbiBFdmVudCBUaW1lcj4gaW9tZW0gMHhmZWQwMDAwMC0weGZlZDAwM2ZmIG9uIGFjcGkw CmFjcGlfaHBldDA6IHZlbmQ6IDB4ODA4NiByZXY6IDB4MSBudW06IDMgaHo6IDE0MzE4MTgwIG9w dHM6IGxlZ2FjeV9yb3V0ZSA2NC1iaXQKVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAxNDMx ODE4MCBIeiBxdWFsaXR5IDkwMAphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0b24+IG9uIGFjcGkw CmFjcGlfbGlkMDogPENvbnRyb2wgTWV0aG9kIExpZCBTd2l0Y2g+IG9uIGFjcGkwCmFjcGlfYnV0 dG9uMTogPFNsZWVwIEJ1dHRvbj4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRn ZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li MApwY2kwOiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTAKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBk ZXY9MHgyYTQwLCByZXZpZD0weDA3Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9MCwgZnVuYz0wCglj bGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA2LCBzdGF0 cmVnPTB4MjA5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBt aW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgw ODYsIGRldj0weDJhNDIsIHJldmlkPTB4MDcKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yLCBmdW5j PTAKCWNsYXNzPTAzLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDcs IHN0YXRyZWc9MHgwMDkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJx PTExCglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0 cyAxIG1lc3NhZ2UKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGUwMDAw MDAwLCBzaXplIDIyLCBlbmFibGVkCgltYXBbMThdOiB0eXBlIFByZWZldGNoYWJsZSBNZW1vcnks IHJhbmdlIDY0LCBiYXNlIDB4ZDAwMDAwMDAsIHNpemUgMjgsIGVuYWJsZWQKCW1hcFsyMF06IHR5 cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MzExMCwgc2l6ZSAgMywgZW5hYmxlZApwY2li MDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yLklOVEEKcGNpYjA6IHNsb3QgMiBJTlRBIGhhcmR3aXJl ZCB0byBJUlEgMTYKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyYTQzLCByZXZpZD0weDA3 Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9MiwgZnVuYz0xCgljbGFzcz0wMy04MC0wMCwgaGRydHlw ZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDA5MCwgY2FjaGVsbnN6 PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1h eGxhdD0weDAwICgwIG5zKQoJcG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQw CgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhlMjQwMDAwMCwgc2l6ZSAy MCwgZW5hYmxlZApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI5MzcsIHJldmlkPTB4MDMK CWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yNiwgZnVuYz0wCgljbGFzcz0wYy0wMy0wMCwgaGRydHlw ZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6 PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1h eGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJbWFwWzIwXTogdHlwZSBJL08gUG9y dCwgcmFuZ2UgMzIsIGJhc2UgMHgzMGUwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVk IGVudHJ5IGZvciAwLjI2LklOVEEKcGNpYjA6IHNsb3QgMjYgSU5UQSBoYXJkd2lyZWQgdG8gSVJR IDE2CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjkzOCwgcmV2aWQ9MHgwMwoJZG9tYWlu PTAsIGJ1cz0wLCBzbG90PTI2LCBmdW5jPTEKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAs IG1mZGV2PTAKCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdv cmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4 MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTEwCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5n ZSAzMiwgYmFzZSAweDMwYzAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkg Zm9yIDAuMjYuSU5UQgpwY2liMDogc2xvdCAyNiBJTlRCIGhhcmR3aXJlZCB0byBJUlEgMjEKZm91 bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyOTNjLCByZXZpZD0weDAzCglkb21haW49MCwgYnVz PTAsIHNsb3Q9MjYsIGZ1bmM9NwoJY2xhc3M9MGMtMDMtMjAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MAoJY21kcmVnPTB4MDAwNiwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCgls YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu cykKCWludHBpbj1kLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVu dCBEMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZTQ1MDVjMDAsIHNp emUgMTAsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjYuSU5URApwY2liMDog c2xvdCAyNiBJTlREIGhhcmR3aXJlZCB0byBJUlEgMTkKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBk ZXY9MHgyOTNlLCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjcsIGZ1bmM9MAoJ Y2xhc3M9MDQtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNiwgc3Rh dHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyks IG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTEx Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAx IG1lc3NhZ2UsIDY0IGJpdAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4 ZTQ1MDAwMDAsIHNpemUgMTQsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjcu SU5UQQpwY2liMDogc2xvdCAyNyBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMjIKZm91bmQtPgl2ZW5k b3I9MHg4MDg2LCBkZXY9MHgyOTQwLCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9 MjgsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MQoJY21kcmVn PTB4MDAwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9 MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRw aW49YSwgaXJxPTI1NQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglN U0kgc3VwcG9ydHMgMSBtZXNzYWdlCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4Mjk0NCwg cmV2aWQ9MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI4LCBmdW5jPTIKCWNsYXNzPTA2LTA0 LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEw LCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgw MCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWMsIGlycT0yNTUKCXBvd2Vyc3Bl YyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZQpm b3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI5MzQsIHJldmlkPTB4MDMKCWRvbWFpbj0wLCBi dXM9MCwgc2xvdD0yOSwgZnVuYz0wCgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRl dj0xCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykK CWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgw IG5zKQoJaW50cGluPWEsIGlycT0xMQoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIs IGJhc2UgMHgzMGEwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAw LjI5LklOVEEKcGNpYjA6IHNsb3QgMjkgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDIzCmZvdW5kLT4J dmVuZG9yPTB4ODA4NiwgZGV2PTB4MjkzNSwgcmV2aWQ9MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBz bG90PTI5LCBmdW5jPTEKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNt ZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGlt ZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglp bnRwaW49YiwgaXJxPTExCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAw eDMwODAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5U QgpwY2liMDogc2xvdCAyOSBJTlRCIGhhcmR3aXJlZCB0byBJUlEgMTkKZm91bmQtPgl2ZW5kb3I9 MHg4MDg2LCBkZXY9MHgyOTM2LCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9Mjks IGZ1bmM9MgoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4 MDAwNSwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAw ICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1k LCBpcnE9MTEKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MzA2MCwg c2l6ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRECnBjaWIw OiBzbG90IDI5IElOVEQgaGFyZHdpcmVkIHRvIElSUSAxNgpmb3VuZC0+CXZlbmRvcj0weDgwODYs IGRldj0weDI5MzksIHJldmlkPTB4MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOSwgZnVuYz0z CgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBz dGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMp LCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWMsIGlycT0x MQoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgzMDQwLCBzaXplICA1 LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI5LklOVEMKcGNpYjA6IHNsb3Qg MjkgSU5UQyBoYXJkd2lyZWQgdG8gSVJRIDE4CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4 MjkzYSwgcmV2aWQ9MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI5LCBmdW5jPTcKCWNsYXNz PTBjLTAzLTIwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9 MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdu dD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dl cnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgTWVtb3J5 LCByYW5nZSAzMiwgYmFzZSAweGU0NTA1ODAwLCBzaXplIDEwLCBlbmFibGVkCnBjaWIwOiBtYXRj aGVkIGVudHJ5IGZvciAwLjI5LklOVEEKcGNpYjA6IHNsb3QgMjkgSU5UQSBoYXJkd2lyZWQgdG8g SVJRIDIzCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjQ0OCwgcmV2aWQ9MHg5MwoJZG9t YWluPTAsIGJ1cz0wLCBzbG90PTMwLCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAxLCBoZHJ0eXBlPTB4 MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MCAo ZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjkxNywgcmV2aWQ9MHgw MwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMxLCBmdW5jPTAKCWNsYXNzPTA2LTAxLTAwLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxu c3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwg bWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjkyOSwgcmV2 aWQ9MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMxLCBmdW5jPTIKCWNsYXNzPTAxLTA2LTAx LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMmIwLCBj YWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTExCglwb3dlcnNwZWMgMyAg c3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxNiBtZXNzYWdlcwoJbWFw WzEwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgzMTA4LCBzaXplICAzLCBlbmFi bGVkCgltYXBbMTRdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDMxMWMsIHNpemUg IDIsIGVuYWJsZWQKCW1hcFsxOF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MzEw MCwgc2l6ZSAgMywgZW5hYmxlZAoJbWFwWzFjXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJh c2UgMHgzMTE4LCBzaXplICAyLCBlbmFibGVkCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5n ZSAzMiwgYmFzZSAweDMwMjAsIHNpemUgIDUsIGVuYWJsZWQKCW1hcFsyNF06IHR5cGUgTWVtb3J5 LCByYW5nZSAzMiwgYmFzZSAweGU0NTA1MDAwLCBzaXplIDExLCBlbmFibGVkCnBjaWIwOiBtYXRj aGVkIGVudHJ5IGZvciAwLjMxLklOVEIKcGNpYjA6IHNsb3QgMzEgSU5UQiBoYXJkd2lyZWQgdG8g SVJRIDE5CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjkzMCwgcmV2aWQ9MHgwMwoJZG9t YWluPTAsIGJ1cz0wLCBzbG90PTMxLCBmdW5jPTMKCWNsYXNzPTBjLTA1LTAwLCBoZHJ0eXBlPTB4 MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDMsIHN0YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9MCAo ZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpCglpbnRwaW49YywgaXJxPTExCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFu Z2UgNjQsIGJhc2UgMHhlNDUwNjAwMCwgc2l6ZSAgOCwgZW5hYmxlZAoJbWFwWzIwXTogdHlwZSBJ L08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgzMDAwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBt YXRjaGVkIGVudHJ5IGZvciAwLjMxLklOVEMKcGNpYjA6IHNsb3QgMzEgSU5UQyBoYXJkd2lyZWQg dG8gSVJRIDE4CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjkzMiwgcmV2aWQ9MHgwMwoJ ZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMxLCBmdW5jPTYKCWNsYXNzPTExLTgwLTAwLCBoZHJ0eXBl PTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDIsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9 MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4 bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YywgaXJxPTExCglwb3dlcnNwZWMgMyAgc3VwcG9ydHMg RDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAw eGU0NTA0MDAwLCBzaXplIDEyLCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjMx LklOVEMKcGNpYjA6IHNsb3QgMzEgSU5UQyBoYXJkd2lyZWQgdG8gSVJRIDE4CnZnYXBjaTA6IDxW R0EtY29tcGF0aWJsZSBkaXNwbGF5PiBwb3J0IDB4MzExMC0weDMxMTcgbWVtIDB4ZTAwMDAwMDAt MHhlMDNmZmZmZiwweGQwMDAwMDAwLTB4ZGZmZmZmZmYgaXJxIDE2IGF0IGRldmljZSAyLjAgb24g cGNpMAphZ3AwOiA8SW50ZWwgR000NSBTVkdBIGNvbnRyb2xsZXI+IG9uIHZnYXBjaTAKdmdhcGNp MDogUmVzZXJ2ZWQgMHgxMDAwMDAwMCBieXRlcyBmb3IgcmlkIDB4MTggdHlwZSAzIGF0IDB4ZDAw MDAwMDAKdmdhcGNpMDogUmVzZXJ2ZWQgMHg0MDAwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUg MyBhdCAweGUwMDAwMDAwCmFncDA6IGFwZXJ0dXJlIHNpemUgaXMgMjU2TSwgZGV0ZWN0ZWQgNjU1 MzJrIHN0b2xlbiBtZW1vcnkKdmdhcGNpMTogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IG1lbSAw eGUyNDAwMDAwLTB4ZTI0ZmZmZmYgYXQgZGV2aWNlIDIuMSBvbiBwY2kwCnVoY2kwOiA8SW50ZWwg ODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDMwZTAtMHgzMGZmIGlycSAxNiBh dCBkZXZpY2UgMjYuMCBvbiBwY2kwCnVoY2kwOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQg MHgyMCB0eXBlIDQgYXQgMHgzMGUwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE2IChQQ0kgSVJR IDE2KSB0byBsYXBpYyAwIHZlY3RvciA0OQp1aGNpMDogW01QU0FGRV0KdWhjaTA6IFtJVEhSRUFE XQp1aGNpMDogTGVnU3VwID0gMHgwZjEwCnVzYnVzMDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNC IGNvbnRyb2xsZXI+IG9uIHVoY2kwCnVoY2kxOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29u dHJvbGxlcj4gcG9ydCAweDMwYzAtMHgzMGRmIGlycSAyMSBhdCBkZXZpY2UgMjYuMSBvbiBwY2kw CnVoY2kxOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHgzMGMw CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIxIChQQ0kgSVJRIDIxKSB0byBsYXBpYyAwIHZlY3Rv ciA1MAp1aGNpMTogW01QU0FGRV0KdWhjaTE6IFtJVEhSRUFEXQp1aGNpMTogTGVnU3VwID0gMHgw ZjAwCnVzYnVzMTogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kx CmVoY2kwOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGU0 NTA1YzAwLTB4ZTQ1MDVmZmYgaXJxIDE5IGF0IGRldmljZSAyNi43IG9uIHBjaTAKZWhjaTA6IFJl c2VydmVkIDB4NDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhlNDUwNWMwMAppb2Fw aWMwOiByb3V0aW5nIGludHBpbiAxOSAoUENJIElSUSAxOSkgdG8gbGFwaWMgMCB2ZWN0b3IgNTEK ZWhjaTA6IFtNUFNBRkVdCmVoY2kwOiBbSVRIUkVBRF0KdXNidXMyOiB3YWl0aW5nIGZvciBCSU9T IHRvIGdpdmUgdXAgY29udHJvbAp1c2J1czI6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMyOiA8SW50 ZWwgODI4MDFJIChJQ0g5KSBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVoY2kwCnBjaTA6IDxtdWx0 aW1lZGlhLCBIREE+IGF0IGRldmljZSAyNy4wIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaWIxOiA8 QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDI4LjAgb24gcGNpMApwY2liMTogICBkb21h aW4gICAgICAgICAgICAwCnBjaWIxOiAgIHNlY29uZGFyeSBidXMgICAgIDEKcGNpYjE6ICAgc3Vi b3JkaW5hdGUgYnVzICAgMQpwY2liMTogICBJL08gZGVjb2RlICAgICAgICAweDIwMDAtMHgyZmZm CnBjaWIxOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZTM1MDAwMDAtMHhlNDRmZmZmZgpwY2liMTog ICBwcmVmZXRjaGVkIGRlY29kZSAweGUwNDAwMDAwLTB4ZTEzZmZmZmYKcGNpMTogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjEKcGNpMTogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0xCmZvdW5kLT4JdmVu ZG9yPTB4ODA4NiwgZGV2PTB4NDIzMiwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0xLCBzbG90 PTAsIGZ1bmM9MAoJY2xhc3M9MDItODAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVn PTB4MDAwNiwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9 MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRw aW49YSwgaXJxPTExCglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1T SSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdl IDY0LCBiYXNlIDB4ZTM1MDAwMDAsIHNpemUgMTMsIGVuYWJsZWQKcGNpYjE6IHJlcXVlc3RlZCBt ZW1vcnkgcmFuZ2UgMHhlMzUwMDAwMC0weGUzNTAxZmZmOiBnb29kCnBjaWIxOiBtYXRjaGVkIGVu dHJ5IGZvciAxLjAuSU5UQQpwY2liMTogc2xvdCAwIElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNgpw Y2kxOiA8bmV0d29yaz4gYXQgZGV2aWNlIDAuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2liMjog PEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyOC4yIG9uIHBjaTAKcGNpYjI6ICAgZG9t YWluICAgICAgICAgICAgMApwY2liMjogICBzZWNvbmRhcnkgYnVzICAgICAyCnBjaWIyOiAgIHN1 Ym9yZGluYXRlIGJ1cyAgIDIKcGNpYjI6ICAgSS9PIGRlY29kZSAgICAgICAgMHgxMDAwLTB4MWZm ZgpwY2liMjogICBtZW1vcnkgZGVjb2RlICAgICAweGUyNTAwMDAwLTB4ZTM0ZmZmZmYKcGNpYjI6 ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhlMTQwMDAwMC0weGUyM2ZmZmZmCnBjaTI6IDxBQ1BJIFBD SSBidXM+IG9uIHBjaWIyCnBjaTI6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9Mgpmb3VuZC0+CXZl bmRvcj0weDE5NjksIGRldj0weDEwNjMsIHJldmlkPTB4YzAKCWRvbWFpbj0wLCBidXM9Miwgc2xv dD0wLCBmdW5jPTAKCWNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJl Zz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVy PTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50 cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglN U0kgc3VwcG9ydHMgMSBtZXNzYWdlLCA2NCBiaXQKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5n ZSA2NCwgYmFzZSAweGUyNTAwMDAwLCBzaXplIDE4LCBlbmFibGVkCnBjaWIyOiByZXF1ZXN0ZWQg bWVtb3J5IHJhbmdlIDB4ZTI1MDAwMDAtMHhlMjUzZmZmZjogZ29vZAoJbWFwWzE4XTogdHlwZSBJ L08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgxMDAwLCBzaXplICA3LCBlbmFibGVkCnBjaWIyOiBy ZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4MTAwMC0weDEwN2Y6IGluIHJhbmdlCnBjaWIyOiBtYXRjaGVk IGVudHJ5IGZvciAyLjAuSU5UQQpwY2liMjogc2xvdCAwIElOVEEgaGFyZHdpcmVkIHRvIElSUSAx OAphbGMwOiA8QXRoZXJvcyBBUjgxMzEgUENJZSBHaWdhYml0IEV0aGVybmV0PiBwb3J0IDB4MTAw MC0weDEwN2YgbWVtIDB4ZTI1MDAwMDAtMHhlMjUzZmZmZiBpcnEgMTggYXQgZGV2aWNlIDAuMCBv biBwY2kyCmFsYzA6IFJlc2VydmVkIDB4NDAwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBh dCAweGUyNTAwMDAwCmFsYzA6IFJlYWQgcmVxdWVzdCBzaXplIDogNTEyIGJ5dGVzLgphbGMwOiBU TFAgcGF5bG9hZCBzaXplIDogMTI4IGJ5dGVzLgphbGMwOiBSQ0IgNjQgYnl0ZXMKYWxjMDogQVNQ TSBMMSBlbmFibGVkCmFsYzA6IFBDSSBkZXZpY2UgcmV2aXNpb24gOiAweDAwYzAKYWxjMDogQ2hp cCBpZC9yZXZpc2lvbiA6IDB4NDAwMgphbGMwOiAxNTg3MiBUeCBGSUZPLCAxNTM2MCBSeCBGSUZP CmFsYzA6IE1TSVggY291bnQgOiAwCmFsYzA6IE1TSSBjb3VudCA6IDEKYWxjMDogYXR0ZW1wdGlu ZyB0byBhbGxvY2F0ZSAxIE1TSSB2ZWN0b3JzICgxIHN1cHBvcnRlZCkKbXNpOiByb3V0aW5nIE1T SSBJUlEgMjU2IHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3IgNTIKYWxjMDogdXNpbmcgSVJRIDI1NiBm b3IgTVNJCmFsYzA6IFVzaW5nIDEgTVNJIG1lc3NhZ2UocykuCm1paWJ1czA6IDxNSUkgYnVzPiBv biBhbGMwCmF0cGh5MDogPEF0aGVyb3MgRjEgMTAvMTAwLzEwMDAgUEhZPiBQSFkgMCBvbiBtaWli dXMwCmF0cGh5MDogT1VJIDB4MDAxMzc0LCBtb2RlbCAweDAwMDEsIHJldi4gMTEKYXRwaHkwOiAg MTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgMTAwMGJhc2VU LUZEWCwgYXV0bwphbGMwOiBicGYgYXR0YWNoZWQKYWxjMDogRXRoZXJuZXQgYWRkcmVzczogMDA6 YTA6ZDE6Y2Y6ODI6NDEKYWxjMDogW01QU0FGRV0KYWxjMDogW0ZJTFRFUl0KdWhjaTI6IDxJbnRl bCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4MzBhMC0weDMwYmYgaXJxIDIz IGF0IGRldmljZSAyOS4wIG9uIHBjaTAKdWhjaTI6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJp ZCAweDIwIHR5cGUgNCBhdCAweDMwYTAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjMgKFBDSSBJ UlEgMjMpIHRvIGxhcGljIDAgdmVjdG9yIDUzCnVoY2kyOiBbTVBTQUZFXQp1aGNpMjogW0lUSFJF QURdCnVoY2kyOiBMZWdTdXAgPSAweDBmMDAKdXNidXMzOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBV U0IgY29udHJvbGxlcj4gb24gdWhjaTIKdWhjaTM6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBj b250cm9sbGVyPiBwb3J0IDB4MzA4MC0weDMwOWYgaXJxIDE5IGF0IGRldmljZSAyOS4xIG9uIHBj aTAKdWhjaTM6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweDMw ODAKdWhjaTM6IFtNUFNBRkVdCnVoY2kzOiBbSVRIUkVBRF0KdWhjaTM6IExlZ1N1cCA9IDB4MGYx MAp1c2J1czQ6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMwp1 aGNpNDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHgzMDYwLTB4 MzA3ZiBpcnEgMTYgYXQgZGV2aWNlIDI5LjIgb24gcGNpMAp1aGNpNDogUmVzZXJ2ZWQgMHgyMCBi eXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4MzA2MAp1aGNpNDogW01QU0FGRV0KdWhjaTQ6 IFtJVEhSRUFEXQp1aGNpNDogTGVnU3VwID0gMHgwZjAwCnVzYnVzNTogPEludGVsIDgyODAxSSAo SUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2k0CnVoY2k1OiA8SW50ZWwgODI4MDFJIChJQ0g5 KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDMwNDAtMHgzMDVmIGlycSAxOCBhdCBkZXZpY2UgMjku MyBvbiBwY2kwCnVoY2k1OiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQg YXQgMHgzMDQwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE4IChQQ0kgSVJRIDE4KSB0byBsYXBp YyAwIHZlY3RvciA1NAp1aGNpNTogW01QU0FGRV0KdWhjaTU6IFtJVEhSRUFEXQp1aGNpNTogTGVn U3VwID0gMHgwZjAwCnVzYnVzNjogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+ IG9uIHVoY2k1CmVoY2kxOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgMi4wIGNvbnRyb2xsZXI+ IG1lbSAweGU0NTA1ODAwLTB4ZTQ1MDViZmYgaXJxIDIzIGF0IGRldmljZSAyOS43IG9uIHBjaTAK ZWhjaTE6IFJlc2VydmVkIDB4NDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhlNDUw NTgwMAplaGNpMTogW01QU0FGRV0KZWhjaTE6IFtJVEhSRUFEXQp1c2J1czc6IHdhaXRpbmcgZm9y IEJJT1MgdG8gZ2l2ZSB1cCBjb250cm9sCnVzYnVzNzogRUhDSSB2ZXJzaW9uIDEuMAp1c2J1czc6 IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTEKcGNpYjM6 IDxQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMApwY2liMzogICBkb21haW4g ICAgICAgICAgICAwCnBjaWIzOiAgIHNlY29uZGFyeSBidXMgICAgIDMKcGNpYjM6ICAgc3Vib3Jk aW5hdGUgYnVzICAgMwpwY2liMzogICBJL08gZGVjb2RlICAgICAgICAweGYwMDAtMHhmZmYKcGNp YjM6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUKcGNpYjM6ICAgU3VidHJhY3RpdmVseSBkZWNvZGVk IGJyaWRnZS4KcGNpMzogPFBDSSBidXM+IG9uIHBjaWIzCnBjaTM6IGRvbWFpbj0wLCBwaHlzaWNh bCBidXM9Mwppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlz YTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphdGFwY2kwOiA8SW50ZWwgKElEPTI5Mjk4MDg2KSBBSENJ IGNvbnRyb2xsZXI+IHBvcnQgMHgzMTA4LTB4MzEwZiwweDMxMWMtMHgzMTFmLDB4MzEwMC0weDMx MDcsMHgzMTE4LTB4MzExYiwweDMwMjAtMHgzMDNmIG1lbSAweGU0NTA1MDAwLTB4ZTQ1MDU3ZmYg aXJxIDE5IGF0IGRldmljZSAzMS4yIG9uIHBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgyMCBieXRl cyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4MzAyMAphdGFwY2kwOiBSZXNlcnZlZCAweDgwMCBi eXRlcyBmb3IgcmlkIDB4MjQgdHlwZSAzIGF0IDB4ZTQ1MDUwMDAKYXRhcGNpMDogW01QU0FGRV0K YXRhcGNpMDogW0lUSFJFQURdCmF0YXBjaTA6IEFIQ0kgdjEuMjAgY29udHJvbGxlciB3aXRoIDQg M0dicHMgcG9ydHMsIFBNIHN1cHBvcnRlZAphdGFwY2kwOiBDYXBzOiA2NGJpdCBOQ1EgU05URiBN UFMgU1MgQUxQIEFMIENMTyAzR2JwcyBQTSBQTUQgU1NDIFBTQyAzMmNtZCBDQ0MgRU0gNHBvcnRz CmF0YTI6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0YTI6IEFIQ0kgcmVzZXQuLi4KYXRh MjogaGFyZHdhcmUgcmVzZXQgLi4uCmF0YTI6IFNBVEEgY29ubmVjdCB0aW1lb3V0IHN0YXR1cz0w MDAwMDAwNAphdGEyOiBBSENJIHJlc2V0IGRvbmU6IHBoeSByZXNldCBmb3VuZCBubyBkZXZpY2UK YXRhMjogW01QU0FGRV0KYXRhMjogW0lUSFJFQURdCmF0YTM6IDxBVEEgY2hhbm5lbCAxPiBvbiBh dGFwY2kwCmF0YTM6IEFIQ0kgcmVzZXQuLi4KYXRhMzogaGFyZHdhcmUgcmVzZXQgLi4uCmF0YTM6 IFNBVEEgY29ubmVjdCB0aW1lPTBtcyBzdGF0dXM9MDAwMDAxMjMKYXRhMzogcmVhZHkgd2FpdCB0 aW1lPTc4bXMKYXRhMzogc29mdHdhcmUgcmVzZXQgcG9ydCAxNS4uLgphdGEzOiByZWFkeSB3YWl0 IHRpbWU9MG1zCmF0YTM6IFNJR05BVFVSRTogMDAwMDAxMDEKYXRhMzogQUhDSSByZXNldCBkb25l OiBkZXZpY2VzPTAwMDAwMDAxCmF0YTM6IFtNUFNBRkVdCmF0YTM6IFtJVEhSRUFEXQphdGE0OiA8 QVRBIGNoYW5uZWwgND4gb24gYXRhcGNpMAphdGE0OiBBSENJIHJlc2V0Li4uCmF0YTQ6IGhhcmR3 YXJlIHJlc2V0IC4uLgphdGE0OiBTQVRBIGNvbm5lY3QgdGltZW91dCBzdGF0dXM9MDAwMDAwMDQK YXRhNDogQUhDSSByZXNldCBkb25lOiBwaHkgcmVzZXQgZm91bmQgbm8gZGV2aWNlCmF0YTQ6IFtN UFNBRkVdCmF0YTQ6IFtJVEhSRUFEXQphdGE1OiA8QVRBIGNoYW5uZWwgNT4gb24gYXRhcGNpMAph dGE1OiBBSENJIHJlc2V0Li4uCmF0YTU6IGhhcmR3YXJlIHJlc2V0IC4uLgphdGE1OiBTQVRBIGNv bm5lY3QgdGltZW91dCBzdGF0dXM9MDAwMDAwMDQKYXRhNTogQUhDSSByZXNldCBkb25lOiBwaHkg cmVzZXQgZm91bmQgbm8gZGV2aWNlCmF0YTU6IFtNUFNBRkVdCmF0YTU6IFtJVEhSRUFEXQpwY2kw OiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAzMS4zIChubyBkcml2ZXIgYXR0YWNoZWQp CnBjaTA6IDxkYXNwPiBhdCBkZXZpY2UgMzEuNiAobm8gZHJpdmVyIGF0dGFjaGVkKQphY3BpX3R6 MDogPFRoZXJtYWwgWm9uZT4gb24gYWNwaTAKYXRydGMwOiA8QVQgcmVhbHRpbWUgY2xvY2s+IHBv cnQgMHg3MC0weDc3IG9uIGFjcGkwCmF0cnRjMDogV2FybmluZzogQ291bGRuJ3QgbWFwIEkvTy4K YXRydGMwOiByZWdpc3RlcmVkIGFzIGEgdGltZS1vZi1kYXkgY2xvY2sgKHJlc29sdXRpb24gMTAw MDAwMHVzKQphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjAs MHg2NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRj MAphdGtiZDogdGhlIGN1cnJlbnQga2JkIGNvbnRyb2xsZXIgY29tbWFuZCBieXRlIDAwNjcKYXRr YmQ6IGtleWJvYXJkIElEIDB4NDFhYiAoMikKQ2FsbGluZyBpbnQgMHgxNSAoYXg9MHhjMDAwIGJ4 PTB4MDAwMCBjeD0weDAwMDAgZHg9MHgwMDAwIGVzPTB4MDAwMCBkaT0weDAwMDApCkV4aXRpbmcg aW50IDB4MTUgKGF4PTB4MDAwMCBieD0weGU4MjAgY3g9MHgwMDAwIGR4PTB4MDAwMCBlcz0weGYw MDAgZGk9MHgwMDAwKQprYmQwIGF0IGF0a2JkMAprYmQwOiBhdGtiZDAsIEFUIDEwMS8xMDIgKDIp LCBjb25maWc6MHgwLCBmbGFnczoweDNkMDAwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxIChJ U0EgSVJRIDEpIHRvIGxhcGljIDAgdmVjdG9yIDU1CmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KYXRr YmQwOiBbSVRIUkVBRF0KcHNtMDogdW5hYmxlIHRvIGFsbG9jYXRlIElSUQpwc21jcG5wMDogPFBT LzIgbW91c2UgcG9ydD4gaXJxIDEyIG9uIGFjcGkwCnBzbTA6IGN1cnJlbnQgY29tbWFuZCBieXRl OjAwNjcKcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwCmlvYXBpYzA6IHJvdXRp bmcgaW50cGluIDEyIChJU0EgSVJRIDEyKSB0byBsYXBpYyAwIHZlY3RvciA1Ngpwc20wOiBbR0lB TlQtTE9DS0VEXQpwc20wOiBbSVRIUkVBRF0KcHNtMDogbW9kZWwgR2VuZXJpYyBQUy8yIG1vdXNl LCBkZXZpY2UgSUQgMC0wMCwgMiBidXR0b25zCnBzbTA6IGNvbmZpZzowMDAwMDAwMCwgZmxhZ3M6 MDAwMDAwMDgsIHBhY2tldCBzaXplOjMKcHNtMDogc3luY21hc2s6YzAsIHN5bmNiaXRzOjAwCmJh dHRlcnkwOiA8QUNQSSBDb250cm9sIE1ldGhvZCBCYXR0ZXJ5PiBvbiBhY3BpMAphY3BpX2FjYWQw OiA8QUMgQWRhcHRlcj4gb24gYWNwaTAKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApBQ1BJOiBT U0RUIDB4YjllNmVjOTggMDAyMjMgKHYxICBQbVJlZiAgQ3B1MElzdCAwMDAwMzAwMCBJTlRMIDIw MDUxMTE3KQpBQ1BJOiBTU0RUIDB4YjllNmM1OTggMDA1MzcgKHYxICBQbVJlZiAgQ3B1MENzdCAw MDAwMzAwMSBJTlRMIDIwMDUxMTE3KQplc3QwOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5j eSBDb250cm9sPiBvbiBjcHUwCmVzdDA6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDIwNzYs IDE4MTEpCmVzdDA6IEludmFsaWQgZnJlcSAxNDAxLCBpZ25vcmVkLgplc3QwOiBJbnZhbGlkIGlk MTYgKHNldCwgY3VyKSA9ICgxNTUxLCAxODExKQplc3QwOiBJbnZhbGlkIGZyZXEgMTIwMCwgaWdu b3JlZC4KcDR0Y2MwOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTAKY3B1 MTogPEFDUEkgQ1BVPiBvbiBhY3BpMApBQ1BJOiBTU0RUIDB4YjllNmRlMTggMDAxQ0YgKHYxICBQ bVJlZiAgICBBcElzdCAwMDAwMzAwMCBJTlRMIDIwMDUxMTE3KQpBQ1BJOiBTU0RUIDB4YjllNmVm MTggMDAwOEQgKHYxICBQbVJlZiAgICBBcENzdCAwMDAwMzAwMCBJTlRMIDIwMDUxMTE3KQplc3Qx OiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUxCmVzdDE6IElu dmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDIwNzYsIDE4MTEpCmVzdDE6IEludmFsaWQgZnJlcSAx NDAxLCBpZ25vcmVkLgplc3QxOiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxNTUxLCAxODEx KQplc3QxOiBJbnZhbGlkIGZyZXEgMTIwMCwgaWdub3JlZC4KcDR0Y2MxOiA8Q1BVIEZyZXF1ZW5j eSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTEKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0 IGF0IDIwMwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMjQzCnBucF9pZGVudGlm eTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyODMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0 IGF0IDJjMwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzAzCnBucF9pZGVudGlm eTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzNDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0 IGF0IDM4MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgM2MzClBOUCBJZGVudGlm eSBjb21wbGV0ZQpleF9pc2FfaWRlbnRpZnkoKQp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFp bGVkIGZmCnVua25vd246IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKdW5rbm93bjogc3RhdHVz IHJlZyB0ZXN0IGZhaWxlZCBmZgp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCnVu a25vd246IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0 IGZhaWxlZCBmZgppc2FfcHJvYmVfY2hpbGRyZW46IGRpc2FibGluZyBQblAgZGV2aWNlcwpwbXRp bWVyMCBvbiBpc2EwCmF0a2JkYzogYXRrYmRjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQK YXRydGM6IGF0cnRjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKc2M6IHNjMCBhbHJlYWR5 IGV4aXN0czsgc2tpcHBpbmcgaXQKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIG5vbi1QblAg ZGV2aWNlcwpvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMwMDAwLTB4Y2ZmZmYs MHhkMDAwMC0weGQwZmZmIHBucGlkIE9STTAwMDAgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29s ZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywg ZmxhZ3M9MHgzMDA+CnNjMDogZmIwLCBrYmQxLCB0ZXJtaW5hbCBlbXVsYXRvcjogc2N0ZWtlbiAo dGVrZW4gdGVybWluYWwpCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgz ZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKYXRhMCBhdCBwb3J0IDB4MWYwLTB4MWY3 LDB4M2Y2IGlycSAxNCBvbiBpc2EwCmF0YTA6IHJlc2V0IHRwMSBtYXNrPTAwIG9zdGF0MD1mZiBv c3RhdDE9ZmYKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTQgKElTQSBJUlEgMTQpIHRvIGxhcGlj IDAgdmVjdG9yIDU3CmF0YTA6IFtNUFNBRkVdCmF0YTA6IFtJVEhSRUFEXQphdGExIGF0IHBvcnQg MHgxNzAtMHgxNzcsMHgzNzYgaXJxIDE1IG9uIGlzYTAKYXRhMTogcmVzZXQgdHAxIG1hc2s9MDAg b3N0YXQwPWZmIG9zdGF0MT1mZgppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxNSAoSVNBIElSUSAx NSkgdG8gbGFwaWMgMCB2ZWN0b3IgNTgKYXRhMTogW01QU0FGRV0KYXRhMTogW0lUSFJFQURdCmZk YzAgZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIg b24gaXNhMApwcGMwOiBwYXJhbGxlbCBwb3J0IG5vdCBmb3VuZC4KcHBjMDogPFBhcmFsbGVsIHBv cnQ+IGZhaWxlZCB0byBwcm9iZSBhdCBpcnEgNyBvbiBpc2EwCnVhcnQwOiA8bnM4MjUwPiBmYWls ZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNmOC0weDNmZiBpcnEgNCBvbiBpc2EwCnVhcnQxOiA8bnM4 MjUwPiBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDJmOC0weDJmZiBpcnEgMyBvbiBpc2EwCmlz YV9wcm9iZV9jaGlsZHJlbjogcHJvYmluZyBQblAgZGV2aWNlcwpEZXZpY2UgY29uZmlndXJhdGlv biBmaW5pc2hlZC4KUmVkdWNpbmcga2Vybi5tYXh2bm9kZXMgMTkyMTQ1IC0+IDEwMDAwMApwcm9j ZnMgcmVnaXN0ZXJlZApsYXBpYzogRGl2aXNvciAyLCBGcmVxdWVuY3kgMTAwMTYxMjQwIGh6ClRp bWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSAxNDAyMjU3MzE4IEh6IHF1YWxpdHkgLTEwMApUaW1l Y291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjCmxvMDogYnBmIGF0dGFjaGVkCmhwdHJyOiBu byBjb250cm9sbGVyIGRldGVjdGVkLgphdGEwOiBJZGVudGlmeWluZyBkZXZpY2VzOiAwMDAwMDAw MAphdGEwOiBOZXcgZGV2aWNlczogMDAwMDAwMDAKYXRhMTogSWRlbnRpZnlpbmcgZGV2aWNlczog MDAwMDAwMDAKYXRhMTogTmV3IGRldmljZXM6IDAwMDAwMDAwCmF0YTI6IElkZW50aWZ5aW5nIGRl dmljZXM6IDAwMDAwMDAwCmF0YTI6IE5ldyBkZXZpY2VzOiAwMDAwMDAwMAphdGEzOiBJZGVudGlm eWluZyBkZXZpY2VzOiAwMDAwMDAwMQphdGEzOiBOZXcgZGV2aWNlczogMDAwMDAwMDEKdXNidXMw OiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czE6IDEyTWJwcyBGdWxsIFNwZWVkIFVT QiB2MS4wCnVzYnVzMjogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVzYnVzMzogMTJNYnBz IEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXM0OiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1 c2J1czU6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzNjogMTJNYnBzIEZ1bGwgU3Bl ZWQgVVNCIHYxLjAKdXNidXM3OiA0ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjAKYmF0dGVyeTA6 IGJhdHRlcnkgaW5pdGlhbGl6YXRpb24gc3RhcnQKYWNwaV9hY2FkMDogYWNsaW5lIGluaXRpYWxp emF0aW9uIHN0YXJ0CmF0YTMtbWFzdGVyOiBwaW89UElPNCB3ZG1hPVdETUEyIHVkbWE9VURNQTEz MyBjYWJsZT00MCB3aXJlCmFkNjogMjM4NDc1TUIgPEhpdGFjaGkgSFRTNTQ1MDI1QjlBMzAwIFBC Mk9DNjBGPiBhdCBhdGEzLW1hc3RlciBTQVRBMzAwCmFkNjogNDg4Mzk3MTY4IHNlY3RvcnMgWzQ4 NDUyMUMvMTZILzYzU10gMTYgc2VjdG9ycy9pbnRlcnJ1cHQgMSBkZXB0aCBxdWV1ZQpHRU9NOiBu ZXcgZGlzayBhZDYKdWdlbjAuMTogPEludGVsPiBhdCB1c2J1czAKdWh1YjA6IDxJbnRlbCBVSENJ IHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMwCnVn ZW4xLjE6IDxJbnRlbD4gYXQgdXNidXMxCnVodWIxOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xh c3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMQp1Z2VuMi4xOiA8SW50ZWw+ IGF0IHVzYnVzMgp1aHViMjogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIu MDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czIKdWdlbjMuMTogPEludGVsPiBhdCB1c2J1czMKdWh1 YjM6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIg MT4gb24gdXNidXMzCnVnZW40LjE6IDxJbnRlbD4gYXQgdXNidXM0CnVodWI0OiA8SW50ZWwgVUhD SSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNAp1 Z2VuNS4xOiA8SW50ZWw+IGF0IHVzYnVzNQp1aHViNTogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNs YXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czUKdWdlbjYuMTogPEludGVs PiBhdCB1c2J1czYKdWh1YjY6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAx LjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM2CnVnZW43LjE6IDxJbnRlbD4gYXQgdXNidXM3CnVo dWI3OiA8SW50ZWwgRUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRy IDE+IG9uIHVzYnVzNwpBQ1BJIFdhcm5pbmcgZm9yIFxcX1NCXy5QQ0kwLkxQQ18uRUMwXy5CQVQw Ll9CSUY6IENvbnZlcnRlZCBCdWZmZXIgdG8gZXhwZWN0ZWQgU3RyaW5nIGF0IGluZGV4IDkgKDIw MDkwOTAzL25zcmVwYWlyLTIxNSkKQUNQSSBXYXJuaW5nIGZvciBcXF9TQl8uUENJMC5MUENfLkVD MF8uQkFUMC5fQklGOiBDb252ZXJ0ZWQgQnVmZmVyIHRvIGV4cGVjdGVkIFN0cmluZyBhdCBpbmRl eCAxMSAoMjAwOTA5MDMvbnNyZXBhaXItMjE1KQpBQ1BJIFdhcm5pbmcgZm9yIFxcX1NCXy5QQ0kw LkxQQ18uRUMwXy5CQVQwLl9CSUY6IENvbnZlcnRlZCBCdWZmZXIgdG8gZXhwZWN0ZWQgU3RyaW5n IGF0IGluZGV4IDEyICgyMDA5MDkwMy9uc3JlcGFpci0yMTUpCmJhdHRlcnkwOiBiYXR0ZXJ5IGlu aXRpYWxpemF0aW9uIGRvbmUsIHRyaWVkIDEgdGltZXMKYWNwaV9hY2FkMDogT24gTGluZQphY3Bp X2FjYWQwOiBhY2xpbmUgaW5pdGlhbGl6YXRpb24gZG9uZSwgdHJpZWQgMSB0aW1lcwphZDY6IElu dGVsIGNoZWNrMSBmYWlsZWQKYWQ2OiBBZGFwdGVjIGNoZWNrMSBmYWlsZWQKYWQ2OiBMU0kgKHYz KSBjaGVjazEgZmFpbGVkR0VPTTogYWQ2OiBwYXJ0aXRpb24gMyBkb2VzIG5vdCBzdGFydCBvbiBh IHRyYWNrIGJvdW5kYXJ5LgpHRU9NOiBhZDY6IHBhcnRpdGlvbiAzIGRvZXMgbm90IGVuZCBvbiBh IHRyYWNrIGJvdW5kYXJ5LgpHRU9NOiBhZDY6IHBhcnRpdGlvbiAyIGRvZXMgbm90IHN0YXJ0IG9u IGEgdHJhY2sgYm91bmRhcnkuCkdFT006IGFkNjogcGFydGl0aW9uIDIgZG9lcyBub3QgZW5kIG9u IGEgdHJhY2sgYm91bmRhcnkuCkdFT006IGFkNjogcGFydGl0aW9uIDEgZG9lcyBub3Qgc3RhcnQg b24gYSB0cmFjayBib3VuZGFyeS4KR0VPTTogYWQ2OiBwYXJ0aXRpb24gMSBkb2VzIG5vdCBlbmQg b24gYSB0cmFjayBib3VuZGFyeS4KCmFkNjogTFNJICh2MikgY2hlY2sxIGZhaWxlZAphZDY6IEZy ZWVCU0QgY2hlY2sxIGZhaWxlZAphdGE0OiBJZGVudGlmeWluZyBkZXZpY2VzOiAwMDAwMDAwMAph dGE0OiBOZXcgZGV2aWNlczogMDAwMDAwMDAKYXRhNTogSWRlbnRpZnlpbmcgZGV2aWNlczogMDAw MDAwMDAKYXRhNTogTmV3IGRldmljZXM6IDAwMDAwMDAwCkFUQSBQc2V1ZG9SQUlEIGxvYWRlZApT TVA6IEFQIENQVSAjMSBMYXVuY2hlZCEKY3B1MSBBUDoKICAgICBJRDogMHgwMTAwMDAwMCAgIFZF UjogMHgwMDA1MDAxNCBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmCiAgbGludDA6IDB4 MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNWUjogMHgwMDAwMDFm ZgogIHRpbWVyOiAweDAwMDIwMGVmIHRoZXJtOiAweDAwMDEwMjAwIGVycjogMHgwMDAxMDAwMCBw Y206IDB4MDAwMTA0MDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gOSAoSVNBIElSUSA5KSB0byBs YXBpYyAxIHZlY3RvciA0OAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxNCAoSVNBIElSUSAxNCkg dG8gbGFwaWMgMSB2ZWN0b3IgNDkKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTYgKFBDSSBJUlEg MTYpIHRvIGxhcGljIDEgdmVjdG9yIDUwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE5IChQQ0kg SVJRIDE5KSB0byBsYXBpYyAxIHZlY3RvciA1MQppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMyAo UENJIElSUSAyMykgdG8gbGFwaWMgMSB2ZWN0b3IgNTIKV0FSTklORzogV0lUTkVTUyBvcHRpb24g ZW5hYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2UuCnVodWIwOiAyIHBvcnRzIHdpdGgg MiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxl LCBzZWxmIHBvd2VyZWQKdWh1YjM6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dl cmVkCnVodWI0OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViNTog MiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjY6IDIgcG9ydHMgd2l0 aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVz NyB1c2J1czIKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM3IHVzYnVzMgp1aHViMjogNCBw b3J0cyB3aXRoIDQgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5nIGZv cjogdXNidXM3IHVzYnVzMgp1Z2VuMi4yOiA8U3VZaW4+IGF0IHVzYnVzMgp1aHViNzogOCBwb3J0 cyB3aXRoIDggcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjog dXNidXM3CnVnZW43LjI6IDxzaWxpY29uPiBhdCB1c2J1czcKdW1hc3MwOiA8c2lsaWNvbiAtcG93 ZXIsIGNsYXNzIDAvMCwgcmV2IDIuMDAvMS4xMCwgYWRkciAyPiBvbiB1c2J1czcKdW1hc3MwOiAg U0NTSSBvdmVyIEJ1bGstT25seTsgcXVpcmtzID0gMHgwMDAwClJvb3QgbW91bnQgd2FpdGluZyBm b3I6IHVzYnVzNwp1bWFzczA6MDowOi0xOiBBdHRhY2hlZCB0byBzY2J1czAKKHByb2JlMDp1bWFz cy1zaW0wOjA6MDowKTogRG93biByZXZpbmcgUHJvdG9jb2wgVmVyc2lvbiBmcm9tIDIgdG8gMD8K R0VPTTogbmV3IGRpc2sgZGEwcGFzczAgYXQgdW1hc3Mtc2ltMCBidXMgMCBzY2J1czAgdGFyZ2V0 IDAgbHVuIDAKCnBhc3MwOiA8c2lsaWNvbiAtcG93ZXIgMC4wMD4gUmVtb3ZhYmxlIERpcmVjdCBB Y2Nlc3MgU0NTSS0wIGRldmljZSAKcGFzczA6IFNlcmlhbCBOdW1iZXIgRTY4ODE2MDAzQTEzCnBh c3MwOiA0MC4wMDBNQi9zIHRyYW5zZmVycwpkYTAgYXQgdW1hc3Mtc2ltMCBidXMgMCBzY2J1czAg dGFyZ2V0IDAgbHVuIDAKZGEwOiA8c2lsaWNvbiAtcG93ZXIgMC4wMD4gUmVtb3ZhYmxlIERpcmVj dCBBY2Nlc3MgU0NTSS0wIGRldmljZSAKZGEwOiBTZXJpYWwgTnVtYmVyIEU2ODgxNjAwM0ExMwpk YTA6IDQwLjAwME1CL3MgdHJhbnNmZXJzCmRhMDogNzY0NE1CICgxNTY1NDkxMiA1MTIgYnl0ZSBz ZWN0b3JzOiAyNTVIIDYzUy9UIDk3NEMpCnVnZW40LjI6IDxMb2dpdGVjaD4gYXQgdXNidXM0CnVt czA6IDxMb2dpdGVjaCBVU0IgUmVjZWl2ZXIsIGNsYXNzIDAvMCwgcmV2IDEuMTAvNDYuMDAsIGFk ZHIgMj4gb24gdXNidXM0CnVtczA6IDggYnV0dG9ucyBhbmQgW1hZWl0gY29vcmRpbmF0ZXMgSUQ9 MAp1aGlkMDogPExvZ2l0ZWNoIFVTQiBSZWNlaXZlciwgY2xhc3MgMC8wLCByZXYgMS4xMC80Ni4w MCwgYWRkciAyPiBvbiB1c2J1czQKVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9k YTBzMWEKY3RfdG9fdHMoWzIwMDktMTAtMDYgMjA6Mjc6MDZdKSA9IDEyNTQ4NjA4MjYuMDAwMDAw MDAwCnN0YXJ0X2luaXQ6IHRyeWluZyAvc2Jpbi9pbml0Cg== --------_4ACB35D7000000000694_MULTIPART_MIXED_ Content-Type: application/octet-stream; name="vostro1000.log" Content-Disposition: attachment; filename="vostro1000.log" Content-Transfer-Encoding: base64 Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA5LjAtQ1VSUkVOVCAjMDogVHVlIE9jdCAgNiAwNzox MzoyNiBKU1QgMjAwOQogICAga2FybEBiZWVmLmppbmJvLmpwOi91c3Ivb2JqL3Vzci9zcmMvc3lz L0dFTkVSSUMgaTM4NgpXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3QgcmVk dWNlZCBwZXJmb3JtYW5jZS4KUHJlbG9hZGVkIGVsZiBrZXJuZWwgIi9ib290L2tlcm5lbC9rZXJu ZWwiIGF0IDB4YzExMjAwMDAuClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIg SHogcXVhbGl0eSAwCkNhbGlicmF0aW5nIFRTQyBjbG9jayAuLi4gVFNDIGNsb2NrOiAxNzk1NTEw OTYzIEh6CkNQVTogQU1EIEF0aGxvbih0bSkgNjQgWDIgRHVhbC1Db3JlIFByb2Nlc3NvciBUSy01 NSAoMTc5NS41MS1NSHogNjg2LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiQXV0aGVudGljQU1EIiAg SWQgPSAweDYwZjgxICBTdGVwcGluZyA9IDEKICBGZWF0dXJlcz0weDE3OGJmYmZmPEZQVSxWTUUs REUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFU LFBTRTM2LENMRkxVU0gsTU1YLEZYU1IsU1NFLFNTRTIsSFRUPgogIEZlYXR1cmVzMj0weDIwMDE8 U1NFMyxDWDE2PgogIEFNRCBGZWF0dXJlcz0weGVhNTAwODAwPFNZU0NBTEwsTlgsTU1YKyxGRlhT UixSRFRTQ1AsTE0sM0ROb3chKywzRE5vdyE+CiAgQU1EIEZlYXR1cmVzMj0weDExZjxMQUhGLENN UCxTVk0sRXh0QVBJQyxDUjgsUHJlZmV0Y2g+CkRhdGEgVExCOiAzMiBlbnRyaWVzLCBmdWxseSBh c3NvY2lhdGl2ZQpJbnN0cnVjdGlvbiBUTEI6IDMyIGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZl CkwxIGRhdGEgY2FjaGU6IDY0IGtieXRlcywgNjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90YWcsIDIt d2F5IGFzc29jaWF0aXZlCkwxIGluc3RydWN0aW9uIGNhY2hlOiA2NCBrYnl0ZXMsIDY0IGJ5dGVz L2xpbmUsIDEgbGluZXMvdGFnLCAyLXdheSBhc3NvY2lhdGl2ZQpMMiBpbnRlcm5hbCBjYWNoZTog MjU2IGtieXRlcywgNjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90YWcsIDgtd2F5IGFzc29jaWF0aXZl CnJlYWwgbWVtb3J5ICA9IDIxNDc0ODM2NDggKDIwNDggTUIpClBoeXNpY2FsIG1lbW9yeSBjaHVu ayhzKToKMHgwMDAwMDAwMDAwMDAxMDAwIC0gMHgwMDAwMDAwMDAwMDljZmZmLCA2Mzg5NzYgYnl0 ZXMgKDE1NiBwYWdlcykKMHgwMDAwMDAwMDAwMTAwMDAwIC0gMHgwMDAwMDAwMDAwM2ZmZmZmLCAz MTQ1NzI4IGJ5dGVzICg3NjggcGFnZXMpCjB4MDAwMDAwMDAwMTQyNjAwMCAtIDB4MDAwMDAwMDA3 NWM2MmZmZiwgMTk1NDc5NTUyMCBieXRlcyAoNDc3MjQ1IHBhZ2VzKQphdmFpbCBtZW1vcnkgPSAx OTUzMzYxOTIwICgxODYyIE1CKQpUYWJsZSAnRkFDUCcgYXQgMHg3N2U3ZmI1OApUYWJsZSAnVENQ QScgYXQgMHg3N2U3ZmJjYwpUYWJsZSAnU1NEVCcgYXQgMHg3N2U3ZmJmZQpUYWJsZSAnQVBJQycg YXQgMHg3N2U3ZmRjMgpBUElDOiBGb3VuZCB0YWJsZSBhdCAweDc3ZTdmZGMyCk1QIENvbmZpZ3Vy YXRpb24gVGFibGUgdmVyc2lvbiAxLjQgZm91bmQgYXQgMHhjMDA5ZTE3MQpBUElDOiBVc2luZyB0 aGUgTUFEVCBlbnVtZXJhdG9yLgpNQURUOiBGb3VuZCBDUFUgQVBJQyBJRCAwIEFDUEkgSUQgMDog ZW5hYmxlZApTTVA6IEFkZGVkIENQVSAwIChBUCkKTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMSBB Q1BJIElEIDE6IGVuYWJsZWQKU01QOiBBZGRlZCBDUFUgMSAoQVApCkFDUEkgQVBJQyBUYWJsZTog PFBUTFREICAJIEFQSUMgID4KSU5UUjogQWRkaW5nIGxvY2FsIEFQSUMgMSBhcyBhIHRhcmdldApG cmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiAyIENQVXMKRnJlZUJT RC9TTVA6IDEgcGFja2FnZShzKSB4IDIgY29yZShzKQogY3B1MCAoQlNQKTogQVBJQyBJRDogIDAK IGNwdTEgKEFQKTogQVBJQyBJRDogIDEKYmlvczMyOiBGb3VuZCBCSU9TMzIgU2VydmljZSBEaXJl Y3RvcnkgaGVhZGVyIGF0IDB4YzAwZjg0YTAKYmlvczMyOiBFbnRyeSA9IDB4ZmRjODQgKGMwMGZk Yzg0KSAgUmV2ID0gMCAgTGVuID0gMQpwY2liaW9zOiBQQ0kgQklPUyBlbnRyeSBhdCAweGZkYzgw KzB4MApwbnBiaW9zOiBGb3VuZCBQblAgQklPUyBkYXRhIGF0IDB4YzAwZjg1NDAKcG5wYmlvczog RW50cnkgPSBlNWNiOjk0OTkgIFJldiA9IDEuMApPdGhlciBCSU9TIHNpZ25hdHVyZXMgZm91bmQ6 CkFQSUM6IENQVSAwIGhhcyBBQ1BJIElEIDAKQVBJQzogQ1BVIDEgaGFzIEFDUEkgSUQgMQpVTEU6 IHNldHVwIGNwdSAwClVMRTogc2V0dXAgY3B1IDEKQUNQSTogUlNEUCAweGY4NTAwIDAwMDE0ICh2 MCBQVExURCApCkFDUEk6IFJTRFQgMHg3N2U3OTUzOSAwMDA0MCAodjEgREVMTCAgICBNMDggICAg IDA2MDQwMDAwICBMVFAgMDAwMDAwMDApCkFDUEk6IEZBQ1AgMHg3N2U3ZmI1OCAwMDA3NCAodjEg QVRJICAgIEJvd2ZpbiAgIDA2MDQwMDAwIEFUSSAgMDAwRjQyNDApCkFDUEk6IERTRFQgMHg3N2U3 OTU3OSAwNjVERiAodjEgICAgQVRJICAgIFNCNjAwIDA2MDQwMDAwIE1TRlQgMDMwMDAwMDApCkFD UEk6IEZBQ1MgMHg3N2U5MGZjMCAwMDA0MApBQ1BJOiBUQ1BBIDB4NzdlN2ZiY2MgMDAwMzIgKHYy IEFNRCAgICAgICAgICAgICAwNjA0MDAwMCBQVEVDIDAwMDAwMDAwKQpBQ1BJOiBTU0RUIDB4Nzdl N2ZiZmUgMDAxQzQgKHYxIFBUTFREICBQT1dFUk5PVyAwNjA0MDAwMCAgTFRQIDAwMDAwMDAxKQpB Q1BJOiBBUElDIDB4NzdlN2ZkYzIgMDAwNTQgKHYxIFBUTFREICA/IEFQSUMgICAwNjA0MDAwMCAg TFRQIDAwMDAwMDAwKQpBQ1BJOiBNQ0ZHIDB4NzdlN2ZlMTYgMDAwM0MgKHYxIFBUTFREICAgIE1D RkcgICAwNjA0MDAwMCAgTFRQIDAwMDAwMDAwKQpBQ1BJOiBIUEVUIDB4NzdlN2ZlNTIgMDAwMzgg KHYxIFBUTFREICBIUEVUVEJMICAwNjA0MDAwMCAgTFRQIDAwMDAwMDAxKQpBQ1BJOiBTTElDIDB4 NzdlN2ZlOGEgMDAxNzYgKHYxIERFTEwgICAgTTA4ICAgICAwNjA0MDAwMCAgTFRQIDAwMDAwMDAw KQpNQURUOiBGb3VuZCBJTyBBUElDIElEIDIsIEludGVycnVwdCAwIGF0IDB4ZmVjMDAwMDAKaW9h cGljMDogUm91dGluZyBleHRlcm5hbCA4MjU5QSdzIC0+IGludHBpbiAwCmxhcGljMDogUm91dGlu ZyBOTUkgLT4gTElOVDEKbGFwaWMwOiBMSU5UMSB0cmlnZ2VyOiBlZGdlCmxhcGljMDogTElOVDEg cG9sYXJpdHk6IGhpZ2gKbGFwaWMxOiBSb3V0aW5nIE5NSSAtPiBMSU5UMQpsYXBpYzE6IExJTlQx IHRyaWdnZXI6IGVkZ2UKbGFwaWMxOiBMSU5UMSBwb2xhcml0eTogaGlnaApNQURUOiBGb3JjaW5n IGFjdGl2ZS1sb3cgcG9sYXJpdHkgYW5kIGxldmVsIHRyaWdnZXIgZm9yIFNDSQppb2FwaWMwOiBp bnRwaW4gOSBwb2xhcml0eTogbG93CmlvYXBpYzA6IGludHBpbiA5IHRyaWdnZXI6IGxldmVsCmlv YXBpYzAgPFZlcnNpb24gMi4xPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQKY3B1MCBCU1A6CiAg ICAgSUQ6IDB4MDAwMDAwMDAgICBWRVI6IDB4ODAwNTAwMTAgTERSOiAweDAwMDAwMDAwIERGUjog MHhmZmZmZmZmZgogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgw MDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAxMDBlZiB0aGVybTogMHgwMDAx MDAwMCBlcnI6IDB4MDAwMTAwMDAgcGNtOiAweDAwMDEwNDAwCndsYW46IDw4MDIuMTEgTGluayBM YXllcj4KcmFuZG9tOiA8ZW50cm9weSBzb3VyY2UsIFNvZnR3YXJlLCBZYXJyb3c+Cm5mc2xvY2s6 IHBzZXVkby1kZXZpY2UKa2JkOiBuZXcgYXJyYXkgc2l6ZSA0CmtiZDEgYXQga2JkbXV4MAptZW06 IDxtZW1vcnk+ClBlbnRpdW0gUHJvIE1UUlIgc3VwcG9ydCBlbmFibGVkCmlvOiA8SS9PPgpudWxs OiA8bnVsbCBkZXZpY2UsIHplcm8gZGV2aWNlPgpocHRycjogUm9ja2V0UkFJRCAxN3h4LzJ4eHgg U0FUQSBjb250cm9sbGVyIGRyaXZlciB2MS4yCm5weDA6IElOVCAxNiBpbnRlcmZhY2UKYWNwaTA6 IDxERUxMIE0wOCAgICA+IG9uIG1vdGhlcmJvYXJkClBDSWU6IE1lbW9yeSBNYXBwZWQgY29uZmln dXJhdGlvbiBiYXNlIEAgMHhlMDAwMDAwMApwY2liaW9zOiBCSU9TX1BSRVNFTlQgY2FsbCBmYWls ZWQKaW9hcGljMDogcm91dGluZyBpbnRwaW4gOSAoSVNBIElSUSA5KSB0byBsYXBpYyAwIHZlY3Rv ciA0OAphY3BpMDogW01QU0FGRV0KYWNwaTA6IFtJVEhSRUFEXQpBY3BpT3NEZXJpdmVQY2lJZDog XFxfU0JfLlBDSTAuU0FUQS5TQVRYIC0+IGJ1cyAwIGRldiAxOCBmdW5jIDAKQWNwaU9zRGVyaXZl UGNpSWQ6IFxcX1NCXy5QQ0kwLlNBVDIuU0FUWCAtPiBidXMgMCBkZXYgMTcgZnVuYyAwCmFjcGkw OiBQb3dlciBCdXR0b24gKGZpeGVkKQphY3BpMDogd2FrZXVwIGNvZGUgdmEgMHhjNTI3OTAwMCBw YSAweDEwMDAKQWNwaU9zRGVyaXZlUGNpSWQ6IFxcX1NCXy5QQ0kwLklERV8uSURFXyAtPiBidXMg MCBkZXYgMjAgZnVuYyAxCnVua25vd246IEkvTyByYW5nZSBub3Qgc3VwcG9ydGVkCkFjcGlPc0Rl cml2ZVBjaUlkOiBcXF9TQl8uUENJMC5CQVIxIC0+IGJ1cyAwIGRldiAwIGZ1bmMgMApBY3BpT3NE ZXJpdmVQY2lJZDogXFxfU0JfLlBDSTAuU01CXy5aMDBBIC0+IGJ1cyAwIGRldiAyMCBmdW5jIDAK YWNwaTA6IHJlc2VydmF0aW9uIG9mIDAsIDEwMDAgKDMpIGZhaWxlZApBQ1BJIEhQRVQgdGFibGUg d2FybmluZzogU2VxdWVuY2UgaXMgbm9uLXplcm8gKDIpCkFDUEkgdGltZXI6IDEvMSAxLzEgMS8x IDEvMSAxLzEgMS8xIDEvMSAxLzEgMS8xIDEvMSAtPiAxMApUaW1lY291bnRlciAiQUNQSS1mYXN0 IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDEwMDAKYWNwaV90aW1lcjA6IDwzMi1iaXQg dGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHg4MDA4LTB4ODAwYiBvbiBhY3BpMAphY3BpX2Vj MDogPEVtYmVkZGVkIENvbnRyb2xsZXI6IEdQRSAweDE0PiBwb3J0IDB4NjIsMHg2NiBvbiBhY3Bp MApwY2lfbGluazA6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwg UHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTAgMTEKICBWYWxpZGF0aW9uICAgICAgICAg IDAgIDI1NSAgIE4gICAgIDAgIDEwIDExCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBO ICAgICAwICAxMCAxMQpwY2lfbGluazE6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJR cwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTAgMTEKICBWYWxpZGF0 aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDEwIDExCiAgQWZ0ZXIgRGlzYWJsZSAgICAg ICAwICAyNTUgICBOICAgICAwICAxMCAxMQpwY2lfbGluazI6ICAgICAgICBJbmRleCAgSVJRICBS dGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTAg MTEKICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDEwIDExCiAgQWZ0ZXIg RGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAxMCAxMQpwY2lfbGluazM6ICAgICAgICBJ bmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAg TiAgICAgMCAgMTAgMTEKICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDEw IDExCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAxMCAxMQpwY2lfbGlu azQ6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAg ICAgMCAgMjU1ICAgTiAgICAgMCAgMTAgMTEKICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDEwIDExCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAx MCAxMQpwY2lfbGluazU6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRp YWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTAgMTEKICBWYWxpZGF0aW9uICAgICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDEwIDExCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUg ICBOICAgICAwICAxMCAxMQpwY2lfbGluazY6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAg SVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTAgMTEKICBWYWxp ZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDEwIDExCiAgQWZ0ZXIgRGlzYWJsZSAg ICAgICAwICAyNTUgICBOICAgICAwICAxMCAxMQpwY2lfbGluazc6ICAgICAgICBJbmRleCAgSVJR ICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAg MTAgMTEKICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDEwIDExCiAgQWZ0 ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAxMCAxMQpwY2lfbGluazg6ICAgICAg ICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1 ICAgTiAgICAgMCAgMyA0IDUgNwogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAg MCAgMyA0IDUgNwogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUg NwphY3BpX2hwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAw MDAtMHhmZWQwMDNmZiBvbiBhY3BpMAphY3BpX2hwZXQwOiB2ZW5kOiAweDQzNTMgcmV2OiAweDEg bnVtOiAzIGh6OiAxNDMxODE4MCBvcHRzOiBsZWdhY3lfcm91dGUKVGltZWNvdW50ZXIgIkhQRVQi IGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDkwMAphY3BpX2J1dHRvbjA6IDxQb3dlciBC dXR0b24+IG9uIGFjcGkwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgt MHhjZmYgb24gYWNwaTAKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKcGNpMDogZG9tYWlu PTAsIHBoeXNpY2FsIGJ1cz0wCmZvdW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2PTB4NTk1MCwgcmV2 aWQ9MHgxMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDYtMDAtMDAs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNiwgc3RhdHJlZz0weDMyMjAsIGNh Y2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMDAyLCBkZXY9MHg1 YTNmLCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MSwgZnVuYz0wCgljbGFzcz0w Ni0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4 MDIzMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5n bnQ9MHgwYyAoMzAwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDEw MDIsIGRldj0weDVhMzcsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD01LCBmdW5j PTAKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDAs IHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDA0ICgxMDAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglwb3dlcnNwZWMg MyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UKZm91 bmQtPgl2ZW5kb3I9MHgxMDAyLCBkZXY9MHg1YTM4LCByZXZpZD0weDAwCglkb21haW49MCwgYnVz PTAsIHNsb3Q9NiwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0w CgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTggKGR3b3JkcykKCWxh dHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwNCAoMTAwMCBucyksIG1heGxhdD0weDAwICgw IG5zKQoJcG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9y dHMgMSBtZXNzYWdlCmZvdW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2PTB4NDM4MCwgcmV2aWQ9MHgw MAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTE4LCBmdW5jPTAKCWNsYXNzPTAxLTAxLThmLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwYTMwLCBjYWNoZWxu c3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDAwICgwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMgMiAgc3Vw cG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMy LCBiYXNlIDB4ODQzOCwgc2l6ZSAgMywgZW5hYmxlZAoJbWFwWzE0XTogdHlwZSBJL08gUG9ydCwg cmFuZ2UgMzIsIGJhc2UgMHg4NDU0LCBzaXplICAyLCBlbmFibGVkCgltYXBbMThdOiB0eXBlIEkv TyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDg0MzAsIHNpemUgIDMsIGVuYWJsZWQKCW1hcFsxY106 IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ODQ1MCwgc2l6ZSAgMiwgZW5hYmxlZAoJ bWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg4NDAwLCBzaXplICA0LCBl bmFibGVkCgltYXBbMjRdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhjMDAwNDAwMCwg c2l6ZSAxMCwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4xOC5JTlRBCnBjaWIw OiBzbG90IDE4IElOVEEgaGFyZHdpcmVkIHRvIElSUSAyMgpmb3VuZC0+CXZlbmRvcj0weDEwMDIs IGRldj0weDQzODcsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xOSwgZnVuYz0w CgljbGFzcz0wYy0wMy0xMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDE3LCBz dGF0cmVnPTB4MDJhMCwgY2FjaGVsbnN6PTggKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAg bnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGly cT0xMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4YzAwMDUwMDAsIHNp emUgMTIsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMTkuSU5UQQpwY2liMDog c2xvdCAxOSBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTYKZm91bmQtPgl2ZW5kb3I9MHgxMDAyLCBk ZXY9MHg0Mzg4LCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MTksIGZ1bmM9MQoJ Y2xhc3M9MGMtMDMtMTAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAxNywgc3Rh dHJlZz0weDAyYTAsIGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIwIG5z KSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9 MTEKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGMwMDA2MDAwLCBzaXpl IDEyLCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjE5LklOVEIKcGNpYjA6IHNs b3QgMTkgSU5UQiBoYXJkd2lyZWQgdG8gSVJRIDE3CmZvdW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2 PTB4NDM4OSwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTE5LCBmdW5jPTIKCWNs YXNzPTBjLTAzLTEwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMTcsIHN0YXRy ZWc9MHgwMmEwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyks IG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YywgaXJxPTEx CgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhjMDAwNzAwMCwgc2l6ZSAx MiwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4xOS5JTlRDCnBjaWIwOiBzbG90 IDE5IElOVEMgaGFyZHdpcmVkIHRvIElSUSAxOApmb3VuZC0+CXZlbmRvcj0weDEwMDIsIGRldj0w eDQzOGEsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xOSwgZnVuYz0zCgljbGFz cz0wYy0wMy0xMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDE3LCBzdGF0cmVn PTB4MDJhMCwgY2FjaGVsbnN6PTggKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBt aW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWIsIGlycT0xMQoJ bWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4YzAwMDgwMDAsIHNpemUgMTIs IGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMTkuSU5UQgpwY2liMDogc2xvdCAx OSBJTlRCIGhhcmR3aXJlZCB0byBJUlEgMTcKZm91bmQtPgl2ZW5kb3I9MHgxMDAyLCBkZXY9MHg0 MzhiLCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MTksIGZ1bmM9NAoJY2xhc3M9 MGMtMDMtMTAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAxNywgc3RhdHJlZz0w eDAyYTAsIGNhY2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWlu Z250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1jLCBpcnE9MTEKCW1h cFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGMwMDA5MDAwLCBzaXplIDEyLCBl bmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjE5LklOVEMKcGNpYjA6IHNsb3QgMTkg SU5UQyBoYXJkd2lyZWQgdG8gSVJRIDE4CmZvdW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2PTB4NDM4 NiwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTE5LCBmdW5jPTUKCWNsYXNzPTBj LTAzLTIwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMTcsIHN0YXRyZWc9MHgw MmIwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdu dD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49ZCwgaXJxPTExCglwb3dl cnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUg TWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGMwMDA0NDAwLCBzaXplICA4LCBlbmFibGVkCnBjaWIw OiBtYXRjaGVkIGVudHJ5IGZvciAwLjE5LklOVEQKcGNpYjA6IHNsb3QgMTkgSU5URCBoYXJkd2ly ZWQgdG8gSVJRIDE5CmZvdW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2PTB4NDM4NSwgcmV2aWQ9MHgx NAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIwLCBmdW5jPTAKCWNsYXNzPTBjLTA1LTAwLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDMsIHN0YXRyZWc9MHgwMjMwLCBjYWNoZWxu c3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwg bWF4bGF0PTB4MDAgKDAgbnMpCgltYXBbMTBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFz ZSAweDg0MTAsIHNpemUgIDQsIGVuYWJsZWQKCW1hcFsxNF06IHR5cGUgTWVtb3J5LCByYW5nZSAz MiwgYmFzZSAweGZlZDAwMDAwLCBzaXplIDEwLCBlbmFibGVkCmZvdW5kLT4JdmVuZG9yPTB4MTAw MiwgZGV2PTB4NDM4YywgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIwLCBmdW5j PTEKCWNsYXNzPTAxLTAxLThhLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMTUs IHN0YXRyZWc9MHgwMjIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJx PTI1NQoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg4NDIwLCBzaXpl ICA0LCBlbmFibGVkCmZvdW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2PTB4NDM4MywgcmV2aWQ9MHgw MAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIwLCBmdW5jPTIKCWNsYXNzPTA0LTAzLTAwLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgwNDEwLCBjYWNoZWxu c3o9OCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDAwICgwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMiAgc3Vw cG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwg YmFzZSAweGMwMDAwMDAwLCBzaXplIDE0LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZv ciAwLjIwLklOVEEKcGNpYjA6IHNsb3QgMjAgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CmZvdW5k LT4JdmVuZG9yPTB4MTAwMiwgZGV2PTB4NDM4ZCwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0w LCBzbG90PTIwLCBmdW5jPTMKCWNsYXNzPTA2LTAxLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEK CWNtZHJlZz0weDAwMGYsIHN0YXRyZWc9MHgwMjIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0 dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMp CmZvdW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2PTB4NDM4NCwgcmV2aWQ9MHgwMAoJZG9tYWluPTAs IGJ1cz0wLCBzbG90PTIwLCBmdW5jPTQKCWNsYXNzPTA2LTA0LTAxLCBoZHJ0eXBlPTB4MDEsIG1m ZGV2PTEKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMmEwLCBjYWNoZWxuc3o9MCAoZHdvcmRz KQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDA2ICgxNTAwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4MTEwMCwgcmV2aWQ9MHgw MAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI0LCBmdW5jPTAKCWNsYXNzPTA2LTAwLTAwLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxu c3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwg bWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4MTEwMSwgcmV2 aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI0LCBmdW5jPTEKCWNsYXNzPTA2LTAwLTAw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMDAwLCBj YWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4MTEw MiwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI0LCBmdW5jPTIKCWNsYXNzPTA2 LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgw MDAwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0w eDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2 PTB4MTEwMywgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI0LCBmdW5jPTMKCWNs YXNzPTA2LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDAsIHN0YXRy ZWc9MHgwMDEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1p bmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCnBjaWIxOiA8QUNQSSBQQ0ktUENJ IGJyaWRnZT4gYXQgZGV2aWNlIDEuMCBvbiBwY2kwCnBjaWIxOiAgIGRvbWFpbiAgICAgICAgICAg IDAKcGNpYjE6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMQpwY2liMTogICBzdWJvcmRpbmF0ZSBidXMg ICAxCnBjaWIxOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4OTAwMC0weDlmZmYKcGNpYjE6ICAgbWVt b3J5IGRlY29kZSAgICAgMHhjMDEwMDAwMC0weGMwMWZmZmZmCnBjaWIxOiAgIHByZWZldGNoZWQg ZGVjb2RlIDB4YzgwMDAwMDAtMHhjZmZmZmZmZgpwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li MQpwY2kxOiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTEKZm91bmQtPgl2ZW5kb3I9MHgxMDAyLCBk ZXY9MHg1OTc1LCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTEsIHNsb3Q9NSwgZnVuYz0wCglj bGFzcz0wMy0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0 cmVnPTB4MDJiMCwgY2FjaGVsbnN6PTggKGR3b3JkcykKCWxhdHRpbWVyPTB4NDIgKDE5ODAgbnMp LCBtaW5nbnQ9MHgwOCAoMjAwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGly cT0xMAoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCgltYXBb MTBdOiB0eXBlIFByZWZldGNoYWJsZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4YzgwMDAwMDAs IHNpemUgMjcsIGVuYWJsZWQKcGNpYjE6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhjODAwMDAw MC0weGNmZmZmZmZmOiBnb29kCgltYXBbMTRdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFz ZSAweDkwMDAsIHNpemUgIDgsIGVuYWJsZWQKcGNpYjE6IHJlcXVlc3RlZCBJL08gcmFuZ2UgMHg5 MDAwLTB4OTBmZjogaW4gcmFuZ2UKCW1hcFsxOF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFz ZSAweGMwMTAwMDAwLCBzaXplIDE2LCBlbmFibGVkCnBjaWIxOiByZXF1ZXN0ZWQgbWVtb3J5IHJh bmdlIDB4YzAxMDAwMDAtMHhjMDEwZmZmZjogZ29vZApwY2liMTogbWF0Y2hlZCBlbnRyeSBmb3Ig MS41LklOVEEKcGNpYjE6IHNsb3QgNSBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTcKdmdhcGNpMDog PFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IHBvcnQgMHg5MDAwLTB4OTBmZiBtZW0gMHhjODAwMDAw MC0weGNmZmZmZmZmLDB4YzAxMDAwMDAtMHhjMDEwZmZmZiBpcnEgMTcgYXQgZGV2aWNlIDUuMCBv biBwY2kxCnBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDUuMCBvbiBwY2kw CnBjaWIyOiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjI6ICAgc2Vjb25kYXJ5IGJ1cyAgICAg MgpwY2liMjogICBzdWJvcmRpbmF0ZSBidXMgICA0CnBjaWIyOiAgIEkvTyBkZWNvZGUgICAgICAg IDB4MC0weDAKcGNpYjI6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUKcGNpMjogPEFDUEkgUENJIGJ1 cz4gb24gcGNpYjIKcGNpMjogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0yCnBjaWIzOiA8QUNQSSBQ Q0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDYuMCBvbiBwY2kwCnBjaWIzOiAgIGRvbWFpbiAgICAg ICAgICAgIDAKcGNpYjM6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgNQpwY2liMzogICBzdWJvcmRpbmF0 ZSBidXMgICA3CnBjaWIzOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4ZjAwMC0weGZmZgpwY2liMzog ICBtZW1vcnkgZGVjb2RlICAgICAweGMwMjAwMDAwLTB4YzAyZmZmZmYKcGNpYjM6ICAgbm8gcHJl ZmV0Y2hlZCBkZWNvZGUKcGNpNTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMKcGNpNTogZG9tYWlu PTAsIHBoeXNpY2FsIGJ1cz01CmZvdW5kLT4JdmVuZG9yPTB4MTRlNCwgZGV2PTB4NDMxMiwgcmV2 aWQ9MHgwMQoJZG9tYWluPTAsIGJ1cz01LCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDItODAtMDAs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwMTAsIGNh Y2hlbG5zej04IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAg bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBz dXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZQoJ bWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4YzAyMDAwMDAsIHNpemUgMTQs IGVuYWJsZWQKcGNpYjM6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhjMDIwMDAwMC0weGMwMjAz ZmZmOiBnb29kCnBjaWIzOiBtYXRjaGVkIGVudHJ5IGZvciA1LjAuSU5UQQpwY2liMzogc2xvdCAw IElOVEEgaGFyZHdpcmVkIHRvIElSUSAxOApwY2k1OiA8bmV0d29yaz4gYXQgZGV2aWNlIDAuMCAo bm8gZHJpdmVyIGF0dGFjaGVkKQphdGFwY2kwOiA8QVRJIElYUDYwMCBTQVRBMzAwIGNvbnRyb2xs ZXI+IHBvcnQgMHg4NDM4LTB4ODQzZiwweDg0NTQtMHg4NDU3LDB4ODQzMC0weDg0MzcsMHg4NDUw LTB4ODQ1MywweDg0MDAtMHg4NDBmIG1lbSAweGMwMDA0MDAwLTB4YzAwMDQzZmYgaXJxIDIyIGF0 IGRldmljZSAxOC4wIG9uIHBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3Igcmlk IDB4MjAgdHlwZSA0IGF0IDB4ODQwMAphdGFwY2kwOiBSZXNlcnZlZCAweDQwMCBieXRlcyBmb3Ig cmlkIDB4MjQgdHlwZSAzIGF0IDB4YzAwMDQwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjIg KFBDSSBJUlEgMjIpIHRvIGxhcGljIDAgdmVjdG9yIDQ5CmF0YXBjaTA6IFtNUFNBRkVdCmF0YXBj aTA6IFtJVEhSRUFEXQphdGFwY2kwOiBBSENJIHYxLjEwIGNvbnRyb2xsZXIgd2l0aCA0IDNHYnBz IHBvcnRzLCBQTSBzdXBwb3J0ZWQKYXRhcGNpMDogQ2FwczogNjRiaXQgTkNRIFNOVEYgTVBTIEFM UCBBTCBDTE8gM0dicHMgUE0gUE1EIFNTQyBQU0MgMzJjbWQgQ0NDIDRwb3J0cwphdGEyOiA8QVRB IGNoYW5uZWwgMD4gb24gYXRhcGNpMAphdGEyOiBBSENJIHJlc2V0Li4uCmF0YTI6IGhhcmR3YXJl IHJlc2V0IC4uLgphdGEyOiBTQVRBIGNvbm5lY3QgdGltZT0xMG1zIHN0YXR1cz0wMDAwMDExMwph dGEyOiByZWFkeSB3YWl0IHRpbWU9MzQybXMKYXRhMjogc29mdHdhcmUgcmVzZXQgcG9ydCAxNS4u LgphdGEyOiBhaGNpX2lzc3VlX2NtZCB0aW1lb3V0OiAzMDAwIG9mIDMwMDBtcywgc3RhdHVzPTAw MDAwMDAxCmF0YTI6IHBvcnQgaXMgbm90IHJlYWR5ICh0aW1lb3V0IDBtcykgdGZkID0gMDAwMDAx ZDAKYXRhMjogc29mdHdhcmUgcmVzZXQgY2xlYXIgdGltZW91dAphdGEyOiBzb2Z0d2FyZSByZXNl dCBwb3J0IDAuLi4KYXRhMjogcmVhZHkgd2FpdCB0aW1lPTBtcwphdGEyOiBTSUdOQVRVUkU6IDAw MDAwMTAxCmF0YTI6IEFIQ0kgcmVzZXQgZG9uZTogZGV2aWNlcz0wMDAwMDAwMQphdGEyOiBbTVBT QUZFXQphdGEyOiBbSVRIUkVBRF0KYXRhMzogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAKYXRh MzogQUhDSSByZXNldC4uLgphdGEzOiBoYXJkd2FyZSByZXNldCAuLi4KYXRhMzogU0FUQSBjb25u ZWN0IHRpbWVvdXQgc3RhdHVzPTAwMDAwMDAwCmF0YTM6IEFIQ0kgcmVzZXQgZG9uZTogcGh5IHJl c2V0IGZvdW5kIG5vIGRldmljZQphdGEzOiBbTVBTQUZFXQphdGEzOiBbSVRIUkVBRF0KYXRhNDog PEFUQSBjaGFubmVsIDI+IG9uIGF0YXBjaTAKYXRhNDogQUhDSSByZXNldC4uLgphdGE0OiBoYXJk d2FyZSByZXNldCAuLi4KYXRhNDogU0FUQSBjb25uZWN0IHRpbWVvdXQgc3RhdHVzPTAwMDAwMDAw CmF0YTQ6IEFIQ0kgcmVzZXQgZG9uZTogcGh5IHJlc2V0IGZvdW5kIG5vIGRldmljZQphdGE0OiBb TVBTQUZFXQphdGE0OiBbSVRIUkVBRF0KYXRhNTogPEFUQSBjaGFubmVsIDM+IG9uIGF0YXBjaTAK YXRhNTogQUhDSSByZXNldC4uLgphdGE1OiBoYXJkd2FyZSByZXNldCAuLi4KYXRhNTogU0FUQSBj b25uZWN0IHRpbWVvdXQgc3RhdHVzPTAwMDAwMDAwCmF0YTU6IEFIQ0kgcmVzZXQgZG9uZTogcGh5 IHJlc2V0IGZvdW5kIG5vIGRldmljZQphdGE1OiBbTVBTQUZFXQphdGE1OiBbSVRIUkVBRF0Kb2hj aTA6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gbWVtIDB4YzAwMDUwMDAtMHhjMDAw NWZmZiBpcnEgMTYgYXQgZGV2aWNlIDE5LjAgb24gcGNpMApvaGNpMDogUmVzZXJ2ZWQgMHgxMDAw IGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhjMDAwNTAwMAppb2FwaWMwOiByb3V0aW5n IGludHBpbiAxNiAoUENJIElSUSAxNikgdG8gbGFwaWMgMCB2ZWN0b3IgNTAKb2hjaTA6IFtNUFNB RkVdCm9oY2kwOiBbSVRIUkVBRF0KdXNidXMwOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xs ZXI+IG9uIG9oY2kwCm9oY2kxOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG1lbSAw eGMwMDA2MDAwLTB4YzAwMDZmZmYgaXJxIDE3IGF0IGRldmljZSAxOS4xIG9uIHBjaTAKb2hjaTE6 IFJlc2VydmVkIDB4MTAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4YzAwMDYwMDAK aW9hcGljMDogcm91dGluZyBpbnRwaW4gMTcgKFBDSSBJUlEgMTcpIHRvIGxhcGljIDAgdmVjdG9y IDUxCm9oY2kxOiBbTVBTQUZFXQpvaGNpMTogW0lUSFJFQURdCnVzYnVzMTogPE9IQ0kgKGdlbmVy aWMpIFVTQiBjb250cm9sbGVyPiBvbiBvaGNpMQpvaGNpMjogPE9IQ0kgKGdlbmVyaWMpIFVTQiBj b250cm9sbGVyPiBtZW0gMHhjMDAwNzAwMC0weGMwMDA3ZmZmIGlycSAxOCBhdCBkZXZpY2UgMTku MiBvbiBwY2kwCm9oY2kyOiBSZXNlcnZlZCAweDEwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUg MyBhdCAweGMwMDA3MDAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE4IChQQ0kgSVJRIDE4KSB0 byBsYXBpYyAwIHZlY3RvciA1MgpvaGNpMjogW01QU0FGRV0Kb2hjaTI6IFtJVEhSRUFEXQp1c2J1 czI6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gb2hjaTIKb2hjaTM6IDxPSENJ IChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gbWVtIDB4YzAwMDgwMDAtMHhjMDAwOGZmZiBpcnEg MTcgYXQgZGV2aWNlIDE5LjMgb24gcGNpMApvaGNpMzogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZv ciByaWQgMHgxMCB0eXBlIDMgYXQgMHhjMDAwODAwMApvaGNpMzogW01QU0FGRV0Kb2hjaTM6IFtJ VEhSRUFEXQp1c2J1czM6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gb2hjaTMK b2hjaTQ6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gbWVtIDB4YzAwMDkwMDAtMHhj MDAwOWZmZiBpcnEgMTggYXQgZGV2aWNlIDE5LjQgb24gcGNpMApvaGNpNDogUmVzZXJ2ZWQgMHgx MDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhjMDAwOTAwMApvaGNpNDogW01QU0FG RV0Kb2hjaTQ6IFtJVEhSRUFEXQp1c2J1czQ6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxl cj4gb24gb2hjaTQKZWhjaTA6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+IG1l bSAweGMwMDA0NDAwLTB4YzAwMDQ0ZmYgaXJxIDE5IGF0IGRldmljZSAxOS41IG9uIHBjaTAKZWhj aTA6IFJlc2VydmVkIDB4MTAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhjMDAwNDQw MAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxOSAoUENJIElSUSAxOSkgdG8gbGFwaWMgMCB2ZWN0 b3IgNTMKZWhjaTA6IFtNUFNBRkVdCmVoY2kwOiBbSVRIUkVBRF0KZWhjaTA6IEFNRCBTQjYwMC83 MDAgcXVpcmsgYXBwbGllZAp1c2J1czU6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXM1OiA8RUhDSSAo Z2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMApwY2kwOiA8c2VyaWFsIGJ1cywg U01CdXM+IGF0IGRldmljZSAyMC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCmF0YXBjaTE6IDxBVEkg SVhQNjAwIFVETUExMzMgY29udHJvbGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiwweDE3MC0w eDE3NywweDM3NiwweDg0MjAtMHg4NDJmIGF0IGRldmljZSAyMC4xIG9uIHBjaTAKYXRhcGNpMTog UmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4ODQyMAphdGEwOiA8 QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMQphdGFwY2kxOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9y IHJpZCAweDEwIHR5cGUgNCBhdCAweDFmMAphdGFwY2kxOiBSZXNlcnZlZCAweDEgYnl0ZXMgZm9y IHJpZCAweDE0IHR5cGUgNCBhdCAweDNmNgphdGEwOiByZXNldCB0cDEgbWFzaz0wMiBvc3RhdDA9 ZmYgb3N0YXQxPTUwCmF0YTA6IHN0YXQxPTB4MTAgZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWIK YXRhMDogcmVzZXQgdHAyIHN0YXQwPTAwIHN0YXQxPTEwIGRldmljZXM9MHgyMDAwMAppb2FwaWMw OiByb3V0aW5nIGludHBpbiAxNCAoSVNBIElSUSAxNCkgdG8gbGFwaWMgMCB2ZWN0b3IgNTQKYXRh MDogW01QU0FGRV0KYXRhMDogW0lUSFJFQURdCnBjaTA6IDxtdWx0aW1lZGlhLCBIREE+IGF0IGRl dmljZSAyMC4yIChubyBkcml2ZXIgYXR0YWNoZWQpCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0 IGRldmljZSAyMC4zIG9uIHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCnBjaWI0OiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDIwLjQgb24gcGNpMApwY2liNDogICBkb21haW4g ICAgICAgICAgICAwCnBjaWI0OiAgIHNlY29uZGFyeSBidXMgICAgIDgKcGNpYjQ6ICAgc3Vib3Jk aW5hdGUgYnVzICAgMTAKcGNpYjQ6ICAgSS9PIGRlY29kZSAgICAgICAgMHhmMDAwLTB4ZmZmCnBj aWI0OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4YzAzMDAwMDAtMHhjMDNmZmZmZgpwY2liNDogICBu byBwcmVmZXRjaGVkIGRlY29kZQpwY2liNDogICBTdWJ0cmFjdGl2ZWx5IGRlY29kZWQgYnJpZGdl LgpwY2k4OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNApwY2k4OiBkb21haW49MCwgcGh5c2ljYWwg YnVzPTgKZm91bmQtPgl2ZW5kb3I9MHgxNGU0LCBkZXY9MHgxNzBjLCByZXZpZD0weDAyCglkb21h aW49MCwgYnVzPTgsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMi0wMC0wMCwgaGRydHlwZT0weDAw LCBtZmRldj0wCgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTAgKGR3 b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxh dD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMAoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQw IEQxIEQyIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJh c2UgMHhjMDMwMDAwMCwgc2l6ZSAxMywgZW5hYmxlZApwY2liNDogcmVxdWVzdGVkIG1lbW9yeSBy YW5nZSAweGMwMzAwMDAwLTB4YzAzMDFmZmY6IGdvb2QKcGNpYjQ6IG1hdGNoZWQgZW50cnkgZm9y IDguMC5JTlRBCnBjaWI0OiBzbG90IDAgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDIxCmZvdW5kLT4J dmVuZG9yPTB4MTE4MCwgZGV2PTB4MDgyMiwgcmV2aWQ9MHgxOQoJZG9tYWluPTAsIGJ1cz04LCBz bG90PTEsIGZ1bmM9MAoJY2xhc3M9MDgtMDUtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21k cmVnPTB4MDAwNiwgc3RhdHJlZz0weDAyMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1l cj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykK CWludHBpbj1iLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3Vy cmVudCBEMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4YzAzMDIwMDAs IHNpemUgIDgsIGVuYWJsZWQKcGNpYjQ6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhjMDMwMjAw MC0weGMwMzAyMGZmOiBnb29kCnBjaWI0OiBtYXRjaGVkIGVudHJ5IGZvciA4LjEuSU5UQgpwY2li NDogc2xvdCAxIElOVEIgaGFyZHdpcmVkIHRvIElSUSAyMApmb3VuZC0+CXZlbmRvcj0weDExODAs IGRldj0weDA4NDMsIHJldmlkPTB4MDEKCWRvbWFpbj0wLCBidXM9OCwgc2xvdD0xLCBmdW5jPTEK CWNsYXNzPTA4LTgwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDYsIHN0 YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyks IG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTkK CXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTog dHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4YzAzMDI0MDAsIHNpemUgIDgsIGVuYWJsZWQK cGNpYjQ6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhjMDMwMjQwMC0weGMwMzAyNGZmOiBnb29k CnBjaWI0OiBtYXRjaGVkIGVudHJ5IGZvciA4LjEuSU5UQgpwY2liNDogc2xvdCAxIElOVEIgaGFy ZHdpcmVkIHRvIElSUSAyMApiZmUwOiA8QnJvYWRjb20gQkNNNDQwMS1CMCBGYXN0IEV0aGVybmV0 PiBtZW0gMHhjMDMwMDAwMC0weGMwMzAxZmZmIGlycSAyMSBhdCBkZXZpY2UgMC4wIG9uIHBjaTgK YmZlMDogUmVzZXJ2ZWQgMHgyMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhjMDMw MDAwMAptaWlidXMwOiA8TUlJIGJ1cz4gb24gYmZlMApibXRwaHkwOiA8QkNNNDQwMSAxMC8xMDBi YXNlVFggUEhZPiBQSFkgMSBvbiBtaWlidXMwCmJtdHBoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZE WCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCBhdXRvCmJmZTA6IGJwZiBhdHRhY2hlZApiZmUw OiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxZDowOTpiNjpmMzpmMAppb2FwaWMwOiByb3V0aW5nIGlu dHBpbiAyMSAoUENJIElSUSAyMSkgdG8gbGFwaWMgMCB2ZWN0b3IgNTUKYmZlMDogW01QU0FGRV0K YmZlMDogW0lUSFJFQURdCnBjaTg6IDxiYXNlIHBlcmlwaGVyYWwsIFNEIGhvc3QgY29udHJvbGxl cj4gYXQgZGV2aWNlIDEuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2k4OiA8YmFzZSBwZXJpcGhl cmFsPiBhdCBkZXZpY2UgMS4xIChubyBkcml2ZXIgYXR0YWNoZWQpCmFjcGlfYnV0dG9uMTogPFNs ZWVwIEJ1dHRvbj4gb24gYWNwaTAKYWNwaV9saWQwOiA8Q29udHJvbCBNZXRob2QgTGlkIFN3aXRj aD4gb24gYWNwaTAKYWNwaV9hY2FkMDogPEFDIEFkYXB0ZXI+IG9uIGFjcGkwCmJhdHRlcnkwOiA8 QUNQSSBDb250cm9sIE1ldGhvZCBCYXR0ZXJ5PiBvbiBhY3BpMAphY3BpX3R6MDogPFRoZXJtYWwg Wm9uZT4gb24gYWNwaTAKYXRydGMwOiA8QVQgcmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3MC0weDcx IGlycSA4IG9uIGFjcGkwCmF0cnRjMDogcmVnaXN0ZXJlZCBhcyBhIHRpbWUtb2YtZGF5IGNsb2Nr IChyZXNvbHV0aW9uIDEwMDAwMDB1cykKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4 MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+ IGlycSAxIG9uIGF0a2JkYzAKYXRrYmQ6IHRoZSBjdXJyZW50IGtiZCBjb250cm9sbGVyIGNvbW1h bmQgYnl0ZSAwMDQ3CmF0a2JkOiBrZXlib2FyZCBJRCAweDQxYWIgKDIpCkNhbGxpbmcgaW50IDB4 MTUgKGF4PTB4YzAwMCBieD0weDAwMDAgY3g9MHgwMDAwIGR4PTB4MDAwMCBlcz0weDAwMDAgZGk9 MHgwMDAwKQpFeGl0aW5nIGludCAweDE1IChheD0weDAwMDAgYng9MHhlNmY1IGN4PTB4MDAwMCBk eD0weDAwMDAgZXM9MHhmMDAwIGRpPTB4MDAwMCkKa2JkMCBhdCBhdGtiZDAKa2JkMDogYXRrYmQw LCBBVCAxMDEvMTAyICgyKSwgY29uZmlnOjB4MCwgZmxhZ3M6MHgzZDAwMDAKaW9hcGljMDogcm91 dGluZyBpbnRwaW4gMSAoSVNBIElSUSAxKSB0byBsYXBpYyAwIHZlY3RvciA1NgphdGtiZDA6IFtH SUFOVC1MT0NLRURdCmF0a2JkMDogW0lUSFJFQURdCnBzbTA6IHVuYWJsZSB0byBhbGxvY2F0ZSBJ UlEKcHNtY3BucDA6IDxQUy8yIG1vdXNlIHBvcnQ+IGlycSAxMiBvbiBhY3BpMApwc20wOiBjdXJy ZW50IGNvbW1hbmQgYnl0ZTowMDQ3CnBzbTA6IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRj MAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxMiAoSVNBIElSUSAxMikgdG8gbGFwaWMgMCB2ZWN0 b3IgNTcKcHNtMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogW0lUSFJFQURdCnBzbTA6IG1vZGVsIEdl bmVyaWMgUFMvMiBtb3VzZSwgZGV2aWNlIElEIDAtMDAsIDIgYnV0dG9ucwpwc20wOiBjb25maWc6 MDAwMDAwMDAsIGZsYWdzOjAwMDAwMDA4LCBwYWNrZXQgc2l6ZTozCnBzbTA6IHN5bmNtYXNrOmMw LCBzeW5jYml0czowMApjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTA6IHN3aXRjaGluZyB0 byBnZW5lcmljIEN4IG1vZGUKYWNwaV90aHJvdHRsZTA6IDxBQ1BJIENQVSBUaHJvdHRsaW5nPiBv biBjcHUwCmFjcGlfdGhyb3R0bGUwOiBQX0NOVCBmcm9tIFBfQkxLIDB4ODAxMApwb3dlcm5vdzA6 IDxQb3dlck5vdyEgSzg+IG9uIGNwdTAKY3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMApwb3dlcm5v dzE6IDxQb3dlck5vdyEgSzg+IG9uIGNwdTEKYWhjX2lzYV9wcm9iZSAwOiBpb3BvcnQgMHhjMDAg YWxsb2MgZmFpbGVkCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyMDMKcG5wX2lk ZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDI0MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFk X1BvcnQgYXQgMjgzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyYzMKcG5wX2lk ZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDMwMwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFk X1BvcnQgYXQgMzQzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzODMKcG5wX2lk ZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDNjMwpQTlAgSWRlbnRpZnkgY29tcGxldGUKZXhf aXNhX2lkZW50aWZ5KCkKdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZgp1bmtub3du OiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCnVua25vd246IHN0YXR1cyByZWcgdGVzdCBmYWls ZWQgZmYKdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZgp1bmtub3duOiBzdGF0dXMg cmVnIHRlc3QgZmFpbGVkIGZmCmlzYV9wcm9iZV9jaGlsZHJlbjogZGlzYWJsaW5nIFBuUCBkZXZp Y2VzCnBtdGltZXIwIG9uIGlzYTAKYXRhOiBhdGEwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBp dAphdGtiZGM6IGF0a2JkYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmF0cnRjOiBhdHJ0 YzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CnNjOiBzYzAgYWxyZWFkeSBleGlzdHM7IHNr aXBwaW5nIGl0CmlzYV9wcm9iZV9jaGlsZHJlbjogcHJvYmluZyBub24tUG5QIGRldmljZXMKb3Jt MDogPElTQSBPcHRpb24gUk9Ncz4gYXQgaW9tZW0gMHhjMDAwMC0weGNjZmZmLDB4Y2QwMDAtMHhj ZGZmZiBwbnBpZCBPUk0wMDAwIG9uIGlzYTAKc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdz IDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAw PgpzYzA6IGZiMCwga2JkMSwgdGVybWluYWwgZW11bGF0b3I6IHNjdGVrZW4gKHRla2VuIHRlcm1p bmFsKQp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4 YTAwMDAtMHhiZmZmZiBvbiBpc2EwCmF0YTEgZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgxNzAg aXJxIDE1IG9uIGlzYTAKZmRjMCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNmMC0weDNmNSww eDNmNyBpcnEgNiBkcnEgMiBvbiBpc2EwCnBwYzA6IHBhcmFsbGVsIHBvcnQgbm90IGZvdW5kLgpw cGMwOiA8UGFyYWxsZWwgcG9ydD4gZmFpbGVkIHRvIHByb2JlIGF0IGlycSA3IG9uIGlzYTAKdWFy dDA6IDxuczgyNTA+IGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IG9u IGlzYTAKdWFydDE6IDxuczgyNTA+IGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4MmY4LTB4MmZm IGlycSAzIG9uIGlzYTAKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIFBuUCBkZXZpY2VzCkRl dmljZSBjb25maWd1cmF0aW9uIGZpbmlzaGVkLgpSZWR1Y2luZyBrZXJuLm1heHZub2RlcyAxMjU3 MDYgLT4gMTAwMDAwCnByb2NmcyByZWdpc3RlcmVkCmxhcGljOiBEaXZpc29yIDIsIEZyZXF1ZW5j eSA5OTc1MDYxNCBoegpUaW1lY291bnRlciAiVFNDIiBmcmVxdWVuY3kgMTc5NTUxMDk2MyBIeiBx dWFsaXR5IC0xMDAKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwpsbzA6IGJwZiBh dHRhY2hlZApocHRycjogbm8gY29udHJvbGxlciBkZXRlY3RlZC4KYXRhMDogSWRlbnRpZnlpbmcg ZGV2aWNlczogMDAwMjAwMDAKYXRhMDogTmV3IGRldmljZXM6IDAwMDIwMDAwCnVzYnVzMDogMTJN YnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMxOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEu MAp1c2J1czI6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzMzogMTJNYnBzIEZ1bGwg U3BlZWQgVVNCIHYxLjAKdXNidXM0OiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czU6 IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAphY3BpX2FjYWQwOiBhY2xpbmUgaW5pdGlhbGl6 YXRpb24gc3RhcnQKYmF0dGVyeTA6IGJhdHRlcnkgaW5pdGlhbGl6YXRpb24gc3RhcnQKYXRhMC1z bGF2ZTogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVETUEzMyBjYWJsZT00MCB3aXJlCmFjcGlf YWNhZDA6IE9uIExpbmUKYWNwaV9hY2FkMDogYWNsaW5lIGluaXRpYWxpemF0aW9uIGRvbmUsIHRy aWVkIDEgdGltZXMKYWNkMDogc2V0dGluZyBQSU80IG9uIElYUDYwMCBjaGlwCmFjZDA6IHNldHRp bmcgVURNQTMzIG9uIElYUDYwMCBjaGlwCnVnZW4wLjE6IDxBVEk+IGF0IHVzYnVzMAp1aHViMDog PEFUSSBPSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24g dXNidXMwCnVnZW4xLjE6IDxBVEk+IGF0IHVzYnVzMQp1aHViMTogPEFUSSBPSENJIHJvb3QgSFVC LCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMxCnVnZW4yLjE6IDxB VEk+IGF0IHVzYnVzMgp1aHViMjogPEFUSSBPSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAx LjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMyCnVnZW4zLjE6IDxBVEk+IGF0IHVzYnVzMwp1aHVi MzogPEFUSSBPSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4g b24gdXNidXMzCnVnZW40LjE6IDxBVEk+IGF0IHVzYnVzNAp1aHViNDogPEFUSSBPSENJIHJvb3Qg SFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM0CnVnZW41LjE6 IDxBVEk+IGF0IHVzYnVzNQp1aHViNTogPEFUSSBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJl diAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM1CmFjZDA6IDxUU1NUY29ycENEL0RWRFcgVFMt TDYzMk0vU0MwMj4gRFZEUiBkcml2ZSBhdCBhdGEwIGFzIHNsYXZlCmFjZDA6IHJlYWQgNDEzNEtC L3MgKDQxMzRLQi9zKSB3cml0ZSAxNzJLQi9zICg0MTM0S0IvcyksIDIwNDhLQiBidWZmZXIsIFVE TUEzMwphY2QwOiBSZWFkczogQ0RSLCBDRFJXLCBDRERBIHN0cmVhbSwgRFZEUk9NLCBEVkRSLCBE VkRSQU0sIHBhY2tldAphY2QwOiBXcml0ZXM6IENEUiwgQ0RSVywgRFZEUiwgRFZEUkFNLCB0ZXN0 IHdyaXRlLCBidXJucHJvb2YKYWNkMDogQXVkaW86IHBsYXksIDI1NiB2b2x1bWUgbGV2ZWxzCmFj ZDA6IE1lY2hhbmlzbTogZWplY3RhYmxlIHRyYXksIHVubG9ja2VkCmFjZDA6IE1lZGl1bTogbm8v YmxhbmsgZGlzYwphdGEyOiBJZGVudGlmeWluZyBkZXZpY2VzOiAwMDAwMDAwMQphdGEyOiBOZXcg ZGV2aWNlczogMDAwMDAwMDEKYXRhMi1tYXN0ZXI6IHBpbz1QSU80IHdkbWE9V0RNQTIgdWRtYT1V RE1BMTMzIGNhYmxlPTQwIHdpcmUKYWQ0OiAxMTQ0NzNNQiA8V0RDIFdEMTIwMEJFVlMtMjJVU1Qw IDAxLjAxQTAxPiBhdCBhdGEyLW1hc3RlciBTQVRBMTUwCmFkNDogMjM0NDQxNjQ4IHNlY3RvcnMg WzIzMjU4MUMvMTZILzYzU10gMTYgc2VjdG9ycy9pbnRlcnJ1cHQgMSBkZXB0aCBxdWV1ZQpHRU9N OiBuZXcgZGlzayBhZDQKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dl cmVkCnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMjog MiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjM6IDIgcG9ydHMgd2l0 aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI0OiAyIHBvcnRzIHdpdGggMiByZW1vdmFi bGUsIHNlbGYgcG93ZXJlZAphZDQ6IFNpbGljb24gSW1hZ2UgY2hlY2szIGZhaWxlZApBQ1BJIFdh cm5pbmcgZm9yIFxcX1NCXy5CQVQxLl9CSUY6IENvbnZlcnRlZCBCdWZmZXIgdG8gZXhwZWN0ZWQg U3RyaW5nIGF0IGluZGV4IDkgKDIwMDkwOTAzL25zcmVwYWlyLTIxNSkKQUNQSSBXYXJuaW5nIGZv ciBcXF9TQl8uQkFUMS5fQklGOiBDb252ZXJ0ZWQgQnVmZmVyIHRvIGV4cGVjdGVkIFN0cmluZyBh dCBpbmRleCAxMCAoMjAwOTA5MDMvbnNyZXBhaXItMjE1KQpiYXR0ZXJ5MDogYmF0dGVyeSBpbml0 aWFsaXphdGlvbiBkb25lLCB0cmllZCAxIHRpbWVzCmFkNDogQWRhcHRlYyBjaGVjazEgZmFpbGVk CmFkNDogTFNJICh2MykgY2hlY2sxIGZhaWxlZAphZDQ6IExTSSAodjIpIGNoZWNrMSBmYWlsZWQK R0VPTTogYWQ0OiBwYXJ0aXRpb24gMiBkb2VzIG5vdCBzdGFydCBvbiBhIHRyYWNrIGJvdW5kYXJ5 LgpHRU9NOiBhZDQ6IHBhcnRpdGlvbiAyIGRvZXMgbm90IGVuZCBvbiBhIHRyYWNrIGJvdW5kYXJ5 LgpHRU9NOiBhZDQ6IHBhcnRpdGlvbiAxIGRvZXMgbm90IHN0YXJ0IG9uIGEgdHJhY2sgYm91bmRh cnkuCkdFT006IGFkNDogcGFydGl0aW9uIDEgZG9lcyBub3QgZW5kIG9uIGEgdHJhY2sgYm91bmRh cnkuCmFkNDogRnJlZUJTRCBjaGVjazEgZmFpbGVkCmF0YTM6IElkZW50aWZ5aW5nIGRldmljZXM6 IDAwMDAwMDAwCmF0YTM6IE5ldyBkZXZpY2VzOiAwMDAwMDAwMAphdGE0OiBJZGVudGlmeWluZyBk ZXZpY2VzOiAwMDAwMDAwMAphdGE0OiBOZXcgZGV2aWNlczogMDAwMDAwMDAKYXRhNTogSWRlbnRp ZnlpbmcgZGV2aWNlczogMDAwMDAwMDAKYXRhNTogTmV3IGRldmljZXM6IDAwMDAwMDAwCkFUQSBQ c2V1ZG9SQUlEIGxvYWRlZApTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCEKY3B1MSBBUDoKICAgICBJ RDogMHgwMTAwMDAwMCAgIFZFUjogMHg4MDA1MDAxMCBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZm ZmZmZmZmCiAgbGludDA6IDB4MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAw MDAwIFNWUjogMHgwMDAwMDFmZgogIHRpbWVyOiAweDAwMDIwMGVmIHRoZXJtOiAweDAwMDEwMDAw IGVycjogMHgwMDAxMDAwMCBwY206IDB4MDAwMTA0MDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4g OSAoSVNBIElSUSA5KSB0byBsYXBpYyAxIHZlY3RvciA0OAppb2FwaWMwOiByb3V0aW5nIGludHBp biAxNCAoSVNBIElSUSAxNCkgdG8gbGFwaWMgMSB2ZWN0b3IgNDkKaW9hcGljMDogcm91dGluZyBp bnRwaW4gMTcgKFBDSSBJUlEgMTcpIHRvIGxhcGljIDEgdmVjdG9yIDUwCmlvYXBpYzA6IHJvdXRp bmcgaW50cGluIDE5IChQQ0kgSVJRIDE5KSB0byBsYXBpYyAxIHZlY3RvciA1MQppb2FwaWMwOiBy b3V0aW5nIGludHBpbiAyMiAoUENJIElSUSAyMikgdG8gbGFwaWMgMSB2ZWN0b3IgNTIKV0FSTklO RzogV0lUTkVTUyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2UuClJv b3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNQpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1 czUKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM1ClJvb3QgbW91bnQgd2FpdGluZyBmb3I6 IHVzYnVzNQp1aHViNTogMTAgcG9ydHMgd2l0aCAxMCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApS b290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czUKdWdlbjUuMjogPHNpbGljb24+IGF0IHVzYnVz NQp1bWFzczA6IDxzaWxpY29uIC1wb3dlciwgY2xhc3MgMC8wLCByZXYgMi4wMC8xLjEwLCBhZGRy IDI+IG9uIHVzYnVzNQp1bWFzczA6ICBTQ1NJIG92ZXIgQnVsay1Pbmx5OyBxdWlya3MgPSAweDAw MDAKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM1CnVtYXNzMDowOjA6LTE6IEF0dGFjaGVk IHRvIHNjYnVzMAoocHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiBEb3duIHJldmluZyBQcm90b2Nv bCBWZXJzaW9uIGZyb20gMiB0byAwPwpHRU9NOiBuZXcgZGlzayBkYTAKcGFzczAgYXQgdW1hc3Mt c2ltMCBidXMgMCBzY2J1czAgdGFyZ2V0IDAgbHVuIDAKcGFzczA6IDxzaWxpY29uIC1wb3dlciAw LjAwPiBSZW1vdmFibGUgRGlyZWN0IEFjY2VzcyBTQ1NJLTAgZGV2aWNlIApwYXNzMDogU2VyaWFs IE51bWJlciBFNjg4MTYwMDNBMTMKcGFzczA6IDQwLjAwME1CL3MgdHJhbnNmZXJzCmRhMCBhdCB1 bWFzcy1zaW0wIGJ1cyAwIHNjYnVzMCB0YXJnZXQgMCBsdW4gMApkYTA6IDxzaWxpY29uIC1wb3dl ciAwLjAwPiBSZW1vdmFibGUgRGlyZWN0IEFjY2VzcyBTQ1NJLTAgZGV2aWNlIApkYTA6IFNlcmlh bCBOdW1iZXIgRTY4ODE2MDAzQTEzCmRhMDogNDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGEwOiA3NjQ0 TUIgKDE1NjU0OTEyIDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgOTc0QykKVHJ5aW5nIHRv IG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9kYTBzMWEKY3RfdG9fdHMoWzIwMDktMTAtMDYgMjA6 MjM6MzZdKSA9IDEyNTQ4NjA2MTYuMDAwMDAwMDAwCnN0YXJ0X2luaXQ6IHRyeWluZyAvc2Jpbi9p bml0CnVnZW4yLjI6IDxTSUxJQ09OIExBQk9SQVRPUklFUyBJTkMuPiBhdCB1c2J1czIKdWhpZDA6 IDxTSUxJQ09OIExBQk9SQVRPUklFUyBJTkMuIEZNIFJhZGlvLCBjbGFzcyAwLzAsIHJldiAxLjEw LzEuMDAsIGFkZHIgMj4gb24gdXNidXMyCg== --------_4ACB35D7000000000694_MULTIPART_MIXED_ Content-Type: application/octet-stream; name="m4a78pro.log" Content-Disposition: attachment; filename="m4a78pro.log" Content-Transfer-Encoding: base64 Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA5LjAtQ1VSUkVOVCAjMDogVHVlIE9jdCAgNiAwNzox MzoyNiBKU1QgMjAwOQogICAga2FybEBiZWVmLmppbmJvLmpwOi91c3Ivb2JqL3Vzci9zcmMvc3lz L0dFTkVSSUMgaTM4NgpXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3QgcmVk dWNlZCBwZXJmb3JtYW5jZS4KUHJlbG9hZGVkIGVsZiBrZXJuZWwgIi9ib290L2tlcm5lbC9rZXJu ZWwiIGF0IDB4YzExMjAwMDAuClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIg SHogcXVhbGl0eSAwCkNhbGlicmF0aW5nIFRTQyBjbG9jayAuLi4gVFNDIGNsb2NrOiAzNDExNTI0 MTkwIEh6CkNQVTogQU1EIFBoZW5vbSh0bSkgSUkgWDQgOTQwIFByb2Nlc3NvciAoMzQxMS41Mi1N SHogNjg2LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiQXV0aGVudGljQU1EIiAgSWQgPSAweDEwMGY0 MiAgU3RlcHBpbmcgPSAyCiAgRmVhdHVyZXM9MHgxNzhiZmJmZjxGUFUsVk1FLERFLFBTRSxUU0Ms TVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZM VVNILE1NWCxGWFNSLFNTRSxTU0UyLEhUVD4KICBGZWF0dXJlczI9MHg4MDIwMDk8U1NFMyxNT04s Q1gxNixQT1BDTlQ+CiAgQU1EIEZlYXR1cmVzPTB4ZWU1MDA4MDA8U1lTQ0FMTCxOWCxNTVgrLEZG WFNSLFBhZ2UxR0IsUkRUU0NQLExNLDNETm93ISssM0ROb3chPgogIEFNRCBGZWF0dXJlczI9MHgz N2ZmPExBSEYsQ01QLFNWTSxFeHRBUElDLENSOCxBQk0sU1NFNEEsTUFTLFByZWZldGNoLE9TVlcs SUJTLFNLSU5JVCxXRFQ+CiAgVFNDOiBQLXN0YXRlIGludmFyaWFudApEYXRhIFRMQjogNDggZW50 cmllcywgZnVsbHkgYXNzb2NpYXRpdmUKSW5zdHJ1Y3Rpb24gVExCOiAzMiBlbnRyaWVzLCBmdWxs eSBhc3NvY2lhdGl2ZQpMMSBkYXRhIGNhY2hlOiA2NCBrYnl0ZXMsIDY0IGJ5dGVzL2xpbmUsIDEg bGluZXMvdGFnLCAyLXdheSBhc3NvY2lhdGl2ZQpMMSBpbnN0cnVjdGlvbiBjYWNoZTogNjQga2J5 dGVzLCA2NCBieXRlcy9saW5lLCAxIGxpbmVzL3RhZywgMi13YXkgYXNzb2NpYXRpdmUKTDIgaW50 ZXJuYWwgY2FjaGU6IDUxMiBrYnl0ZXMsIDY0IGJ5dGVzL2xpbmUsIDEgbGluZXMvdGFnLCA4LXdh eSBhc3NvY2lhdGl2ZQpyZWFsIG1lbW9yeSAgPSA4NTg5OTM0NTkyICg4MTkyIE1CKQpQaHlzaWNh bCBtZW1vcnkgY2h1bmsocyk6CjB4MDAwMDAwMDAwMDAwMTAwMCAtIDB4MDAwMDAwMDAwMDA5ZWZm ZiwgNjQ3MTY4IGJ5dGVzICgxNTggcGFnZXMpCjB4MDAwMDAwMDAwMDEwMDAwMCAtIDB4MDAwMDAw MDAwMDNmZmZmZiwgMzE0NTcyOCBieXRlcyAoNzY4IHBhZ2VzKQoweDAwMDAwMDAwMDE0MjYwMDAg LSAweDAwMDAwMDAwY2M0YWVmZmYsIDM0MDYzMzYwMDAgYnl0ZXMgKDgzMTYyNSBwYWdlcykKYXZh aWwgbWVtb3J5ID0gMzQwNDg4MTkyMCAoMzI0NyBNQikKVGFibGUgJ0ZBQ1AnIGF0IDB4Y2ZmOTAy OTAKVGFibGUgJ0FQSUMnIGF0IDB4Y2ZmOTAzOTAKQVBJQzogRm91bmQgdGFibGUgYXQgMHhjZmY5 MDM5MApNUCBDb25maWd1cmF0aW9uIFRhYmxlIHZlcnNpb24gMS40IGZvdW5kIGF0IDB4YzAwZjBm ZTAKQVBJQzogVXNpbmcgdGhlIE1BRFQgZW51bWVyYXRvci4KTUFEVDogRm91bmQgQ1BVIEFQSUMg SUQgMCBBQ1BJIElEIDE6IGVuYWJsZWQKU01QOiBBZGRlZCBDUFUgMCAoQVApCk1BRFQ6IEZvdW5k IENQVSBBUElDIElEIDEgQUNQSSBJRCAyOiBlbmFibGVkClNNUDogQWRkZWQgQ1BVIDEgKEFQKQpN QURUOiBGb3VuZCBDUFUgQVBJQyBJRCAyIEFDUEkgSUQgMzogZW5hYmxlZApTTVA6IEFkZGVkIENQ VSAyIChBUCkKTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMyBBQ1BJIElEIDQ6IGVuYWJsZWQKU01Q OiBBZGRlZCBDUFUgMyAoQVApCk1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDEzMiBBQ1BJIElEIDU6 IGRpc2FibGVkCk1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDEzMyBBQ1BJIElEIDY6IGRpc2FibGVk CkFDUEkgQVBJQyBUYWJsZTogPDA3MjcwOSBBUElDMTA0NT4KSU5UUjogQWRkaW5nIGxvY2FsIEFQ SUMgMSBhcyBhIHRhcmdldApJTlRSOiBBZGRpbmcgbG9jYWwgQVBJQyAyIGFzIGEgdGFyZ2V0CklO VFI6IEFkZGluZyBsb2NhbCBBUElDIDMgYXMgYSB0YXJnZXQKRnJlZUJTRC9TTVA6IE11bHRpcHJv Y2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogNCBDUFVzCkZyZWVCU0QvU01QOiAxIHBhY2thZ2Uocykg eCA0IGNvcmUocykKIGNwdTAgKEJTUCk6IEFQSUMgSUQ6ICAwCiBjcHUxIChBUCk6IEFQSUMgSUQ6 ICAxCiBjcHUyIChBUCk6IEFQSUMgSUQ6ICAyCiBjcHUzIChBUCk6IEFQSUMgSUQ6ICAzCmJpb3Mz MjogRm91bmQgQklPUzMyIFNlcnZpY2UgRGlyZWN0b3J5IGhlYWRlciBhdCAweGMwMGYwMDAwCmJp b3MzMjogRW50cnkgPSAweGYwMDEwIChjMDBmMDAxMCkgIFJldiA9IDAgIExlbiA9IDEKcGNpYmlv czogUENJIEJJT1MgZW50cnkgYXQgMHhmMDAwMCsweDMxCnBucGJpb3M6IEZvdW5kIFBuUCBCSU9T IGRhdGEgYXQgMHhjMDBmNjQxMApwbnBiaW9zOiBFbnRyeSA9IGYwMDAwOjc2YWEgIFJldiA9IDEu MApPdGhlciBCSU9TIHNpZ25hdHVyZXMgZm91bmQ6CkFQSUM6IENQVSAwIGhhcyBBQ1BJIElEIDEK QVBJQzogQ1BVIDEgaGFzIEFDUEkgSUQgMgpBUElDOiBDUFUgMiBoYXMgQUNQSSBJRCAzCkFQSUM6 IENQVSAzIGhhcyBBQ1BJIElEIDQKVUxFOiBzZXR1cCBjcHUgMApVTEU6IHNldHVwIGNwdSAxClVM RTogc2V0dXAgY3B1IDIKVUxFOiBzZXR1cCBjcHUgMwpBQ1BJOiBSU0RQIDB4ZmI4YjAgMDAwMjQg KHYyIEFDUElBTSkKQUNQSTogWFNEVCAweGNmZjkwMTAwIDAwMDU0ICh2MSAwNzI3MDkgWFNEVDEw NDUgMjAwOTA3MjcgTVNGVCAwMDAwMDA5NykKQUNQSTogRkFDUCAweGNmZjkwMjkwIDAwMEY0ICh2 MyAwNzI3MDkgRkFDUDEwNDUgMjAwOTA3MjcgTVNGVCAwMDAwMDA5NykKQUNQSSBXYXJuaW5nOiBP cHRpb25hbCBmaWVsZCBQbTJDb250cm9sQmxvY2sgaGFzIHplcm8gYWRkcmVzcyBvciBsZW5ndGg6 ICAgICAgICAwICAgICAgIDAvMSAoMjAwOTA5MDMvdGJmYWR0LTY1NSkKQUNQSTogRFNEVCAweGNm ZjkwNDUwIDBEQUZFICh2MSAgQTExNTAgQTExNTAwMDAgMDAwMDAwMDAgSU5UTCAyMDA2MDExMykK QUNQSTogRkFDUyAweGNmZmE4MDAwIDAwMDQwCkFDUEk6IEFQSUMgMHhjZmY5MDM5MCAwMDA3QyAo djEgMDcyNzA5IEFQSUMxMDQ1IDIwMDkwNzI3IE1TRlQgMDAwMDAwOTcpCkFDUEk6IE1DRkcgMHhj ZmY5MDQxMCAwMDAzQyAodjEgMDcyNzA5IE9FTU1DRkcgIDIwMDkwNzI3IE1TRlQgMDAwMDAwOTcp CkFDUEk6IE9FTUIgMHhjZmZhODA0MCAwMDA3MiAodjEgMDcyNzA5IE9FTUIxMDQ1IDIwMDkwNzI3 IE1TRlQgMDAwMDAwOTcpCkFDUEk6IEhQRVQgMHhjZmY5ZjQ1MCAwMDAzOCAodjEgMDcyNzA5IE9F TUhQRVQgIDIwMDkwNzI3IE1TRlQgMDAwMDAwOTcpCkFDUEk6IFNTRFQgMHhjZmY5ZjQ5MCAwMDg4 QyAodjEgQSBNIEkgIFBPV0VSTk9XIDAwMDAwMDAxIEFNRCAgMDAwMDAwMDEpCk1BRFQ6IEZvdW5k IElPIEFQSUMgSUQgNCwgSW50ZXJydXB0IDAgYXQgMHhmZWMwMDAwMAppb2FwaWMwOiBSb3V0aW5n IGV4dGVybmFsIDgyNTlBJ3MgLT4gaW50cGluIDAKTUFEVDogSW50ZXJydXB0IG92ZXJyaWRlOiBz b3VyY2UgMCwgaXJxIDIKaW9hcGljMDogUm91dGluZyBJUlEgMCAtPiBpbnRwaW4gMgpNQURUOiBJ bnRlcnJ1cHQgb3ZlcnJpZGU6IHNvdXJjZSA5LCBpcnEgOQppb2FwaWMwOiBpbnRwaW4gOSB0cmln Z2VyOiBsZXZlbAppb2FwaWMwOiBpbnRwaW4gOSBwb2xhcml0eTogbG93CmlvYXBpYzAgPFZlcnNp b24gMi4xPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQKY3B1MCBCU1A6CiAgICAgSUQ6IDB4MDAw MDAwMDAgICBWRVI6IDB4ODAwNTAwMTAgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZgog IGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6 IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAxMDBlZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4 MDAwMTAwMGYgcGNtOiAweDAwMDEwNDAwCndsYW46IDw4MDIuMTEgTGluayBMYXllcj4KcmFuZG9t OiA8ZW50cm9weSBzb3VyY2UsIFNvZnR3YXJlLCBZYXJyb3c+Cm5mc2xvY2s6IHBzZXVkby1kZXZp Y2UKa2JkOiBuZXcgYXJyYXkgc2l6ZSA0CmtiZDEgYXQga2JkbXV4MAptZW06IDxtZW1vcnk+ClBl bnRpdW0gUHJvIE1UUlIgc3VwcG9ydCBlbmFibGVkCmlvOiA8SS9PPgpudWxsOiA8bnVsbCBkZXZp Y2UsIHplcm8gZGV2aWNlPgpocHRycjogUm9ja2V0UkFJRCAxN3h4LzJ4eHggU0FUQSBjb250cm9s bGVyIGRyaXZlciB2MS4yCm5weDA6IElOVCAxNiBpbnRlcmZhY2UKYWNwaTA6IDwwNzI3MDkgWFNE VDEwNDU+IG9uIG1vdGhlcmJvYXJkClBDSWU6IE1lbW9yeSBNYXBwZWQgY29uZmlndXJhdGlvbiBi YXNlIEAgMHhlMDAwMDAwMApwY2liaW9zOiBCSU9TIHZlcnNpb24gMy4wMAppb2FwaWMwOiByb3V0 aW5nIGludHBpbiA5IChJU0EgSVJRIDkpIHRvIGxhcGljIDAgdmVjdG9yIDQ4CmFjcGkwOiBbTVBT QUZFXQphY3BpMDogW0lUSFJFQURdCkFDUEkgRXJyb3IgKHBzYXJncy0wNDY0KTogW0VDRU5dIE5h bWVzcGFjZSBsb29rdXAgZmFpbHVyZSwgQUVfTk9UX0ZPVU5ECkFDUEkgRXJyb3IgKHBzcGFyc2Ut MDYzMyk6IE1ldGhvZCBwYXJzZS9leGVjdXRpb24gZmFpbGVkIFtcXF0gKE5vZGUgMHhjMGRhOGYz YyksIEFFX05PVF9GT1VORApBQ1BJOiBFeGVjdXRlZCAzIGJsb2NrcyBvZiBtb2R1bGUtbGV2ZWwg ZXhlY3V0YWJsZSBBTUwgY29kZQphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkKYWNwaTA6IHdh a2V1cCBjb2RlIHZhIDB4YzZiNGUwMDAgcGEgMHgxMDAwCkFjcGlPc0Rlcml2ZVBjaUlkOiBcXF9T Ql8uUENJMC5SUzc4Lk5CMl8gLT4gYnVzIDAgZGV2IDAgZnVuYyAwCmFjcGkwOiByZXNlcnZhdGlv biBvZiBmZWUwMDAwMCwgMTAwMCAoMykgZmFpbGVkCmFjcGkwOiByZXNlcnZhdGlvbiBvZiBmZmI4 MDAwMCwgODAwMDAgKDMpIGZhaWxlZAphY3BpMDogcmVzZXJ2YXRpb24gb2YgZmVjMTAwMDAsIDIw ICgzKSBmYWlsZWQKYWNwaTA6IHJlc2VydmF0aW9uIG9mIDAsIGEwMDAwICgzKSBmYWlsZWQKYWNw aTA6IHJlc2VydmF0aW9uIG9mIDEwMDAwMCwgY2ZmMDAwMDAgKDMpIGZhaWxlZApBQ1BJIEhQRVQg dGFibGUgd2FybmluZzogU2VxdWVuY2UgaXMgbm9uLXplcm8gKDIpCkFDUEkgdGltZXI6IDEvMiAx LzIgMS8yIDEvMiAxLzIgMS8yIDEvMiAxLzIgMS8yIDEvMiAtPiAxMApUaW1lY291bnRlciAiQUNQ SS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDEwMDAKYWNwaV90aW1lcjA6IDwz Mi1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHg4MDgtMHg4MGIgb24gYWNwaTAKcGNp X2xpbmswOiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2Jl ICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDQgNyAxMCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24g ICAgICAgICAgMCAgIDExICAgTiAgICAgMCAgNCA3IDEwIDExIDEyIDE0IDE1CiAgQWZ0ZXIgRGlz YWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICA0IDcgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsx OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAg IDAgICAxMCAgIE4gICAgIDAgIDQgNyAxMCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAg ICAgMCAgIDEwICAgTiAgICAgMCAgNCA3IDEwIDExIDEyIDE0IDE1CiAgQWZ0ZXIgRGlzYWJsZSAg ICAgICAwICAyNTUgICBOICAgICAwICA0IDcgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsyOiAgICAg ICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAx MCAgIE4gICAgIDAgIDQgNyAxMCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAg IDEwICAgTiAgICAgMCAgNCA3IDEwIDExIDEyIDE0IDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAw ICAyNTUgICBOICAgICAwICA0IDcgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmszOiAgICAgICAgSW5k ZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAgNyAgIE4g ICAgIDAgIDQgNyAxMCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgICA3ICAg TiAgICAgMCAgNCA3IDEwIDExIDEyIDE0IDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUg ICBOICAgICAwICA0IDcgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms0OiAgICAgICAgSW5kZXggIElS USAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAg IDQgNyAxMCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAg MCAgNCA3IDEwIDExIDEyIDE0IDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAg ICAwICA0IDcgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms1OiAgICAgICAgSW5kZXggIElSUSAgUnRk ICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMCAgIE4gICAgIDAgIDQgNyAx MCAxMSAxMiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgIDEwICAgTiAgICAgMCAgNCA3 IDEwIDExIDEyIDE0IDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICA0 IDcgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms2OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYg IElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDQgNyAxMCAxMSAx MiAxNCAxNQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgIDExICAgTiAgICAgMCAgNCA3IDEwIDEx IDEyIDE0IDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICA0IDcgMTAg MTEgMTIgMTQgMTUKcGNpX2xpbms3OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMK ICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDQgNyAxMCAxMSAxMiAxNCAx NQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNCA3IDEwIDExIDEyIDE0 IDE1CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICA0IDcgMTAgMTEgMTIg MTQgMTUKYWNwaV9ocGV0MDogPEhpZ2ggUHJlY2lzaW9uIEV2ZW50IFRpbWVyPiBpb21lbSAweGZl ZDAwMDAwLTB4ZmVkMDAzZmYgb24gYWNwaTAKYWNwaV9ocGV0MDogdmVuZDogMHg0MzUzIHJldjog MHgxIG51bTogMyBoejogMTQzMTgxODAgb3B0czogbGVnYWN5X3JvdXRlClRpbWVjb3VudGVyICJI UEVUIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA5MDAKcGNpYjA6IDxBQ1BJIEhvc3Qt UENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liMApwY2kwOiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTAKZm91bmQtPgl2ZW5kb3I9 MHgxMDIyLCBkZXY9MHg5NjAwLCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MCwg ZnVuYz0wCgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgw MDA2LCBzdGF0cmVnPTB4MjIzMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZl bmRvcj0weDEwNDMsIGRldj0weDk2MDIsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xv dD0xLCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJl Zz0weDAxMDcsIHN0YXRyZWc9MHgwMjMwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9 MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDFhICg2NTAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMp CmZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4OTYwNiwgcmV2aWQ9MHgwMAoJZG9tYWluPTAs IGJ1cz0wLCBzbG90PTYsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZk ZXY9MAoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRz KQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDA3ICgxNzUwIG5zKSwgbWF4bGF0PTB4 MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMg IGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UKcGNpYjA6IG1hdGNoZWQgZW50cnkg Zm9yIDAuNi5JTlRBCnBjaWIwOiBzbG90IDYgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE4CmZvdW5k LT4JdmVuZG9yPTB4MTAwMiwgZGV2PTB4NDM5MSwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0w LCBzbG90PTE3LCBmdW5jPTAKCWNsYXNzPTAxLTA2LTAxLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAK CWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgwMjMwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxh dHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgw IG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJy ZW50IEQwCgltYXBbMTBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGIwMDAsIHNp emUgIDMsIGVuYWJsZWQKCW1hcFsxNF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4 YTAwMCwgc2l6ZSAgMiwgZW5hYmxlZAoJbWFwWzE4XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIs IGJhc2UgMHg5MDAwLCBzaXplICAzLCBlbmFibGVkCgltYXBbMWNdOiB0eXBlIEkvTyBQb3J0LCBy YW5nZSAzMiwgYmFzZSAweDgwMDAsIHNpemUgIDIsIGVuYWJsZWQKCW1hcFsyMF06IHR5cGUgSS9P IFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4NzAwMCwgc2l6ZSAgNCwgZW5hYmxlZAoJbWFwWzI0XTog dHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmJiZmZjMDAsIHNpemUgMTAsIGVuYWJsZWQK cGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMTcuSU5UQQpwY2liMDogc2xvdCAxNyBJTlRBIGhh cmR3aXJlZCB0byBJUlEgMjIKZm91bmQtPgl2ZW5kb3I9MHgxMDAyLCBkZXY9MHg0Mzk3LCByZXZp ZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MTgsIGZ1bmM9MAoJY2xhc3M9MGMtMDMtMTAs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDEwMiwgc3RhdHJlZz0weDAyYTAsIGNh Y2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDAw ICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCgltYXBbMTBdOiB0 eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmYmJmZDAwMCwgc2l6ZSAxMiwgZW5hYmxlZApw Y2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4xOC5JTlRBCnBjaWIwOiBzbG90IDE4IElOVEEgaGFy ZHdpcmVkIHRvIElSUSAxNgpmb3VuZC0+CXZlbmRvcj0weDEwMDIsIGRldj0weDQzOTgsIHJldmlk PTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xOCwgZnVuYz0xCgljbGFzcz0wYy0wMy0xMCwg aGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMTE3LCBzdGF0cmVnPTB4MDJhMCwgY2Fj aGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCW1hcFsxMF06IHR5 cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZiYmZlMDAwLCBzaXplIDEyLCBlbmFibGVkCnBj aWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjE4LklOVEEKcGNpYjA6IHNsb3QgMTggSU5UQSBoYXJk d2lyZWQgdG8gSVJRIDE2CmZvdW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2PTB4NDM5NiwgcmV2aWQ9 MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTE4LCBmdW5jPTIKCWNsYXNzPTBjLTAzLTIwLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDIsIHN0YXRyZWc9MHgwMmIwLCBjYWNo ZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWIsIGlycT0xMAoJcG93ZXJzcGVjIDIg IHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwg cmFuZ2UgMzIsIGJhc2UgMHhmYmJmZjgwMCwgc2l6ZSAgOCwgZW5hYmxlZApwY2liMDogbWF0Y2hl ZCBlbnRyeSBmb3IgMC4xOC5JTlRCCnBjaWIwOiBzbG90IDE4IElOVEIgaGFyZHdpcmVkIHRvIElS USAxNwpmb3VuZC0+CXZlbmRvcj0weDEwMDIsIGRldj0weDQzOTcsIHJldmlkPTB4MDAKCWRvbWFp bj0wLCBidXM9MCwgc2xvdD0xOSwgZnVuYz0wCgljbGFzcz0wYy0wMy0xMCwgaGRydHlwZT0weDAw LCBtZmRldj0xCgljbWRyZWc9MHgwMTAyLCBzdGF0cmVnPTB4MDJhMCwgY2FjaGVsbnN6PTE2IChk d29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhs YXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCBy YW5nZSAzMiwgYmFzZSAweGZiYmZiMDAwLCBzaXplIDEyLCBlbmFibGVkCnBjaWIwOiBtYXRjaGVk IGVudHJ5IGZvciAwLjE5LklOVEEKcGNpYjA6IHNsb3QgMTkgSU5UQSBoYXJkd2lyZWQgdG8gSVJR IDE4CmZvdW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2PTB4NDM5OCwgcmV2aWQ9MHgwMAoJZG9tYWlu PTAsIGJ1cz0wLCBzbG90PTE5LCBmdW5jPTEKCWNsYXNzPTBjLTAzLTEwLCBoZHJ0eXBlPTB4MDAs IG1mZGV2PTAKCWNtZHJlZz0weDAxMTcsIHN0YXRyZWc9MHgwMmEwLCBjYWNoZWxuc3o9MTYgKGR3 b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxh dD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJh bmdlIDMyLCBiYXNlIDB4ZmJiZmMwMDAsIHNpemUgMTIsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQg ZW50cnkgZm9yIDAuMTkuSU5UQQpwY2liMDogc2xvdCAxOSBJTlRBIGhhcmR3aXJlZCB0byBJUlEg MTgKZm91bmQtPgl2ZW5kb3I9MHgxMDAyLCBkZXY9MHg0Mzk2LCByZXZpZD0weDAwCglkb21haW49 MCwgYnVzPTAsIHNsb3Q9MTksIGZ1bmM9MgoJY2xhc3M9MGMtMDMtMjAsIGhkcnR5cGU9MHgwMCwg bWZkZXY9MAoJY21kcmVnPTB4MDEwMiwgc3RhdHJlZz0weDAyYjAsIGNhY2hlbG5zej0xNiAoZHdv cmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTcKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBE MSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNl IDB4ZmJiZmY0MDAsIHNpemUgIDgsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAu MTkuSU5UQgpwY2liMDogc2xvdCAxOSBJTlRCIGhhcmR3aXJlZCB0byBJUlEgMTkKZm91bmQtPgl2 ZW5kb3I9MHgxMDAyLCBkZXY9MHg0Mzg1LCByZXZpZD0weDNhCglkb21haW49MCwgYnVzPTAsIHNs b3Q9MjAsIGZ1bmM9MAoJY2xhc3M9MGMtMDUtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21k cmVnPTB4MDQwMywgc3RhdHJlZz0weGQyMzAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1l cj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91 bmQtPgl2ZW5kb3I9MHgxMDAyLCBkZXY9MHg0MzljLCByZXZpZD0weDAwCglkb21haW49MCwgYnVz PTAsIHNsb3Q9MjAsIGZ1bmM9MQoJY2xhc3M9MDEtMDEtOGEsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyMzAsIGNhY2hlbG5zej0wIChkd29yZHMpCgls YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu cykKCWludHBpbj1hLCBpcnE9MjU1CglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlCgltYXBbMjBdOiB0 eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGZmMDAsIHNpemUgIDQsIGVuYWJsZWQKZm91 bmQtPgl2ZW5kb3I9MHgxMDAyLCBkZXY9MHg0MzgzLCByZXZpZD0weDAwCglkb21haW49MCwgYnVz PTAsIHNsb3Q9MjAsIGZ1bmM9MgoJY2xhc3M9MDQtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MAoJY21kcmVnPTB4MDAwNiwgc3RhdHJlZz0weDA0MTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJ bGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAg KDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1 cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGZiYmY0MDAw LCBzaXplIDE0LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjIwLklOVEEKcGNp YjA6IHNsb3QgMjAgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CmZvdW5kLT4JdmVuZG9yPTB4MTAw MiwgZGV2PTB4NDM5ZCwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIwLCBmdW5j PTMKCWNsYXNzPTA2LTAxLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMGYs IHN0YXRyZWc9MHgwMjIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9y PTB4MTAwMiwgZGV2PTB4NDM4NCwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIw LCBmdW5jPTQKCWNsYXNzPTA2LTA0LTAxLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTEKCWNtZHJlZz0w eDAxMDcsIHN0YXRyZWc9MHgwMmEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0 MCAoMTkyMCBucyksIG1pbmdudD0weDA3ICgxNzUwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZv dW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2PTB4NDM5OSwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1 cz0wLCBzbG90PTIwLCBmdW5jPTUKCWNsYXNzPTBjLTAzLTEwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2 PTAKCWNtZHJlZz0weDAxMDIsIHN0YXRyZWc9MHgwMmEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykK CWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAw ICgwIG5zKQoJaW50cGluPWMsIGlycT0xMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMy LCBiYXNlIDB4ZmJiZmEwMDAsIHNpemUgMTIsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkg Zm9yIDAuMjAuSU5UQwpwY2liMDogc2xvdCAyMCBJTlRDIGhhcmR3aXJlZCB0byBJUlEgMTgKZm91 bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMjAwLCByZXZpZD0weDAwCglkb21haW49MCwgYnVz PTAsIHNsb3Q9MjQsIGZ1bmM9MAoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCgls YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu cykKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMjAxLCByZXZpZD0weDAwCglkb21haW49 MCwgYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MQoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwg bWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hlbG5zej0wIChkd29y ZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgw MCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMjAyLCByZXZpZD0weDAwCglk b21haW49MCwgYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MgoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9 MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hlbG5zej0w IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhs YXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMjAzLCByZXZpZD0w eDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MwoJY2xhc3M9MDYtMDAtMDAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMTAsIGNhY2hl bG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMjA0LCBy ZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9NAoJY2xhc3M9MDYtMDAt MDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAs IGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBh dCBkZXZpY2UgMS4wIG9uIHBjaTAKcGNpYjE6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liMTog ICBzZWNvbmRhcnkgYnVzICAgICAxCnBjaWIxOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDEKcGNpYjE6 ICAgSS9PIGRlY29kZSAgICAgICAgMHhjMDAwLTB4Y2ZmZgpwY2liMTogICBtZW1vcnkgZGVjb2Rl ICAgICAweGZiYzAwMDAwLTB4ZmJkZmZmZmYKcGNpYjE6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhk MDAwMDAwMC0weGRmZmZmZmZmCnBjaTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxCnBjaTE6IGRv bWFpbj0wLCBwaHlzaWNhbCBidXM9MQpmb3VuZC0+CXZlbmRvcj0weDEwMDIsIGRldj0weDk2MTAs IHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MSwgc2xvdD01LCBmdW5jPTAKCWNsYXNzPTAzLTAw LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHg0MDEw LCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgw MCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMAoJcG93ZXJzcGVj IDMgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNz YWdlLCA2NCBiaXQKCW1hcFsxMF06IHR5cGUgUHJlZmV0Y2hhYmxlIE1lbW9yeSwgcmFuZ2UgMzIs IGJhc2UgMHhkMDAwMDAwMCwgc2l6ZSAyOCwgZW5hYmxlZApwY2liMTogcmVxdWVzdGVkIG1lbW9y eSByYW5nZSAweGQwMDAwMDAwLTB4ZGZmZmZmZmY6IGdvb2QKCW1hcFsxNF06IHR5cGUgSS9PIFBv cnQsIHJhbmdlIDMyLCBiYXNlIDB4YzAwMCwgc2l6ZSAgOCwgZW5hYmxlZApwY2liMTogcmVxdWVz dGVkIEkvTyByYW5nZSAweGMwMDAtMHhjMGZmOiBpbiByYW5nZQoJbWFwWzE4XTogdHlwZSBNZW1v cnksIHJhbmdlIDMyLCBiYXNlIDB4ZmJkZTAwMDAsIHNpemUgMTYsIGVuYWJsZWQKcGNpYjE6IHJl cXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhmYmRlMDAwMC0weGZiZGVmZmZmOiBnb29kCgltYXBbMjRd OiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmYmMwMDAwMCwgc2l6ZSAyMCwgZW5hYmxl ZApwY2liMTogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGZiYzAwMDAwLTB4ZmJjZmZmZmY6IGdv b2QKcGNpYjE6IG1hdGNoZWQgZW50cnkgZm9yIDEuNS5JTlRBCnBjaWIxOiBzbG90IDUgSU5UQSBo YXJkd2lyZWQgdG8gSVJRIDE4CmZvdW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2PTB4OTYwZiwgcmV2 aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0xLCBzbG90PTUsIGZ1bmM9MQoJY2xhc3M9MDQtMDMtMDAs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDQwMTAsIGNh Y2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTcKCXBvd2Vyc3BlYyAzICBz dXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwg NjQgYml0CgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmYmRmYzAwMCwg c2l6ZSAxNCwgZW5hYmxlZApwY2liMTogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGZiZGZjMDAw LTB4ZmJkZmZmZmY6IGdvb2QKcGNpYjE6IG1hdGNoZWQgZW50cnkgZm9yIDEuNS5JTlRCCnBjaWIx OiBzbG90IDUgSU5UQiBoYXJkd2lyZWQgdG8gSVJRIDE5CnZnYXBjaTA6IDxWR0EtY29tcGF0aWJs ZSBkaXNwbGF5PiBwb3J0IDB4YzAwMC0weGMwZmYgbWVtIDB4ZDAwMDAwMDAtMHhkZmZmZmZmZiww eGZiZGUwMDAwLTB4ZmJkZWZmZmYsMHhmYmMwMDAwMC0weGZiY2ZmZmZmIGlycSAxOCBhdCBkZXZp Y2UgNS4wIG9uIHBjaTEKcGNpMTogPG11bHRpbWVkaWEsIEhEQT4gYXQgZGV2aWNlIDUuMSAobm8g ZHJpdmVyIGF0dGFjaGVkKQpwY2liMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxOCBhdCBk ZXZpY2UgNi4wIG9uIHBjaTAKcGNpYjI6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liMjogICBz ZWNvbmRhcnkgYnVzICAgICAyCnBjaWIyOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDIKcGNpYjI6ICAg SS9PIGRlY29kZSAgICAgICAgMHhkMDAwLTB4ZGZmZgpwY2liMjogICBtZW1vcnkgZGVjb2RlICAg ICAweGZiZTAwMDAwLTB4ZmJlZmZmZmYKcGNpYjI6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUKcGNp MjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIKcGNpMjogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0y CmZvdW5kLT4JdmVuZG9yPTB4MTk2OSwgZGV2PTB4MTAyNiwgcmV2aWQ9MHhiMAoJZG9tYWluPTAs IGJ1cz0yLCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDItMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZk ZXY9MAoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDQwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRz KQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAg KDAgbnMpCglpbnRwaW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1 cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdAoJbWFwWzEwXTogdHlwZSBN ZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZmJlYzAwMDAsIHNpemUgMTgsIGVuYWJsZWQKcGNpYjI6 IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhmYmVjMDAwMC0weGZiZWZmZmZmOiBnb29kCgltYXBb MThdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGRjMDAsIHNpemUgIDcsIGVuYWJs ZWQKcGNpYjI6IHJlcXVlc3RlZCBJL08gcmFuZ2UgMHhkYzAwLTB4ZGM3ZjogaW4gcmFuZ2UKcGNp YjI6IG1hdGNoZWQgZW50cnkgZm9yIDIuMC5JTlRBCnBjaWIyOiBzbG90IDAgSU5UQSBoYXJkd2ly ZWQgdG8gSVJRIDE4CmFsZTA6IDxBdGhlcm9zIEFSODEyMS9BUjgxMTMvQVI4MTE0IFBDSWUgRXRo ZXJuZXQ+IHBvcnQgMHhkYzAwLTB4ZGM3ZiBtZW0gMHhmYmVjMDAwMC0weGZiZWZmZmZmIGlycSAx OCBhdCBkZXZpY2UgMC4wIG9uIHBjaTIKYWxlMDogUmVzZXJ2ZWQgMHg0MDAwMCBieXRlcyBmb3Ig cmlkIDB4MTAgdHlwZSAzIGF0IDB4ZmJlYzAwMDAKYWxlMDogUENJIGRldmljZSByZXZpc2lvbiA6 IDB4MDBiMAphbGUwOiBDaGlwIGlkL3JldmlzaW9uIDogMHhiMDAyCmFsZTA6IDk2MCBUeCBGSUZP LCAxMDI0IFJ4IEZJRk8KYWxlMDogTVNJWCBjb3VudCA6IDAKYWxlMDogTVNJIGNvdW50IDogMQph bGUwOiBhdHRlbXB0aW5nIHRvIGFsbG9jYXRlIDEgTVNJIHZlY3RvcnMgKDEgc3VwcG9ydGVkKQpt c2k6IHJvdXRpbmcgTVNJIElSUSAyNTYgdG8gbG9jYWwgQVBJQyAwIHZlY3RvciA0OQphbGUwOiB1 c2luZyBJUlEgMjU2IGZvciBNU0kKYWxlMDogVXNpbmcgMSBNU0kgbWVzc2FnZXMuCmFsZTA6IFJl YWQgcmVxdWVzdCBzaXplIDogNTEyIGJ5dGVzLgphbGUwOiBUTFAgcGF5bG9hZCBzaXplIDogMTI4 IGJ5dGVzLgphbGUwOiBQQ0kgVlBEIGNhcGFiaWxpdHkgbm90IGZvdW5kIQptaWlidXMwOiA8TUlJ IGJ1cz4gb24gYWxlMAphdHBoeTA6IDxBdGhlcm9zIEYxIDEwLzEwMC8xMDAwIFBIWT4gUEhZIDAg b24gbWlpYnVzMAphdHBoeTA6IE9VSSAweDAwMTM3NCwgbW9kZWwgMHgwMDAxLCByZXYuIDkKYXRw aHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgMTAw MGJhc2VULUZEWCwgYXV0bwphbGUwOiBicGYgYXR0YWNoZWQKYWxlMDogRXRoZXJuZXQgYWRkcmVz czogMDA6MjQ6OGM6NTI6YzA6OGQKYWxlMDogW01QU0FGRV0KYWxlMDogW0ZJTFRFUl0KYXRhcGNp MDogPEFUSSBJWFA3MDAvODAwIFNBVEEzMDAgY29udHJvbGxlcj4gcG9ydCAweGIwMDAtMHhiMDA3 LDB4YTAwMC0weGEwMDMsMHg5MDAwLTB4OTAwNywweDgwMDAtMHg4MDAzLDB4NzAwMC0weDcwMGYg bWVtIDB4ZmJiZmZjMDAtMHhmYmJmZmZmZiBpcnEgMjIgYXQgZGV2aWNlIDE3LjAgb24gcGNpMAph dGFwY2kwOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHg3MDAw CmF0YXBjaTA6IFJlc2VydmVkIDB4NDAwIGJ5dGVzIGZvciByaWQgMHgyNCB0eXBlIDMgYXQgMHhm YmJmZmMwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMiAoUENJIElSUSAyMikgdG8gbGFwaWMg MCB2ZWN0b3IgNTAKYXRhcGNpMDogW01QU0FGRV0KYXRhcGNpMDogW0lUSFJFQURdCmF0YXBjaTA6 IEFIQ0kgdjEuMTAgY29udHJvbGxlciB3aXRoIDYgM0dicHMgcG9ydHMsIFBNIHN1cHBvcnRlZAph dGFwY2kwOiBDYXBzOiA2NGJpdCBOQ1EgU05URiBNUFMgQUxQIEFMIENMTyAzR2JwcyBQTSBQTUQg U1NDIFBTQyAzMmNtZCBDQ0MgNnBvcnRzCmF0YTI6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kw CmF0YTI6IEFIQ0kgcmVzZXQuLi4KYXRhMjogaGFyZHdhcmUgcmVzZXQgLi4uCmF0YTI6IFNBVEEg Y29ubmVjdCB0aW1lb3V0IHN0YXR1cz0wMDAwMDAwMAphdGEyOiBBSENJIHJlc2V0IGRvbmU6IHBo eSByZXNldCBmb3VuZCBubyBkZXZpY2UKYXRhMjogW01QU0FGRV0KYXRhMjogW0lUSFJFQURdCmF0 YTM6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwCmF0YTM6IEFIQ0kgcmVzZXQuLi4KYXRhMzog aGFyZHdhcmUgcmVzZXQgLi4uCmF0YTM6IFNBVEEgY29ubmVjdCB0aW1lb3V0IHN0YXR1cz0wMDAw MDAwMAphdGEzOiBBSENJIHJlc2V0IGRvbmU6IHBoeSByZXNldCBmb3VuZCBubyBkZXZpY2UKYXRh MzogW01QU0FGRV0KYXRhMzogW0lUSFJFQURdCmF0YTQ6IDxBVEEgY2hhbm5lbCAyPiBvbiBhdGFw Y2kwCmF0YTQ6IEFIQ0kgcmVzZXQuLi4KYXRhNDogaGFyZHdhcmUgcmVzZXQgLi4uCmF0YTQ6IFNB VEEgY29ubmVjdCB0aW1lb3V0IHN0YXR1cz0wMDAwMDAwMAphdGE0OiBBSENJIHJlc2V0IGRvbmU6 IHBoeSByZXNldCBmb3VuZCBubyBkZXZpY2UKYXRhNDogW01QU0FGRV0KYXRhNDogW0lUSFJFQURd CmF0YTU6IDxBVEEgY2hhbm5lbCAzPiBvbiBhdGFwY2kwCmF0YTU6IEFIQ0kgcmVzZXQuLi4KYXRh NTogaGFyZHdhcmUgcmVzZXQgLi4uCmF0YTU6IFNBVEEgY29ubmVjdCB0aW1lb3V0IHN0YXR1cz0w MDAwMDAwMAphdGE1OiBBSENJIHJlc2V0IGRvbmU6IHBoeSByZXNldCBmb3VuZCBubyBkZXZpY2UK YXRhNTogW01QU0FGRV0KYXRhNTogW0lUSFJFQURdCmF0YTY6IDxBVEEgY2hhbm5lbCA0PiBvbiBh dGFwY2kwCmF0YTY6IEFIQ0kgcmVzZXQuLi4KYXRhNjogaGFyZHdhcmUgcmVzZXQgLi4uCmF0YTY6 IFNBVEEgY29ubmVjdCB0aW1lb3V0IHN0YXR1cz0wMDAwMDAwMAphdGE2OiBBSENJIHJlc2V0IGRv bmU6IHBoeSByZXNldCBmb3VuZCBubyBkZXZpY2UKYXRhNjogW01QU0FGRV0KYXRhNjogW0lUSFJF QURdCmF0YTc6IDxBVEEgY2hhbm5lbCA1PiBvbiBhdGFwY2kwCmF0YTc6IEFIQ0kgcmVzZXQuLi4K YXRhNzogaGFyZHdhcmUgcmVzZXQgLi4uCmF0YTc6IFNBVEEgY29ubmVjdCB0aW1lb3V0IHN0YXR1 cz0wMDAwMDAwMAphdGE3OiBBSENJIHJlc2V0IGRvbmU6IHBoeSByZXNldCBmb3VuZCBubyBkZXZp Y2UKYXRhNzogW01QU0FGRV0KYXRhNzogW0lUSFJFQURdCm9oY2kwOiA8T0hDSSAoZ2VuZXJpYykg VVNCIGNvbnRyb2xsZXI+IG1lbSAweGZiYmZkMDAwLTB4ZmJiZmRmZmYgaXJxIDE2IGF0IGRldmlj ZSAxOC4wIG9uIHBjaTAKb2hjaTA6IFJlc2VydmVkIDB4MTAwMCBieXRlcyBmb3IgcmlkIDB4MTAg dHlwZSAzIGF0IDB4ZmJiZmQwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTYgKFBDSSBJUlEg MTYpIHRvIGxhcGljIDAgdmVjdG9yIDUxCm9oY2kwOiBbTVBTQUZFXQpvaGNpMDogW0lUSFJFQURd CnVzYnVzMDogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiBvaGNpMApvaGNpMTog PE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBtZW0gMHhmYmJmZTAwMC0weGZiYmZlZmZm IGlycSAxNiBhdCBkZXZpY2UgMTguMSBvbiBwY2kwCm9oY2kxOiBSZXNlcnZlZCAweDEwMDAgYnl0 ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGZiYmZlMDAwCm9oY2kxOiBbTVBTQUZFXQpvaGNp MTogW0lUSFJFQURdCnVzYnVzMTogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiBv aGNpMQplaGNpMDogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZmJi ZmY4MDAtMHhmYmJmZjhmZiBpcnEgMTcgYXQgZGV2aWNlIDE4LjIgb24gcGNpMAplaGNpMDogUmVz ZXJ2ZWQgMHgxMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGZiYmZmODAwCmlvYXBp YzA6IHJvdXRpbmcgaW50cGluIDE3IChQQ0kgSVJRIDE3KSB0byBsYXBpYyAwIHZlY3RvciA1Mgpl aGNpMDogW01QU0FGRV0KZWhjaTA6IFtJVEhSRUFEXQp1c2J1czI6IHdhaXRpbmcgZm9yIEJJT1Mg dG8gZ2l2ZSB1cCBjb250cm9sCmVoY2kwOiBBTUQgU0I2MDAvNzAwIHF1aXJrIGFwcGxpZWQKdXNi dXMyOiBFSENJIHZlcnNpb24gMS4wCnVzYnVzMjogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29u dHJvbGxlcj4gb24gZWhjaTAKb2hjaTI6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4g bWVtIDB4ZmJiZmIwMDAtMHhmYmJmYmZmZiBpcnEgMTggYXQgZGV2aWNlIDE5LjAgb24gcGNpMApv aGNpMjogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhmYmJm YjAwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxOCAoUENJIElSUSAxOCkgdG8gbGFwaWMgMCB2 ZWN0b3IgNTMKb2hjaTI6IFtNUFNBRkVdCm9oY2kyOiBbSVRIUkVBRF0KdXNidXMzOiA8T0hDSSAo Z2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kyCm9oY2kzOiA8T0hDSSAoZ2VuZXJpYykg VVNCIGNvbnRyb2xsZXI+IG1lbSAweGZiYmZjMDAwLTB4ZmJiZmNmZmYgaXJxIDE4IGF0IGRldmlj ZSAxOS4xIG9uIHBjaTAKb2hjaTM6IFJlc2VydmVkIDB4MTAwMCBieXRlcyBmb3IgcmlkIDB4MTAg dHlwZSAzIGF0IDB4ZmJiZmMwMDAKb2hjaTM6IFtNUFNBRkVdCm9oY2kzOiBbSVRIUkVBRF0KdXNi dXM0OiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kzCmVoY2kxOiA8RUhD SSAoZ2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhmYmJmZjQwMC0weGZiYmZmNGZm IGlycSAxOSBhdCBkZXZpY2UgMTkuMiBvbiBwY2kwCmVoY2kxOiBSZXNlcnZlZCAweDEwMCBieXRl cyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZmJiZmY0MDAKaW9hcGljMDogcm91dGluZyBpbnRw aW4gMTkgKFBDSSBJUlEgMTkpIHRvIGxhcGljIDAgdmVjdG9yIDU0CmVoY2kxOiBbTVBTQUZFXQpl aGNpMTogW0lUSFJFQURdCnVzYnVzNTogd2FpdGluZyBmb3IgQklPUyB0byBnaXZlIHVwIGNvbnRy b2wKZWhjaTE6IEFNRCBTQjYwMC83MDAgcXVpcmsgYXBwbGllZAp1c2J1czU6IEVIQ0kgdmVyc2lv biAxLjAKdXNidXM1OiA8RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNp MQpwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAyMC4wIChubyBkcml2ZXIgYXR0 YWNoZWQpCmF0YXBjaTE6IDxBVEkgSVhQNzAwLzgwMCBVRE1BMTMzIGNvbnRyb2xsZXI+IHBvcnQg MHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHhmZjAwLTB4ZmYwZiBhdCBkZXZp Y2UgMjAuMSBvbiBwY2kwCmF0YXBjaTE6IFJlc2VydmVkIDB4MTAgYnl0ZXMgZm9yIHJpZCAweDIw IHR5cGUgNCBhdCAweGZmMDAKYXRhcGNpMTogU0FUQSBjb250cm9sbGVyIGVuYWJsZWQgKHNlY29u ZGFyeSBjaGFubmVsKQphdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMQphdGFwY2kxOiBS ZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDFmMAphdGFwY2kxOiBS ZXNlcnZlZCAweDEgYnl0ZXMgZm9yIHJpZCAweDE0IHR5cGUgNCBhdCAweDNmNgphdGEwOiByZXNl dCB0cDEgbWFzaz0wMyBvc3RhdDA9N2Ygb3N0YXQxPTdmCmF0YTA6IHN0YXQwPTB4N2YgZXJyPTB4 N2YgbHNiPTB4N2YgbXNiPTB4N2YKYXRhMDogc3RhdDA9MHg3ZiBlcnI9MHg3ZiBsc2I9MHg3ZiBt c2I9MHg3ZgphdGEwOiBzdGF0MD0weDdmIGVycj0weDdmIGxzYj0weDdmIG1zYj0weDdmCmF0YTA6 IHN0YXQwPTB4N2YgZXJyPTB4N2YgbHNiPTB4N2YgbXNiPTB4N2YKYXRhMDogc3RhdDA9MHg3ZiBl cnI9MHg3ZiBsc2I9MHg3ZiBtc2I9MHg3ZgphdGEwOiBzdGF0MD0weDdmIGVycj0weDdmIGxzYj0w eDdmIG1zYj0weDdmCmF0YTA6IHN0YXQwPTB4N2YgZXJyPTB4N2YgbHNiPTB4N2YgbXNiPTB4N2YK YXRhMDogc3RhdDA9MHg3ZiBlcnI9MHg3ZiBsc2I9MHg3ZiBtc2I9MHg3ZgphdGEwOiBzdGF0MD0w eDdmIGVycj0weDdmIGxzYj0weDdmIG1zYj0weDdmCmF0YTA6IHN0YXQwPTB4N2YgZXJyPTB4N2Yg bHNiPTB4N2YgbXNiPTB4N2YKYXRhMDogc3RhdDA9MHg3ZiBlcnI9MHg3ZiBsc2I9MHg3ZiBtc2I9 MHg3ZgphdGEwOiBzdGF0MD0weDdmIGVycj0weDdmIGxzYj0weDdmIG1zYj0weDdmCmF0YTA6IHN0 YXQxPTB4N2YgZXJyPTB4N2YgbHNiPTB4N2YgbXNiPTB4N2YKYXRhMDogcmVzZXQgdHAyIHN0YXQw PWZmIHN0YXQxPWZmIGRldmljZXM9MHgwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE0IChJU0Eg SVJRIDE0KSB0byBsYXBpYyAwIHZlY3RvciA1NQphdGEwOiBbTVBTQUZFXQphdGEwOiBbSVRIUkVB RF0KcGNpMDogPG11bHRpbWVkaWEsIEhEQT4gYXQgZGV2aWNlIDIwLjIgKG5vIGRyaXZlciBhdHRh Y2hlZCkKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDIwLjMgb24gcGNpMAppc2Ew OiA8SVNBIGJ1cz4gb24gaXNhYjAKcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZp Y2UgMjAuNCBvbiBwY2kwCnBjaWIzOiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjM6ICAgc2Vj b25kYXJ5IGJ1cyAgICAgMwpwY2liMzogICBzdWJvcmRpbmF0ZSBidXMgICAzCnBjaWIzOiAgIEkv TyBkZWNvZGUgICAgICAgIDB4ZTAwMC0weGVmZmYKcGNpYjM6ICAgbWVtb3J5IGRlY29kZSAgICAg MHhmYmYwMDAwMC0weGZiZmZmZmZmCnBjaWIzOiAgIG5vIHByZWZldGNoZWQgZGVjb2RlCnBjaWIz OiAgIFN1YnRyYWN0aXZlbHkgZGVjb2RlZCBicmlkZ2UuCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWIzCnBjaTM6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9Mwpmb3VuZC0+CXZlbmRvcj0weDEw ZWMsIGRldj0weDgxNjksIHJldmlkPTB4MTAKCWRvbWFpbj0wLCBidXM9Mywgc2xvdD02LCBmdW5j PTAKCWNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMTcs IHN0YXRyZWc9MHgwMmIwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5 MjAgbnMpLCBtaW5nbnQ9MHgyMCAoODAwMCBucyksIG1heGxhdD0weDQwICgxNjAwMCBucykKCWlu dHBpbj1hLCBpcnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVu dCBEMAoJbWFwWzEwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhlODAwLCBzaXpl ICA4LCBlbmFibGVkCnBjaWIzOiByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4ZTgwMC0weGU4ZmY6IGlu IHJhbmdlCgltYXBbMTRdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmYmZmZmMwMCwg c2l6ZSAgOCwgZW5hYmxlZApwY2liMzogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGZiZmZmYzAw LTB4ZmJmZmZjZmY6IGdvb2QKcGNpYjM6IG1hdGNoZWQgZW50cnkgZm9yIDMuNi5JTlRBCnBjaWIz OiBzbG90IDYgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDIxCnJlMDogPFJlYWxUZWsgODE2OS84MTY5 Uy84MTY5U0IoTCkvODExMFMvODExMFNCKEwpIEdpZ2FiaXQgRXRoZXJuZXQ+IHBvcnQgMHhlODAw LTB4ZThmZiBtZW0gMHhmYmZmZmMwMC0weGZiZmZmY2ZmIGlycSAyMSBhdCBkZXZpY2UgNi4wIG9u IHBjaTMKcmUwOiBSZXNlcnZlZCAweDEwMCBieXRlcyBmb3IgcmlkIDB4MTQgdHlwZSAzIGF0IDB4 ZmJmZmZjMDAKcmUwOiBDaGlwIHJldi4gMHgwNDAwMDAwMApyZTA6IE1BQyByZXYuIDB4MDAwMDAw MDAKbWlpYnVzMTogPE1JSSBidXM+IG9uIHJlMApyZ2VwaHkwOiA8UlRMODE2OVMvODExMFMvODIx MUIgbWVkaWEgaW50ZXJmYWNlPiBQSFkgMSBvbiBtaWlidXMxCnJnZXBoeTA6ICAxMGJhc2VULCAx MGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFzZVQsIDEwMDBiYXNl VC1GRFgsIGF1dG8KcmUwOiBicGYgYXR0YWNoZWQKcmUwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDox NjowMTo1YzphMDpjMgppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMSAoUENJIElSUSAyMSkgdG8g bGFwaWMgMCB2ZWN0b3IgNTYKcmUwOiBbTVBTQUZFXQpyZTA6IFtGSUxURVJdCm9oY2k0OiA8T0hD SSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGZiYmZhMDAwLTB4ZmJiZmFmZmYgaXJx IDE4IGF0IGRldmljZSAyMC41IG9uIHBjaTAKb2hjaTQ6IFJlc2VydmVkIDB4MTAwMCBieXRlcyBm b3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZmJiZmEwMDAKb2hjaTQ6IFtNUFNBRkVdCm9oY2k0OiBb SVRIUkVBRF0KdXNidXM2OiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2k0 CmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKYXRydGMwOiA8QVQgcmVhbHRp bWUgY2xvY2s+IHBvcnQgMHg3MC0weDcxIGlycSA4IG9uIGFjcGkwCmF0cnRjMDogcmVnaXN0ZXJl ZCBhcyBhIHRpbWUtb2YtZGF5IGNsb2NrIChyZXNvbHV0aW9uIDEwMDAwMDB1cykKdWFydDA6IDwx NjU1MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24g YWNwaTAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gNCAoSVNBIElSUSA0KSB0byBsYXBpYyAwIHZl Y3RvciA1Nwp1YXJ0MDogW0ZJTFRFUl0KdWFydDA6IGZhc3QgaW50ZXJydXB0CkFDUEkgV2Fybmlu ZyBmb3IgXFxfU0JfLlBDSTAuU0JSRy5GRENfLl9GREU6IFJldHVybiB0eXBlIG1pc21hdGNoIC0g Zm91bmQgUGFja2FnZSwgZXhwZWN0ZWQgQnVmZmVyICgyMDA5MDkwMy9uc3ByZWRlZi0xMTQzKQpm ZGMwOiA8ZmxvcHB5IGRyaXZlIGNvbnRyb2xsZXIgKEZERSk+IHBvcnQgMHgzZjAtMHgzZjUsMHgz ZjcgaXJxIDYgZHJxIDIgb24gYWNwaTAKZmRjMDogaWNfdHlwZSA5MCBwYXJ0X2lkIDgwCmlvYXBp YzA6IHJvdXRpbmcgaW50cGluIDYgKElTQSBJUlEgNikgdG8gbGFwaWMgMCB2ZWN0b3IgNTgKZmRj MDogW0ZJTFRFUl0KYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAw eDYwLDB4NjQgaXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0 a2JkYzAKYXRrYmQ6IHRoZSBjdXJyZW50IGtiZCBjb250cm9sbGVyIGNvbW1hbmQgYnl0ZSAwMDY1 CmF0a2JkOiBrZXlib2FyZCBJRCAweDQxYWIgKDIpCkNhbGxpbmcgaW50IDB4MTUgKGF4PTB4YzAw MCBieD0weDAwMDAgY3g9MHgwMDAwIGR4PTB4MDAwMCBlcz0weDAwMDAgZGk9MHgwMDAwKQpFeGl0 aW5nIGludCAweDE1IChheD0weDAwMDAgYng9MHhlNzEyIGN4PTB4MDAwMCBkeD0weDAwMDAgZXM9 MHhmMDAwIGRpPTB4MDAwMCkKa2JkMCBhdCBhdGtiZDAKa2JkMDogYXRrYmQwLCBBVCAxMDEvMTAy ICgyKSwgY29uZmlnOjB4MCwgZmxhZ3M6MHgzZDAwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4g MSAoSVNBIElSUSAxKSB0byBsYXBpYyAwIHZlY3RvciA1OQphdGtiZDA6IFtHSUFOVC1MT0NLRURd CmF0a2JkMDogW0lUSFJFQURdCnBzbTA6IHVuYWJsZSB0byBhbGxvY2F0ZSBJUlEKY3B1MDogPEFD UEkgQ1BVPiBvbiBhY3BpMApjcHUwOiBzd2l0Y2hpbmcgdG8gZ2VuZXJpYyBDeCBtb2RlCmFjcGlf dGhyb3R0bGUwOiA8QUNQSSBDUFUgVGhyb3R0bGluZz4gb24gY3B1MAphY3BpX3Rocm90dGxlMDog UF9DTlQgZnJvbSBQX0JMSyAweDgxMApod3BzdGF0ZTA6IDxDb29sYG4nUXVpZXQgMi4wPiBvbiBj cHUwCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MjogPEFDUEkgQ1BVPiBvbiBhY3BpMApj cHUzOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmFoY19pc2FfcHJvYmUgMDogaW9wb3J0IDB4YzAwIGFs bG9jIGZhaWxlZAphaGNfaXNhX3Byb2JlIDEzOiBpb3BvcnQgMHhkYzAwIGFsbG9jIGZhaWxlZApw bnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMjAzCnBucF9pZGVudGlmeTogVHJ5aW5n IFJlYWRfUG9ydCBhdCAyNDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDI4Mwpw bnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMmMzCnBucF9pZGVudGlmeTogVHJ5aW5n IFJlYWRfUG9ydCBhdCAzMDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDM0Mwpw bnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzgzCnBucF9pZGVudGlmeTogVHJ5aW5n IFJlYWRfUG9ydCBhdCAzYzMKUE5QIElkZW50aWZ5IGNvbXBsZXRlCmV4X2lzYV9pZGVudGlmeSgp CnVua25vd246IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKdW5rbm93bjogc3RhdHVzIHJlZyB0 ZXN0IGZhaWxlZCBmZgp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCnVua25vd246 IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKaXNhX3Byb2JlX2NoaWxkcmVuOiBkaXNhYmxpbmcg UG5QIGRldmljZXMKcG10aW1lcjAgb24gaXNhMAphdGE6IGF0YTAgYWxyZWFkeSBleGlzdHM7IHNr aXBwaW5nIGl0CmF0a2JkYzogYXRrYmRjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKYXRy dGM6IGF0cnRjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKZmRjOiBmZGMwIGFscmVhZHkg ZXhpc3RzOyBza2lwcGluZyBpdApzYzogc2MwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAp1 YXJ0OiB1YXJ0MCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKaXNhX3Byb2JlX2NoaWxkcmVu OiBwcm9iaW5nIG5vbi1QblAgZGV2aWNlcwpzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3Mg MHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+ CnNjMDogZmIwLCBrYmQxLCB0ZXJtaW5hbCBlbXVsYXRvcjogc2N0ZWtlbiAodGVrZW4gdGVybWlu YWwpCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhh MDAwMC0weGJmZmZmIG9uIGlzYTAKYXRhMSBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDE3MCBp cnEgMTUgb24gaXNhMApwcGMwOiBwYXJhbGxlbCBwb3J0IG5vdCBmb3VuZC4KcHBjMDogPFBhcmFs bGVsIHBvcnQ+IGZhaWxlZCB0byBwcm9iZSBhdCBpcnEgNyBvbiBpc2EwCnVhcnQxOiA8bnM4MjUw PiBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDJmOC0weDJmZiBpcnEgMyBvbiBpc2EwCmlzYV9w cm9iZV9jaGlsZHJlbjogcHJvYmluZyBQblAgZGV2aWNlcwpEZXZpY2UgY29uZmlndXJhdGlvbiBm aW5pc2hlZC4KUmVkdWNpbmcga2Vybi5tYXh2bm9kZXMgMjE0MzAxIC0+IDEwMDAwMApwcm9jZnMg cmVnaXN0ZXJlZApsYXBpYzogRGl2aXNvciAyLCBGcmVxdWVuY3kgMTAwMzM4OTU1IGh6ClRpbWVj b3VudGVyICJUU0MiIGZyZXF1ZW5jeSAzNDExNTI0MTkwIEh6IHF1YWxpdHkgLTEwMApUaW1lY291 bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjCmxvMDogYnBmIGF0dGFjaGVkCmhwdHJyOiBubyBj b250cm9sbGVyIGRldGVjdGVkLgphdGEwOiBJZGVudGlmeWluZyBkZXZpY2VzOiAwMDAwMDAwMAph dGEwOiBOZXcgZGV2aWNlczogMDAwMDAwMDAKYXRhMjogSWRlbnRpZnlpbmcgZGV2aWNlczogMDAw MDAwMDAKYXRhMjogTmV3IGRldmljZXM6IDAwMDAwMDAwCmF0YTM6IElkZW50aWZ5aW5nIGRldmlj ZXM6IDAwMDAwMDAwCmF0YTM6IE5ldyBkZXZpY2VzOiAwMDAwMDAwMAphdGE0OiBJZGVudGlmeWlu ZyBkZXZpY2VzOiAwMDAwMDAwMAphdGE0OiBOZXcgZGV2aWNlczogMDAwMDAwMDAKYXRhNTogSWRl bnRpZnlpbmcgZGV2aWNlczogMDAwMDAwMDAKYXRhNTogTmV3IGRldmljZXM6IDAwMDAwMDAwCmF0 YTY6IElkZW50aWZ5aW5nIGRldmljZXM6IDAwMDAwMDAwCmF0YTY6IE5ldyBkZXZpY2VzOiAwMDAw MDAwMAphdGE3OiBJZGVudGlmeWluZyBkZXZpY2VzOiAwMDAwMDAwMAphdGE3OiBOZXcgZGV2aWNl czogMDAwMDAwMDAKdXNidXMwOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czE6IDEy TWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzMjogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2 Mi4wCnVzYnVzMzogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXM0OiAxMk1icHMgRnVs bCBTcGVlZCBVU0IgdjEuMAp1c2J1czU6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1c2J1 czY6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVnZW4wLjE6IDxBVEk+IGF0IHVzYnVzMAp1 aHViMDogPEFUSSBPSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIg MT4gb24gdXNidXMwCnVnZW4xLjE6IDxBVEk+IGF0IHVzYnVzMQp1aHViMTogPEFUSSBPSENJIHJv b3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMxCnVnZW4y LjE6IDxBVEk+IGF0IHVzYnVzMgp1aHViMjogPEFUSSBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAs IHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMyCnVnZW4zLjE6IDxBVEk+IGF0IHVzYnVz Mwp1aHViMzogPEFUSSBPSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFk ZHIgMT4gb24gdXNidXMzCnVnZW40LjE6IDxBVEk+IGF0IHVzYnVzNAp1aHViNDogPEFUSSBPSENJ IHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM0CnVn ZW41LjE6IDxBVEk+IGF0IHVzYnVzNQp1aHViNTogPEFUSSBFSENJIHJvb3QgSFVCLCBjbGFzcyA5 LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM1CnVnZW42LjE6IDxBVEk+IGF0IHVz YnVzNgp1aHViNjogPEFUSSBPSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAs IGFkZHIgMT4gb24gdXNidXM2CmZkYzA6IG91dHB1dCByZWFkeSB0aW1lb3V0CmZkYzA6IG91dHB1 dCByZWFkeSB0aW1lb3V0CnVodWI2OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93 ZXJlZAp1aHViMDogMyBwb3J0cyB3aXRoIDMgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjE6 IDMgcG9ydHMgd2l0aCAzIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWIzOiAzIHBvcnRzIHdp dGggMyByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViNDogMyBwb3J0cyB3aXRoIDMgcmVtb3Zh YmxlLCBzZWxmIHBvd2VyZWQKZmRjMDogb3V0cHV0IHJlYWR5IHRpbWVvdXQKZmRjMDogb3V0cHV0 IHJlYWR5IHRpbWVvdXQKZmRjMDogb3V0cHV0IHJlYWR5IHRpbWVvdXQKZmRjMDogb3V0cHV0IHJl YWR5IHRpbWVvdXQKZmRjMDogb3V0cHV0IHJlYWR5IHRpbWVvdXQKQVRBIFBzZXVkb1JBSUQgbG9h ZGVkClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQpjcHUxIEFQOgogICAgIElEOiAweDAxMDAwMDAw ICAgVkVSOiAweDgwMDUwMDEwIExEUjogMHgwMDAwMDAwMCBERlI6IDB4ZmZmZmZmZmYKICBsaW50 MDogMHgwMDAxMDcwMCBsaW50MTogMHgwMDAwMDQwMCBUUFI6IDB4MDAwMDAwMDAgU1ZSOiAweDAw MDAwMWZmCiAgdGltZXI6IDB4MDAwMjAwZWYgdGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAwMDEw MDAwIHBjbTogMHgwMDAxMDQwMApTTVA6IEFQIENQVSAjMiBMYXVuY2hlZCEKY3B1MiBBUDoKICAg ICBJRDogMHgwMjAwMDAwMCAgIFZFUjogMHg4MDA1MDAxMCBMRFI6IDB4MDAwMDAwMDAgREZSOiAw eGZmZmZmZmZmCiAgbGludDA6IDB4MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAw MDAwMDAwIFNWUjogMHgwMDAwMDFmZgogIHRpbWVyOiAweDAwMDIwMGVmIHRoZXJtOiAweDAwMDEw MDAwIGVycjogMHgwMDAxMDAwMCBwY206IDB4MDAwMTA0MDAKU01QOiBBUCBDUFUgIzMgTGF1bmNo ZWQhCmNwdTMgQVA6CiAgICAgSUQ6IDB4MDMwMDAwMDAgICBWRVI6IDB4ODAwNTAwMTAgTERSOiAw eDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZgogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAw MDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAyMDBl ZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4MDAwMTAwMDAgcGNtOiAweDAwMDEwNDAwCmlvYXBp YzA6IHJvdXRpbmcgaW50cGluIDQgKElTQSBJUlEgNCkgdG8gbGFwaWMgMSB2ZWN0b3IgNDgKaW9h cGljMDogcm91dGluZyBpbnRwaW4gNiAoSVNBIElSUSA2KSB0byBsYXBpYyAyIHZlY3RvciA0OApp b2FwaWMwOiByb3V0aW5nIGludHBpbiA5IChJU0EgSVJRIDkpIHRvIGxhcGljIDMgdmVjdG9yIDQ4 CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE2IChQQ0kgSVJRIDE2KSB0byBsYXBpYyAxIHZlY3Rv ciA0OQppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxNyAoUENJIElSUSAxNykgdG8gbGFwaWMgMiB2 ZWN0b3IgNDkKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTggKFBDSSBJUlEgMTgpIHRvIGxhcGlj IDMgdmVjdG9yIDQ5CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIxIChQQ0kgSVJRIDIxKSB0byBs YXBpYyAxIHZlY3RvciA1MAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMiAoUENJIElSUSAyMikg dG8gbGFwaWMgMiB2ZWN0b3IgNTAKbXNpOiBBc3NpZ25pbmcgTVNJIElSUSAyNTYgdG8gbG9jYWwg QVBJQyAzIHZlY3RvciA1MApXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3Qg cmVkdWNlZCBwZXJmb3JtYW5jZS4KUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM1IHVzYnVz MgpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czUgdXNidXMyCmZkYzA6IG91dHB1dCByZWFk eSB0aW1lb3V0CmZkYzA6IGlucHV0IHJlYWR5IHRpbWVvdXQKZmRjMDogb3V0cHV0IHJlYWR5IHRp bWVvdXQKZmRjMDogaW5wdXQgcmVhZHkgdGltZW91dApmZGMwOiBvdXRwdXQgcmVhZHkgdGltZW91 dAp1aHViMjogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjU6IDYg cG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCmZkYzA6IGlucHV0IHJlYWR5IHRp bWVvdXQKZmRjMDogb3V0cHV0IHJlYWR5IHRpbWVvdXQKZmRjMDogaW5wdXQgcmVhZHkgdGltZW91 dAp1Z2VuMi4yOiA8c2lsaWNvbj4gYXQgdXNidXMyCnVtYXNzMDogPHNpbGljb24gLXBvd2VyLCBj bGFzcyAwLzAsIHJldiAyLjAwLzEuMTAsIGFkZHIgMj4gb24gdXNidXMyCnVtYXNzMDogIFNDU0kg b3ZlciBCdWxrLU9ubHk7IHF1aXJrcyA9IDB4MDAwMApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1 c2J1czIKdW1hc3MwOjA6MDotMTogQXR0YWNoZWQgdG8gc2NidXMwClRyeWluZyB0byBtb3VudCBy b290IGZyb20gdWZzOi9kZXYvZGEwczFhClJPT1QgTU9VTlQgRVJST1I6IApJZiB5b3UgaGF2ZSBp bnZhbGlkIG1vdW50IG9wdGlvbnMsIHJlYm9vdCwgYW5kIGZpcnN0IHRyeSB0aGUgZm9sbG93aW5n IGZyb20KdGhlIGxvYWRlciBwcm9tcHQ6CgogICAgIHNldCB2ZnMucm9vdC5tb3VudGZyb20ub3B0 aW9ucz1ydwoKYW5kIHRoZW4gcmVtb3ZlIGludmFsaWQgbW91bnQgb3B0aW9ucyBmcm9tIC9ldGMv ZnN0YWIuCgpMb2FkZXIgdmFyaWFibGVzOgp2ZnMucm9vdC5tb3VudGZyb209dWZzOi9kZXYvZGEw czFhCnZmcy5yb290Lm1vdW50ZnJvbS5vcHRpb25zPXJ3CgpNYW51YWwgcm9vdCBmaWxlc3lzdGVt IHNwZWNpZmljYXRpb246CiAgPGZzdHlwZT46PGRldmljZT4gIE1vdW50IDxkZXZpY2U+IHVzaW5n IGZpbGVzeXN0ZW0gPGZzdHlwZT4KICAgICAgICAgICAgICAgICAgICAgICBlZy4gdWZzOi9kZXYv ZGEwczFhCiAgICAgICAgICAgICAgICAgICAgICAgZWcuIGNkOTY2MDovZGV2L2FjZDAKICAgICAg ICAgICAgICAgICAgICAgICBUaGlzIGlzIGVxdWl2YWxlbnQgdG86IG1vdW50IC10IGNkOTY2MCAv ZGV2L2FjZDAgLwoKICA/ICAgICAgICAgICAgICAgICAgTGlzdCB2YWxpZCBkaXNrIGJvb3QgZGV2 aWNlcwogIDxlbXB0eSBsaW5lPiAgICAgICBBYm9ydCBtYW51YWwgaW5wdXQKCm1vdW50cm9vdD4g KHByb2JlMDp1bWFzcy1zaW0wOjA6MDowKTogRG93biByZXZpbmcgUHJvdG9jb2wgVmVyc2lvbiBm cm9tIDIgdG8gMD8KR0VPTTogbmV3IGRpc2sgZGEwcGFzczAgYXQgdW1hc3Mtc2ltMCBidXMgMCBz Y2J1czAgdGFyZ2V0IDAgbHVuIDAKCnBhc3MwOiA8c2lsaWNvbiAtcG93ZXIgMC4wMD4gUmVtb3Zh YmxlIERpcmVjdCBBY2Nlc3MgU0NTSS0wIGRldmljZSAKcGFzczA6IFNlcmlhbCBOdW1iZXIgRTY4 ODE2MDAzQTEzCnBhc3MwOiA0MC4wMDBNQi9zIHRyYW5zZmVycwpkYTAgYXQgdW1hc3Mtc2ltMCBi dXMgMCBzY2J1czAgdGFyZ2V0IDAgbHVuIDAKZGEwOiA8c2lsaWNvbiAtcG93ZXIgMC4wMD4gUmVt b3ZhYmxlIERpcmVjdCBBY2Nlc3MgU0NTSS0wIGRldmljZSAKZGEwOiBTZXJpYWwgTnVtYmVyIEU2 ODgxNjAwM0ExMwpkYTA6IDQwLjAwME1CL3MgdHJhbnNmZXJzCmRhMDogNzY0NE1CICgxNTY1NDkx MiA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDk3NEMpCnVmczovZGV2L2RhMHMxYQpUcnlp bmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2RhMHMxYQpjdF90b190cyhbMjAwOS0xMC0w NSAyMDo1MDowOF0pID0gMTI1NDc3NTgwOC4wMDAwMDAwMDAKc3RhcnRfaW5pdDogdHJ5aW5nIC9z YmluL2luaXQK --------_4ACB35D7000000000694_MULTIPART_MIXED_-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 12:37:21 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48136106568D; Tue, 6 Oct 2009 12:37:21 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0C8778FC12; Tue, 6 Oct 2009 12:37:21 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:517e:fefd:3695:676c] (unknown [IPv6:2001:7b8:3a7:0:517e:fefd:3695:676c]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 40E575C59; Tue, 6 Oct 2009 14:37:20 +0200 (CEST) Message-ID: <4ACB3A08.9030109@andric.com> Date: Tue, 06 Oct 2009 14:37:28 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.4pre) Gecko/20091003 Shredder/3.0pre MIME-Version: 1.0 To: Hiroki Sato References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <4ACA4B81.3090105@andric.com> In-Reply-To: <4ACA4B81.3090105@andric.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-rc@FreeBSD.org Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 12:37:21 -0000 On 2009-10-05 21:39, Dimitry Andric wrote: >> http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff > Hmm, build bombs out at sbin/ifconfig: ... > This is because the patch doesn't seem to contain > sbin/ifconfig/af_nd6.c. Can I just use the version from head? FYI, the patch also misses etc/rc.d/{faith,stf}. Without these, mergemaster fails; again, taking them from head fixes it. From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 13:22:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E71101065672 for ; Tue, 6 Oct 2009 13:22:01 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id A0AEF8FC0C for ; Tue, 6 Oct 2009 13:22:01 +0000 (UTC) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1Mv9zM-00058i-6Z; Tue, 06 Oct 2009 17:22:00 +0400 From: Boris Samorodov To: Kostik Belousov References: <78132948@bb.ipt.ru> <20091005190710.GW2259@deviant.kiev.zoral.com.ua> <22767770@bb.ipt.ru> <20091006110359.GH2259@deviant.kiev.zoral.com.ua> Date: Tue, 06 Oct 2009 17:21:59 +0400 In-Reply-To: <20091006110359.GH2259@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Tue, 6 Oct 2009 14:03:59 +0300") Message-ID: <35241576@bb.ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: bz@freebsd.org, freebsd-current@freebsd.org Subject: Re: abort acroread at today's -current, but OK at 03-Oct -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 13:22:02 -0000 On Tue, 6 Oct 2009 14:03:59 +0300 Kostik Belousov wrote: > Do you have amd64 or i386 system ? i386. > Anyway, please try http://people.freebsd.org/~kib/misc/pie.3.patch That did it, thanks! Not only acroread works but even skype (the latter didn't work either but didn't complain as opposed to acroread). -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 15:22:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9E7A1065672 for ; Tue, 6 Oct 2009 15:22:42 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.freebsd.org (Postfix) with ESMTP id 511D78FC14 for ; Tue, 6 Oct 2009 15:22:41 +0000 (UTC) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw1.york.ac.uk (8.13.6/8.13.6) with ESMTP id n96FLlW9021887; Tue, 6 Oct 2009 16:21:57 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MvBmz-0000YA-6C; Tue, 06 Oct 2009 16:17:21 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.3/8.14.3) with ESMTP id n96FHLUp026897; Tue, 6 Oct 2009 16:17:21 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id n96FHKxC026896; Tue, 6 Oct 2009 16:17:20 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Christian Schmidt In-Reply-To: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> References: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 06 Oct 2009 16:17:20 +0100 Message-Id: <1254842240.23831.22.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: freebsd-current@freebsd.org Subject: Re: Boot issues with a Dell Inspiron 530 and 8.0 RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 15:22:42 -0000 On Tue, 2009-10-06 at 09:54 +0200, Christian Schmidt wrote: > Hello list, > > I am seeing a strange issue with my Dell Inspiron 530 with 8.0 RC1-p1 > at around 50-75% percent of all boots. It all boils down to GENERIC > throwing the following: > > AP #1 (PHY #1) failed! > panic y/n? [y] panic: bye-bye > cpuid = 0 If you answer no, does it work? There are a couple of things that might be worth trying. Firstly, try playing with any USB-related options in the BIOS (especially "legacy emulation" or similar. Secondly, try editing src/sys/amd64/amd64/machdep.c (or /sys/i386/i386/machdep.c if you are using i386), search for "MacBook", and adding the output of the command "kenv smbios.system.product" to the list of strings compared. This may not make any difference, or may even make things worse (so keep your backup kernel ready:) but it's worth a try. Gavin From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 16:21:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14615106568F for ; Tue, 6 Oct 2009 16:21:07 +0000 (UTC) (envelope-from dhorn2000@gmail.com) Received: from mail-yw0-f204.google.com (mail-yw0-f204.google.com [209.85.211.204]) by mx1.freebsd.org (Postfix) with ESMTP id 510998FC14 for ; Tue, 6 Oct 2009 16:21:06 +0000 (UTC) Received: by ywh42 with SMTP id 42so3732361ywh.28 for ; Tue, 06 Oct 2009 09:21:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dGVFPnc66mWnoCI7HnfG3Ykb7sBDfpkZpLA3MebaMrY=; b=W3tcF4U9OgLjD2COTu60BrKaHknVcybbsOeX5IlcfQVk+CizZcICIRDDNHCMOWbA1x rI6wYRXl41Dbt6KWtSZq5/ZfC0jmp4L2CTgBy61yaDcFfT6IPIoMlrV5YuxyBuLjSEVt kHiXNc/03kWemxWYobjkKTIwxuLGacUnBdn3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QsGKUrKx9lSvAPWjg8pLzouP2Y35GfWsGW+MUoBNL461/rbfahcd+T+a7IgCNG4nsA ysGUNIBp0zk4LavHdKHK6746h8rpajIasU+ja/J+M3Yr4ziZCMOEBT6PovJtQZ8xc8NN A37kmLwEN7ZBPmJuFX58Ai9qCd/mYFibKsvac= MIME-Version: 1.0 Received: by 10.100.24.37 with SMTP id 37mr1744227anx.45.1254846065545; Tue, 06 Oct 2009 09:21:05 -0700 (PDT) In-Reply-To: <4ACB3A08.9030109@andric.com> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <4ACA4B81.3090105@andric.com> <4ACB3A08.9030109@andric.com> Date: Tue, 6 Oct 2009 12:21:05 -0400 Message-ID: <25ff90d60910060921k2118994aq1f5b0431868ec800@mail.gmail.com> From: David Horn To: Hiroki Sato Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-rc@freebsd.org Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 16:21:07 -0000 On Tue, Oct 6, 2009 at 8:37 AM, Dimitry Andric wrote: > On 2009-10-05 21:39, Dimitry Andric wrote: >>> =A0 http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff >> Hmm, build bombs out at sbin/ifconfig: > ... >> This is because the patch doesn't seem to contain >> sbin/ifconfig/af_nd6.c. =A0Can I just use the version from head? > > FYI, the patch also misses etc/rc.d/{faith,stf}. =A0Without these, > mergemaster fails; again, taking them from head fixes it. Hiroki -- I also attempted to use your patch against 8/Stable svn, and wanted to give some feedback. svn add before doing the svn diff will ensure that files you want to add to a patch get noticed. svn diff will only look at files under version control. 1) Patchset is missing examples and defaults for new rc.conf variables to /etc/defaults/rc.conf. (The defaults/rc.conf has been updated in -current, although perhaps once everything settles, it would help to expand the examples in comments) 2) I really like the changes to ifconfig and kernel for exposing per-interface flags for "accept_rtadv" and other ndp flags to ifconfig (and inherently rc.conf). I previously had to do some hackery to disable "accept_rtadv" at boot time for just one interface within rc.conf. 3) I would prefer that ipv6_enable remain a global flag in rc.conf, and NOT be obsoleted. I would also prefer that ipv6_network_interfaces=3D"auto" as in the past by default. Again, I like the logic changes and the flexibility it provides, it is just the default/obsolete that I am interested in changing. 4) Personal opinion time: change the "accept_rtadv" token to "autoconf" in ifconfig and rc.conf, as this it is a better self-description. Just one persons opinion. 5) I noticed in the comments that you are considering allowing autoconf+router in a future advanced configuration. I completely agree with adding this functionality to -current (for ipv6 router cpe needs), we just need a new knob when this gets added. I had code around somewhere at one point. I'll see if I can find it still. There is a PR (conf/121812) on this as well. Given the timing, +1 for letting this bake in -current until after 8.0 release. If you want any early feedback for a future MFC of this code, feel free to email me and I will gladly test the patch. Thanks for the changes. ---Dave H From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 16:27:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FE3C1065679 for ; Tue, 6 Oct 2009 16:27:09 +0000 (UTC) (envelope-from christian@nertenher.de) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id A32538FC12 for ; Tue, 6 Oct 2009 16:27:07 +0000 (UTC) Received: by fxm22 with SMTP id 22so3972860fxm.36 for ; Tue, 06 Oct 2009 09:27:07 -0700 (PDT) MIME-Version: 1.0 Sender: christian@nertenher.de Received: by 10.223.145.129 with SMTP id d1mr499548fav.99.1254846427120; Tue, 06 Oct 2009 09:27:07 -0700 (PDT) In-Reply-To: <1254842240.23831.22.camel@buffy.york.ac.uk> References: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> <1254842240.23831.22.camel@buffy.york.ac.uk> From: Christian Schmidt Date: Tue, 6 Oct 2009 18:26:47 +0200 X-Google-Sender-Auth: 020695417f4b475c Message-ID: <309b65830910060926x5842b05cw976942e76b13cfe9@mail.gmail.com> To: Gavin Atkinson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Boot issues with a Dell Inspiron 530 and 8.0 RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 16:27:09 -0000 On Tue, Oct 6, 2009 at 17:17, Gavin Atkinson wrote: [...] > > If you answer no, does it work? I am not really given the choice here. It's always y. FreeBSD-Devs have a great sense of humor. :-) > There are a couple of things that might be worth trying. =C2=A0Firstly, t= ry > playing with any USB-related options in the BIOS (especially "legacy > emulation" or similar. Alright, I will try that and give some feedback. > Secondly, try editing src/sys/amd64/amd64/machdep.c > (or /sys/i386/i386/machdep.c if you are using i386), search for > "MacBook", and adding the output of the command > "kenv smbios.system.product" > to the list of strings compared. Just for some understanding: what will that exactly do and why "MacBook"? > This may not make any difference, or may even make things worse (so keep > your backup kernel ready:) but it's worth a try. Good to know. :-) Thanks. > Gavin Christian --=20 Todays mistakes are tomorrows catastrophes. From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 17:50:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE7221065693 for ; Tue, 6 Oct 2009 17:50:24 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout6.freenet.de (mout6.freenet.de [IPv6:2001:748:100:40::2:8]) by mx1.freebsd.org (Postfix) with ESMTP id 7822A8FC19 for ; Tue, 6 Oct 2009 17:50:24 +0000 (UTC) Received: from [195.4.92.19] (helo=9.mx.freenet.de) by mout6.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1MvEB4-0007WA-GI; Tue, 06 Oct 2009 19:50:22 +0200 Received: from taa37.t.pppool.de ([89.55.170.55]:43890 helo=ernst.jennejohn.org) by 9.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1MvEB4-00041l-76; Tue, 06 Oct 2009 19:50:22 +0200 Date: Tue, 6 Oct 2009 19:50:21 +0200 From: Gary Jennejohn To: Christian Schmidt Message-ID: <20091006195021.00b828f6@ernst.jennejohn.org> In-Reply-To: <309b65830910060926x5842b05cw976942e76b13cfe9@mail.gmail.com> References: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> <1254842240.23831.22.camel@buffy.york.ac.uk> <309b65830910060926x5842b05cw976942e76b13cfe9@mail.gmail.com> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Boot issues with a Dell Inspiron 530 and 8.0 RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 17:50:25 -0000 On Tue, 6 Oct 2009 18:26:47 +0200 Christian Schmidt wrote: > On Tue, Oct 6, 2009 at 17:17, Gavin Atkinson > > Secondly, try editing src/sys/amd64/amd64/machdep.c > > (or /sys/i386/i386/machdep.c if you are using i386), search for > > "MacBook", and adding the output of the command > > "kenv smbios.system.product" > > to the list of strings compared. > > Just for some understanding: what will that exactly do and why "MacBook"? > MacBook is in a comment near the code you should modifiy. If you were to look at the code you would see that it disables the LEGACY_USB_EN bit on the Intel ICH. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 18:50:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28D73106568D for ; Tue, 6 Oct 2009 18:50:25 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout018.mac.com (asmtpout018.mac.com [17.148.16.93]) by mx1.freebsd.org (Postfix) with ESMTP id 125A78FC16 for ; Tue, 6 Oct 2009 18:50:24 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from cswiger1.apple.com ([17.227.140.124]) by asmtp018.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KR3004PRWBRGK20@asmtp018.mac.com>; Tue, 06 Oct 2009 11:50:20 -0700 (PDT) Message-id: <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> From: Chuck Swiger To: Hans Petter Selasky In-reply-to: <200910021440.50021.hselasky@freebsd.org> Date: Tue, 06 Oct 2009 11:50:14 -0700 References: <200910021440.50021.hselasky@freebsd.org> X-Mailer: Apple Mail (2.936) Cc: arch@freebsd.org, freebsd-current@freebsd.org, Robert Watson Subject: Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 18:50:25 -0000 Hi, Hans-- On Oct 2, 2009, at 5:40 AM, Hans Petter Selasky wrote: > Can the Apple's "Blocks" C language extension be used when > programming in the kernel? Or is this a user-space only feature? While the main benefit of blocks is in conjunction with libdispatch for userland apps, they can be used by themselves, in the kernel or elsewhere. A block is a closure and starts off living on the stack (although, a block can outlive the stack frame of the caller by being copied over to the heap if needed); the compiler wraps automatic variables which were around in the scope of the caller, turns their type into const (unless you explicitly declare that you need to change a variable by using __block storage keyword, in which case that variable is kept on the heap and accessed by reference) in order to preserve the state until the block runs. In effect, blocks are normal function invocations which also have an extra argument which is the context or pointer to the saved environment state. They can be used to implement callbacks and continuations in a clean way, although you do have some overhead with accessing mutable variables via pointer dereference to the struct holding your saved context. However, most uses of callbacks in C are implemented as functions which accept a void *, which is used to feed the callback function a struct * of some sort, so the end result is fairly similar. Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 20:29:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9CD11065672; Tue, 6 Oct 2009 20:29:54 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C15648FC28; Tue, 6 Oct 2009 20:29:54 +0000 (UTC) Received: from [192.168.2.101] (host81-155-13-237.range81-155.btcentralplus.com [81.155.13.237]) by cyrus.watson.org (Postfix) with ESMTPSA id 8AE7C46B35; Tue, 6 Oct 2009 16:29:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: "Robert N. M. Watson" In-Reply-To: <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> Date: Tue, 6 Oct 2009 21:29:50 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <200910021440.50021.hselasky@freebsd.org> <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> To: Chuck Swiger X-Mailer: Apple Mail (2.1076) Cc: arch@freebsd.org, freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 20:29:55 -0000 On 6 Oct 2009, at 19:50, Chuck Swiger wrote: > Hi, Hans-- > > On Oct 2, 2009, at 5:40 AM, Hans Petter Selasky wrote: >> Can the Apple's "Blocks" C language extension be used when >> programming in the kernel? Or is this a user-space only feature? > > While the main benefit of blocks is in conjunction with libdispatch > for userland apps, they can be used by themselves, in the kernel or > elsewhere. When a block is instantiated (perhaps not the formal terminology), the blocks runtime allocates memory to hold copies of relevant variables from the calling scope. This memory allocation may present an issue in some calling contexts in the kernel -- in particular, it won't be appropriate in contexts were non-sleepable locks are held, interrupt threads, etc. While it should be possible to use the primitive in the kernel, we may want to think carefully about these implications. Also, blocks are currently specific to clang, although with any luck gcc will grow them also. Robert > > A block is a closure and starts off living on the stack (although, a > block can outlive the stack frame of the caller by being copied over > to the heap if needed); the compiler wraps automatic variables which > were around in the scope of the caller, turns their type into const > (unless you explicitly declare that you need to change a variable by > using __block storage keyword, in which case that variable is kept > on the heap and accessed by reference) in order to preserve the > state until the block runs. > > In effect, blocks are normal function invocations which also have an > extra argument which is the context or pointer to the saved > environment state. They can be used to implement callbacks and > continuations in a clean way, although you do have some overhead > with accessing mutable variables via pointer dereference to the > struct holding your saved context. However, most uses of callbacks > in C are implemented as functions which accept a void *, which is > used to feed the callback function a struct * of some sort, so the > end result is fairly similar. > > Regards, > -- > -Chuck > From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 20:35:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE0841065692; Tue, 6 Oct 2009 20:35:18 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id AB2EA8FC1C; Tue, 6 Oct 2009 20:35:18 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n96KZIjp026568; Tue, 6 Oct 2009 13:35:18 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n96KZIY3026567; Tue, 6 Oct 2009 13:35:18 -0700 (PDT) (envelope-from sgk) Date: Tue, 6 Oct 2009 13:35:18 -0700 From: Steve Kargl To: "Robert N. M. Watson" Message-ID: <20091006203518.GA26478@troutmask.apl.washington.edu> References: <200910021440.50021.hselasky@freebsd.org> <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org, Hans Petter Selasky , freebsd-current@freebsd.org Subject: Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 20:35:18 -0000 On Tue, Oct 06, 2009 at 09:29:50PM +0100, Robert N. M. Watson wrote: > > On 6 Oct 2009, at 19:50, Chuck Swiger wrote: > > >Hi, Hans-- > > > >On Oct 2, 2009, at 5:40 AM, Hans Petter Selasky wrote: > >>Can the Apple's "Blocks" C language extension be used when > >>programming in the kernel? Or is this a user-space only feature? > > > >While the main benefit of blocks is in conjunction with libdispatch > >for userland apps, they can be used by themselves, in the kernel or > >elsewhere. > > When a block is instantiated (perhaps not the formal terminology), the > blocks runtime allocates memory to hold copies of relevant variables > from the calling scope. This memory allocation may present an issue in > some calling contexts in the kernel -- in particular, it won't be > appropriate in contexts were non-sleepable locks are held, interrupt > threads, etc. While it should be possible to use the primitive in the > kernel, we may want to think carefully about these implications. Also, > blocks are currently specific to clang, although with any luck gcc > will grow them also. > It is unlikely that gcc will grow support for block any time soon. http://gcc.gnu.org/ml/gcc/2009-09/msg00272.html -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 20:42:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6E881065670; Tue, 6 Oct 2009 20:42:09 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5A99D8FC0C; Tue, 6 Oct 2009 20:42:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 06C089CB0CF; Tue, 6 Oct 2009 22:41:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFirOaSXBlXb; Tue, 6 Oct 2009 22:41:52 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id AC59A9CB27B; Tue, 6 Oct 2009 22:41:52 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n96Kfq1B038538; Tue, 6 Oct 2009 22:41:52 +0200 (CEST) (envelope-from rdivacky) Date: Tue, 6 Oct 2009 22:41:52 +0200 From: Roman Divacky To: "Robert N. M. Watson" Message-ID: <20091006204152.GA37998@freebsd.org> References: <200910021440.50021.hselasky@freebsd.org> <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org, Hans Petter Selasky , freebsd-current@freebsd.org Subject: Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 20:42:09 -0000 On Tue, Oct 06, 2009 at 09:29:50PM +0100, Robert N. M. Watson wrote: > > On 6 Oct 2009, at 19:50, Chuck Swiger wrote: > > >Hi, Hans-- > > > >On Oct 2, 2009, at 5:40 AM, Hans Petter Selasky wrote: > >>Can the Apple's "Blocks" C language extension be used when > >>programming in the kernel? Or is this a user-space only feature? > > > >While the main benefit of blocks is in conjunction with libdispatch > >for userland apps, they can be used by themselves, in the kernel or > >elsewhere. > > When a block is instantiated (perhaps not the formal terminology), the > blocks runtime allocates memory to hold copies of relevant variables > from the calling scope. This memory allocation may present an issue in > some calling contexts in the kernel -- in particular, it won't be > appropriate in contexts were non-sleepable locks are held, interrupt > threads, etc. While it should be possible to use the primitive in the > kernel, we may want to think carefully about these implications. Also, > blocks are currently specific to clang, although with any luck gcc > will grow them also. apple-gcc can do blocks iirc not that it matters for us. judging from the discussion on gcc ML they dont like this feature (they prefer C++0x lambdas and the thing from the new C standard iirc) From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 21:10:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00482106568F for ; Tue, 6 Oct 2009 21:10:46 +0000 (UTC) (envelope-from csjp@freebsd.org) Received: from mx-01queue01.mts.net (mx-01queue01.mts.net [142.161.3.10]) by mx1.freebsd.org (Postfix) with ESMTP id BA2768FC24 for ; Tue, 6 Oct 2009 21:10:46 +0000 (UTC) Received: from wnpgmb013qw-sp03.mts.net ([10.205.128.23]) by mx-01mtaout01.mts.net with ESMTP id <20091006205519.JZLH6612.mx-01mtaout01.mts.net@wnpgmb013qw-sp03.mts.net> for ; Tue, 6 Oct 2009 15:55:19 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAA5My0qOoTFx/2dsb2JhbACBUsNQCY58gjMXgWAEgVOCTA X-IronPort-AV: E=Sophos;i="4.44,515,1249275600"; d="scan'208";a="103278005" Received: from wnpgmb1308w-ad04-49-113.dynamic.mts.net (HELO movsx.my.domain) ([142.161.49.113]) by wnpgmb013qw-sp03.mts.net with ESMTP; 06 Oct 2009 15:54:59 -0500 Received: from movsx.my.domain (csjp@localhost [127.0.0.1]) by movsx.my.domain (8.14.3/8.14.3) with ESMTP id n96KsxMv015812; Tue, 6 Oct 2009 20:54:59 GMT (envelope-from csjp@movsx.my.domain) Received: (from csjp@localhost) by movsx.my.domain (8.14.3/8.14.3/Submit) id n96KswBA015811; Tue, 6 Oct 2009 20:54:58 GMT (envelope-from csjp) Date: Tue, 6 Oct 2009 20:54:58 +0000 From: Christian Peron To: Larry Baird Message-ID: <20091006205458.GA15679@movsx> References: <20090921153655.GA37236@gta.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <20090921153655.GA37236@gta.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: XEN 5.5.0 and clflush X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 21:10:47 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This has been fixed. Update your kernel On Mon, Sep 21, 2009 at 11:36:55AM -0400, Larry Baird wrote: > Since the end of August I have been unable to boot a generic kernel from > FreeBSD current or 8 under XEN 5.5.0. Finally had a chance to briefly lo= ok > at the problem. If I apply attached patch to remove calls to clflush() I > am able to boot current. Hopefully somebody can shed some light. Is > XEN incorrecty reporting CPUID_CLFSH or is XEN not correctly virtualizing > this option. Or is the issue someplace else? I have also attached the > dmesg from a successful boot. This issue seems to be same as > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D138863 >=20 >=20 > Here is an attempt to type backtrace from non-booting kernel: > pmap_invalidate_cache_range(c3252000,c3253000,c3253000,0,fee00000,...) at= pamp_invalidate_cache_range+0x60 > pmap_mapdev_attr(fee00000,400,0,c1420d34,c0ba7a72,...) at pmap_mapdev_att= r+0xec > pmap_mapdev() at pmap_mapdev+0x20 > lapic_init() at lapic_init+0x32 > madt_setup_local() at madt_setup_local+0x2c > apic_init() at apic_init+0x11a > mistartup() at mi_startup+0x96 > begin() at begin+0x2c >=20 > Larry >=20 >=20 > --=20 > ------------------------------------------------------------------------ > Larry Baird | http://www.gta.com > Global Technology Associates, Inc. | Orlando, FL > Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-CURRENT #2: Mon Sep 21 11:00:46 EDT 2009 > lab@sw-xenoss.gta.com:/usr/src/sys/i386/compile/GENERIC > WARNING: WITNESS option enabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(R) CPU 5110 @ 1.60GHz (1691.83-MHz 686-cla= ss CPU) > Origin =3D "GenuineIntel" Id =3D 0x6fb Stepping =3D 11 > Features=3D0x789fbff > Features2=3D0x80002201> > AMD Features=3D0x20000000 > AMD Features2=3D0x1 > TSC: P-state invariant > real memory =3D 536870912 (512 MB) > avail memory =3D 493977600 (471 MB) > ACPI APIC Table: > ioapic0: Changing APIC ID to 1 > MADT: Forcing active-low polarity and level trigger for SCI > ioapic0 irqs 0-47 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x1f48-0x1f4b on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on a= cpi0 > Timecounter "HPET" frequency 62500000 Hz quality 900 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > isab0: at device 1.0 on pci0 > isa0: on isab0 > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x17= 7,0x376,0xc220-0xc22f at device 1.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > uhci0: port 0xc200-0xc21f irq 23 a= t device 1.2 on pci0 > uhci0: [ITHREAD] > uhci0: LegSup =3D 0x0000 > usbus0: controller did not stop > usbus0: on uhci0 > pci0: at device 1.3 (no driver attached) > vgapci0: mem 0xf0000000-0xf1ffffff,0xf3000000-0x= f3000fff at device 2.0 on pci0 > pci0: at device 3.0 (no driver attached) > re0: port 0xc100-0xc1ff mem 0xf3001000-0xf3= 0010ff irq 32 at device 4.0 on pci0 > re0: Chip rev. 0x74800000 > re0: MAC rev. 0x00000000 > miibus0: on re0 > rlphy0: PHY 0 on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > re0: Ethernet address: 4e:c4:60:ce:d0:72 > re0: [FILTER] > atrtc0: port 0x70-0x71 irq 8 on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model IntelliMouse Explorer, device ID 4 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acp= i0 > fdc0: does not respond > device_attach: fdc0 attach returned 6 > uart0: port 0x3f8-0x3ff irq 4= flags 0x10 on acpi0 > uart0: [FILTER] > ppc0: port 0x378-0x37f irq 7 on acpi0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppc0: [ITHREAD] > ppbus0: on ppc0 > plip0: on ppbus0 > plip0: [ITHREAD] > lpt0: on ppbus0 > lpt0: [ITHREAD] > lpt0: Interrupt-driven port > ppi0: on ppbus0 > cpu0: on acpi0 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acp= i0 > fdc0: does not respond > device_attach: fdc0 attach returned 6 > pmtimer0 on isa0 > orm0: at iomem 0xd0000-0xd7fff pnpid ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounter "TSC" frequency 1691834274 Hz quality 800 > Timecounters tick every 10.000 msec > usbus0: 12Mbps Full Speed USB v1.0 > ad0: 20480MB at ata0-master WDMA2 > ugen0.1: at usbus0 > uhub0: on usbus0 > GEOM: ad0s1: geometry does not match label (255h,63s !=3D 16h,63s). > uhub0: 2 ports with 2 removable, self powered > ugen0.2: at usbus0 > ums0: on usbus0 > ums0: 3 buttons and [Z] coordinates ID=3D0 > acd0: CDROM at ata1-slave WDMA2 > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from ufs:/dev/ad0s1a > lock order reversal: (sleepable after non-sleepable) > 1st 0xc390a058 rtentry (rtentry) @ net/route.c:1409 > 2nd 0xc0f433b8 ifnet_sx (ifnet_sx) @ netinet/sctp_bsd_addr.c:211 > KDB: stack backtrace: > db_trace_self_wrapper(c0c828bc,d6957788,c08c2725,c08b354b,c0c85715,...) a= t db_trace_self_wrapper+0x26 > kdb_backtrace(c08b354b,c0c85715,c35286e8,c352c8b8,d69577e4,...) at kdb_ba= cktrace+0x29 > _witness_debugger(c0c85715,c0f433b8,c0c8e50e,c352c8b8,c0c9865e,...) at _w= itness_debugger+0x25 > witness_checkorder(c0f433b8,1,c0c98655,d3,0,...) at witness_checkorder+0x= 839 > _sx_slock(c0f433b8,0,c0c98655,d3,d6957878,...) at _sx_slock+0x85 > sctp_init_ifns_for_vrf(3,c39018c0,d69578c0,c08c3178,c3901964,...) at sctp= _init_ifns_for_vrf+0x30 > sctp_addr_change(c38ffa00,1,d69578c0,c08c256c,d695791c,...) at sctp_addr_= change+0x2c > rt_newaddrmsg(1,c38ffa00,0,c390a000,c38ffa00,...) at rt_newaddrmsg+0x3f > rtinit(c38ffa00,1,5,c0de9cfc,51573592,...) at rtinit+0x381 > in_ifinit(0,c0c96ee7,1aa,1a6,c3814800,...) at in_ifinit+0x8f6 > in_control(c38f7000,8040691a,c3907dc0,c3814800,c39018c0,...) at in_contro= l+0xccb > ifioctl(c38f7000,8040691a,c3907dc0,c39018c0,c38ff200,...) at ifioctl+0x14= f0 > soo_ioctl(c385f540,8040691a,c3907dc0,c356e100,c39018c0,...) at soo_ioctl+= 0x415 > kern_ioctl(c39018c0,3,8040691a,c3907dc0,8bc060,...) at kern_ioctl+0x1fd > ioctl(c39018c0,d6957cf8,c,c0c96f81,c0d665c8,...) at ioctl+0x134 > syscall(d6957d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (54, FreeBSD ELF32, ioctl), eip =3D 0x281bf513, esp =3D 0xbfb= fe61c, ebp =3D 0xbfbfe658 --- > _______________________________________________ > 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" --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkrLrqIACgkQzHFpVAM/ozwlFQCfd9F1xpIT5oT3YFgTgFbyu+2Z uVMAn1Oon4TBBvwAqm7qo98z5XKq5SNP =TJ3o -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 22:17:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 979E31065697 for ; Tue, 6 Oct 2009 22:17:26 +0000 (UTC) (envelope-from lists@rhavenn.net) Received: from smtp184.dfw.emailsrvr.com (smtp184.dfw.emailsrvr.com [67.192.241.184]) by mx1.freebsd.org (Postfix) with ESMTP id 76A828FC17 for ; Tue, 6 Oct 2009 22:17:26 +0000 (UTC) Received: from relay8.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay8.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id E21B43FFEE; Tue, 6 Oct 2009 18:17:25 -0400 (EDT) Received: by relay8.relay.dfw.mlsrvr.com (Authenticated sender: rhavenn-AT-rhavenn.net) with ESMTPSA id C32563FFAD; Tue, 6 Oct 2009 18:17:25 -0400 (EDT) Received: by alucard.int.rhavenn.net (Postfix, from userid 1000) id 7AE9D11428D; Tue, 6 Oct 2009 14:17:19 -0800 (AKDT) Date: Tue, 6 Oct 2009 14:17:19 -0800 From: Henrik Hudson To: nocturnal Message-ID: <20091006221719.GA5942@alucard.int.rhavenn.net> References: <9aed80930910051249ocfcf946o2341c653d16b8e24@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9aed80930910051249ocfcf946o2341c653d16b8e24@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: Updating FreeBSD 7.0-RELEASE i386 to 7.2 amd64? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 22:17:26 -0000 On Mon, 05 Oct 2009, nocturnal wrote: > Can it be done with a simple cvs or binary update of FreeBSD or must i > re-install using some media? > > If i kept my /usr partition intact and just overwrote the important stuff > with new files from the CD it wouldn't be so bad with a re-install but it > would be nice if large parts of it could be done remote. > > What is your suggestion for this? You will have to recompile all ports (/usr/local ) and any manually installed apps due to the changes in the system libs. Personally, it's not worth the headache of trying to do a "upgrade" across architectures like this. Most of the items in /usr (outside of /usr/local) are part of the base system and should update "okay", but I don't know if you will be able to boot a x64 kernel into a x86 system, assuming you try a reboot between make installkernel and make installworld . I don't think a binary upgrade would work at all, but I've never actually done a binary upgrade. I always csup. On that note, I've never tried this, but I would recommend against it. Henrik -- Henrik Hudson lists@rhavenn.net ----------------------------------------- "God, root, what is difference?" Pitr; UF From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 22:17:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 967CF106568F for ; Tue, 6 Oct 2009 22:17:32 +0000 (UTC) (envelope-from lab@gta.com) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.20]) by mx1.freebsd.org (Postfix) with SMTP id 58E2A8FC16 for ; Tue, 6 Oct 2009 22:17:32 +0000 (UTC) Received: (qmail 18561 invoked by uid 1000); 6 Oct 2009 22:17:31 -0000 Date: Tue, 6 Oct 2009 18:17:31 -0400 From: Larry Baird To: Christian Peron Message-ID: <20091006221731.GA18178@gta.com> References: <20090921153655.GA37236@gta.com> <20091006205458.GA15679@movsx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091006205458.GA15679@movsx> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: XEN 5.5.0 and clflush X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 22:17:32 -0000 On Tue, Oct 06, 2009 at 08:54:58PM +0000, Christian Peron wrote: > This has been fixed. Update your kernel I have verified I can now boot FreeBSD 9 under Xen. -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 22:55:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6913F1065693; Tue, 6 Oct 2009 22:55:13 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 03F608FC19; Tue, 6 Oct 2009 22:55:12 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAChoy0qDaFvH/2dsb2JhbADUfIQqBIFT X-IronPort-AV: E=Sophos;i="4.44,515,1249272000"; d="scan'208";a="50727866" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 06 Oct 2009 18:55:11 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id E750B1084764; Tue, 6 Oct 2009 18:55:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYKSmOutfkWM; Tue, 6 Oct 2009 18:55:11 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 1D2731084752; Tue, 6 Oct 2009 18:55:11 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n96N1QW26729; Tue, 6 Oct 2009 19:01:26 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 6 Oct 2009 19:01:26 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: John Baldwin In-Reply-To: <200910020824.15488.john@baldwin.cx> Message-ID: References: <4AB27FB6.4010806@eng.auth.gr> <20090921222241.GF1001@rwpc12.mby.riverwillow.net.au> <20091002081319.GN37304@rwpc12.mby.riverwillow.net.au> <200910020824.15488.john@baldwin.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: George Mamalakis , Doug Rabson , freebsd-current@freebsd.org, John Marshall Subject: Re: [PATCH] SASL problems with spnego on 8.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 22:55:13 -0000 On Fri, 2 Oct 2009, John Baldwin wrote: > > Hmmm, I thought that libgssapi was supposed to use dlopen to load the proper > back-end libraries using /etc/gss/mech rather than having applications > directly link against them. > I think the problem is that the global var. defined in -lgssapi doesn't get used by the app. so the .o file in -lgssapi where it's defined doesn't get loaded. (Can't remember the exact name, but it's something like GSS_C_HOST_BASED_NAME.) Then, when -lgssapi-spengo gets loaded, it can't resolve it. (I don't know enough about dynamic linking to know the correct way to fix this. The patch I suggested got it working...) rick From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 23:15:16 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BD08106566B; Tue, 6 Oct 2009 23:15:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id BFEC68FC21; Tue, 6 Oct 2009 23:15:15 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMtsy0qDaFvK/2dsb2JhbADVA4QqBA X-IronPort-AV: E=Sophos;i="4.44,515,1249272000"; d="scan'208";a="49082467" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 06 Oct 2009 19:15:13 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id C3003109C2DA; Tue, 6 Oct 2009 19:15:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faSYLA-3E+fZ; Tue, 6 Oct 2009 19:15:13 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 4B33D109C2E5; Tue, 6 Oct 2009 19:15:13 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n96NLTe00555; Tue, 6 Oct 2009 19:21:29 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 6 Oct 2009 19:21:29 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Robert Watson In-Reply-To: Message-ID: References: <4ABD4BB9.1030804@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@FreeBSD.org, Marcel Moolenaar , "current@freebsd.org mailing list" , Jamie Gritton Subject: Re: 8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS related?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 23:15:16 -0000 On Sun, 27 Sep 2009, Robert Watson wrote: > > On Fri, 25 Sep 2009, Jamie Gritton wrote: > >> It seems to be NFS related. I think the null pointer in question is from >> the export's anonymous credential. Try the patch below and see if it helps >> (which I guess means run it overnight and see if it crashes again). I've >> also patched a similar missing cred prison in GSS_SVC, since I'm not versed >> enough in NFS/RPC stuff to know if it might be the problem. > > This is one of the reasons I really dislike "magic" credentials and special > handling of NULL credentials -- they always get into code the author doesn't > expect, and either there are bad pointer dereferences, or incorrect security > decisions. It's almost always the case that a correct credential should have > been cached or generated at some earlier point to represent the security > context... > I don't really understand prisons/jails, but would creating these credentials via: crdup(td->td_ucred); // duplicating the daemon thread's cred - and then replacing the make sense as an alternative to starting with crget()? (ie. All the other stuff except would be "inherited" from the credential for the daemon thread.) rick From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 23:37:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59D66106566B for ; Tue, 6 Oct 2009 23:37:47 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from mail.haruhiism.net (remilia.fujibayashi.jp [92.243.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id 13A768FC12 for ; Tue, 6 Oct 2009 23:37:46 +0000 (UTC) Received: from [192.168.0.10] (datacenter.telecombusinessconsulting.net [77.221.137.211]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.haruhiism.net (Postfix) with ESMTPSA id 9AF934222C for ; Wed, 7 Oct 2009 08:37:43 +0900 (JST) Message-ID: <4ACBD4CA.3070300@haruhiism.net> Date: Wed, 07 Oct 2009 03:37:46 +0400 From: Kamigishi Rei User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: FreeBSD-Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ZFS-related panic, 8.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 23:37:47 -0000 Hello, hope you're having a nice day, Alas, this time I didn't manage to get a dump, so only the panic message is available: panic: _sx_xlock_hard: recursed on non-recursive sx zfsvfs->z_hold_mtx[i] @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1023 -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 23:45:37 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4176D1065692; Tue, 6 Oct 2009 23:45:37 +0000 (UTC) (envelope-from bland@FreeBSD.org) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id BE7438FC27; Tue, 6 Oct 2009 23:45:36 +0000 (UTC) Received: from hub.bbnest.net (w133033.ppp.asahi-net.or.jp [121.1.133.33]) by mail2.asahi-net.or.jp (Postfix) with ESMTP id 08BC176865; Wed, 7 Oct 2009 08:45:34 +0900 (JST) Received: from nest.bbnest.net (nest.bbnest.net [10.0.0.249]) by hub.bbnest.net (8.14.3/8.14.3) with ESMTP id n96NjTa1030019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Oct 2009 08:45:29 +0900 (JST) (envelope-from bland@FreeBSD.org) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/mixed; boundary=Apple-Mail-6--459860985 From: Alexander Nedotsukov In-Reply-To: Date: Wed, 7 Oct 2009 08:45:29 +0900 Message-Id: <19306024-4C3D-41EC-A198-1652B047DF1A@FreeBSD.org> References: <4AB27FB6.4010806@eng.auth.gr> <20090921222241.GF1001@rwpc12.mby.riverwillow.net.au> <20091002081319.GN37304@rwpc12.mby.riverwillow.net.au> <200910020824.15488.john@baldwin.cx> To: Rick Macklem X-Mailer: Apple Mail (2.1076) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Oct 7 08:45:34 2009 X-DSPAM-Confidence: 0.9995 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4acbd69e300201779819952 Cc: John Baldwin , John Marshall , Doug Rabson , freebsd-current@FreeBSD.org, George Mamalakis Subject: Re: [PATCH] SASL problems with spnego on 8.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Oct 2009 23:45:37 -0000 --Apple-Mail-6--459860985 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Use this patch. --Apple-Mail-6--459860985 Content-Disposition: attachment; filename=libgssapi_foo.patch Content-Type: application/octet-stream; name="libgssapi_foo.patch" Content-Transfer-Encoding: 7bit --- libgssapi_krb5/Makefile.orig 2009-10-07 08:32:45.526804858 +0900 +++ libgssapi_krb5/Makefile 2009-10-07 08:33:30.837746152 +0900 @@ -2,8 +2,8 @@ LIB= gssapi_krb5 LDFLAGS= -Wl,-Bsymbolic -LDADD= -lkrb5 -lhx509 -lcrypto -lroken -lasn1 -lcom_err -lcrypt -DPADD= ${LIBKRB5} ${LIBHX509} ${LIBCRYPTO} ${LIBROKEN} ${LIBASN1} \ +LDADD= -lgssapi -lkrb5 -lhx509 -lcrypto -lroken -lasn1 -lcom_err -lcrypt +DPADD= ${LIBGSSAPI} ${LIBKRB5} ${LIBHX509} ${LIBCRYPTO} ${LIBROKEN} ${LIBASN1} \ ${LIBCOM_ERR} ${LIBCRYPT} INCS= ${KRB5DIR}/lib/gssapi/gssapi/gssapi_krb5.h --- libgssapi_spnego/Makefile.orig 2009-10-07 08:32:37.694213217 +0900 +++ libgssapi_spnego/Makefile 2009-10-07 08:34:08.379282521 +0900 @@ -2,8 +2,8 @@ LIB= gssapi_spnego LDFLAGS= -Wl,-Bsymbolic -LDADD= -lasn1 -DPADD= ${LIBASN1} +LDADD= -lgssapi -lasn1 +DPADD= ${LIBGSSAPI} ${LIBASN1} SRCS= accept_sec_context.c \ compat.c \ --Apple-Mail-6--459860985 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On 07.10.2009, at 8:01, Rick Macklem wrote: > > > On Fri, 2 Oct 2009, John Baldwin wrote: > >> >> Hmmm, I thought that libgssapi was supposed to use dlopen to load >> the proper >> back-end libraries using /etc/gss/mech rather than having >> applications >> directly link against them. >> > I think the problem is that the global var. defined in -lgssapi > doesn't > get used by the app. so the .o file in -lgssapi where it's defined > doesn't > get loaded. (Can't remember the exact name, but it's something like > GSS_C_HOST_BASED_NAME.) Then, when -lgssapi-spengo gets loaded, it > can't > resolve it. (I don't know enough about dynamic linking to know the > correct way to fix this. The patch I suggested got it working...) > > rick > > _______________________________________________ > 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 > " --Apple-Mail-6--459860985-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 00:01:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44909106568D; Wed, 7 Oct 2009 00:01:19 +0000 (UTC) (envelope-from csjp@freebsd.org) Received: from mx-02mtaout01.mts.net (mx-02mtaout01.mts.net [142.161.131.3]) by mx1.freebsd.org (Postfix) with ESMTP id E45D98FC18; Wed, 7 Oct 2009 00:01:18 +0000 (UTC) Received: from wnpgmb021pw-sp03.mts.net ([10.204.128.23]) by mx-02mtaout01.mts.net with ESMTP id <20091007000118.JCIF17966.mx-02mtaout01.mts.net@wnpgmb021pw-sp03.mts.net>; Tue, 6 Oct 2009 19:01:18 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsFABt3y0qOoTFx/2dsb2JhbACBUsRqCY8HgkqBYAQ X-IronPort-AV: E=Sophos;i="4.44,515,1249275600"; d="scan'208";a="104136772" Received: from wnpgmb1308w-ad04-49-113.dynamic.mts.net (HELO movsx.my.domain) ([142.161.49.113]) by wnpgmb021pw-sp03.mts.net with ESMTP; 06 Oct 2009 19:01:18 -0500 Received: from movsx.my.domain (csjp@localhost [127.0.0.1]) by movsx.my.domain (8.14.3/8.14.3) with ESMTP id n9701H0h018192; Wed, 7 Oct 2009 00:01:17 GMT (envelope-from csjp@movsx.my.domain) Received: (from csjp@localhost) by movsx.my.domain (8.14.3/8.14.3/Submit) id n9701HYw018191; Wed, 7 Oct 2009 00:01:17 GMT (envelope-from csjp) Date: Wed, 7 Oct 2009 00:01:17 +0000 From: Christian Peron To: Larry Baird Message-ID: <20091007000117.GA17855@movsx> References: <20090921153655.GA37236@gta.com> <20091006205458.GA15679@movsx> <20091006221731.GA18178@gta.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: <20091006221731.GA18178@gta.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, Christian Peron Subject: Re: XEN 5.5.0 and clflush X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 00:01:19 -0000 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable K.. pretty sure there are plans to MFC this for 8 (assuming it has not been done already.) I will check. On Tue, Oct 06, 2009 at 06:17:31PM -0400, Larry Baird wrote: > On Tue, Oct 06, 2009 at 08:54:58PM +0000, Christian Peron wrote: > > This has been fixed. Update your kernel > I have verified I can now boot FreeBSD 9 under Xen. >=20 >=20 > --=20 > ------------------------------------------------------------------------ > Larry Baird | http://www.gta.com > Global Technology Associates, Inc. | Orlando, FL > Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkrL2kwACgkQzHFpVAM/ozwQkgCcD8qoDT1Jh+9FQ4DF2fwHI9qZ 2VsAn0g5q+JWu/uCGHpIlC4CNSb1YbV6 =mnxK -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 01:40:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08D45106568B for ; Wed, 7 Oct 2009 01:40:00 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id BF9F38FC21 for ; Wed, 7 Oct 2009 01:39:59 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 26612489B7 for ; Wed, 7 Oct 2009 02:39:58 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvySe97ZbCtV for ; Wed, 7 Oct 2009 02:39:54 +0100 (BST) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 6B55A48988 for ; Wed, 7 Oct 2009 02:39:54 +0100 (BST) Message-ID: <4ACBF147.1030002@tomjudge.com> Date: Wed, 07 Oct 2009 01:39:19 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4ACA0549.7030404@tomjudge.com> In-Reply-To: <4ACA0549.7030404@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 01:40:00 -0000 Tom Judge wrote: > Hi, > > Does anyone know of a patch that will add per jail memory limits so > that a jail can't swallow the resources of the entire box? > So I have worked up some thing usable fore us based on the 7.0 code from the wiki. This patch is for 7.1 in implements both soft and hard memory limits. Details are here: http://www.tomjudge.com/index.php/FreeBSD/Jails/MemoryLimits Changes that add supporting infrastructure for cpu limiting are in the patch but changes to the schedulers have not been included. If you need the scheduling support you will need to patch sched_4bsd with the code from the original patch set here: http://lists.freebsd.org/pipermail/freebsd-jail/2008-June/000333.html Hope this is useful for some people. Tom From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 01:46:19 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2A2B106566B for ; Wed, 7 Oct 2009 01:46:19 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id 63CAC8FC1C for ; Wed, 7 Oct 2009 01:46:19 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 93A22489B7; Wed, 7 Oct 2009 02:46:18 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fl5OjOlKwurN; Wed, 7 Oct 2009 02:46:14 +0100 (BST) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id DE9C748988; Wed, 7 Oct 2009 02:46:13 +0100 (BST) Message-ID: <4ACBF2C2.4040004@tomjudge.com> Date: Wed, 07 Oct 2009 01:45:38 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Jamie Gritton References: <4ACA0549.7030404@tomjudge.com> <4ACA46D8.8010504@FreeBSD.org> In-Reply-To: <4ACA46D8.8010504@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 01:46:19 -0000 Jamie Gritton wrote: > Tom Judge wrote: >> Does anyone know of a patch that will add per jail memory limits so >> that a jail can't swallow the resources of the entire box? > > Edward Tomasz Napierala has been working on a general resource limit > framework, including jails and memory limits. You can find it at: > http://p4db.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2009/trasz_limits > > > - Jamie Is this in the subversion projects tree? It seems the p4 is not very easy to access unless you have access server. Tom From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 04:38:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B2331065670; Wed, 7 Oct 2009 04:38:23 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id 79F038FC13; Wed, 7 Oct 2009 04:38:22 +0000 (UTC) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n974c898036545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Oct 2009 15:38:08 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1254890288; bh=Z5jcunkvjYddgMptiw0s1T7rPvVuiixp45hzYdlE2Gc=; h=Date:From:To:Cc:Subject:Message-ID:References:Mime-Version: Content-Type:In-Reply-To; b=XNei1qQCegp6rWbPamcYE2ZdLVXyUQN9GqVGhBNOcgUkdJtQpR7uaHoMaX8wZwD01 dg6L/b/Gs4xLfMR9x+/LJoxoiv3onXrgK9MtmKxtBUzjZT9CFR+TkH5ymJl8SmtIGG VmibYdnnko7Je9JWxp6ueek1HYkuVfQU+CJfsrxc= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n974c7FD013410; Wed, 7 Oct 2009 15:38:07 +1100 (AEDT) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id n974c6rE013409; Wed, 7 Oct 2009 15:38:06 +1100 (AEDT) (envelope-from john) Date: Wed, 7 Oct 2009 15:38:06 +1100 From: John Marshall To: Alexander Nedotsukov Message-ID: <20091007043806.GN1086@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: Alexander Nedotsukov , Rick Macklem , John Baldwin , Doug Rabson , freebsd-current@freebsd.org, George Mamalakis References: <4AB27FB6.4010806@eng.auth.gr> <20090921222241.GF1001@rwpc12.mby.riverwillow.net.au> <20091002081319.GN37304@rwpc12.mby.riverwillow.net.au> <200910020824.15488.john@baldwin.cx> <19306024-4C3D-41EC-A198-1652B047DF1A@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oj4kGyHlBMXGt3Le" Content-Disposition: inline In-Reply-To: <19306024-4C3D-41EC-A198-1652B047DF1A@FreeBSD.org> User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Cc: John Baldwin , Doug Rabson , Rick Macklem , George Mamalakis , freebsd-current@freebsd.org Subject: Re: [PATCH] SASL problems with spnego on 8.0-BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 04:38:23 -0000 --oj4kGyHlBMXGt3Le Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 07 Oct 2009, 08:45 +0900, Alexander Nedotsukov wrote: > Use this patch.=20 It worked for me (for _krb5 case). FreeBSD 8.0-RC1 #0: Fri Sep 18 13:35:00 AEST 2009 i386 cyrus-sasl-2.1.23 openldap-sasl-server-2.4.18_1 - Restored original /usr/bin/krb5-config - Stopped LDAP server - Re-built port security/cyrus-sasl2 - Started LDAP server - Confirmed that attempted LDAP access with gssapi auth from a client failed and made the LDAP server die. - Applied libgssapi_foo.patch and re-built kerberos5 - Re-built port security/cyrus-sasl2 - Started LDAP server - LDAP access with gssapi auth from a client succeeded. Perhaps George Mamalakis could test the _spnego case? --=20 John Marshall --oj4kGyHlBMXGt3Le Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkrMGy4ACgkQw/tAaKKahKLB2ACgi7xBIOFvUQVZofnu5nz2yXYA v6IAn161c9k6pT8kCUi6jbWU9u1gQ/HE =qb3d -----END PGP SIGNATURE----- --oj4kGyHlBMXGt3Le-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 05:42:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B619D106568D; Wed, 7 Oct 2009 05:42:21 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id 9E83A8FC16; Wed, 7 Oct 2009 05:42:21 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [17.151.125.209] by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KR400DV4QIIHV60@asmtp022.mac.com>; Tue, 06 Oct 2009 22:42:21 -0700 (PDT) Message-id: <6E3505F9-C73D-480A-9304-890BF153983E@mac.com> From: Chuck Swiger To: "Robert N. M. Watson" In-reply-to: Date: Tue, 06 Oct 2009 22:42:18 -0700 References: <200910021440.50021.hselasky@freebsd.org> <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> X-Mailer: Apple Mail (2.936) Cc: arch@freebsd.org, freebsd-current@freebsd.org Subject: Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 05:42:21 -0000 Hi, Robert-- On Oct 6, 2009, at 1:29 PM, Robert N. M. Watson wrote: >> While the main benefit of blocks is in conjunction with libdispatch >> for userland apps, they can be used by themselves, in the kernel or >> elsewhere. > > When a block is instantiated (perhaps not the formal terminology), > the blocks runtime allocates memory to hold copies of relevant > variables from the calling scope. This memory allocation may present > an issue in some calling contexts in the kernel -- in particular, it > won't be appropriate in contexts were non-sleepable locks are held, > interrupt threads, etc. While it should be possible to use the > primitive in the kernel, we may want to think carefully about these > implications. Also, blocks are currently specific to clang, although > with any luck gcc will grow them also. Yes, you bring up some good points. Blocks haven't been around for long enough to have a widely visible track record as to their benefits and tradeoffs, and the compiler toolchain support is not too widely present, either. While I am confident that blocks could be used in the kernel (and so answered the question which Hans asked), whether the FreeBSD kernel should attempt to use them (much less right away) is more complex topic. Apple's changes to gcc-4.2 to add support for blocks is likely to be available here: http://opensource.apple.com/source/gcc/gcc-5646, or perhaps nearby in a sibling directory [1]. Blocks are normally allocated on the stack, unless you decide to copy them to the heap [2]. If do you need to put a block onto the heap, you shouldn't try to do so in a situation where you aren't OK to call malloc(9) or whatever Block_copy() would use. On the other hand, it's entirely possible that using blocks and dispatch queues would help identify and/ or resolve some of hard-to-reproduce race condition bugs or even deadlocks lurking in the depths of recursive locking/lock-order reversals. To address the other point made by Steve and Roman; the proposed C++0x lambda syntax using [] brackets conflicts with existing code written in ObjC++, so that is likely going to be a non-starter for some folks. Also, the ^ operator can't be overloaded in C++, whereas you can overload the array access operator (aka []). Regards, -- -Chuck [1]: There are a bunch of test cases under http://opensource.apple.com/source/gcc/gcc-5646/gcc/testsuite/gcc.apple/block-* , so I think I've found the right place. :-) [2]: Such as when you are returning a block, or you have a __block variable which itself is a block, or you are using C++ or ObjC and have GC or some sort of reference counting in use, as discussed here: http://clang.llvm.org/docs/BlockLanguageSpec.txt or here: http://thirdcog.eu/pwcblocks/ From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 06:00:48 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 188FC106566B for ; Wed, 7 Oct 2009 06:00:48 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id A68128FC13 for ; Wed, 7 Oct 2009 06:00:47 +0000 (UTC) Received: from [41.154.0.10] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MvPZs-0003hH-5K for current@freebsd.org; Wed, 07 Oct 2009 08:00:44 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvPZq-000Fqu-Ti for current@freebsd.org; Wed, 07 Oct 2009 08:00:42 +0200 To: current@freebsd.org From: "Ian Freislich" X-Attribution: BOFH Date: Wed, 07 Oct 2009 08:00:42 +0200 Message-Id: Cc: Subject: alc(4) link autoselect problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 06:00:48 -0000 Hi On my recently acquired netbook (compaq mini-110), the ethernet doesn't autoselect the link speed properly. I think this is because HP chose the cheapest ethernet controler and the cheapest PHY and there's a speed missmatch (or the PHY isn't correctly detected): alc0: port 0xec80-0xecff mem 0xfebc0000-0xfebfffff irq 17 at device 0.0 on pci2 alc0: 15872 Tx FIFO, 15360 Rx FIFO alc0: Using 1 MSI message(s). miibus0: on alc0 atphy0: PHY 0 on miibus0 atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto alc0: Ethernet address: 00:25:b3:6f:ab:9a alc0: [FILTER] alc0@pci0:2:0:0: class=0x020000 card=0x308f103c chip=0x10621969 rev=0xc0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[48] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[58] = PCI-Express 1 endpoint max data 128(4096) link x1(x1) cap 03[6c] = VPD The AR8132 is Fast Ethernet, but the Atheros F1 is gigabit capable. If I set the media to 100BaseTX full-duplex it works. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 07:31:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBB21106566B for ; Wed, 7 Oct 2009 07:31:27 +0000 (UTC) (envelope-from bofh@redwerk.com) Received: from redwerk.com (redwerk.com [89.105.196.9]) by mx1.freebsd.org (Postfix) with ESMTP id E5C648FC08 for ; Wed, 7 Oct 2009 07:31:26 +0000 (UTC) Received: from [192.168.250.5] (helo=office.redwerk.com) by redwerk.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MvQzZ-00089I-OG for freebsd-current@freebsd.org; Wed, 07 Oct 2009 09:31:25 +0200 Received: from bofh by office.redwerk.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvQzY-0005Ii-VQ for freebsd-current@freebsd.org; Wed, 07 Oct 2009 10:31:20 +0300 Date: Wed, 7 Oct 2009 10:31:20 +0300 From: Eugene Dzhurinsky To: freebsd-current@freebsd.org Message-ID: <20091007073120.GA11667@office.redwerk.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dc+cDN39EJAMEtIO" Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD 8.0 RC1 does not recognize dvd rw controller when enhanced IDE mode is used X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 07:31:27 -0000 --dc+cDN39EJAMEtIO Content-Type: multipart/mixed; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello! I am facing strange issue with FreeBSD 8.0 RC1 and my laptop, Asus K40IN - with enhanced mode for IDE channels the on-board DVD RW drive is not recognized. I've attached verbose logs from dmesg for both modes (enhanced and compatible). Probably somebody could take a look at this problem (I think it is related to ahci module)? Thank you in advance! --=20 Eugene N Dzhurinsky --n8g4imXOkfNTN/H1-- --dc+cDN39EJAMEtIO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkrMQ8cACgkQy/i/DoZLbHwoQwCeP9SQ7MFukbdggUE1H0jwaO0M rFgAnR0rSg34MivuZDLm3mHOHE1MxpWa =PrA8 -----END PGP SIGNATURE----- --dc+cDN39EJAMEtIO-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 08:45:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57F8B106566B; Wed, 7 Oct 2009 08:45:17 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 09A008FC12; Wed, 7 Oct 2009 08:45:15 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=1xjITpaIZIUA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=Yv4Q5gvs8gH1Cj39_C4A:9 a=MF4zQ8768sM9FJsRIb8A:7 a=YmpKpVShKCXwlsegRQIqdXDgRtgA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1309087748; Wed, 07 Oct 2009 10:45:13 +0200 Received-SPF: softfail receiver=mailfe06.swip.net; client-ip=188.126.201.140; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 7 Oct 2009 10:45:59 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20091006204152.GA37998@freebsd.org> In-Reply-To: <20091006204152.GA37998@freebsd.org> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910071046.01595.hselasky@freebsd.org> Cc: arch@freebsd.org, Roman Divacky , "Robert N. M. Watson" Subject: Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 08:45:17 -0000 On Tuesday 06 October 2009 22:41:52 Roman Divacky wrote: > On Tue, Oct 06, 2009 at 09:29:50PM +0100, Robert N. M. Watson wrote: > > On 6 Oct 2009, at 19:50, Chuck Swiger wrote: > > >Hi, Hans-- > > > > > >On Oct 2, 2009, at 5:40 AM, Hans Petter Selasky wrote: > > >>Can the Apple's "Blocks" C language extension be used when > > >>programming in the kernel? Or is this a user-space only feature? > > > > > >While the main benefit of blocks is in conjunction with libdispatch > > >for userland apps, they can be used by themselves, in the kernel or > > >elsewhere. > > > > When a block is instantiated (perhaps not the formal terminology), the > > blocks runtime allocates memory to hold copies of relevant variables > > from the calling scope. This memory allocation may present an issue in > > some calling contexts in the kernel Hi Robert, I would argue that it is highly desirable to be able to pre-allocate memory for the given "callbacks" [here: Apple's "Blocks"]. Apple's "Blocks" reminds me of the USB stack's "msignal" system. "msignal" associates a piece of code with some data structure, and executes it for callback. Memory allocation is always a challenge. To allocate memory on the fly can also be a performance issue, and not at least make problems for realtime systems. I would suggest that the language is extended so that the elements that gets allocated are in the form of a structure. Example pseudo code: struct async_callback_001 { struct libdispatch_data xxx; int x; int y; }; void my_func(int x, int y) { static struct queue pq; static struct async_callback_001 data; init_queue(&pq); queue(&pq, &data, ^{ block of code which can only access parent fields that are given through the "data" structure. }); } Also there should be the possibility to lock the queue and test if an instance of a Apple Block has been queued for execution, because it is not just about paralell execution, but also about being able to drain/stop a system without polling. I admit I haven't looked too closely at the Apple Block's system yet, so maybe some of the features I'm asking for are already present. > > -- in particular, it won't be > > appropriate in contexts were non-sleepable locks are held, interrupt > > threads, etc. While it should be possible to use the primitive in the > > kernel, we may want to think carefully about these implications. Maybe that suggests that malloc() is the wrong way forward for keeping the temporary variable storage. Like I state in my example above, maybe the temporary variable storage should be separated out, so that for instance in a critical context, pre-allocated or static memory can be used instead?! > > Also, > > blocks are currently specific to clang, although with any luck gcc > > will grow them also. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 09:35:48 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BAD1106566B; Wed, 7 Oct 2009 09:35:48 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 0A7138FC19; Wed, 7 Oct 2009 09:35:47 +0000 (UTC) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 1F48A19E027; Wed, 7 Oct 2009 11:35:46 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 7FE1A19E023; Wed, 7 Oct 2009 11:35:43 +0200 (CEST) Message-ID: <4ACC60EF.50104@quip.cz> Date: Wed, 07 Oct 2009 11:35:43 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: Tom Judge References: <4ACA0549.7030404@tomjudge.com> <4ACBF147.1030002@tomjudge.com> In-Reply-To: <4ACBF147.1030002@tomjudge.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-jail@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 09:35:48 -0000 Tom Judge wrote: > So I have worked up some thing usable fore us based on the 7.0 code from > the wiki. > > This patch is for 7.1 in implements both soft and hard memory limits. > > Details are here: > http://www.tomjudge.com/index.php/FreeBSD/Jails/MemoryLimits > > Changes that add supporting infrastructure for cpu limiting are in the > patch but changes to the schedulers have not been included. If you need > the scheduling support you will need to patch sched_4bsd with the code > from the original patch set here: > > http://lists.freebsd.org/pipermail/freebsd-jail/2008-June/000333.html > > Hope this is useful for some people. I added links to this thread and to your patch into wiki page http://wiki.freebsd.org/Jails. I hope it will help people to find your work. Do you plan to make it for 7.2 and other future releases? Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 10:43:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2A60106566B for ; Wed, 7 Oct 2009 10:43:36 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 359AA8FC13 for ; Wed, 7 Oct 2009 10:43:35 +0000 (UTC) Received: from [41.154.0.10] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MvTzZ-0008AJ-Jo; Wed, 07 Oct 2009 12:43:33 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvTzV-0001VQ-A8; Wed, 07 Oct 2009 12:43:29 +0200 To: pyunyh@gmail.com From: Ian FREISLICH In-Reply-To: <20090914173805.GB1155@michelle.cdnetworks.com> References: <20090914173805.GB1155@michelle.cdnetworks.com> <4AA65ABE.4000207@lazybytes.org> <4AA668E0.1010305@FreeBSD.org> <4AA6ACF1.3040501@lazybytes.org> <20090908204520.GC1520@michelle.cdnetworks.com> <20090913202710.21762fa7@lazybytes.org> X-Attribution: BOFH Date: Wed, 07 Oct 2009 12:43:29 +0200 Message-Id: Cc: freebsd-current@freebsd.org Subject: Re: alc(4) link handling [was: Re: ath(4) Atheros AR9285 support] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 10:43:36 -0000 Pyun YongHyeon wrote: > Hmm, AR8132 uses F1 gigabit PHY but Atheros changed its internal > circuit such that it operates as 10/100 PHY. I guess it's more > appropriate to disable advertisement of 1000baseT capability for > AR8132 case. Would you try attached patch? I've tried this patch (actually committed) but my adapter which uses the same chip/phy doesn't auto negotiate when plugged into a gigabit port on my switch. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 09:15:36 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D286C106568B; Wed, 7 Oct 2009 09:15:36 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-bw0-f227.google.com (mail-bw0-f227.google.com [209.85.218.227]) by mx1.freebsd.org (Postfix) with ESMTP id 21B648FC1C; Wed, 7 Oct 2009 09:15:35 +0000 (UTC) Received: by bwz27 with SMTP id 27so3685248bwz.43 for ; Wed, 07 Oct 2009 02:15:34 -0700 (PDT) Received: by 10.103.81.38 with SMTP id i38mr1218571mul.92.1254905208264; Wed, 07 Oct 2009 01:46:48 -0700 (PDT) Received: from terran.mk.farlep.net (i168-101-19-89.vpdn.way.kv.chereda.net [89.19.101.168]) by mx.google.com with ESMTPS id 25sm2494473mul.55.2009.10.07.01.46.45 (version=SSLv3 cipher=RC4-MD5); Wed, 07 Oct 2009 01:46:46 -0700 (PDT) Sender: Alex RAY Date: Wed, 7 Oct 2009 11:46:12 +0300 From: Alexandr Rybalko To: Marcel Moolenaar Message-Id: <20091007114612.00408f53.ray@dlink.ua> In-Reply-To: <9BAB53FC-022B-4AA8-B29A-4B7428B5CC74@mac.com> References: <9BAB53FC-022B-4AA8-B29A-4B7428B5CC74@mac.com> Organization: D-Link X-Mailer: Sylpheed 2.6.0 (GTK+ 2.14.7; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 07 Oct 2009 11:36:59 +0000 Cc: arm@freebsd.org, FreeBSD current mailing list Subject: Re: [ARM+NFS] panic while copying across NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 09:15:36 -0000 Hi All! Testing on Orion like board (D-Link DNS-323) I get same result, panic on copy file across NFS. panic: vm_page_insert: offset already allocated backtrace - same. On Fri, 12 Jun 2009 13:19:22 -0700 Marcel Moolenaar wrote: >> I just ran into the following panic: >> >> panic: vm_page_insert: offset already allocated >> >> I was copying a kernel across NFS at the time: >> >> orion% cd /nfs/netboot/arm >> orion% ls >> kernel-save.bin kernel.bin ubldr >> orion% sudo cp kernel.bin kernel-save.bin >> orion% sudo cp /usr/obj/nfs/freebsd/base/head/sys/ORION/kernel.bin >> kernel.bin >> >> (/usr/obj is on a local disk) >> >> With this backtrace: >> >> db> bt >> Tracing pid 26585 tid 100073 td 0xc22bd6f0 >> db_trace_thread() at db_trace_thread+0x10 >> scp=0xc0ae66e8 rlv=0xc0914d78 (db_command_init+0x484) >> rsp=0xc8492878 rfp=0xc8492898 >> r10=0x00000001 r9=0xc0bb3e94 >> r8=0xc0babdc8 r7=0xc0bab59c r6=0x00000010 r5=0x00000000 >> r4=0xc22bd6f0 >> db_command_init() at db_command_init+0x404 >> scp=0xc0914cf8 rlv=0xc09145b4 (db_skip_to_eol+0x38c) >> rsp=0xc849289c rfp=0xc8492940 >> r6=0x00000002 r5=0x00000000 >> r4=0xc0b8bb80 >> db_skip_to_eol() at db_skip_to_eol+0x1d0 >> scp=0xc09143f8 rlv=0xc09147d0 (db_command_loop+0x50) >> rsp=0xc8492944 rfp=0xc8492954 >> r10=0x00000001 r8=0x00000000 >> r7=0xc8492b1c r6=0xc0bb3e90 r5=0x00000000 r4=0xc0bab598 >> db_command_loop() at db_command_loop+0x18 >> scp=0xc0914798 rlv=0xc0916960 (X_db_sym_numargs+0xa0) >> rsp=0xc8492958 rfp=0xc8492a74 >> r4=0xc849295c >> X_db_sym_numargs() at X_db_sym_numargs+0x18 >> scp=0xc09168d8 rlv=0xc09bcb98 (kdb_trap+0xb0) >> rsp=0xc8492a78 rfp=0xc8492aa0 >> r4=0x000000c0 >> kdb_trap() at kdb_trap+0x10 >> scp=0xc09bcaf8 rlv=0xc0af76cc (undefinedinstruction+0x124) >> rsp=0xc8492aa4 rfp=0xc8492b18 >> r10=0xc22bd6f0 r9=0x00000000 >> r8=0xc09bc88c r7=0xe7ffffff r6=0xc8492b1c r5=0x00000000 >> r4=0x00000000 >> undefinedinstruction() at undefinedinstruction+0x10 >> scp=0xc0af75b8 rlv=0xc0ae8174 (address_exception_entry+0x50) >> rsp=0xc8492b1c rfp=0xc8492b7c >> r10=0xc0d147c8 r8=0x00000000 >> r7=0xc22bd6f0 r6=0xc0bb00c0 r5=0xffff1004 r4=0x00000000 >> kdb_enter() at kdb_enter+0x14 >> scp=0xc09bc858 rlv=0xc09955f4 (panic+0xa0) >> rsp=0xc8492b80 rfp=0xc8492b94 >> r5=0xc0b4c994 r4=0x00000100 >> panic() at panic+0x1c >> scp=0xc0995570 rlv=0xc0ad8de0 (vm_page_insert+0x164) >> rsp=0xc8492ba8 rfp=0xc8492bc8 >> vm_page_insert() at vm_page_insert+0x10 >> scp=0xc0ad8c8c rlv=0xc0ad90f4 (vm_page_alloc+0x304) >> rsp=0xc8492bcc rfp=0xc8492bf4 >> r8=0x00001e03 r7=0x00000061 >> r6=0x00000001 r5=0xc0fe25c8 r4=0x00000000 >> vm_page_alloc() at vm_page_alloc+0x10 >> scp=0xc0ad8e00 rlv=0xc0acd740 (kmem_malloc+0x2b4) >> rsp=0xc8492bf8 rfp=0xc8492c48 >> r10=0x00000000 r9=0x00001000 >> r8=0x00000103 r7=0xc0e3a088 r6=0x01e03000 r5=0x00000061 >> r4=0xc1e03000 >> kmem_malloc() at kmem_malloc+0x14 >> scp=0xc0acd4a0 rlv=0xc0ac77bc (uma_zcreate+0xd0) >> rsp=0xc8492c4c rfp=0xc8492c88 >> r10=0xc0ac5efc r9=0xc0e36640 >> r8=0x00000103 r7=0xc1dfd000 r6=0xc1dfd000 r5=0x00000003 >> r4=0xc0e2d280 >> uma_zcreate() at uma_zcreate+0x70 >> scp=0xc0ac775c rlv=0xc0ac7d28 (uma_prealloc+0x198) >> rsp=0xc8492c8c rfp=0xc8492cac >> r10=0xc0e319d8 r9=0x00000020 >> r8=0xc0e36640 r7=0x00000000 r6=0xc0e36640 r5=0x00000203 >> r4=0xc0e2d280 >> uma_prealloc() at uma_prealloc+0xd4 >> scp=0xc0ac7c64 rlv=0xc0ac7fe8 (uma_prealloc+0x458) >> rsp=0xc8492cb0 rfp=0xc8492cc8 >> r7=0x00000002 r6=0xc0e36640 >> r5=0x00000003 r4=0xc0e2d280 >> uma_prealloc() at uma_prealloc+0x42c >> scp=0xc0ac7fbc rlv=0xc0ac9230 (uma_zalloc_arg+0x32c) >> rsp=0xc8492ccc rfp=0xc8492d10 >> r6=0xc1a5dcc0 r5=0x00000013 >> r4=0x00000013 >> uma_zalloc_arg() at uma_zalloc_arg+0x10 >> scp=0xc0ac8f14 rlv=0xc0a86710 (nfsm_uiotombuf+0xec) >> rsp=0xc8492d14 rfp=0xc8492d5c >> r10=0xc4bc0fcc r9=0x00008000 >> r8=0x00006034 r7=0xc8492df4 r6=0xc1976800 r5=0x00000800 >> r4=0x00000000 >> nfsm_uiotombuf() at nfsm_uiotombuf+0x10 >> scp=0xc0a86634 rlv=0xc0a8e8f4 (nfs_writerpc+0x1a8) >> rsp=0xc8492d60 rfp=0xc8492ddc >> r10=0xc3884910 r9=0x00008000 >> r8=0xc1acb000 r7=0x00008000 r6=0xc8492df4 r5=0xc1979900 >> r4=0x00000000 >> nfs_writerpc() at nfs_writerpc+0x10 >> scp=0xc0a8e75c rlv=0xc0a7f680 (nfs_doio+0x204) >> rsp=0xc8492de0 rfp=0xc8492e4c >> r10=0xc3884910 r9=0xc235cca8 >> r8=0x00008000 r7=0x00000000 r6=0x00000000 r5=0x000000c0 >> r4=0x00000000 >> nfs_doio() at nfs_doio+0x10 >> scp=0xc0a7f48c rlv=0xc0a871d8 (nfs_nfsiodnew+0x3c4) >> rsp=0xc8492e50 rfp=0xc8492e80 >> r10=0x00000000 r9=0xc0d13ab4 >> r8=0xc0d13990 r7=0x00000006 r6=0x00000000 r5=0xc1acb000 >> r4=0xc3884910 >> nfs_nfsiodnew() at nfs_nfsiodnew+0x2ac >> scp=0xc0a870c0 rlv=0xc0974b84 (fork_exit+0x64) >> rsp=0xc8492e84 rfp=0xc8492ea8 >> r10=0xc0a870b0 r9=0xc0d1f6c0 >> r8=0xc0d13368 r7=0xc1c6a828 r6=0xc8492eac r5=0xc0d1f6c0 >> r4=0xc22bd6f0 >> fork_exit() at fork_exit+0x10 >> scp=0xc0974b30 rlv=0xc0af6190 (fork_trampoline+0x14) >> rsp=0xc8492eac rfp=0x00000000 >> r10=0xc0d1f6c0 r8=0x00000104 >> r7=0xc0ae7f4c r6=0xc8492eac r5=0xc0d13368 r4=0xc0a870b0 >> >> >> FYI, >> >> -- >> Marcel Moolenaar >> xcllnt@mac.com >> >> >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- Alexandr Rybalko From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 10:30:58 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 634CC1065670; Wed, 7 Oct 2009 10:30:58 +0000 (UTC) (envelope-from kostjn@peterhost.ru) Received: from fb0.z8.ru (fb0.z8.ru [80.93.58.95]) by mx1.freebsd.org (Postfix) with ESMTP id 1E3208FC16; Wed, 7 Oct 2009 10:30:58 +0000 (UTC) Received: from mail.z8.ru ([80.93.58.56]) by fb0.z8.ru with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvTdD-000G7X-Rb; Wed, 07 Oct 2009 14:20:27 +0400 Received: from [85.235.196.139] (helo=kostjn.pht) by mail.z8.ru with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1MvTca-000DP1-Ll; Wed, 07 Oct 2009 14:19:48 +0400 Message-ID: <4ACC6C01.80106@peterhost.ru> Date: Wed, 07 Oct 2009 14:22:57 +0400 From: Menshikov Konstantin User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz> References: <4ACA0549.7030404@tomjudge.com> <4ACBF147.1030002@tomjudge.com> <4ACC60EF.50104@quip.cz> In-Reply-To: <4ACC60EF.50104@quip.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 07 Oct 2009 11:37:12 +0000 Cc: Tom Judge , freebsd-current@FreeBSD.org, freebsd-jail@FreeBSD.org Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 10:30:58 -0000 Miroslav Lachman wrote: > Tom Judge wrote: > >> So I have worked up some thing usable fore us based on the 7.0 code >> from the wiki. >> >> This patch is for 7.1 in implements both soft and hard memory limits. >> >> Details are here: >> http://www.tomjudge.com/index.php/FreeBSD/Jails/MemoryLimits >> >> Changes that add supporting infrastructure for cpu limiting are in >> the patch but changes to the schedulers have not been included. If >> you need the scheduling support you will need to patch sched_4bsd >> with the code from the original patch set here: >> >> http://lists.freebsd.org/pipermail/freebsd-jail/2008-June/000333.html >> >> Hope this is useful for some people. > > I added links to this thread and to your patch into wiki page > http://wiki.freebsd.org/Jails. I hope it will help people to find your > work. > Do you plan to make it for 7.2 and other future releases? > > Miroslav Lachman > _______________________________________________ > freebsd-jail@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-jail > To unsubscribe, send any mail to "freebsd-jail-unsubscribe@freebsd.org" > It is good that people work in this direction! At present there are some patches, however any of them is not finished. I suggest to discuss in details a problem. The most important questions. 1. It is necessary to limit what resources? 2. How resources should be limited? Soft and hard limits. 3. How to count memory occupied with group of processes? 4. How to limit memory use? Whether correctly to kill processes? 5. How to limit use of processor time at absence in ULE separate turns of performance for jails? 6. Whether limits should be inherited at creation jails? etc. -- Menshikov Konstantin From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 10:44:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B71601065692 for ; Wed, 7 Oct 2009 10:44:31 +0000 (UTC) (envelope-from ggajic@afrodita.rcub.bg.ac.rs) Received: from mx.rcub.bg.ac.rs (mx.rcub.bg.ac.rs [147.91.1.122]) by mx1.freebsd.org (Postfix) with ESMTP id 749EF8FC14 for ; Wed, 7 Oct 2009 10:44:30 +0000 (UTC) Received: by mx.rcub.bg.ac.rs (Postfix, from userid 2055) id 28CC41919D71; Wed, 7 Oct 2009 12:44:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx.rcub.bg.ac.rs (Postfix) with ESMTP id 177DF1919D6F for ; Wed, 7 Oct 2009 12:44:24 +0200 (CEST) Date: Wed, 7 Oct 2009 12:44:24 +0200 (CEST) From: Goran Gajic To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-RCUB-MailScanner-Information: Please contact the ISP for more information X-RCUB-MailScanner: Found to be clean X-RCUB-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.399, required 7, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Mailman-Approved-At: Wed, 07 Oct 2009 11:37:22 +0000 Subject: cdrom and freebsd 8.0-rc1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 10:44:31 -0000 Hi, This is quite strange, but this is what I'm getting: gbsd# mount /cdrom gbsd# ls -al /cdrom/ total 687895 dr-xr-xr-x 2 root wheel 2048 Oct 7 11:02 . drwxr-xr-x 25 root wheel 1024 Oct 7 11:30 .. -rw-rw-r-- 1 ggajic black 704400540 Oct 7 02:04 2.avi gbsd# umount /cdrom gbsd# mount /cdrom info: [drm] Loading R300 Microcode info: [drm] Num pipes: 4 g_vfs_done():acd0[READ(offset=32768, length=2048)]error = 5 mount_cd9660: /dev/acd0: Input/output error gbsd# mount /cdrom Until I reboot computer I can't mount cdrom back.. FreeBSD gbsd.interex-pla.net 8.0-RC1 FreeBSD 8.0-RC1 #0 r197801M: Tue Oct 6 10:32:11 CEST 2009 root@gbsd.interex-pla.net:/usr/src/sys/i386/compile/GENERIC i386 regards, gg. From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 11:21:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3FAD1065695 for ; Wed, 7 Oct 2009 11:21:43 +0000 (UTC) (envelope-from ggajic@afrodita.rcub.bg.ac.rs) Received: from mx.rcub.bg.ac.rs (mx.rcub.bg.ac.rs [147.91.1.122]) by mx1.freebsd.org (Postfix) with ESMTP id 9DB858FC1C for ; Wed, 7 Oct 2009 11:21:43 +0000 (UTC) Received: by mx.rcub.bg.ac.rs (Postfix, from userid 2055) id 7D3ED1919E28; Wed, 7 Oct 2009 13:21:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx.rcub.bg.ac.rs (Postfix) with ESMTP id 6EFCB1919E27 for ; Wed, 7 Oct 2009 13:21:11 +0200 (CEST) Date: Wed, 7 Oct 2009 13:21:11 +0200 (CEST) From: Goran Gajic To: freebsd-current@freebsd.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-RCUB-MailScanner-Information: Please contact the ISP for more information X-RCUB-MailScanner: Found to be clean X-RCUB-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.399, required 7, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Mailman-Approved-At: Wed, 07 Oct 2009 11:37:32 +0000 Subject: Re: cdrom and freebsd 8.0-rc1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 11:21:44 -0000 I forgot to mention that this happens after usage of burncd utility. However, after few minutes problem goes away. I have tried this with several cds and it is always happening. gg. On Wed, 7 Oct 2009, Goran Gajic wrote: > > > Hi, > > This is quite strange, but this is what I'm getting: > > gbsd# mount /cdrom > gbsd# ls -al /cdrom/ > total 687895 > dr-xr-xr-x 2 root wheel 2048 Oct 7 11:02 . > drwxr-xr-x 25 root wheel 1024 Oct 7 11:30 .. > -rw-rw-r-- 1 ggajic black 704400540 Oct 7 02:04 2.avi > gbsd# umount /cdrom > gbsd# mount /cdrom > info: [drm] Loading R300 Microcode > info: [drm] Num pipes: 4 > g_vfs_done():acd0[READ(offset=32768, length=2048)]error = 5 > mount_cd9660: /dev/acd0: Input/output error > gbsd# mount /cdrom > > Until I reboot computer I can't mount cdrom back.. > FreeBSD gbsd.interex-pla.net 8.0-RC1 FreeBSD 8.0-RC1 #0 r197801M: Tue Oct 6 > 10:32:11 CEST 2009 > root@gbsd.interex-pla.net:/usr/src/sys/i386/compile/GENERIC i386 > > regards, > gg. > From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 11:53:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73007106568B for ; Wed, 7 Oct 2009 11:53:38 +0000 (UTC) (envelope-from bofh@redwerk.com) Received: from redwerk.com (redwerk.com [89.105.196.9]) by mx1.freebsd.org (Postfix) with ESMTP id C34948FC16 for ; Wed, 7 Oct 2009 11:53:37 +0000 (UTC) Received: from [192.168.250.5] (helo=office.redwerk.com) by redwerk.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MvV5K-0002ML-EX for freebsd-current@freebsd.org; Wed, 07 Oct 2009 13:53:37 +0200 Received: from bofh by office.redwerk.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvV5J-000LCs-7I for freebsd-current@freebsd.org; Wed, 07 Oct 2009 14:53:33 +0300 Date: Wed, 7 Oct 2009 14:53:33 +0300 From: Eugene Dzhurinsky To: freebsd-current@freebsd.org Message-ID: <20091007115333.GA81330@office.redwerk.com> References: <20091007073120.GA11667@office.redwerk.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kORqDWCi7qDJ0mEj" Content-Disposition: inline In-Reply-To: <20091007073120.GA11667@office.redwerk.com> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: FreeBSD 8.0 RC1 does not recognize dvd rw controller when enhanced IDE mode is used X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 11:53:38 -0000 --kORqDWCi7qDJ0mEj Content-Type: multipart/mixed; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 07, 2009 at 10:31:20AM +0300, Eugene Dzhurinsky wrote: > Hello! >=20 > I am facing strange issue with FreeBSD 8.0 RC1 and my laptop, Asus K40IN - > with enhanced mode for IDE channels the on-board DVD RW drive is not > recognized. >=20 > I've attached verbose logs from dmesg for both modes (enhanced and > compatible). Probably somebody could take a look at this problem (I think= it > is related to ahci module)? >=20 > Thank you in advance! Attachment followed, sorry :) --=20 Eugene N Dzhurinsky --PNTmBPCT7hxwcZjr-- --kORqDWCi7qDJ0mEj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkrMgTwACgkQy/i/DoZLbHwkrQCgrHnnTVtCM1oXpAGxNq/MFJQB qgIAnjWuU5Hgv+A0jyKJ/ptb3Ra9YQ6o =XTZ7 -----END PGP SIGNATURE----- --kORqDWCi7qDJ0mEj-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 12:23:16 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F300106566B for ; Wed, 7 Oct 2009 12:23:16 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id CD7D58FC16 for ; Wed, 7 Oct 2009 12:23:14 +0000 (UTC) Received: from [41.154.0.10] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MvVY0-0006Vz-0C for current@freebsd.org; Wed, 07 Oct 2009 14:23:12 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvVXy-00031b-Mt for current@freebsd.org; Wed, 07 Oct 2009 14:23:10 +0200 To: current@freebsd.org From: "Ian Freislich" X-Attribution: BOFH Date: Wed, 07 Oct 2009 14:23:10 +0200 Message-Id: Cc: Subject: urtw(4) feedback. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 12:23:16 -0000 Hi FWIW, the manual can be updated to include support for the Linksys WG111v3 adapter. Mine detects as follows: ugen4.3: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON urtw0: on usbus4 urtw0: rtl8187b rf rtl8225z2 hwrev e Opening it up confirms the presence of a RTL8187B. However throughput is very poor, I haven't been able to get more than about 130kB/s and pings seem to be timed every 1.5 seconds. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 13:03:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A7781065670 for ; Wed, 7 Oct 2009 13:03:06 +0000 (UTC) (envelope-from swehack@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 81F508FC14 for ; Wed, 7 Oct 2009 13:03:05 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 4so1113029eyf.9 for ; Wed, 07 Oct 2009 06:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=AlpKhK/dfT0X488jKX7uXJPUY3+LHMEScrtuB2gINoI=; b=wmBSEVXl3WuP3uYGPWd68gCxIzAUiWwPRWZFvJunQUHfLcNdSxWj8jLLN54JL0O4sx zIck5Gk5E8CZCu6N1yBDGugbSGzIkhFoZ8kWgbKJp+ji6v/YRusFx5ThJPKN0VH/+Vi9 ZNciVrCcnrkDSMA6GozUnFELB9AMWl+nngHC0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ugh2YcE8CwZRjnbb2xLk7WfgvL+MeemcuCpFEpPZemFMhi0TkXGeL5+oMHwlR8WVEV PUivvXK1nogLwoQgN5Idy+y8O2KtpMwvwktSIe7jCiTpm7cfJLgWpRrbql2gNJEJ/DtK cBKrKrlhRHaHVvoj5VCSUwHbhf7Jekv3t4y0c= MIME-Version: 1.0 Received: by 10.211.158.15 with SMTP id k15mr3227147ebo.25.1254920576278; Wed, 07 Oct 2009 06:02:56 -0700 (PDT) In-Reply-To: <20091006221719.GA5942@alucard.int.rhavenn.net> References: <9aed80930910051249ocfcf946o2341c653d16b8e24@mail.gmail.com> <20091006221719.GA5942@alucard.int.rhavenn.net> Date: Wed, 7 Oct 2009 15:02:56 +0200 Message-ID: <9aed80930910070602o76ac20f4u900098f1d0c32080@mail.gmail.com> From: nocturnal To: Henrik Hudson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Updating FreeBSD 7.0-RELEASE i386 to 7.2 amd64? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 13:03:06 -0000 Thanks for the pointers Henrik. I have decided that you are right, it's too much of a headache. I would rather just re-install and restore backups. 2009/10/7 Henrik Hudson > On Mon, 05 Oct 2009, nocturnal wrote: > > > Can it be done with a simple cvs or binary update of FreeBSD or must i > > re-install using some media? > > > > If i kept my /usr partition intact and just overwrote the important stu= ff > > with new files from the CD it wouldn't be so bad with a re-install but = it > > would be nice if large parts of it could be done remote. > > > > What is your suggestion for this? > > You will have to recompile all ports (/usr/local ) and any manually > installed apps due > to the changes in the system libs. Personally, it's not worth the > headache of trying to do a "upgrade" across architectures like this. > > Most of the items in /usr (outside of /usr/local) are part of the > base system and should update "okay", but I don't know if you will > be able to boot a x64 kernel into a x86 system, assuming you try a > reboot between make installkernel and make installworld . > > I don't think a binary upgrade would work at all, but I've never > actually done a binary upgrade. I always csup. > > On that note, I've never tried this, but I would recommend against it. > > Henrik > -- > Henrik Hudson > lists@rhavenn.net > ----------------------------------------- > "God, root, what is difference?" Pitr; UF > > --=20 Med v=E4nliga h=E4lsningar Stefan Midjich aka nocturnal [SWEHACK] http://swehack.se From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 14:20:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C6B41065692 for ; Wed, 7 Oct 2009 14:20:54 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id E94868FC31 for ; Wed, 7 Oct 2009 14:20:53 +0000 (UTC) Received: from [41.154.0.10] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MvXNr-0006UN-Bp for current@freebsd.org; Wed, 07 Oct 2009 16:20:51 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvXNq-0003F6-2Q for current@freebsd.org; Wed, 07 Oct 2009 16:20:50 +0200 From: Ian FREISLICH In-Reply-To: References: X-Attribution: BOFH Date: Wed, 07 Oct 2009 16:20:50 +0200 Message-Id: Cc: current@freebsd.org Subject: Re: urtw(4) feedback. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 14:20:54 -0000 "Ian Freislich" wrote: > Hi > > FWIW, the manual can be updated to include support for the Linksys > WG111v3 adapter. Mine detects as follows: Umm. typo. That should be "Netgear WG111v3" Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 15:11:05 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1185B106568D for ; Wed, 7 Oct 2009 15:11:05 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 9D7D48FC08 for ; Wed, 7 Oct 2009 15:11:04 +0000 (UTC) Received: from [41.154.0.10] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MvYAP-0001Qi-Uc; Wed, 07 Oct 2009 17:11:02 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvYAM-0003Y7-Mo; Wed, 07 Oct 2009 17:10:58 +0200 To: Rui Paulo From: Ian FREISLICH In-Reply-To: References: X-Attribution: BOFH Date: Wed, 07 Oct 2009 17:10:58 +0200 Message-Id: Cc: current@freebsd.org Subject: Re: urtw(4) feedback. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 15:11:05 -0000 Rui Paulo wrote: > On 7 Oct 2009, at 13:23, Ian Freislich wrote: > > urtw0: rtl8187b rf rtl8225z2 hwrev e > > > > Opening it up confirms the presence of a RTL8187B. > > > > However throughput is very poor, I haven't been able to get more > > than about 130kB/s and pings seem to be timed every 1.5 seconds. > > > > This might help: > http://p4db.freebsd.org/chv.cgi?CH=169276 Not significantly. The stability of the wireless association is improved throughput is nearly doubled to 240kB/s, but there's some wierdness: it responds to ping from "outside" almost immediately, but when the host pings out, it spaces requests at about 1.6 seconds (which it doesn't do on the alc0 interface). [mini] /usr/src/sys/modules/usb/urtw # time ping -c2 10.0.2.1 PING 10.0.2.1 (10.0.2.1): 56 data bytes 64 bytes from 10.0.2.1: icmp_seq=0 ttl=64 time=36.176 ms 64 bytes from 10.0.2.1: icmp_seq=1 ttl=64 time=44.282 ms --- 10.0.2.1 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 36.176/40.229/44.282/4.053 ms real 0m1.696s user 0m0.000s sys 0m0.001s It also takes about 10 seconds for the wlan0 interface to appear after insertion. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 14:46:20 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 015F71065695 for ; Wed, 7 Oct 2009 14:46:20 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id 670C78FC1A for ; Wed, 7 Oct 2009 14:46:19 +0000 (UTC) Received: by fxm22 with SMTP id 22so4831331fxm.36 for ; Wed, 07 Oct 2009 07:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=/suv5zBwrNnUBvjOPOoNiuuu4P6gIPP4wda9JP/7BlU=; b=hjTGZQmsY4Ab2LeEx7gjulSIXV5BGFH0c4ynuB/mEoONpNbFlqu4LXoBbNJKDnkNER 1MtHPlEtw+z/JvdTvBSGeq6NA+Ff1f77b7DlkwmQT4HvjT2mvBLXF5ttbSH+epoTBmAr ON45XUCs6vkIRLGGEpHJbpfj2Q9DPHdTbv8Z8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=xnUnRw8H9g65hfVkQy611ZorwflNGB5c3UM/ygHgt/MRhzuedqKSeT8P8gvnOLu1Lz WSzHCDorRfyejgX3dtRJ7ah+UzBBBBPPWsTQ/znW74IfDLzc7+khWSblaiSFYXuZDlNL fwSzJZuLMrQDvUxoffoy8hDGvu7Jl12qtmM7c= Received: by 10.86.22.12 with SMTP id 12mr23845fgv.69.1254925022834; Wed, 07 Oct 2009 07:17:02 -0700 (PDT) Received: from mac-mini.lan (bl5-224-203.dsl.telepac.pt [82.154.224.203]) by mx.google.com with ESMTPS id d4sm534828fga.14.2009.10.07.07.17.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 07 Oct 2009 07:17:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Rui Paulo In-Reply-To: Date: Wed, 7 Oct 2009 15:17:00 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: To: Ian Freislich X-Mailer: Apple Mail (2.1076) X-Mailman-Approved-At: Wed, 07 Oct 2009 15:55:55 +0000 Cc: current@freebsd.org Subject: Re: urtw(4) feedback. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 14:46:20 -0000 On 7 Oct 2009, at 13:23, Ian Freislich wrote: > Hi > > FWIW, the manual can be updated to include support for the Linksys > WG111v3 adapter. Mine detects as follows: > > ugen4.3: at usbus4, cfg=0 md=HOST > spd=HIGH (480Mbps) pwr=ON > > urtw0: 3> on usbus4 > urtw0: rtl8187b rf rtl8225z2 hwrev e > > Opening it up confirms the presence of a RTL8187B. > > However throughput is very poor, I haven't been able to get more > than about 130kB/s and pings seem to be timed every 1.5 seconds. > This might help: http://p4db.freebsd.org/chv.cgi?CH=169276 -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 16:04:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 898B4106566B for ; Wed, 7 Oct 2009 16:04:23 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 12F9F8FC13 for ; Wed, 7 Oct 2009 16:04:22 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=GqLEGs8G9nuRgBIQ54oA:9 a=b-XV6MyxXhr9QMFLehMA:7 a=8eognya5aV4DfNbeaWQ7fUSzn30A:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1306247669; Wed, 07 Oct 2009 18:04:19 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 7 Oct 2009 18:05:07 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: In-Reply-To: X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910071805.09153.hselasky@c2i.net> Cc: Rui Paulo , Ian FREISLICH Subject: Re: urtw(4) feedback. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 16:04:23 -0000 On Wednesday 07 October 2009 17:10:58 Ian FREISLICH wrote: > Rui Paulo wrote: > > On 7 Oct 2009, at 13:23, Ian Freislich wrote: > > > urtw0: rtl8187b rf rtl8225z2 hwrev e > > > > > > Opening it up confirms the presence of a RTL8187B. > > > > > > However throughput is very poor, I haven't been able to get more > > > than about 130kB/s and pings seem to be timed every 1.5 seconds. > > > > This might help: > > http://p4db.freebsd.org/chv.cgi?CH=169276 > > Not significantly. The stability of the wireless association is > improved throughput is nearly doubled to 240kB/s, but there's some > wierdness: it responds to ping from "outside" almost immediately, > but when the host pings out, it spaces requests at about 1.6 seconds > (which it doesn't do on the alc0 interface). > > [mini] /usr/src/sys/modules/usb/urtw # time ping -c2 10.0.2.1 > PING 10.0.2.1 (10.0.2.1): 56 data bytes > 64 bytes from 10.0.2.1: icmp_seq=0 ttl=64 time=36.176 ms > 64 bytes from 10.0.2.1: icmp_seq=1 ttl=64 time=44.282 ms > > --- 10.0.2.1 ping statistics --- > 2 packets transmitted, 2 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 36.176/40.229/44.282/4.053 ms > > real 0m1.696s > user 0m0.000s > sys 0m0.001s > > It also takes about 10 seconds for the wlan0 interface to appear > after insertion. And if you use "ping -f" ? Could it be that it is only the last packet sent that is not flushed out? --HPS From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 17:36:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21BD1106566B for ; Wed, 7 Oct 2009 17:36:35 +0000 (UTC) (envelope-from christian@nertenher.de) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id AEBCA8FC18 for ; Wed, 7 Oct 2009 17:36:33 +0000 (UTC) Received: by fxm22 with SMTP id 22so5001955fxm.36 for ; Wed, 07 Oct 2009 10:36:32 -0700 (PDT) MIME-Version: 1.0 Sender: christian@nertenher.de Received: by 10.223.144.67 with SMTP id y3mr90420fau.20.1254936992298; Wed, 07 Oct 2009 10:36:32 -0700 (PDT) In-Reply-To: <1254842240.23831.22.camel@buffy.york.ac.uk> References: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> <1254842240.23831.22.camel@buffy.york.ac.uk> From: Christian Schmidt Date: Wed, 7 Oct 2009 19:36:12 +0200 X-Google-Sender-Auth: 48b792d462474159 Message-ID: <309b65830910071036h77276ee2jb2a9c7e82fe7ba9d@mail.gmail.com> To: Gavin Atkinson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Boot issues with a Dell Inspiron 530 and 8.0 RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 17:36:35 -0000 On Tue, Oct 6, 2009 at 17:17, Gavin Atkinson wrote: > On Tue, 2009-10-06 at 09:54 +0200, Christian Schmidt wrote: >> Hello list, >> >> I am seeing a strange issue with my Dell Inspiron 530 with 8.0 RC1-p1 >> at around 50-75% percent of all boots. It all boils down to GENERIC >> throwing the following: >> >> AP #1 (PHY #1) failed! >> panic y/n? [y] panic: bye-bye >> cpuid =3D 0 [...] > There are a couple of things that might be worth trying. =C2=A0Firstly, t= ry > playing with any USB-related options in the BIOS (especially "legacy > emulation" or similar. Okay, I had a look at that one but the BIOS does not feature a lot of options concerning USB. There was nothing about legacy emulation or anything remotely similar, so that was a dead-end. > Secondly, try editing src/sys/amd64/amd64/machdep.c > (or /sys/i386/i386/machdep.c if you are using i386), search for > "MacBook", and adding the output of the command > "kenv smbios.system.product" > to the list of strings compared. I tried that (with the help of some of the kind people from bsdforen.de ;-)) but that didn't fix the issue at all. Rebooting resulted in panic. Oddly enough, a complete poweroff and reboot from the old kernel worked well enough. Like I said: a cold-boot increases the chances significantly while a reboot is almost always bound to fail. > This may not make any difference, or may even make things worse (so keep > your backup kernel ready:) but it's worth a try. Well, it didn't immolate my machine so I'm fine. ;-) Thanks, Christian --=20 Todays mistakes are tomorrows catastrophes. From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 17:37:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43DB71065695 for ; Wed, 7 Oct 2009 17:37:17 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-bw0-f226.google.com (mail-bw0-f226.google.com [209.85.218.226]) by mx1.freebsd.org (Postfix) with ESMTP id C030C8FC13 for ; Wed, 7 Oct 2009 17:37:16 +0000 (UTC) Received: by bwz26 with SMTP id 26so4205824bwz.36 for ; Wed, 07 Oct 2009 10:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=uydyBCTMu8J3gllADfuDHDwnMmJjabLdne7Q8F+CpqU=; b=AY1EDuSdc/5Cox6ZmvgeeB7QrV/3Xo2K1UTew5fexCkuVDy4bWhF/P3hol0MgBp/Hq 6Ed9zAHaJqTLzSHb/uRFqJMrwGBOaU+p5XgbKS3GcdfG3MpS8XqngXk2xqbfa183FXB8 hcdLtjB6IdNUFTlqWOOwLH3ebxb6CGils0neg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=N2QFr65a9WfaY40K9WJS5iTtrS+ij5fo89k4E+2DHkaCt0uQA2vQi3GvAGYjqsD28h CxL3VK3slpL552i1UiYYJqc8o907ZtSL99AIGOTl4GxFPLFTka2UJYr7L6L2GPlfOaC4 E5L9Zt7MKS1ixoy4uXKknVCY8YWhkJQg1d2eY= Received: by 10.204.153.217 with SMTP id l25mr127885bkw.108.1254937035675; Wed, 07 Oct 2009 10:37:15 -0700 (PDT) Received: from localhost (lan-78-157-90-54.vln.skynet.lt [78.157.90.54]) by mx.google.com with ESMTPS id p9sm2898642fkb.0.2009.10.07.10.37.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 07 Oct 2009 10:37:14 -0700 (PDT) Date: Wed, 7 Oct 2009 20:36:55 +0300 From: Gleb Kurtsou To: Kamigishi Rei Message-ID: <20091007173655.GA11144@tops> References: <4ACBD4CA.3070300@haruhiism.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4ACBD4CA.3070300@haruhiism.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD-Current Subject: Re: ZFS-related panic, 8.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 17:37:17 -0000 On (07/10/2009 03:37), Kamigishi Rei wrote: > Hello, hope you're having a nice day, > > Alas, this time I didn't manage to get a dump, so only the panic message > is available: > panic: _sx_xlock_hard: recursed on non-recursive sx > zfsvfs->z_hold_mtx[i] @ > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1023 Do you run nullfs on top of zfs by any chance? I've seen something similar. It was caused by zfs -> getnewvnode -> zfs_inactive But information provided is not enough for debugging. Can you get full backtrace? > > -- > Kamigishi Rei > KREI-RIPE > _______________________________________________ > 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 Oct 7 18:04:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C24ED1065679 for ; Wed, 7 Oct 2009 18:04:18 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id 457C58FC1E for ; Wed, 7 Oct 2009 18:04:17 +0000 (UTC) Received: by fxm22 with SMTP id 22so5027805fxm.36 for ; Wed, 07 Oct 2009 11:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=bZcv/NpDpu6YD4Vs0pw2r2UokRWpzIO9loz4jUG4HUs=; b=jMdo7Vf9fzZW+yxaduNGusQlZ3dXXWVZIkhXx+6xdmR5MYCwPWZ2yMQkLyfeoa/uBL zhKcY9rOU/j8dPbPf3nJ5hy0bzDii87QRDK+TnQ6JhSBgQhA4JEyuIpyX8tdCk/gPQjO aA1+SxyrSbiMEh6TE9CyrrZsyNF+7lW+y5A6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=S3LysuHDdwhS5q3Yx3qvY8cySvcUjqWcnDDzuExFcmHTGjznApvn1U9ob6lK8qOISa AuRkgCVqO5pExjP9hNSS0cvmILcMATJHJpAQIChvCnYsDCC/duo0HXofRsekwPtp9G/Y AX1rtYcPdUBMxXEcVkdNgFz8bT8W6TchKCYXI= Received: by 10.103.84.15 with SMTP id m15mr76732mul.105.1254938656840; Wed, 07 Oct 2009 11:04:16 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id s10sm82233muh.54.2009.10.07.11.04.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 07 Oct 2009 11:04:11 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 7 Oct 2009 11:02:57 -0700 From: Pyun YongHyeon Date: Wed, 7 Oct 2009 11:02:57 -0700 To: Ian Freislich Message-ID: <20091007180257.GA3843@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: alc(4) link autoselect problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 07 Oct 2009 18:04:18 -0000 On Wed, Oct 07, 2009 at 08:00:42AM +0200, Ian Freislich wrote: > Hi > > On my recently acquired netbook (compaq mini-110), the ethernet > doesn't autoselect the link speed properly. I think this is because > HP chose the cheapest ethernet controler and the cheapest PHY and Don't know it's cheapest controller but alc(4) hardwares would be better than ale(4) hardwares. Due to lack of documentation I'm not sure but alc(4) seems to have a header split feature which I don't know how to enable the feature. > there's a speed missmatch (or the PHY isn't correctly detected): > > alc0: port 0xec80-0xecff mem 0xfebc0000-0xfebfffff irq 17 at device 0.0 on pci2 > alc0: 15872 Tx FIFO, 15360 Rx FIFO > alc0: Using 1 MSI message(s). > miibus0: on alc0 > atphy0: PHY 0 on miibus0 > atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > alc0: Ethernet address: 00:25:b3:6f:ab:9a > alc0: [FILTER] > > alc0@pci0:2:0:0: class=0x020000 card=0x308f103c chip=0x10621969 rev=0xc0 hdr=0x00 > vendor = 'Attansic (Now owned by Atheros)' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D3 current D0 > cap 05[48] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[58] = PCI-Express 1 endpoint max data 128(4096) link x1(x1) > cap 03[6c] = VPD > > The AR8132 is Fast Ethernet, but the Atheros F1 is gigabit capable. The atphy(4) recognizes PHY as F1 gigabit PHY because AR8132 uses the same PHY id of F1 gigabit PHY. There is no way to know whether it really has F1 gigabit PHY in driver's view. > If I set the media to 100BaseTX full-duplex it works. If link parter used auto-negotiation, this forced media selection shall make your link partner select half-duplex mode instead of full-duplex due to the nature of parallel detection. > I couldn't see link establishment issues on AR8132 sample board. Does link partner also see no link when you use auto-negotiation on alc(4)? Does your link partner support 1000baseT link? Can you see blinking LED of AR8132 when link was not established? How about unplugging UTP cable and then replug the cable after a couple of seconds? Does it make any difference? How about checking MIB statistics of controller? (sysctl dev.alc.0.stats) From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 18:05:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A8831065672 for ; Wed, 7 Oct 2009 18:05:33 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 10E678FC08 for ; Wed, 7 Oct 2009 18:05:32 +0000 (UTC) Received: from [41.154.0.10] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MvatH-0006cF-9O; Wed, 07 Oct 2009 20:05:31 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mvat7-000EjN-A6; Wed, 07 Oct 2009 20:05:21 +0200 To: Hans Petter Selasky From: Ian FREISLICH In-Reply-To: <200910071805.09153.hselasky@c2i.net> References: <200910071805.09153.hselasky@c2i.net> X-Attribution: BOFH Date: Wed, 07 Oct 2009 20:05:21 +0200 Message-Id: Cc: Rui Paulo , freebsd-current@freebsd.org Subject: Re: urtw(4) feedback. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 18:05:33 -0000 Hans Petter Selasky wrote: > On Wednesday 07 October 2009 17:10:58 Ian FREISLICH wrote: > > [mini] /usr/src/sys/modules/usb/urtw # time ping -c2 10.0.2.1 > > PING 10.0.2.1 (10.0.2.1): 56 data bytes > > 64 bytes from 10.0.2.1: icmp_seq=0 ttl=64 time=36.176 ms > > 64 bytes from 10.0.2.1: icmp_seq=1 ttl=64 time=44.282 ms > > > > --- 10.0.2.1 ping statistics --- > > 2 packets transmitted, 2 packets received, 0.0% packet loss > > round-trip min/avg/max/stddev = 36.176/40.229/44.282/4.053 ms > > > > real 0m1.696s > > user 0m0.000s > > sys 0m0.001s > > > > It also takes about 10 seconds for the wlan0 interface to appear > > after insertion. > > And if you use "ping -f" ? > > Could it be that it is only the last packet sent that is not flushed out? [mini] /usr/src # time ping -f -c2 10.0.2.1 PING 10.0.2.1 (10.0.2.1): 56 data bytes . --- 10.0.2.1 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 9.752/9.934/10.115/0.182 ms real 0m0.024s user 0m0.008s sys 0m0.001s however, 200 results in packet loss: [mini] /usr/src # time ping -f -c200 10.0.2.1 PING 10.0.2.1 (10.0.2.1): 56 data bytes .............. --- 10.0.2.1 ping statistics --- 200 packets transmitted, 187 packets received, 6.5% packet loss round-trip min/avg/max/stddev = 3.782/10.161/15.065/2.029 ms real 0m3.866s user 0m0.000s sys 0m0.034s Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 18:07:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1EB7106568F for ; Wed, 7 Oct 2009 18:07:23 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from mail.haruhiism.net (remilia.fujibayashi.jp [92.243.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id 7A4488FC1B for ; Wed, 7 Oct 2009 18:07:22 +0000 (UTC) Received: from [192.168.0.10] (datacenter.telecombusinessconsulting.net [77.221.137.211]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.haruhiism.net (Postfix) with ESMTPSA id 0570344E14; Thu, 8 Oct 2009 03:07:19 +0900 (JST) Message-ID: <4ACCD8DC.1030403@haruhiism.net> Date: Wed, 07 Oct 2009 22:07:24 +0400 From: Kamigishi Rei User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Gleb Kurtsou References: <4ACBD4CA.3070300@haruhiism.net> <20091007173655.GA11144@tops> In-Reply-To: <20091007173655.GA11144@tops> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: ZFS-related panic, 8.0-RC1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 18:07:23 -0000 On 07.10.2009 21:36, Gleb Kurtsou wrote: > panic: _sx_xlock_hard: recursed on non-recursive sx >> zfsvfs->z_hold_mtx[i] @ >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1023 >> > Do you run nullfs on top of zfs by any chance? > Indeed. I'm using ezjail suite, and it uses nullfs to link jail subdirectories to the base structure. > I've seen something similar. It was caused by > zfs -> getnewvnode -> zfs_inactive > But information provided is not enough for debugging. Can you get full > backtrace? > I've disabled gmirror so next time I'll probably get the backtrace. Note that with 8.0-BETA3, the previous revision I ran, nothing happened through 39+ days uptime with the same ezjail-based structure. -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 19:12:08 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44EBB106566B; Wed, 7 Oct 2009 19:12:08 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0E78C8FC12; Wed, 7 Oct 2009 19:12:07 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id AD6C73982C; Wed, 7 Oct 2009 21:12:03 +0200 (SAST) Date: Wed, 7 Oct 2009 21:12:03 +0200 From: John Hay To: "Bjoern A. Zeeb" Message-ID: <20091007191203.GA24065@zibbi.meraka.csir.co.za> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <20091005055806.GB58246@zibbi.meraka.csir.co.za> <20091005091708.J26486@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091005091708.J26486@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org, Hiroki Sato , freebsd-rc@FreeBSD.org Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration (was: Re: svn commit: r197145 - in head: etc/defaults share/man/man5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 19:12:08 -0000 Hi, Sorry I was away from keyboard for a few days. On Mon, Oct 05, 2009 at 09:25:18AM +0000, Bjoern A. Zeeb wrote: > On Mon, 5 Oct 2009, John Hay wrote: > > Hi, > > >On Mon, Oct 05, 2009 at 12:34:27PM +0900, Hiroki Sato wrote: > >>Hi, > >> > >> I would like your comments about merging the network_ipv6 -> netif > >> integration to stable/8. The issue of this rc.d script change is it > >> involves user-visible changes in rc.conf(5) variables as described in > >> UPDATING. > >> > >> I still want to do so before 8.0-R because the ND6 change in -CURRENT > >> needs updating IPv6-related rc.d scripts first. While the ND6 change > >> is not harmful from viewpoint of compatibility because basically it > >> just converts a global knob to a per-interface flag, handling it in > >> the rc.d scripts needs a kind of overhaul of rc.d/network_ipv6 and > >> rc.d/netif. > >> > >> The necessary changes have already been committed into -CURRENT. It > >> displays a warning to inform the users what is old in the rc.conf if > >> the user uses rc.d variables that have been changed, and at the same > >> time it keeps backward compatibility so that the old variables also > >> work. So, I think the impact is small enough, and this sort of > >> visible changes should be included in the .0 release rather than in > >> the middle of future 8.x releases. > >> > >> The patch for stable/8 can be found at: > >> > >> http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff > >> > >> This includes both of the ND6 kernel change and the rc.d script > >> change. If there is an objection from someone here I will put off > >> the merge until after 8.0-R. > > > >Is there a good reason why we still ship with ipv6 off by default? Most > >others seem to ship with ipv6 on. At least Windows, most linux flavours > >and Mac OS X which make out the rest of the machines on our network here > >at Meraka Institute. > > > >One thing that I have against the way the stuff in -current is done at > >the moment, is that it seems to be a lot more work to just get ipv6 to > >work. Either I did things wrong or we are taking a step backward. Make > >no mistake, I like the idea of being able to control it per interface, > >but it seems that you have to enable it per interface with a long string > >for each... I would rather that it is enabled everywhere by default and > >then you disbale it where you do not want it. > > > link-local had been enabled by default in the past and I am not sure > if we had a SA or EN for that or that it was just preemptively > disabled. > > The problem is that if it is enabled by default you are exposing > yourself to others on the same network. That is of course especially > bad if you are in untrusted environments like conferences, ... or on a > public LAN. For a while I hoped that we could return to the good old days, but I guess it is fear and terror nowadays. :-/ > If we'd support IPv4 link-local addresses by default we would have to > apply the same logic there. > > I am not sure about OSX but at least Windows has a firewall set to > deny any unrelated incoming things by default these days. Well depending on how narrow you look at it, we are not that far away from that. We have all network services off by default and if you install via sysinstall, you get a chance to enable the ones you want. :-) > > Just because others haven't yet (really) thought about the problems > doesn't mean they aren't there. > > If you want to use IPv4 you either add an address or start DHCP or .. > and you have to configure that. If you want IPv6, you configure that > as well. You shall not have anything enbaled by default that people > can use to attack you and you don't know about because you didn't > configure. > > While (we) IPv6 people know that it would be there a lot of people are > still totally unaware of IPv6 and they would be surprised. Ok I can understand why not have it totally enabled by default, but why not keep ipv6_enabled and let the user only have to add ipv6_enabled="YES" to his rc.conf and have the "normal" case of a client ipv6 box just work? Either on all interfaces or limited to maybe network_interfaces. After all, one of the aims of IPv6 was to make configuration easier for the "normal" client case. John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 20:08:47 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 646D6106568B; Wed, 7 Oct 2009 20:08:47 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id 283808FC1F; Wed, 7 Oct 2009 20:08:47 +0000 (UTC) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id n97K8juR097151; Wed, 7 Oct 2009 14:08:46 -0600 (MDT) Message-ID: <4ACCF548.2070200@FreeBSD.org> Date: Wed, 07 Oct 2009 14:08:40 -0600 From: Jamie Gritton User-Agent: Thunderbird 2.0.0.19 (X11/20090109) MIME-Version: 1.0 To: Rick Macklem References: <4ABD4BB9.1030804@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org, Marcel Moolenaar , Robert Watson , "current@freebsd.org mailing list" Subject: Re: 8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS related?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 20:08:47 -0000 Rick Macklem wrote: > On Sun, 27 Sep 2009, Robert Watson wrote: >> On Fri, 25 Sep 2009, Jamie Gritton wrote: >> >>> It seems to be NFS related. I think the null pointer in question is >>> from the export's anonymous credential. Try the patch below and see >>> if it helps (which I guess means run it overnight and see if it >>> crashes again). I've also patched a similar missing cred prison in >>> GSS_SVC, since I'm not versed enough in NFS/RPC stuff to know if it >>> might be the problem. >> >> This is one of the reasons I really dislike "magic" credentials and >> special handling of NULL credentials -- they always get into code the >> author doesn't expect, and either there are bad pointer dereferences, >> or incorrect security decisions. It's almost always the case that a >> correct credential should have been cached or generated at some >> earlier point to represent the security context... >> > I don't really understand prisons/jails, but would creating these > credentials via: > crdup(td->td_ucred); // duplicating the daemon thread's cred > - and then replacing the > make sense as an alternative to starting with crget()? > (ie. All the other stuff except would be "inherited" from the > credential for the daemon thread.) That sounds right to me for cases when the cred is based on passed UID/GIDs. Perhaps you'd want to use the UID-changing helper functions on kern_prot.c, or perhaps a new helper or helpers just for the circumstance. - Jamie From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 20:09:46 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F85B1065694 for ; Wed, 7 Oct 2009 20:09:46 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id EE6ED8FC1D for ; Wed, 7 Oct 2009 20:09:45 +0000 (UTC) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id n97K9iUU097285; Wed, 7 Oct 2009 14:09:45 -0600 (MDT) Message-ID: <4ACCF583.9030004@FreeBSD.org> Date: Wed, 07 Oct 2009 14:09:39 -0600 From: Jamie Gritton User-Agent: Thunderbird 2.0.0.19 (X11/20090109) MIME-Version: 1.0 To: Tom Judge References: <4ACA0549.7030404@tomjudge.com> <4ACA46D8.8010504@FreeBSD.org> <4ACBF2C2.4040004@tomjudge.com> In-Reply-To: <4ACBF2C2.4040004@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 20:09:46 -0000 Tom Judge wrote: > Jamie Gritton wrote: >> Tom Judge wrote: >>> Does anyone know of a patch that will add per jail memory limits so >>> that a jail can't swallow the resources of the entire box? >> >> Edward Tomasz Napierala has been working on a general resource limit >> framework, including jails and memory limits. You can find it at: >> http://p4db.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2009/trasz_limits >> >> >> - Jamie > Is this in the subversion projects tree? > > It seems the p4 is not very easy to access unless you have access server. Quite true - sorry I totally forgot that detail. Perhaps trasz has some tarballs or patches available. - Jamie From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 20:49:31 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37FA81065696 for ; Wed, 7 Oct 2009 20:49:31 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id D85AB8FC0A for ; Wed, 7 Oct 2009 20:49:30 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id E9FC2489D8; Wed, 7 Oct 2009 21:49:29 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAe66dI-L4SZ; Wed, 7 Oct 2009 21:49:26 +0100 (BST) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 6A69F489D1; Wed, 7 Oct 2009 21:49:25 +0100 (BST) Message-ID: <4ACCFEB1.1010306@tomjudge.com> Date: Wed, 07 Oct 2009 20:48:49 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz> References: <4ACA0549.7030404@tomjudge.com> <4ACBF147.1030002@tomjudge.com> <4ACC60EF.50104@quip.cz> In-Reply-To: <4ACC60EF.50104@quip.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-jail@FreeBSD.org Subject: Re: Per Jail Memory Limits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 07 Oct 2009 20:49:31 -0000 Miroslav Lachman wrote: > Tom Judge wrote: > >> So I have worked up some thing usable fore us based on the 7.0 code >> from the wiki. >> >> This patch is for 7.1 in implements both soft and hard memory limits. >> >> Details are here: >> http://www.tomjudge.com/index.php/FreeBSD/Jails/MemoryLimits >> >> Changes that add supporting infrastructure for cpu limiting are in >> the patch but changes to the schedulers have not been included. If >> you need the scheduling support you will need to patch sched_4bsd >> with the code from the original patch set here: >> >> http://lists.freebsd.org/pipermail/freebsd-jail/2008-June/000333.html >> >> Hope this is useful for some people. > > I added links to this thread and to your patch into wiki page > http://wiki.freebsd.org/Jails. I hope it will help people to find your > work. > Do you plan to make it for 7.2 and other future releases? Thanks for adding it to the wiki. It should be simple to apply to 7.2, I can try to knock out a patch in my spare time for this. However at this time I have no plans to take this any further, it seems plenty of people are working on this problem. Maybe one day there will be an in tree solution. Tom From owner-freebsd-current@FreeBSD.ORG Thu Oct 8 10:38:58 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB7551065676 for ; Thu, 8 Oct 2009 10:38:58 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id F11DB8FC13 for ; Thu, 8 Oct 2009 10:38:57 +0000 (UTC) Received: from [41.154.0.10] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MvqOc-000477-GN; Thu, 08 Oct 2009 12:38:54 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvqOT-0000Oo-7F; Thu, 08 Oct 2009 12:38:45 +0200 To: pyunyh@gmail.com From: Ian FREISLICH In-Reply-To: <20091007180257.GA3843@michelle.cdnetworks.com> References: <20091007180257.GA3843@michelle.cdnetworks.com> X-Attribution: BOFH Date: Thu, 08 Oct 2009 12:38:45 +0200 Message-Id: Cc: current@freebsd.org Subject: Re: alc(4) link autoselect problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Oct 2009 10:38:58 -0000 Pyun YongHyeon wrote: > The atphy(4) recognizes PHY as F1 gigabit PHY because AR8132 uses > the same PHY id of F1 gigabit PHY. There is no way to know whether > it really has F1 gigabit PHY in driver's view. > > > If I set the media to 100BaseTX full-duplex it works. > > If link parter used auto-negotiation, this forced media selection > shall make your link partner select half-duplex mode instead of > full-duplex due to the nature of parallel detection. When I do this: [mini] /usr/home/ianf # ifconfig alc0 media 100BaseTX mediaopt full-duplex I get this on the switch: 08-Oct-2009 12:26:42 %STP-W-PORTSTATUS: g14 of instance 0: STP status Forwarding 08-Oct-2009 12:26:42 %STP-W-PORTSTATUS: g14 of instance 1: STP status Forwarding 08-Oct-2009 12:26:42 %STP-W-PORTSTATUS: g14 of instance 2: STP status Forwarding 08-Oct-2009 12:26:42 %LINK-I-Up: g14 wgsw-24010# sh interfaces status ethernet g14 Flow Link Back Mdix Port Type Duplex Speed Neg ctrl State Pressure Mode -------- ------------ ------ ----- -------- ---- ----------- -------- ------- g14 1G-Copper Full 100 Enabled Off Up Disabled Off So, it correctly detects full duplex. The cable tester still reports the cable os open at 2m, probably because it expects all 4 pairs to be terminated. > I couldn't see link establishment issues on AR8132 sample board. > Does link partner also see no link when you use auto-negotiation on > alc(4)? I get no link, not even temporary blips on the link light. When I invoke the cable tester, this is what I see: wgsw-24010# test copper-port tdr g14 .. Cable on port g14 is open at 2 m > Does your link partner support 1000baseT link? Yes, it does. > Can you see blinking LED of AR8132 when link was not established? No. > How about unplugging UTP cable and then replug the cable after > a couple of seconds? Does it make any difference? No difference either. > How about checking MIB statistics of controller? > (sysctl dev.alc.0.stats) This is after a reboot, but the link was up for a short while to do the above testing. rx.good_frames looks a bit high for "up 21 mins". dev.alc.0.stats.rx.good_frames: 3348588249 dev.alc.0.stats.rx.good_bcast_frames: 0 dev.alc.0.stats.rx.good_mcast_frames: 0 dev.alc.0.stats.rx.pause_frames: 0 dev.alc.0.stats.rx.control_frames: 0 dev.alc.0.stats.rx.crc_errs: 0 dev.alc.0.stats.rx.len_errs: 0 dev.alc.0.stats.rx.good_octets: 0 dev.alc.0.stats.rx.good_bcast_octets: 0 dev.alc.0.stats.rx.good_mcast_octets: 0 dev.alc.0.stats.rx.runts: 0 dev.alc.0.stats.rx.fragments: 0 dev.alc.0.stats.rx.frames_64: 13 dev.alc.0.stats.rx.frames_65_127: 5 dev.alc.0.stats.rx.frames_128_255: 181 dev.alc.0.stats.rx.frames_256_511: 2 dev.alc.0.stats.rx.frames_512_1023: 0 dev.alc.0.stats.rx.frames_1024_1518: 0 dev.alc.0.stats.rx.frames_1519_max: 0 dev.alc.0.stats.rx.trunc_errs: 0 dev.alc.0.stats.rx.fifo_oflows: 0 dev.alc.0.stats.rx.rrs_errs: 0 dev.alc.0.stats.rx.align_errs: 0 dev.alc.0.stats.rx.filtered: 201 dev.alc.0.stats.tx.good_frames: 0 dev.alc.0.stats.tx.good_bcast_frames: 0 dev.alc.0.stats.tx.good_mcast_frames: 0 dev.alc.0.stats.tx.pause_frames: 0 dev.alc.0.stats.tx.control_frames: 0 dev.alc.0.stats.tx.excess_defers: 0 dev.alc.0.stats.tx.defers: 0 dev.alc.0.stats.tx.good_octets: 0 dev.alc.0.stats.tx.good_bcast_octets: 0 dev.alc.0.stats.tx.good_mcast_octets: 0 dev.alc.0.stats.tx.frames_64: 0 dev.alc.0.stats.tx.frames_65_127: 0 dev.alc.0.stats.tx.frames_128_255: 0 dev.alc.0.stats.tx.frames_256_511: 0 dev.alc.0.stats.tx.frames_512_1023: 0 dev.alc.0.stats.tx.frames_1024_1518: 0 dev.alc.0.stats.tx.frames_1519_max: 0 dev.alc.0.stats.tx.single_colls: 0 dev.alc.0.stats.tx.multi_colls: 0 dev.alc.0.stats.tx.late_colls: 0 dev.alc.0.stats.tx.excess_colls: 0 dev.alc.0.stats.tx.abort: 0 dev.alc.0.stats.tx.underruns: 0 dev.alc.0.stats.tx.desc_underruns: 0 dev.alc.0.stats.tx.len_errs: 0 dev.alc.0.stats.tx.trunc_errs: 0 dev.alc.0.stats.rx.filtered is not climbing with outo-negotiate enabled. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Thu Oct 8 12:42:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8B3F1065670 for ; Thu, 8 Oct 2009 12:42:26 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 227E38FC14 for ; Thu, 8 Oct 2009 12:42:25 +0000 (UTC) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.3/8.14.3) with ESMTP id n98CU1xB083018 for ; Thu, 8 Oct 2009 16:30:01 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1255005002; bh=X1U4OtFcHctITZDrOeAXiaYyo/vyRQQ5dNGNzMGV9O0=; l=339; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=HY25Y3dlXaY8auPOT2/8sAHubSEfZLvS60Kcx0NpQd2emLBWoxmRB9XW4VTN2aScI A8JF90xnkgczQf39Qu5UMNR5JqvMody6YpyX4jf2yyNUImC5RXDCYkS/6jj63AZYYy JqFGvin5wXY2o4GvsBBfUTkgzhOAPNinoteVuAa4= Received: (from ache@localhost) by nagual.pp.ru (8.14.3/8.14.3/Submit) id n98CU1PI083017 for freebsd-current@freebsd.org; Thu, 8 Oct 2009 16:30:01 +0400 (MSD) (envelope-from ache) Date: Thu, 8 Oct 2009 16:30:01 +0400 From: Andrey Chernov To: freebsd-current@freebsd.org Message-ID: <20091008123001.GA82997@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , freebsd-current@freebsd.org References: <20091004090156.GA85409@crete.org.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091004090156.GA85409@crete.org.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 'ee' editor prints cyrillic characters on white background X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Oct 2009 12:42:26 -0000 On Sun, Oct 04, 2009 at 12:01:56PM +0300, Alexander Shikoff wrote: > Hello, > > I've upgraded my 7.2-RELEASE to 8.0-RC1. ee editor began to highlight > cyrillic characters (locale uk_UA.KOI8-U) with white background and > underscoring. Does anyone know how to disable this? Thanks. Fixed in -current. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Thu Oct 8 13:08:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76DE5106568B for ; Thu, 8 Oct 2009 13:08:39 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 0D1CC8FC1F for ; Thu, 8 Oct 2009 13:08:38 +0000 (UTC) Received: from [41.154.0.10] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MvsjU-0008BK-FM; Thu, 08 Oct 2009 15:08:36 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvsjS-0000mS-Uh; Thu, 08 Oct 2009 15:08:34 +0200 To: Tim Kientzle From: Ian FREISLICH In-Reply-To: <4ABAF113.9030904@freebsd.org> References: <4ABAF113.9030904@freebsd.org> <20090922212905.GA77503@sysmon.tcworks.net> X-Attribution: BOFH Date: Thu, 08 Oct 2009 15:08:34 +0200 Message-Id: Cc: freebsd-current@freebsd.org Subject: Re: Nagios SIGSEGV on FreeBSD 8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Oct 2009 13:08:39 -0000 Tim Kientzle wrote: > Scott Lambert wrote: > > I've posted this to FreeBSD-ports and Nagios-Users without a nibble. > > > > [New Thread 28326280 (LWP 100051)] > > [New Thread 28301140 (LWP 100222)] > > (gdb) bt > > #0 0x0807fe8b in get_next_comment_by_host () > > #1 0x08080940 in delete_host_acknowledgement_comments () > > #2 0x28331180 in ?? () > > #3 0x4aaac053 in ?? () > > #4 0x080cc394 in __JCR_LIST__ () > > Build with debug symbols and try again; maybe you can get > more detail. Also, check a couple of core dumps to > see if it's crashing in the same place; that might > also give a clue. > > Do the "New Thread" messages mean that Nagios is running > multiple threads? If so, I wonder what the other > thread is doing? > We've been trying to combat a performance issue in Nagios. One thread handles incoming events (nsca etc) and data from the nagios.cmd pipe file and writes files for processing in /var/spool/nagios/checkresults. The other thread processes these files and updates the host state and other data. The threading broke profiling (I think) because when Nagios was compiled with -pg it did no more than read its configuration, but this alone was a pointer to the area that Nagios is poorly optimised - string processing. Reading our configuration resulted in 65000000 calls to strcmp. 65 Million!! We're battling to keep up with passive events from about 5000 hosts every few minutes. The nagios.cmd thread struggles to keep up reading from the fifo when there a about 4000 writers. And the worker thread struggles parse the checkresults files - they're big, but not *that* big, maybe 80k to 120k lines which it takes about 7 minutes to parse. We also had to up kern.maxusers="1024" and kern.ipc.nmbclusters="131072" to prevent the system starving network resources. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Thu Oct 8 13:56:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 912951065670 for ; Thu, 8 Oct 2009 13:56:48 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6B3038FC14 for ; Thu, 8 Oct 2009 13:56:48 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id DD69B46B1A; Thu, 8 Oct 2009 09:56:47 -0400 (EDT) Date: Thu, 8 Oct 2009 14:56:47 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kamigishi Rei In-Reply-To: <4AC61ED6.1090802@haruhiism.net> Message-ID: References: <4AC61ED6.1090802@haruhiism.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD-Current Subject: Believed fixed (was: Re: Another panic (during netisr?)) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Oct 2009 13:56:48 -0000 On Fri, 2 Oct 2009, Kamigishi Rei wrote: > Hello, hope you're having a nice day, > > This is on FreeBSD 8.0-BETA3 (Ameagari) #23 r196460: Mon Aug 24 00:36:33 JST > 2009; not sure if it has been witnessed or fixed. I've been running it > without restarts to test the stability and here we go: Since debugging this went offline, the quick summary for the list is: it looks like a race condition in the read-write locking for tcbinfo in 8.x/9.x was responsible, and I've now committed a fix to head and merged to stable/8 this morning. If this recurs with the fix, please let me know, because that would mean we fixed the wrong bug. :-) Robert > > Unread portion of the kernel message buffer: > panic: tcp_input: so == NULL > cpuid = 0 > Uptime: 39d15h40m53s > > (kgdb) #0 doadump () at pcpu.h:223 > #1 0xffffffff805ab6d3 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:416 > #2 0xffffffff805abb2c in panic (fmt=Variable "fmt" is not available. > ) > at /usr/src/sys/kern/kern_shutdown.c:579 > #3 0xffffffff80725543 in tcp_input (m=0xffffff00672a8300, off0=Variable > "off0" is not available. > ) > at /usr/src/sys/netinet/tcp_input.c:737 > #4 0xffffffff806bea9c in ip_input (m=0xffffff00672a8300) > at /usr/src/sys/netinet/ip_input.c:775 > #5 0xffffffff8065d478 in netisr_dispatch_src (proto=1, source=Variable > "source" is not available. > ) > at /usr/src/sys/net/netisr.c:917 > #6 0xffffffff80655b7d in ether_demux (ifp=0xffffff0001656000, > m=0xffffff00672a8300) at /usr/src/sys/net/if_ethersubr.c:895 > #7 0xffffffff80655fa5 in ether_input (ifp=0xffffff0001656000, > m=0xffffff00672a8300) at /usr/src/sys/net/if_ethersubr.c:754 > #8 0xffffffff80347f64 in em_rxeof (adapter=0xffffff80002b0000, count=4) > at /usr/src/sys/dev/e1000/if_em.c:4605 > #9 0xffffffff80349d05 in em_poll (ifp=0xffffff0001656000, cmd=Variable "cmd" > is not available. > ) > at /usr/src/sys/dev/e1000/if_em.c:1657 > #10 0xffffffff8059fa17 in netisr_poll () at /usr/src/sys/kern/kern_poll.c:448 > #11 0xffffffff8065cd56 in swi_net (arg=0xffffffff80eb7800) > at /usr/src/sys/net/netisr.c:748 > #12 0xffffffff80585398 in intr_event_execute_handlers (p=Variable "p" is not > available. > ) > at /usr/src/sys/kern/kern_intr.c:1165 > #13 0xffffffff80585ff2 in ithread_loop (arg=0xffffff00014d8660) > at /usr/src/sys/kern/kern_intr.c:1178 > #14 0xffffffff805832ea in fork_exit ( > callout=0xffffffff80585f40 , arg=0xffffff00014d8660, > frame=0xffffff8000032c80) at /usr/src/sys/kern/kern_fork.c:838 > #15 0xffffffff8087a24e in fork_trampoline () > at /usr/src/sys/amd64/amd64/exception.S:561 > > -- > Kamigishi Rei > KREI-RIPE > fujibayashi.jp > _______________________________________________ > 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 Thu Oct 8 14:59:04 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD9AC1065670; Thu, 8 Oct 2009 14:59:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 26DE68FC0A; Thu, 8 Oct 2009 14:59:03 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n98Ex0Ir069921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Oct 2009 17:59:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n98Ex0Sv059499; Thu, 8 Oct 2009 17:59:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n98Ex0nQ059498; Thu, 8 Oct 2009 17:59:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 8 Oct 2009 17:59:00 +0300 From: Kostik Belousov To: current@freebsd.org, arch@freebsd.org Message-ID: <20091008145900.GK2259@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p+SyGXcYc+aq/C8k" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Subject: PIE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Oct 2009 14:59:04 -0000 --p+SyGXcYc+aq/C8k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline There is a patch, that should provide more or less proper support for PIE (Position Independent Executables). Besides being desirable feature itself, this is needed to be able to execute PIE binaries, both native FreeBSD and Linux images, with sysctl security.bsd.map_at_zero=0. In particular, Samba port is affected. gdb does not work for PIE binaries, I believe this is a gdb shortcoming. Patch was reviewed by Alexander Kabaev, discussed with Bjoern A. Zeeb, who tested i386 and amd64, and tested by Boris Samorodov for Linux binaries. I am asking for general testing for the patch. Also, I would ask the architecture maintainers to look for the per-arch mapbase address selected for the PIE binaries. http://people.freebsd.org/~kib/misc/pie.5.patch --p+SyGXcYc+aq/C8k Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrN/jMACgkQC3+MBN1Mb4iDzQCfUrr/kLoY+6HsM7SN5prNXhdr xMQAn0L1RMTx254+EcL0gMVhpq1nDptV =6md9 -----END PGP SIGNATURE----- --p+SyGXcYc+aq/C8k-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 8 17:02:30 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33B10106568B; Thu, 8 Oct 2009 17:02:30 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 1AEE58FC13; Thu, 8 Oct 2009 17:02:30 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n98H2THV008175; Thu, 8 Oct 2009 10:02:29 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n98H2Thm008171; Thu, 8 Oct 2009 10:02:29 -0700 (PDT) (envelope-from sgk) Date: Thu, 8 Oct 2009 10:02:29 -0700 From: Steve Kargl To: Kostik Belousov Message-ID: <20091008170229.GA75042@troutmask.apl.washington.edu> References: <20091008145900.GK2259@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091008145900.GK2259@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org, current@freebsd.org Subject: Re: PIE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Oct 2009 17:02:30 -0000 On Thu, Oct 08, 2009 at 05:59:00PM +0300, Kostik Belousov wrote: > > gdb does not work for PIE binaries, I believe this is a gdb shortcoming. > gdb 7.0 was released on Oct 6th. It appears to work fine with PIE. (Yes, I know that gdb 7.0 is unlikely to appear in FreeBSD.) -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Oct 8 17:06:14 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B895410656A6 for ; Thu, 8 Oct 2009 17:06:14 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 4231A8FC14 for ; Thu, 8 Oct 2009 17:06:13 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 16so2028826fgg.13 for ; Thu, 08 Oct 2009 10:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=A7IfOnn76JrcPJ3kURguy2TYeRs/cqJb1PKKl8y8qLE=; b=pluCvqqZIk0tmYGIMmjZrULbP9bKIEZBJjatmUR8HxnVC6OYiY/GhIzUxdzpYBdhy7 P5RLrsav3y1Zxn/GvZlwPH4kj3GhpV/X1G33DphmYHZFFrClApbRpfgWxpNYSGdVdQh5 UCetYYolINKWpArS0MUSA97ySBJW+Zqx+MdsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=cpTwQNbKFzF9g/vI8KHtpVmdSSFM2KAhMFPwdNS1vpEFOdsxqyhUgs3UqyRiTZR2VV uTyAAC+YcuWtMkBxhqMAOQU+P7S7n6u0mJOD1gqZRZaaL2H2u4AzOhqSHNo6h3B0FR7s 5C93KI9K+9420GQzyuhAVx0/QWyFRZZz2K3KI= Received: by 10.86.173.4 with SMTP id v4mr1375473fge.78.1255021573107; Thu, 08 Oct 2009 10:06:13 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 4sm104111fgg.28.2009.10.08.10.06.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 08 Oct 2009 10:06:10 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 8 Oct 2009 10:04:58 -0700 From: Pyun YongHyeon Date: Thu, 8 Oct 2009 10:04:58 -0700 To: Ian FREISLICH Message-ID: <20091008170458.GC3843@michelle.cdnetworks.com> References: <20091007180257.GA3843@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: alc(4) link autoselect problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Thu, 08 Oct 2009 17:06:14 -0000 On Thu, Oct 08, 2009 at 12:38:45PM +0200, Ian FREISLICH wrote: > Pyun YongHyeon wrote: > > The atphy(4) recognizes PHY as F1 gigabit PHY because AR8132 uses > > the same PHY id of F1 gigabit PHY. There is no way to know whether > > it really has F1 gigabit PHY in driver's view. > > > > > If I set the media to 100BaseTX full-duplex it works. > > > > If link parter used auto-negotiation, this forced media selection > > shall make your link partner select half-duplex mode instead of > > full-duplex due to the nature of parallel detection. > > When I do this: > [mini] /usr/home/ianf # ifconfig alc0 media 100BaseTX mediaopt full-duplex > > I get this on the switch: > > 08-Oct-2009 12:26:42 %STP-W-PORTSTATUS: g14 of instance 0: STP status Forwarding > 08-Oct-2009 12:26:42 %STP-W-PORTSTATUS: g14 of instance 1: STP status Forwarding > 08-Oct-2009 12:26:42 %STP-W-PORTSTATUS: g14 of instance 2: STP status Forwarding > 08-Oct-2009 12:26:42 %LINK-I-Up: g14 > > wgsw-24010# sh interfaces status ethernet g14 > Flow Link Back Mdix > Port Type Duplex Speed Neg ctrl State Pressure Mode > -------- ------------ ------ ----- -------- ---- ----------- -------- ------- > g14 1G-Copper Full 100 Enabled Off Up Disabled Off > Hmm, does your switch have an option to enable/disable downshifting feature? If so, how about toggling the option? > So, it correctly detects full duplex. > > The cable tester still reports the cable os open at 2m, probably > because it expects all 4 pairs to be terminated. > [...] > > How about checking MIB statistics of controller? > > (sysctl dev.alc.0.stats) > > This is after a reboot, but the link was up for a short while to > do the above testing. rx.good_frames looks a bit high for "up 21 > mins". > > dev.alc.0.stats.rx.good_frames: 3348588249 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > dev.alc.0.stats.rx.good_bcast_frames: 0 > dev.alc.0.stats.rx.good_mcast_frames: 0 > dev.alc.0.stats.rx.pause_frames: 0 > dev.alc.0.stats.rx.control_frames: 0 > dev.alc.0.stats.rx.crc_errs: 0 > dev.alc.0.stats.rx.len_errs: 0 > dev.alc.0.stats.rx.good_octets: 0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Yeah, that looks odd, it seemed controller received a lot of good frames but none were meaningful packets so I guess there are link establishment issues. I still have no clue but if I manage to find more test case I will let you know. > dev.alc.0.stats.rx.good_bcast_octets: 0 > dev.alc.0.stats.rx.good_mcast_octets: 0 [...] From owner-freebsd-current@FreeBSD.ORG Thu Oct 8 19:09:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D315106566B for ; Thu, 8 Oct 2009 19:09:49 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe13.swipnet.se [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id AA4E98FC13 for ; Thu, 8 Oct 2009 19:09:48 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=7H_uI1Jp-TAA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=7o0vgxtEv0OaWoPWRUQA:9 a=W1AdtfT8KQEDeUfaTPUsA-dZUtcA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe13.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 929858533; Thu, 08 Oct 2009 20:09:44 +0200 Received-SPF: softfail receiver=mailfe13.swip.net; client-ip=188.126.201.140; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Thu, 8 Oct 2009 20:10:34 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200909251909.31503.hselasky@freebsd.org> <4ABE2B4F.6080104@tomjudge.com> <200909271950.55189.hselasky@freebsd.org> In-Reply-To: <200909271950.55189.hselasky@freebsd.org> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910082010.36621.hselasky@freebsd.org> Cc: Tom Judge , freebsd-current@freebsd.org Subject: Re: Polling support for USB serial port adapters [patches] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Oct 2009 19:09:49 -0000 On Sunday 27 September 2009 19:50:54 Hans Petter Selasky wrote: > Hi, > > Here is a patchset which you can try. > > http://perforce.freebsd.org/chv.cgi?CH=168932 > > You need to download at least: > > usb_serial.h > and > usb_serial.c > > Download serial port drivers as needed. > > You need to at least recompile all USB serial modules. > > To enable you set: > > hw.usb.ucom.cons_unit=0 > hw.usb.ucom.cons_baud=9600 > > In /boot/loader.conf > > NOTE: The patches have not been tested yet, only carefully reviewed. If you > experience any problems, please debug and send patch to me. > Has anyone tried this out? --HPS From owner-freebsd-current@FreeBSD.ORG Thu Oct 8 23:09:38 2009 Return-Path: Delivered-To: FreeBSD-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 430131065672 for ; Thu, 8 Oct 2009 23:09:38 +0000 (UTC) (envelope-from ehrmann@gmail.com) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by mx1.freebsd.org (Postfix) with ESMTP id 1C75D8FC17 for ; Thu, 8 Oct 2009 23:09:37 +0000 (UTC) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id 1DDDC2FDC3D for ; Thu, 8 Oct 2009 18:54:16 -0400 (EDT) Received: from [10.0.0.171] (unknown [64.9.236.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4030A22E264 for ; Thu, 8 Oct 2009 18:54:12 -0400 (EDT) Message-ID: <4ACE6D84.3000209@gmail.com> Date: Thu, 08 Oct 2009 15:53:56 -0700 From: David Ehrmann User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: FreeBSD-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 08 Oct 2009 23:31:14 +0000 Cc: Subject: 8.0rc1 not recognizing partitions on EPIA SN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Oct 2009 23:09:38 -0000 First, I tried to upgrade the normal way. I built my own kernel and installed it, but when I tried to boot it, I got a mountroot> prompt. When I printed the devices, instead of seeing ad0s1a and friends, I saw ad0a and ad0d (just those two for ad0). I was still able to use the old (7.1) kernel fine. Thinking it was something to do with the upgrade, I tried to do a reinstall. I chose the default options, but once it got to the "last chance..." screen, this happened: Unable to find device node for /dev/ad0s1b in /dev! The creation of filesystems will be aborted. Needless to say, the installation failed. Like I said in the subject, this is with a VIA EPIA SN motherboard. The hard drive is a CF card in a slot on the board. The card's worked fine in the past, and was detected fine at partitioning time. Forgive me if this is the wrong list, and please CC me as I am not on the mailing list. From owner-freebsd-current@FreeBSD.ORG Fri Oct 9 00:37:45 2009 Return-Path: Delivered-To: FreeBSD-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14A871065676 for ; Fri, 9 Oct 2009 00:37:45 +0000 (UTC) (envelope-from tom@uffner.com) Received: from eris.uffner.com (uffner.com [66.208.243.25]) by mx1.freebsd.org (Postfix) with ESMTP id A10798FC13 for ; Fri, 9 Oct 2009 00:37:43 +0000 (UTC) Received: from xiombarg.uffner.com (static-71-162-143-94.phlapa.fios.verizon.net [71.162.143.94]) (authenticated bits=0) by eris.uffner.com (8.14.3/8.14.3) with ESMTP id n990Sjpl004060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Oct 2009 20:28:54 -0400 (EDT) (envelope-from tom@uffner.com) Message-ID: <4ACE833A.3030506@uffner.com> Date: Thu, 08 Oct 2009 20:26:34 -0400 From: Tom Uffner User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.23) Gecko/20090925 SeaMonkey/1.1.18 MIME-Version: 1.0 To: David Ehrmann References: <4ACE6D84.3000209@gmail.com> In-Reply-To: <4ACE6D84.3000209@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-current@freebsd.org Subject: Re: 8.0rc1 not recognizing partitions on EPIA SN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2009 00:37:45 -0000 David Ehrmann wrote: > First, I tried to upgrade the normal way. I built my own kernel and > installed it, but when I tried to boot it, I got a mountroot> prompt. > When I printed the devices, instead of seeing ad0s1a and friends, I saw > ad0a and ad0d (just those two for ad0). I was still able to use the old > (7.1) kernel fine. Thinking it was something to do with the upgrade, I > tried to do a reinstall. I chose the default options, but once it got > to the "last chance..." screen, this happened: > > Unable to find device node for /dev/ad0s1b in /dev! > The creation of filesystems will be aborted. this is becoming an FAQ for 8.0 the short answer is "dangerously dedicated" partitions are not supported by the 8.0 installer. back up your data. zero the MBR & partition table with dd, and re-slice & partition your disk. after the install, restore from your backups. search the freebsd-current archives for full details. From owner-freebsd-current@FreeBSD.ORG Fri Oct 9 03:23:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CF201065676; Fri, 9 Oct 2009 03:23:18 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id 8930C8FC12; Fri, 9 Oct 2009 03:23:17 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id n993NFZb058925; Thu, 8 Oct 2009 22:23:15 -0500 (CDT) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: content-type:content-transfer-encoding; b=DGNyy3zPJfzALJo8rbBwlqmC4hJDW23ffwYtQTLkcbNTOtq25jCoSsuptGReyqUTX DXEPow0r5u/UC8sB0Z8/uu7yPACz5/VMKQnOal/r8aajMWV51hucQzx4RsCx4ZstPZ9 +BFY2H/bqcjasSyn+QUlT0mHhkNHRhjDMQspQvw= Message-ID: <4ACEACA3.9070702@jrv.org> Date: Thu, 08 Oct 2009 22:23:15 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin Subject: [Fwd: siis change] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2009 03:23:18 -0000 mav committed a change to SIIS so I tried it but still get the device hangs as before. I should have sent that report here instead of to mav. ch1 below connects to a port multiplier and ada3 is one of four disks behind ch1. Does disk ada3 ever get reset, or the link between the port multiplier behind ch1 and ada3 ever get reinitialized? I'm wondering if the port multiplier is the key. I don't see any code to reset ada3 or at least stop/start its PHY link. It takes about an hour for "zpool scrub" to hang. -------- Original Message -------- Subject: siis change Date: Thu, 08 Oct 2009 18:06:01 -0500 From: James R. Van Artsdalen To: Alexander Motin I see you dropped in a change to SIIS for timeout errors so I decided to give it a try. It still hangs for me. FreeBSD pygmy.housenet.jrv 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r197866: Thu Oct 8 16:32:18 CDT 2009 root@pygmy.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 I did a "zpool scrub" which was generally running at about 100 MB/s across six 2 TB disks in two port multiplier enclosures. Here is that complete /var/log/messages. Oct 8 17:47:54 pygmy kernel: siisch1: Timeout on slot 3 Oct 8 17:47:54 pygmy kernel: siisch1: siis_timeout is 00000000 ss 00028308 rs 00028308 es 00000000 sts 80032000 serr 00000000 Oct 8 17:47:54 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:47:54 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:24 pygmy kernel: siisch1: Timeout on slot 29 Oct 8 17:48:24 pygmy kernel: siisch1: siis_timeout is 00040000 ss 60000007 rs 60000007 es 00000000 sts 801d2000 serr 00000000 Oct 8 17:48:24 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:48:24 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:54 pygmy kernel: siisch1: Timeout on slot 3 Oct 8 17:48:54 pygmy kernel: siisch1: siis_timeout is 00040000 ss 000000f8 rs 000000f8 es 00000000 sts 80032000 serr 00000000 Oct 8 17:48:54 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:48:54 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:49:24 pygmy kernel: siisch1: Timeout on slot 8 Oct 8 17:49:24 pygmy kernel: siisch1: siis_timeout is 00040000 ss 00001f00 rs 00001f00 es 00000000 sts 80082000 serr 00000000 Oct 8 17:49:24 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:49:24 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:49:54 pygmy kernel: siisch1: Timeout on slot 13 Oct 8 17:49:54 pygmy kernel: siisch1: siis_timeout is 00040000 ss 0003e000 rs 0003e000 es 00000000 sts 800d2000 serr 00000000 Oct 8 17:49:54 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:49:54 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): error 5 Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Retries Exhausted Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:24 pygmy kernel: siisch1: Timeout on slot 18 Oct 8 17:50:24 pygmy kernel: siisch1: siis_timeout is 00040000 ss 00fc0000 rs 00fc0000 es 00000000 sts 80122000 serr 00000000 Oct 8 17:50:24 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:50:24 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:54 pygmy kernel: siisch1: Timeout on slot 24 Oct 8 17:50:54 pygmy kernel: siisch1: siis_timeout is 00040000 ss 3f000000 rs 3f000000 es 00000000 sts 80182000 serr 00000000 Oct 8 17:50:54 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:50:54 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:24 pygmy kernel: siisch1: Timeout on slot 30 Oct 8 17:51:24 pygmy kernel: siisch1: siis_timeout is 00040000 ss 4000001f rs 4000001f es 00000000 sts 801e2000 serr 00000000 Oct 8 17:51:24 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:51:24 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:54 pygmy kernel: siisch1: Timeout on slot 5 Oct 8 17:51:54 pygmy kernel: siisch1: siis_timeout is 00040000 ss 000007e0 rs 000007e0 es 00000000 sts 80052000 serr 00000000 Oct 8 17:51:54 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:51:54 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:24 pygmy kernel: siisch1: Timeout on slot 11 Oct 8 17:52:24 pygmy kernel: siisch1: siis_timeout is 00040000 ss 0001f800 rs 0001f800 es 00000000 sts 800b2000 serr 00000000 Oct 8 17:52:24 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:52:24 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:54 pygmy kernel: siisch1: Timeout on slot 17 Oct 8 17:52:54 pygmy kernel: siisch1: siis_timeout is 00040000 ss 007e0000 rs 007e0000 es 00000000 sts 80112000 serr 00000000 Oct 8 17:52:54 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:52:54 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): error 5 Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Retries Exhausted Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:53:24 pygmy kernel: siisch1: Timeout on slot 23 Oct 8 17:53:24 pygmy kernel: siisch1: siis_timeout is 00040000 ss 3f800000 rs 3f800000 es 00000000 sts 80172000 serr 00000000 Oct 8 17:53:24 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:53:24 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command [root@pygmy ~]# From owner-freebsd-current@FreeBSD.ORG Fri Oct 9 02:21:06 2009 Return-Path: Delivered-To: FreeBSD-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D13BA1065672 for ; Fri, 9 Oct 2009 02:21:06 +0000 (UTC) (envelope-from ehrmann@gmail.com) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by mx1.freebsd.org (Postfix) with ESMTP id A82F88FC29 for ; Fri, 9 Oct 2009 02:21:05 +0000 (UTC) Received: from [10.0.0.171] (unknown [64.9.236.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4ADBC22E1F1; Thu, 8 Oct 2009 22:21:01 -0400 (EDT) Message-ID: <4ACE9DFD.3010207@gmail.com> Date: Thu, 08 Oct 2009 19:20:45 -0700 From: David Ehrmann User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tom Uffner References: <4ACE6D84.3000209@gmail.com> <4ACE833A.3030506@uffner.com> In-Reply-To: <4ACE833A.3030506@uffner.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 09 Oct 2009 04:57:38 +0000 Cc: FreeBSD-current@freebsd.org Subject: Re: 8.0rc1 not recognizing partitions on EPIA SN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2009 02:21:06 -0000 Tom Uffner wrote: > David Ehrmann wrote: >> First, I tried to upgrade the normal way. I built my own kernel and >> installed it, but when I tried to boot it, I got a mountroot> >> prompt. When I printed the devices, instead of seeing ad0s1a and >> friends, I saw ad0a and ad0d (just those two for ad0). I was still >> able to use the old (7.1) kernel fine. Thinking it was something to >> do with the upgrade, I tried to do a reinstall. I chose the default >> options, but once it got to the "last chance..." screen, this happened: >> >> Unable to find device node for /dev/ad0s1b in /dev! >> The creation of filesystems will be aborted. > > this is becoming an FAQ for 8.0 > > the short answer is "dangerously dedicated" partitions are not supported > by the 8.0 installer. back up your data. zero the MBR & partition table > with dd, and re-slice & partition your disk. after the install, restore > from your backups. > > search the freebsd-current archives for full details. dd did the trick. I understand why this was done, but at the same time, upgrading is now impractical for some users, and what looks like a fresh installation (repartitioned, resliced) can even fail. Is there a change that could be made to the partitioning process that would fix this? From owner-freebsd-current@FreeBSD.ORG Fri Oct 9 05:29:15 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AC2A1065676 for ; Fri, 9 Oct 2009 05:29:15 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id B505D8FC14 for ; Fri, 9 Oct 2009 05:29:14 +0000 (UTC) Received: from [41.154.0.10] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Mw82S-0005ai-3w; Fri, 09 Oct 2009 07:29:12 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mw82O-0006kF-PA; Fri, 09 Oct 2009 07:29:08 +0200 To: pyunyh@gmail.com From: Ian FREISLICH In-Reply-To: <20091008170458.GC3843@michelle.cdnetworks.com> References: <20091008170458.GC3843@michelle.cdnetworks.com> <20091007180257.GA3843@michelle.cdnetworks.com> X-Attribution: BOFH Date: Fri, 09 Oct 2009 07:29:08 +0200 Message-Id: Cc: current@freebsd.org Subject: Re: alc(4) link autoselect problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2009 05:29:15 -0000 Pyun YongHyeon wrote: > On Thu, Oct 08, 2009 at 12:38:45PM +0200, Ian FREISLICH wrote: > > wgsw-24010# sh interfaces status ethernet g14 > > Flow Link Back Mdix > > Port Type Duplex Speed Neg ctrl State Pressure Mode > > -------- ------------ ------ ----- -------- ---- ----------- -------- ---- --- > > g14 1G-Copper Full 100 Enabled Off Up Disabled Off > > > > Hmm, does your switch have an option to enable/disable downshifting > feature? If so, how about toggling the option? I'm not sure exactly what you mean. There's no configuration options that obviously match. > > > How about checking MIB statistics of controller? > > > (sysctl dev.alc.0.stats) > > > > This is after a reboot, but the link was up for a short while to > > do the above testing. rx.good_frames looks a bit high for "up 21 > > mins". > > > > dev.alc.0.stats.rx.good_frames: 3348588249 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > dev.alc.0.stats.rx.good_octets: 0 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Yeah, that looks odd, it seemed controller received a lot of good > frames but none were meaningful packets so I guess there are link > establishment issues. I still have no clue but if I manage to find > more test case I will let you know. That number is bogus. It's currently incrementing by approximately 33435108 per second without a cable plugged in. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Oct 9 06:35:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 287A5106568D for ; Fri, 9 Oct 2009 06:35:34 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id A51D98FC16 for ; Fri, 9 Oct 2009 06:35:33 +0000 (UTC) Received: by fxm22 with SMTP id 22so6304151fxm.36 for ; Thu, 08 Oct 2009 23:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=W5+eaZkhliPR63m93X+3Y/i2Opk69cfVa14eE8zdQpk=; b=DCmIg7fE5mBemO3OjPA4yiSIuMnVqTOttYwJJFZ0g0+oGa6UeRglwhmvOB7mbvlqhS ItfGmc2qIRnpUS5apF/hz+9/+D3qJ35Iwwd5T8bESqgcRCZ6ipMeAOuZbgW7jlJnOyzs Vg1pruVCHkfbEL+5PDYqOVWJWpRne0faFQVpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=VRqUIAg3zBeQhpfZTQd5Kd/F7EUS1/qIo6jkvv2DltyipYagPZnQnArQ+yx4BeGtn1 2070e65VqTgFychpbnUA0q21Gvxc81sj3mJtEX1VxA78dPW41j0ulJ5KzrvxA6OS/FXK h1/34gEbMza62uqCjfPZkT5affKHgtQ7B1QkY= Received: by 10.103.126.3 with SMTP id d3mr894792mun.101.1255070132641; Thu, 08 Oct 2009 23:35:32 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id j10sm1416512muh.0.2009.10.08.23.35.31 (version=SSLv3 cipher=RC4-MD5); Thu, 08 Oct 2009 23:35:32 -0700 (PDT) Sender: Alexander Motin Message-ID: <4ACED9B2.8060203@FreeBSD.org> Date: Fri, 09 Oct 2009 09:35:30 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: "James R. Van Artsdalen" References: <4ACEACA3.9070702@jrv.org> In-Reply-To: <4ACEACA3.9070702@jrv.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: [Fwd: siis change] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2009 06:35:34 -0000 James R. Van Artsdalen wrote: > mav committed a change to SIIS so I tried it but still get the device > hangs as before. I should have sent that report here instead of to mav. This change just fixes possible problem inside CAM, but it does nothing to hardware. > ch1 below connects to a port multiplier and ada3 is one of four disks > behind ch1. > > Does disk ada3 ever get reset, or the link between the port multiplier > behind ch1 and ada3 ever get reinitialized? I'm wondering if the port > multiplier is the key. I don't see any code to reset ada3 or at least > stop/start its PHY link. It is still not implemented. I am going to start working on it now. > It takes about an hour for "zpool scrub" to hang. > > -------- Original Message -------- > Subject: siis change > Date: Thu, 08 Oct 2009 18:06:01 -0500 > From: James R. Van Artsdalen > To: Alexander Motin > > I see you dropped in a change to SIIS for timeout errors so I decided to > give it a try. It still hangs for me. > > FreeBSD pygmy.housenet.jrv 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r197866: > Thu Oct 8 16:32:18 CDT 2009 > root@pygmy.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 > > I did a "zpool scrub" which was generally running at about 100 MB/s > across six 2 TB disks in two port multiplier enclosures. > > Here is that complete /var/log/messages. > > Oct 8 17:47:54 pygmy kernel: siisch1: Timeout on slot 3 > Oct 8 17:47:54 pygmy kernel: siisch1: siis_timeout is 00000000 ss > 00028308 rs 00028308 es 00000000 sts 80032000 serr 00000000 > Oct 8 17:47:54 pygmy kernel: siisch1: ready wait time=0ms > Oct 8 17:47:54 pygmy kernel: siisch1: ready wait time=1ms > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command > Oct 8 17:48:24 pygmy kernel: siisch1: Timeout on slot 29 > Oct 8 17:48:24 pygmy kernel: siisch1: siis_timeout is 00040000 ss > 60000007 rs 60000007 es 00000000 sts 801d2000 serr 00000000 > Oct 8 17:48:24 pygmy kernel: siisch1: ready wait time=1ms > Oct 8 17:48:24 pygmy kernel: siisch1: ready wait time=0ms > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Oct 9 09:55:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51B361065676; Fri, 9 Oct 2009 09:55:01 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206049004.chello.pl [87.206.49.4]) by mx1.freebsd.org (Postfix) with ESMTP id 810728FC15; Fri, 9 Oct 2009 09:54:59 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 50D8C45CBA; Fri, 9 Oct 2009 11:54:58 +0200 (CEST) Received: from localhost (pdawidek.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 6B39145C99; Fri, 9 Oct 2009 11:54:53 +0200 (CEST) Date: Fri, 9 Oct 2009 11:54:53 +0200 From: Pawel Jakub Dawidek To: Oliver Lehmann Message-ID: <20091009095453.GE1725@garage.freebsd.pl> References: <20090927170244.0980d699.lehmann@ans-netz.de> <20090927223725.5893371f.lehmann@ans-netz.de> <20090928084035.GB1659@garage.freebsd.pl> <20090928203756.ef70e0c6.lehmann@ans-netz.de> <20090928184926.GA2016@garage.freebsd.pl> <20091005193340.cd84f0ec.lehmann@ans-netz.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jCrbxBqMcLqd4mOl" Content-Disposition: inline In-Reply-To: <20091005193340.cd84f0ec.lehmann@ans-netz.de> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: =?iso-8859-1?Q?Sm=F8rgrav?= , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Dag-Erling@FreeBSD.ORG Subject: Re: glabel+gmirror (8.0-RC1 problem) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2009 09:55:01 -0000 --jCrbxBqMcLqd4mOl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 05, 2009 at 07:33:40PM +0200, Oliver Lehmann wrote: > gjorunal is also affected. I tried to use one partition of my gmirror > disk as journal device for my 3ware raid-5 device which works until I > reboot - the journal is then gone as well. > Is this patch likly to fix this as well? Will it be included in a future > RC? Until now I've stayed away using glabel+gmirror but I didn't knew > that gjournal is affected as well so I'm now left with warning that the > journal provider is gone wile booting - and more tragically I'm left > without journaling at all (which hurts on a 2.7TB partition when the > system was not cleanly shut down) I just committed the patch. Yes, it should fix gjournal case as well. I want to merge it before 8.0-RELEASE. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --jCrbxBqMcLqd4mOl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKzwhtForvXbEpPzQRAq+QAKCsPQ1ZKFoQ0m+Pq6J7xiBjbojMgwCfSdSn 7hQZkkVEqBF32PQEV25MnHw= =Gdrr -----END PGP SIGNATURE----- --jCrbxBqMcLqd4mOl-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 9 10:21:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7E7E106566B; Fri, 9 Oct 2009 10:21:22 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 81C0A8FC08; Fri, 9 Oct 2009 10:21:22 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:1121:8bf:8006:29a3] (unknown [IPv6:2001:7b8:3a7:0:1121:8bf:8006:29a3]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 5AC4F5C43; Fri, 9 Oct 2009 12:21:21 +0200 (CEST) Message-ID: <4ACF0EA0.9070401@andric.com> Date: Fri, 09 Oct 2009 12:21:20 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.4pre) Gecko/20091003 Shredder/3.0pre MIME-Version: 1.0 To: David Horn References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <4ACA4B81.3090105@andric.com> <4ACB3A08.9030109@andric.com> <25ff90d60910060921k2118994aq1f5b0431868ec800@mail.gmail.com> In-Reply-To: <25ff90d60910060921k2118994aq1f5b0431868ec800@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org, freebsd-current@freebsd.org Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2009 10:21:23 -0000 On 2009-10-06 18:21, David Horn wrote: > 1) Patchset is missing examples and defaults for new rc.conf > variables to /etc/defaults/rc.conf. (The defaults/rc.conf has been > updated in -current, although perhaps once everything settles, it > would help to expand the examples in comments) Not only that, it would prevent the following needless warnings, which are printed at every boot: [...] /etc/rc: WARNING: $ipv6_enable is obsolete. Use $ipv6_prefer instead. /etc/rc: WARNING: $ipv6_enable is obsolete. Use $ipv6_prefer instead. [...] /etc/rc: WARNING: $ipv6_router_enable is obsolete. Use $route6d_enable instead. /etc/rc: WARNING: $ipv6_router is obsolete. Use $route6d_program instead. /etc/rc: WARNING: $router_enable is obsolete. Use $routed_enable instead. /etc/rc: WARNING: $router is obsolete. Use $routed_program instead. /etc/rc: WARNING: $router_flags is obsolete. Use $routed_flags instead. Although the warning about ipv6_enable could be considered right, there's no need to print it twice, and I never touched any of the other ipv6_* or router_* variables. Those are from /etc/defaults/rc.conf. > 2) I really like the changes to ifconfig and kernel for exposing > per-interface flags for "accept_rtadv" and other ndp flags to ifconfig > (and inherently rc.conf). I previously had to do some hackery to > disable "accept_rtadv" at boot time for just one interface within > rc.conf. I'm not entirely sure if this is a sensible default. I would guess that for most users (80%? 90%?) the choice is only to have IPv6 "globally" disabled or enabled, and only a small percentage of users will need per-interface enabling/disabling of IPv4. Since it's now 2009 and everybody should start using IPv6 ASAP, it might make sense to have IPv6 globally enabled by default, with additional options for users like David to selectively disable it for individual interfaces. > 3) I would prefer that ipv6_enable remain a global flag in rc.conf, > and NOT be obsoleted. I would also prefer that > ipv6_network_interfaces="auto" as in the past by default. Again, I > like the logic changes and the flexibility it provides, it is just the > default/obsolete that I am interested in changing. Seconded. Even Windows defaults to enabling IPv6 globally for all interfaces these days. :) > 4) Personal opinion time: change the "accept_rtadv" token to > "autoconf" in ifconfig and rc.conf, as this it is a better > self-description. Just one persons opinion. Since the old "global" sysctl was also called accept_rtadv, I understand the same name was chosen for the per-interface option. People might confuse "autoconf" with "zeroconf" or other automatic configuration systems. Since the option means to accept router advertisements, accept_rtadv seems not a very bad name to me... :) > Given the timing, +1 for letting this bake in -current until after 8.0 > release. Yes. A few weeks at least. From owner-freebsd-current@FreeBSD.ORG Fri Oct 9 10:58:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D8B51065672 for ; Fri, 9 Oct 2009 10:58:28 +0000 (UTC) (envelope-from syso.fml@ext.no-route.org) Received: from core.kel1.no-route.org (core.kel1.no-route.org [217.70.192.207]) by mx1.freebsd.org (Postfix) with ESMTP id C78EB8FC0C for ; Fri, 9 Oct 2009 10:58:27 +0000 (UTC) Received: from [0.0.0.0] (isis.kel.no-route.org [217.70.197.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by core.kel1.no-route.org (Postfix) with ESMTPSA id EDF9B13F6DC for ; Fri, 9 Oct 2009 10:38:48 +0000 (UTC) Message-ID: <4ACF131C.1060201@ext.no-route.org> Date: Fri, 09 Oct 2009 12:40:28 +0200 From: Sylwester Sosnowski User-Agent: some piece of software MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Support for PC Engines ALIX2 reset pushbutton. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2009 10:58:28 -0000 Hello, I've just written an user-space utility for handling the PC Enginges ALIX' reset-pushbutton. It's a quick-and-dirty prototype and does the same what "shutdown -h now" does. I'll do a clean rewrite later. Any comments or suggestions appreciated. Here is the prototype: ----- BEGIN ----- /* * User-space reset-button support for PC Engines ALIX boards. * This is a prototype. * * Usage: * Use from rc(8). */ #include #include #include #include #include #include #include #include #include #include #include #include // MY_NAME is the process name used in syslog. #define MY_NAME "resetguard" // GPIO_RESET u_int32_t switchAddr = 0x61b0; int switchBit = 8; // GPIO_LED3 u_int32_t ledAddr = 0x6180; int ledBit = 11; // Blink GPIO_LED3. void blinkLed(int times) { int i; for (i=0; i Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5816A106566B for ; Fri, 9 Oct 2009 09:19:33 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from web51802.mail.re2.yahoo.com (web51802.mail.re2.yahoo.com [206.190.38.233]) by mx1.freebsd.org (Postfix) with SMTP id 053CA8FC0C for ; Fri, 9 Oct 2009 09:19:32 +0000 (UTC) Received: (qmail 2437 invoked by uid 60001); 9 Oct 2009 08:52:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1255078371; bh=Cd9mx8WU0XVZ21cnvJ/trPYglD8x32gmAudFiJEL/L8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=gXfpfLCah792Z6pUoAM6HEMnp+vrEtJ7NJazaI7brXkI7ozr5lQhaqfSoASRi2XnFgfYkRd6KO+ipkK6DOJizWzWytflTnlZ75iejJglBNEsrKaVcVYFC+kPvyxnm2p7lYamOPgO1rl+WcQq9TOiyi20+L5pMAp+qHQ/T5kcTgU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=Q+Z9vCC8OUEIyughbUv5gKl1bRwr1exI8fytm3He01qdHzV2bBD6pu7+jeEzISsqRbv67A4ktUx4Qk4sizquZ4wngrRD+ABo3RICT3uKNy8r+Q72V8VL8kG7g4k5ICv77DC/cTsg/oW+owGfdCF+vCff32B6Qxl21cppCwpL8YU=; Message-ID: <989483.352.qm@web51802.mail.re2.yahoo.com> X-YMail-OSG: HaXSODwVM1lbyyc_gl6HPTeLWaj2YD9aHhefLEnOgANiztgxi.bZoFibFypNJ.U6H2LODJwd271RbNZNafajQkLqT.ogbivXMqVNfGRlmrajUUBnORHvXGgkqiyY4na00INEg2ByBBAFVaXapzjFDYt5UskAXktZ05AD9n5bM7.tTe0mzxg7dwcED_PljEE2KBPXrlqaOrO4MhwjDBPjNilxNWT3kubP2ivkHnqEfvlDHoLMoey8ED2fPsSxQja3rYjpDfDyFmVd6Y5d1d03Nz5SWHDQwGXabTvYecETXVmK91uOU9yXt0LFWV1iFHRDU4USxQ0NUqT_Uw0xXuYBzeeFnoQAtJ2veQR9bJ2jPYgR2lb76cQUnwAU Received: from [75.158.17.63] by web51802.mail.re2.yahoo.com via HTTP; Fri, 09 Oct 2009 01:52:50 PDT X-Mailer: YahooMailRC/182.10 YahooMailWebService/0.7.347.3 Date: Fri, 9 Oct 2009 01:52:50 -0700 (PDT) From: Tango To: current@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 09 Oct 2009 11:22:29 +0000 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: ported run driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2009 09:19:33 -0000 Hello, I have ported run (ru'N' not ru'M') driver and posted on freebsd forum. http://forums.freebsd.org/showthread.php?s=91e5d3d58be54728b80686a77c8428cd&t=7562 Then, one member suggested to email you so some developers can review the code. Also, one of mailing list subscribers recommended to port to current, so I'm planing to do that. I'm new to freebsd. Any comments/suggestions would be appreciated. Thank you. Akinori __________________________________________________________________ Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca From owner-freebsd-current@FreeBSD.ORG Fri Oct 9 18:34:28 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3BDF106566B for ; Fri, 9 Oct 2009 18:34:28 +0000 (UTC) (envelope-from sean@seanmcollins.com) Received: from masakari.coreitpro.com (masakari.coreitpro.com [38.98.245.188]) by mx1.freebsd.org (Postfix) with ESMTP id 8FBD08FC12 for ; Fri, 9 Oct 2009 18:34:28 +0000 (UTC) Received: from masakari.coreitpro.com (masakari.coreitpro.com [38.98.245.188]) by masakari.coreitpro.com (8.14.3/8.14.3) with ESMTP id n99IYQt7005723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Oct 2009 14:34:26 -0400 (EDT) (envelope-from sean@seanmcollins.com) Received: (from www@localhost) by masakari.coreitpro.com (8.14.3/8.14.3/Submit) id n99IYQHh005722; Fri, 9 Oct 2009 14:34:26 -0400 (EDT) (envelope-from sean@seanmcollins.com) X-Authentication-Warning: masakari.coreitpro.com: www set sender to sean@seanmcollins.com using -f Received: from 209.133.84.170 ([209.133.84.170]) by masakari.coreitpro.com (Horde Framework) with HTTP; Fri, 09 Oct 2009 14:34:26 -0400 Message-ID: <20091009143426.21228n4sedds0je8@masakari.coreitpro.com> Date: Fri, 09 Oct 2009 14:34:26 -0400 From: Sean Collins To: Tango References: <989483.352.qm@web51802.mail.re2.yahoo.com> In-Reply-To: <989483.352.qm@web51802.mail.re2.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.3.3 / FreeBSD-7.2 X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on masakari.coreitpro.com X-Mailman-Approved-At: Fri, 09 Oct 2009 18:36:00 +0000 Cc: current@freebsd.org Subject: Re: ported run driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2009 18:34:28 -0000 Awesome! Thank you for the contribution! Thank You, Sean Collins ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-current@FreeBSD.ORG Fri Oct 9 19:41:52 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FA631065695 for ; Fri, 9 Oct 2009 19:41:52 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE4E8FC18 for ; Fri, 9 Oct 2009 19:41:51 +0000 (UTC) Received: by ewy18 with SMTP id 18so1366746ewy.43 for ; Fri, 09 Oct 2009 12:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=/q7ZEoBqAjXHtQ6lycVAyZ1BGhQ0KiFECYEWpYHaV10=; b=dxm60SXkvQ7lIalJugzQ5A2mRE0Xr7CpP5hGKyhBGsGoYPQZlEqW8x+/YtxqbAomMV 82L6h6CoOIFu2QC67eTAYx+eGuzWtpsN8nPDoGrG5G9PoK8spj0XxS91UCpwEU0S/sDB MKC/5GnzUfuHI3YWGj8wNmUOGEdBjnD9K77SI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=I6nQe+ZDafY0tL+bljSOYvnSyw3cslbOSbL+uFvzfce2ByD1N+54m5J7GoE5z05nBk IQutPDJDufy0t5QL5z/jMc9h5mPihPIjBNtVDMVoB3H6pq4OEhbfSKO+yh6Mm/I7nArj T3QIAd+LRYnXmYQIZ/u/IjYWK44+cfL8WDHQU= Received: by 10.216.90.203 with SMTP id e53mr1025589wef.28.1255117310798; Fri, 09 Oct 2009 12:41:50 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id m5sm203772gve.26.2009.10.09.12.41.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Oct 2009 12:41:47 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 9 Oct 2009 12:40:37 -0700 From: Pyun YongHyeon Date: Fri, 9 Oct 2009 12:40:37 -0700 To: Ian FREISLICH Message-ID: <20091009194037.GI3843@michelle.cdnetworks.com> References: <20091008170458.GC3843@michelle.cdnetworks.com> <20091007180257.GA3843@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: alc(4) link autoselect problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 09 Oct 2009 19:41:52 -0000 On Fri, Oct 09, 2009 at 07:29:08AM +0200, Ian FREISLICH wrote: > Pyun YongHyeon wrote: > > On Thu, Oct 08, 2009 at 12:38:45PM +0200, Ian FREISLICH wrote: > > > wgsw-24010# sh interfaces status ethernet g14 > > > Flow Link Back Mdix > > > Port Type Duplex Speed Neg ctrl State Pressure Mode > > > -------- ------------ ------ ----- -------- ---- ----------- -------- ---- > --- > > > g14 1G-Copper Full 100 Enabled Off Up Disabled Off > > > > > > > Hmm, does your switch have an option to enable/disable downshifting > > feature? If so, how about toggling the option? > > I'm not sure exactly what you mean. There's no configuration options > that obviously match. > Modern PHYs have ability to correct several cabling problems, for example, - pair swaps - pair skews - pair polarity - automatic MDI/MDIX - downshift to enable 10/100Mps link establishment with two pairs by downgrading the link speed to 10/100Mbps during auto-negotiation process when it can't establish 1000Mbps link. Existing cables used to connect 10/100Mbps link partners may have only two pairs. With two pairs PHYs can announce 1000Mbps capability to link partner but it can't establish the link as 1000Mbps link requires 4 pairs. Since F1 PHY seems to have above capability I just wanted to see whether disabling downshifting on link partner makes any difference. > > > > How about checking MIB statistics of controller? > > > > (sysctl dev.alc.0.stats) > > > > > > This is after a reboot, but the link was up for a short while to > > > do the above testing. rx.good_frames looks a bit high for "up 21 > > > mins". > > > > > > dev.alc.0.stats.rx.good_frames: 3348588249 > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > dev.alc.0.stats.rx.good_octets: 0 > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Yeah, that looks odd, it seemed controller received a lot of good > > frames but none were meaningful packets so I guess there are link > > establishment issues. I still have no clue but if I manage to find > > more test case I will let you know. > > That number is bogus. It's currently incrementing by approximately > 33435108 per second without a cable plugged in. > Hmm, I have to test this case. Thanks. > Ian > > -- > Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Oct 9 20:29:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B46D106566B for ; Fri, 9 Oct 2009 20:29:07 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id B0EEB8FC18 for ; Fri, 9 Oct 2009 20:29:06 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 4CAF0489D2; Fri, 9 Oct 2009 21:29:05 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RH8AIzxQ+1kq; Fri, 9 Oct 2009 21:29:01 +0100 (BST) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 859A748988; Fri, 9 Oct 2009 21:29:00 +0100 (BST) Message-ID: <4ACF9CE7.30808@tomjudge.com> Date: Fri, 09 Oct 2009 20:28:23 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Sylwester Sosnowski References: <4ACF131C.1060201@ext.no-route.org> In-Reply-To: <4ACF131C.1060201@ext.no-route.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Support for PC Engines ALIX2 reset pushbutton. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2009 20:29:07 -0000 Hi Sylwester, This is interesting, what boards should be supported? (I have a couple of 2d3's) I will be needing something like this for my current project as well. Thanks TJ Sylwester Sosnowski wrote: > Hello, > > I've just written an user-space utility for handling the PC Enginges ALIX' > reset-pushbutton. It's a quick-and-dirty prototype and does the same what > "shutdown -h now" does. I'll do a clean rewrite later. > > Any comments or suggestions appreciated. > > > Here is the prototype: > > ----- BEGIN ----- > > /* > * User-space reset-button support for PC Engines ALIX boards. > * This is a prototype. > * > * Usage: > * Use from rc(8). > */ > > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > > // MY_NAME is the process name used in syslog. > #define MY_NAME "resetguard" > > // GPIO_RESET > u_int32_t switchAddr = 0x61b0; > int switchBit = 8; > > // GPIO_LED3 > u_int32_t ledAddr = 0x6180; > int ledBit = 11; > > > // Blink GPIO_LED3. > void blinkLed(int times) > { > int i; > > for (i=0; i { > outl(ledAddr, 1 << (ledBit + 16)); > usleep(80000); > outl(ledAddr, 1 << ledBit); > usleep(80000); > } > } > > // Return GPIO_RESET state. > char isResetPressed() { > return ((inl(switchAddr) & (1 << switchBit)) == 0); > } > > int main() { > int fd; // Define our file descriptor > char *empty_environ[] = { NULL }; // Environment for halt(8) > > if(geteuid()) > { > errx(1, "You're not super-user."); // Show error and exit. > } > > > fd = open("/dev/io", O_RDONLY); // Read-only file descriptor for /dev/io > > if (fd == -1) { // On error (e.g. wrong permissions) > perror("Cannot open /dev/io."); // Print error message > exit(1); // and exit with status 1 > } > > /* > * At this point we'll be polling the GPIO-Pin of the Reset-button > * at the front of the PC Engines Alix board every 450ms. > * If the pin is HIGH, resetBoard() will be called. > */ > > while(1) // Infinite loop > { > usleep(4000000); // Wait ca. 450ms before probing again > if(isResetPressed()) { // If resetPressed() returns 1.. > blinkLed(4); // Blink GPIO_LED3 4 times > > setlogmask(LOG_UPTO (LOG_NOTICE)); // LOG_NOTICE > > // We'll be logging to LOG_LOCAL1 > openlog(MY_NAME, LOG_CONS | LOG_NDELAY, LOG_LOCAL1); > > // Write message to syslog > syslog(LOG_NOTICE, "Event detected on GPIO_RESET (UID %d)", getuid()); > > // Close Log > closelog(); > > // Halt system (like "shutdown -h now" does) > execle(_PATH_HALT, "halt", "-l", sync, (char *)NULL, empty_environ); > > // Exit with status 0 > exit(0); > } > } > > exit(0); // This should never be reached (exit 0) > } > > > ----- END ----- > _______________________________________________ > 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 Sat Oct 10 05:25:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 834C81065676 for ; Sat, 10 Oct 2009 05:25:18 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6F28E8FC13; Sat, 10 Oct 2009 05:25:18 +0000 (UTC) Received: from apple.my.domain (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9A5PGVa033418; Sat, 10 Oct 2009 05:25:17 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4AD01ABC.50901@freebsd.org> Date: Sat, 10 Oct 2009 13:25:16 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20080612) MIME-Version: 1.0 To: Kostik Belousov References: <20091001120730.GR3130@deviant.kiev.zoral.com.ua> <20091002201213.GA16633@stack.nl> <20091005192144.GA2259@deviant.kiev.zoral.com.ua> In-Reply-To: <20091005192144.GA2259@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Jilles Tjoelker , Justin Teller Subject: Re: Signals and an exiting thread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 05:25:18 -0000 Kostik Belousov wrote: > I agree that postponing assignment of the thread for signal delivery > till the actual delivery occurs is the proper fix. I tried to cheat > in my previous patch. Below is an experimental change that did very > minimal testing. > Even if the signal is put into process's signal queue, it is still possible that signal notification is lost because selected thread exits before seeing it, if other threads are sleeping, they are not notified, this leaves signal in process queue long time before it can be delivered to userland. From owner-freebsd-current@FreeBSD.ORG Sat Oct 10 09:41:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BFB010656A6 for ; Sat, 10 Oct 2009 09:41:03 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 04D238FC20 for ; Sat, 10 Oct 2009 09:41:02 +0000 (UTC) Received: from baby-jane.lamaiziere.net (20.6.192-77.rev.gaoland.net [77.192.6.20]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 7ED51633322; Sat, 10 Oct 2009 11:41:01 +0200 (CEST) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 6336DB662; Sat, 10 Oct 2009 11:41:01 +0200 (CEST) Date: Sat, 10 Oct 2009 11:41:00 +0200 From: Patrick Lamaiziere To: Hans Petter Selasky Message-ID: <20091010114100.51b67abd@baby-jane.lamaiziere.net> In-Reply-To: <200910082010.36621.hselasky@freebsd.org> References: <200909251909.31503.hselasky@freebsd.org> <4ABE2B4F.6080104@tomjudge.com> <200909271950.55189.hselasky@freebsd.org> <200910082010.36621.hselasky@freebsd.org> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.6; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Polling support for USB serial port adapters [patches] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 09:41:03 -0000 Le Thu, 8 Oct 2009 20:10:34 +0200, Hans Petter Selasky a =E9crit : Hello, > > hw.usb.ucom.cons_unit=3D0 > > hw.usb.ucom.cons_baud=3D9600 > > > > In /boot/loader.conf > > > > NOTE: The patches have not been tested yet, only carefully > > reviewed. If you experience any problems, please debug and send > > patch to me. I'm trying with uplcom (Prolific chipset) but I'm not familiar with serial debuging. Shall I use a remote gdb. Or should it work if I set a serial console on the machine (like with uart)? I'm testing on 8.0.=20 Regards. From owner-freebsd-current@FreeBSD.ORG Sat Oct 10 10:38:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD1D71065672; Sat, 10 Oct 2009 10:38:16 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 1C9FE8FC1F; Sat, 10 Oct 2009 10:38:15 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=7H_uI1Jp-TAA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=R5zHh6Q0aC69Z2J8_2IA:9 a=bqN_6H8h7G0Dbm70ma9dyuXSeBQA:4 a=SV7veod9ZcQA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1309878422; Sat, 10 Oct 2009 12:38:13 +0200 Received-SPF: softfail receiver=mailfe06.swip.net; client-ip=188.126.201.140; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Sat, 10 Oct 2009 12:39:00 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200909251909.31503.hselasky@freebsd.org> <200910082010.36621.hselasky@freebsd.org> <20091010114100.51b67abd@baby-jane.lamaiziere.net> In-Reply-To: <20091010114100.51b67abd@baby-jane.lamaiziere.net> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpO< =?iso-8859-1?q?Q0yAl=7E=3F=60=27F=3FjDVb=5DE6TQ7=27=23h-VlLs=7Dk/=0A=09?=(yxg(p!IL.`#ng"%`BMrham7%UK,}VH\wUOm=^>wEEQ+KWt[{J#x6ow~JO:,zwp.(t; @ =?iso-8859-1?q?Aq=0A=09=3A4=3A=26nFCgDb8=5B3oIeTb=5E=27?=",; u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200910101239.02783.hselasky@freebsd.org> Cc: freebsd-current@freebsd.org, Patrick Lamaiziere Subject: Re: Polling support for USB serial port adapters [patches] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 10:38:16 -0000 On Saturday 10 October 2009 11:41:00 Patrick Lamaiziere wrote: > Le Thu, 8 Oct 2009 20:10:34 +0200, > Hans Petter Selasky a =E9crit : > > Hello, > > > > hw.usb.ucom.cons_unit=3D0 > > > hw.usb.ucom.cons_baud=3D9600 > > > > > > In /boot/loader.conf > > > > > > NOTE: The patches have not been tested yet, only carefully > > > reviewed. If you experience any problems, please debug and send > > > patch to me. > > I'm trying with uplcom (Prolific chipset) but I'm not familiar with > serial debuging. Shall I use a remote gdb. Or should it work if I > set a serial console on the machine (like with uart)? > > I'm testing on 8.0. It should work with both GDB and the console driver. =2D-HPS From owner-freebsd-current@FreeBSD.ORG Sat Oct 10 11:26:15 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E964D1065694; Sat, 10 Oct 2009 11:26:15 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from kennaway-macbookpro.config (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 047518FC1A; Sat, 10 Oct 2009 11:26:14 +0000 (UTC) Message-ID: <4AD06F62.50800@FreeBSD.org> Date: Sat, 10 Oct 2009 12:26:26 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Pavo Banicevic References: <3a142e750909301035m4a08d71as3e0175d0726038a8@mail.gmail.com> In-Reply-To: <3a142e750909301035m4a08d71as3e0175d0726038a8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Watson , current@freebsd.org Subject: Re: odd make/build output on ^Z / fg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 11:26:16 -0000 Pavo Banicevic wrote: > On 7/9/09, Robert Watson wrote: >> Today I suspended a kernel build with ^Z to free up a bit of I/O bandwidth >> on >> a box. When I re-foregrounded, all appeared fine for a bit, but later when >> I >> switched back to the xterm I found this: >> >> ototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef >> -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I../../.. >> -I../../../contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include >> opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 >> --param large-function-growth=1000 -mno-align-long-strings >> -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 >> -mno-sse3 >> -ffreestanding -fstack-protector -Werror ../../../i386/acpica/acpi_wakeup.c >> couldn't resume mac_pipe.o: No such process >> *** Signal 1 >> couldn't resume audit_arg.o: No such process >> *** Signal 1 >> couldn't resume nlm_prot_impl.o: No such process >> *** Signal 1 >> couldn't resume nfs_serv.o: No such process >> *** Signal 1 >> couldn't resume nfs_vnops.o: No such process >> *** Signal 1 >> couldn't resume modules-obj: No such process >> ===> usb/uether (obj) >> ===> usb/aue (obj) >> ... >> ===> xfs (obj) >> ===> xl (obj) >> ===> zfs (obj) >> ===> zlib (obj) >> *** Signal 1 >> 6 errors >> >> I've never seen that before, but I also don't suspend builds all that >> frequently. New bug? Old bug? > > Today I got this when building kernel: > > # fg > make -j6 buildkernel > *** Stopped -- signal 18 > Child (49737) not in table? > couldn't resume aicasm_macro_gram.o: No such process > *** Signal 1 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > > > I have kern.randompid=777, and I did stopped buildworld just before > building kernel. Maybe this is (tcsh) shell issue? It's a very old bug. I first saw it after changes made by phk to the way make communicates with its child processes several years ago, but it's not clear where the problem lies. Kris From owner-freebsd-current@FreeBSD.ORG Sat Oct 10 11:28:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E25B7106566B for ; Sat, 10 Oct 2009 11:28:27 +0000 (UTC) (envelope-from johny-freebsd@earthmagic.org) Received: from ppp194-14.static.internode.on.net (ppp194-14.static.internode.on.net [59.167.194.14]) by mx1.freebsd.org (Postfix) with ESMTP id A4AA48FC1A for ; Sat, 10 Oct 2009 11:28:27 +0000 (UTC) Received: from [192.168.2.4] (tornado.zone2.earthmagic.org [192.168.2.4]) by ppp194-14.static.internode.on.net (Postfix-MSA) with ESMTP id 2F63566ECE for ; Sat, 10 Oct 2009 22:28:26 +1100 (EST) Message-ID: <4AD06FD9.20206@earthmagic.org> Date: Sat, 10 Oct 2009 22:28:25 +1100 From: Johny Mattsson User-Agent: Thunderbird 2.0.0.23 (X11/20090919) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: zfsboot insists on /boot.config being >=512 bytes to not be "invalid format" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 11:28:28 -0000 Hi all, Just came across a tiny annoyance on 8.0-RC1-p1 - when booting off a zfs root and using a /boot.config file, zfsboot prints "Invalid format" unless /boot.config is at least 512 bytes. Everything still works, so this is a cosmetic/user-friendliness bug only. Looking at /sys/boot/i386/zfsboot/zfsboot.c, this appears to stem from xfsread() being used to load in /boot.config, and xfsread() wants to be able to read in a full buffer. Switching to using plain zfs_read() should fix it. Below is a one-liner patch to do so. Cheers, /Johny --- zfsboot.c.orig 2009-10-10 22:04:29.464823028 +1100 +++ zfsboot.c 2009-10-10 22:05:06.766834831 +1100 @@ -609,7 +609,7 @@ if (zfs_lookup(spa, PATH_CONFIG, &dn) == 0) { off = 0; - xfsread(&dn, &off, cmd, sizeof(cmd)); + zfs_read(spa, &dn, &off, cmd, sizeof(cmd)); } if (*cmd) { From owner-freebsd-current@FreeBSD.ORG Sat Oct 10 13:39:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 906011065670 for ; Sat, 10 Oct 2009 13:39:39 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by mx1.freebsd.org (Postfix) with ESMTP id 403908FC14 for ; Sat, 10 Oct 2009 13:39:38 +0000 (UTC) Received: by gxk6 with SMTP id 6so7150576gxk.13 for ; Sat, 10 Oct 2009 06:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=9XblpqN2ZU+vJh9lXIduEmmX61Kv9uvPD/UKgGLXo1Q=; b=bF2g+JEUxV2Z4LgB407AmeTsPMhstYfVxMNPHo7wIzxF8pCA037IxAIx7SBLH3oWCw 3prFY+9LgLO2twSpf10pmyayv+P6AIyKfI5X0K5Hyr0W7YSwrKQMcjyM6rfnAFZDuX19 4HXFubY2rAuldLJH63FQhUqzQcLBpHdKPrs2M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=eY3x7yH0NStxaugd+z0cTJ4ZA360dLu2kZnmxvwE/mgPALnY7RzDmTcgTyuK4Hneor Nm5YKjLJ62qtQHKaekfkSnvbi7LbF2QJphBvzIx/DYGsbaiRwKNGa68h7JmMhe+/lGOM xpxBegDJdL4g2P36mhGOOvh0//XvtrlrCn1GI= MIME-Version: 1.0 Sender: chmeeedalf@gmail.com Received: by 10.101.27.20 with SMTP id e20mr4327413anj.137.1255181978349; Sat, 10 Oct 2009 06:39:38 -0700 (PDT) In-Reply-To: References: <20091001120730.GR3130@deviant.kiev.zoral.com.ua> <20091002201213.GA16633@stack.nl> <20091005192144.GA2259@deviant.kiev.zoral.com.ua> <4AD01ABC.50901@freebsd.org> Date: Sat, 10 Oct 2009 09:39:38 -0400 X-Google-Sender-Auth: 1b54e50fb9f2a115 Message-ID: From: Justin Hibbits To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fwd: Signals and an exiting thread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 13:39:39 -0000 I really need to change gmail to reply to all by default. ---------- Forwarded message ---------- From: Justin Hibbits Date: Sat, Oct 10, 2009 at 9:38 AM Subject: Re: Signals and an exiting thread To: David Xu On Sat, Oct 10, 2009 at 1:25 AM, David Xu wrote: > Kostik Belousov wrote: > > I agree that postponing assignment of the thread for signal delivery >> till the actual delivery occurs is the proper fix. I tried to cheat >> in my previous patch. Below is an experimental change that did very >> minimal testing. >> >> > > Even if the signal is put into process's signal queue, it is still > possible that signal notification is lost because selected thread > exits before seeing it, if other threads are sleeping, they are > not notified, this leaves signal in process queue long time before > it can be delivered to userland. Unless they're in an uninterruptible sleep, wouldn't they be woken when the signal is processed? It might need work to give a second pass over the threads after one dies, but I think that could be done when handling the next task schedule. - Justin From owner-freebsd-current@FreeBSD.ORG Sat Oct 10 14:14:51 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B4EA1065692 for ; Sat, 10 Oct 2009 14:14:51 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 09CA88FC0C for ; Sat, 10 Oct 2009 14:14:50 +0000 (UTC) Received: from [202.179.21.128] (helo=beastie.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MwcIl-000Pro-3p; Sat, 10 Oct 2009 21:48:03 +0800 Message-ID: <4AD090CA.9000503@micom.mng.net> Date: Sat, 10 Oct 2009 21:48:58 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.19 (X11/20090127) MIME-Version: 1.0 To: Tango References: <989483.352.qm@web51802.mail.re2.yahoo.com> In-Reply-To: <989483.352.qm@web51802.mail.re2.yahoo.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=78F6425E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: ported run driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 14:14:51 -0000 Tango wrote: > Hello, > > I have ported run (ru'N' not ru'M') driver and posted on freebsd forum. > http://forums.freebsd.org/showthread.php?s=91e5d3d58be54728b80686a77c8428cd&t=7562 > Then, one member suggested to email you so some developers can review the code. > That is great. I have one these small USB device Planex GW-USMicroN and I was thinking to work on openbsd if_run driver, but somehow couldn't allocate the time for it :( I will definitely test if_run driver that you ported, however my laptop's CURRENT is really old so I have to update that one first :) Let us know once you port it to CURRENT. thanks, Ganbold Ts. > Also, one of mailing list subscribers recommended to port to current, so I'm planing to do that. > > I'm new to freebsd. Any comments/suggestions would be appreciated. > > Thank you. > Akinori > > > __________________________________________________________________ > Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca > _______________________________________________ > 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" > > > > -- He who spends a storm beneath a tree, takes life with a grain of TNT. From owner-freebsd-current@FreeBSD.ORG Sat Oct 10 14:30:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2435106566B for ; Sat, 10 Oct 2009 14:30:00 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.swip.net [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id 6ED818FC14 for ; Sat, 10 Oct 2009 14:29:59 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=CHl5VXKqUDu3IxEA_kIA:9 a=0qEE7tttRyhutHaa0zYA:7 a=RX4zt8j2hExnPBf3aPdyxpeZZT8A:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 571576108; Sat, 10 Oct 2009 16:29:57 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 10 Oct 2009 16:30:49 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <989483.352.qm@web51802.mail.re2.yahoo.com> <4AD090CA.9000503@micom.mng.net> In-Reply-To: <4AD090CA.9000503@micom.mng.net> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910101630.50752.hselasky@c2i.net> Cc: Ganbold , Tango Subject: Re: ported run driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 14:30:01 -0000 On Saturday 10 October 2009 15:48:58 Ganbold wrote: > Tango wrote: > > Hello, > > > > I have ported run (ru'N' not ru'M') driver and posted on freebsd forum. > > http://forums.freebsd.org/showthread.php?s=91e5d3d58be54728b80686a77c8428 > >cd&t=7562 Then, one member suggested to email you so some developers can > > review the code. > > That is great. I have one these small USB device Planex GW-USMicroN and > I was thinking to work on openbsd if_run driver, but somehow couldn't > allocate the time for it :( > I will definitely test if_run driver that you ported, however my > laptop's CURRENT is really old so I have to update that one first :) > Let us know once you port it to CURRENT. > > thanks, > > Ganbold Ts. Hi, Regarding -current, there should be plenty of Wireless USB device drivers to look at! --HPS From owner-freebsd-current@FreeBSD.ORG Sat Oct 10 14:36:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CF031065672 for ; Sat, 10 Oct 2009 14:36:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 1BB368FC21 for ; Sat, 10 Oct 2009 14:36:48 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n9AEahbL091470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Oct 2009 17:36:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n9AEahRQ082599; Sat, 10 Oct 2009 17:36:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n9AEahKq082598; Sat, 10 Oct 2009 17:36:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 10 Oct 2009 17:36:43 +0300 From: Kostik Belousov To: David Xu Message-ID: <20091010143643.GA2259@deviant.kiev.zoral.com.ua> References: <20091001120730.GR3130@deviant.kiev.zoral.com.ua> <20091002201213.GA16633@stack.nl> <20091005192144.GA2259@deviant.kiev.zoral.com.ua> <4AD01ABC.50901@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jvmCgFKx2lledmPK" Content-Disposition: inline In-Reply-To: <4AD01ABC.50901@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, Jilles Tjoelker , Justin Teller Subject: Re: Signals and an exiting thread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 14:36:50 -0000 --jvmCgFKx2lledmPK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 10, 2009 at 01:25:16PM +0800, David Xu wrote: > Kostik Belousov wrote: >=20 > >I agree that postponing assignment of the thread for signal delivery > >till the actual delivery occurs is the proper fix. I tried to cheat > >in my previous patch. Below is an experimental change that did very > >minimal testing. > > >=20 > Even if the signal is put into process's signal queue, it is still > possible that signal notification is lost because selected thread > exits before seeing it, if other threads are sleeping, they are > not notified, this leaves signal in process queue long time before > it can be delivered to userland. >=20 Agreed. Actually, there is one more race. Namely, when thread enters kernel for executing sigprocmask syscall, but still did not acquired process mutex, some signal may be scheduled for the thread which will block it later while still in kernel, so wakeup is lost again. I did fixed that in later version of the patch, by waking up possible target threads that have newly blocked signals unblocked. Resulting code seems to be relevant for exiting thread as well, where we also shall set sigmask to indicate that thread is not willing (cannot) handle any further signals. Updated patch below. diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index 0386fc4..9e61ea8 100644 --- a/sys/kern/kern_sig.c +++ b/sys/kern/kern_sig.c @@ -220,6 +220,8 @@ static int sigproptbl[NSIG] =3D { SA_KILL|SA_PROC, /* SIGUSR2 */ }; =20 +static void reschedule_signals(struct proc *p, sigset_t block); + static void sigqueue_start(void) { @@ -581,20 +583,11 @@ void signotify(struct thread *td) { struct proc *p; - sigset_t set; =20 p =3D td->td_proc; =20 PROC_LOCK_ASSERT(p, MA_OWNED); =20 - /* - * If our mask changed we may have to move signal that were - * previously masked by all threads to our sigqueue. - */ - set =3D p->p_sigqueue.sq_signals; - SIGSETNAND(set, td->td_sigmask); - if (! SIGISEMPTY(set)) - sigqueue_move_set(&p->p_sigqueue, &td->td_sigqueue, &set); if (SIGPENDING(td)) { thread_lock(td); td->td_flags |=3D TDF_NEEDSIGCHK | TDF_ASTPENDING; @@ -976,24 +969,28 @@ execsigs(struct proc *p) * Manipulate signal mask. */ int -kern_sigprocmask(td, how, set, oset, old) - struct thread *td; - int how; - sigset_t *set, *oset; - int old; +kern_sigprocmask(struct thread *td, int how, sigset_t *set, sigset_t *oset, + int old) { + sigset_t new_block, oset1; + struct proc *p; int error; =20 - PROC_LOCK(td->td_proc); + p =3D td->td_proc; + PROC_LOCK(p); if (oset !=3D NULL) *oset =3D td->td_sigmask; =20 error =3D 0; + SIGEMPTYSET(new_block); if (set !=3D NULL) { switch (how) { case SIG_BLOCK: SIG_CANTMASK(*set); + oset1 =3D td->td_sigmask; SIGSETOR(td->td_sigmask, *set); + new_block =3D td->td_sigmask; + SIGSETNAND(new_block, oset1); break; case SIG_UNBLOCK: SIGSETNAND(td->td_sigmask, *set); @@ -1001,10 +998,13 @@ kern_sigprocmask(td, how, set, oset, old) break; case SIG_SETMASK: SIG_CANTMASK(*set); + oset1 =3D td->td_sigmask; if (old) SIGSETLO(td->td_sigmask, *set); else td->td_sigmask =3D *set; + new_block =3D td->td_sigmask; + SIGSETNAND(new_block, oset1); signotify(td); break; default: @@ -1012,7 +1012,20 @@ kern_sigprocmask(td, how, set, oset, old) break; } } - PROC_UNLOCK(td->td_proc); + + /* + * The new_block set contains signals that were not previosly + * blocked, but are blocked now. + * + * In case we block any signal that was not previously blocked + * for td, and process has the signal pending, try to schedule + * signal delivery to some thread that does not block the signal, + * possibly waking it up. + */ + if (p->p_numthreads !=3D 1) + reschedule_signals(p, new_block); + + PROC_UNLOCK(p); return (error); } =20 @@ -1985,17 +1998,9 @@ tdsignal(struct proc *p, struct thread *td, int sig,= ksiginfo_t *ksi) KNOTE_LOCKED(&p->p_klist, NOTE_SIGNAL | sig); prop =3D sigprop(sig); =20 - /* - * If the signal is blocked and not destined for this thread, then - * assign it to the process so that we can find it later in the first - * thread that unblocks it. Otherwise, assign it to this thread now. - */ if (td =3D=3D NULL) { td =3D sigtd(p, sig, prop); - if (SIGISMEMBER(td->td_sigmask, sig)) - sigqueue =3D &p->p_sigqueue; - else - sigqueue =3D &td->td_sigqueue; + sigqueue =3D &p->p_sigqueue; } else { KASSERT(td->td_proc =3D=3D p, ("invalid thread")); sigqueue =3D &td->td_sigqueue; @@ -2392,6 +2397,62 @@ stopme: return (td->td_xsig); } =20 +static void +reschedule_signals(struct proc *p, sigset_t block) +{ + struct sigacts *ps; + struct thread *td; + int i; + + PROC_LOCK_ASSERT(p, MA_OWNED); + + ps =3D p->p_sigacts; + for (i =3D 0; !SIGISEMPTY(block); i++) { + if (!SIGISMEMBER(block, i)) + continue; + SIGDELSET(block, i); + if (!SIGISMEMBER(p->p_siglist, i)) + continue; + + td =3D sigtd(p, i, 0); + signotify(td); + mtx_lock(&ps->ps_mtx); + if (p->p_flag & P_TRACED || SIGISMEMBER(ps->ps_sigcatch, i)) + tdsigwakeup(td, i, SIG_CATCH, + (SIGISMEMBER(ps->ps_sigintr, i) ? EINTR : + ERESTART)); + mtx_unlock(&ps->ps_mtx); + } +} + +void +tdsigcleanup(struct thread *td) +{ + struct proc *p; + sigset_t unblocked; + + p =3D td->td_proc; + PROC_LOCK_ASSERT(p, MA_OWNED); + + sigqueue_flush(&td->td_sigqueue); + if (p->p_numthreads =3D=3D 1) + return; + + /* + * Since we cannot handle signals, notify signal post code + * about this by filling the sigmask. + * + * Also, if needed, wake up thread(s) that do not block the + * same signals as the exiting thread, since the thread might + * have been selected for delivery and woken up. + */ + SIGFILLSET(unblocked); + SIGSETNAND(unblocked, td->td_sigmask); + SIGFILLSET(td->td_sigmask); + reschedule_signals(p, unblocked); + +} + /* * If the current process has received a signal (should be caught or cause * termination, should interrupt current syscall), return the signal numbe= r. @@ -2409,8 +2470,9 @@ issignal(struct thread *td, int stop_allowed) { struct proc *p; struct sigacts *ps; + struct sigqueue *queue; sigset_t sigpending; - int sig, prop, newsig; + int sig, prop, newsig, signo; =20 p =3D td->td_proc; ps =3D p->p_sigacts; @@ -2420,6 +2482,7 @@ issignal(struct thread *td, int stop_allowed) int traced =3D (p->p_flag & P_TRACED) || (p->p_stops & S_SIG); =20 sigpending =3D td->td_sigqueue.sq_signals; + SIGSETOR(sigpending, p->p_sigqueue.sq_signals); SIGSETNAND(sigpending, td->td_sigmask); =20 if (p->p_flag & P_PPWAIT) @@ -2440,6 +2503,7 @@ issignal(struct thread *td, int stop_allowed) */ if (SIGISMEMBER(ps->ps_sigignore, sig) && (traced =3D=3D 0)) { sigqueue_delete(&td->td_sigqueue, sig); + sigqueue_delete(&p->p_sigqueue, sig); continue; } if (p->p_flag & P_TRACED && (p->p_flag & P_PPWAIT) =3D=3D 0) { @@ -2452,12 +2516,18 @@ issignal(struct thread *td, int stop_allowed) =20 if (sig !=3D newsig) { ksiginfo_t ksi; + + queue =3D &td->td_sigqueue; /* * clear old signal. * XXX shrug off debugger, it causes siginfo to * be thrown away. */ - sigqueue_get(&td->td_sigqueue, sig, &ksi); + if (sigqueue_get(queue, sig, &ksi) =3D=3D 0) { + queue =3D &p->p_sigqueue; + signo =3D sigqueue_get(queue, sig, &ksi); + KASSERT(signo =3D=3D sig, ("signo !=3D sig")); + } =20 /* * If parent wants us to take the signal, @@ -2472,7 +2542,7 @@ issignal(struct thread *td, int stop_allowed) * Put the new signal into td_sigqueue. If the * signal is being masked, look for other signals. */ - SIGADDSET(td->td_sigqueue.sq_signals, sig); + SIGADDSET(queue->sq_signals, sig); if (SIGISMEMBER(td->td_sigmask, sig)) continue; signotify(td); @@ -2567,6 +2637,7 @@ issignal(struct thread *td, int stop_allowed) return (sig); } sigqueue_delete(&td->td_sigqueue, sig); /* take the signal! */ + sigqueue_delete(&p->p_sigqueue, sig); } /* NOTREACHED */ } @@ -2613,7 +2684,9 @@ postsig(sig) ps =3D p->p_sigacts; mtx_assert(&ps->ps_mtx, MA_OWNED); ksiginfo_init(&ksi); - sigqueue_get(&td->td_sigqueue, sig, &ksi); + if (sigqueue_get(&td->td_sigqueue, sig, &ksi) =3D=3D 0 && + sigqueue_get(&p->p_sigqueue, sig, &ksi) =3D=3D 0) + return; ksi.ksi_signo =3D sig; if (ksi.ksi_code =3D=3D SI_TIMER) itimer_accept(p, ksi.ksi_timerid, &ksi); diff --git a/sys/kern/kern_thr.c b/sys/kern/kern_thr.c index 630069b..3159a91 100644 --- a/sys/kern/kern_thr.c +++ b/sys/kern/kern_thr.c @@ -282,7 +282,7 @@ thr_exit(struct thread *td, struct thr_exit_args *uap) } =20 PROC_LOCK(p); - sigqueue_flush(&td->td_sigqueue); + tdsigcleanup(td); PROC_SLOCK(p); =20 /* diff --git a/sys/kern/subr_trap.c b/sys/kern/subr_trap.c index 6d60ddb..ccf6479 100644 --- a/sys/kern/subr_trap.c +++ b/sys/kern/subr_trap.c @@ -90,6 +90,7 @@ userret(struct thread *td, struct trapframe *frame) =20 CTR3(KTR_SYSC, "userret: thread %p (pid %d, %s)", td, p->p_pid, td->td_name); +#if 0 #ifdef DIAGNOSTIC /* Check that we called signotify() enough. */ PROC_LOCK(p); @@ -100,6 +101,7 @@ userret(struct thread *td, struct trapframe *frame) thread_unlock(td); PROC_UNLOCK(p); #endif +#endif #ifdef KTRACE KTRUSERRET(td); #endif @@ -218,7 +220,14 @@ ast(struct trapframe *framep) ktrcsw(0, 1); #endif } - if (flags & TDF_NEEDSIGCHK) { + + /* + * Check for signals. Unlocked reads of p_pendingcnt or + * p_siglist might cause process-directed signal to be handled + * later. + */ + if (flags & TDF_NEEDSIGCHK || p->p_pendingcnt > 0 || + !SIGISEMPTY(p->p_siglist)) { PROC_LOCK(p); mtx_lock(&p->p_sigacts->ps_mtx); while ((sig =3D cursig(td, SIG_STOP_ALLOWED)) !=3D 0) diff --git a/sys/sys/signalvar.h b/sys/sys/signalvar.h index 89b40f0..b39f2bf 100644 --- a/sys/sys/signalvar.h +++ b/sys/sys/signalvar.h @@ -252,9 +252,10 @@ typedef struct sigqueue { =20 /* Return nonzero if process p has an unmasked pending signal. */ #define SIGPENDING(td) \ - (!SIGISEMPTY((td)->td_siglist) && \ - !sigsetmasked(&(td)->td_siglist, &(td)->td_sigmask)) - + ((!SIGISEMPTY((td)->td_siglist) && \ + !sigsetmasked(&(td)->td_siglist, &(td)->td_sigmask)) || \ + (!SIGISEMPTY((td)->td_proc->p_siglist) && \ + !sigsetmasked(&(td)->td_proc->p_siglist, &(td)->td_sigmask))) /* * Return the value of the pseudo-expression ((*set & ~*mask) !=3D 0). Th= is * is an optimized version of SIGISEMPTY() on a temporary variable @@ -336,6 +337,7 @@ void sigexit(struct thread *td, int signum) __dead2; int sig_ffs(sigset_t *set); void siginit(struct proc *p); void signotify(struct thread *td); +void tdsigcleanup(struct thread *td); int tdsignal(struct proc *p, struct thread *td, int sig, ksiginfo_t *ksi); void trapsignal(struct thread *td, ksiginfo_t *); diff --git a/tools/regression/sigqueue/sigqtest1/sigqtest1.c b/tools/regres= sion/sigqueue/sigqtest1/sigqtest1.c index 0f40021..f0201c3 100644 --- a/tools/regression/sigqueue/sigqtest1/sigqtest1.c +++ b/tools/regression/sigqueue/sigqtest1/sigqtest1.c @@ -1,12 +1,14 @@ /* $FreeBSD$ */ -#include -#include #include #include +#include +#include +#include =20 int received; =20 -void handler(int sig, siginfo_t *si, void *ctx) +void +handler(int sig, siginfo_t *si, void *ctx) { if (si->si_code !=3D SI_QUEUE) errx(1, "si_code !=3D SI_QUEUE"); @@ -15,7 +17,8 @@ void handler(int sig, siginfo_t *si, void *ctx) received++; } =20 -int main() +int +main() { struct sigaction sa; union sigval val; diff --git a/tools/regression/sigqueue/sigqtest2/sigqtest2.c b/tools/regres= sion/sigqueue/sigqtest2/sigqtest2.c index 078ea81..50b579d 100644 --- a/tools/regression/sigqueue/sigqtest2/sigqtest2.c +++ b/tools/regression/sigqueue/sigqtest2/sigqtest2.c @@ -1,24 +1,29 @@ /* $FreeBSD$ */ -#include -#include -#include -#include #include #include +#include +#include +#include +#include +#include +#include =20 int stop_received; int exit_received; int cont_received; =20 -void job_handler(int sig, siginfo_t *si, void *ctx) +void +job_handler(int sig, siginfo_t *si, void *ctx) { int status; int ret; =20 if (si->si_code =3D=3D CLD_STOPPED) { + printf("%d: stop received\n", si->si_pid); stop_received =3D 1; kill(si->si_pid, SIGCONT); } else if (si->si_code =3D=3D CLD_EXITED) { + printf("%d: exit received\n", si->si_pid); ret =3D waitpid(si->si_pid, &status, 0); if (ret =3D=3D -1) errx(1, "waitpid"); @@ -26,11 +31,13 @@ void job_handler(int sig, siginfo_t *si, void *ctx) errx(1, "!WIFEXITED(status)"); exit_received =3D 1; } else if (si->si_code =3D=3D CLD_CONTINUED) { + printf("%d: cont received\n", si->si_pid); cont_received =3D 1; } } =20 -void job_control_test() +void +job_control_test(void) { struct sigaction sa; pid_t pid; @@ -43,9 +50,12 @@ void job_control_test() stop_received =3D 0; cont_received =3D 0; exit_received =3D 0; + fflush(stdout); pid =3D fork(); if (pid =3D=3D 0) { + printf("child %d\n", getpid()); kill(getpid(), SIGSTOP); + sleep(2); exit(1); } =20 @@ -60,11 +70,13 @@ void job_control_test() printf("job control test OK.\n"); } =20 -void rtsig_handler(int sig, siginfo_t *si, void *ctx) +void +rtsig_handler(int sig, siginfo_t *si, void *ctx) { } =20 -int main() +int +main() { struct sigaction sa; sigset_t set; --jvmCgFKx2lledmPK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrQm/sACgkQC3+MBN1Mb4hTygCfVN6ia2OYpxHSXQS1jZWht6wc 8iIAoIq4qtkfEEQzINCI5h9zqifPXsI+ =pV7V -----END PGP SIGNATURE----- --jvmCgFKx2lledmPK-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 10 14:41:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B999B1065679 for ; Sat, 10 Oct 2009 14:41:22 +0000 (UTC) (envelope-from syso.fml@ext.no-route.org) Received: from core.kel1.no-route.org (core.kel1.no-route.org [217.70.192.207]) by mx1.freebsd.org (Postfix) with ESMTP id 79F8D8FC15 for ; Sat, 10 Oct 2009 14:41:21 +0000 (UTC) Received: from [0.0.0.0] (isis.kel.no-route.org [217.70.197.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by core.kel1.no-route.org (Postfix) with ESMTPSA id D62A713F6DC; Sat, 10 Oct 2009 14:39:38 +0000 (UTC) Message-ID: <4AD09D0F.5030700@ext.no-route.org> Date: Sat, 10 Oct 2009 16:41:19 +0200 From: Sylwester Sosnowski User-Agent: some piece of software MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4ACF131C.1060201@ext.no-route.org> <4ACF9CE7.30808@tomjudge.com> In-Reply-To: <4ACF9CE7.30808@tomjudge.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Tom Judge Subject: Re: Support for PC Engines ALIX2 reset pushbutton. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 14:41:22 -0000 Tom Judge schrieb: > Hi Sylwester, Hi, > > This is interesting, what boards should be supported? (I have a couple > of 2d3's) As far as I can see this should work with any Alix2xx boards (I'm using a 2d13, which is a new version of the 2d3 with a RTC-Battery, some extra Pin headers, ..) but maybe it's also compatible with Alix6xx. I guess you can check out the schematic on the vendor's site. > I will be needing something like this for my current project as well. Well, feel free to use it. > Thanks You're welcome. > TJ Regards, Sylwester From owner-freebsd-current@FreeBSD.ORG Sat Oct 10 15:08:07 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51D381065693 for ; Sat, 10 Oct 2009 15:08:07 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 0F0628FC20 for ; Sat, 10 Oct 2009 15:08:06 +0000 (UTC) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1MwdYD-000Nbu-M4 for freebsd-current@FreeBSD.org; Sat, 10 Oct 2009 19:08:05 +0400 From: Boris Samorodov To: freebsd-current@FreeBSD.org References: <10236192@bb.ipt.ru> Date: Sat, 10 Oct 2009 19:08:05 +0400 In-Reply-To: <10236192@bb.ipt.ru> (Boris Samorodov's message of "Sat, 10 Oct 2009 19:05:35 +0400") Message-ID: <22716042@bb.ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: [amd64, lib32] ccache and buldworld: suffix or operands invalid for `mov' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 15:08:07 -0000 Hello List, I'm new to using devel/ccache, so need help how to further diagnose the problem. The world builds fine without ccache. But with ccache enabled the following error occures: ----- ===> lib/csu/i386-elf (obj,depend,all,install) rm -f .depend CC='/usr/local/libexec/ccache/world-cc' mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include /usr/src/lib/csu/i386-elf/crt1.c /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S /usr/local/libexec/ccache/world-cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crt1.c {standard input}: Assembler messages: {standard input}:27: Error: suffix or operands invalid for `mov' *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 ----- That is for: ----- % uname -a FreeBSD tba.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Mon Oct 5 19:56:42 MSD 2009 root@tba.ipt.ru:/usr/obj/usr/src/sys/TBA amd64 % ccache -V ccache version 2.4 ----- So is it a ccache or FreeBSD sources or /dev/hands to blame? What to do further? Thanks. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sat Oct 10 16:08:09 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB6B3106566B for ; Sat, 10 Oct 2009 16:08:09 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id A67178FC19 for ; Sat, 10 Oct 2009 16:08:09 +0000 (UTC) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1MweUK-000OKD-Bv for freebsd-current@FreeBSD.org; Sat, 10 Oct 2009 20:08:08 +0400 From: Boris Samorodov To: freebsd-current@FreeBSD.org References: <10236192@bb.ipt.ru> <22716042@bb.ipt.ru> Date: Sat, 10 Oct 2009 20:08:08 +0400 In-Reply-To: <22716042@bb.ipt.ru> (Boris Samorodov's message of "Sat, 10 Oct 2009 19:08:05 +0400") Message-ID: <90552439@bb.ipt.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: [amd64, lib32] ccache and buldworld: suffix or operands invalid for `mov' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 16:08:10 -0000 On Sat, 10 Oct 2009 19:08:05 +0400 Boris Samorodov wrote: > I'm new to using devel/ccache, so need help how to further diagnose > the problem. The world builds fine without ccache. But with ccache > enabled the following error occures: > ----- > ===> lib/csu/i386-elf (obj,depend,all,install) > rm -f .depend > CC='/usr/local/libexec/ccache/world-cc' mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include /usr/src/lib/csu/i386-elf/crt1.c /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S > /usr/local/libexec/ccache/world-cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crt1.c > {standard input}: Assembler messages: > {standard input}:27: Error: suffix or operands invalid for `mov' > *** Error code 1 > Stop in /usr/src/lib/csu/i386-elf. > *** Error code 1 > ----- > That is for: > ----- > % uname -a > FreeBSD tba.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Mon Oct 5 19:56:42 MSD 2009 root@tba.ipt.ru:/usr/obj/usr/src/sys/TBA amd64 > % ccache -V > ccache version 2.4 > ----- > So is it a ccache or FreeBSD sources or /dev/hands to blame? > What to do further? Thanks. David Wolfskill adviced to clean the cache. That didn't work, the same error. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sat Oct 10 16:49:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DB09106566B for ; Sat, 10 Oct 2009 16:49:12 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id E18708FC0C for ; Sat, 10 Oct 2009 16:49:11 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n9AGn78I028391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Oct 2009 18:49:10 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4AD0BAFB.6020207@omnilan.de> Date: Sat, 10 Oct 2009 18:48:59 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig88EA98E593F43FE117E55494" Subject: shutdown not working with uart console X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 16:49:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig88EA98E593F43FE117E55494 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Dear coders, I recognized one RELENG_8 problem when trying to shutdown via serial=20 console. While shutdown via SSH works like expected, when called via=20 serial console it keeps hanging forever. I compiled a debug kernel for my embedded device and got the following=20 backtrace: ~KDB: enter: Line break on console [thread pid 1102 tid 100074 ] Stopped at kdb_enter+0x3b: movl $0,kdb_why db> bt Tracing pid 1102 tid 100074 td 0xc36c26c0 kdb_enter(c08aca1d,c08b61ae,d5c5e894,c35a0180,0,...) at kdb_enter+0x3b uart_intr(c35a0100,c36c26c0,c344a900,c347b0d0,4,...) at uart_intr+0x298 intr_event_handle(c344a900,d5c5e8ac,c36c26c0,c37a9ad0,1ce,...) at=20 intr_event_handle+0x4b intr_execute_handlers(c347b0d0,d5c5e8ac,0,d5c5e90c,c0852ed4,...) at=20 intr_execute_handlers+0x48 lapic_handle_intr(38,d5c5e8ac) at lapic_handle_intr+0x3a Xapic_isr1() at Xapic_isr1+0x34 --- interrupt, eip =3D 0xc05d0814, esp =3D 0xd5c5e8ec, ebp =3D 0xd5c5e90c= --- _lockmgr_assert(c37a9ad0,1,c08d41d6,1ce,d5c5e940,...) at=20 _lockmgr_assert+0x13e __lockmgr_args(c37a9ad0,100000,c37a9aec,0,0,...) at __lockmgr_args+0x16b vop_stdunlock(d5c5e9ec,0,c36c26c0,80000,c37a9a78,...) at vop_stdunlock+0x= 55 VOP_UNLOCK_APV(c0912b40,d5c5e9ec,c091d71c,c09477e0,c37a9a78,...) at=20 VOP_UNLOCK_APV+0x9a _vn_lock(c37a9a78,80100,c08d4ec2,823,c08c5fec,...) at _vn_lock+0xbc vget(c37a9a78,80100,c36c26c0,4f3,c37a9a78,...) at vget+0x61 devfs_revoke(d5c5eaa4,d5c5eaa4,c08c2b09,157,c36cf330,...) at=20 devfs_revoke+0x210 exit1(c36c26c0,1,c08c78e8,ab6,3,...) at exit1+0x9ff sigexit(c36c26c0,1,c08c78e8,a49,0,...) at sigexit+0x84 postsig(1,64,c08cc013,df,c36cf2a8,...) at postsig+0x34d ast(d5c5ed38) at ast+0x42f doreti_ast() at doreti_ast+0x17 I have no idea where the problem is, nor how to get more info. Any help appreciated. Thanks in advance, -Harry --------------enig88EA98E593F43FE117E55494 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.13 (FreeBSD) iEYEARECAAYFAkrQuwMACgkQLDqVQ9VXb8h1ygCbB4EDdp0GoaG0Fp47k2+mk+Aw 6/UAni4i9MfRosxnpxsPLJDznN2YG11a =6UVD -----END PGP SIGNATURE----- --------------enig88EA98E593F43FE117E55494-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 10 16:58:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 705051065670 for ; Sat, 10 Oct 2009 16:58:07 +0000 (UTC) (envelope-from miki.bsd@gmail.com) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by mx1.freebsd.org (Postfix) with ESMTP id DD4EC8FC1D for ; Sat, 10 Oct 2009 16:58:06 +0000 (UTC) Received: by bwz23 with SMTP id 23so1213272bwz.43 for ; Sat, 10 Oct 2009 09:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=eGyoGflHESc7C71I7WmbX4dhLnIOsoq7PVyFrfyCYis=; b=NVV1Ad3sDC4O30b8oFedQGWJjaVqOwZcLzoy4Wh131fiCmw7q+ip6K72sqV1tSgIyA jW10MtXGGltBCjwDyICvC8Z89vNYpxZsDdFc4/9XunflnwxzgjTa6ZFaOiBNamKTWcHg Tm1xtEO3/k3a9jOZZRpnF1d5FsJV1tiMHDmf0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=r+9QDO+XMgHpOB4cMzT/cBkYCHsMxYPbRP1S5NPR4rJ267L6Eldx2DC2uVOPrdF8Lj Qy0tKOM5C9DO+SoDmhWe+3aZShrewhZqUgDGkIFFobT/pLdgK0c/YgJaIXEhIpTzN05V IZMAwNG8MOQsXHjtpN50+XQq8HxPUi6sw4IVA= MIME-Version: 1.0 Received: by 10.223.73.20 with SMTP id o20mr1142378faj.71.1255192389217; Sat, 10 Oct 2009 09:33:09 -0700 (PDT) Date: Sat, 10 Oct 2009 18:33:09 +0200 Message-ID: <261c29700910100933ked4245bg47f0cf826a1c3a10@mail.gmail.com> From: Miki To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: SIGBUS with sftp from OpenSSH 5.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 16:58:07 -0000 Hi all, sftp from OpenSSH 5.3 exit on a SIGBUS when trying to fetch a file. sftp from OpenSSH 5.2 worked fine. here is a backtrace : #0 0x000000000040b3cf in ?? () #1 0x0000000800efb8b0 in globfree () from /lib/libc.so.7 #2 0x0000000800efbe01 in globfree () from /lib/libc.so.7 #3 0x0000000800efc491 in glob () from /lib/libc.so.7 #4 0x000000000040a77f in remote_glob (conn=0x801a08740, pattern=0x801a0b080 "/home/miki/mech", flags=0, errfunc=0, pglob=0x7fffffffd680) at /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp-glob.c:148 #5 0x00000000004038f4 in process_get (conn=0x801a08740, src=0x801a0b070 "/home/miki/mech", dst=0x801a04080 "/tmp/", pwd=0x801a0b050 "/home/miki", pflag=0) at /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp.c:507 #6 0x00000000004059c7 in parse_dispatch_command (conn=0x801a08740, cmd=0x7fffffffdcb0 "get /home/miki/mech /tmp/", pwd=0x7fffffffdc98, err_abort=1) at /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp.c:1264 #7 0x00000000004067ec in interactive_loop (fd_in=3, fd_out=3, file1=0x801a0b04a "mech", file2=0x7fffffffe981 "/tmp/") at /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp.c:1531 #8 0x000000000040733b in main (argc=3, argv=0x7fffffffe5c8) at /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp.c:1825 I'm running FreeBSD cocyte.homeunix.org 9.0-CURRENT FreeBSD 9.0-CURRENT #6 r197928M: Sat Oct 10 13:37:22 CEST 2009 miki@cocyte.homeunix.org:/usr/obj/usr/src/sys/COCYTE amd64 Kernel and userland are in sync. I can provide full backtrace or more debugging information if necessary. Thanks. Miki From owner-freebsd-current@FreeBSD.ORG Sat Oct 10 17:51:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7430C106568F for ; Sat, 10 Oct 2009 17:51:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id E421C8FC12 for ; Sat, 10 Oct 2009 17:51:19 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n9AHpGBX011113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Oct 2009 20:51:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n9AHpF7w084486; Sat, 10 Oct 2009 20:51:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n9AHpFaY084485; Sat, 10 Oct 2009 20:51:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 10 Oct 2009 20:51:15 +0300 From: Kostik Belousov To: Harald Schmalzbauer Message-ID: <20091010175115.GC2259@deviant.kiev.zoral.com.ua> References: <4AD0BAFB.6020207@omnilan.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hH1sCSVFCbBgKiGT" Content-Disposition: inline In-Reply-To: <4AD0BAFB.6020207@omnilan.de> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: shutdown not working with uart console X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 17:51:20 -0000 --hH1sCSVFCbBgKiGT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 10, 2009 at 06:48:59PM +0200, Harald Schmalzbauer wrote: > Dear coders, >=20 > I recognized one RELENG_8 problem when trying to shutdown via serial=20 > console. While shutdown via SSH works like expected, when called via=20 > serial console it keeps hanging forever. > I compiled a debug kernel for my embedded device and got the following=20 > backtrace: > ~KDB: enter: Line break on console > [thread pid 1102 tid 100074 ] > Stopped at kdb_enter+0x3b: movl $0,kdb_why > db> bt > Tracing pid 1102 tid 100074 td 0xc36c26c0 > kdb_enter(c08aca1d,c08b61ae,d5c5e894,c35a0180,0,...) at kdb_enter+0x3b > uart_intr(c35a0100,c36c26c0,c344a900,c347b0d0,4,...) at uart_intr+0x298 > intr_event_handle(c344a900,d5c5e8ac,c36c26c0,c37a9ad0,1ce,...) at=20 > intr_event_handle+0x4b > intr_execute_handlers(c347b0d0,d5c5e8ac,0,d5c5e90c,c0852ed4,...) at=20 > intr_execute_handlers+0x48 > lapic_handle_intr(38,d5c5e8ac) at lapic_handle_intr+0x3a > Xapic_isr1() at Xapic_isr1+0x34 > --- interrupt, eip =3D 0xc05d0814, esp =3D 0xd5c5e8ec, ebp =3D 0xd5c5e90c= --- > _lockmgr_assert(c37a9ad0,1,c08d41d6,1ce,d5c5e940,...) at=20 > _lockmgr_assert+0x13e > __lockmgr_args(c37a9ad0,100000,c37a9aec,0,0,...) at __lockmgr_args+0x16b > vop_stdunlock(d5c5e9ec,0,c36c26c0,80000,c37a9a78,...) at vop_stdunlock+0x= 55 > VOP_UNLOCK_APV(c0912b40,d5c5e9ec,c091d71c,c09477e0,c37a9a78,...) at=20 > VOP_UNLOCK_APV+0x9a > _vn_lock(c37a9a78,80100,c08d4ec2,823,c08c5fec,...) at _vn_lock+0xbc > vget(c37a9a78,80100,c36c26c0,4f3,c37a9a78,...) at vget+0x61 > devfs_revoke(d5c5eaa4,d5c5eaa4,c08c2b09,157,c36cf330,...) at=20 > devfs_revoke+0x210 > exit1(c36c26c0,1,c08c78e8,ab6,3,...) at exit1+0x9ff > sigexit(c36c26c0,1,c08c78e8,a49,0,...) at sigexit+0x84 > postsig(1,64,c08cc013,df,c36cf2a8,...) at postsig+0x34d > ast(d5c5ed38) at ast+0x42f > doreti_ast() at doreti_ast+0x17 >=20 > I have no idea where the problem is, nor how to get more info. > Any help appreciated. I wondering whether I was too conservative in r195509. Please try this. diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c index 39b48e0..b96cdbf 100644 --- a/sys/kern/kern_exit.c +++ b/sys/kern/kern_exit.c @@ -340,10 +340,10 @@ exit1(struct thread *td, int rv) =20 if (ttyvp !=3D NULL) { sx_xunlock(&proctree_lock); - vn_lock(ttyvp, LK_EXCLUSIVE | LK_RETRY); - if (ttyvp->v_type !=3D VBAD) + if (vn_lock(ttyvp, LK_EXCLUSIVE) =3D=3D 0) { VOP_REVOKE(ttyvp, REVOKEALL); - VOP_UNLOCK(ttyvp, 0); + VOP_UNLOCK(ttyvp, 0); + } sx_xlock(&proctree_lock); } } --hH1sCSVFCbBgKiGT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrQyZMACgkQC3+MBN1Mb4gSHACglARbQ/Bc31BLaGw5AfDti9VN 6aoAoO5TSrtBfOWDKT5rvZhlrUYSntuY =46W4 -----END PGP SIGNATURE----- --hH1sCSVFCbBgKiGT-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 10 19:38:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08EDD106566B for ; Sat, 10 Oct 2009 19:38:17 +0000 (UTC) (envelope-from ehrmann@gmail.com) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by mx1.freebsd.org (Postfix) with ESMTP id D54AF8FC0C for ; Sat, 10 Oct 2009 19:38:16 +0000 (UTC) Received: from [10.0.0.171] (unknown [64.9.236.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3198122DD6D for ; Sat, 10 Oct 2009 15:38:14 -0400 (EDT) Message-ID: <4AD0E286.9030508@gmail.com> Date: Sat, 10 Oct 2009 12:37:42 -0700 From: David Ehrmann User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Strange md/unionfs issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 19:38:17 -0000 I have a system running on a flash disk. To prevent it from wearing out quickly, I don't run with a swap and mount /tmp and /var from memory. Because /var needs some directories and contains files I probably should save from time to time, I mount it from flash, mount /var to /var_real so I can access the underlying files, and then I mount an md device on top of /var as a unionfs. Initially, it seems to work, but seconds later, the unionfs seems to fail. server# cd /var server# ls .snap crash heimdal preserve yp account cron log run at db mail rwho audit empty msgs spool backups games named tmp server# mount /dev/ad0s1a on / (ufs, NFS exported, local) devfs on /dev (devfs, local, multilabel) /dev/ad0s1f on /usr (ufs, local, soft-updates) /dev/ad0s1e on /var (ufs, local, soft-updates) /var on /var_real (nullfs, local, noatime) /dev/md0 on /var (ufs, local, union, soft-updates) /dev/md1 on /tmp (ufs, local, soft-updates) server# cd /var_real/ server# ls .snap crash heimdal preserve yp account cron log run at db mail rwho audit empty msgs spool backups games named tmp server# cd /var server# ls .snap server# Removing /var_real from the fstab didn't help. Here's the full version: # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1a / ufs rw 1 1 /dev/ad0s1f /usr ufs rw 2 2 /dev/ad0s1e /var ufs rw 2 2 /var /var_real nullfs rw,noatime md /var mfs rw,union,-s128M md /tmp mfs rw,-s128M Ideas? From owner-freebsd-current@FreeBSD.ORG Sat Oct 10 20:14:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0B451065672 for ; Sat, 10 Oct 2009 20:14:37 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 3888E8FC18 for ; Sat, 10 Oct 2009 20:14:36 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n9AKEZHw030952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Oct 2009 22:14:35 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4AD0EB24.5020700@omnilan.de> Date: Sat, 10 Oct 2009 22:14:28 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Kostik Belousov References: <4AD0BAFB.6020207@omnilan.de> <20091010175115.GC2259@deviant.kiev.zoral.com.ua> In-Reply-To: <20091010175115.GC2259@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4A06FE475FD7C249E7596AC5" Cc: freebsd-current@freebsd.org Subject: Re: shutdown not working with uart console X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 20:14:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4A06FE475FD7C249E7596AC5 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Kostik Belousov schrieb am 10.10.2009 19:51 (localtime): =2E.. > I wondering whether I was too conservative in r195509. > Please try this. >=20 > diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c > index 39b48e0..b96cdbf 100644 > --- a/sys/kern/kern_exit.c > +++ b/sys/kern/kern_exit.c > @@ -340,10 +340,10 @@ exit1(struct thread *td, int rv) > =20 > if (ttyvp !=3D NULL) { > sx_xunlock(&proctree_lock); > - vn_lock(ttyvp, LK_EXCLUSIVE | LK_RETRY); > - if (ttyvp->v_type !=3D VBAD) > + if (vn_lock(ttyvp, LK_EXCLUSIVE) =3D=3D 0) { > VOP_REVOKE(ttyvp, REVOKEALL); > - VOP_UNLOCK(ttyvp, 0); > + VOP_UNLOCK(ttyvp, 0); > + } > sx_xlock(&proctree_lock); > } > } Great, thanks a lot, this fixes my problem :) There's one LOR left at shutdown (vfs_mount+ffs_vfsops) and one at=20 startup (unionfs+ufs) but that's completele unrelated I guess. Thanks, -Harry --------------enig4A06FE475FD7C249E7596AC5 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.13 (FreeBSD) iEYEARECAAYFAkrQ6ysACgkQLDqVQ9VXb8izfACfYoLVRR5VuZXhIK2bKfYfpSeh /toAn3BDNDKOEgu0D1PV5c5+RhwmgWHp =07/d -----END PGP SIGNATURE----- --------------enig4A06FE475FD7C249E7596AC5-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 10 20:25:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C3DC106568D for ; Sat, 10 Oct 2009 20:25:06 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id B03A78FC1D for ; Sat, 10 Oct 2009 20:25:05 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n9AKP4ma031091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Oct 2009 22:25:04 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4AD0ED9F.3080706@omnilan.de> Date: Sat, 10 Oct 2009 22:25:03 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Alexander Best References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD8B84B0F37AD484C517CA65F" Cc: freebsd-current@freebsd.org Subject: Re: Where to report LORs? (ffs and unionfs LORs included X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 20:25:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD8B84B0F37AD484C517CA65F Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Alexander Best schrieb am 07.07.2009 21:33 (localtime): > try http://sources.zabbadoz.net/freebsd/lor.html I still see a unionfs LOR with RELENG_8 which is not listed, so I'd like = to report it again. lock order reversal: 1st 0xc372c488 unionfs (unionfs) @=20 /FlashBSD/src/sys/fs/unionfs/union_subr.c:356 2nd 0xc372c594 ufs (ufs) @ /FlashBSD/src/sys/kern/vfs_subr.c:2188 KDB: stack backtrace: db_trace_self_wrapper(c0616390,c08cd5d5,c3416770,c3416500,d5c42864,...)=20 at db_trace_self_wrapper+0x26 _witness_debugger(c08cd5d5,c372c594,c08c0703,c3416500,c08d4ec2,...) at=20 _witness_debugger+0x49 witness_checkorder(c372c594,9,c08d4ec2,88c,0,...) at=20 witness_checkorder+0x6ec __lockmgr_args(c372c594,80100,c372c5b0,0,0,...) at __lockmgr_args+0xc97 ffs_lock(d5c42958,8,c36c4764,80100,c372c53c,...) at ffs_lock+0x96 VOP_LOCK1_APV(c09374a0,d5c42958,c05d89e9,c09477c0,c372c53c,...) at=20 VOP_LOCK1_APV+0x9a _vn_lock(c372c53c,80100,c08d4ec2,88c,c0877c6e,...) at _vn_lock+0x46 vrele(c372c53c,d5c429d8,c372c4a4,0,0,...) at vrele+0x12a unionfs_noderem(c372c430,c36c46c0,d5c42a44,c06764fc,d5c42a20,...) at=20 unionfs_noderem+0x1e5 unionfs_reclaim(d5c42a20,d5c42a20,0,0,c372c4a4,...) at unionfs_reclaim+0x= 1b vgonel(c372c4a4,0,c08d4ec2,9c5,c372c4a4,...) at vgonel+0x100 vrecycle(c372c430,c36c46c0,d5c42aa4,c0675c29,d5c42a8c,...) at vrecycle+0x= 6a unionfs_inactive(d5c42a8c,d5c42a8c,c08d4ec2,924,c0947780,...) at=20 unionfs_inactive+0x28 vinactive(c372c594,d5c42ac0,c08d4ec2,8aa,c3451de0,...) at vinactive+0x6a vput(c372c430,ffffffdf,c344ab80,0,c36c46c0,...) at vput+0x205 kern_statat_vnhook(c36c46c0,0,ffffff9c,28209e1c,0,...) at=20 kern_statat_vnhook+0xe0 kern_statat(c36c46c0,0,ffffff9c,28209e1c,0,...) at kern_statat+0x3c kern_stat(c36c46c0,28209e1c,0,d5c42c18,c0a83a18,...) at kern_stat+0x36 stat(c36c46c0,d5c42cf8,8,d5c42d38,c0916cd0,...) at stat+0x2b syscall(d5c42d38) at syscall+0x176 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (188, FreeBSD ELF32, stat), eip =3D 0x281c6c2b, esp =3D=20 0xbfbfe96c, ebp =3D 0xbfbfea68 --- So far I couldn't notice any deadlock, but the box is not in production y= et. -Harry --------------enigD8B84B0F37AD484C517CA65F 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.13 (FreeBSD) iEYEARECAAYFAkrQ7aAACgkQLDqVQ9VXb8iy2wCfWZ0ykfyvAg08FHKeCJTLPvDf qFEAoIj8iEiDC1Flk1/b7ZGVRZD3t1cL =DMou -----END PGP SIGNATURE----- --------------enigD8B84B0F37AD484C517CA65F-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 10 21:49:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F27F1065676 for ; Sat, 10 Oct 2009 21:49:09 +0000 (UTC) (envelope-from ehrmann@gmail.com) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by mx1.freebsd.org (Postfix) with ESMTP id 655FA8FC08 for ; Sat, 10 Oct 2009 21:49:09 +0000 (UTC) Received: from [10.0.0.171] (unknown [64.9.236.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1B2B422DD6D for ; Sat, 10 Oct 2009 17:49:06 -0400 (EDT) Message-ID: <4AD10135.9050002@gmail.com> Date: Sat, 10 Oct 2009 14:48:37 -0700 From: David Ehrmann User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4AD0E286.9030508@gmail.com> In-Reply-To: <4AD0E286.9030508@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Strange md/unionfs issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 21:49:09 -0000 David Ehrmann wrote: > I have a system running on a flash disk. To prevent it from wearing > out quickly, I don't run with a swap and mount /tmp and /var from > memory. Because /var needs some directories and contains files I > probably should save from time to time, I mount it from flash, mount > /var to /var_real so I can access the underlying files, and then I > mount an md device on top of /var as a unionfs. Initially, it seems > to work, but seconds later, the unionfs seems to fail. > > server# cd /var > server# ls > .snap crash heimdal preserve yp > account cron log run > at db mail rwho > audit empty msgs spool > backups games named tmp > server# mount > /dev/ad0s1a on / (ufs, NFS exported, local) > devfs on /dev (devfs, local, multilabel) > /dev/ad0s1f on /usr (ufs, local, soft-updates) > /dev/ad0s1e on /var (ufs, local, soft-updates) > /var on /var_real (nullfs, local, noatime) > /dev/md0 on /var (ufs, local, union, soft-updates) > /dev/md1 on /tmp (ufs, local, soft-updates) > server# cd /var_real/ > server# ls > .snap crash heimdal preserve yp > account cron log run > at db mail rwho > audit empty msgs spool > backups games named tmp > server# cd /var > server# ls > .snap > server# > > Removing /var_real from the fstab didn't help. Here's the full version: > > # Device Mountpoint FStype Options > Dump Pass# > /dev/ad0s1a / ufs rw 1 1 > /dev/ad0s1f /usr ufs rw 2 2 > > /dev/ad0s1e /var ufs rw 2 2 > /var /var_real nullfs rw,noatime > md /var mfs rw,union,-s128M > > md /tmp mfs rw,-s128M > > Ideas? > It looks like I don't have the problem if I mount the md on top of /var if /var is really on /, i.e. not a mount point. From owner-freebsd-current@FreeBSD.ORG Sat Oct 10 22:04:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6448C1065695 for ; Sat, 10 Oct 2009 22:04:22 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2AA2E8FC1F for ; Sat, 10 Oct 2009 22:04:22 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:5595:f502:d368:640e] (unknown [IPv6:2001:7b8:3a7:0:5595:f502:d368:640e]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 631E35C43; Sun, 11 Oct 2009 00:04:20 +0200 (CEST) Message-ID: <4AD104E4.2070009@andric.com> Date: Sun, 11 Oct 2009 00:04:20 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.4pre) Gecko/20091003 Shredder/3.0pre MIME-Version: 1.0 To: Harald Schmalzbauer References: <4AD0BAFB.6020207@omnilan.de> <20091010175115.GC2259@deviant.kiev.zoral.com.ua> <4AD0EB24.5020700@omnilan.de> In-Reply-To: <4AD0EB24.5020700@omnilan.de> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: shutdown not working with uart console X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2009 22:04:22 -0000 On 2009-10-10 22:14, Harald Schmalzbauer wrote: >> I wondering whether I was too conservative in r195509. >> Please try this. >> >> diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c >> index 39b48e0..b96cdbf 100644 >> --- a/sys/kern/kern_exit.c >> +++ b/sys/kern/kern_exit.c >> @@ -340,10 +340,10 @@ exit1(struct thread *td, int rv) >> >> if (ttyvp != NULL) { >> sx_xunlock(&proctree_lock); >> - vn_lock(ttyvp, LK_EXCLUSIVE | LK_RETRY); >> - if (ttyvp->v_type != VBAD) >> + if (vn_lock(ttyvp, LK_EXCLUSIVE) == 0) { >> VOP_REVOKE(ttyvp, REVOKEALL); >> - VOP_UNLOCK(ttyvp, 0); >> + VOP_UNLOCK(ttyvp, 0); >> + } >> sx_xlock(&proctree_lock); >> } >> } > > Great, thanks a lot, this fixes my problem :) I had seen this issue too, some time ago, but disregarded it as just some anomaly. In any case, the above patch also fixes it for me.