From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 01:38:32 2011 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 678C41065743; Sun, 18 Sep 2011 01:38:32 +0000 (UTC) (envelope-from poyopoyo@puripuri.plala.or.jp) Received: from msa03b.plala.or.jp (msa03.plala.or.jp [IPv6:2400:7800:0:5010::3]) by mx1.freebsd.org (Postfix) with ESMTP id C7F518FC08; Sun, 18 Sep 2011 01:38:31 +0000 (UTC) Received: from i125-202-7-242.s02.a026.ap.plala.or.jp ([125.202.7.242]) by msa03b.plala.or.jp with ESMTP id <20110918013830.ELTT5763.msa03b.plala.or.jp@i125-202-7-242.s02.a026.ap.plala.or.jp>; Sun, 18 Sep 2011 10:38:30 +0900 Date: Sun, 18 Sep 2011 10:38:29 +0900 Message-ID: <86ipoqsk8a.wl%poyopoyo@puripuri.plala.or.jp> From: poyopoyo@puripuri.plala.or.jp To: Gabor Kovesdan To: freebsd-current@FreeBSD.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.3 (amd64-portbld-freebsd9.0) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-VirusScan: Outbound; msa03b; Sun, 18 Sep 2011 10:38:30 +0900 X-Mailman-Approved-At: Sun, 18 Sep 2011 01:44:43 +0000 Cc: Subject: bsdgrep: does anyone see this? 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, 18 Sep 2011 01:38:32 -0000 Hi, On the latest -CURRENT of r225642 built with single line "WITH_BSD_GREP=yes" in src.conf, $ type -a grep grep is /usr/bin/grep $ grep -V grep (BSD grep) 2.5.1-FreeBSD $ locale LANG= LC_CTYPE="C" LC_COLLATE="C" LC_TIME=C LC_NUMERIC="C" LC_MONETARY="C" LC_MESSAGES=C LC_ALL= $ echo |grep -q '^'; echo $? 1 $ echo |grep -qv '^'; echo $? 0 $ echo |gnugrep -q '^'; echo $? 0 $ echo |gnugrep -qv '^'; echo $? 1 I believe GNU grep is correct, and bsdgrep inverts logic when input is a newline. Imagine my astonishment when yes ""|grep -v '^$' scrolled out console text instantly. :) I also tested stock GNU grep on RELENG_8 chroot sandbox, bsd-grep-20110912 from ports on both RELENG_8 and 9-CURRENT, and found they work all OK as GNU grep. So I think this has been fixed in the latest bsdgrep but not checked in to -CURRENT yet. Am I correct? Does anyone see this on your 9-CURRENT box? -- kuro From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 03:40:11 2011 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 A24431065672 for ; Sun, 18 Sep 2011 03:40:11 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (unknown [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b2]) by mx1.freebsd.org (Postfix) with ESMTP id 6531E8FC14 for ; Sun, 18 Sep 2011 03:40:11 +0000 (UTC) Received: from meatwad.mouf.net (cpe-065-190-149-241.nc.res.rr.com [65.190.149.241]) (authenticated bits=0) by mouf.net (8.14.4/8.14.4) with ESMTP id p8I3e9YM065564 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sat, 17 Sep 2011 23:40:10 -0400 (EDT) (envelope-from swills@FreeBSD.org) Message-ID: <4E756819.50601@FreeBSD.org> Date: Sat, 17 Sep 2011 23:40:09 -0400 From: Steve Wills User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110531 Thunderbird/3.1.10 MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mouf.net [204.109.58.86]); Sat, 17 Sep 2011 23:40:10 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.97.2 at mouf.net X-Virus-Status: Clean Cc: Subject: 7.x gcc won't run 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, 18 Sep 2011 03:40:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Yesterday afternoon, I updated my -CURRENT host. Then I updated the "jail"s (chroots) that my ports tinderbox uses. Now I've found that the 7.x and 8.x ones can't run gcc as it reports: gcc: Internal error: Abort trap: 6 (program cc1) 9.x things work fine and other 7.x and 8.x binaries seem to run fine. Anyone have any ideas? Thanks, Steve -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOdWgYAAoJEPXPYrMgexuhDcYH/jImRJ08OFgGzOowHMe/uhoM 2dx1qW/BQprnmv3oRZ7XtOiHNpi18t/rgtzSG+LIojbYdGvVRIyEWaU/tLfGjGGA HaVAOGtBaLv4RuLRanFdkRDbMS3/GZmZZsDf+UrxTxgihsLRwi7Vx20xa5aVCeOa OYtRbSLB3xePIiExOjqLtqibCdkcohZe+mucsJjttVPLoxo4Nso0Be125XRJ4RcY aZ/lwYCbxurGFLcfakKCLvBZzb0TB8pnShMtxDCsm6VsKjO5rMCMCyTsxApMxdWe E9kcInvkxEfp44panzKrazN6/IXyCTuTmiCktQaBBsDQ8pHOpNPOSiwTz2wfpvM= =WNAv -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 03:38:52 2011 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 B8D51106564A; Sun, 18 Sep 2011 03:38:52 +0000 (UTC) (envelope-from poyopoyo@puripuri.plala.or.jp) Received: from msa03a.plala.or.jp (msa03.plala.or.jp [IPv6:2400:7800:0:5010::3]) by mx1.freebsd.org (Postfix) with ESMTP id 2151E8FC14; Sun, 18 Sep 2011 03:38:51 +0000 (UTC) Received: from i125-202-7-242.s02.a026.ap.plala.or.jp ([125.202.7.242]) by msa02b.plala.or.jp with ESMTP id <20110918032819.OVMC16800.msa02b.plala.or.jp@i125-202-7-242.s02.a026.ap.plala.or.jp>; Sun, 18 Sep 2011 12:28:19 +0900 Date: Sun, 18 Sep 2011 12:28:19 +0900 Message-ID: <86hb4asf58.wl%poyopoyo@puripuri.plala.or.jp> From: poyopoyo@puripuri.plala.or.jp To: Gabor Kovesdan , freebsd-current@FreeBSD.org In-Reply-To: <86ipoqsk8a.wl%poyopoyo@puripuri.plala.or.jp> References: <86ipoqsk8a.wl%poyopoyo@puripuri.plala.or.jp> Mail-Followup-To: poyopoyo@puripuri.plala.or.jp, Gabor Kovesdan , freebsd-current@FreeBSD.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.3 (amd64-portbld-freebsd9.0) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-VirusScan: Outbound; msa02b; Sun, 18 Sep 2011 12:28:19 +0900 X-Mailman-Approved-At: Sun, 18 Sep 2011 03:45:04 +0000 Cc: Subject: Re: bsdgrep: does anyone see this? 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, 18 Sep 2011 03:38:52 -0000 http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/bsdgrep/Makefile#rev1.16 | - Update to 20110912 | Chabgelog: .. | + Bugfix: fix handling of ^$ anchors Oh I found it. Perhaps this one? -- kuro From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 03:58:59 2011 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 E13B0106566B; Sun, 18 Sep 2011 03:58:59 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 98A0A8FC15; Sun, 18 Sep 2011 03:58:59 +0000 (UTC) Received: from dhcp-192-168-2-22.wifi.xcllnt.net (atm.xcllnt.net [70.36.220.6]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id p8I3waOF014797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 17 Sep 2011 20:58:44 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20110916181559.GA31128@mech-cluster241.men.bris.ac.uk> Date: Sat, 17 Sep 2011 20:58:49 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20110916181559.GA31128@mech-cluster241.men.bris.ac.uk> To: Anton Shterenlikht X-Mailer: Apple Mail (2.1244.3) Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: ia64 r221488: panic: blockable sleep lock (sleep mutex) process lock @ /usr/src/sys/ia64/ia64/trap.c:562 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, 18 Sep 2011 03:59:00 -0000 On Sep 16, 2011, at 11:15 AM, Anton Shterenlikht wrote: > I know it's not exactly current anymore, but.. > > ia64 r221488 At this point in time, I don't have any clear indications that this is a code problem. I have found that different optimizations tend to affect the failure mode or rate. As such, I suspect GCC. It'll be difficult to find the bad code. -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 04:28:53 2011 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 3D61C106566C for ; Sun, 18 Sep 2011 04:28:53 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost03.isp.att.net (fmailhost03.isp.att.net [204.127.217.103]) by mx1.freebsd.org (Postfix) with ESMTP id 2C9818FC0A for ; Sun, 18 Sep 2011 04:28:53 +0000 (UTC) Date: Sun, 18 Sep 2011 04:28:52 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-72-147-183-55.sdf.bellsouth.net[72.147.183.55]) by isp.att.net (frfwmhc03) with SMTP id <20110918042852H03002sb3ae>; Sun, 18 Sep 2011 04:28:52 +0000 X-Originating-IP: [72.147.183.55] From: "Thomas Mueller" Cc: Antonio Olivares Subject: Re: no X after installing xorg + xfce 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, 18 Sep 2011 04:28:53 -0000 > I have successfully installed FreeBSD-9.0-BETA2 to an amd64 bit > machine, I have used the ports to install xfce and xorg. When I type > startx, I get a screen with a bunch of colors no mouse, no keyboard, > just colors. The machine has nvidia onboard graphics. I am trying to > get kernel sources installed via sysinstall to install nvidia-driver > but I can't get anywhere from any ftp site I select at random. I have > updated to latest sources available on the ports and it comes up the > same. I have to use the nv driver, should I try the nouveau driver? > What should I do? I want to help in testing and have no way to report > bugs as without X there's not much one can do :( > Is it not automatically installed when one goes into > /usr/ports/x11/xorg, and runs make install clean? > Regards, > Antonio You would get the xorg server with the xorg metaport/megaport. One thing I can think of is a little dirty trick I have seen in FreeBSD but not NetBSD or Linux, X comes up but no response to mouse or keyboard. I ran startx, got twm with its windows, but no response to mouse or keyboard. Cure was, to include in /etc/rc.conf hald_enable="YES" dbus_enable="YES" Tom From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 04:36:51 2011 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 A950C106566C for ; Sun, 18 Sep 2011 04:36:51 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 64F758FC08 for ; Sun, 18 Sep 2011 04:36:51 +0000 (UTC) Received: by qyk4 with SMTP id 4so5514953qyk.13 for ; Sat, 17 Sep 2011 21:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TlGqE8xeKwk3NB/BrsTMf8JtKNnoKmixj3ELn7mG/A4=; b=I2WAqMUZx5p0zm8COPan5k2LZRkXH5r3ftRMSoBGEVFezzsv7DJ1uFl/d6ueT6Rx92 eJZc0AzuH+kahGhBYgF02dxwyVYi1fHSsyQ9luhB8mZXEtEHo2ZTuIgmRTGWJkUy/gsa z/2RjL1zPKCjajeMDcwuFB4rB11f8uDrXj0RE= MIME-Version: 1.0 Received: by 10.224.18.203 with SMTP id x11mr824651qaa.92.1316320610419; Sat, 17 Sep 2011 21:36:50 -0700 (PDT) Received: by 10.224.37.83 with HTTP; Sat, 17 Sep 2011 21:36:50 -0700 (PDT) In-Reply-To: <20110918042853.3D61C106566C@hub.freebsd.org> References: <20110918042853.3D61C106566C@hub.freebsd.org> Date: Sat, 17 Sep 2011 21:36:50 -0700 Message-ID: From: Garrett Cooper To: "Thomas Mueller Subject: Re: no X after installing xorg + xfce 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, 18 Sep 2011 04:36:51 -0000 On Sat, Sep 17, 2011 at 9:28 PM, <"Thomas Mueller wrote: >> I have successfully installed FreeBSD-9.0-BETA2 to an amd64 bit >> machine, I have used the ports to install xfce and xorg. =A0When I type >> startx, I get a screen with a bunch of colors no mouse, no keyboard, >> just colors. =A0The machine has nvidia onboard graphics. =A0I am trying = to >> get kernel sources installed via sysinstall to install nvidia-driver >> but I can't get anywhere from any ftp site I select at random. =A0I have >> updated to latest sources available on the ports and it comes up the >> same. =A0I have to use the nv driver, should I try the nouveau driver? >> What should I do? =A0I want to help in testing and have no way to report >> bugs as without X there's not much one can do :( > >> Is it not automatically installed when one goes into >> /usr/ports/x11/xorg, and runs make install clean? > > You would get the xorg server with the xorg metaport/megaport. > > One thing I can think of is a little dirty trick I have seen in FreeBSD b= ut not NetBSD or Linux, X comes up but no response to mouse or keyboard. > > I ran startx, got twm with its windows, but no response to mouse or keybo= ard. > > Cure was, to include in /etc/rc.conf > > > hald_enable=3D"YES" > dbus_enable=3D"YES" This seems like more of a question@ issue. I doubt that the above claim is at fault, given past experience. What does /var/log/Xorg.0.log say, and what does your xorg.conf contain? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 05:18:56 2011 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 E3FA4106566C for ; Sun, 18 Sep 2011 05:18:56 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (unknown [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b2]) by mx1.freebsd.org (Postfix) with ESMTP id A53AC8FC0A for ; Sun, 18 Sep 2011 05:18:56 +0000 (UTC) Received: from meatwad.mouf.net (cpe-065-190-149-241.nc.res.rr.com [65.190.149.241]) (authenticated bits=0) by mouf.net (8.14.4/8.14.4) with ESMTP id p8I5ImQ7065893 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sun, 18 Sep 2011 01:18:54 -0400 (EDT) (envelope-from swills@FreeBSD.org) Message-ID: <4E757F36.6040009@FreeBSD.org> Date: Sun, 18 Sep 2011 01:18:46 -0400 From: Steve Wills User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110531 Thunderbird/3.1.10 MIME-Version: 1.0 To: current@FreeBSD.org References: <4E756819.50601@FreeBSD.org> In-Reply-To: <4E756819.50601@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mouf.net [204.109.58.86]); Sun, 18 Sep 2011 01:18:55 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.97.2 at mouf.net X-Virus-Status: Clean Cc: Subject: Re: 7.x gcc won't run 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, 18 Sep 2011 05:18:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please disregard this, it was a local issue that I resolved. I had tried to enable userland Dtrace (WITH_CTF), but mistakenly did it for 7.x and 8.x as well as 9.x. Sorry for the noise. Steve On 09/17/11 23:40, Steve Wills wrote: > Hi, > > Yesterday afternoon, I updated my -CURRENT host. Then I updated the > "jail"s (chroots) that my ports tinderbox uses. Now I've found that the > 7.x and 8.x ones can't run gcc as it reports: > > gcc: Internal error: Abort trap: 6 (program cc1) > > 9.x things work fine and other 7.x and 8.x binaries seem to run fine. > Anyone have any ideas? > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOdX82AAoJEPXPYrMgexuhkEAH/j/wd3Xlk1UrGf3i7IWpa6Vb 7+8JG+C4kE4WZzIhqD8QR4dXtzeqHlnc4XObI5wjUgDULHXMdl//E5WiHsKi+WI6 SqpMuy3dkn10WU2jQdB+d2BPldtrFerzKyxU+HXjBZyBv7JH2hJhblmr0HUpinD1 9QBgaL0f46QL/Th7E02Zg2wLx3EI+dk4FsFaRNkTVZOC7/m7DIEQe/fwVQnFU2ci 3S9vf5si3Dc7uIZSDdstCXFLOeZP8aEsc6pXvytpVQEFGYBFDQQzom1U4/ONFz8y BU/scyvdrH5Lh2FURfmCjH9PiO6p10neu+7KugaegOboR8w9VjSOAaJb4U8M+E0= =gmLL -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 07:52:07 2011 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 4D311106564A for ; Sun, 18 Sep 2011 07:52:07 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D18868FC0C for ; Sun, 18 Sep 2011 07:52:06 +0000 (UTC) Received: by fxg9 with SMTP id 9so4008331fxg.13 for ; Sun, 18 Sep 2011 00:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; bh=W4N1PGkd0dcTiCHr/ypTifDLpZAUeETGzy098OOJXJ0=; b=o1W8XUIFdtWkJq2uNpulcNwWPiqg/VMcJ00nTHXl6V9cgpHzUTZ4vRwO+27mK6qcLF G35g4SbxmOP1CVoph1ENrsIu/26Xt86vPa15Bl6nw8hzQ3hI6CHXyFtzkdBzDFV99SOW wTuyRT/fsmLDhCSiCQOF1yssYtkPRJnQZ42/A= Received: by 10.223.99.91 with SMTP id t27mr2699199fan.56.1316332325728; Sun, 18 Sep 2011 00:52:05 -0700 (PDT) Received: from ernst.jennejohn.org (p578E2168.dip.t-dialin.net. [87.142.33.104]) by mx.google.com with ESMTPS id v17sm4197695fai.18.2011.09.18.00.52.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Sep 2011 00:52:05 -0700 (PDT) Date: Sun, 18 Sep 2011 09:52:03 +0200 From: Gary Jennejohn To: freebsd-current@freebsd.org Message-ID: <20110918095203.06d7264f@ernst.jennejohn.org> In-Reply-To: References: <20110918042853.3D61C106566C@hub.freebsd.org> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: no X after installing xorg + xfce X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 07:52:07 -0000 On Sat, 17 Sep 2011 21:36:50 -0700 Garrett Cooper wrote: > On Sat, Sep 17, 2011 at 9:28 PM, <"Thomas Mueller > wrote: > >> I have successfully installed FreeBSD-9.0-BETA2 to an amd64 bit > >> machine, I have used the ports to install xfce and xorg.  When I type > >> startx, I get a screen with a bunch of colors no mouse, no keyboard, > >> just colors.  The machine has nvidia onboard graphics.  I am trying to > >> get kernel sources installed via sysinstall to install nvidia-driver > >> but I can't get anywhere from any ftp site I select at random.  I have > >> updated to latest sources available on the ports and it comes up the > >> same.  I have to use the nv driver, should I try the nouveau driver? > >> What should I do?  I want to help in testing and have no way to report > >> bugs as without X there's not much one can do :( > > > >> Is it not automatically installed when one goes into > >> /usr/ports/x11/xorg, and runs make install clean? > > > > You would get the xorg server with the xorg metaport/megaport. > > > > One thing I can think of is a little dirty trick I have seen in FreeBSD but not NetBSD or Linux, X comes up but no response to mouse or keyboard. > > > > I ran startx, got twm with its windows, but no response to mouse or keyboard. > > > > Cure was, to include in /etc/rc.conf > > > > > > hald_enable="YES" > > dbus_enable="YES" > > This seems like more of a question@ issue. > I doubt that the above claim is at fault, given past experience. > What does /var/log/Xorg.0.log say, and what does your xorg.conf > contain? > This may not be relevant, but I had a similar problem when I installed xorg-dev a few weeks ago. I'd forgotten to update the mouse and keyboard drivers and they apparently are not updated automatically. So try going into /usr/ports/x11-drivers and reinstalling xf86-input-mouse and xf86-input-keyboard. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 08:04:05 2011 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 80E7E1065670; Sun, 18 Sep 2011 08:04:05 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id BDB428FC0C; Sun, 18 Sep 2011 08:04:04 +0000 (UTC) Received: by iadk27 with SMTP id k27so6457841iad.13 for ; Sun, 18 Sep 2011 01:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=8FHbJLaWvgw602CEMZx8UEZ79emE9THzrpBD0w/C6BM=; b=NGX0UFr5SimDq6Bx99VO0lhsXnUezd/0U3fDPwhFPiY3N9f4rt/6K9k8smn86kax+r NdErXApZ7rJ2/L2f/yI+gCOV4LLQt6HGxwEsYJ9TMJlPPjKMYMJfBvmtot1AWWb799Q0 T7aqmu35OfRnydWW7309uJPEHhgvJ4e/LQ0ho= Received: by 10.231.65.73 with SMTP id h9mr1918731ibi.21.1316333044060; Sun, 18 Sep 2011 01:04:04 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.231.35.194 with HTTP; Sun, 18 Sep 2011 01:03:34 -0700 (PDT) In-Reply-To: <4E751428.7040609@a1poweruser.com> References: <4E71F647.2050007@a1poweruser.com> <4E7453CB.1040908@freebsd.org> <4E74C9B7.2090901@a1poweruser.com> <4E751428.7040609@a1poweruser.com> From: Chris Rees Date: Sun, 18 Sep 2011 09:03:34 +0100 X-Google-Sender-Auth: 23UAXJvriaXPx0Tvhos5fQ715x8 Message-ID: To: Fbsd8 Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, FreeBSD Questions Subject: Re: 9.0 bata2 & keymap 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, 18 Sep 2011 08:04:05 -0000 On 17 September 2011 22:42, Fbsd8 wrote: > Chris Rees wrote: >> >> On 17 Sep 2011 17:25, "Fbsd8" wrote: >>> >>> Nathan Whitehorn wrote: >>>>>>> >>>>>>> On 09/15/11 14:57, Fbsd8 wrote: >>>>>>> Out of the 9 USA maps only "us.iso.acc.kbd" worked somewhat. >>>>>>> The keyboard 9 key block above the arrow keys don't function. >>>>>>> Issuing the "man cmd_name" command doe's display the man page, >>>>>>> but the {Page up, Page down keys } don't work. >>>>>>> Also when using the "ee" edit command the {delete, Page up, Page down >>>>>>> keys } don't work. This does not happen in any of the previous >> >> releases. >>>>>>> >>>>>>> Further more, localization of the keyboard should not be forced on >>>>>>> the >>>>>>> user during the install process. This BSDinstall option should be >>>>>>> disabled or removed. >>>>>> >>>>>> You can press "Cancel" there, which will cancel keymap selection and >> >> keep the default. The utility being invoked is just kbdmap(1), and any >> changes to it need to go there. >>>>>> >>>>>> -Nathan >>>>> >>>>> >>>>> .. maybe name that button "skip" then? >>>>> >>>> The button is provided by kbdmap, as is the entire screen. We could add >>> >>> an "installer" mode to kbdmap that names it skip instead of cancel, of >>> course. I'm traveling for another 2 weeks and won't have time to do >>> >that, >> >> however. >>>> >>>> -Nathan >>>> >>> Nathan >>> >>> Its good to be talking directly with the bsdinstall author. >>> >>> Changing the cancel button in the kbdmap command to skip, does not >>> address >> >> the problem, which is the lack of knowledge of the standard bsdinstall >> user. >> I've been using Freebsd since 4.0 and never used the kbdmap command or for >> that matter even knew it existed. >> >> Wait, are you suggesting that everyone on Earth can "make do" with the >> "standard" keyboard layout until they learn rc.conf syntax? >> >> I would strongly object if localisation of the keyboard were not "forced >> on" >> the user; we don't all use pc105-us, and the ability to use the keyboard >> properly early on is kinda helpful. >> >> Chris >> >> > You would help yourself a great deal if you read the complete post before > jumping in. The rest of the post (ie: the part you neglected to include in > your post) clearly describes what I am suggesting. > I had read the rest of your post, and found it rather difficult to follow. The fact remains that every other installer I have ever used gives the user the choice of keymap, so I don't really understand your problem. If you're not suggesting removing localisation from bsdinstall, then please accept my apologies. Chris From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 09:04:29 2011 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 00C42106566B; Sun, 18 Sep 2011 09:04:28 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 532DD8FC0C; Sun, 18 Sep 2011 09:04:28 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:f803:edca:622b:8392]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 663FF4AC1C; Sun, 18 Sep 2011 13:04:26 +0400 (MSD) Date: Sun, 18 Sep 2011 13:04:14 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <8710192069.20110918130414@serebryakov.spb.ru> To: Chris Rees In-Reply-To: References: <4E71F647.2050007@a1poweruser.com> <4E7453CB.1040908@freebsd.org> <4E74C9B7.2090901@a1poweruser.com> <4E751428.7040609@a1poweruser.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Fbsd8 , FreeBSD Questions , freebsd-current@freebsd.org Subject: Re: 9.0 bata2 & keymap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 09:04:29 -0000 Hello, Chris. You wrote 18 =F1=E5=ED=F2=FF=E1=F0=FF 2011 =E3., 12:03:34: > I had read the rest of your post, and found it rather difficult to > follow. The fact remains that every other installer I have ever used > gives the user the choice of keymap, so I don't really understand your > problem. IMHO, main problem is, that in bsdinstall it is completely unclear how to have English keymap and other one and switch between them. For example, it is very natural to select "Russian" in Russia, but, nobody (ok, may be ALMOST nobody) in Russia want to enter Russian hostname, usernames and root password. And it is completely unobvious how to switch back to English after selecting Russian keymap. I think, other national keymaps have exactly same problem. And if Western-European ones allow to enter basic ASCII letters (and only add some diacritics, and, maybe, alert keys placement, like Z-A swap), and things like Dvorak allows it too (for sure!), but more specific national keymaps doesn't contain ASCII (Latin) letters at all. IMHO, selecting one and only one keymap without selecting at leas two of them and switching key have very limited use. It could be used to select variants of English maps (QWERTY vs Dvorak, different placement of additional characters, etc) and to select Latin-based maps with some extended characters. All other (Russian and other Cyrillic, Japan, Arabic, etc.,) need TWO keymaps right at installation time and configurable/known way to switch between them. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 09:16:25 2011 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 91B21106564A; Sun, 18 Sep 2011 09:16:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gw0-f50.google.com (mail-gw0-f50.google.com [74.125.83.50]) by mx1.freebsd.org (Postfix) with ESMTP id 176D58FC12; Sun, 18 Sep 2011 09:16:24 +0000 (UTC) Received: by gwj16 with SMTP id 16so5054395gwj.37 for ; Sun, 18 Sep 2011 02:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0Tk1LV+LR19EJDhVz9islaKrM+J2bwQ53rhUemSGtyk=; b=dOiw42xUC/ZDnsV2bPbsGTPrQUQPKazuDVKLUEKX41sEkEsJ4oXP33z4gQLlEPIrxD VZIU2tjUTjes3dmJOukLr2B9kt0qqs0ZH7ot0v4Fw+eAHA32AYCymzPTNh/p289iJbYl WxpsfrPV9YqjwrSCLt5BXEr19GqzFTOFqflPI= MIME-Version: 1.0 Received: by 10.236.129.165 with SMTP id h25mr606155yhi.38.1316337384236; Sun, 18 Sep 2011 02:16:24 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Sun, 18 Sep 2011 02:16:24 -0700 (PDT) In-Reply-To: <8710192069.20110918130414@serebryakov.spb.ru> References: <4E71F647.2050007@a1poweruser.com> <4E7453CB.1040908@freebsd.org> <4E74C9B7.2090901@a1poweruser.com> <4E751428.7040609@a1poweruser.com> <8710192069.20110918130414@serebryakov.spb.ru> Date: Sun, 18 Sep 2011 17:16:24 +0800 X-Google-Sender-Auth: Ys3RH7SlMTgh-FiEsb7qtUbXdVE Message-ID: From: Adrian Chadd To: lev@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Chris Rees , Fbsd8 , FreeBSD Questions , freebsd-current@freebsd.org Subject: Re: 9.0 bata2 & keymap 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, 18 Sep 2011 09:16:25 -0000 Hi all, Just keep in mind that Nathan is currently on holiday. Please don't be disenheartened if he doesn't reply or if bsdinstaller isn't 'fixed' until then. As always, patches == best. Adrian From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 09:55:26 2011 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 D866D1065670 for ; Sun, 18 Sep 2011 09:55:26 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost01.isp.att.net (fmailhost01.isp.att.net [204.127.217.101]) by mx1.freebsd.org (Postfix) with ESMTP id C75078FC13 for ; Sun, 18 Sep 2011 09:55:26 +0000 (UTC) Date: Sun, 18 Sep 2011 09:55:26 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-72-147-183-55.sdf.bellsouth.net[72.147.183.55]) by isp.att.net (frfwmhc01) with SMTP id <20110918095525H0100n3j1be>; Sun, 18 Sep 2011 09:55:25 +0000 X-Originating-IP: [72.147.183.55] From: "Thomas Mueller" Subject: Re: 9.0 beta2 & the new bsdinstaller 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, 18 Sep 2011 09:55:26 -0000 Some more ideas on the new bsdinstaller cross my mind. Since the way the bsdinstaller would make partitions is unpredictable, at least to the uninitiated, and in all likelihood at variance with how much space the user wants to allocate, it might be better to offer a roadmap to help guide the user to allocating space for FreeBSD using gpart or Rod Smith's gdisk. Also, I can't see the function of the 64 KB boot partition with no file system, which does not boot for me, though I can boot the main partition using grub2 from the System Rescue CD (http://sysresccd.org/). Another concern is updating to the next beta (BETA3?) without trashing the installed application software (from ports). So far, bsdinstaller hasn't offered any possibility of upgrading an existing installation. I don't think a user wants to rebuild all ports for every new beta or release candidate. Tom From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 10:11:24 2011 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 5EDE2106566B for ; Sun, 18 Sep 2011 10:11:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1BA108FC0C for ; Sun, 18 Sep 2011 10:11:23 +0000 (UTC) Received: by yxk36 with SMTP id 36so4488480yxk.13 for ; Sun, 18 Sep 2011 03:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=d/ynQLfqkeR3OsKkT3HyKiyhd7wAfNbcX4F1MqD2VH0=; b=eaM13FC7p2AF6+hVP6r0ZPY7gqMh4t/8CYqTGGNx8KcQHGHSmW3OzeEJPSO97dBUMd 9LJ4OIyVWrHGHQfEDlZ+1X65BzUXMFsGO9VY8YgHWUguj4kZDFQ/C1z4RhVLqJYf9PnD wPXzYOzEmWWei1PnuBqTLXuBjftAazer1UBfo= MIME-Version: 1.0 Received: by 10.236.185.195 with SMTP id u43mr7057484yhm.106.1316340683338; Sun, 18 Sep 2011 03:11:23 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Sun, 18 Sep 2011 03:11:23 -0700 (PDT) In-Reply-To: References: <20110908221356.Horde.MFEsZ6Qd9PdOaSIEaid2X_A@avocado.salatschuessel.net> <4E692F87.5010708@sentex.net> <20110909073305.Horde.oi-EGaQd9PdOaaURAsTRVJk@avocado.salatschuessel.net> <4E6A076D.7040309@wintek.com> Date: Sun, 18 Sep 2011 18:11:23 +0800 X-Google-Sender-Auth: ffVqWNs15DzU_F86y7yghpdp9e4 Message-ID: From: Adrian Chadd To: Alexander Zagrebin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current , lehmann@ans-netz.de Subject: Re: cvsup broken on 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: Sun, 18 Sep 2011 10:11:24 -0000 Hi, So I've taken a look at the csup source. The problem here is the updater thread setting the "closed" state (fixups_closed()) before calling updater_batch() again to handle fixups. Checking for size != 0 at that point may not be valid at the list size may actually be 0 for a short period of time. What about this patch: Index: updater.c =================================================================== --- updater.c (revision 224905) +++ updater.c (working copy) @@ -240,9 +240,9 @@ * Make sure to close the fixups even in case of an error, * so that the lister thread doesn't block indefinitely. */ - fixups_close(up->config->fixups); if (!error) error = updater_batch(up, 1); + fixups_close(up->config->fixups); switch (error) { case UPDATER_ERR_PROTO: xasprintf(&args->errmsg, "Updater failed: Protocol error"); Oliver, would you please try that? Thanks, Adrian From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 10:22:55 2011 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 3B613106564A for ; Sun, 18 Sep 2011 10:22:55 +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 7047B8FC08 for ; Sun, 18 Sep 2011 10:22:54 +0000 (UTC) Received: (qmail 27634 invoked by uid 80); 18 Sep 2011 10:22:53 -0000 Received: from dsdf-4db53ddf.pool.mediaWays.net (dsdf-4db53ddf.pool.mediaWays.net [77.181.61.223]) by avocado.salatschuessel.net (Horde Framework) with HTTP; Sun, 18 Sep 2011 12:22:53 +0200 Date: Sun, 18 Sep 2011 12:22:53 +0200 Message-ID: <20110918122253.Horde.tJj2ZaQd9PdOdcZ9N4nRVsI@avocado.salatschuessel.net> From: Oliver Lehmann To: Adrian Chadd References: <20110908221356.Horde.MFEsZ6Qd9PdOaSIEaid2X_A@avocado.salatschuessel.net> <4E692F87.5010708@sentex.net> <20110909073305.Horde.oi-EGaQd9PdOaaURAsTRVJk@avocado.salatschuessel.net> <4E6A076D.7040309@wintek.com> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H4 (5.0.11) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Cc: freebsd-current , Alexander Zagrebin Subject: Re: cvsup broken on 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: Sun, 18 Sep 2011 10:22:55 -0000 Adrian Chadd wrote: > So I've taken a look at the csup source. > > [...] > > What about this patch: > > [...] > > Oliver, would you please try that? I have a problem with cvsup, not csup - Alexander mentioned a csup problem. From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 10:27:57 2011 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 5AAD2106564A; Sun, 18 Sep 2011 10:27:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id C41748FC0C; Sun, 18 Sep 2011 10:27:56 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p8IARfuG027774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Sep 2011 13:27:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id p8IARfEV094119; Sun, 18 Sep 2011 13:27:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id p8IARfUi094118; Sun, 18 Sep 2011 13:27:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 18 Sep 2011 13:27:41 +0300 From: Kostik Belousov To: Oliver Lehmann Message-ID: <20110918102741.GV1511@deviant.kiev.zoral.com.ua> References: <20110908221356.Horde.MFEsZ6Qd9PdOaSIEaid2X_A@avocado.salatschuessel.net> <4E692F87.5010708@sentex.net> <20110909073305.Horde.oi-EGaQd9PdOaaURAsTRVJk@avocado.salatschuessel.net> <4E6A076D.7040309@wintek.com> <20110918122253.Horde.tJj2ZaQd9PdOdcZ9N4nRVsI@avocado.salatschuessel.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xi8lRpXYeGgNnUjs" Content-Disposition: inline In-Reply-To: <20110918122253.Horde.tJj2ZaQd9PdOdcZ9N4nRVsI@avocado.salatschuessel.net> 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Adrian Chadd , freebsd-current , Alexander Zagrebin Subject: Re: cvsup broken on 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: Sun, 18 Sep 2011 10:27:57 -0000 --xi8lRpXYeGgNnUjs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 18, 2011 at 12:22:53PM +0200, Oliver Lehmann wrote: >=20 > Adrian Chadd wrote: >=20 > >So I've taken a look at the csup source. > > > >[...] > > > >What about this patch: > > > >[...] > > > >Oliver, would you please try that? >=20 > I have a problem with cvsup, not csup - Alexander mentioned a csup proble= m. Did you saw the message with the patch for tzcode I mailed to you ? --xi8lRpXYeGgNnUjs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk51x50ACgkQC3+MBN1Mb4gd1wCgmF4m8zWIftUQqAq12G2p5TEc UYAAnjSgClHzo4GAeZbwrACr14KZqCPN =2in8 -----END PGP SIGNATURE----- --xi8lRpXYeGgNnUjs-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 10:33:08 2011 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 3D3DC106564A for ; Sun, 18 Sep 2011 10:33:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id F0E658FC08 for ; Sun, 18 Sep 2011 10:33:07 +0000 (UTC) Received: by gxk28 with SMTP id 28so4979523gxk.13 for ; Sun, 18 Sep 2011 03:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Wi51kOc6hE5MGjyzkadXjvQvWncM0FmkcQbcyjwTLUA=; b=s3d1shE60iu7XdxToAf+fcJXMONQF1/9KOqCDhEctho47CuixHXt3quMZTlkPs5Ci7 AaDY56nfZ8HuBuXFcvQ5AaMwltBNpWNkb96zcuOUzQq8gBzuBnre8GQHsdd4oJHfPv6W KlM8WxBO2LObqJzeYYuMkNmK0B+VY9eJJ/3dY= MIME-Version: 1.0 Received: by 10.236.176.65 with SMTP id a41mr7262225yhm.72.1316341987473; Sun, 18 Sep 2011 03:33:07 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Sun, 18 Sep 2011 03:33:07 -0700 (PDT) In-Reply-To: <4E6A076D.7040309@wintek.com> References: <20110908221356.Horde.MFEsZ6Qd9PdOaSIEaid2X_A@avocado.salatschuessel.net> <4E692F87.5010708@sentex.net> <20110909073305.Horde.oi-EGaQd9PdOaaURAsTRVJk@avocado.salatschuessel.net> <4E6A076D.7040309@wintek.com> Date: Sun, 18 Sep 2011 18:33:07 +0800 X-Google-Sender-Auth: O_-4jRiAjrMgSWDUq1nObmVUxCc Message-ID: From: Adrian Chadd To: rjk@wintek.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, alexz@visp.ru Subject: Re: cvsup broken on 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: Sun, 18 Sep 2011 10:33:08 -0000 Ah, you're the one with the csup problem. Would you mind trying csup again, and if it doesn't work, try this patch: Index: updater.c =================================================================== --- updater.c (revision 224905) +++ updater.c (working copy) @@ -240,9 +240,9 @@ * Make sure to close the fixups even in case of an error, * so that the lister thread doesn't block indefinitely. */ - fixups_close(up->config->fixups); if (!error) error = updater_batch(up, 1); + fixups_close(up->config->fixups); switch (error) { case UPDATER_ERR_PROTO: xasprintf(&args->errmsg, "Updater failed: Protocol error"); There's a PR open now (154954) but the patch may be wrong. thanks, Adrian From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 10:33:57 2011 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 29143106564A for ; Sun, 18 Sep 2011 10:33:57 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 047B18FC12 for ; Sun, 18 Sep 2011 10:33:56 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R5EhA-0001F5-1m for freebsd-current@freebsd.org; Sun, 18 Sep 2011 03:33:56 -0700 Date: Sun, 18 Sep 2011 03:33:56 -0700 (PDT) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1316342036012-4815764.post@n5.nabble.com> In-Reply-To: <86hb4asf58.wl%poyopoyo@puripuri.plala.or.jp> References: <86ipoqsk8a.wl%poyopoyo@puripuri.plala.or.jp> <86hb4asf58.wl%poyopoyo@puripuri.plala.or.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: bsdgrep: does anyone see this? 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, 18 Sep 2011 10:33:57 -0000 FreeBSD 9.0-BETA2 #0 r225641 amd64 $ echo |grep -q '^'; echo $? 0 $ echo |grep -qv '^'; echo $? 1 $ echo |bsdgrep -q '^'; echo $? 1 $ echo |bsdgrep -qv '^'; echo $? 0 -- View this message in context: http://freebsd.1045724.n5.nabble.com/bsdgrep-does-anyone-see-this-tp4815133p4815764.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 10:46:24 2011 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 56F94106566B for ; Sun, 18 Sep 2011 10:46:24 +0000 (UTC) (envelope-from pkubaj@gmail.com) Received: from mail-vw0-f45.google.com (mail-vw0-f45.google.com [209.85.212.45]) by mx1.freebsd.org (Postfix) with ESMTP id 126888FC08 for ; Sun, 18 Sep 2011 10:46:23 +0000 (UTC) Received: by vws17 with SMTP id 17so21385653vws.18 for ; Sun, 18 Sep 2011 03:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=evnPCb7SXKKDCp3mWvYZeo9mNC4t5Z7uxAfeisOoNw0=; b=vEl7h0sujhF6DIZ0OYDNraOUmqxW6zwvTsapyCZdaDro/OspqHBVjgMPa1/JsSpNfE sfUmBl5tkdFBAQOLorycDVH3yjHZdLACXo5rnWYHf8MnHhaJyOa0N34SCJPz74p3UBhD YnD+it6GSfJkJ5LpASuApYUMPxJLfes7Ivt6s= MIME-Version: 1.0 Received: by 10.52.89.104 with SMTP id bn8mr1049587vdb.285.1316342782557; Sun, 18 Sep 2011 03:46:22 -0700 (PDT) Received: by 10.52.165.5 with HTTP; Sun, 18 Sep 2011 03:46:22 -0700 (PDT) In-Reply-To: References: Date: Sun, 18 Sep 2011 12:46:22 +0200 Message-ID: From: Piotr Kubaj To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sun, 18 Sep 2011 11:42:31 +0000 Subject: Re: Kernel panic after an upgrade 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, 18 Sep 2011 10:46:24 -0000 I forgot to add. Following http://lists.freebsd.org/pipermail/freebsd-current/2011-September/027059.html I disabled vboxdrv and cuse4bsd modules. On Sun, Sep 18, 2011 at 12:44 PM, Piotr Kubaj wrote: > I upgraded on 16th September to the newest snapshot. Everything > compiled well, but after rebooting to the new system, hal couldn't > start. I tried to start it manually, however, there was a message that > libcam.so.5 couldn't be found. Seeing that this library is in the base > system, I recompiled hal and dbus. I rebooted and that's when kernel > panics started. > I've attached the core.txt file. > From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 10:44:44 2011 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 BE754106566C for ; Sun, 18 Sep 2011 10:44:44 +0000 (UTC) (envelope-from pkubaj@gmail.com) Received: from mail-vw0-f45.google.com (mail-vw0-f45.google.com [209.85.212.45]) by mx1.freebsd.org (Postfix) with ESMTP id 026798FC15 for ; Sun, 18 Sep 2011 10:44:43 +0000 (UTC) Received: by vws17 with SMTP id 17so21376537vws.18 for ; Sun, 18 Sep 2011 03:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=8L3YYTjQo/ma44PU5IPcOzb366fEy0hJHuhdtCH6o8U=; b=OMGYNJuoEeRe1i5BEd/ya5k69cLONo6nhuaOiVIIACsLDxJOC56xe1EnG25W0Z6Hi8 +yV1pw74WCjPU+cDJx7draS5ovWVhM7DGRbNQip70ivrZXyx0gHjlMBeqGKf7pwAS9Fb A867QuUliypC8QoRhuhqHAfsl8EBpzNreTKZI= MIME-Version: 1.0 Received: by 10.52.71.99 with SMTP id t3mr1101214vdu.17.1316342683149; Sun, 18 Sep 2011 03:44:43 -0700 (PDT) Received: by 10.52.165.5 with HTTP; Sun, 18 Sep 2011 03:44:43 -0700 (PDT) Date: Sun, 18 Sep 2011 12:44:43 +0200 Message-ID: From: Piotr Kubaj To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary=20cf307f375e08272604ad34ead8 X-Mailman-Approved-At: Sun, 18 Sep 2011 11:52:07 +0000 Subject: Kernel panic after an upgrade 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, 18 Sep 2011 10:44:44 -0000 --20cf307f375e08272604ad34ead8 Content-Type: text/plain; charset=UTF-8 I upgraded on 16th September to the newest snapshot. Everything compiled well, but after rebooting to the new system, hal couldn't start. I tried to start it manually, however, there was a message that libcam.so.5 couldn't be found. Seeing that this library is in the base system, I recompiled hal and dbus. I rebooted and that's when kernel panics started. I've attached the core.txt file. --20cf307f375e08272604ad34ead8 Content-Type: application/octet-stream; name="core.txt.4" Content-Disposition: attachment; filename="core.txt.4" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gspwfoyf0 YmVhc3RpZSBkdW1wZWQgY29yZSAtIHNlZSAvdmFyL2NyYXNoL3ZtY29yZS40CgpGcmkgU2VwIDE2 IDIyOjUwOjQxIENFU1QgMjAxMQoKRnJlZUJTRCBiZWFzdGllIDkuMC1CRVRBMiBGcmVlQlNEIDku MC1CRVRBMiAjNjogRnJpIFNlcCAxNiAwMDozNTo0MyBDRVNUIDIwMTEgICAgIHJvb3RAYmVhc3Rp ZTovdXNyL29iai91c3Ivc3JjL3N5cy9CRUFTVElFICBhbWQ2NAoKcGFuaWM6IHBhZ2UgZmF1bHQK CkdOVSBnZGIgNi4xLjEgW0ZyZWVCU0RdCkNvcHlyaWdodCAyMDA0IEZyZWUgU29mdHdhcmUgRm91 bmRhdGlvbiwgSW5jLgpHREIgaXMgZnJlZSBzb2Z0d2FyZSwgY292ZXJlZCBieSB0aGUgR05VIEdl bmVyYWwgUHVibGljIExpY2Vuc2UsIGFuZCB5b3UgYXJlCndlbGNvbWUgdG8gY2hhbmdlIGl0IGFu ZC9vciBkaXN0cmlidXRlIGNvcGllcyBvZiBpdCB1bmRlciBjZXJ0YWluIGNvbmRpdGlvbnMuClR5 cGUgInNob3cgY29weWluZyIgdG8gc2VlIHRoZSBjb25kaXRpb25zLgpUaGVyZSBpcyBhYnNvbHV0 ZWx5IG5vIHdhcnJhbnR5IGZvciBHREIuICBUeXBlICJzaG93IHdhcnJhbnR5IiBmb3IgZGV0YWls cy4KVGhpcyBHREIgd2FzIGNvbmZpZ3VyZWQgYXMgImFtZDY0LW1hcmNlbC1mcmVlYnNkIi4uLgoK VW5yZWFkIHBvcnRpb24gb2YgdGhlIGtlcm5lbCBtZXNzYWdlIGJ1ZmZlcjoKCgpGYXRhbCB0cmFw IDEyOiBwYWdlIGZhdWx0IHdoaWxlIGluIGtlcm5lbCBtb2RlCmNwdWlkID0gMDsgYXBpYyBpZCA9 IDAwCmZhdWx0IHZpcnR1YWwgYWRkcmVzcwk9IDB4OApmYXVsdCBjb2RlCQk9IHN1cGVydmlzb3Ig cmVhZCBkYXRhLCBwYWdlIG5vdCBwcmVzZW50Cmluc3RydWN0aW9uIHBvaW50ZXIJPSAweDIwOjB4 ZmZmZmZmZmY4MDNkZDU4NQpzdGFjayBwb2ludGVyCSAgICAgICAgPSAweDI4OjB4ZmZmZmZmODEx ZDUwZjZiMApmcmFtZSBwb2ludGVyCSAgICAgICAgPSAweDI4OjB4ZmZmZmZmODExZDUwZjZlMApj b2RlIHNlZ21lbnQJCT0gYmFzZSAweDAsIGxpbWl0IDB4ZmZmZmYsIHR5cGUgMHgxYgoJCQk9IERQ TCAwLCBwcmVzIDEsIGxvbmcgMSwgZGVmMzIgMCwgZ3JhbiAxCnByb2Nlc3NvciBlZmxhZ3MJPSBp bnRlcnJ1cHQgZW5hYmxlZCwgcmVzdW1lLCBJT1BMID0gMApjdXJyZW50IHByb2Nlc3MJCT0gMjEy OCAoaGFsZCkKdHJhcCBudW1iZXIJCT0gMTIKcGFuaWM6IHBhZ2UgZmF1bHQKY3B1aWQgPSAwClVw dGltZTogMW0yM3MKRHVtcGluZyAyMDM2IG91dCBvZiA0MDY3IE1COi4uMSUuLjExJS4uMjElLi4z MSUuLjQxJS4uNTElLi42MSUuLjcxJS4uODElLi45MSUKCk5vIHN5bWJvbCAiZHVtcHRpZCIgaW4g Y3VycmVudCBjb250ZXh0LgpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvemZzLmtv Li4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3QtbW91bnQvYm9vdC9rZXJuZWwvemZzLmtvLnN5 bWJvbHMuLi5kb25lLgpkb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL3pmcy5r bwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvb3BlbnNvbGFyaXMua28uLi5SZWFk aW5nIHN5bWJvbHMgZnJvbSAvYm9vdC1tb3VudC9ib290L2tlcm5lbC9vcGVuc29sYXJpcy5rby5z eW1ib2xzLi4uZG9uZS4KZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC9vcGVu c29sYXJpcy5rbwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9tb2R1bGVzL252aWRpYS5rby4u LmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9tb2R1bGVzL252aWRpYS5rbwpSZWFkaW5n IHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvZmRlc2Nmcy5rby4uLlJlYWRpbmcgc3ltYm9scyBm cm9tIC9ib290LW1vdW50L2Jvb3Qva2VybmVsL2ZkZXNjZnMua28uc3ltYm9scy4uLmRvbmUuCmRv bmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvZmRlc2Nmcy5rbwpSZWFkaW5nIHN5 bWJvbHMgZnJvbSAvYm9vdC9tb2R1bGVzL3Zib3huZXRmbHQua28uLi5kb25lLgpMb2FkZWQgc3lt Ym9scyBmb3IgL2Jvb3QvbW9kdWxlcy92Ym94bmV0Zmx0LmtvClJlYWRpbmcgc3ltYm9scyBmcm9t IC9ib290L21vZHVsZXMvdmJveGRydi5rby4uLmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9v dC9tb2R1bGVzL3Zib3hkcnYua28KUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL25l dGdyYXBoLmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3QtbW91bnQvYm9vdC9rZXJuZWwv bmV0Z3JhcGgua28uc3ltYm9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9v dC9rZXJuZWwvbmV0Z3JhcGgua28KUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL25n X2V0aGVyLmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3QtbW91bnQvYm9vdC9rZXJuZWwv bmdfZXRoZXIua28uc3ltYm9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9v dC9rZXJuZWwvbmdfZXRoZXIua28KUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3QvbW9kdWxlcy92 Ym94bmV0YWRwLmtvLi4uZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L21vZHVsZXMvdmJv eG5ldGFkcC5rbwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvdW1zLmtvLi4uUmVh ZGluZyBzeW1ib2xzIGZyb20gL2Jvb3QtbW91bnQvYm9vdC9rZXJuZWwvdW1zLmtvLnN5bWJvbHMu Li5kb25lLgpkb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL3Vtcy5rbwpSZWFk aW5nIHN5bWJvbHMgZnJvbSAvdXNyL2xvY2FsL21vZHVsZXMvZnVzZS5rby4uLmRvbmUuCkxvYWRl ZCBzeW1ib2xzIGZvciAvdXNyL2xvY2FsL21vZHVsZXMvZnVzZS5rbwojMCAgc2NoZWRfc3dpdGNo ICh0ZD1kd2FyZjJfcmVhZF9hZGRyZXNzOiBDb3JydXB0ZWQgRFdBUkYgZXhwcmVzc2lvbi4KKSBh dCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODU0CjE4NTQJCQljcHVpZCA9IFBDUFVf R0VUKGNwdWlkKTsKKGtnZGIpICMwICBzY2hlZF9zd2l0Y2ggKHRkPWR3YXJmMl9yZWFkX2FkZHJl c3M6IENvcnJ1cHRlZCBEV0FSRiBleHByZXNzaW9uLgopIGF0IC91c3Ivc3JjL3N5cy9rZXJuL3Nj aGVkX3VsZS5jOjE4NTQKIzEgIDB4ZmZmZmZmZmY4MDQ3NzRlNCBpbiBtaV9zd2l0Y2ggKGZsYWdz PWR3YXJmMl9yZWFkX2FkZHJlc3M6IENvcnJ1cHRlZCBEV0FSRiBleHByZXNzaW9uLgopCiAgICBh dCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3N5bmNoLmM6NDQ4CiMyICAweGZmZmZmZmZmODA0YWIw NWEgaW4gc2xlZXBxX3RpbWVkd2FpdCAod2NoYW49ZHdhcmYyX3JlYWRfYWRkcmVzczogQ29ycnVw dGVkIERXQVJGIGV4cHJlc3Npb24uCikKICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfc2xl ZXBxdWV1ZS5jOjY1MgojMyAgMHhmZmZmZmZmZjgwNDc3MDlmIGluIF9zbGVlcCAoaWRlbnQ9VmFy aWFibGUgImlkZW50IiBpcyBub3QgYXZhaWxhYmxlLgopCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vy bi9rZXJuX3N5bmNoLmM6MjMwCiM0ICAweGZmZmZmZmZmODA2MzE3MWEgaW4gc2NoZWR1bGVyIChk dW1teT1WYXJpYWJsZSAiZHVtbXkiIGlzIG5vdCBhdmFpbGFibGUuCikgYXQgL3Vzci9zcmMvc3lz L3ZtL3ZtX2dsdWUuYzo3OTMKIzUgIDB4ZmZmZmZmZmY4MDQyOTE2MyBpbiBtaV9zdGFydHVwICgp IGF0IC91c3Ivc3JjL3N5cy9rZXJuL2luaXRfbWFpbi5jOjI1OAojNiAgMHhmZmZmZmZmZjgwMjcx YmNjIGluIGJ0ZXh0ICgpCiM3ICAweGZmZmZmZTAwMDI4ZmU0NjAgaW4gPz8gKCkKIzggIDB4ZmZm ZmZmZmY4MGE4MDM3MCBpbiBib290dmVyYm9zZSAoKQojOSAgMHgwMDAwMDAwMDAwMDAwMDAwIGlu ID8/ICgpCiMxMCAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzExIDB4ZmZmZmZmZmY4MWRl N2JiMCBpbiA/PyAoKQojMTIgMHhmZmZmZmZmZjgxZGU3YjU4IGluID8/ICgpCiMxMyAweGZmZmZm ZmZmODBhODAzNzAgaW4gYm9vdHZlcmJvc2UgKCkKIzE0IDB4ZmZmZmZmZmY4MDQ5MTMyNSBpbiBz Y2hlZF9zd2l0Y2ggKHRkPWR3YXJmMl9yZWFkX2FkZHJlc3M6IENvcnJ1cHRlZCBEV0FSRiBleHBy ZXNzaW9uLgopCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODQ4CkN1cnJl bnQgbGFuZ3VhZ2U6ICBhdXRvOyBjdXJyZW50bHkgbWluaW1hbAooa2dkYikgCgotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KcHMgLWF4bAoKICBVSUQgICBQSUQgIFBQSUQgQ1BVIFBSSSBOSSAgICBWU1ogICAgUlNT IE1XQ0hBTiBTVEFUICBUVCAgICAgVElNRSBDT01NQU5ECiAgICAwICAgICAwICAgICAwICAgMCAg LTggIDAgICAgICAwICAgICAgMCAtICAgICAgRExzICAgPz8gIDA6MDEuNDYgW2tlcm5lbF0KICAg IDAgICAgIDEgICAgIDAgICAwICA1MiAgMCAgIDYyNzYgICAgICAwIHdhaXQgICBETHMgICA/PyAg MDowMC4wMyBbaW5pdF0KICAgIDAgICAgIDIgICAgIDAgICAwICAtOCAgMCAgICAgIDAgICAgICAw IHR4LT50eCBETCAgICA/PyAgMDowMC4xMSBbemZza2Vybl0KICAgIDAgICAgIDMgICAgIDAgICAw IC0xNiAgMCAgICAgIDAgICAgICAwIHBmdG0gICBETCAgICA/PyAgMDowMC4wMCBbcGZwdXJnZV0K ICAgIDAgICAgIDQgICAgIDAgICAwIC0xNiAgMCAgICAgIDAgICAgICAwIHdhaXRpbiBETCAgICA/ PyAgMDowMC4wMCBbc2N0cF9pdGVyYQogICAgMCAgICAgNSAgICAgMCAgIDAgLTE2ICAwICAgICAg MCAgICAgIDAgY2NiX3NjIERMICAgID8/ICAwOjAwLjAwIFt4cHRfdGhyZF0KICAgIDAgICAgIDYg ICAgIDAgICAwIC0xNiAgMCAgICAgIDAgICAgICAwIHBzbGVlcCBETCAgICA/PyAgMDowMC4wMCBb cGFnZWRhZW1vbgogICAgMCAgICAgNyAgICAgMCAgIDAgLTE2ICAwICAgICAgMCAgICAgIDAgcHNs ZWVwIERMICAgID8/ICAwOjAwLjAwIFt2bWRhZW1vbl0KICAgIDAgICAgIDggICAgIDAgICAwIDE1 NSAgMCAgICAgIDAgICAgICAwIHBnemVybyBETCAgICA/PyAgMDowMC4wMCBbcGFnZXplcm9dCiAg ICAwICAgICA5ICAgICAwICAgMCAtMTYgIDAgICAgICAwICAgICAgMCAtICAgICAgUkwgICAgPz8g IDA6MDAuMDAgW2J1ZmRhZW1vbl0KICAgIDAgICAgMTAgICAgIDAgICAwIC0xNiAgMCAgICAgIDAg ICAgICAwIGF1ZGl0XyBETCAgICA/PyAgMDowMC4wMCBbYXVkaXRdCiAgICAwICAgIDExICAgICAw ICAgMCAxNTUgIDAgICAgICAwICAgICAgMCAtICAgICAgUkwgICAgPz8gIDI6MjEuNTMgW2lkbGVd CiAgICAwICAgIDEyICAgICAwICAgMCAtNzIgIDAgICAgICAwICAgICAgMCAtICAgICAgV0wgICAg Pz8gIDA6MDAuNjAgW2ludHJdCiAgICAwICAgIDEzICAgICAwICAgMCAgLTggIDAgICAgICAwICAg ICAgMCAtICAgICAgREwgICAgPz8gIDA6MDAuNzkgW2dlb21dCiAgICAwICAgIDE0ICAgICAwICAg MCAtMTYgIDAgICAgICAwICAgICAgMCAtICAgICAgREwgICAgPz8gIDA6MDAuMDMgW3lhcnJvd10K ICAgIDAgICAgMTUgICAgIDAgICAwIC02OCAgMCAgICAgIDAgICAgICAwIC0gICAgICBETCAgICA/ PyAgMDowMC4wMyBbdXNiXQogICAgMCAgICAxNiAgICAgMCAgIDAgIDE2ICAwICAgICAgMCAgICAg IDAgLSAgICAgIFJMICAgID8/ICAwOjAwLjAyIFtzeW5jZXJdCiAgICAwICAgIDE3ICAgICAwICAg MCAtMTYgIDAgICAgICAwICAgICAgMCB2bHJ1d3QgREwgICAgPz8gIDA6MDAuMDAgW3ZubHJ1XQog ICAgMCAgICAxOCAgICAgMCAgIDAgLTE2ICAwICAgICAgMCAgICAgIDAgc2RmbHVzIERMICAgID8/ ICAwOjAwLjAwIFtzb2Z0ZGVwZmx1CiAgICAwICAgMTQwICAgICAwICAgMCAtMjAgIDAgICAgICAw ICAgICAgMCBJUFJUIFMgREwgICAgPz8gIDA6MDAuMDAgW1RJTUVSXQogICAgMCAgIDE0MSAgICAg MCAgIDAgLTE2ICAwICAgICAgMCAgICAgIDAgc2xlZXAgIERMICAgID8/ICAwOjAwLjAwIFtuZ19x dWV1ZV0KICAgIDAgIDEzMTkgICAgIDEgICAwICA1MiAgMCAgMTQzMTIgICAgICAwIHNlbGVjdCBE cyAgICA/PyAgMDowMC4wMCBbbW91c2VkXQogICAgMCAgMTMzNiAgICAgMSAgIDAgIDIwICAwICAx MDM3MiAgICAgIDAgc2VsZWN0IERzICAgID8/ICAwOjAwLjAwIFtkZXZkXQogICAgMCAgMTQ4NiAg ICAgMSAgIDAgIDUyICAwICAxMDAxNiAgICAgIDAgc2VsZWN0IERzICAgID8/ICAwOjAwLjAwIFtk aGNsaWVudF0KICAgNjUgIDE1MjQgICAgIDEgICAwICA1MiAgMCAgMTAwMTYgICAgICAwIHNlbGVj dCBEcyAgICA/PyAgMDowMC4wMCBbZGhjbGllbnRdCiAgICAwICAxNjUxICAgICAxICAgMCAgMjAg IDAgIDEyMjY4ICAgICAgMCBzZWxlY3QgRHMgICAgPz8gIDA6MDAuMDEgW3N5c2xvZ2RdCiAgICAw ICAxOTM4ICAgICAxICAgMCAgMjQgIDAgIDg2OTk2ICAgICAgMCAtICAgICAgUnMgICAgPz8gIDA6 MDAuMDAgW3NsaW1dCiAgICAwICAxOTUyICAxOTM4ICAgMCAgNDEgIDAgMTQwNDQwICAgICAgMCBz ZWxlY3QgRCAgICAgPz8gIDA6MDEuMzQgW1hvcmddCiAgNTU2ICAxOTUzICAgICAxICAgMCAgMjQg IDAgIDE0NTQwICAgICAgMCBzZWxlY3QgRHMgICAgPz8gIDA6MDAuMDAgW2RidXMtZGFlbW8KICAg IDAgIDE5NjAgICAgIDEgICAwICA1MiAgMCAgODQ5MzYgICAgICAwIHNlbGVjdCBEICAgICA/PyAg MDowMC4wMSBbaGFsZF0KICAgIDAgIDE5ODEgICAgIDEgICAwICAyOSAgMCAgMzQ0NDQgICAgICAw IG5hbnNscCBEcyAgICA/PyAgMDowMC4wMSBbcGVybF0KICAgIDAgIDE5OTUgICAgIDEgICAwICA1 MiAgMCAgNDY5MzIgICAgICAwIG5hbnNscCBEcyAgICA/PyAgMDowMC4wMCBbcGVybDUuMTQuMQog ICAgMCAgMjAyNSAgICAgMSAgIDAgIDUyICAwICA0Njg5MiAgICAgIDAgc2VsZWN0IERzICAgID8/ ICAwOjAwLjAwIFtzc2hkXQogICAgMCAgMjAzMiAgICAgMSAgIDAgIDUyICAwICAyMDQyNCAgICAg IDAgc2VsZWN0IERzICAgID8/ICAwOjAwLjAwIFtzZW5kbWFpbF0KICAgMjUgIDIwMzkgICAgIDEg ICAwICA1MiAgMCAgMjA0MjQgICAgICAwIHBhdXNlICBEcyAgICA/PyAgMDowMC4wMCBbc2VuZG1h aWxdCiAgICAwICAyMDQ5ICAgICAxICAgMCAgNTIgIDAgIDE0MjI0ICAgICAgMCBuYW5zbHAgRHMg ICAgPz8gIDA6MDAuMDAgW2Nyb25dCiAgICAwICAyMTExICAgICAxICAgMCAgNTIgIDAgIDE0NTky ICAgICAgMCB3YWl0ICAgRCAgICAgPz8gIDA6MDAuMDAgW3NoXQogICAgMCAgMjExMiAgICAgMSAg IDAgIDUyICAwICAxMDAxNiAgICAgIDAgcGlwZXJkIEQgICAgID8/ICAwOjAwLjAwIFtsb2dnZXJd CiAgICAwICAyMTEzICAyMTExICAgMCAgNTIgIDAgICAzODgwICAgICAgMCBuYW5zbHAgRCAgICAg Pz8gIDA6MDAuMDAgW3NsZWVwXQogICAgMCAgMjExNiAgICAgMSAgIDAgIDUyICAwICAxMjE0NCAg ICAgIDAgdHR5aW4gIERzKyAgID8/ICAwOjAwLjAwIFtnZXR0eV0KICAgIDAgIDIxMTcgICAgIDEg ICAwICA1MiAgMCAgMTIxNDQgICAgICAwIHR0eWluICBEcysgICA/PyAgMDowMC4wMCBbZ2V0dHld CiAgICAwICAyMTE4ICAgICAxICAgMCAgNTIgIDAgIDEyMTQ0ICAgICAgMCB0dHlpbiAgRHMrICAg Pz8gIDA6MDAuMDAgW2dldHR5XQogICAgMCAgMjExOSAgICAgMSAgIDAgIDUyICAwICAxMjE0NCAg ICAgIDAgdHR5aW4gIERzKyAgID8/ICAwOjAwLjAwIFtnZXR0eV0KICAgIDAgIDIxMjAgICAgIDEg ICAwICA1MiAgMCAgMTIxNDQgICAgICAwIHR0eWluICBEcysgICA/PyAgMDowMC4wMCBbZ2V0dHld CiAgICAwICAyMTIxICAgICAxICAgMCAgNTIgIDAgIDEyMTQ0ICAgICAgMCB0dHlpbiAgRHMrICAg Pz8gIDA6MDAuMDAgW2dldHR5XQogICAgMCAgMjEyMiAgICAgMSAgIDAgIDUyICAwICAxMjE0NCAg ICAgIDAgdHR5aW4gIERzKyAgID8/ICAwOjAwLjAwIFtnZXR0eV0KICAgIDAgIDIxMjMgICAgIDEg ICAwICA1MiAgMCAgMTIxNDQgICAgICAwIHR0eWluICBEcysgICA/PyAgMDowMC4wMCBbZ2V0dHld CiAgICAwICAyMTI4ICAxOTYwICAgMCAgMzQgIDAgIDg1MDY4ICAgICAgMCBwaXBlcmQgRHMgICAg Pz8gIDA6MDAuMDAgW2hhbGRdCiAgICAwICAyMTMwICAgICAxICAgMCAgMjIgIDAgIDkxOTg0ICAg ICAgMCBuICAgICAgRCAgICAgPz8gIDA6MDAuMDAgW2NvbnNvbGUta2kKICAgIDAgIDIxMzMgICAg IDEgICAwICAyNiAgMCAgODg5ODQgICAgICAwIHNlbGVjdCBEICAgICA/PyAgMDowMC4wMCBbcG9s a2l0ZF0KICAgIDAgIDIxMzUgICAgIDEgICAwICAyNCAgMCAgNTc4MjAgICAgICAwIC0gICAgICBS ICAgICA/PyAgMDowMC4wMCBbZ2FtX3NlcnZlcgogICAgMCAgMjEzNiAgMjEyOCAgIDAgIDM1ICAw ICA3NDIyNCAgICAgIDAgc2VsZWN0IEQgICAgID8/ICAwOjAwLjAwIFtoYWxkLXJ1bm5lCgotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0Kdm1zdGF0IC1zCgogICA5NTIwMjUgY3B1IGNvbnRleHQgc3dpdGNoZXMKICAg MTA0NTM1IGRldmljZSBpbnRlcnJ1cHRzCiAgICAzNzczMiBzb2Z0d2FyZSBpbnRlcnJ1cHRzCiAg IDQxNzg2NSB0cmFwcwogICA0MjYyMDQgc3lzdGVtIGNhbGxzCiAgICAgICAyMCBrZXJuZWwgdGhy ZWFkcyBjcmVhdGVkCiAgICAgMjExMSAgZm9yaygpIGNhbGxzCiAgICAgICAgNSB2Zm9yaygpIGNh bGxzCiAgICAgICAgMCByZm9yaygpIGNhbGxzCiAgICAgICAgMCBzd2FwIHBhZ2VyIHBhZ2VpbnMK ICAgICAgICAwIHN3YXAgcGFnZXIgcGFnZXMgcGFnZWQgaW4KICAgICAgICAwIHN3YXAgcGFnZXIg cGFnZW91dHMKICAgICAgICAwIHN3YXAgcGFnZXIgcGFnZXMgcGFnZWQgb3V0CiAgICAgOTUwMyB2 bm9kZSBwYWdlciBwYWdlaW5zCiAgICAgOTUwMyB2bm9kZSBwYWdlciBwYWdlcyBwYWdlZCBpbgog ICAgICAgIDAgdm5vZGUgcGFnZXIgcGFnZW91dHMKICAgICAgICAwIHZub2RlIHBhZ2VyIHBhZ2Vz IHBhZ2VkIG91dAogICAgICAgIDAgcGFnZSBkYWVtb24gd2FrZXVwcwogICAgICAgIDAgcGFnZXMg ZXhhbWluZWQgYnkgdGhlIHBhZ2UgZGFlbW9uCiAgICAgNDA0MCBwYWdlcyByZWFjdGl2YXRlZAog ICAgNjkxMjggY29weS1vbi13cml0ZSBmYXVsdHMKICAgICAgMzgxIGNvcHktb24td3JpdGUgb3B0 aW1pemVkIGZhdWx0cwogICAyNzcxMTggemVybyBmaWxsIHBhZ2VzIHplcm9lZAogICAgICAgIDAg emVybyBmaWxsIHBhZ2VzIHByZXplcm9lZAogICAgICAgIDcgaW50cmFuc2l0IGJsb2NraW5nIHBh Z2UgZmF1bHRzCiAgIDQyOTI2MyB0b3RhbCBWTSBmYXVsdHMgdGFrZW4KICAgICAgICAwIHBhZ2Vz IGFmZmVjdGVkIGJ5IGtlcm5lbCB0aHJlYWQgY3JlYXRpb24KICAxMDc3NTU4IHBhZ2VzIGFmZmVj dGVkIGJ5ICBmb3JrKCkKICAgICAyNjAwIHBhZ2VzIGFmZmVjdGVkIGJ5IHZmb3JrKCkKICAgICAg ICAwIHBhZ2VzIGFmZmVjdGVkIGJ5IHJmb3JrKCkKICAgICAgICAwIHBhZ2VzIGNhY2hlZAogICA4 MTkyMjcgcGFnZXMgZnJlZWQKICAgICAgICAwIHBhZ2VzIGZyZWVkIGJ5IGRhZW1vbgogICAgICAg IDAgcGFnZXMgZnJlZWQgYnkgZXhpdGluZyBwcm9jZXNzZXMKICAgIDE3MDg4IHBhZ2VzIGFjdGl2 ZQogICAgIDM4NzMgcGFnZXMgaW5hY3RpdmUKICAgICAxNDE0IHBhZ2VzIGluIFZNIGNhY2hlCiAg IDQ3ODEyOCBwYWdlcyB3aXJlZCBkb3duCiAgIDUwMzg5MSBwYWdlcyBmcmVlCiAgICAgNDA5NiBi eXRlcyBwZXIgcGFnZQogICAgNTEzMzYgdG90YWwgbmFtZSBsb29rdXBzCiAgICAgICAgICBjYWNo ZSBoaXRzICg4NSUgcG9zICsgNiUgbmVnKSBzeXN0ZW0gMCUgcGVyLWRpcmVjdG9yeQogICAgICAg ICAgZGVsZXRpb25zIDAlLCBmYWxzZWhpdHMgMCUsIHRvb2xvbmcgMCUKCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQp2bXN0YXQgLW0KCiAgICAgICAgIFR5cGUgSW5Vc2UgTWVtVXNlIEhpZ2hVc2UgUmVxdWVzdHMg IFNpemUocykKICAgICAgICBjYWNoZSAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMzIK ICAgICAgIGRldmJ1ZiAyMDk3NiA0OTkyN0sgICAgICAgLSAgICAyMTQ0NyAgMTYsMzIsNjQsMTI4 LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgICAgdGVtcCAgIDE2MCAgICAxN0sgICAgICAg LSAgICAgODEyMSAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgICAg aGRhYyAgICAgNyAgICAyNksgICAgICAgLSAgICAgICAgNyAgNjQsMTI4LDUxMiwxMDI0LDQwOTYK ICAgICAgICAgIFVTQiAgICA3NSAgIDExNEsgICAgICAgLSAgICAgICA3OCAgMTYsMzIsNjQsMTI4 LDI1Niw1MTIsMjA0OCw0MDk2CiAgICAgICBtb2R1bGUgICAyNTAgICAgMzJLICAgICAgIC0gICAg ICAyNTAgIDEyOAogICAgIG10eF9wb29sICAgICAyICAgIDE2SyAgICAgICAtICAgICAgICAyICAK ICAgICAgIFVTQmRldiAgICA0OSAgICAxN0sgICAgICAgLSAgICAgICA1MCAgNjQsMTI4LDUxMiwx MDI0LDQwOTYKICAgICAgICAgIG9zZCAgICAgNCAgICAgMUsgICAgICAgLSAgICAgICAgOCAgMTYs NjQsMTI4CiAgICBDQU0gcXVldWUgICAgMzAgICAgIDFLICAgICAgIC0gICAgICAxNzcgIDE2LDMy LDI1NgogICAgICAgICBwZ3JwICAgIDI2ICAgICA0SyAgICAgICAtICAgICAgIDI5ICAxMjgKICAg ICAgc2Vzc2lvbiAgICAyNSAgICAgNEsgICAgICAgLSAgICAgICAyNyAgMTI4CiAgICAgICAgIHBy b2MgICAgIDIgICAgMTZLICAgICAgIC0gICAgICAgIDIgIAogICAgICBzdWJwcm9jICAgMTI1ICAg MjQ1SyAgICAgICAtICAgICAyMjEwICA1MTIsNDA5NgogICAgICAgICBjcmVkICAgIDQ0ICAgICA3 SyAgICAgICAtICAgICA3OTEyICA2NCwyNTYKICAgICAgIHBsaW1pdCAgICAxMiAgICAgM0sgICAg ICAgLSAgICAgIDEzNCAgMjU2CiAgICAgIHVpZGluZm8gICAgIDUgICAgIDNLICAgICAgIC0gICAg ICAgIDUgIDEyOCwyMDQ4CiAgICAgIHNjc2lfY2QgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAg IDggIDE2CiAgICAgICBzeXNjdGwgICAgIDAgICAgIDBLICAgICAgIC0gICAgICA4MjYgIDE2LDMy LDY0CiAgICBzeXNjdGxvaWQgIDQ2NzQgICAyMzFLICAgICAgIC0gICAgIDQ3ODAgIDE2LDMyLDY0 LDEyOAogICAgc3lzY3RsdG1wICAgICAwICAgICAwSyAgICAgICAtICAgICAgMzk2ICAxNiwzMiw2 NCwxMjgsMjA0OAogICAgICB0aWRoYXNoICAgICAxICAgIDE2SyAgICAgICAtICAgICAgICAxICAK ICAgICAgY2FsbG91dCAgICAgMSAgIDUxMksgICAgICAgLSAgICAgICAgMSAgCiAgICAgICAgIHVt dHggICA2MzYgICAgODBLICAgICAgIC0gICAgICA2MzYgIDEyOAogICAgIHAxMDAzLjFiICAgICAx ICAgICAxSyAgICAgICAtICAgICAgICAxICAxNgogICAgICAgICBTV0FQICAgICAyICAyMTg5SyAg ICAgICAtICAgICAgICAyICA2NAogICAgICAgICAgYnVzICAgNzk1ICAgIDcxSyAgICAgICAtICAg ICAzNDIxICAxNiwzMiw2NCwxMjgsMjU2LDEwMjQKICAgICAgIGJ1cy1zYyAgICA4MSAgIDQwOEsg ICAgICAgLSAgICAgMTE2OSAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAg ICAgZGV2c3RhdCAgICAgOCAgICAxN0sgICAgICAgLSAgICAgICAgOCAgMzIsNDA5NgogZXZlbnRo YW5kbGVyICAgIDc5ICAgICA3SyAgICAgICAtICAgICAgIDc5ICA2NCwxMjgKICAgICAgICAga29i aiAgIDE3MiAgIDY4OEsgICAgICAgLSAgICAgIDE5MyAgNDA5NgogICAgICBQZXItY3B1ICAgICAx ICAgICAxSyAgICAgICAtICAgICAgICAxICAzMgpDQU0gZGV2IHF1ZXVlICAgICA4ICAgICAxSyAg ICAgICAtICAgICAgICA4ICAxMjgKICAgICAgIGZlZWRlciAgICAyNSAgICAgM0sgICAgICAgLSAg ICAgICAzMiAgMzIsMTI4CiAgICAgICBrYmRtdXggICAgIDYgICAgMThLICAgICAgIC0gICAgICAg IDYgIDE2LDUxMiwxMDI0LDIwNDgKICAgICAgICAgIExFRCAgICAyNCAgICAgMksgICAgICAgLSAg ICAgICAyNCAgMTYsMTI4CiAgICAgICAgIHJtYW4gICAyMzkgICAgMjhLICAgICAgIC0gICAgICA0 NTUgIDE2LDMyLDEyOAogICAgICAgICBzYnVmICAgICAxICAgICA0SyAgICAgICAtICAgICAgODQx ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICAgc2dsaXN0ICAgIDEx ICAgICA0SyAgICAgICAtICAgICAgIDEyICAzMiw1MTIsMjA0OAogICAgICAgREVWRlMzICAgMTU4 ICAgIDQwSyAgICAgICAtICAgICAgMTYzICAyNTYKICAgICAgICBzdGFjayAgICAgMCAgICAgMEsg ICAgICAgLSAgICAgICAgMiAgMjU2CiAgICB0YXNrcXVldWUgICAgNTcgICAgIDZLICAgICAgIC0g ICAgICAgODcgIDE2LDMyLDY0LDEyOCwxMDI0CiAgICAgICBVbml0bm8gICAgMTIgICAgIDFLICAg ICAgIC0gICAgICAgMTggIDMyLDY0CiAgICAgaW9jdGxvcHMgICAgIDAgICAgIDBLICAgICAgIC0g ICAgIDIwNzUgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OAogICAgICAgc2VsZWN0ICAg IDI4ICAgICA0SyAgICAgICAtICAgICAgIDI4ICAxMjgKICAgICAgICAgIGlvdiAgICAgMCAgICAg MEsgICAgICAgLSAgICAgIDYwMiAgMTYsMzIsNjQsMTI4LDI1Niw1MTIKICAgICAgICAgIG1zZyAg ICAgNCAgICAzMEsgICAgICAgLSAgICAgICAgNCAgMjA0OCw0MDk2CiAgICAgICAgICBzZW0gICAg IDQgICAxMDZLICAgICAgIC0gICAgICAgIDQgIDIwNDgsNDA5NgogICAgICAgICAgc2htICAgICAx ICAgIDIwSyAgICAgICAtICAgICAgICAxICAKICAgICAgICAgIHR0eSAgICAxOCAgICAxOEsgICAg ICAgLSAgICAgICAyMCAgMTAyNCwyMDQ4CiAgICAgbWJ1Zl90YWcgICAgIDAgICAgIDBLICAgICAg IC0gICAgICAgMTEgIDMyCiAgICAgICAgIGtzZW0gICAgIDEgICAgIDhLICAgICAgIC0gICAgICAg IDEgIAogICAgICAgIHNobWZkICAgICAxICAgICA4SyAgICAgICAtICAgICAgICAxICAKICAgICAg IHNvbmFtZSAgICAxOCAgICAgMksgICAgICAgLSAgICAgIDI5MCAgMTYsMzIsNjQsMTI4CiAgICAg ICAgICBwY2IgICAgMTcgICAxNTdLICAgICAgIC0gICAgICAgMjggIDE2LDMyLDEyOCwxMDI0LDIw NDgsNDA5NgogICAgICAgREVWRlMxICAgMTM4ICAgIDY5SyAgICAgICAtICAgICAgMTM5ICA1MTIK ICAgICB2ZnNjYWNoZSAgICAgMSAgMjA0OEsgICAgICAgLSAgICAgICAgMSAgCiAgICAgdmZzX2hh c2ggICAgIDEgIDEwMjRLICAgICAgIC0gICAgICAgIDEgIAogICAgICAgdm5vZGVzICAgICAyICAg ICAxSyAgICAgICAtICAgICAgICAyICAyNTYKICAgREVWRlNfUlVMRSAgICA2MCAgICAyOEsgICAg ICAgLSAgICAgICA2MCAgNjQsNTEyCiAgICAgICAgbW91bnQgICAgOTggICAgIDVLICAgICAgIC0g ICAgICAxODkgIDE2LDMyLDY0LDEyOCwyNTYKICB2bm9kZW1hcmtlciAgICAgMSAgICAgMUsgICAg ICAgLSAgIDQwMDk1NyAgNTEyCiAgICAgICAgICBCUEYgICAgMTkgICAgMTFLICAgICAgIC0gICAg ICAgMTkgIDEyOCw1MTIsNDA5NgogICAgICAgIERFVkZTICAgIDI3ICAgICAxSyAgICAgICAtICAg ICAgIDI4ICAxNiwzMiwxMjgKICAgICAgICBpZm5ldCAgICAxNSAgICAyOUsgICAgICAgLSAgICAg ICAxNSAgMTI4LDIwNDgKICAgICAgIGlmYWRkciAgICA2MyAgICAyMEsgICAgICAgLSAgICAgICA2 NCAgMzIsMjU2LDUxMiwyMDQ4LDQwOTYKICBldGhlcl9tdWx0aSAgICAgNyAgICAgMUsgICAgICAg LSAgICAgICAxNCAgMTYsNjQKICAgICAgICBjbG9uZSAgICAgNCAgICAxNksgICAgICAgLSAgICAg ICAgNCAgNDA5NgogICAgICAgYXJwY29tICAgICAzICAgICAxSyAgICAgICAtICAgICAgICAzICAx NgogICAgICBsbHRhYmxlICAgIDE2ICAgICA4SyAgICAgICAtICAgICAgIDE2ICAyNTYsNTEyCiAg ICAgICBERVZGU1AgICAgMTcgICAgIDJLICAgICAgIC0gICAgICAgMTggIDY0CiAgICBwZnNfbm9k ZXMgICAxNzAgICAgNDNLICAgICAgIC0gICAgICAxNzAgIDI1NgogIHBmc192bmNhY2hlICAgIDEx ICAgICAxSyAgICAgICAtICAgICAgIDE1ICA2NAogICAgIHJvdXRldGJsICAgIDEyICAgICAzSyAg ICAgICAtICAgICAgMTA0ICAzMiw2NCwxMjgsMjU2LDUxMgogICAgICAgICBpZ21wICAgIDE0ICAg ICA0SyAgICAgICAtICAgICAgIDE0ICAyNTYKICAgICBpbl9tdWx0aSAgICAgMiAgICAgMUsgICAg ICAgLSAgICAgICAgMyAgMjU2CiAgICAgICAgIEdFT00gICAxMDggICAgMjdLICAgICAgIC0gICAg ICA0MTMgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OAogICAgc2N0cF9hX2l0ICAgICAw ICAgICAwSyAgICAgICAtICAgICAgICAxICAxNgogICAgIHNjdHBfdnJmICAgICAxICAgICAxSyAg ICAgICAtICAgICAgICAxICA2NAogICAgIHNjdHBfaWZhICAgICAyICAgICAxSyAgICAgICAtICAg ICAgICAyICAxMjgKICAgICBzY3RwX2lmbiAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAg MTI4CiAgICBzY3RwX2l0ZXIgICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDEgIDI1NgogICAg aG9zdGNhY2hlICAgICAxICAgIDI4SyAgICAgICAtICAgICAgICAxICAKICAgICBzeW5jYWNoZSAg ICAgMSAgICA5NksgICAgICAgLSAgICAgICAgMSAgCmF1ZGl0X2V2Y2xhc3MgICAxNzkgICAgIDZL ICAgICAgIC0gICAgICAyMTggIDMyCiAgICAgIHBhZ2VkZXAgICAgIDEgICAxMjhLICAgICAgIC0g ICAgICAgIDEgIAogICAgIGlub2RlZGVwICAgICAxICAxMDI0SyAgICAgICAtICAgICAgICAxICAK ICAgIGJtc2FmZW1hcCAgICAgMSAgICAgOEsgICAgICAgLSAgICAgICAgMSAgCiAgICAgICBuZXdi bGsgICAgIDEgICAxMjhLICAgICAgIC0gICAgICAgIDEgIAogICAgIGZyZWV3b3JrICAgICAxICAg ICAxSyAgICAgICAtICAgICAgICAxICAxNgogIHVmc19kaXJoYXNoICAgICA5ICAgICAzSyAgICAg ICAtICAgICAgICA5ICAxMjgsNTEyCiAgICB1ZnNfbW91bnQgICAgIDMgICAgMTNLICAgICAgIC0g ICAgICAgIDMgIDUxMiw0MDk2CiAgICB2bV9wZ2RhdGEgICAgIDIgICAxMjlLICAgICAgIC0gICAg ICAgIDIgIDEyOAogICAgICAgIG1peGVyICAgICA1ICAgIDIwSyAgICAgICAtICAgICAgICA1ICA0 MDk2CiAgICAgYWNwaWludHIgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDY0CiAgICAg ICBhY3BpY2EgIDM3OTcgICAzOTVLICAgICAgIC0gICAgNDkxNjQgIDE2LDMyLDY0LDEyOCwyNTYs NTEyLDEwMjQsMjA0OAogICAgIHBjaV9saW5rICAgIDE2ICAgICAySyAgICAgICAtICAgICAgIDE2 ICA2NCwxMjgKICAgIGFjcGlfcGVyZiAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgNjQK ICAgICAgbWVtZGVzYyAgICAgMSAgICAgNEsgICAgICAgLSAgICAgICAgMiAgNDA5NgogICAgICAg aXNhZGV2ICAgICA2ICAgICAxSyAgICAgICAtICAgICAgICA2ICAxMjgKICAgICBhdGtiZGRldiAg ICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgNjQKICAgICAgQ0FNIFNJTSAgICAgOCAgICAg MksgICAgICAgLSAgICAgICAgOCAgMjU2CiAgICAgICAgIFVBUlQgICAgIDMgICAgIDJLICAgICAg IC0gICAgICAgIDMgIDE2LDUxMiwxMDI0CiAgICAgIENBTSBYUFQgICAgODIgICAgNzJLICAgICAg IC0gICAgICAyMzQgIDMyLDY0LDEyOCwxMDI0LDIwNDgKICAgICAgICAgY2RldiAgICAgNyAgICAg MksgICAgICAgLSAgICAgICAgNyAgMjU2CiAgICAgYWNwaXRhc2sgICAgIDEgICAgIDJLICAgICAg IC0gICAgICAgIDEgIDIwNDgKICAgICBmaWxlZGVzYyAgICA1NCAgICAyOEsgICAgICAgLSAgICAg MjE0MCAgNTEyLDEwMjQKICAgICAgICBsaW51eCAgICAxNiAgICAgMUsgICAgICAgLSAgICAgICAx NiAgNjQKICAgICAgICBzaWdpbyAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgNjQKICAg ICAgICAga2VudiAgIDExMSAgICAxM0sgICAgICAgLSAgICAgIDEyMiAgMTYsMzIsNjQsMTI4CiAg ICAgICBhcG1kZXYgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDEyOAogICAgICAga3F1 ZXVlICAgICA3ICAgICA2SyAgICAgICAtICAgICAgIDE3ICAyNTYsNTEyLDIwNDgKICAgIHByb2Mt YXJncyAgICAzMSAgICAgMksgICAgICAgLSAgICAgIDc0MyAgMTYsMzIsNjQsMTI4LDI1NgogICAg ICBhY3Bpc2VtICAgIDIxICAgICAzSyAgICAgICAtICAgICAgIDIxICAxMjgKICAgICAgICBoaG9v ayAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgMTI4CiAgICAgIGl0aHJlYWQgICAgODUg ICAgMTRLICAgICAgIC0gICAgICAgODUgIDMyLDEyOCwyNTYKICAgQ0FNIHBlcmlwaCAgICAgOCAg ICAgMksgICAgICAgLSAgICAgICAzMCAgMTYsMzIsNjQsMTI4LDI1NgogICAgICBpb19hcGljICAg ICAxICAgICAySyAgICAgICAtICAgICAgICAxICAyMDQ4CiAgICAgICBLVFJBQ0UgICAxMDAgICAg MTNLICAgICAgIC0gICAgICAxMDAgIDEyOAogICAgICBlbnRyb3B5ICAxMDI0ICAgIDY0SyAgICAg ICAtICAgICAxMDI0ICA2NAogICAgICAgICAgbXNpICAgICAzICAgICAxSyAgICAgICAtICAgICAg ICAzICAxMjgKICAgICBuZXh1c2RldiAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgMyAgMTYK ICAgICAgIGxpbmtlciAgIDIzMyAgIDMyN0sgICAgICAgLSAgICAgIDMwNSAgMTYsMzIsNjQsMTI4 LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgYWNwaWRldiAgICAzNiAgICAgM0sgICAgICAg LSAgICAgICAzNiAgNjQKICAgICAgICBsb2NrZiAgICAyMCAgICAgM0sgICAgICAgLSAgICAgICAz MiAgNjQsMTI4CiAgIGxvZ2luY2xhc3MgICAgIDEgICAgIDFLICAgICAgIC0gICAgICAgIDEgIDY0 CiAgICAgIHNvbGFyaXMgNDExNzQgMTczMzgyNksgICAgICAgLSAgIDU2MzIxNyAgMTYsMzIsNjQs MTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAga3N0YXRfZGF0YSAgICAgNCAgICAgMUsgICAg ICAgLSAgICAgICAgNCAgNjQKICAgICAgIG52aWRpYSAgMTAwNyAgMjYwN0sgICAgICAgLSAgICAg MTY5NSAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICBmZGVzY19tb3VudCAg ICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTYKICAgICBpcHJ0aGVhcCAgICAxOCAgICAg NEsgICAgICAgLSAgICAgICAxOCAgMzIsNjQsMTI4LDI1NiwyMDQ4CiAgICAgaXBydG1vYmogICAg IDEgICAgIDRLICAgICAgIC0gICAgICAgIDEgIAogICAgIG5ldGdyYXBoICAgICAzICAgICAxSyAg ICAgICAtICAgICAgICAzICA2NApuZXRncmFwaF9ub2RlICAgICAzICAgICAxSyAgICAgICAtICAg ICAgICAzICAyNTYKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp2bXN0YXQgLXoKCklURU0gICAgICAgICAgICAg ICAgICAgU0laRSAgTElNSVQgICAgIFVTRUQgICAgIEZSRUUgICAgICBSRVEgRkFJTCBTTEVFUAoK VU1BIEtlZ3M6ICAgICAgICAgICAgICAgMjA4LCAgICAgIDAsICAgICAyMDIsICAgICAgIDIsICAg ICAyMDIsICAgMCwgICAwClVNQSBab25lczogICAgICAgICAgICAgIDY0MCwgICAgICAwLCAgICAg MjAyLCAgICAgICAyLCAgICAgMjAyLCAgIDAsICAgMApVTUEgU2xhYnM6ICAgICAgICAgICAgICA1 NjgsICAgICAgMCwgICAxNjAyMywgICAgICAgMCwgICAzMTMzNCwgICAwLCAgIDAKVU1BIFJDbnRT bGFiczogICAgICAgICAgNTY4LCAgICAgIDAsICAgICAxMzksICAgICAgIDEsICAgICAxMzksICAg MCwgICAwClVNQSBIYXNoOiAgICAgICAgICAgICAgIDI1NiwgICAgICAwLCAgICAgIDg0LCAgICAg ICA2LCAgICAgIDg0LCAgIDAsICAgMAoxNiBCdWNrZXQ6ICAgICAgICAgICAgICAxNTIsICAgICAg MCwgICAgICA3OSwgICAgICAyMSwgICAgICA3OSwgICAwLCAgIDAKMzIgQnVja2V0OiAgICAgICAg ICAgICAgMjgwLCAgICAgIDAsICAgICAgNzMsICAgICAgMTEsICAgICAgNzMsICAgMCwgICAwCjY0 IEJ1Y2tldDogICAgICAgICAgICAgIDUzNiwgICAgICAwLCAgICAgIDc5LCAgICAgICA1LCAgICAg IDc5LCAgNTcsICAgMAoxMjggQnVja2V0OiAgICAgICAgICAgIDEwNDgsICAgICAgMCwgICAgIDEy NSwgICAgICAgMSwgICAgIDEyNSwgNDQxLCAgIDAKVk0gT0JKRUNUOiAgICAgICAgICAgICAgMjE2 LCAgICAgIDAsICAgIDE4NTMsICAgICAgNTUsICAgMjgwNzcsICAgMCwgICAwCk1BUDogICAgICAg ICAgICAgICAgICAgIDIzMiwgICAgICAwLCAgICAgICA3LCAgICAgIDI1LCAgICAgICA3LCAgIDAs ICAgMApLTUFQIEVOVFJZOiAgICAgICAgICAgICAxMjAsIDE1MDIyNiwgICAgIDEwMCwgICAgIDE3 OSwgICA1Nzg5MCwgICAwLCAgIDAKTUFQIEVOVFJZOiAgICAgICAgICAgICAgMTIwLCAgICAgIDAs ICAgIDEyODMsICAgICAxNzQsICAgNjM2MzksICAgMCwgICAwCmZha2VwZzogICAgICAgICAgICAg ICAgIDEyMCwgICAgICAwLCAgICAgMTQ2LCAgICAgIDcxLCAgICAgMTQ2LCAgIDAsICAgMAptdF96 b25lOiAgICAgICAgICAgICAgIDQxMTIsICAgICAgMCwgICAgIDI1NCwgICAgICAgOSwgICAgIDI1 NCwgICAwLCAgIDAKMTY6ICAgICAgICAgICAgICAgICAgICAgIDE2LCAgICAgIDAsICAgIDI3NzMs ICAgICAyNTEsICAxMTAyNjUsICAgMCwgICAwCjMyOiAgICAgICAgICAgICAgICAgICAgICAzMiwg ICAgICAwLCAgICAzMjk0LCAgICAgODUzLCAgIDU2ODE2LCAgIDAsICAgMAo2NDogICAgICAgICAg ICAgICAgICAgICAgNjQsICAgICAgMCwgICAzMzU4NSwgICAgICA4MywgIDIwNzg3MiwgICAwLCAg IDAKMTI4OiAgICAgICAgICAgICAgICAgICAgMTI4LCAgICAgIDAsICAgIDY2NTAsICAgIDE3MDIs ICAxMzYzNDIsICAgMCwgICAwCjI1NjogICAgICAgICAgICAgICAgICAgIDI1NiwgICAgICAwLCAg ICAxOTI1LCAgICAxNjYwLCAgIDgyMDgyLCAgIDAsICAgMAo1MTI6ICAgICAgICAgICAgICAgICAg ICA1MTIsICAgICAgMCwgICAgMjA2MywgICAgICAzMCwgIDM2OTM5NywgICAwLCAgIDAKMTAyNDog ICAgICAgICAgICAgICAgICAxMDI0LCAgICAgIDAsICAgICAyNDQsICAgICA1MDQsICAgIDQ5ODAs ICAgMCwgICAwCjIwNDg6ICAgICAgICAgICAgICAgICAgMjA0OCwgICAgICAwLCAgICAgMzYxLCAg ICAgIDIxLCAgICAxMjY3LCAgIDAsICAgMAo0MDk2OiAgICAgICAgICAgICAgICAgIDQwOTYsICAg ICAgMCwgICAgIDgzOSwgICAgICAxOSwgICAxMDUyMiwgICAwLCAgIDAKRmlsZXM6ICAgICAgICAg ICAgICAgICAgIDgwLCAgICAgIDAsICAgICAxNjIsICAgICAxMDgsICAgIDkxMzUsICAgMCwgICAw ClRVUk5TVElMRTogICAgICAgICAgICAgIDEzNiwgICAgICAwLCAgICAgMzE5LCAgICAgIDQxLCAg ICAgMzE5LCAgIDAsICAgMAp1bXR4IHBpOiAgICAgICAgICAgICAgICAgOTYsICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKTUFDIGxhYmVsczogICAgICAgICAgICAg IDQwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwClBST0M6ICAg ICAgICAgICAgICAgICAgMTE2MCwgICAgICAwLCAgICAgIDUxLCAgICAgIDIxLCAgICAyMTM2LCAg IDAsICAgMApUSFJFQUQ6ICAgICAgICAgICAgICAgIDExMTIsICAgICAgMCwgICAgIDI5NSwgICAg ICAyMywgICAgIDQzMywgICAwLCAgIDAKU0xFRVBRVUVVRTogICAgICAgICAgICAgIDgwLCAgICAg IDAsICAgICAzMTksICAgICAgMjksICAgICAzMTksICAgMCwgICAwClZNU1BBQ0U6ICAgICAgICAg ICAgICAgIDM5MiwgICAgICAwLCAgICAgIDMyLCAgICAgIDE4LCAgICAyMTE4LCAgIDAsICAgMApj cHVzZXQ6ICAgICAgICAgICAgICAgICAgNzIsICAgICAgMCwgICAgICAgMiwgICAgICA5OCwgICAg ICAgMiwgICAwLCAgIDAKYXVkaXRfcmVjb3JkOiAgICAgICAgICAgOTYwLCAgICAgIDAsICAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCm1idWZfcGFja2V0OiAgICAgICAgICAgIDI1 NiwgICAgICAwLCAgICAgICAwLCAgICAgMjY5LCAgICAgIDU4LCAgIDAsICAgMAptYnVmOiAgICAg ICAgICAgICAgICAgICAyNTYsICAgICAgMCwgICAgICAgMywgICAgIDI2NiwgICAgIDI2OCwgICAw LCAgIDAKbWJ1Zl9jbHVzdGVyOiAgICAgICAgICAyMDQ4LCAgMjU2MDAsICAgICAyNTYsICAgICAg MTgsICAgICAyNTYsICAgMCwgICAwCm1idWZfanVtYm9fcGFnZTogICAgICAgNDA5NiwgIDEyODAw LCAgICAgICAwLCAgICAgICAyLCAgICAgICAyLCAgIDAsICAgMAptYnVmX2p1bWJvXzlrOiAgICAg ICAgIDkyMTYsICAxOTIwMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKbWJ1 Zl9qdW1ib18xNms6ICAgICAgIDE2Mzg0LCAgMTI4MDAsICAgICAgIDAsICAgICAgIDAsICAgICAg IDAsICAgMCwgICAwCm1idWZfZXh0X3JlZmNudDogICAgICAgICAgNCwgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp0dHlpbnE6ICAgICAgICAgICAgICAgICAxNjAs ICAgICAgMCwgICAgIDEzNSwgICAgICAzMywgICAgIDQ5NSwgICAwLCAgIDAKdHR5b3V0cTogICAg ICAgICAgICAgICAgMjU2LCAgICAgIDAsICAgICAgNzIsICAgICAgMTgsICAgICAyNjQsICAgMCwg ICAwCmdfYmlvOiAgICAgICAgICAgICAgICAgIDIzMiwgICAgICAwLCAgICAgICAwLCAgICAgMTc2 LCAgMTU1MDIzLCAgIDAsICAgMAphdGFfcmVxdWVzdDogICAgICAgICAgICAzMjgsICAgICAgMCwg ICAgICAgMCwgICAgICAzNiwgICAgICAzMCwgICAwLCAgIDAKYXRhX2NvbXBvc2l0ZTogICAgICAg ICAgMzM2LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCm52X3N0 YWNrX3Q6ICAgICAgICAgICAxMjI4OCwgICAgICAwLCAgICAgICA4LCAgICAgICA2LCAgICAgIDE4 LCAgIDAsICAgMAp0YXNrcV96b25lOiAgICAgICAgICAgICAgNDgsICAgICAgMCwgICAgICAgMCwg ICAgIDIxNiwgICAgICA0MSwgICAwLCAgIDAKVk5PREU6ICAgICAgICAgICAgICAgICAgNDgwLCAg ICAgIDAsICAgIDI0MTAsICAgICAgMTQsICAgIDI0NTQsICAgMCwgICAwClZOT0RFUE9MTDogICAg ICAgICAgICAgIDExMiwgICAgICAwLCAgICAgICA5LCAgICAgIDU3LCAgICAgICA5LCAgIDAsICAg MApOQU1FSTogICAgICAgICAgICAgICAgIDEwMjQsICAgICAgMCwgICAgICAgMSwgICAgICAzNSwg ICAxOTExMiwgICAwLCAgIDAKUyBWRlMgQ2FjaGU6ICAgICAgICAgICAgMTA4LCAgICAgIDAsICAg IDI0NDksICAgICAxMjUsICAgIDM4MDMsICAgMCwgICAwCkwgVkZTIENhY2hlOiAgICAgICAgICAg IDMyOCwgICAgICAwLCAgICAgICA0LCAgICAgIDMyLCAgICAgICA0LCAgIDAsICAgMApESVJIQVNI OiAgICAgICAgICAgICAgIDEwMjQsICAgICAgMCwgICAgICA0OCwgICAgICAgOCwgICAgICA0OCwg ICAwLCAgIDAKcGlwZTogICAgICAgICAgICAgICAgICAgNzI4LCAgICAgIDAsICAgICAgMTQsICAg ICAgMTYsICAgIDE0NDUsICAgMCwgICAwCnppb19jYWNoZTogICAgICAgICAgICAgIDg4MCwgICAg ICAwLCAgICAgICA1LCAgICAxNjE1LCAgMTY5NzYxLCAgIDAsICAgMAp6aW9fbGlua19jYWNoZTog ICAgICAgICAgNDgsICAgICAgMCwgICAgICAgMSwgICAgMTY1NSwgICA0NTY2OSwgICAwLCAgIDAK emlvX2J1Zl81MTI6ICAgICAgICAgICAgNTEyLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAg ICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl81MTI6ICAgICAgIDUxMiwgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzEwMjQ6ICAgICAgICAgIDEw MjQsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFf YnVmXzEwMjQ6ICAgICAxMDI0LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAg MCwgICAwCnppb19idWZfMTUzNjogICAgICAgICAgMTUzNiwgICAgICAwLCAgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfMTUzNjogICAgIDE1MzYsICAgICAg MCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl8yMDQ4OiAgICAg ICAgICAyMDQ4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnpp b19kYXRhX2J1Zl8yMDQ4OiAgICAgMjA0OCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAg ICAwLCAgIDAsICAgMAp6aW9fYnVmXzI1NjA6ICAgICAgICAgIDI1NjAsICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzI1NjA6ICAgICAyNTYw LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19idWZfMzA3 MjogICAgICAgICAgMzA3MiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAs ICAgMAp6aW9fZGF0YV9idWZfMzA3MjogICAgIDMwNzIsICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl8zNTg0OiAgICAgICAgICAzNTg0LCAgICAgIDAs ICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl8zNTg0OiAg ICAgMzU4NCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9f YnVmXzQwOTY6ICAgICAgICAgIDQwOTYsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzQwOTY6ICAgICA0MDk2LCAgICAgIDAsICAgICAgIDAs ICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19idWZfNTEyMDogICAgICAgICAgNTEyMCwg ICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZf NTEyMDogICAgIDUxMjAsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAg IDAKemlvX2J1Zl82MTQ0OiAgICAgICAgICA2MTQ0LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl82MTQ0OiAgICAgNjE0NCwgICAgICAwLCAg ICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzcxNjg6ICAgICAgICAg IDcxNjgsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2Rh dGFfYnVmXzcxNjg6ICAgICA3MTY4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgMCwgICAwCnppb19idWZfODE5MjogICAgICAgICAgODE5MiwgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfODE5MjogICAgIDgxOTIsICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl8xMDI0MDog ICAgICAgIDEwMjQwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAw Cnppb19kYXRhX2J1Zl8xMDI0MDogICAxMDI0MCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzEyMjg4OiAgICAgICAgMTIyODgsICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzEyMjg4OiAgIDEy Mjg4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19idWZf MTQzMzY6ICAgICAgICAxNDMzNiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAg IDAsICAgMAp6aW9fZGF0YV9idWZfMTQzMzY6ICAgMTQzMzYsICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl8xNjM4NDogICAgICAgIDE2Mzg0LCAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl8xNjM4 NDogICAxNjM4NCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6 aW9fYnVmXzIwNDgwOiAgICAgICAgMjA0ODAsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzIwNDgwOiAgIDIwNDgwLCAgICAgIDAsICAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19idWZfMjQ1NzY6ICAgICAgICAyNDU3 NiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9i dWZfMjQ1NzY6ICAgMjQ1NzYsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAw LCAgIDAKemlvX2J1Zl8yODY3MjogICAgICAgIDI4NjcyLCAgICAgIDAsICAgICAgIDAsICAgICAg IDAsICAgICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl8yODY3MjogICAyODY3MiwgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzMyNzY4OiAgICAg ICAgMzI3NjgsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlv X2RhdGFfYnVmXzMyNzY4OiAgIDMyNzY4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAg IDAsICAgMCwgICAwCnppb19idWZfMzY4NjQ6ICAgICAgICAzNjg2NCwgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfMzY4NjQ6ICAgMzY4NjQs ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl80MDk2 MDogICAgICAgIDQwOTYwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwg ICAwCnppb19kYXRhX2J1Zl80MDk2MDogICA0MDk2MCwgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzQ1MDU2OiAgICAgICAgNDUwNTYsICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzQ1MDU2OiAg IDQ1MDU2LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19i dWZfNDkxNTI6ICAgICAgICA0OTE1MiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgIDAsICAgMAp6aW9fZGF0YV9idWZfNDkxNTI6ICAgNDkxNTIsICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl81MzI0ODogICAgICAgIDUzMjQ4LCAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl81 MzI0ODogICA1MzI0OCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAg MAp6aW9fYnVmXzU3MzQ0OiAgICAgICAgNTczNDQsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzU3MzQ0OiAgIDU3MzQ0LCAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19idWZfNjE0NDA6ICAgICAgICA2 MTQ0MCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0 YV9idWZfNjE0NDA6ICAgNjE0NDAsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwg ICAwLCAgIDAKemlvX2J1Zl82NTUzNjogICAgICAgIDY1NTM2LCAgICAgIDAsICAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl82NTUzNjogICA2NTUzNiwgICAg ICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzY5NjMyOiAg ICAgICAgNjk2MzIsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAK emlvX2RhdGFfYnVmXzY5NjMyOiAgIDY5NjMyLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAg ICAgIDAsICAgMCwgICAwCnppb19idWZfNzM3Mjg6ICAgICAgICA3MzcyOCwgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfNzM3Mjg6ICAgNzM3 MjgsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl83 NzgyNDogICAgICAgIDc3ODI0LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAg MCwgICAwCnppb19kYXRhX2J1Zl83NzgyNDogICA3NzgyNCwgICAgICAwLCAgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzgxOTIwOiAgICAgICAgODE5MjAsICAgICAg MCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzgxOTIw OiAgIDgxOTIwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnpp b19idWZfODYwMTY6ICAgICAgICA4NjAxNiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAg ICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfODYwMTY6ICAgODYwMTYsICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl85MDExMjogICAgICAgIDkwMTEy LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1 Zl85MDExMjogICA5MDExMiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAs ICAgMAp6aW9fYnVmXzk0MjA4OiAgICAgICAgOTQyMDgsICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzk0MjA4OiAgIDk0MjA4LCAgICAgIDAs ICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19idWZfOTgzMDQ6ICAgICAg ICA5ODMwNCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9f ZGF0YV9idWZfOTgzMDQ6ICAgOTgzMDQsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAwLCAgIDAKemlvX2J1Zl8xMDI0MDA6ICAgICAgMTAyNDAwLCAgICAgIDAsICAgICAgIDAs ICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19kYXRhX2J1Zl8xMDI0MDA6IDEwMjQwMCwg ICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzEwNjQ5 NjogICAgICAxMDY0OTYsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAg IDAKemlvX2RhdGFfYnVmXzEwNjQ5NjogMTA2NDk2LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgICAgIDAsICAgMCwgICAwCnppb19idWZfMTEwNTkyOiAgICAgIDExMDU5MiwgICAgICAwLCAg ICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfMTEwNTkyOiAx MTA1OTIsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1 Zl8xMTQ2ODg6ICAgICAgMTE0Njg4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgMCwgICAwCnppb19kYXRhX2J1Zl8xMTQ2ODg6IDExNDY4OCwgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgICAgICAwLCAgIDAsICAgMAp6aW9fYnVmXzExODc4NDogICAgICAxMTg3ODQsICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzEx ODc4NDogMTE4Nzg0LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAw Cnppb19idWZfMTIyODgwOiAgICAgIDEyMjg4MCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAg ICAgICAwLCAgIDAsICAgMAp6aW9fZGF0YV9idWZfMTIyODgwOiAxMjI4ODAsICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2J1Zl8xMjY5NzY6ICAgICAgMTI2 OTc2LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnppb19kYXRh X2J1Zl8xMjY5NzY6IDEyNjk3NiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAg IDAsICAgMAp6aW9fYnVmXzEzMTA3MjogICAgICAxMzEwNzIsICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAwLCAgIDAKemlvX2RhdGFfYnVmXzEzMTA3MjogMTMxMDcyLCAgICAg IDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnNhX2NhY2hlOiAgICAgICAg ICAgICAgICA4MCwgICAgICAwLCAgICAxMDA1LCAgICAgIDc1LCAgICAxMDQ0LCAgIDAsICAgMApk bm9kZV90OiAgICAgICAgICAgICAgICA4NTYsICAgICAgMCwgICAgMTE3MiwgICAgICAxMiwgICAg MTI2NiwgICAwLCAgIDAKZG11X2J1Zl9pbXBsX3Q6ICAgICAgICAgMjI0LCAgICAgIDAsICAgMTU4 MTAsICAgICAgNTEsICAgMjg4OTEsICAgMCwgICAwCmFyY19idWZfaGRyX3Q6ICAgICAgICAgIDIx NiwgICAgICAwLCAgIDE1MTM4LCAgICAgIDM2LCAgIDI4MTc1LCAgIDAsICAgMAphcmNfYnVmX3Q6 ICAgICAgICAgICAgICAxMDQsICAgICAgMCwgICAxNTEwMCwgICAgICAyMCwgICAyODMwOCwgICAw LCAgIDAKemlsX2x3Yl9jYWNoZTogICAgICAgICAgMTkyLCAgICAgIDAsICAgICAgIDEsICAgICAx MTksICAgICAxMjgsICAgMCwgICAwCnpmc196bm9kZV9jYWNoZTogICAgICAgIDQwMCwgICAgICAw LCAgICAxMDA1LCAgICAgIDMwLCAgICAxMDQ0LCAgIDAsICAgMApNb3VudHBvaW50czogICAgICAg ICAgICA3NjgsICAgICAgMCwgICAgICAgOCwgICAgICAxNywgICAgICAgOCwgICAwLCAgIDAKa3Np Z2luZm86ICAgICAgICAgICAgICAgMTEyLCAgICAgIDAsICAgICAgNTgsICAgICA5OTEsICAgICAg NjIsICAgMCwgICAwCml0aW1lcjogICAgICAgICAgICAgICAgIDM0NCwgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApLTk9URTogICAgICAgICAgICAgICAgICAxMjgs ICAgICAgMCwgICAgICAgOCwgICAgICA3OSwgICAgICAyMCwgICAwLCAgIDAKcGZzeW5jOiAgICAg ICAgICAgICAgICAgIDg4LCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwg ICAwCnBmc3JjdHJwbDogICAgICAgICAgICAgIDE1MiwgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgICAgICAwLCAgIDAsICAgMApwZnJ1bGVwbDogICAgICAgICAgICAgICA5MzYsICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKcGZzdGF0ZXBsOiAgICAgICAgICAg ICAgMjg4LCAgMTAwMTAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnBmc3Rh dGVrZXlwbDogICAgICAgICAgIDI4OCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAw LCAgIDAsICAgMApwZnN0YXRlaXRlbXBsOiAgICAgICAgICAyODgsICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKcGZhbHRxcGw6ICAgICAgICAgICAgICAgMjQwLCAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnBmcG9vbGFkZHJwbDog ICAgICAgICAgICA4OCwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAg MApwZnJrdGFibGU6ICAgICAgICAgICAgIDEyOTYsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwg ICAgICAgMCwgICAwLCAgIDAKcGZya2VudHJ5OiAgICAgICAgICAgICAgMTYwLCAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnBmZnJlbnQ6ICAgICAgICAgICAgICAg ICAzMiwgICA1MDUwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApwZmZyYWc6 ICAgICAgICAgICAgICAgICAgODAsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwg ICAwLCAgIDAKcGZmcmNhY2hlOiAgICAgICAgICAgICAgIDgwLCAgMTAwMzUsICAgICAgIDAsICAg ICAgIDAsICAgICAgIDAsICAgMCwgICAwCnBmZnJjZW50OiAgICAgICAgICAgICAgICAyNCwgIDUw MDIyLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApwZnN0YXRlc2NydWI6ICAg ICAgICAgICAgNDAsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAK cGZpYWRkcnBsOiAgICAgICAgICAgICAgMTIwLCAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAg ICAgIDAsICAgMCwgICAwCnBmb3NwZmVuOiAgICAgICAgICAgICAgIDExMiwgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApwZm9zZnA6ICAgICAgICAgICAgICAgICAg NDAsICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKc29ja2V0OiAg ICAgICAgICAgICAgICAgNjgwLCAgMjU2MDIsICAgICAgNDAsICAgICAgMjAsICAgICAyNDEsICAg MCwgICAwCmlwcTogICAgICAgICAgICAgICAgICAgICA1NiwgICAgODE5LCAgICAgICAwLCAgICAg ICAwLCAgICAgICAwLCAgIDAsICAgMAp1ZHBfaW5wY2I6ICAgICAgICAgICAgICAzOTIsICAyNTYw MCwgICAgICAgMSwgICAgICAyOSwgICAgIDE0NiwgICAwLCAgIDAKdWRwY2I6ICAgICAgICAgICAg ICAgICAgIDE2LCAgMjU3MDQsICAgICAgIDEsICAgICAzMzUsICAgICAxNDYsICAgMCwgICAwCnRj cF9pbnBjYjogICAgICAgICAgICAgIDM5MiwgIDI1NjAwLCAgICAgICAzLCAgICAgIDI3LCAgICAg ICA1LCAgIDAsICAgMAp0Y3BjYjogICAgICAgICAgICAgICAgICA5NzYsICAyNTYwMCwgICAgICAg MywgICAgICAgOSwgICAgICAgNSwgICAwLCAgIDAKdGNwdHc6ICAgICAgICAgICAgICAgICAgIDcy LCAgIDUxNTAsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnN5bmNhY2hlOiAg ICAgICAgICAgICAgIDE1MiwgIDE1Mzc1LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAs ICAgMApob3N0Y2FjaGU6ICAgICAgICAgICAgICAxMzYsICAxNTM3MiwgICAgICAgMCwgICAgICAg MCwgICAgICAgMCwgICAwLCAgIDAKdGNwcmVhc3M6ICAgICAgICAgICAgICAgIDQwLCAgIDE2ODAs ICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnNhY2tob2xlOiAgICAgICAgICAg ICAgICAzMiwgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApzY3Rw X2VwOiAgICAgICAgICAgICAgIDEzNjAsICAyNTYwMiwgICAgICAgMCwgICAgICAgMCwgICAgICAg MCwgICAwLCAgIDAKc2N0cF9hc29jOiAgICAgICAgICAgICAyMjcyLCAgNDAwMDAsICAgICAgIDAs ICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCnNjdHBfbGFkZHI6ICAgICAgICAgICAgICA0OCwg IDgwMDY0LCAgICAgICAwLCAgICAgMTQ0LCAgICAgICAxLCAgIDAsICAgMApzY3RwX3JhZGRyOiAg ICAgICAgICAgICA2NzIsICA4MDAwNCwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAg IDAKc2N0cF9jaHVuazogICAgICAgICAgICAgMTM2LCA0MDAwMDgsICAgICAgIDAsICAgICAgIDAs ICAgICAgIDAsICAgMCwgICAwCnNjdHBfcmVhZHE6ICAgICAgICAgICAgIDEwNCwgNDAwMDMyLCAg ICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApzY3RwX3N0cmVhbV9tc2dfb3V0OiAg ICAxMTIsIDQwMDAyNiwgICAgICAgMCwgICAgICAgMCwgICAgICAgMCwgICAwLCAgIDAKc2N0cF9h c2NvbmY6ICAgICAgICAgICAgIDQwLCA0MDAwMDgsICAgICAgIDAsICAgICAgIDAsICAgICAgIDAs ICAgMCwgICAwCnNjdHBfYXNjb25mX2FjazogICAgICAgICA0OCwgNDAwMDMyLCAgICAgICAwLCAg ICAgICAwLCAgICAgICAwLCAgIDAsICAgMApyaXBjYjogICAgICAgICAgICAgICAgICAzOTIsICAy NTYwMCwgICAgICAgMSwgICAgICAxOSwgICAgICAgMSwgICAwLCAgIDAKdW5wY2I6ICAgICAgICAg ICAgICAgICAgMjQwLCAgMjU2MDAsICAgICAgMzQsICAgICAgNDYsICAgICAgODMsICAgMCwgICAw CnJ0ZW50cnk6ICAgICAgICAgICAgICAgIDIwMCwgICAgICAwLCAgICAgICA0LCAgICAgIDUzLCAg ICAgICA1LCAgIDAsICAgMApzZWxmZDogICAgICAgICAgICAgICAgICAgNTYsICAgICAgMCwgICAg ICA3OSwgICAgIDE3MywgICAgMTYzNiwgICAwLCAgIDAKU1dBUE1FVEE6ICAgICAgICAgICAgICAg Mjg4LCAxMTY1MTksICAgICAgIDAsICAgICAgIDAsICAgICAgIDAsICAgMCwgICAwCkZGUyBpbm9k ZTogICAgICAgICAgICAgIDE2OCwgICAgICAwLCAgICAxMzI2LCAgICAgIDM4LCAgICAxMzI2LCAg IDAsICAgMApGRlMxIGRpbm9kZTogICAgICAgICAgICAxMjgsICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAgICAgMCwgICAwLCAgIDAKRkZTMiBkaW5vZGU6ICAgICAgICAgICAgMjU2LCAgICAg IDAsICAgIDEzMjYsICAgICAgMjQsICAgIDEzMjYsICAgMCwgICAwCk5ldEdyYXBoIGl0ZW1zOiAg ICAgICAgICA3MiwgICA0MTE4LCAgICAgICAwLCAgICAgICAwLCAgICAgICAwLCAgIDAsICAgMApO ZXRHcmFwaCBkYXRhIGl0ZW1zOiAgICAgNzIsICAgIDUyMiwgICAgICAgMCwgICAgICAgMCwgICAg ICAgMCwgICAwLCAgIDAKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0Kdm1zdGF0IC1pCgppbnRlcnJ1cHQgICAg ICAgICAgICAgICAgICAgICAgICAgIHRvdGFsICAgICAgIHJhdGUKaXJxMTogYXRrYmQwICAgICAg ICAgICAgICAgICAgICAgICAgICAxMCAgICAgICAgICAwCmlycTE2OiB2Z2FwY2kwKysgICAgICAg ICAgICAgICAgICAgICAxNzAgICAgICAgICAgMQppcnExODogdWhjaTIgZWhjaTArICAgICAgICAg ICAgICAgICAgIDE1ICAgICAgICAgIDAKaXJxMjA6IGhwZXQwICAgICAgICAgICAgICAgICAgICAg ICA3MTUwOSAgICAgICAgODMxCmlycTIzOiB1aGNpMyBlaGNpMSAgICAgICAgICAgICAgICAgICAg MzIgICAgICAgICAgMAppcnEyNTY6IGhkYWMwICAgICAgICAgICAgICAgICAgICAgICAgIDQyICAg ICAgICAgIDAKaXJxMjU3OiBhbGUwICAgICAgICAgICAgICAgICAgICAgICAgICAyMiAgICAgICAg ICAwCmlycTI1ODogYWhjaTAgICAgICAgICAgICAgICAgICAgICAgMzI3MzUgICAgICAgIDM4MApU b3RhbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTA0NTM1ICAgICAgIDEyMTUKCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQpwc3RhdCAtVAoKMTYyLzEyMzI4IGZpbGVzCjBNLzk3MjdNIHN3YXAgc3BhY2UK Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQpwc3RhdCAtcwoKRGV2aWNlICAgICAgICAgIDUxMi1ibG9ja3MgICAg IFVzZWQgICAgQXZhaWwgQ2FwYWNpdHkKL2Rldi9sYWJlbC9zd2FwMCAgIDE5OTIyNjgwICAgICAg ICAwIDE5OTIyNjgwICAgICAwJQoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCmlvc3RhdAoKaW9zdGF0OiBrdm1f cmVhZChfdGtfbmluKTogaW52YWxpZCBhZGRyZXNzICgweDApCmlvc3RhdDogZGlzYWJsaW5nIFRU WSBzdGF0aXN0aWNzCiAgICAgICAgICAgIGFkYTAgICAgICAgICAgICAgIGNkMCAgICAgICAgICAg ICAgY2QxICAgICAgICAgICAgIGNwdQogIEtCL3QgdHBzICBNQi9zICAgS0IvdCB0cHMgIE1CL3Mg ICBLQi90IHRwcyAgTUIvcyAgdXMgbmkgc3kgaW4gaWQKIDExMC41MiAzNjcgMzkuNjUgICAwLjAw ICAgMCAgMC4wMCAgIDAuMDAgICAwICAwLjAwICAgNSAgMCAgNyAgMCA4OAoKLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tCmlwY3MgLWEKCk1lc3NhZ2UgUXVldWVzOgpUICAgICAgICAgICBJRCAgICAgICAgICBLRVkg TU9ERSAgICAgICAgT1dORVIgICAgR1JPVVAgICAgQ1JFQVRPUiAgQ0dST1VQICAgICAgICAgICAg ICAgICBDQllURVMgICAgICAgICAgICAgICAgIFFOVU0gICAgICAgICAgICAgICBRQllURVMgICAg ICAgIExTUElEICAgICAgICBMUlBJRCBTVElNRSAgICBSVElNRSAgICBDVElNRSAgIAoKU2hhcmVk IE1lbW9yeToKVCAgICAgICAgICAgSUQgICAgICAgICAgS0VZIE1PREUgICAgICAgIE9XTkVSICAg IEdST1VQICAgIENSRUFUT1IgIENHUk9VUCAgICAgICAgIE5BVFRDSCAgICAgICAgU0VHU1ogICAg ICAgICBDUElEICAgICAgICAgTFBJRCBBVElNRSAgICBEVElNRSAgICBDVElNRSAgIAoKU2VtYXBo b3JlczoKVCAgICAgICAgICAgSUQgICAgICAgICAgS0VZIE1PREUgICAgICAgIE9XTkVSICAgIEdS T1VQICAgIENSRUFUT1IgIENHUk9VUCAgICAgICAgICBOU0VNUyBPVElNRSAgICBDVElNRSAgIAoK Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQppcGNzIC1UCgptc2dpbmZvOgoJbXNnbWF4OiAgICAgICAgMTYzODQJ KG1heCBjaGFyYWN0ZXJzIGluIGEgbWVzc2FnZSkKCW1zZ21uaTogICAgICAgICAgIDQwCSgjIG9m IG1lc3NhZ2UgcXVldWVzKQoJbXNnbW5iOiAgICAgICAgIDIwNDgJKG1heCBjaGFyYWN0ZXJzIGlu IGEgbWVzc2FnZSBxdWV1ZSkKCW1zZ3RxbDogICAgICAgICAgIDQwCShtYXggIyBvZiBtZXNzYWdl cyBpbiBzeXN0ZW0pCgltc2dzc3o6ICAgICAgICAgICAgOAkoc2l6ZSBvZiBhIG1lc3NhZ2Ugc2Vn bWVudCkKCW1zZ3NlZzogICAgICAgICAyMDQ4CSgjIG9mIG1lc3NhZ2Ugc2VnbWVudHMgaW4gc3lz dGVtKQoKc2htaW5mbzoKCXNobW1heDogICAgNTM2ODcwOTEyCShtYXggc2hhcmVkIG1lbW9yeSBz ZWdtZW50IHNpemUpCglzaG1taW46ICAgICAgICAgICAgMQkobWluIHNoYXJlZCBtZW1vcnkgc2Vn bWVudCBzaXplKQoJc2htbW5pOiAgICAgICAgICAxOTIJKG1heCBudW1iZXIgb2Ygc2hhcmVkIG1l bW9yeSBpZGVudGlmaWVycykKCXNobXNlZzogICAgICAgICAgMTI4CShtYXggc2hhcmVkIG1lbW9y eSBzZWdtZW50cyBwZXIgcHJvY2VzcykKCXNobWFsbDogICAgICAgMTMxMDcyCShtYXggYW1vdW50 IG9mIHNoYXJlZCBtZW1vcnkgaW4gcGFnZXMpCgpzZW1pbmZvOgoJc2VtbW5pOiAgICAgICAgICAg NTAJKCMgb2Ygc2VtYXBob3JlIGlkZW50aWZpZXJzKQoJc2VtbW5zOiAgICAgICAgICAzNDAJKCMg b2Ygc2VtYXBob3JlcyBpbiBzeXN0ZW0pCglzZW1tbnU6ICAgICAgICAgIDE1MAkoIyBvZiB1bmRv IHN0cnVjdHVyZXMgaW4gc3lzdGVtKQoJc2VtbXNsOiAgICAgICAgICAzNDAJKG1heCAjIG9mIHNl bWFwaG9yZXMgcGVyIGlkKQoJc2Vtb3BtOiAgICAgICAgICAxMDAJKG1heCAjIG9mIG9wZXJhdGlv bnMgcGVyIHNlbW9wIGNhbGwpCglzZW11bWU6ICAgICAgICAgICA1MAkobWF4ICMgb2YgdW5kbyBl bnRyaWVzIHBlciBwcm9jZXNzKQoJc2VtdXN6OiAgICAgICAgICA2MzIJKHNpemUgaW4gYnl0ZXMg b2YgdW5kbyBzdHJ1Y3R1cmUpCglzZW12bXg6ICAgICAgICAzMjc2Nwkoc2VtYXBob3JlIG1heGlt dW0gdmFsdWUpCglzZW1hZW06ICAgICAgICAxNjM4NAkoYWRqdXN0IG9uIGV4aXQgbWF4IHZhbHVl KQoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQpuZnNzdGF0CgpuZnNzdGF0OiBuZXcgY2xpZW50L3NlcnZlciBu b3QgbG9hZGVkCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KbmV0c3RhdCAtcwoKdGNwOgoJNSBwYWNrZXRzIHNl bnQKCQkxIGRhdGEgcGFja2V0ICg5MSBieXRlcykKCQkwIGRhdGEgcGFja2V0cyAoMCBieXRlcykg cmV0cmFuc21pdHRlZAoJCTAgZGF0YSBwYWNrZXRzIHVubmVjZXNzYXJpbHkgcmV0cmFuc21pdHRl ZAoJCTAgcmVzZW5kcyBpbml0aWF0ZWQgYnkgTVRVIGRpc2NvdmVyeQoJCTIgYWNrLW9ubHkgcGFj a2V0cyAoMCBkZWxheWVkKQoJCTAgVVJHIG9ubHkgcGFja2V0cwoJCTAgd2luZG93IHByb2JlIHBh Y2tldHMKCQkwIHdpbmRvdyB1cGRhdGUgcGFja2V0cwoJCTIgY29udHJvbCBwYWNrZXRzCgk0IHBh Y2tldHMgcmVjZWl2ZWQKCQkzIGFja3MgKGZvciA5MiBieXRlcykKCQkxIGR1cGxpY2F0ZSBhY2sK CQkwIGFja3MgZm9yIHVuc2VudCBkYXRhCgkJMiBwYWNrZXRzICgyNjEgYnl0ZXMpIHJlY2VpdmVk IGluLXNlcXVlbmNlCgkJMCBjb21wbGV0ZWx5IGR1cGxpY2F0ZSBwYWNrZXRzICgwIGJ5dGVzKQoJ CTAgb2xkIGR1cGxpY2F0ZSBwYWNrZXRzCgkJMCBwYWNrZXRzIHdpdGggc29tZSBkdXAuIGRhdGEg KDAgYnl0ZXMgZHVwZWQpCgkJMCBvdXQtb2Ytb3JkZXIgcGFja2V0cyAoMCBieXRlcykKCQkwIHBh Y2tldHMgKDAgYnl0ZXMpIG9mIGRhdGEgYWZ0ZXIgd2luZG93CgkJMCB3aW5kb3cgcHJvYmVzCgkJ MCB3aW5kb3cgdXBkYXRlIHBhY2tldHMKCQkwIHBhY2tldHMgcmVjZWl2ZWQgYWZ0ZXIgY2xvc2UK CQkwIGRpc2NhcmRlZCBmb3IgYmFkIGNoZWNrc3VtcwoJCTAgZGlzY2FyZGVkIGZvciBiYWQgaGVh ZGVyIG9mZnNldCBmaWVsZHMKCQkwIGRpc2NhcmRlZCBiZWNhdXNlIHBhY2tldCB0b28gc2hvcnQK CQkwIGRpc2NhcmRlZCBkdWUgdG8gbWVtb3J5IHByb2JsZW1zCgkxIGNvbm5lY3Rpb24gcmVxdWVz dAoJMCBjb25uZWN0aW9uIGFjY2VwdHMKCTAgYmFkIGNvbm5lY3Rpb24gYXR0ZW1wdHMKCTAgbGlz dGVuIHF1ZXVlIG92ZXJmbG93cwoJMCBpZ25vcmVkIFJTVHMgaW4gdGhlIHdpbmRvd3MKCTEgY29u bmVjdGlvbiBlc3RhYmxpc2hlZCAoaW5jbHVkaW5nIGFjY2VwdHMpCgkyIGNvbm5lY3Rpb25zIGNs b3NlZCAoaW5jbHVkaW5nIDAgZHJvcHMpCgkJMCBjb25uZWN0aW9ucyB1cGRhdGVkIGNhY2hlZCBS VFQgb24gY2xvc2UKCQkwIGNvbm5lY3Rpb25zIHVwZGF0ZWQgY2FjaGVkIFJUVCB2YXJpYW5jZSBv biBjbG9zZQoJCTAgY29ubmVjdGlvbnMgdXBkYXRlZCBjYWNoZWQgc3N0aHJlc2ggb24gY2xvc2UK CTAgZW1icnlvbmljIGNvbm5lY3Rpb25zIGRyb3BwZWQKCTMgc2VnbWVudHMgdXBkYXRlZCBydHQg KG9mIDMgYXR0ZW1wdHMpCgkwIHJldHJhbnNtaXQgdGltZW91dHMKCQkwIGNvbm5lY3Rpb25zIGRy b3BwZWQgYnkgcmV4bWl0IHRpbWVvdXQKCTAgcGVyc2lzdCB0aW1lb3V0cwoJCTAgY29ubmVjdGlv bnMgZHJvcHBlZCBieSBwZXJzaXN0IHRpbWVvdXQKCTAgQ29ubmVjdGlvbnMgKGZpbl93YWl0XzIp IGRyb3BwZWQgYmVjYXVzZSBvZiB0aW1lb3V0CgkwIGtlZXBhbGl2ZSB0aW1lb3V0cwoJCTAga2Vl cGFsaXZlIHByb2JlcyBzZW50CgkJMCBjb25uZWN0aW9ucyBkcm9wcGVkIGJ5IGtlZXBhbGl2ZQoJ MCBjb3JyZWN0IEFDSyBoZWFkZXIgcHJlZGljdGlvbnMKCTAgY29ycmVjdCBkYXRhIHBhY2tldCBo ZWFkZXIgcHJlZGljdGlvbnMKCTAgc3luY2FjaGUgZW50cmllcyBhZGRlZAoJCTAgcmV0cmFuc21p dHRlZAoJCTAgZHVwc3luCgkJMCBkcm9wcGVkCgkJMCBjb21wbGV0ZWQKCQkwIGJ1Y2tldCBvdmVy ZmxvdwoJCTAgY2FjaGUgb3ZlcmZsb3cKCQkwIHJlc2V0CgkJMCBzdGFsZQoJCTAgYWJvcnRlZAoJ CTAgYmFkYWNrCgkJMCB1bnJlYWNoCgkJMCB6b25lIGZhaWx1cmVzCgkwIGNvb2tpZXMgc2VudAoJ MCBjb29raWVzIHJlY2VpdmVkCgkwIGhvc3RjYWNoZSBlbnRyaWVzIGFkZGVkCgkJMCBidWNrZXQg b3ZlcmZsb3cKCTAgU0FDSyByZWNvdmVyeSBlcGlzb2RlcwoJMCBzZWdtZW50IHJleG1pdHMgaW4g U0FDSyByZWNvdmVyeSBlcGlzb2RlcwoJMCBieXRlIHJleG1pdHMgaW4gU0FDSyByZWNvdmVyeSBl cGlzb2RlcwoJMCBTQUNLIG9wdGlvbnMgKFNBQ0sgYmxvY2tzKSByZWNlaXZlZAoJMCBTQUNLIG9w dGlvbnMgKFNBQ0sgYmxvY2tzKSBzZW50CgkwIFNBQ0sgc2NvcmVib2FyZCBvdmVyZmxvdwoJMCBw YWNrZXRzIHdpdGggRUNOIENFIGJpdCBzZXQKCTAgcGFja2V0cyB3aXRoIEVDTiBFQ1QoMCkgYml0 IHNldAoJMCBwYWNrZXRzIHdpdGggRUNOIEVDVCgxKSBiaXQgc2V0CgkwIHN1Y2Nlc3NmdWwgRUNO IGhhbmRzaGFrZXMKCTAgdGltZXMgRUNOIHJlZHVjZWQgdGhlIGNvbmdlc3Rpb24gd2luZG93CnVk cDoKCTUgZGF0YWdyYW1zIHJlY2VpdmVkCgkwIHdpdGggaW5jb21wbGV0ZSBoZWFkZXIKCTAgd2l0 aCBiYWQgZGF0YSBsZW5ndGggZmllbGQKCTAgd2l0aCBiYWQgY2hlY2tzdW0KCTAgd2l0aCBubyBj aGVja3N1bQoJMCBkcm9wcGVkIGR1ZSB0byBubyBzb2NrZXQKCTAgYnJvYWRjYXN0L211bHRpY2Fz dCBkYXRhZ3JhbXMgdW5kZWxpdmVyZWQKCTAgZHJvcHBlZCBkdWUgdG8gZnVsbCBzb2NrZXQgYnVm ZmVycwoJMCBub3QgZm9yIGhhc2hlZCBwY2IKCTUgZGVsaXZlcmVkCgk1IGRhdGFncmFtcyBvdXRw dXQKCTAgdGltZXMgbXVsdGljYXN0IHNvdXJjZSBmaWx0ZXIgbWF0Y2hlZAppcDoKCTExIHRvdGFs IHBhY2tldHMgcmVjZWl2ZWQKCTAgYmFkIGhlYWRlciBjaGVja3N1bXMKCTAgd2l0aCBzaXplIHNt YWxsZXIgdGhhbiBtaW5pbXVtCgkwIHdpdGggZGF0YSBzaXplIDwgZGF0YSBsZW5ndGgKCTAgd2l0 aCBpcCBsZW5ndGggPiBtYXggaXAgcGFja2V0IHNpemUKCTAgd2l0aCBoZWFkZXIgbGVuZ3RoIDwg ZGF0YSBzaXplCgkwIHdpdGggZGF0YSBsZW5ndGggPCBoZWFkZXIgbGVuZ3RoCgkwIHdpdGggYmFk IG9wdGlvbnMKCTAgd2l0aCBpbmNvcnJlY3QgdmVyc2lvbiBudW1iZXIKCTAgZnJhZ21lbnRzIHJl Y2VpdmVkCgkwIGZyYWdtZW50cyBkcm9wcGVkIChkdXAgb3Igb3V0IG9mIHNwYWNlKQoJMCBmcmFn bWVudHMgZHJvcHBlZCBhZnRlciB0aW1lb3V0CgkwIHBhY2tldHMgcmVhc3NlbWJsZWQgb2sKCTkg cGFja2V0cyBmb3IgdGhpcyBob3N0CgkxIHBhY2tldCBmb3IgdW5rbm93bi91bnN1cHBvcnRlZCBw cm90b2NvbAoJMCBwYWNrZXRzIGZvcndhcmRlZCAoMCBwYWNrZXRzIGZhc3QgZm9yd2FyZGVkKQoJ MSBwYWNrZXQgbm90IGZvcndhcmRhYmxlCgkwIHBhY2tldHMgcmVjZWl2ZWQgZm9yIHVua25vd24g bXVsdGljYXN0IGdyb3VwCgkwIHJlZGlyZWN0cyBzZW50CgkxMCBwYWNrZXRzIHNlbnQgZnJvbSB0 aGlzIGhvc3QKCTAgcGFja2V0cyBzZW50IHdpdGggZmFicmljYXRlZCBpcCBoZWFkZXIKCTAgb3V0 cHV0IHBhY2tldHMgZHJvcHBlZCBkdWUgdG8gbm8gYnVmcywgZXRjLgoJMCBvdXRwdXQgcGFja2V0 cyBkaXNjYXJkZWQgZHVlIHRvIG5vIHJvdXRlCgkwIG91dHB1dCBkYXRhZ3JhbXMgZnJhZ21lbnRl ZAoJMCBmcmFnbWVudHMgY3JlYXRlZAoJMCBkYXRhZ3JhbXMgdGhhdCBjYW4ndCBiZSBmcmFnbWVu dGVkCgkwIHR1bm5lbGluZyBwYWNrZXRzIHRoYXQgY2FuJ3QgZmluZCBnaWYKCTAgZGF0YWdyYW1z IHdpdGggYmFkIGFkZHJlc3MgaW4gaGVhZGVyCmljbXA6CgkwIGNhbGxzIHRvIGljbXBfZXJyb3IK CTAgZXJyb3JzIG5vdCBnZW5lcmF0ZWQgaW4gcmVzcG9uc2UgdG8gYW4gaWNtcCBtZXNzYWdlCgkw IG1lc3NhZ2VzIHdpdGggYmFkIGNvZGUgZmllbGRzCgkwIG1lc3NhZ2VzIGxlc3MgdGhhbiB0aGUg bWluaW11bSBsZW5ndGgKCTAgbWVzc2FnZXMgd2l0aCBiYWQgY2hlY2tzdW0KCTAgbWVzc2FnZXMg d2l0aCBiYWQgbGVuZ3RoCgkwIG11bHRpY2FzdCBlY2hvIHJlcXVlc3RzIGlnbm9yZWQKCTAgbXVs dGljYXN0IHRpbWVzdGFtcCByZXF1ZXN0cyBpZ25vcmVkCgkwIG1lc3NhZ2UgcmVzcG9uc2VzIGdl bmVyYXRlZAoJMCBpbnZhbGlkIHJldHVybiBhZGRyZXNzZXMKCTAgbm8gcmV0dXJuIHJvdXRlcwpp Z21wOgoJMSBtZXNzYWdlIHJlY2VpdmVkCgkwIG1lc3NhZ2VzIHJlY2VpdmVkIHdpdGggdG9vIGZl dyBieXRlcwoJMCBtZXNzYWdlcyByZWNlaXZlZCB3aXRoIHdyb25nIFRUTAoJMCBtZXNzYWdlcyBy ZWNlaXZlZCB3aXRoIGJhZCBjaGVja3N1bQoJMSBWMS9WMiBtZW1iZXJzaGlwIHF1ZXJ5IHJlY2Vp dmVkCgkwIFYzIG1lbWJlcnNoaXAgcXVlcmllcyByZWNlaXZlZAoJMCBtZW1iZXJzaGlwIHF1ZXJp ZXMgcmVjZWl2ZWQgd2l0aCBpbnZhbGlkIGZpZWxkKHMpCgkxIGdlbmVyYWwgcXVlcnkgcmVjZWl2 ZWQKCTAgZ3JvdXAgcXVlcmllcyByZWNlaXZlZAoJMCBncm91cC1zb3VyY2UgcXVlcmllcyByZWNl aXZlZAoJMCBncm91cC1zb3VyY2UgcXVlcmllcyBkcm9wcGVkCgkwIG1lbWJlcnNoaXAgcmVwb3J0 cyByZWNlaXZlZAoJMCBtZW1iZXJzaGlwIHJlcG9ydHMgcmVjZWl2ZWQgd2l0aCBpbnZhbGlkIGZp ZWxkKHMpCgkwIG1lbWJlcnNoaXAgcmVwb3J0cyByZWNlaXZlZCBmb3IgZ3JvdXBzIHRvIHdoaWNo IHdlIGJlbG9uZwoJMCBWMyByZXBvcnRzIHJlY2VpdmVkIHdpdGhvdXQgUm91dGVyIEFsZXJ0Cgkw IG1lbWJlcnNoaXAgcmVwb3J0cyBzZW50CnBmc3luYzoKCTAgcGFja2V0cyByZWNlaXZlZCAoSVB2 NCkKCTAgcGFja2V0cyByZWNlaXZlZCAoSVB2NikKCQkwIHBhY2tldHMgZGlzY2FyZGVkIGZvciBi YWQgaW50ZXJmYWNlCgkJMCBwYWNrZXRzIGRpc2NhcmRlZCBmb3IgYmFkIHR0bAoJCTAgcGFja2V0 cyBzaG9ydGVyIHRoYW4gaGVhZGVyCgkJMCBwYWNrZXRzIGRpc2NhcmRlZCBmb3IgYmFkIHZlcnNp b24KCQkwIHBhY2tldHMgZGlzY2FyZGVkIGZvciBiYWQgSE1BQwoJCTAgcGFja2V0cyBkaXNjYXJk ZWQgZm9yIGJhZCBhY3Rpb24KCQkwIHBhY2tldHMgZGlzY2FyZGVkIGZvciBzaG9ydCBwYWNrZXQK CQkwIHN0YXRlcyBkaXNjYXJkZWQgZm9yIGJhZCB2YWx1ZXMKCQkwIHN0YWxlIHN0YXRlcwoJCTAg ZmFpbGVkIHN0YXRlIGxvb2t1cC9pbnNlcnRzCgkwIHBhY2tldHMgc2VudCAoSVB2NCkKCTAgcGFj a2V0cyBzZW50IChJUHY2KQoJCTAgc2VuZCBmYWlsZWQgZHVlIHRvIG1idWYgbWVtb3J5IGVycm9y CgkJMCBzZW5kIGVycm9yCmFycDoKCTIgQVJQIHJlcXVlc3RzIHNlbnQKCTAgQVJQIHJlcGxpZXMg c2VudAoJMCBBUlAgcmVxdWVzdHMgcmVjZWl2ZWQKCTEgQVJQIHJlcGx5IHJlY2VpdmVkCgkxIEFS UCBwYWNrZXQgcmVjZWl2ZWQKCTAgdG90YWwgcGFja2V0cyBkcm9wcGVkIGR1ZSB0byBubyBBUlAg ZW50cnkKCTAgQVJQIGVudHJ5cyB0aW1lZCBvdXQKCTAgRHVwbGljYXRlIElQcyBzZWVuCgotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0KbmV0c3RhdCAtbQoKMy81MzUvNTM4IG1idWZzIGluIHVzZSAoY3VycmVudC9j YWNoZS90b3RhbCkKMTg0NDY3NDQwNzM3MDk1NTE2MDMvMjg3LzI3NC8yNTYwMCBtYnVmIGNsdXN0 ZXJzIGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbC9tYXgpCjAvMjY5IG1idWYrY2x1c3RlcnMg b3V0IG9mIHBhY2tldCBzZWNvbmRhcnkgem9uZSBpbiB1c2UgKGN1cnJlbnQvY2FjaGUpCjAvMi8y LzEyODAwIDRrIChwYWdlIHNpemUpIGp1bWJvIGNsdXN0ZXJzIGluIHVzZSAoY3VycmVudC9jYWNo ZS90b3RhbC9tYXgpCjAvMC8wLzE5MjAwIDlrIGp1bWJvIGNsdXN0ZXJzIGluIHVzZSAoY3VycmVu dC9jYWNoZS90b3RhbC9tYXgpCjAvMC8wLzEyODAwIDE2ayBqdW1ibyBjbHVzdGVycyBpbiB1c2Ug KGN1cnJlbnQvY2FjaGUvdG90YWwvbWF4KQoxODAxNDM5ODUwOTQ4MTk1OEsvNzE1Sy82OTBLIGJ5 dGVzIGFsbG9jYXRlZCB0byBuZXR3b3JrIChjdXJyZW50L2NhY2hlL3RvdGFsKQowLzAvMCByZXF1 ZXN0cyBmb3IgbWJ1ZnMgZGVuaWVkIChtYnVmcy9jbHVzdGVycy9tYnVmK2NsdXN0ZXJzKQowLzAv MCByZXF1ZXN0cyBmb3IganVtYm8gY2x1c3RlcnMgZGVuaWVkICg0ay85ay8xNmspCjAgcmVxdWVz dHMgZm9yIHNmYnVmcyBkZW5pZWQKMCByZXF1ZXN0cyBmb3Igc2ZidWZzIGRlbGF5ZWQKMCByZXF1 ZXN0cyBmb3IgSS9PIGluaXRpYXRlZCBieSBzZW5kZmlsZQowIGNhbGxzIHRvIHByb3RvY29sIGRy YWluIHJvdXRpbmVzCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KbmV0c3RhdCAtaWQKCk5hbWUgICAgTXR1IE5l dHdvcmsgICAgICAgQWRkcmVzcyAgICAgICAgICAgICAgSXBrdHMgSWVycnMgSWRyb3AgICAgT3Br dHMgT2VycnMgIENvbGwgRHJvcAp1c2J1cyAgICAgMCA8TGluayMxPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAwICAgICAwICAgICAwICAgICAgICAwICAgICAwICAgICAwICAgIDAgCnVz YnVzICAgICAwIDxMaW5rIzI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgICAgIDAg ICAgIDAgICAgICAgIDAgICAgIDAgICAgIDAgICAgMCAKdXNidXMgICAgIDAgPExpbmsjMz4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgICAgMCAgICAgMCAgICAgICAgMCAgICAgMCAg ICAgMCAgICAwIAp1c2J1cyAgICAgMCA8TGluayM0PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAwICAgICAwICAgICAwICAgICAgICAwICAgICAwICAgICAwICAgIDAgCmFsZTAgICAxNTAw IDxMaW5rIzU+ICAgICAgMDA6MjQ6OGM6NDc6MWM6ZmYgICAgICAgMTIgICAgIDAgICAgIDAgICAg ICAgMTMgICAgIDAgICAgIDAgICAgMCAKYWxlMCAgIDE1MDAgMTkyLjE2OC4xLjAgICAxOTIuMTY4 LjEuMTAwICAgICAgICAgICAgOSAgICAgLSAgICAgLSAgICAgICAxMCAgICAgLSAgICAgLSAgICAt IAp1c2J1cyAgICAgMCA8TGluayM2PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAg ICAwICAgICAwICAgICAgICAwICAgICAwICAgICAwICAgIDAgCnVzYnVzICAgICAwIDxMaW5rIzc+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgICAgIDAgICAgIDAgICAgICAgIDAgICAg IDAgICAgIDAgICAgMCAKdXNidXMgICAgIDAgPExpbmsjOD4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgMCAgICAgMCAgICAgMCAgICAgICAgMCAgICAgMCAgICAgMCAgICAwIAp1c2J1cyAg ICAgMCA8TGluayM5PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAwICAgICAw ICAgICAgICAwICAgICAwICAgICAwICAgIDAgCnJsMCAgICAxNTAwIDxMaW5rIzEwPiAgICAgMDA6 MjQ6MDE6MmY6YTU6OGYgICAgICAgIDAgICAgIDAgICAgIDAgICAgICAgIDAgICAgIDAgICAgIDAg ICAgMCAKcGZzeW4gIDE1MDAgPExpbmsjMTE+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg MCAgICAgMCAgICAgMCAgICAgICAgMCAgICAgMCAgICAgMCAgICAwIApwZmxvZyAzMzE1MiA8TGlu ayMxMj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAwICAgICAwICAgICAgICAw ICAgICAwICAgICAwICAgIDAgCmxvMCAgIDE2Mzg0IDxMaW5rIzEzPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDAgICAgIDAgICAgIDAgICAgICAgIDAgICAgIDAgICAgIDAgICAgMCAKbG8w ICAgMTYzODQgeW91ci1uZXQgICAgICBsb2NhbGhvc3QgICAgICAgICAgICAgICAgMCAgICAgLSAg ICAgLSAgICAgICAgMCAgICAgLSAgICAgLSAgICAtIAp2Ym94biAgMTUwMCA8TGluayMxND4gICAg IDBhOjAwOjI3OjAwOjAwOjAwICAgICAgICAwICAgICAwICAgICAwICAgICAgICAwICAgICAwICAg ICAwICAgIDAgCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KbmV0c3RhdCAtYW5yCgpSb3V0aW5nIHRhYmxlcwoK SW50ZXJuZXQ6CkRlc3RpbmF0aW9uICAgICAgICBHYXRld2F5ICAgICAgICAgICAgRmxhZ3MgICAg UmVmcyAgICAgIFVzZSAgTmV0aWYgRXhwaXJlCmRlZmF1bHQgICAgICAgICAgICAxOTIuMTY4LjEu MSAgICAgICAgVUdTICAgICAgICAgMCAgICAgICAxMCAgIGFsZTAKMTI3LjAuMC4xICAgICAgICAg IGxpbmsjMTMgICAgICAgICAgICBVSCAgICAgICAgICAwICAgICAgICAwICAgIGxvMAoxOTIuMTY4 LjEuMC8yNCAgICAgbGluayM1ICAgICAgICAgICAgIFUgICAgICAgICAgIDAgICAgICAgIDAgICBh bGUwCjE5Mi4xNjguMS4xMDAgICAgICBsaW5rIzUgICAgICAgICAgICAgVUhTICAgICAgICAgMCAg ICAgICAgMCAgICBsbzAKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpuZXRzdGF0IC1hbkEKCkFjdGl2ZSBJbnRl cm5ldCBjb25uZWN0aW9ucyAoaW5jbHVkaW5nIHNlcnZlcnMpClRjcGNiICAgICAgICAgICAgUHJv dG8gUmVjdi1RIFNlbmQtUSBMb2NhbCBBZGRyZXNzICAgICAgRm9yZWlnbiBBZGRyZXNzICAgIChz dGF0ZSkKZmZmZmZlMDA2NmViODNkMCB0Y3A0ICAgICAgIDAgICAgICAwIDEyNy4wLjAuMS4yNSAg ICAgICAqLiogICAgICAgICAgICAgICAgTElTVEVOCmZmZmZmZTAwNjZjOGQ3YTAgdGNwNCAgICAg ICAwICAgICAgMCAqLjIyICAgICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAgIExJU1RFTgpm ZmZmZmUwMDY2YzhlMDAwIHRjcDQgICAgICAgMCAgICAgIDAgKi42MDAwICAgICAgICAgICAgICou KiAgICAgICAgICAgICAgICBMSVNURU4KZmZmZmZlMDAwODY2NTMxMCB1ZHA0ICAgICAgIDAgICAg ICAwICouNTE0ICAgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgCkFjdGl2ZSBVTklYIGRv bWFpbiBzb2NrZXRzCkFkZHJlc3MgIFR5cGUgICBSZWN2LVEgU2VuZC1RICAgIElub2RlICAgICBD b25uICAgICBSZWZzICBOZXh0cmVmIEFkZHIKZmZmZmZlMDAyYjJlZTY5MCBzdHJlYW0gICAgMTIz ICAgICAgMCAgICAgICAgMCBmZmZmZmUwMDJiMmVlNzgwICAgICAgICAwICAgICAgICAwIC92YXIv cnVuL2hhbGQvZGJ1cy1sR1EyMjN3VlNmCmZmZmZmZTAwMmIyZWU3ODAgc3RyZWFtICAgICAgMCAg ICAgIDAgICAgICAgIDAgZmZmZmZlMDAyYjJlZTY5MCAgICAgICAgMCAgICAgICAgMApmZmZmZmUw MDJiMzg3M2MwIHN0cmVhbSAgICAgIDAgICAgICAwIGZmZmZmZTAwMmIyOWQ1YTAgICAgICAgIDAg ICAgICAgIDAgICAgICAgIDAgL3Zhci9ydW4vaGFsZC9kYnVzLWxHUTIyM3dWU2YKZmZmZmZlMDAw ODYzNTFlMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmUwMDA4NjM1MGYwICAg ICAgICAwICAgICAgICAwIC90bXAvZmFtLXJvb3QvZmFtLQpmZmZmZmUwMDA4NjM1MGYwIHN0cmVh bSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZTAwMDg2MzUxZTAgICAgICAgIDAgICAgICAg IDAKZmZmZmZlMDAwODYzNTAwMCBzdHJlYW0gICAgICAwICAgICAgMCBmZmZmZmUwMDJiMzNjM2Mw ICAgICAgICAwICAgICAgICAwICAgICAgICAwIC90bXAvZmFtLXJvb3QvZmFtLQpmZmZmZmUwMDA4 NjM1M2MwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZTAwMDg2MzYwMDAgICAg ICAgIDAgICAgICAgIDAgL3RtcC8uWDExLXVuaXgvWDAKZmZmZmZlMDAwODYzNjAwMCBzdHJlYW0g ICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmUwMDA4NjM1M2MwICAgICAgICAwICAgICAgICAw CmZmZmZmZTAwMDg2MzUyZDAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAw ODYzNTg3MCAgICAgICAgMCAgICAgICAgMCAvdmFyL3J1bi9kYnVzL3N5c3RlbV9idXNfc29ja2V0 CmZmZmZmZTAwMDg1MjkxZTAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAw ODUyOTBmMCAgICAgICAgMCAgICAgICAgMCAvdG1wLy5YMTEtdW5peC9YMApmZmZmZmUwMDA4NjM1 ODcwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZTAwMDg2MzUyZDAgICAgICAg IDAgICAgICAgIDAKZmZmZmZlMDAwODUyOTBmMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAg MCBmZmZmZmUwMDA4NTI5MWUwICAgICAgICAwICAgICAgICAwCmZmZmZmZTAwMDg2MzVlMTAgc3Ry ZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAwODYzNWQyMCAgICAgICAgMCAgICAg ICAgMCAvdmFyL3J1bi9kYnVzL3N5c3RlbV9idXNfc29ja2V0CmZmZmZmZTAwMDg2MzVkMjAgc3Ry ZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAwODYzNWUxMCAgICAgICAgMCAgICAg ICAgMApmZmZmZmUwMDA4NjM2YzMwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZm ZTAwMDg2MzZiNDAgICAgICAgIDAgICAgICAgIDAgL3Zhci9ydW4vZGJ1cy9zeXN0ZW1fYnVzX3Nv Y2tldApmZmZmZmUwMDA4NjM2YjQwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZm ZTAwMDg2MzZjMzAgICAgICAgIDAgICAgICAgIDAKZmZmZmZlMDAwODYzNmE1MCBzdHJlYW0gICAg ICAwICAgICAgMCAgICAgICAgMCBmZmZmZmUwMDA4NjM2OTYwICAgICAgICAwICAgICAgICAwIC92 YXIvcnVuL2RidXMvc3lzdGVtX2J1c19zb2NrZXQKZmZmZmZlMDAwODYzNjk2MCBzdHJlYW0gICAg ICAwICAgICAgMCAgICAgICAgMCBmZmZmZmUwMDA4NjM2YTUwICAgICAgICAwICAgICAgICAwCmZm ZmZmZTAwMDg2MzVjMzAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAwODYz NWI0MCAgICAgICAgMCAgICAgICAgMCAvdmFyL3J1bi9kYnVzL3N5c3RlbV9idXNfc29ja2V0CmZm ZmZmZTAwMDg2MzViNDAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZlMDAwODYz NWMzMCAgICAgICAgMCAgICAgICAgMApmZmZmZmUwMDA4NjM1YTUwIHN0cmVhbSAgICAgIDAgICAg ICAwIGZmZmZmZTAwMmIxM2Q3ODAgICAgICAgIDAgICAgICAgIDAgICAgICAgIDAgL3Zhci9ydW4v aGFsZC9kYnVzLTZHYWlBMXczUkIKZmZmZmZlMDAwODYzNjVhMCBzdHJlYW0gICAgICAwICAgICAg MCAgICAgICAgMCBmZmZmZmUwMDA4NjM2NGIwICAgICAgICAwICAgICAgICAwIC92YXIvcnVuL2Rl dmQucGlwZQpmZmZmZmUwMDA4NjM2NGIwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZm ZmZmZTAwMDg2MzY1YTAgICAgICAgIDAgICAgICAgIDAKZmZmZmZlMDAwODYzNTc4MCBzdHJlYW0g ICAgICAwICAgICAgMCBmZmZmZmUwMDY2YzE2M2MwICAgICAgICAwICAgICAgICAwICAgICAgICAw IC90bXAvLlgxMS11bml4L1gwCmZmZmZmZTAwMDg2MzU2OTAgc3RyZWFtICAgICAgMCAgICAgIDAg ICAgICAgIDAgZmZmZmZlMDAwODYzNTVhMCAgICAgICAgMCAgICAgICAgMApmZmZmZmUwMDA4NjM1 NWEwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZTAwMDg2MzU2OTAgICAgICAg IDAgICAgICAgIDAKZmZmZmZlMDAwODYzNTRiMCBzdHJlYW0gICAgICAwICAgICAgMCBmZmZmZmUw MDY2YzE3NWEwICAgICAgICAwICAgICAgICAwICAgICAgICAwIC92YXIvcnVuL2RidXMvc3lzdGVt X2J1c19zb2NrZXQKZmZmZmZlMDAwODUyOTAwMCBzdHJlYW0gICAgICAwICAgICAgMCBmZmZmZmUw MDA4NjRhZDIwICAgICAgICAwICAgICAgICAwICAgICAgICAwIC92YXIvcnVuL2RldmQucGlwZQpm ZmZmZmUwMDA4NjM2NjkwIGRncmFtICAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZTAwMDg2 MzYwZjAgICAgICAgIDAgZmZmZmZlMDAwODYzNjNjMApmZmZmZmUwMDA4NjM2M2MwIGRncmFtICAg ICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZTAwMDg2MzYwZjAgICAgICAgIDAgICAgICAgIDAK ZmZmZmZlMDAwODYzNTk2MCBkZ3JhbSAgICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmUwMDA4 NjM2MWUwICAgICAgICAwIGZmZmZmZTAwMDg2MzYyZDAKZmZmZmZlMDAwODYzNjJkMCBkZ3JhbSAg ICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmUwMDA4NjM2MWUwICAgICAgICAwICAgICAgICAw CmZmZmZmZTAwMDg2MzYxZTAgZGdyYW0gICAgICAgMCAgICAgIDAgZmZmZmZlMDAwODg4ODNjMCAg ICAgICAgMCBmZmZmZmUwMDA4NjM1OTYwICAgICAgICAwIC92YXIvcnVuL2xvZ3ByaXYKZmZmZmZl MDAwODYzNjBmMCBkZ3JhbSAgICAgICAwICAgICAgMCBmZmZmZmUwMDA4ODg4NWEwICAgICAgICAw IGZmZmZmZTAwMDg2MzY2OTAgICAgICAgIDAgL3Zhci9ydW4vbG9nCgotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K bmV0c3RhdCAtYUwKCkN1cnJlbnQgbGlzdGVuIHF1ZXVlIHNpemVzIChxbGVuL2luY3FsZW4vbWF4 cWxlbikKUHJvdG8gTGlzdGVuICAgICAgICAgTG9jYWwgQWRkcmVzcyAgICAgICAgIAp0Y3A0ICAw LzAvMTAgICAgICAgICBsb2NhbGhvc3Quc210cCAgICAgICAgIAp0Y3A0ICAwLzAvMTI4ICAgICAg ICAqLnNzaCAgICAgICAgICAgICAgICAgIAp0Y3A0ICAwLzAvMTI4ICAgICAgICAqLngxMSAgICAg ICAgICAgICAgICAgIAp1bml4ICAwLzAvMzAgICAgICAgICAvdmFyL3J1bi9oYWxkL2RidXMtbEdR MjIzd1ZTZgp1bml4ICAwLzAvMzAgICAgICAgICAvdG1wL2ZhbS1yb290L2ZhbS0KdW5peCAgMC8w LzMwICAgICAgICAgL3Zhci9ydW4vaGFsZC9kYnVzLTZHYWlBMXczUkIKdW5peCAgMC8wLzEyOCAg ICAgICAgL3RtcC8uWDExLXVuaXgvWDAKdW5peCAgMC8wLzMwICAgICAgICAgL3Zhci9ydW4vZGJ1 cy9zeXN0ZW1fYnVzX3NvY2tldAp1bml4ICAwLzAvNCAgICAgICAgICAvdmFyL3J1bi9kZXZkLnBp cGUKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQpmc3RhdAoKVVNFUiAgICAgQ01EICAgICAgICAgIFBJRCAgIEZE IE1PVU5UICAgICAgSU5VTSBNT0RFICAgICAgICAgU1p8RFYgUi9XCnJvb3QgICAgIGhhbGQtcnVu bmVyICAyMTM2IHJvb3QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1 NTk4Njc0ICByCnJvb3QgICAgIGhhbGQtcnVubmVyICAyMTM2ICAgd2QgLyAgICAgICAgICAgICA0 ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIGhhbGQtcnVubmVy ICAyMTM2IHRleHQgL3VzciAgICAgMTExMDcyNSA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5 ODY3NCAgcgpyb290ICAgICBoYWxkLXJ1bm5lciAgMjEzNiAgICAwIC9kZXYgICAgICAgICAxMiBj cnctcnctcnctICAgIG51bGwgIHIKcm9vdCAgICAgaGFsZC1ydW5uZXIgIDIxMzYgICAgMSAvZGV2 ICAgICAgICAgMTIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIGhhbGQtcnVubmVyICAy MTM2ICAgIDIgL2RldiAgICAgICAgIDEyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBo YWxkLXJ1bm5lciAgMjEzNiAgICAzKiBsb2NhbCBzdHJlYW0gZmZmZmZlMDAyYjJlZTc4MCA8LT4g ZmZmZmZlMDAyYjJlZTY5MApyb290ICAgICBnYW1fc2VydmVyICAyMTM1IHJvb3QgLyAgICAgICAg ICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIGdhbV9z ZXJ2ZXIgIDIxMzUgICB3ZCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1 NzU1OTg2NzQgIHIKcm9vdCAgICAgZ2FtX3NlcnZlciAgMjEzNSB0ZXh0IC91c3IgICAgIDM1Mjgx MCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAgICBnYW1fc2VydmVy ICAyMTM1ICAgIDAgL2RldiAgICAgICAgIDEyIGNydy1ydy1ydy0gICAgbnVsbCAgcgpyb290ICAg ICBnYW1fc2VydmVyICAyMTM1ICAgIDEgL2RldiAgICAgICAgIDEyIGNydy1ydy1ydy0gICAgbnVs bCAgdwpyb290ICAgICBnYW1fc2VydmVyICAyMTM1ICAgIDIgL2RldiAgICAgICAgIDEyIGNydy1y dy1ydy0gICAgbnVsbCAgdwpyb290ICAgICBnYW1fc2VydmVyICAyMTM1ICAgIDQqIGxvY2FsIHN0 cmVhbSBmZmZmZmUwMDA4NjM1MDAwCnJvb3QgICAgIGdhbV9zZXJ2ZXIgIDIxMzUgICAgNSogcGlw ZSBmZmZmZmUwMDA4NjlmMmQ4IDwtPiBmZmZmZmUwMDA4NjlmNDMwICAgICAgMCBydwpyb290ICAg ICBnYW1fc2VydmVyICAyMTM1ICAgIDYqIHBpcGUgZmZmZmZlMDAwODY5ZjQzMCA8LT4gZmZmZmZl MDAwODY5ZjJkOCAgICAgIDAgcncKcm9vdCAgICAgZ2FtX3NlcnZlciAgMjEzNSAgICA3KiBsb2Nh bCBzdHJlYW0gZmZmZmZlMDAwODYzNTFlMCA8LT4gZmZmZmZlMDAwODYzNTBmMApyb290ICAgICBn YW1fc2VydmVyICAyMTM1ICAgIDggL3VzciAgICAgMzMxNjQ5ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0 MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIGdhbV9zZXJ2ZXIgIDIxMzUgICAgOSAvdXNyICAgICA0 MzY1MzYgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAgZ2FtX3Nl cnZlciAgMjEzNSAgIDEwIC91c3IgICAgIDQzNzQwNiA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3 NTU5ODY3NCAgcgpyb290ICAgICBnYW1fc2VydmVyICAyMTM1ICAgMTEgL3VzciAgICAgMzM5Nzg3 ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIGdhbV9zZXJ2ZXIg IDIxMzUgICAxMiAvdmFyICAgICAgMjQ2MTIgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2 NzQgIHIKcm9vdCAgICAgZ2FtX3NlcnZlciAgMjEzNSAgIDEzIC91c3IgICAgIDQzNjU5NiA/LS0t LS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAgICBwb2xraXRkICAgICAyMTMz IHJvb3QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICBy CnJvb3QgICAgIHBvbGtpdGQgICAgIDIxMzMgICB3ZCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0t LSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAgcG9sa2l0ZCAgICAgMjEzMyB0ZXh0 IC91c3IgICAgIDQzNjYxNiA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290 ICAgICBwb2xraXRkICAgICAyMTMzICAgIDAgL2RldiAgICAgICAgIDEyIGNydy1ydy1ydy0gICAg bnVsbCBydwpyb290ICAgICBwb2xraXRkICAgICAyMTMzICAgIDEgL2RldiAgICAgICAgIDEyIGNy dy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBwb2xraXRkICAgICAyMTMzICAgIDIgL2RldiAg ICAgICAgIDEyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBwb2xraXRkICAgICAyMTMz ICAgIDMqIHBpcGUgZmZmZmZlMDAwODNjYjAwMCA8LT4gZmZmZmZlMDAwODNjYjE1OCAgICAgIDAg cncKcm9vdCAgICAgcG9sa2l0ZCAgICAgMjEzMyAgICA0IC9kZXYgICAgICAgICAxMiBjcnctcnct cnctICAgIG51bGwgcncKcm9vdCAgICAgcG9sa2l0ZCAgICAgMjEzMyAgICA1KiBwaXBlIGZmZmZm ZTAwMDgzY2IxNTggPC0+IGZmZmZmZTAwMDgzY2IwMDAgICAgICAwIHJ3CnJvb3QgICAgIHBvbGtp dGQgICAgIDIxMzMgICAgNiAvdXNyICAgICAyOTUxODMgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1 NzU1OTg2NzQgIHIKcm9vdCAgICAgcG9sa2l0ZCAgICAgMjEzMyAgICA3IC91c3IgICAgIDI5NTE5 MSA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAgICBwb2xraXRkICAg ICAyMTMzICAgIDkqIGxvY2FsIHN0cmVhbSBmZmZmZmUwMDA4NjM1ZDIwIDwtPiBmZmZmZmUwMDA4 NjM1ZTEwCnJvb3QgICAgIHBvbGtpdGQgICAgIDIxMzMgICAxMCogcGlwZSBmZmZmZmUwMDA4NDA5 NWIwIDwtPiBmZmZmZmUwMDA4NDA5NzA4ICAgICAgMCBydwpyb290ICAgICBwb2xraXRkICAgICAy MTMzICAgMTEqIHBpcGUgZmZmZmZlMDAwODQwOTcwOCA8LT4gZmZmZmZlMDAwODQwOTViMCAgICAg IDAgcncKcm9vdCAgICAgcG9sa2l0ZCAgICAgMjEzMyAgIDEyKiBwaXBlIGZmZmZmZTAwMDg4Nzg1 YjAgPC0+IGZmZmZmZTAwMDg4Nzg3MDggICAgICAwIHJ3CnJvb3QgICAgIHBvbGtpdGQgICAgIDIx MzMgICAxMyogcGlwZSBmZmZmZmUwMDA4ODc4NzA4IDwtPiBmZmZmZmUwMDA4ODc4NWIwICAgICAg MCBydwpyb290ICAgICBwb2xraXRkICAgICAyMTMzICAgMTQqIGxvY2FsIHN0cmVhbSBmZmZmZmUw MDA4NjM1MGYwIDwtPiBmZmZmZmUwMDA4NjM1MWUwCnJvb3QgICAgIGNvbnNvbGUta2l0LWRhZW1v biAgMjEzMCByb290IC8gICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5 ODY3NCAgcgpyb290ICAgICBjb25zb2xlLWtpdC1kYWVtb24gIDIxMzAgICB3ZCAvICAgICAgICAg ICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAgY29uc29s ZS1raXQtZGFlbW9uICAyMTMwIHRleHQgL3VzciAgICAgNDM3MzcwID8tLS0tLS0tLS0gIDE4NDQ2 NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIGNvbnNvbGUta2l0LWRhZW1vbiAgMjEzMCAgICAw IC9kZXYgICAgICAgICAxMiBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgY29uc29sZS1r aXQtZGFlbW9uICAyMTMwICAgIDEgL2RldiAgICAgICAgIDEyIGNydy1ydy1ydy0gICAgbnVsbCBy dwpyb290ICAgICBjb25zb2xlLWtpdC1kYWVtb24gIDIxMzAgICAgMiAvZGV2ICAgICAgICAgMTIg Y3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIGNvbnNvbGUta2l0LWRhZW1vbiAgMjEzMCAg ICAzKiBwaXBlIGZmZmZmZTAwMDg2OWUwMDAgPC0+IGZmZmZmZTAwMDg2OWUxNTggICAgICAwIHJ3 CnJvb3QgICAgIGNvbnNvbGUta2l0LWRhZW1vbiAgMjEzMCAgICA0IC9kZXYgICAgICAgICAxMiBj cnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgY29uc29sZS1raXQtZGFlbW9uICAyMTMwICAg IDUqIHBpcGUgZmZmZmZlMDAwODY5ZTE1OCA8LT4gZmZmZmZlMDAwODY5ZTAwMCAgICAgIDAgcncK cm9vdCAgICAgY29uc29sZS1raXQtZGFlbW9uICAyMTMwICAgIDYgL3VzciAgICAgMjk1MTgzID8t LS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIGNvbnNvbGUta2l0LWRh ZW1vbiAgMjEzMCAgICA3IC91c3IgICAgIDI5NTE5MSA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3 NTU5ODY3NCAgcgpyb290ICAgICBjb25zb2xlLWtpdC1kYWVtb24gIDIxMzAgICAgOCogcGlwZSBm ZmZmZmUwMDA4NjllYjYwIDwtPiBmZmZmZmUwMDA4NjllY2I4ICAgICAgMCBydwpyb290ICAgICBj b25zb2xlLWtpdC1kYWVtb24gIDIxMzAgICAgOSogcGlwZSBmZmZmZmUwMDA4NjllY2I4IDwtPiBm ZmZmZmUwMDA4NjllYjYwICAgICAgMCBydwpyb290ICAgICBjb25zb2xlLWtpdC1kYWVtb24gIDIx MzAgICAxMCogbG9jYWwgc3RyZWFtIGZmZmZmZTAwMDg2MzY5NjAgPC0+IGZmZmZmZTAwMDg2MzZh NTAKcm9vdCAgICAgY29uc29sZS1raXQtZGFlbW9uICAyMTMwICAgMTEgL3ZhciAgICAgIDI1OTY4 ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICB3CnJvb3QgICAgIGNvbnNvbGUta2l0 LWRhZW1vbiAgMjEzMCAgIDEyKiBsb2NhbCBzdHJlYW0gZmZmZmZlMDAwODYzNmI0MCA8LT4gZmZm ZmZlMDAwODYzNmMzMApyb290ICAgICBjb25zb2xlLWtpdC1kYWVtb24gIDIxMzAgICAxMyAvZGV2 ICAgICAgICAgIDYgY3J3LS0tLS0tLSAgY29uc29sZSAgcgpyb290ICAgICBjb25zb2xlLWtpdC1k YWVtb24gIDIxMzAgICAxNCogcGlwZSBmZmZmZmUwMDA4M2NiNWIwIDwtPiBmZmZmZmUwMDA4M2Ni NzA4ICAgICAgMCBydwpyb290ICAgICBjb25zb2xlLWtpdC1kYWVtb24gIDIxMzAgICAxNSogcGlw ZSBmZmZmZmUwMDA4M2NiNzA4IDwtPiBmZmZmZmUwMDA4M2NiNWIwICAgICAgMCBydwpyb290ICAg ICBjb25zb2xlLWtpdC1kYWVtb24gIDIxMzAgICAxOCogcGlwZSBmZmZmZmUwMDA4ODc4MDAwIDwt PiBmZmZmZmUwMDA4ODc4MTU4ICAgICAgMCBydwpyb290ICAgICBjb25zb2xlLWtpdC1kYWVtb24g IDIxMzAgICAxOSogcGlwZSBmZmZmZmUwMDA4ODc4MTU4IDwtPiBmZmZmZmUwMDA4ODc4MDAwICAg ICAgMCBydwpyb290ICAgICBoYWxkICAgICAgICAyMTI4IHJvb3QgLyAgICAgICAgICAgICA0ID8t LS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIGhhbGQgICAgICAgIDIx MjggICB3ZCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQg IHIKcm9vdCAgICAgaGFsZCAgICAgICAgMjEyOCB0ZXh0IC91c3IgICAgIDExMTA3MjMgPy0tLS0t LS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAgaGFsZCAgICAgICAgMjEyOCAg ICAwIC9kZXYgICAgICAgICAxMiBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgaGFsZCAg ICAgICAgMjEyOCAgICAxIC9kZXYgICAgICAgICAxMiBjcnctcnctcnctICAgIG51bGwgcncKcm9v dCAgICAgaGFsZCAgICAgICAgMjEyOCAgICAyIC9kZXYgICAgICAgICAxMiBjcnctcnctcnctICAg IG51bGwgcncKcm9vdCAgICAgaGFsZCAgICAgICAgMjEyOCAgICAzKiBwaXBlIGZmZmZmZTAwMDg0 MDliNjAgPC0+IGZmZmZmZTAwMDg0MDljYjggICAgICAwIHJ3CnJvb3QgICAgIGhhbGQgICAgICAg IDIxMjggICAgNCogcGlwZSBmZmZmZmUwMDA4NDA5Y2I4IDwtPiBmZmZmZmUwMDA4NDA5YjYwICAg ICAgMCBydwpyb290ICAgICBoYWxkICAgICAgICAyMTI4ICAgIDUqIHBpcGUgZmZmZmZlMDAwODNj Yzg4OCA8LT4gZmZmZmZlMDAwODNjYzllMCAgICAgIDAgcncKcm9vdCAgICAgaGFsZCAgICAgICAg MjEyOCAgICA2KiBwaXBlIGZmZmZmZTAwMDgzY2M5ZTAgPC0+IGZmZmZmZTAwMDgzY2M4ODggICAg ICAwIHJ3CnJvb3QgICAgIGhhbGQgICAgICAgIDIxMjggICAgNyogcGlwZSBmZmZmZmUwMDA4Njlm NWIwIDwtPiBmZmZmZmUwMDA4NjlmNzA4ICAgICAgMCBydwpyb290ICAgICBoYWxkICAgICAgICAy MTI4ICAgIDgqIHBpcGUgZmZmZmZlMDAwODY5ZjcwOCA8LT4gZmZmZmZlMDAwODY5ZjViMCAgICAg IDAgcncKcm9vdCAgICAgaGFsZCAgICAgICAgMjEyOCAgICA5KiBsb2NhbCBzdHJlYW0gZmZmZmZl MDAwODYzNWE1MApyb290ICAgICBoYWxkICAgICAgICAyMTI4ICAgMTAqIGxvY2FsIHN0cmVhbSBm ZmZmZmUwMDA4NjM1YjQwIDwtPiBmZmZmZmUwMDA4NjM1YzMwCnJvb3QgICAgIGhhbGQgICAgICAg IDIxMjggICAxMSogbG9jYWwgc3RyZWFtIGZmZmZmZTAwMmIzODczYzAKcm9vdCAgICAgaGFsZCAg ICAgICAgMjEyOCAgIDEyKiBwaXBlIGZmZmZmZTAwMDg0MDkyZDggPC0+IGZmZmZmZTAwMDg0MDk0 MzAgICAgICAwIHJ3CnJvb3QgICAgIGhhbGQgICAgICAgIDIxMjggICAxMyogcGlwZSBmZmZmZmUw MDA4NDA5NDMwIDwtPiBmZmZmZmUwMDA4NDA5MmQ4ICAgICAgMCBydwpyb290ICAgICBoYWxkICAg ICAgICAyMTI4ICAgMTQqIGxvY2FsIHN0cmVhbSBmZmZmZmUwMDJiMmVlNjkwIDwtPiBmZmZmZmUw MDJiMmVlNzgwCnJvb3QgICAgIGhhbGQgICAgICAgIDIxMjggICAxNiAvZGV2ICAgICAgICAgMTUg Y3J3LXItLXItLSAgICAgcGNpIHJ3CnJvb3QgICAgIGhhbGQgICAgICAgIDIxMjggICAxNyAvZGV2 ICAgICAgICAgNzYgY3J3LXItLXItLSAgdXNiY3RsICByCnJvb3QgICAgIGdldHR5ICAgICAgIDIx MjMgcm9vdCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQg IHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMjEyMyAgIHdkIC8gICAgICAgICAgICAgNCA/LS0tLS0t LS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAgICBnZXR0eSAgICAgICAyMTIzIHRl eHQgL3VzciAgICAgMTEwMDQ0MyA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpy b290ICAgICBnZXR0eSAgICAgICAyMTIzIGN0dHkgL2RldiAgICAgICAgIDY0IGNydy0tLS0tLS0g ICB0dHl2NyBydwpyb290ICAgICBnZXR0eSAgICAgICAyMTIzICAgIDAgL2RldiAgICAgICAgIDY0 IGNydy0tLS0tLS0gICB0dHl2NyBydwpyb290ICAgICBnZXR0eSAgICAgICAyMTIzICAgIDEgL2Rl diAgICAgICAgIDY0IGNydy0tLS0tLS0gICB0dHl2NyBydwpyb290ICAgICBnZXR0eSAgICAgICAy MTIzICAgIDIgL2RldiAgICAgICAgIDY0IGNydy0tLS0tLS0gICB0dHl2NyBydwpyb290ICAgICBn ZXR0eSAgICAgICAyMTIyIHJvb3QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0 MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIGdldHR5ICAgICAgIDIxMjIgICB3ZCAvICAgICAgICAg ICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAgZ2V0dHkg ICAgICAgMjEyMiB0ZXh0IC91c3IgICAgIDExMDA0NDMgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1 NzU1OTg2NzQgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMjEyMiBjdHR5IC9kZXYgICAgICAgICA2 MyBjcnctLS0tLS0tICAgdHR5djYgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMjEyMiAgICAwIC9k ZXYgICAgICAgICA2MyBjcnctLS0tLS0tICAgdHR5djYgcncKcm9vdCAgICAgZ2V0dHkgICAgICAg MjEyMiAgICAxIC9kZXYgICAgICAgICA2MyBjcnctLS0tLS0tICAgdHR5djYgcncKcm9vdCAgICAg Z2V0dHkgICAgICAgMjEyMiAgICAyIC9kZXYgICAgICAgICA2MyBjcnctLS0tLS0tICAgdHR5djYg cncKcm9vdCAgICAgZ2V0dHkgICAgICAgMjEyMSByb290IC8gICAgICAgICAgICAgNCA/LS0tLS0t LS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAgICBnZXR0eSAgICAgICAyMTIxICAg d2QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJv b3QgICAgIGdldHR5ICAgICAgIDIxMjEgdGV4dCAvdXNyICAgICAxMTAwNDQzID8tLS0tLS0tLS0g IDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIGdldHR5ICAgICAgIDIxMjEgY3R0eSAv ZGV2ICAgICAgICAgNjIgY3J3LS0tLS0tLSAgIHR0eXY1IHJ3CnJvb3QgICAgIGdldHR5ICAgICAg IDIxMjEgICAgMCAvZGV2ICAgICAgICAgNjIgY3J3LS0tLS0tLSAgIHR0eXY1IHJ3CnJvb3QgICAg IGdldHR5ICAgICAgIDIxMjEgICAgMSAvZGV2ICAgICAgICAgNjIgY3J3LS0tLS0tLSAgIHR0eXY1 IHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDIxMjEgICAgMiAvZGV2ICAgICAgICAgNjIgY3J3LS0t LS0tLSAgIHR0eXY1IHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDIxMjAgcm9vdCAvICAgICAgICAg ICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAgZ2V0dHkg ICAgICAgMjEyMCAgIHdkIC8gICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3 NTU5ODY3NCAgcgpyb290ICAgICBnZXR0eSAgICAgICAyMTIwIHRleHQgL3VzciAgICAgMTEwMDQ0 MyA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAgICBnZXR0eSAgICAg ICAyMTIwIGN0dHkgL2RldiAgICAgICAgIDYxIGNydy0tLS0tLS0gICB0dHl2NCBydwpyb290ICAg ICBnZXR0eSAgICAgICAyMTIwICAgIDAgL2RldiAgICAgICAgIDYxIGNydy0tLS0tLS0gICB0dHl2 NCBydwpyb290ICAgICBnZXR0eSAgICAgICAyMTIwICAgIDEgL2RldiAgICAgICAgIDYxIGNydy0t LS0tLS0gICB0dHl2NCBydwpyb290ICAgICBnZXR0eSAgICAgICAyMTIwICAgIDIgL2RldiAgICAg ICAgIDYxIGNydy0tLS0tLS0gICB0dHl2NCBydwpyb290ICAgICBnZXR0eSAgICAgICAyMTE5IHJv b3QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJv b3QgICAgIGdldHR5ICAgICAgIDIxMTkgICB3ZCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAg MTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMjExOSB0ZXh0IC91 c3IgICAgIDExMDA0NDMgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAg ICAgZ2V0dHkgICAgICAgMjExOSBjdHR5IC9kZXYgICAgICAgICA2MCBjcnctLS0tLS0tICAgdHR5 djMgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMjExOSAgICAwIC9kZXYgICAgICAgICA2MCBjcnct LS0tLS0tICAgdHR5djMgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMjExOSAgICAxIC9kZXYgICAg ICAgICA2MCBjcnctLS0tLS0tICAgdHR5djMgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMjExOSAg ICAyIC9kZXYgICAgICAgICA2MCBjcnctLS0tLS0tICAgdHR5djMgcncKcm9vdCAgICAgZ2V0dHkg ICAgICAgMjExOCByb290IC8gICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3 NTU5ODY3NCAgcgpyb290ICAgICBnZXR0eSAgICAgICAyMTE4ICAgd2QgLyAgICAgICAgICAgICA0 ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIGdldHR5ICAgICAg IDIxMTggdGV4dCAvdXNyICAgICAxMTAwNDQzID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4 Njc0ICByCnJvb3QgICAgIGdldHR5ICAgICAgIDIxMTggY3R0eSAvZGV2ICAgICAgICAgNTkgY3J3 LS0tLS0tLSAgIHR0eXYyIHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDIxMTggICAgMCAvZGV2ICAg ICAgICAgNTkgY3J3LS0tLS0tLSAgIHR0eXYyIHJ3CnJvb3QgICAgIGdldHR5ICAgICAgIDIxMTgg ICAgMSAvZGV2ICAgICAgICAgNTkgY3J3LS0tLS0tLSAgIHR0eXYyIHJ3CnJvb3QgICAgIGdldHR5 ICAgICAgIDIxMTggICAgMiAvZGV2ICAgICAgICAgNTkgY3J3LS0tLS0tLSAgIHR0eXYyIHJ3CnJv b3QgICAgIGdldHR5ICAgICAgIDIxMTcgcm9vdCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAg MTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMjExNyAgIHdkIC8g ICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAg ICBnZXR0eSAgICAgICAyMTE3IHRleHQgL3VzciAgICAgMTEwMDQ0MyA/LS0tLS0tLS0tICAxODQ0 Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAgICBnZXR0eSAgICAgICAyMTE3IGN0dHkgL2RldiAg ICAgICAgIDU4IGNydy0tLS0tLS0gICB0dHl2MSBydwpyb290ICAgICBnZXR0eSAgICAgICAyMTE3 ICAgIDAgL2RldiAgICAgICAgIDU4IGNydy0tLS0tLS0gICB0dHl2MSBydwpyb290ICAgICBnZXR0 eSAgICAgICAyMTE3ICAgIDEgL2RldiAgICAgICAgIDU4IGNydy0tLS0tLS0gICB0dHl2MSBydwpy b290ICAgICBnZXR0eSAgICAgICAyMTE3ICAgIDIgL2RldiAgICAgICAgIDU4IGNydy0tLS0tLS0g ICB0dHl2MSBydwpyb290ICAgICBnZXR0eSAgICAgICAyMTE2IHJvb3QgLyAgICAgICAgICAgICA0 ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIGdldHR5ICAgICAg IDIxMTYgICB3ZCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2 NzQgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMjExNiB0ZXh0IC91c3IgICAgIDExMDA0NDMgPy0t LS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAgZ2V0dHkgICAgICAgMjEx NiBjdHR5IC9kZXYgICAgICAgICA1NyBjcnctLS0tLS0tICAgdHR5djAgcncKcm9vdCAgICAgZ2V0 dHkgICAgICAgMjExNiAgICAwIC9kZXYgICAgICAgICA1NyBjcnctLS0tLS0tICAgdHR5djAgcncK cm9vdCAgICAgZ2V0dHkgICAgICAgMjExNiAgICAxIC9kZXYgICAgICAgICA1NyBjcnctLS0tLS0t ICAgdHR5djAgcncKcm9vdCAgICAgZ2V0dHkgICAgICAgMjExNiAgICAyIC9kZXYgICAgICAgICA1 NyBjcnctLS0tLS0tICAgdHR5djAgcncKcm9vdCAgICAgc2xlZXAgICAgICAgMjExMyByb290IC8g ICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAg ICBzbGVlcCAgICAgICAyMTEzICAgd2QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2 NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIHNsZWVwICAgICAgIDIxMTMgdGV4dCAvICAgICAg ICAgNTE1MjEgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAgc2xl ZXAgICAgICAgMjExMyAgICAwIC9kZXYgICAgICAgICAxMiBjcnctcnctcnctICAgIG51bGwgIHIK cm9vdCAgICAgc2xlZXAgICAgICAgMjExMyAgICAxKiBwaXBlIGZmZmZmZTAwMDg0MDk5ZTAgPC0+ IGZmZmZmZTAwMDg0MDk4ODggICAgICAwIHJ3CnJvb3QgICAgIHNsZWVwICAgICAgIDIxMTMgICAg MiogcGlwZSBmZmZmZmUwMDA4NDA5OWUwIDwtPiBmZmZmZmUwMDA4NDA5ODg4ICAgICAgMCBydwpy b290ICAgICBsb2dnZXIgICAgICAyMTEyIHJvb3QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0g IDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIGxvZ2dlciAgICAgIDIxMTIgICB3ZCAv ICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAg ICAgbG9nZ2VyICAgICAgMjExMiB0ZXh0IC91c3IgICAgIDExMTQxOTAgPy0tLS0tLS0tLSAgMTg0 NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAgbG9nZ2VyICAgICAgMjExMiAgICAwKiBwaXBl IGZmZmZmZTAwMDg0MDk4ODggPC0+IGZmZmZmZTAwMDg0MDk5ZTAgICAgICAwIHJ3CnJvb3QgICAg IGxvZ2dlciAgICAgIDIxMTIgICAgMiAtICAgICAgICAgLSAgICAgICAgIGJhZCAgICAtCnJvb3Qg ICAgIHNoICAgICAgICAgIDIxMTEgcm9vdCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0 NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAgc2ggICAgICAgICAgMjExMSAgIHdkIC8gICAg ICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAgICBz aCAgICAgICAgICAyMTExIHRleHQgLyAgICAgICAgIDUxNTE5ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0 MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIHNoICAgICAgICAgIDIxMTEgICAgMCAvZGV2ICAgICAg ICAgMTIgY3J3LXJ3LXJ3LSAgICBudWxsICByCnJvb3QgICAgIHNoICAgICAgICAgIDIxMTEgICAg MSogcGlwZSBmZmZmZmUwMDA4NDA5OWUwIDwtPiBmZmZmZmUwMDA4NDA5ODg4ICAgICAgMCBydwpy b290ICAgICBzaCAgICAgICAgICAyMTExICAgIDIqIHBpcGUgZmZmZmZlMDAwODQwOTllMCA8LT4g ZmZmZmZlMDAwODQwOTg4OCAgICAgIDAgcncKcm9vdCAgICAgY3JvbiAgICAgICAgMjA0OSByb290 IC8gICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290 ICAgICBjcm9uICAgICAgICAyMDQ5ICAgd2QgL3ZhciAgICAgICAgICA5ID8tLS0tLS0tLS0gIDE4 NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIGNyb24gICAgICAgIDIwNDkgdGV4dCAvdXNy ICAgICAxMTE0OTIwID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAg IGNyb24gICAgICAgIDIwNDkgICAgMCAvZGV2ICAgICAgICAgMTIgY3J3LXJ3LXJ3LSAgICBudWxs IHJ3CnJvb3QgICAgIGNyb24gICAgICAgIDIwNDkgICAgMSAvZGV2ICAgICAgICAgMTIgY3J3LXJ3 LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIGNyb24gICAgICAgIDIwNDkgICAgMiAvZGV2ICAgICAg ICAgMTIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIGNyb24gICAgICAgIDIwNDkgICAg MyAvdmFyICAgICAgMjQ2MDkgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHcKc21t c3AgICAgc2VuZG1haWwgICAgMjAzOSByb290IC8gICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAx ODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpzbW1zcCAgICBzZW5kbWFpbCAgICAyMDM5ICAgd2QgL3Zh ciAgICAgICAgIDQzID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnNtbXNwICAg IHNlbmRtYWlsICAgIDIwMzkgdGV4dCAvdXNyICAgICAxMTE1NDU1ID8tLS0tLS0tLS0gIDE4NDQ2 NzQ0MDcxNTc1NTk4Njc0ICByCnNtbXNwICAgIHNlbmRtYWlsICAgIDIwMzkgICAgMCAvZGV2ICAg ICAgICAgMTIgY3J3LXJ3LXJ3LSAgICBudWxsICByCnNtbXNwICAgIHNlbmRtYWlsICAgIDIwMzkg ICAgMSAvZGV2ICAgICAgICAgMTIgY3J3LXJ3LXJ3LSAgICBudWxsICB3CnNtbXNwICAgIHNlbmRt YWlsICAgIDIwMzkgICAgMiAvZGV2ICAgICAgICAgMTIgY3J3LXJ3LXJ3LSAgICBudWxsICB3CnNt bXNwICAgIHNlbmRtYWlsICAgIDIwMzkgICAgMyogbG9jYWwgZGdyYW0gZmZmZmZlMDAwODYzNjNj MCA8LT4gZmZmZmZlMDAwODYzNjBmMApzbW1zcCAgICBzZW5kbWFpbCAgICAyMDM5ICAgIDQgL3Zh ciAgICAgIDM2ODkyID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICB3CnJvb3QgICAg IHNlbmRtYWlsICAgIDIwMzIgcm9vdCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3 NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAgc2VuZG1haWwgICAgMjAzMiAgIHdkIC92YXIgICAg ICAgICA0MiA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAgICBzZW5k bWFpbCAgICAyMDMyIHRleHQgL3VzciAgICAgMTExNTQ1NSA/LS0tLS0tLS0tICAxODQ0Njc0NDA3 MTU3NTU5ODY3NCAgcgpyb290ICAgICBzZW5kbWFpbCAgICAyMDMyICAgIDAgL2RldiAgICAgICAg IDEyIGNydy1ydy1ydy0gICAgbnVsbCAgcgpyb290ICAgICBzZW5kbWFpbCAgICAyMDMyICAgIDEg L2RldiAgICAgICAgIDEyIGNydy1ydy1ydy0gICAgbnVsbCAgdwpyb290ICAgICBzZW5kbWFpbCAg ICAyMDMyICAgIDIgL2RldiAgICAgICAgIDEyIGNydy1ydy1ydy0gICAgbnVsbCAgdwpyb290ICAg ICBzZW5kbWFpbCAgICAyMDMyICAgIDMqIGludGVybmV0IHN0cmVhbSB0Y3AgZmZmZmZlMDA2NmVi ODNkMApyb290ICAgICBzZW5kbWFpbCAgICAyMDMyICAgIDQqIGxvY2FsIGRncmFtIGZmZmZmZTAw MDg2MzU5NjAgPC0+IGZmZmZmZTAwMDg2MzYxZTAKcm9vdCAgICAgc2VuZG1haWwgICAgMjAzMiAg ICA1IC92YXIgICAgICAyNDYwOCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgdwpy b290ICAgICBzc2hkICAgICAgICAyMDI1IHJvb3QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0g IDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIHNzaGQgICAgICAgIDIwMjUgICB3ZCAv ICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAg ICAgc3NoZCAgICAgICAgMjAyNSB0ZXh0IC91c3IgICAgIDExMDYxNjAgPy0tLS0tLS0tLSAgMTg0 NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAgc3NoZCAgICAgICAgMjAyNSAgICAwIC9kZXYg ICAgICAgICAxMiBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgc3NoZCAgICAgICAgMjAy NSAgICAxIC9kZXYgICAgICAgICAxMiBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgc3No ZCAgICAgICAgMjAyNSAgICAyIC9kZXYgICAgICAgICAxMiBjcnctcnctcnctICAgIG51bGwgcncK cm9vdCAgICAgc3NoZCAgICAgICAgMjAyNSAgICAzKiBpbnRlcm5ldCBzdHJlYW0gdGNwIGZmZmZm ZTAwNjZjOGQ3YTAKcm9vdCAgICAgcGVybDUuMTQuMSAgMTk5NSByb290IC8gICAgICAgICAgICAg NCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAgICBwZXJsNS4xNC4x ICAxOTk1ICAgd2QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4 Njc0ICByCnJvb3QgICAgIHBlcmw1LjE0LjEgIDE5OTUgdGV4dCAvdXNyICAgICAxMDkyMTIzID8t LS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIHBlcmw1LjE0LjEgIDE5 OTUgICAgMCAvZGV2ICAgICAgICAgMTIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIHBl cmw1LjE0LjEgIDE5OTUgICAgMSAvZGV2ICAgICAgICAgMTIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3 CnJvb3QgICAgIHBlcmw1LjE0LjEgIDE5OTUgICAgMiAvZGV2ICAgICAgICAgMTIgY3J3LXJ3LXJ3 LSAgICBudWxsIHJ3CnJvb3QgICAgIHBlcmw1LjE0LjEgIDE5OTUgICAgMyogbG9jYWwgZGdyYW0g ZmZmZmZlMDAwODYzNjJkMCA8LT4gZmZmZmZlMDAwODYzNjFlMApyb290ICAgICBwZXJsNS4xNC4x ICAxOTk1ICAgIDQgL3ZhciAgICAgIDM0MTY4ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4 Njc0ICByCnJvb3QgICAgIHBlcmwgICAgICAgIDE5ODEgcm9vdCAvICAgICAgICAgICAgIDQgPy0t LS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAgcGVybCAgICAgICAgMTk4 MSAgIHdkIC8gICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAg cgpyb290ICAgICBwZXJsICAgICAgICAxOTgxIHRleHQgL3VzciAgICAgMTA5MjEyMyA/LS0tLS0t LS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAgICBwZXJsICAgICAgICAxOTgxICAg IDAgL2RldiAgICAgICAgIDEyIGNydy1ydy1ydy0gICAgbnVsbCAgcgpyb290ICAgICBwZXJsICAg ICAgICAxOTgxICAgIDEgL2RldiAgICAgICAgIDEyIGNydy1ydy1ydy0gICAgbnVsbCAgdwpyb290 ICAgICBwZXJsICAgICAgICAxOTgxICAgIDIgLSAgICAgICAgIC0gICAgICAgICBiYWQgICAgLQpy b290ICAgICBwZXJsICAgICAgICAxOTgxICAgIDMgL3VzciAgICAgNTM2ODgyID8tLS0tLS0tLS0g IDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIGhhbGQgICAgICAgIDE5NjAgcm9vdCAv ICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAg ICAgaGFsZCAgICAgICAgMTk2MCAgIHdkIC8gICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0 Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAgICBoYWxkICAgICAgICAxOTYwIHRleHQgL3VzciAg ICAgMTExMDcyMyA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAgICBo YWxkICAgICAgICAxOTYwICAgIDAgL2RldiAgICAgICAgIDEyIGNydy1ydy1ydy0gICAgbnVsbCAg cgpyb290ICAgICBoYWxkICAgICAgICAxOTYwICAgIDEgLSAgICAgICAgIC0gICAgICAgICBiYWQg ICAgLQpyb290ICAgICBoYWxkICAgICAgICAxOTYwICAgIDIgLSAgICAgICAgIC0gICAgICAgICBi YWQgICAgLQpyb290ICAgICBoYWxkICAgICAgICAxOTYwICAgIDMqIHBpcGUgZmZmZmZlMDAwODQw OWI2MCA8LT4gZmZmZmZlMDAwODQwOWNiOCAgICAgIDAgcncKcm9vdCAgICAgaGFsZCAgICAgICAg MTk2MCAgICA0KiBwaXBlIGZmZmZmZTAwMDg0MDljYjggPC0+IGZmZmZmZTAwMDg0MDliNjAgICAg ICAwIHJ3CnJvb3QgICAgIGhhbGQgICAgICAgIDE5NjAgICAgNSogcGlwZSBmZmZmZmUwMDA4M2Nj ODg4IDwtPiBmZmZmZmUwMDA4M2NjOWUwICAgICAgMCBydwpyb290ICAgICBoYWxkICAgICAgICAx OTYwICAgIDYqIHBpcGUgZmZmZmZlMDAwODNjYzllMCA8LT4gZmZmZmZlMDAwODNjYzg4OCAgICAg IDAgcncKbWVzc2FnZWIgZGJ1cy1kYWVtb24gIDE5NTMgcm9vdCAvICAgICAgICAgICAgIDQgPy0t LS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKbWVzc2FnZWIgZGJ1cy1kYWVtb24gIDE5 NTMgICB3ZCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQg IHIKbWVzc2FnZWIgZGJ1cy1kYWVtb24gIDE5NTMgdGV4dCAvdXNyICAgICAxMDkzODgxID8tLS0t LS0tLS0gICAgICAgMCAgcgptZXNzYWdlYiBkYnVzLWRhZW1vbiAgMTk1MyAgICAwIC9kZXYgICAg ICAgICAxMiBjcnctcnctcnctICAgIG51bGwgcncKbWVzc2FnZWIgZGJ1cy1kYWVtb24gIDE5NTMg ICAgMSAvZGV2ICAgICAgICAgMTIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3Cm1lc3NhZ2ViIGRidXMt ZGFlbW9uICAxOTUzICAgIDIgL2RldiAgICAgICAgIDEyIGNydy1ydy1ydy0gICAgbnVsbCBydwpt ZXNzYWdlYiBkYnVzLWRhZW1vbiAgMTk1MyAgICAzKiBsb2NhbCBzdHJlYW0gZmZmZmZlMDAwODYz NTRiMAptZXNzYWdlYiBkYnVzLWRhZW1vbiAgMTk1MyAgICA0IC9kZXYgICAgICAgICAxMiBjcnct cnctcnctICAgIG51bGwgcncKbWVzc2FnZWIgZGJ1cy1kYWVtb24gIDE5NTMgICAgNiAvdXNyICAg ICAyOTUxODMgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKbWVzc2FnZWIgZGJ1 cy1kYWVtb24gIDE5NTMgICAgNyAvdXNyICAgICAyOTUxOTEgPy0tLS0tLS0tLSAgMTg0NDY3NDQw NzE1NzU1OTg2NzQgIHIKbWVzc2FnZWIgZGJ1cy1kYWVtb24gIDE5NTMgICAgOCogbG9jYWwgc3Ry ZWFtIGZmZmZmZTAwMDg2MzU1YTAgPC0+IGZmZmZmZTAwMDg2MzU2OTAKbWVzc2FnZWIgZGJ1cy1k YWVtb24gIDE5NTMgICAgOSogbG9jYWwgc3RyZWFtIGZmZmZmZTAwMDg2MzU2OTAgPC0+IGZmZmZm ZTAwMDg2MzU1YTAKbWVzc2FnZWIgZGJ1cy1kYWVtb24gIDE5NTMgICAxMCogbG9jYWwgc3RyZWFt IGZmZmZmZTAwMDg2MzVjMzAgPC0+IGZmZmZmZTAwMDg2MzViNDAKbWVzc2FnZWIgZGJ1cy1kYWVt b24gIDE5NTMgICAxMSogbG9jYWwgZGdyYW0gZmZmZmZlMDAwODYzNjY5MCA8LT4gZmZmZmZlMDAw ODYzNjBmMAptZXNzYWdlYiBkYnVzLWRhZW1vbiAgMTk1MyAgIDEzKiBsb2NhbCBzdHJlYW0gZmZm ZmZlMDAwODYzNmE1MCA8LT4gZmZmZmZlMDAwODYzNjk2MAptZXNzYWdlYiBkYnVzLWRhZW1vbiAg MTk1MyAgIDE1KiBsb2NhbCBzdHJlYW0gZmZmZmZlMDAwODYzNmMzMCA8LT4gZmZmZmZlMDAwODYz NmI0MAptZXNzYWdlYiBkYnVzLWRhZW1vbiAgMTk1MyAgIDE3KiBsb2NhbCBzdHJlYW0gZmZmZmZl MDAwODYzNWUxMCA8LT4gZmZmZmZlMDAwODYzNWQyMAptZXNzYWdlYiBkYnVzLWRhZW1vbiAgMTk1 MyAgIDE5KiBsb2NhbCBzdHJlYW0gZmZmZmZlMDAwODYzNTJkMCA8LT4gZmZmZmZlMDAwODYzNTg3 MApyb290ICAgICBYb3JnICAgICAgICAxOTUyIHJvb3QgLyAgICAgICAgICAgICA0ID8tLS0tLS0t LS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIFhvcmcgICAgICAgIDE5NTIgICB3 ZCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9v dCAgICAgWG9yZyAgICAgICAgMTk1MiB0ZXh0IC91c3IgICAgIDU0MjUxNSA/LS0tLS0tLS0tICAx ODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAgICBYb3JnICAgICAgICAxOTUyICAgIDAgL3Zh ciAgICAgIDI0NjA1ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICB3CnJvb3QgICAg IFhvcmcgICAgICAgIDE5NTIgICAgMSogaW50ZXJuZXQgc3RyZWFtIHRjcCBmZmZmZmUwMDY2Yzhl MDAwCnJvb3QgICAgIFhvcmcgICAgICAgIDE5NTIgICAgMiAvdmFyICAgICAgNDA5NzkgPy0tLS0t LS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHcKcm9vdCAgICAgWG9yZyAgICAgICAgMTk1MiAg ICAzKiBsb2NhbCBzdHJlYW0gZmZmZmZlMDAwODYzNTc4MApyb290ICAgICBYb3JnICAgICAgICAx OTUyICAgIDQgL3VzciAgICAgNTQyMzQ4ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0 ICByCnJvb3QgICAgIFhvcmcgICAgICAgIDE5NTIgICAgNSAvZGV2ICAgICAgICAgNjUgY3J3LS0t LS0tLSAgIHR0eXY4IHJ3CnJvb3QgICAgIFhvcmcgICAgICAgIDE5NTIgICAgNiAvZGV2ICAgICAg ICAgMTUgY3J3LXItLXItLSAgICAgcGNpIHJ3CnJvb3QgICAgIFhvcmcgICAgICAgIDE5NTIgICAg NyAvZGV2ICAgICAgICAgIDcgY3J3LXItLS0tLSAgICAgbWVtIHJ3CnJvb3QgICAgIFhvcmcgICAg ICAgIDE5NTIgICAgOCAvZGV2ICAgICAgICAgMTYgY3J3LS0tLS0tLSAgICAgIGlvIHJ3CnJvb3Qg ICAgIFhvcmcgICAgICAgIDE5NTIgICAgOSAvZGV2ICAgICAgICAgMzYgY3J3LXJ3LXJ3LSAgbnZp ZGlhY3RsIHJ3CnJvb3QgICAgIFhvcmcgICAgICAgIDE5NTIgICAxMCAvZGV2ICAgICAgICAgMzUg Y3J3LXJ3LXJ3LSAgbnZpZGlhMCBydwpyb290ICAgICBYb3JnICAgICAgICAxOTUyICAgMTEgL2Rl diAgICAgICAgIDM1IGNydy1ydy1ydy0gIG52aWRpYTAgcncKcm9vdCAgICAgWG9yZyAgICAgICAg MTk1MiAgIDEyIC9kZXYgICAgICAgICAzNSBjcnctcnctcnctICBudmlkaWEwIHJ3CnJvb3QgICAg IFhvcmcgICAgICAgIDE5NTIgICAxMyAvZGV2ICAgICAgICAgMzUgY3J3LXJ3LXJ3LSAgbnZpZGlh MCBydwpyb290ICAgICBYb3JnICAgICAgICAxOTUyICAgMTQgL2RldiAgICAgICAgIDM1IGNydy1y dy1ydy0gIG52aWRpYTAgcncKcm9vdCAgICAgWG9yZyAgICAgICAgMTk1MiAgIDE1IC9kZXYgICAg ICAgICAzNSBjcnctcnctcnctICBudmlkaWEwIHJ3CnJvb3QgICAgIFhvcmcgICAgICAgIDE5NTIg ICAxNiAvZGV2ICAgICAgICAgMzUgY3J3LXJ3LXJ3LSAgbnZpZGlhMCBydwpyb290ICAgICBYb3Jn ICAgICAgICAxOTUyICAgMTcgL2RldiAgICAgICAgIDM1IGNydy1ydy1ydy0gIG52aWRpYTAgcncK cm9vdCAgICAgWG9yZyAgICAgICAgMTk1MiAgIDE4KiBsb2NhbCBzdHJlYW0gZmZmZmZlMDAwODYz NjRiMCA8LT4gZmZmZmZlMDAwODYzNjVhMApyb290ICAgICBYb3JnICAgICAgICAxOTUyICAgMTkg L2RldiAgICAgICAgIDM1IGNydy1ydy1ydy0gIG52aWRpYTAgcncKcm9vdCAgICAgWG9yZyAgICAg ICAgMTk1MiAgIDIwIC9kZXYgICAgICAgICAzNSBjcnctcnctcnctICBudmlkaWEwIHJ3CnJvb3Qg ICAgIFhvcmcgICAgICAgIDE5NTIgICAyMSAvZGV2ICAgICAgICAgMzUgY3J3LXJ3LXJ3LSAgbnZp ZGlhMCBydwpyb290ICAgICBYb3JnICAgICAgICAxOTUyICAgMjIgL2RldiAgICAgICAgIDM2IGNy dy1ydy1ydy0gIG52aWRpYWN0bCBydwpyb290ICAgICBYb3JnICAgICAgICAxOTUyICAgMjMgL2Rl diAgICAgICAgIDM1IGNydy1ydy1ydy0gIG52aWRpYTAgcncKcm9vdCAgICAgWG9yZyAgICAgICAg MTk1MiAgIDI0IC9kZXYgICAgICAgICAzNSBjcnctcnctcnctICBudmlkaWEwIHJ3CnJvb3QgICAg IFhvcmcgICAgICAgIDE5NTIgICAyNSogbG9jYWwgc3RyZWFtIGZmZmZmZTAwMDg2MzU4NzAgPC0+ IGZmZmZmZTAwMDg2MzUyZDAKcm9vdCAgICAgWG9yZyAgICAgICAgMTk1MiAgIDI2KiBsb2NhbCBz dHJlYW0gZmZmZmZlMDAwODUyOTFlMCA8LT4gZmZmZmZlMDAwODUyOTBmMApyb290ICAgICBYb3Jn ICAgICAgICAxOTUyICAgMjcqIGxvY2FsIHN0cmVhbSBmZmZmZmUwMDA4NjM1M2MwIDwtPiBmZmZm ZmUwMDA4NjM2MDAwCnJvb3QgICAgIHNsaW0gICAgICAgIDE5Mzggcm9vdCAvICAgICAgICAgICAg IDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAgc2xpbSAgICAg ICAgMTkzOCAgIHdkIC8gICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5 ODY3NCAgcgpyb290ICAgICBzbGltICAgICAgICAxOTM4IHRleHQgL3VzciAgICAgNTQ4MDc2ID8t LS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIHNsaW0gICAgICAgIDE5 MzggICAgMCAtICAgICAgICAgLSAgICAgICAgIGJhZCAgICAtCnJvb3QgICAgIHNsaW0gICAgICAg IDE5MzggICAgMSAvdmFyICAgICAgNDA5NzkgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2 NzQgIHcKcm9vdCAgICAgc2xpbSAgICAgICAgMTkzOCAgICAyIC92YXIgICAgICA0MDk3OSA/LS0t LS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgdwpyb290ICAgICBzbGltICAgICAgICAxOTM4 ICAgIDMqIGxvY2FsIHN0cmVhbSBmZmZmZmUwMDA4NTI5MGYwIDwtPiBmZmZmZmUwMDA4NTI5MWUw CnJvb3QgICAgIHNsaW0gICAgICAgIDE5MzggICAgNCogbG9jYWwgc3RyZWFtIGZmZmZmZTAwMDg2 MzYwMDAgPC0+IGZmZmZmZTAwMDg2MzUzYzAKcm9vdCAgICAgc3lzbG9nZCAgICAgMTY1MSByb290 IC8gICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290 ICAgICBzeXNsb2dkICAgICAxNjUxICAgd2QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4 NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIHN5c2xvZ2QgICAgIDE2NTEgdGV4dCAvdXNy ICAgICAxMTE1NDkzID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAg IHN5c2xvZ2QgICAgIDE2NTEgICAgMCAvZGV2ICAgICAgICAgMTIgY3J3LXJ3LXJ3LSAgICBudWxs IHJ3CnJvb3QgICAgIHN5c2xvZ2QgICAgIDE2NTEgICAgMSAvZGV2ICAgICAgICAgMTIgY3J3LXJ3 LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIHN5c2xvZ2QgICAgIDE2NTEgICAgMiAvZGV2ICAgICAg ICAgMTIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIHN5c2xvZ2QgICAgIDE2NTEgICAg MyAvdmFyICAgICAgMjQ1OTEgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHcKcm9v dCAgICAgc3lzbG9nZCAgICAgMTY1MSAgICA0KiBsb2NhbCBkZ3JhbSBmZmZmZmUwMDA4NjM2MGYw CnJvb3QgICAgIHN5c2xvZ2QgICAgIDE2NTEgICAgNSogbG9jYWwgZGdyYW0gZmZmZmZlMDAwODYz NjFlMApyb290ICAgICBzeXNsb2dkICAgICAxNjUxICAgIDYqIGludGVybmV0IGRncmFtIHVkcCBm ZmZmZmUwMDA4NjY1MzEwCnJvb3QgICAgIHN5c2xvZ2QgICAgIDE2NTEgICAgNyAvZGV2ICAgICAg ICAgMTAgY3J3LS0tLS0tLSAgICBrbG9nICByCnJvb3QgICAgIHN5c2xvZ2QgICAgIDE2NTEgICAg OSAtICAgICAgICAgLSAgICAgICAgIGJhZCAgICAtCnJvb3QgICAgIHN5c2xvZ2QgICAgIDE2NTEg ICAxMCAvdmFyICAgICAgNTUwNTAgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHcK cm9vdCAgICAgc3lzbG9nZCAgICAgMTY1MSAgIDExIC92YXIgICAgICAgICA5MCA/LS0tLS0tLS0t ICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgdwpyb290ICAgICBzeXNsb2dkICAgICAxNjUxICAgMTIg L3ZhciAgICAgIDM0MTY4ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICB3CnJvb3Qg ICAgIHN5c2xvZ2QgICAgIDE2NTEgICAxMyAvdmFyICAgICAgMzMwMzYgPy0tLS0tLS0tLSAgMTg0 NDY3NDQwNzE1NzU1OTg2NzQgIHcKcm9vdCAgICAgc3lzbG9nZCAgICAgMTY1MSAgIDE0IC92YXIg ICAgICAgICA4NiA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgdwpyb290ICAgICBz eXNsb2dkICAgICAxNjUxICAgMTUgL3ZhciAgICAgICAgIDkxID8tLS0tLS0tLS0gIDE4NDQ2NzQ0 MDcxNTc1NTk4Njc0ICB3CnJvb3QgICAgIHN5c2xvZ2QgICAgIDE2NTEgICAxNiAvdmFyICAgICAg NTYxNjIgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHcKcm9vdCAgICAgc3lzbG9n ZCAgICAgMTY1MSAgIDE3IC92YXIgICAgICAgICA4NSA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3 NTU5ODY3NCAgdwpyb290ICAgICBzeXNsb2dkICAgICAxNjUxICAgMTggL3ZhciAgICAgICAgIDg5 ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICB3Cl9kaGNwICAgIGRoY2xpZW50ICAg IDE1MjQgcm9vdCAvdmFyICAgICAgICAgMjggPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2 NzQgIHIKX2RoY3AgICAgZGhjbGllbnQgICAgMTUyNCAgIHdkIC92YXIgICAgICAgICAyOCA/LS0t LS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpfZGhjcCAgICBkaGNsaWVudCAgICAxNTI0 IGphaWwgL3ZhciAgICAgICAgIDI4ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICBy Cl9kaGNwICAgIGRoY2xpZW50ICAgIDE1MjQgdGV4dCAvICAgICAgICAgNTE1ODcgPy0tLS0tLS0t LSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKX2RoY3AgICAgZGhjbGllbnQgICAgMTUyNCAgICAw IC9kZXYgICAgICAgICAxMiBjcnctcnctcnctICAgIG51bGwgcncKX2RoY3AgICAgZGhjbGllbnQg ICAgMTUyNCAgICAxIC9kZXYgICAgICAgICAxMiBjcnctcnctcnctICAgIG51bGwgcncKX2RoY3Ag ICAgZGhjbGllbnQgICAgMTUyNCAgICAyIC9kZXYgICAgICAgICAxMiBjcnctcnctcnctICAgIG51 bGwgcncKX2RoY3AgICAgZGhjbGllbnQgICAgMTUyNCAgICA0KiByb3V0ZSByYXcgMCBmZmZmZmUw MDA4NTgwZDQ4Cl9kaGNwICAgIGRoY2xpZW50ICAgIDE1MjQgICAgNSogcGlwZSBmZmZmZmUwMDA4 M2NjMTU4IDwtPiBmZmZmZmUwMDA4M2NjMDAwICAgICAgMCBydwpfZGhjcCAgICBkaGNsaWVudCAg ICAxNTI0ICAgIDYgL3ZhciAgICAgICAgIDk2ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4 Njc0ICB3Cl9kaGNwICAgIGRoY2xpZW50ICAgIDE1MjQgICAgNyAvZGV2ICAgICAgICAgMjEgY3J3 LS0tLS0tLSAgICAgYnBmIHJ3Cl9kaGNwICAgIGRoY2xpZW50ICAgIDE1MjQgICAgOCogaW50ZXJu ZXQgcmF3IGlwIGZmZmZmZTAwMDg4MjcwMDAKcm9vdCAgICAgZGhjbGllbnQgICAgMTQ4NiByb290 IC8gICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290 ICAgICBkaGNsaWVudCAgICAxNDg2ICAgd2QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4 NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIGRoY2xpZW50ICAgIDE0ODYgdGV4dCAvICAg ICAgICAgNTE1ODcgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAg ZGhjbGllbnQgICAgMTQ4NiAgICAwIC9kZXYgICAgICAgICAxMiBjcnctcnctcnctICAgIG51bGwg cncKcm9vdCAgICAgZGhjbGllbnQgICAgMTQ4NiAgICAxIC9kZXYgICAgICAgICAxMiBjcnctcnct cnctICAgIG51bGwgcncKcm9vdCAgICAgZGhjbGllbnQgICAgMTQ4NiAgICAyIC9kZXYgICAgICAg ICAxMiBjcnctcnctcnctICAgIG51bGwgcncKcm9vdCAgICAgZGhjbGllbnQgICAgMTQ4NiAgICA0 KiBwaXBlIGZmZmZmZTAwMDgzY2MwMDAgPC0+IGZmZmZmZTAwMDgzY2MxNTggICAgICAwIHJ3CnJv b3QgICAgIGRldmQgICAgICAgIDEzMzYgcm9vdCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAg MTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAgZGV2ZCAgICAgICAgMTMzNiAgIHdkIC8g ICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAg ICBkZXZkICAgICAgICAxMzM2IHRleHQgLyAgICAgICAgIDUxNTgzID8tLS0tLS0tLS0gIDE4NDQ2 NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIGRldmQgICAgICAgIDEzMzYgICAgMCAvZGV2ICAg ICAgICAgMTIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIGRldmQgICAgICAgIDEzMzYg ICAgMSAvZGV2ICAgICAgICAgMTIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJvb3QgICAgIGRldmQg ICAgICAgIDEzMzYgICAgMiAvZGV2ICAgICAgICAgMTIgY3J3LXJ3LXJ3LSAgICBudWxsIHJ3CnJv b3QgICAgIGRldmQgICAgICAgIDEzMzYgICAgMyAvZGV2ICAgICAgICAgIDUgY3J3LS0tLS0tLSAg ZGV2Y3RsICByCnJvb3QgICAgIGRldmQgICAgICAgIDEzMzYgICAgNCogbG9jYWwgc3RyZWFtIGZm ZmZmZTAwMDg1MjkwMDAKcm9vdCAgICAgZGV2ZCAgICAgICAgMTMzNiAgICA1IC92YXIgICAgICAy NDU4NSA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgdwpyb290ICAgICBkZXZkICAg ICAgICAxMzM2ICAgIDYqIGxvY2FsIHN0cmVhbSBmZmZmZmUwMDA4NjM2NWEwIDwtPiBmZmZmZmUw MDA4NjM2NGIwCnJvb3QgICAgIG1vdXNlZCAgICAgIDEzMTkgcm9vdCAvICAgICAgICAgICAgIDQg Py0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAgbW91c2VkICAgICAg MTMxOSAgIHdkIC8gICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3 NCAgcgpyb290ICAgICBtb3VzZWQgICAgICAxMzE5IHRleHQgL3VzciAgICAgMTExNTEzNyA/LS0t LS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAgICBtb3VzZWQgICAgICAxMzE5 ICAgIDAgL2RldiAgICAgICAgIDEyIGNydy1ydy1ydy0gICAgbnVsbCBydwpyb290ICAgICBtb3Vz ZWQgICAgICAxMzE5ICAgIDEgL2RldiAgICAgICAgIDEyIGNydy1ydy1ydy0gICAgbnVsbCBydwpy b290ICAgICBtb3VzZWQgICAgICAxMzE5ICAgIDIgL2RldiAgICAgICAgIDEyIGNydy1ydy1ydy0g ICAgbnVsbCBydwpyb290ICAgICBtb3VzZWQgICAgICAxMzE5ICAgIDMgL2RldiAgICAgICAgMTQy IGNydy1yLS1yLS0gICAgdW1zMCBydwpyb290ICAgICBtb3VzZWQgICAgICAxMzE5ICAgIDQgL2Rl diAgICAgICAgIDczIGNydy0tLS0tLS0gIGNvbnNvbGVjdGwgcncKcm9vdCAgICAgbW91c2VkICAg ICAgMTMxOSAgICA1IC92YXIgICAgICAyNDU4NCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5 ODY3NCAgdwpyb290ICAgICBuZ19xdWV1ZSAgICAgMTQxIHJvb3QgLyAgICAgICAgICAgICA0ID8t LS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIG5nX3F1ZXVlICAgICAx NDEgICB3ZCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQg IHIKcm9vdCAgICAgVElNRVIgICAgICAgIDE0MCByb290IC8gICAgICAgICAgICAgNCA/LS0tLS0t LS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAgICBUSU1FUiAgICAgICAgMTQwICAg d2QgLyAgICAgICAgICAgICA0ID8tLS0tLS0tLS0gIDE4NDQ2NzQ0MDcxNTc1NTk4Njc0ICByCnJv b3QgICAgIGluaXQgICAgICAgICAgIDEgcm9vdCAvICAgICAgICAgICAgIDQgPy0tLS0tLS0tLSAg MTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAgaW5pdCAgICAgICAgICAgMSAgIHdkIC8g ICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3MTU3NTU5ODY3NCAgcgpyb290ICAg ICBpbml0ICAgICAgICAgICAxIHRleHQgLyAgICAgICAgIDUxNjY0ID8tLS0tLS0tLS0gIDE4NDQ2 NzQ0MDcxNTc1NTk4Njc0ICByCnJvb3QgICAgIGtlcm5lbCAgICAgICAgIDAgcm9vdCAvICAgICAg ICAgICAgIDQgPy0tLS0tLS0tLSAgMTg0NDY3NDQwNzE1NzU1OTg2NzQgIHIKcm9vdCAgICAga2Vy bmVsICAgICAgICAgMCAgIHdkIC8gICAgICAgICAgICAgNCA/LS0tLS0tLS0tICAxODQ0Njc0NDA3 MTU3NTU5ODY3NCAgcgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCmRtZXNnCgplbGV0aW5nCiAqKiogVGVtcCAu L2V0Yy9kZXZmcy5jb25mIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0 aW5nCiAqKiogVGVtcCAuL2V0Yy9kaGNsaWVudC5jb25mIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUg c2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9kaXNrdGFiIGFuZCBpbnN0YWxs ZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9mYnRhYiBh bmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9l dGMvZnRwdXNlcnMgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcK ICoqKiBUZW1wIC4vZXRjL2dldHR5dGFiIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMg SWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9nbmF0cy9mcmVlZmFsbCBhbmQgaW5zdGFsbGVk IGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvZ3JvdXAgYW5k IGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRj L2dzcy9tZWNoIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAq KiogVGVtcCAuL2V0Yy9nc3MvcW9wIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQs IGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9ob3N0cyBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNh bWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvaG9zdHMuYWxsb3cgYW5kIGluc3Rh bGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL2hvc3Rz LmVxdWl2IGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiog VGVtcCAuL2V0Yy9ob3N0cy5scGQgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwg ZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL2luZXRkLmNvbmYgYW5kIGluc3RhbGxlZCBoYXZlIHRo ZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL2xpYmFsaWFzLmNvbmYgYW5k IGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRj L2xvY2F0ZS5yYyBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwog KioqIFRlbXAgLi9ldGMvbG9naW4uYWNjZXNzIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBD VlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9sb2dpbi5jb25mIGFuZCBpbnN0YWxsZWQg aGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9tYWMuY29uZiBh bmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9l dGMvbWFpbC5yYyBhbmQgaW5zdGFsbGVkIGFyZSB0aGUgc2FtZSwgZGVsZXRpbmcKICoqKiBUZW1w IC4vZXRjL21haWwvTWFrZWZpbGUgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwg ZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL21haWwvUkVBRE1FIGFuZCBpbnN0YWxsZWQgaGF2ZSB0 aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9tYWlsL2FjY2Vzcy5zYW1w bGUgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1w IC4vZXRjL21haWwvYWxpYXNlcyBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBk ZWxldGluZwogKioqIFRlbXAgLi9ldGMvbWFpbC9mcmVlYnNkLmNmIGFuZCBpbnN0YWxsZWQgaGF2 ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9tYWlsL2ZyZWVic2Qu bWMgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1w IC4vZXRjL21haWwvZnJlZWJzZC5zdWJtaXQuY2YgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1l IENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL21haWwvZnJlZWJzZC5zdWJtaXQubWMg YW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4v ZXRjL21haWwvaGVscGZpbGUgYW5kIGluc3RhbGxlZCBhcmUgdGhlIHNhbWUsIGRlbGV0aW5nCiAq KiogVGVtcCAuL2V0Yy9tYWlsL21haWxlci5jb25mIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2Ft ZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9tYWlsL21haWxlcnRhYmxlLnNhbXBs ZSBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAg Li9ldGMvbWFpbC9zZW5kbWFpbC5jZiBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElk LCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvbWFpbC9zdWJtaXQuY2YgYW5kIGluc3RhbGxlZCBo YXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL21haWwvdmlydHVz ZXJ0YWJsZS5zYW1wbGUgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRp bmcKICoqKiBUZW1wIC4vZXRjL21hc3Rlci5wYXNzd2QgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBz YW1lIENWUyBJZCwgZGVsZXRpbmcKCiAgID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0gICAKCjwxMTg+ICAqKiogRGlz cGxheWluZyBkaWZmZXJlbmNlcyBiZXR3ZWVuIC4vZXRjL21vdGQgYW5kIGluc3RhbGxlZCB2ZXJz aW9uOgoKLS0tIC9ldGMvbW90ZCAgIDIwMTEtMDktMTYgMjI6MTk6MDIuMTk0ODYyNzA3ICswMjAw CisrKyAuL2V0Yy9tb3RkICAyMDExLTA5LTE2IDIyOjI4OjAyLjMzNDM2MjI5MCArMDIwMApAQCAt MSw0ICsxLDQgQEAKLUZyZWVCU0QgOS4wLUJFVEEyIChCRUFTVElFKSAjNjogRnJpIFNlcCAxNiAw MDozNTo0MyBDRVNUIDIwMTEKK0ZyZWVCU0QgPy4/Lj8gIChVTktOT1dOKQogCiBXZWxjb21lIHRv IEZyZWVCU0QhCiAKPDExOD4KICBVc2UgJ2QnIHRvIGRlbGV0ZSB0aGUgdGVtcG9yYXJ5IC4vZXRj L21vdGQKICBVc2UgJ2knIHRvIGluc3RhbGwgdGhlIHRlbXBvcmFyeSAuL2V0Yy9tb3RkCiAgVXNl ICdtJyB0byBtZXJnZSB0aGUgdGVtcG9yYXJ5IGFuZCBpbnN0YWxsZWQgdmVyc2lvbnMKICBVc2Ug J3YnIHRvIHZpZXcgdGhlIGRpZmYgcmVzdWx0cyBhZ2FpbgoKICBEZWZhdWx0IGlzIHRvIGxlYXZl IHRoZSB0ZW1wb3JhcnkgZmlsZSB0byBkZWFsIHdpdGggYnkgaGFuZAoKSG93IHNob3VsZCBJIGRl YWwgd2l0aCB0aGlzPyBbTGVhdmUgaXQgZm9yIGxhdGVyXSAKICAgKioqIC4vZXRjL21vdGQgaW5z dGFsbGVkIHN1Y2Nlc3NmdWxseQoKICoqKiBUZW1wIC4vZXRjL210cmVlL0JTRC5pbmNsdWRlLmRp c3QgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1w IC4vZXRjL210cmVlL0JTRC5yb290LmRpc3QgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENW UyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL210cmVlL0JTRC5zZW5kbWFpbC5kaXN0IGFu ZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0 Yy9tdHJlZS9CU0QudXNyLmRpc3QgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwg ZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL210cmVlL0JTRC52YXIuZGlzdCBhbmQgaW5zdGFsbGVk IGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvbmV0Y29uZmln IGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAu L2V0Yy9uZXRzdGFydCBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGlu ZwoKICAgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PSAgIAoKPDExOD4gICoqKiBEaXNwbGF5aW5nIGRpZmZlcmVuY2Vz IGJldHdlZW4gLi9ldGMvbmV0d29yay5zdWJyIGFuZCBpbnN0YWxsZWQgdmVyc2lvbjoKCi0tLSAv ZXRjL25ldHdvcmsuc3ViciAgIDIwMTEtMDgtMTEgMDA6Mjc6NDAuNjI1OTk2MDYxICswMjAwCisr KyAuL2V0Yy9uZXR3b3JrLnN1YnIgIDIwMTEtMDktMTYgMjI6Mjg6MDIuMzM0MzYyMjkwICswMjAw CkBAIC0yMiw3ICsyMiw3IEBACiAjIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVW RU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKICMgU1VDSCBEQU1BR0UuCiAjCi0j ICRGcmVlQlNEOiBzcmMvZXRjL25ldHdvcmsuc3Vicix2IDEuMjIxIDIwMTEvMDYvMjQgMTQ6NTY6 MzggcGx1a25ldCBFeHAgJAorIyAkRnJlZUJTRDogc3JjL2V0Yy9uZXR3b3JrLnN1YnIsdiAxLjIy NCAyMDExLzA5LzE0IDIwOjEzOjEwIGJydWVmZmVyIEV4cCAkCiAjCiAKICMKQEAgLTMyLDcgKzMy LDcgQEAKIAogIyBpZm5fc3RhcnQgaWZuCiAjICAgICAgQnJpbmcgdXAgYW5kIGNvbmZpZ3VyZSBh biBpbnRlcmZhY2UuICBJZiBzb21lIGNvbmZpZ3VyYXRpb24gaXMKLSMgICAgICBhcHBsaWVkIHBy aW50IHRoZSBpbnRlcmZhY2UgY29uZmlndXJhdGlvbi4KKyMgICAgICBhcHBsaWVkLCBwcmludCB0 aGUgaW50ZXJmYWNlIGNvbmZpZ3VyYXRpb24uCiAjCiBpZm5fc3RhcnQoKQogewpAQCAtNTMsNyAr NTMsNyBAQAogfQotLU1vcmUtLShieXRlIDcwNSlcXkctLU1vcmUtLShieXRlIDcwNSkKICBVc2Ug J2QnIHRvIGRlbGV0ZSB0aGUgdGVtcG9yYXJ5IC4vZXRjL25ldHdvcmsuc3VicgogIFVzZSAnaScg dG8gaW5zdGFsbCB0aGUgdGVtcG9yYXJ5IC4vZXRjL25ldHdvcmsuc3VicgogIFVzZSAnbScgdG8g bWVyZ2UgdGhlIHRlbXBvcmFyeSBhbmQgaW5zdGFsbGVkIHZlcnNpb25zCiAgVXNlICd2JyB0byB2 aWV3IHRoZSBkaWZmIHJlc3VsdHMgYWdhaW4KCiAgRGVmYXVsdCBpcyB0byBsZWF2ZSB0aGUgdGVt cG9yYXJ5IGZpbGUgdG8gZGVhbCB3aXRoIGJ5IGhhbmQKCkhvdyBzaG91bGQgSSBkZWFsIHdpdGgg dGhpcz8gW0xlYXZlIGl0IGZvciBsYXRlcl0gCiAgICoqKiAuL2V0Yy9uZXR3b3JrLnN1YnIgaW5z dGFsbGVkIHN1Y2Nlc3NmdWxseQoKICoqKiBUZW1wIC4vZXRjL25ldHdvcmtzIGFuZCBpbnN0YWxs ZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9uZXdzeXNs b2cuY29uZiBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioq IFRlbXAgLi9ldGMvbnNjZC5jb25mIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQs IGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9uc21iLmNvbmYgYW5kIGluc3RhbGxlZCBoYXZlIHRo ZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL25zc3dpdGNoLmNvbmYgYW5k IGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRj L250cC5jb25mIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAq KiogVGVtcCAuL2V0Yy9vcGllYWNjZXNzIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMg SWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9wYW0uZC9SRUFETUUgYW5kIGluc3RhbGxlZCBo YXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3BhbS5kL2F0cnVu IGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAu L2V0Yy9wYW0uZC9jcm9uIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0 aW5nCiAqKiogVGVtcCAuL2V0Yy9wYW0uZC9mdHAgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1l IENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3BhbS5kL2Z0cGQgYW5kIGluc3RhbGxl ZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3BhbS5kL2lt YXAgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1w IC4vZXRjL3BhbS5kL2tkZSBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxl dGluZwogKioqIFRlbXAgLi9ldGMvcGFtLmQvbG9naW4gYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBz YW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3BhbS5kL290aGVyIGFuZCBpbnN0 YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9wYW0u ZC9wYXNzd2QgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoq KiBUZW1wIC4vZXRjL3BhbS5kL3BvcDMgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJ ZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3BhbS5kL3JzaCBhbmQgaW5zdGFsbGVkIGhhdmUg dGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcGFtLmQvc3NoZCBhbmQg aW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMv cGFtLmQvc3UgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoq KiBUZW1wIC4vZXRjL3BhbS5kL3N5c3RlbSBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZT IElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcGFtLmQvdGVsbmV0ZCBhbmQgaW5zdGFsbGVk IGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcGFtLmQveGRt IGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAu L2V0Yy9wY2NhcmRfZXRoZXIgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVs ZXRpbmcKICoqKiBUZW1wIC4vZXRjL3BlcmlvZGljL2RhaWx5LzEwMC5jbGVhbi1kaXNrcyBhbmQg aW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMv cGVyaW9kaWMvZGFpbHkvMTEwLmNsZWFuLXRtcHMgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1l IENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3BlcmlvZGljL2RhaWx5LzEyMC5jbGVh bi1wcmVzZXJ2ZSBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwog KioqIFRlbXAgLi9ldGMvcGVyaW9kaWMvZGFpbHkvMTMwLmNsZWFuLW1zZ3MgYW5kIGluc3RhbGxl ZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3BlcmlvZGlj L2RhaWx5LzE0MC5jbGVhbi1yd2hvIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQs IGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9wZXJpb2RpYy9kYWlseS8xNTAuY2xlYW4taG9zdHN0 YXQgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1w IC4vZXRjL3BlcmlvZGljL2RhaWx5LzIwMC5iYWNrdXAtcGFzc3dkIGFuZCBpbnN0YWxsZWQgaGF2 ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9wZXJpb2RpYy9kYWls eS8yMTAuYmFja3VwLWFsaWFzZXMgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwg ZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3BlcmlvZGljL2RhaWx5LzIyMC5iYWNrdXAtcGtnZGIg YW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4v ZXRjL3BlcmlvZGljL2RhaWx5LzMxMC5hY2NvdW50aW5nIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUg c2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9wZXJpb2RpYy9kYWlseS8zMzAu bmV3cyBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRl bXAgLi9ldGMvcGVyaW9kaWMvZGFpbHkvNDAwLnN0YXR1cy1kaXNrcyBhbmQgaW5zdGFsbGVkIGhh dmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcGVyaW9kaWMvZGFp bHkvNDA0LnN0YXR1cy16ZnMgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVs ZXRpbmcKICoqKiBUZW1wIC4vZXRjL3BlcmlvZGljL2RhaWx5LzQwNS5zdGF0dXMtYXRhLXJhaWQg YW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4v ZXRjL3BlcmlvZGljL2RhaWx5LzQwNi5zdGF0dXMtZ21pcnJvciBhbmQgaW5zdGFsbGVkIGhhdmUg dGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcGVyaW9kaWMvZGFpbHkv NDA3LnN0YXR1cy1ncmFpZDMgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVs ZXRpbmcKICoqKiBUZW1wIC4vZXRjL3BlcmlvZGljL2RhaWx5LzQwOC5zdGF0dXMtZ3N0cmlwZSBh bmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9l dGMvcGVyaW9kaWMvZGFpbHkvNDA5LnN0YXR1cy1nY29uY2F0IGFuZCBpbnN0YWxsZWQgaGF2ZSB0 aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9wZXJpb2RpYy9kYWlseS80 MjAuc3RhdHVzLW5ldHdvcmsgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVs ZXRpbmcKICoqKiBUZW1wIC4vZXRjL3BlcmlvZGljL2RhaWx5LzQzMC5zdGF0dXMtcndobyBhbmQg aW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMv cGVyaW9kaWMvZGFpbHkvNDQwLnN0YXR1cy1tYWlscSBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNh bWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcGVyaW9kaWMvZGFpbHkvNDUwLnN0 YXR1cy1zZWN1cml0eSBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGlu ZwogKioqIFRlbXAgLi9ldGMvcGVyaW9kaWMvZGFpbHkvNDYwLnN0YXR1cy1tYWlsLXJlamVjdHMg YW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4v ZXRjL3BlcmlvZGljL2RhaWx5LzQ4MC5zdGF0dXMtbnRwZCBhbmQgaW5zdGFsbGVkIGhhdmUgdGhl IHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcGVyaW9kaWMvZGFpbHkvNDkw LnN0YXR1cy1wa2ctY2hhbmdlcyBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBk ZWxldGluZwogKioqIFRlbXAgLi9ldGMvcGVyaW9kaWMvZGFpbHkvNTAwLnF1ZXVlcnVuIGFuZCBp bnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9w ZXJpb2RpYy9kYWlseS84MDAuc2NydWItemZzIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBD VlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9wZXJpb2RpYy9kYWlseS85OTkubG9jYWwg YW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4v ZXRjL3BlcmlvZGljL21vbnRobHkvMjAwLmFjY291bnRpbmcgYW5kIGluc3RhbGxlZCBoYXZlIHRo ZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3BlcmlvZGljL21vbnRobHkv OTk5LmxvY2FsIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAq KiogVGVtcCAuL2V0Yy9wZXJpb2RpYy9zZWN1cml0eS8xMDAuY2hrc2V0dWlkIGFuZCBpbnN0YWxs ZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9wZXJpb2Rp Yy9zZWN1cml0eS8xMTAubmVnZ3JwcGVybSBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZT IElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcGVyaW9kaWMvc2VjdXJpdHkvMjAwLmNoa21v dW50cyBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRl bXAgLi9ldGMvcGVyaW9kaWMvc2VjdXJpdHkvMzAwLmNoa3VpZDAgYW5kIGluc3RhbGxlZCBoYXZl IHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3BlcmlvZGljL3NlY3Vy aXR5LzQwMC5wYXNzd2RsZXNzIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRl bGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9wZXJpb2RpYy9zZWN1cml0eS80MTAubG9naW5jaGVjayBh bmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9l dGMvcGVyaW9kaWMvc2VjdXJpdHkvNDYwLmNoa3BvcnRzdW0gYW5kIGluc3RhbGxlZCBoYXZlIHRo ZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3BlcmlvZGljL3NlY3VyaXR5 LzUwMC5pcGZ3ZGVuaWVkIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0 aW5nCiAqKiogVGVtcCAuL2V0Yy9wZXJpb2RpYy9zZWN1cml0eS81MTAuaXBmZGVuaWVkIGFuZCBp bnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9w ZXJpb2RpYy9zZWN1cml0eS81MjAucGZkZW5pZWQgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1l IENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3BlcmlvZGljL3NlY3VyaXR5LzU1MC5p cGZ3bGltaXQgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoq KiBUZW1wIC4vZXRjL3BlcmlvZGljL3NlY3VyaXR5LzYxMC5pcGY2ZGVuaWVkIGFuZCBpbnN0YWxs ZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9wZXJpb2Rp Yy9zZWN1cml0eS83MDAua2VybmVsbXNnIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMg SWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9wZXJpb2RpYy9zZWN1cml0eS84MDAubG9naW5m YWlsIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVt cCAuL2V0Yy9wZXJpb2RpYy9zZWN1cml0eS85MDAudGNwd3JhcCBhbmQgaW5zdGFsbGVkIGhhdmUg dGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcGVyaW9kaWMvc2VjdXJp dHkvc2VjdXJpdHkuZnVuY3Rpb25zIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQs IGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9wZXJpb2RpYy93ZWVrbHkvMzEwLmxvY2F0ZSBhbmQg aW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMv cGVyaW9kaWMvd2Vla2x5LzMyMC53aGF0aXMgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENW UyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3BlcmlvZGljL3dlZWtseS8zMzAuY2F0bWFu IGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAu L2V0Yy9wZXJpb2RpYy93ZWVrbHkvMzQwLm5vaWQgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1l IENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3BlcmlvZGljL3dlZWtseS80MDAuc3Rh dHVzLXBrZyBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioq IFRlbXAgLi9ldGMvcGVyaW9kaWMvd2Vla2x5Lzk5OS5sb2NhbCBhbmQgaW5zdGFsbGVkIGhhdmUg dGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwoKICAgPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSAgIAoKPDExOD4gICoq KiBEaXNwbGF5aW5nIGRpZmZlcmVuY2VzIGJldHdlZW4gLi9ldGMvcGYub3MgYW5kIGluc3RhbGxl ZCB2ZXJzaW9uOgoKLS0tIC9ldGMvcGYub3MgIDIwMTEtMDgtMTEgMDA6Mjg6MzMuNDAwOTk2MzE4 ICswMjAwCisrKyAuL2V0Yy9wZi5vcyAyMDExLTA5LTE2IDIyOjI4OjAyLjMzOTM2MjEyMiArMDIw MApAQCAtMSw1ICsxLDUgQEAKLSMgJEZyZWVCU0Q6IHNyYy9ldGMvcGYub3MsdiAxLjQgMjAwNi8x MC8yMyAwNTowOTo0NCBkZWxwaGlqIEV4cCAkCi0jICRPcGVuQlNEOiBwZi5vcyx2IDEuMjEgMjAw Ni8wNy8yOCAyMTo1MToxMiBkYXZpZCBFeHAgJAorIyAkRnJlZUJTRDogc3JjL2V0Yy9wZi5vcyx2 IDEuNSAyMDExLzA5LzA4IDIzOjQ2OjA3IGRlbHBoaWogRXhwICQKKyMgJE9wZW5CU0Q6IHBmLm9z LHYgMS4yNSAyMDEwLzEwLzE4IDE1OjU1OjI3IGRlcmFhZHQgRXhwICQKICMgcGFzc2l2ZSBPUyBm aW5nZXJwcmludGluZwogIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAjCkBAIC0yOTksMTMg KzI5OSwxNiBAQAogIyAtLS0tLS0tLS0tLS0tLS0tLSBPcGVuQlNEIC0tLS0tLS0tLS0tLS0tLS0t CiAKIDE2Mzg0OjY0OjA6NjA6TSosTixXMCxOLE4sVDogICAgICAgICAgIE9wZW5CU0Q6Mi42OjpO ZXRCU0QgMS4zIChvciBPcGVuQlNEIDIuNiktMTYzODQ6NjQ6MTo2NDpNKixOLE4sUyxOLFcwLE4s TixUOiAgICAgT3BlbkJTRDozLjAtNC4wOjpPcGVuQlNEIDMuMC00LjAKLTE2Mzg0OjY0OjA6NjQ6 TSosTixOLFMsTixXMCxOLE4sVDogICAgIE9wZW5CU0Q6My4wLTQuMDpuby1kZjpPcGVuQlNEIDMu MC00LjAgKHNjcnViIG5vLWRmKQorMTYzODQ6NjQ6MTo2NDpNKixOLE4sUyxOLFcwLE4sTixUOiAg ICAgT3BlbkJTRDozLjAtNC44OjpPcGVuQlNEIDMuMC00LjgKKzE2Mzg0OjY0OjA6NjQ6TSosTixO LFMsTixXMCxOLE4sVDogICAgIE9wZW5CU0Q6My4wLTQuODpuby1kZjpPcGVuQlNEIDMuMC00Ljgg KHNjcnViIG5vLWRmKQogNTczNDQ6NjQ6MTo2NDpNKixOLE4sUyxOLFcwLE4sTixUOiAgICAgT3Bl bkJTRDozLjMtNC4wOjpPcGVuQlNEIDMuMy00LjAKIDU3MzQ0OjY0OjA6NjQ6TSosTixOLFMsTixX MCxOLE4sVDogICAgIE9wZW5CU0Q6My4zLTQuMDpuby1kZjpPcGVuQlNEIDMuMy00LjAgKHMtLU1v cmUtLShieXRlIDExMDcpCiAgVXNlICdkJyB0byBkZWxldGUgdGhlIHRlbXBvcmFyeSAuL2V0Yy9w Zi5vcwogIFVzZSAnaScgdG8gaW5zdGFsbCB0aGUgdGVtcG9yYXJ5IC4vZXRjL3BmLm9zCiAgVXNl ICdtJyB0byBtZXJnZSB0aGUgdGVtcG9yYXJ5IGFuZCBpbnN0YWxsZWQgdmVyc2lvbnMKICBVc2Ug J3YnIHRvIHZpZXcgdGhlIGRpZmYgcmVzdWx0cyBhZ2FpbgoKICBEZWZhdWx0IGlzIHRvIGxlYXZl IHRoZSB0ZW1wb3JhcnkgZmlsZSB0byBkZWFsIHdpdGggYnkgaGFuZAoKSG93IHNob3VsZCBJIGRl YWwgd2l0aCB0aGlzPyBbTGVhdmUgaXQgZm9yIGxhdGVyXSAKICAgKioqIC4vZXRjL3BmLm9zIGlu c3RhbGxlZCBzdWNjZXNzZnVsbHkKCiAqKiogVGVtcCAuL2V0Yy9waG9uZXMgYW5kIGluc3RhbGxl ZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3BvcnRzbmFw LmNvbmYgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBU ZW1wIC4vZXRjL3ByaW50Y2FwIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRl bGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9wcm9maWxlIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2Ft ZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9wcm90b2NvbHMgYW5kIGluc3RhbGxl ZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjIGFuZCBp bnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9y Yy5ic2RleHRlbmRlZCBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGlu ZwogKioqIFRlbXAgLi9ldGMvcmMuZC9EQUVNT04gYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1l IENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvRklMRVNZU1RFTVMgYW5kIGlu c3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3Jj LmQvTE9HSU4gYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoq KiBUZW1wIC4vZXRjL3JjLmQvTkVUV09SS0lORyBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUg Q1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9TRVJWRVJTIGFuZCBpbnN0YWxs ZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL2Fi aSBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAg Li9ldGMvcmMuZC9hY2NvdW50aW5nIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQs IGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL2FkZHN3YXAgYW5kIGluc3RhbGxlZCBoYXZl IHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvYWRqa2VybnR6 IGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAu L2V0Yy9yYy5kL2FtZCBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGlu ZwogKioqIFRlbXAgLi9ldGMvcmMuZC9hcG0gYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENW UyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvYXBtZCBhbmQgaW5zdGFsbGVkIGhh dmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9hcmNoZGVw IGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAu L2V0Yy9yYy5kL2F0bTEgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRp bmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvYXRtMiBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUg Q1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9hdG0zIGFuZCBpbnN0YWxsZWQg aGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL2F1ZGl0 ZCBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAg Li9ldGMvcmMuZC9iZ2ZzY2sgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVs ZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvYmx1ZXRvb3RoIGFuZCBpbnN0YWxsZWQgaGF2ZSB0 aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL2Jvb3RwYXJhbXMg YW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4v ZXRjL3JjLmQvYnJpZGdlIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0 aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL2Jzbm1wZCBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNh bWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9idGhpZGQgYW5kIGluc3Rh bGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQv Y2NkIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVt cCAuL2V0Yy9yYy5kL2NsZWFudmFyIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQs IGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL2NsZWFydG1wIGFuZCBpbnN0YWxsZWQgaGF2 ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL2Nyb24gYW5k IGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRj L3JjLmQvZGRiIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAq KiogVGVtcCAuL2V0Yy9yYy5kL2RlZmF1bHRyb3V0ZSBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNh bWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9kZXZkIGFuZCBpbnN0YWxs ZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL2Rl dmZzIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVt cCAuL2V0Yy9yYy5kL2RoY2xpZW50IGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQs IGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL2RtZXNnIGFuZCBpbnN0YWxsZWQgaGF2ZSB0 aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL2R1bXBvbiBhbmQg aW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMv cmMuZC9lbmNzd2FwIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5n CiAqKiogVGVtcCAuL2V0Yy9yYy5kL2ZhaXRoIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBD VlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL2ZzY2sgYW5kIGluc3RhbGxlZCBo YXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvZnRwLXBy b3h5IGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVt cCAuL2V0Yy9yYy5kL2Z0cGQgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVs ZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvZ2JkZSBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNh bWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9nZWxpIGFuZCBpbnN0YWxs ZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL2dl bGkyIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVt cCAuL2V0Yy9yYy5kL2dwdGJvb3QgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwg ZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvZ3NzZCBhbmQgaW5zdGFsbGVkIGhhdmUgdGhl IHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9oYXN0ZCBhbmQgaW5z dGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMu ZC9oY3NlY2QgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoq KiBUZW1wIC4vZXRjL3JjLmQvaG9zdGFwZCBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZT IElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9ob3N0aWQgYW5kIGluc3RhbGxlZCBo YXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvaG9zdGlk X3NhdmUgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBU ZW1wIC4vZXRjL3JjLmQvaG9zdG5hbWUgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJ ZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvaW5ldGQgYW5kIGluc3RhbGxlZCBoYXZl IHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvaW5pdHJhbmRv bSBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAg Li9ldGMvcmMuZC9pcDZhZGRyY3RsIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQs IGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL2lwZmlsdGVyIGFuZCBpbnN0YWxsZWQgaGF2 ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL2lwZnMgYW5k IGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRj L3JjLmQvaXBmdyBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwog KioqIFRlbXAgLi9ldGMvcmMuZC9pcG1vbiBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZT IElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9pcG5hdCBhbmQgaW5zdGFsbGVkIGhh dmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9pcHNlYyBh bmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9l dGMvcmMuZC9pcHhyb3V0ZWQgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVs ZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvamFpbCBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNh bWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9rYWRtaW5kIGFuZCBpbnN0 YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5k L2tlcmJlcm9zIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAq KiogVGVtcCAuL2V0Yy9yYy5kL2tleXNlcnYgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENW UyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQva2xkIGFuZCBpbnN0YWxsZWQgaGF2 ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL2tsZHhyZWYg YW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4v ZXRjL3JjLmQva3Bhc3N3ZGQgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVs ZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvbGRjb25maWcgYW5kIGluc3RhbGxlZCBoYXZlIHRo ZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvbG9jYWwgYW5kIGlu c3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3Jj LmQvbG9jYWxwa2cgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcK ICoqKiBUZW1wIC4vZXRjL3JjLmQvbG9ja2QgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENW UyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvbHBkIGFuZCBpbnN0YWxsZWQgaGF2 ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL21kY29uZmln IGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAu L2V0Yy9yYy5kL21kY29uZmlnMiBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBk ZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9taXhlciBhbmQgaW5zdGFsbGVkIGhhdmUgdGhl IHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9tb3RkIGFuZCBpbnN0 YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5k L21vdW50Y3JpdGxvY2FsIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0 aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL21vdW50Y3JpdHJlbW90ZSBhbmQgaW5zdGFsbGVkIGhh dmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9tb3VudGQg YW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4v ZXRjL3JjLmQvbW91bnRsYXRlIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRl bGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL21vdXNlZCBhbmQgaW5zdGFsbGVkIGhhdmUgdGhl IHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9tcm91dGU2ZCBhbmQg aW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMv cmMuZC9tcm91dGVkIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5n CiAqKiogVGVtcCAuL2V0Yy9yYy5kL21zZ3MgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENW UyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvbmFtZWQgYW5kIGluc3RhbGxlZCBo YXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvbmF0ZCBh bmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9l dGMvcmMuZC9uZXRpZiBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGlu ZwoKICAgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PSAgIAoKPDExOD4gICoqKiBEaXNwbGF5aW5nIGRpZmZlcmVuY2Vz IGJldHdlZW4gLi9ldGMvcmMuZC9uZXRvcHRpb25zIGFuZCBpbnN0YWxsZWQgdmVyc2lvbjoKCi0t LSAvZXRjL3JjLmQvbmV0b3B0aW9ucyAgICAgICAgMjAxMS0wOC0xMSAwMDoyOTozMS4yMDE5OTY5 MzkgKzAyMDAKKysrIC4vZXRjL3JjLmQvbmV0b3B0aW9ucyAgICAgICAyMDExLTA5LTE2IDIyOjI4 OjAyLjc1NTM2Mzc3NiArMDIwMApAQCAtMSw2ICsxLDYgQEAKICMhL2Jpbi9zaAogIwotIyAkRnJl ZUJTRDogc3JjL2V0Yy9yYy5kL25ldG9wdGlvbnMsdiAxLjE1NSAyMDExLzAzLzMwIDAxOjE5OjAw IGVtYXN0ZSBFeHAgJAorIyAkRnJlZUJTRDogc3JjL2V0Yy9yYy5kL25ldG9wdGlvbnMsdiAxLjE1 NiAyMDExLzA5LzEzIDAwOjA2OjExIGhycyBFeHAgJAogIwogCiAjIFBST1ZJREU6IG5ldG9wdGlv bnMKQEAgLTEwNiw2ICsxMDYsMTkgQEAKICAgICAgICAgICAgICAgICR7U1lTQ1RMfSBuZXQuaW5l dDYuaXA2LnVzZV90ZW1wYWRkcj0xID4vZGV2L251bGwKICAgICAgICAgICAgICAgICR7U1lTQ1RM fSBuZXQuaW5ldDYuaXA2LnByZWZlcl90ZW1wYWRkcj0xID4vZGV2L251bGwKICAgICAgICBmaQor CisgICAgICAgY2FzZSAkaXB2Nl9jcGVfd2FuaWYgaW4KKyAgICAgICAiInxbTm5dW09vXXxbTm5d W09vXVtObl1bRWVdfFtGZl1bQWFdW0xsXVtTc11bRWVdfFtPb11bRmZdW0ZmXXwwKQorICAgICAg ICAgICAgICAgJHtTWVNDVEx9IG5ldC5pbmV0Ni5pcDYubm9fcmFkcj0wID4vZGV2L251bGwKKyAg ICAgICAgICAgICAgICR7U1lTQ1RMfSBuZXQuaW5ldDYuaXA2LnJmYzYyMDR3Mz0wID4vZGV2L251 bGwKKyAgICAgICA7OworICAgICAgICopICAgICAgCi0tTW9yZS0tKGJ5dGUgNzU3KQogIFVzZSAn ZCcgdG8gZGVsZXRlIHRoZSB0ZW1wb3JhcnkgLi9ldGMvcmMuZC9uZXRvcHRpb25zCiAgVXNlICdp JyB0byBpbnN0YWxsIHRoZSB0ZW1wb3JhcnkgLi9ldGMvcmMuZC9uZXRvcHRpb25zCiAgVXNlICdt JyB0byBtZXJnZSB0aGUgdGVtcG9yYXJ5IGFuZCBpbnN0YWxsZWQgdmVyc2lvbnMKICBVc2UgJ3Yn IHRvIHZpZXcgdGhlIGRpZmYgcmVzdWx0cyBhZ2FpbgoKICBEZWZhdWx0IGlzIHRvIGxlYXZlIHRo ZSB0ZW1wb3JhcnkgZmlsZSB0byBkZWFsIHdpdGggYnkgaGFuZAoKSG93IHNob3VsZCBJIGRlYWwg d2l0aCB0aGlzPyBbTGVhdmUgaXQgZm9yIGxhdGVyXSAKICAgKioqIC4vZXRjL3JjLmQvbmV0b3B0 aW9ucyBpbnN0YWxsZWQgc3VjY2Vzc2Z1bGx5CgogKioqIFRlbXAgLi9ldGMvcmMuZC9uZXR3YWl0 IGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAu L2V0Yy9yYy5kL25ld3N5c2xvZyBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBk ZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9uZnNjYmQgYW5kIGluc3RhbGxlZCBoYXZlIHRo ZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvbmZzY2xpZW50IGFu ZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0 Yy9yYy5kL25mc2QgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcK ICoqKiBUZW1wIC4vZXRjL3JjLmQvbmZzdXNlcmQgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1l IENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvbmlzZG9tYWluIGFuZCBpbnN0 YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5k L25zY2QgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBU ZW1wIC4vZXRjL3JjLmQvbnNzd2l0Y2ggYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJ ZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvbnRwZCBhbmQgaW5zdGFsbGVkIGhhdmUg dGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9udHBkYXRlIGFu ZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0 Yy9yYy5kL290aGVybXRhIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0 aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL3BmIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBD VlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL3BmbG9nIGFuZCBpbnN0YWxsZWQg aGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL3Bmc3lu YyBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAg Li9ldGMvcmMuZC9wb3dlcl9wcm9maWxlIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMg SWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL3Bvd2VyZCBhbmQgaW5zdGFsbGVkIGhh dmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9wcHAgYW5k IGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRj L3JjLmQvcHBwb2VkIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5n CiAqKiogVGVtcCAuL2V0Yy9yYy5kL3B3Y2hlY2sgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1l IENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvcXVvdGEgYW5kIGluc3RhbGxl ZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvcmFu ZG9tIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVt cCAuL2V0Yy9yYy5kL3JhcnBkIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRl bGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL3JjdGwgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBz YW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvcmVzb2x2IGFuZCBpbnN0 YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5k L3JmY29tbV9wcHBkX3NlcnZlciBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBk ZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9yb290IGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUg c2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL3JvdXRlNmQgYW5kIGlu c3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3Jj LmQvcm91dGVkIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAq KiogVGVtcCAuL2V0Yy9yYy5kL3JvdXRpbmcgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENW UyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvcnBjYmluZCBhbmQgaW5zdGFsbGVk IGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9ydGFk dmQgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1w IC4vZXRjL3JjLmQvcnRzb2xkIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRl bGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL3J3aG8gYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBz YW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvc2F2ZWNvcmUgYW5kIGlu c3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3Jj LmQvc2RwZCBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioq IFRlbXAgLi9ldGMvcmMuZC9zZWN1cmVsZXZlbCBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUg Q1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9zZW5kbWFpbCBhbmQgaW5zdGFs bGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9z ZXJpYWwgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBU ZW1wIC4vZXRjL3JjLmQvc3BwcCBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBk ZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC9zc2hkIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUg c2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL3N0YXRkIGFuZCBpbnN0 YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5k L3N0YXRpY19hcnAgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcK ICoqKiBUZW1wIC4vZXRjL3JjLmQvc3RmIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMg SWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL3N3YXAxIGFuZCBpbnN0YWxsZWQgaGF2 ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL3N5c2NvbnMg YW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4v ZXRjL3JjLmQvc3lzY3RsIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0 aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL3N5c2xvZ2QgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBz YW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvdGltZWQgYW5kIGluc3Rh bGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQv dG1wIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVt cCAuL2V0Yy9yYy5kL3VidGhpZGhjaSBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElk LCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC91Z2lkZncgYW5kIGluc3RhbGxlZCBoYXZl IHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvdmFyIGFuZCBp bnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9y Yy5kL3ZpcmVjb3ZlciBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGlu ZwogKioqIFRlbXAgLi9ldGMvcmMuZC93YXRjaGRvZ2QgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBz YW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmQvd3BhX3N1cHBsaWNhbnQg YW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4v ZXRjL3JjLmQveXBiaW5kIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0 aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL3lwcGFzc3dkZCBhbmQgaW5zdGFsbGVkIGhhdmUgdGhl IHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC95cHNlcnYgYW5kIGlu c3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3Jj LmQveXBzZXQgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoq KiBUZW1wIC4vZXRjL3JjLmQveXB1cGRhdGVkIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBD VlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9yYy5kL3lweGZyZCBhbmQgaW5zdGFsbGVk IGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuZC96ZnMg YW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4v ZXRjL3JjLmQvenZvbCBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGlu ZwogKioqIFRlbXAgLi9ldGMvcmMuZmlyZXdhbGwgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1l IENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLmluaXRkaXNrbGVzcyBhbmQgaW5z dGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMu cmVzdW1lIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiog VGVtcCAuL2V0Yy9yYy5zZW5kbWFpbCBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElk LCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvcmMuc2h1dGRvd24gYW5kIGluc3RhbGxlZCBoYXZl IHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3JjLnN1YnIgYW5kIGlu c3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3Jj LnN1c3BlbmQgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoq KiBUZW1wIC4vZXRjL3JlbW90ZSBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBk ZWxldGluZwogKioqIFRlbXAgLi9ldGMvcnBjIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBD VlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9zZWN1cml0eS9hdWRpdF9jbGFzcyBhbmQg aW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMv c2VjdXJpdHkvYXVkaXRfY29udHJvbCBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElk LCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvc2VjdXJpdHkvYXVkaXRfZXZlbnQgYW5kIGluc3Rh bGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3NlY3Vy aXR5L2F1ZGl0X3VzZXIgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRp bmcKICoqKiBUZW1wIC4vZXRjL3NlY3VyaXR5L2F1ZGl0X3dhcm4gYW5kIGluc3RhbGxlZCBoYXZl IHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3NlcnZpY2VzIGFuZCBp bnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9z aGVsbHMgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBU ZW1wIC4vZXRjL3NubXBkLmNvbmZpZyBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUgQ1ZTIElk LCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvc3NoL21vZHVsaSBhbmQgaW5zdGFsbGVkIGFyZSB0 aGUgc2FtZSwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3NzaC9zc2hfY29uZmlnIGFuZCBpbnN0 YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy9zc2gv c3NoZF9jb25maWcgYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcK ICoqKiBUZW1wIC4vZXRjL3NzbC9vcGVuc3NsLmNuZiBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNh bWUgQ1ZTIElkLCBkZWxldGluZwogKioqIFRlbXAgLi9ldGMvc3lzY3RsLmNvbmYgYW5kIGluc3Rh bGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1wIC4vZXRjL3N5c2xv Zy5jb25mIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiog VGVtcCAuL2V0Yy90ZXJtY2FwLnNtYWxsIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUgc2FtZSBDVlMg SWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL2V0Yy90dHlzIGFuZCBpbnN0YWxsZWQgaGF2ZSB0aGUg c2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL3Jvb3QvLmNzaHJjIGFuZCBpbnN0YWxs ZWQgaGF2ZSB0aGUgc2FtZSBDVlMgSWQsIGRlbGV0aW5nCiAqKiogVGVtcCAuL3Jvb3QvLms1bG9n aW4gYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRpbmcKICoqKiBUZW1w IC4vcm9vdC8ubG9naW4gYW5kIGluc3RhbGxlZCBoYXZlIHRoZSBzYW1lIENWUyBJZCwgZGVsZXRp bmcKICoqKiBUZW1wIC4vcm9vdC8ucHJvZmlsZSBhbmQgaW5zdGFsbGVkIGhhdmUgdGhlIHNhbWUg Q1ZTIElkLCBkZWxldGluZwoKICAqKiogVGhlcmUgaXMgbm8gaW5zdGFsbGVkIHZlcnNpb24gb2Yg Li92YXIvY3Jhc2gvbWluZnJlZQoKICBVc2UgJ2QnIHRvIGRlbGV0ZSB0aGUgdGVtcG9yYXJ5IC4v dmFyL2NyYXNoL21pbmZyZWUKICBVc2UgJ2knIHRvIGluc3RhbGwgdGhlIHRlbXBvcmFyeSAuL3Zh ci9jcmFzaC9taW5mcmVlCgogIERlZmF1bHQgaXMgdG8gbGVhdmUgdGhlIHRlbXBvcmFyeSBmaWxl IHRvIGRlYWwgd2l0aCBieSBoYW5kCgpIb3cgc2hvdWxkIEkgZGVhbCB3aXRoIHRoaXM/IFtMZWF2 ZSBpdCBmb3IgbGF0ZXJdIAogICAqKiogLi92YXIvY3Jhc2gvbWluZnJlZSBpbnN0YWxsZWQgc3Vj Y2Vzc2Z1bGx5CgoKKioqIENvbXBhcmlzb24gY29tcGxldGUKKioqIFNhdmluZyBtdHJlZSBkYXRh YmFzZSBmb3IgZnV0dXJlIHVwZ3JhZGVzCgoqKiogL3Zhci90bXAvdGVtcHJvb3QgaXMgZW1wdHks IGRlbGV0aW5nCgolbWFrZSBkZWxldGUtb2xkCj4+PiBSZW1vdmluZyBvbGQgZmlsZXMgKG9ubHkg ZGVsZXRlcyBzYWZlIHRvIGRlbGV0ZSBsaWJzKQpyZW1vdmUgL3Vzci9zaGFyZS9tYW4vbWFuNC9j Yy40Lmd6PyByZW1vdmUgL3Vzci9zaGFyZS9tYW4vbWFuOS9jYy45Lmd6PyByZW1vdmUgL3Vzci9z aGFyZS9tYW4vbWFuOS92bV9wYWdlX2ZsYWcuOS5nej8gcmVtb3ZlIC91c3Ivc2hhcmUvbWFuL21h bjkvdm1fcGFnZV9mbGFnX2NsZWFyLjkuZ3o/IHJlbW92ZSAvdXNyL3NoYXJlL21hbi9tYW45L3Zt X3BhZ2VfZmxhZ19zZXQuOS5nej8gPj4+IE9sZCBmaWxlcyByZW1vdmVkCj4+PiBSZW1vdmluZyBv bGQgZGlyZWN0b3JpZXMKL3Vzci9pbmNsdWRlL2x3cmVzCnJtZGlyOiAvdXNyL3NoYXJlL2RvYy9i aW5kOS9hcm06IERpcmVjdG9yeSBub3QgZW1wdHkKcm1kaXI6IC91c3Ivc2hhcmUvZG9jL2JpbmQ5 L21pc2M6IERpcmVjdG9yeSBub3QgZW1wdHkKcm1kaXI6IC91c3Ivc2hhcmUvZG9jL2JpbmQ5OiBE aXJlY3Rvcnkgbm90IGVtcHR5CnJtZGlyOiAvdmFyL25hbWVkL2V0Yy9uYW1lZGIvbWFzdGVyOiBE aXJlY3Rvcnkgbm90IGVtcHR5Cj4+PiBPbGQgZGlyZWN0b3JpZXMgcmVtb3ZlZApUbyByZW1vdmUg b2xkIGxpYnJhcmllcyBydW4gJ21ha2UgZGVsZXRlLW9sZC1saWJzJy4KJW1ha2UgZGVsZXRlLW9s ZCBcXkgtaVxeSCBcXkhsaWJzCj4+PiBSZW1vdmluZyBvbGQgbGlicmFyaWVzClBsZWFzZSBiZSBz dXJlIG5vIGFwcGxpY2F0aW9uIHN0aWxsIHVzZXMgdGhvc2UgbGlicmFyaWVzLCBlbHNlIHlvdQpj YW4gbm90IHN0YXJ0IHN1Y2ggYW4gYXBwbGljYXRpb24uIENvbnN1bHQgVVBEQVRJTkcgZm9yIG1v cmUKaW5mb3JtYXRpb24gcmVnYXJkaW5nIGhvdyB0byBjb3BlIHdpdGggdGhlIHJlbW92YWwvcmV2 aXNpb24gYnVtcApvZiBhIHNwZWNpZmljIGxpYnJhcnkuCnJlbW92ZSAvbGliL2xpYmNhbS5zby41 PyByZW1vdmUgL2xpYi9saWJwY2FwLnNvLjc/IHJlbW92ZSAvdXNyL2xpYjMyL2xpYmNhbS5zby41 PyA+Pj4gT2xkIGxpYnJhcmllcyByZW1vdmVkCiV5XF5IIFxeSGVlIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5bIChlc2NhcGUp IG1lbnUgIF55IHNlYXJjaCBwcm9tcHQgIF5rIGRlbGV0ZSBsaW5lICAgXnAgcHJldiBsaSAgIF5n IHByZXYgcGFnZV5vbm8gZmlsZWxpbmUgMSBjb2wgMCBsaW5lcyBmcm9tIHRvcCAxICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgfCBtYWluIG1l bnUgICAgICAgICAgIHx8ICAgICAgCiVlZSAvdXNyL3NyYy9VUERBVElORyAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeWyAoZXNj YXBlKSBtZW51ICBeeSBzZWFyY2ggcHJvbXB0ICBeayBkZWxldGUgbGluZSAgIF5wIHByZXYgbGkg ICBeZyBwcmV2IHBhZ2Veb3JlYWRpbmcgZmlsZSAiL3Vzci9zcmMvVVBEQVRJTkciZmlsZSAiL3Vz ci9zcmMvVVBEQVRJTkciLCAxNTA1IGxpbmVzVXBkYXRpbmcgSW5mb3JtYXRpb24gZm9yIEZyZWVC U0QgY3VycmVudCB1cyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgfCBtYWluIG1lbnUgICAg ICAgICAgIHx8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHdyaXRpbmcgZmlsZSAiL3Vzci9zcmMvVVBEQVRJTkciIi91c3Ivc3JjL1VQREFU SU5HIiAxNTEyIGxpbmVzLCA2Mjg2NiBjaGFyYWN0ZXJzZWVCU0QgY3VycmVudCB1c2Vyc2NvcHly aWdodGVkIAolaGVhZCB1XF5IIFxeSFVQREFUSU5HIApbNn4KYWRzCgoKcmVib290CmFkCgpVcGRh dGluZyBJbmZvcm1hdGlvbiBmb3IgRnJlZUJTRCBjdXJyZW50IHVzZXJzCgpUaGlzIGZpbGUgaXMg bWFpbnRhaW5lZCBhbmQgY29weXJpZ2h0ZWQgYnkgTS4gV2FybmVyIExvc2ggPGltcEBmcmVlYnNk Lm9yZz4uCiVoZWFkIFVQREFUSU5HJSAgICAgICAgICAgICAlcmVib290CnJlYm9vdDogQ29tbWFu ZCBub3QgZm91bmQuCiUvcmVzY3VlL3Jlb1xeR1xeSCBcXkhib290IApTZXAgMTYgMjI6MzA6MTIg aW5pdDogc2luZ2xlIHVzZXIgc2hlbGwgdGVybWluYXRlZC4KV2FpdGluZyAobWF4IDYwIHNlY29u ZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgdm5scnUnIHRvIHN0b3AuLi5kb25lCldhaXRpbmcgKG1h eCA2MCBzZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYGJ1ZmRhZW1vbicgdG8gc3RvcC4uLmRv bmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgc3luY2VyJyB0 byBzdG9wLi4uClN5bmNpbmcgZGlza3MsIHZub2RlcyByZW1haW5pbmcuLi4wIDAgZG9uZQpBbGwg YnVmZmVycyBzeW5jZWQuCkNvcHlyaWdodCAoYykgMTk5Mi0yMDExIFRoZSBGcmVlQlNEIFByb2pl Y3QuCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5 MSwgMTk5MiwgMTk5MywgMTk5NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2Fs aWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJh ZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24uCkZyZWVCU0QgOS4wLUJFVEEyICM2OiBG cmkgU2VwIDE2IDAwOjM1OjQzIENFU1QgMjAxMQogICAgcm9vdEBiZWFzdGllOi91c3Ivb2JqL3Vz ci9zcmMvc3lzL0JFQVNUSUUgYW1kNjQKQ1BVOiBJbnRlbChSKSBDb3JlKFRNKTIgQ1BVICAgICAg ICAgIDQzMDAgIEAgMS44MEdIeiAoMTgwMC4xMC1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdpbiA9 ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4NmYyICBGYW1pbHkgPSA2ICBNb2RlbCA9IGYgIFN0ZXBw aW5nID0gMgogIEZlYXR1cmVzPTB4YmZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUs TUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxEVFMs QUNQSSxNTVgsRlhTUixTU0UsU1NFMixTUyxIVFQsVE0sUEJFPgogIEZlYXR1cmVzMj0weGUzOWQ8 U1NFMyxEVEVTNjQsTU9OLERTX0NQTCxFU1QsVE0yLFNTU0UzLENYMTYseFRQUixQRENNPgogIEFN RCBGZWF0dXJlcz0weDIwMTAwODAwPFNZU0NBTEwsTlgsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8 TEFIRj4KICBUU0M6IFAtc3RhdGUgaW52YXJpYW50LCBwZXJmb3JtYW5jZSBzdGF0aXN0aWNzCnJl YWwgbWVtb3J5ICA9IDQyOTQ5NjcyOTYgKDQwOTYgTUIpCmF2YWlsIG1lbW9yeSA9IDQwODUwNDcy OTYgKDM4OTUgTUIpCkV2ZW50IHRpbWVyICJMQVBJQyIgcXVhbGl0eSA0MDAKQUNQSSBBUElDIFRh YmxlOiA8QV9NX0lfIE9FTUFQSUMgPgpGcmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVt IERldGVjdGVkOiAyIENQVXMKRnJlZUJTRC9TTVA6IDEgcGFja2FnZShzKSB4IDIgY29yZShzKQog Y3B1MCAoQlNQKTogQVBJQyBJRDogIDAKIGNwdTEgKEFQKTogQVBJQyBJRDogIDEKaW9hcGljMCA8 VmVyc2lvbiAyLjA+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZAprYmQxIGF0IGtiZG11eDAKYWNw aTA6IDxBX01fSV8gT0VNWFNEVD4gb24gbW90aGVyYm9hcmQKYWNwaTA6IFBvd2VyIEJ1dHRvbiAo Zml4ZWQpCmFjcGkwOiByZXNlcnZhdGlvbiBvZiAwLCBhMDAwMCAoMykgZmFpbGVkCmFjcGkwOiBy ZXNlcnZhdGlvbiBvZiAxMDAwMDAsIGNmZjAwMDAwICgzKSBmYWlsZWQKVGltZWNvdW50ZXIgIkFD UEktZmFzdCIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSA5MDAKYWNwaV90aW1lcjA6IDwy NC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHg4MDgtMHg4MGIgb24gYWNwaTAKY3B1 MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApBQ1BJIFdhcm5pbmc6IEluY29ycmVjdCBjaGVja3N1bSBp biB0YWJsZSBbT0VNQl0gLSAweEJFLCBzaG91bGQgYmUgMHhCRCAoMjAxMTA1MjcvdGJ1dGlscy0y NzkpCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRn ZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li MApwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgMS4wIG9uIHBj aTAKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKdmdhcGNpMDogPFZHQS1jb21wYXRpYmxl IGRpc3BsYXk+IHBvcnQgMHhiYzAwLTB4YmM3ZiBtZW0gMHhmZDAwMDAwMC0weGZkZmZmZmZmLDB4 ZDAwMDAwMDAtMHhkZmZmZmZmZiwweGZjMDAwMDAwLTB4ZmNmZmZmZmYgaXJxIDE2IGF0IGRldmlj ZSAwLjAgb24gcGNpMQpudmlkaWEwOiA8R2VGb3JjZSA3NjAwIEdUPiBvbiB2Z2FwY2kwCnZnYXBj aTA6IGNoaWxkIG52aWRpYTAgcmVxdWVzdGVkIHBjaV9lbmFibGVfaW8KdmdhcGNpMDogY2hpbGQg bnZpZGlhMCByZXF1ZXN0ZWQgcGNpX2VuYWJsZV9pbwp1aGNpMDogPEludGVsIDgyODAxSkkgKElD SDEwKSBVU0IgY29udHJvbGxlciBVU0ItRD4gcG9ydCAweGE4MDAtMHhhODFmIGlycSAxNiBhdCBk ZXZpY2UgMjYuMCBvbiBwY2kwCnVoY2kwOiBMZWdTdXAgPSAweDJmMDAKdXNidXMwOiA8SW50ZWwg ODI4MDFKSSAoSUNIMTApIFVTQiBjb250cm9sbGVyIFVTQi1EPiBvbiB1aGNpMAp1aGNpMTogPElu dGVsIDgyODAxSkkgKElDSDEwKSBVU0IgY29udHJvbGxlciBVU0ItRT4gcG9ydCAweGE4ODAtMHhh ODlmIGlycSAyMSBhdCBkZXZpY2UgMjYuMSBvbiBwY2kwCnVoY2kxOiBMZWdTdXAgPSAweDJmMDAK dXNidXMxOiA8SW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiBjb250cm9sbGVyIFVTQi1FPiBvbiB1 aGNpMQp1aGNpMjogPEludGVsIDgyODAxSkkgKElDSDEwKSBVU0IgY29udHJvbGxlciBVU0ItRj4g cG9ydCAweGFjMDAtMHhhYzFmIGlycSAxOCBhdCBkZXZpY2UgMjYuMiBvbiBwY2kwCnVoY2kyOiBM ZWdTdXAgPSAweDJmMDAKdXNidXMyOiA8SW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiBjb250cm9s bGVyIFVTQi1GPiBvbiB1aGNpMgplaGNpMDogPEludGVsIDgyODAxSkkgKElDSDEwKSBVU0IgMi4w IGNvbnRyb2xsZXIgVVNCLUI+IG1lbSAweGZiZmZmYzAwLTB4ZmJmZmZmZmYgaXJxIDE4IGF0IGRl dmljZSAyNi43IG9uIHBjaTAKdXNidXMzOiBFSENJIHZlcnNpb24gMS4wCnVzYnVzMzogPEludGVs IDgyODAxSkkgKElDSDEwKSBVU0IgMi4wIGNvbnRyb2xsZXIgVVNCLUI+IG9uIGVoY2kwCmhkYWMw OiA8SW50ZWwgODI4MDFKSSBIaWdoIERlZmluaXRpb24gQXVkaW8gQ29udHJvbGxlcj4gbWVtIDB4 ZmJmZjgwMDAtMHhmYmZmYmZmZiBpcnEgMjIgYXQgZGV2aWNlIDI3LjAgb24gcGNpMApwY2liMjog PEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNyBhdCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaTQ6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyCnBjaWIzOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJx IDE3IGF0IGRldmljZSAyOC40IG9uIHBjaTAKcGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMK YXRhcGNpMDogPE1hcnZlbGwgODhTWDYxMDEgVURNQTEzMyBjb250cm9sbGVyPiBwb3J0IDB4ZGMw MC0weGRjMDcsMHhkODgwLTB4ZDg4MywweGQ4MDAtMHhkODA3LDB4ZDQ4MC0weGQ0ODMsMHhkNDAw LTB4ZDQwZiBtZW0gMHhmZWFmZmMwMC0weGZlYWZmZGZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9u IHBjaTMKYXRhMjogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTAKcGNpYjQ6IDxBQ1BJIFBDSS1Q Q0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDI4LjUgb24gcGNpMApwY2kyOiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liNAphbGUwOiA8QXRoZXJvcyBBUjgxMjEvQVI4MTEzL0FSODExNCBQQ0llIEV0 aGVybmV0PiBwb3J0IDB4Y2MwMC0weGNjN2YgbWVtIDB4ZmU5YzAwMDAtMHhmZTlmZmZmZiBpcnEg MTcgYXQgZGV2aWNlIDAuMCBvbiBwY2kyCmFsZTA6IDk2MCBUeCBGSUZPLCAxMDI0IFJ4IEZJRk8K YWxlMDogVXNpbmcgMSBNU0kgbWVzc2FnZXMuCmFsZTA6IDRHQiBib3VuZGFyeSBjcm9zc2VkLCBz d2l0Y2hpbmcgdG8gMzJiaXQgRE1BIGFkZHJlc3NpbmcgbW9kZS4KbWlpYnVzMDogPE1JSSBidXM+ IG9uIGFsZTAKYXRwaHkwOiA8QXRoZXJvcyBGMSAxMC8xMDAvMTAwMCBQSFk+IFBIWSAwIG9uIG1p aWJ1czAKYXRwaHkwOiAgbm9uZSwgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAw YmFzZVRYLUZEWCwgMTAwMGJhc2VULUZEWCwgMTAwMGJhc2VULUZEWC1tYXN0ZXIsIGF1dG8KYWxl MDogRXRoZXJuZXQgYWRkcmVzczogMDA6MjQ6OGM6NDc6MWM6ZmYKdWhjaTM6IDxJbnRlbCA4Mjgw MUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIgVVNCLUE+IHBvcnQgMHhhMDgwLTB4YTA5ZiBpcnEg MjMgYXQgZGV2aWNlIDI5LjAgb24gcGNpMAp1aGNpMzogTGVnU3VwID0gMHgyZjAwCnVzYnVzNDog PEludGVsIDgyODAxSkkgKElDSDEwKSBVU0IgY29udHJvbGxlciBVU0ItQT4gb24gdWhjaTMKdWhj aTQ6IDxJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIgVVNCLUI+IHBvcnQgMHhh NDAwLTB4YTQxZiBpcnEgMTkgYXQgZGV2aWNlIDI5LjEgb24gcGNpMAp1aGNpNDogTGVnU3VwID0g MHgyZjAwCnVzYnVzNTogPEludGVsIDgyODAxSkkgKElDSDEwKSBVU0IgY29udHJvbGxlciBVU0It Qj4gb24gdWhjaTQKdWhjaTU6IDxJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIg VVNCLUM+IHBvcnQgMHhhNDgwLTB4YTQ5ZiBpcnEgMTggYXQgZGV2aWNlIDI5LjIgb24gcGNpMAp1 aGNpNTogTGVnU3VwID0gMHgyZjAwCnVzYnVzNjogPEludGVsIDgyODAxSkkgKElDSDEwKSBVU0Ig Y29udHJvbGxlciBVU0ItQz4gb24gdWhjaTUKZWhjaTE6IDxJbnRlbCA4MjgwMUpJIChJQ0gxMCkg VVNCIDIuMCBjb250cm9sbGVyIFVTQi1BPiBtZW0gMHhmYmZmZjgwMC0weGZiZmZmYmZmIGlycSAy MyBhdCBkZXZpY2UgMjkuNyBvbiBwY2kwCnVzYnVzNzogRUhDSSB2ZXJzaW9uIDEuMAp1c2J1czc6 IDxJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIDIuMCBjb250cm9sbGVyIFVTQi1BPiBvbiBlaGNp MQpwY2liNTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAzMC4wIG9uIHBjaTAKcGNp NTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjUKcmwwOiA8RC1MaW5rIERGRS01MzBUWCsgMTAvMTAw QmFzZVRYPiBwb3J0IDB4ZTgwMC0weGU4ZmYgbWVtIDB4ZmViZmZjMDAtMHhmZWJmZmNmZiBpcnEg MTcgYXQgZGV2aWNlIDEuMCBvbiBwY2k1Cm1paWJ1czE6IDxNSUkgYnVzPiBvbiBybDAKcmxwaHkw OiA8UmVhbFRlayBpbnRlcm5hbCBtZWRpYSBpbnRlcmZhY2U+IFBIWSAwIG9uIG1paWJ1czEKcmxw aHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgYXV0 bwpybDA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjI0OjAxOjJmOmE1OjhmCmlzYWIwOiA8UENJLUlT QSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIw CmFoY2kwOiA8SW50ZWwgSUNIMTAgQUhDSSBTQVRBIGNvbnRyb2xsZXI+IHBvcnQgMHg5YzAwLTB4 OWMwNywweDk4ODAtMHg5ODgzLDB4OTgwMC0weDk4MDcsMHg5NDgwLTB4OTQ4MywweDk0MDAtMHg5 NDFmIG1lbSAweGZiZmZlODAwLTB4ZmJmZmVmZmYgaXJxIDE5IGF0IGRldmljZSAzMS4yIG9uIHBj aTAKYWhjaTA6IEFIQ0kgdjEuMjAgd2l0aCA2IDNHYnBzIHBvcnRzLCBQb3J0IE11bHRpcGxpZXIg c3VwcG9ydGVkCmFoY2ljaDA6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBhaGNpMAph aGNpY2gxOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDEgb24gYWhjaTAKYWhjaWNoMjogPEFI Q0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAyIG9uIGFoY2kwCmFoY2ljaDM6IDxBSENJIGNoYW5uZWw+ IGF0IGNoYW5uZWwgMyBvbiBhaGNpMAphaGNpY2g0OiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVs IDQgb24gYWhjaTAKYWhjaWNoNTogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCA1IG9uIGFoY2kw CnBjaTA6IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDMxLjMgKG5vIGRyaXZlciBhdHRh Y2hlZCkKYWNwaV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMAphdHRpbWVyMDogPEFU IHRpbWVyPiBwb3J0IDB4NDAtMHg0MyBpcnEgMCBvbiBhY3BpMApUaW1lY291bnRlciAiaTgyNTQi IGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApFdmVudCB0aW1lciAiaTgyNTQiIGZyZXF1 ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMTAwCmF0cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBw b3J0IDB4NzAtMHg3MSBpcnEgOCBvbiBhY3BpMApFdmVudCB0aW1lciAiUlRDIiBmcmVxdWVuY3kg MzI3NjggSHogcXVhbGl0eSAwCmhwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXI+IGlv bWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMApUaW1lY291bnRlciAiSFBFVCIgZnJl cXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgOTUwCkV2ZW50IHRpbWVyICJIUEVUIiBmcmVxdWVu Y3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NTAKRXZlbnQgdGltZXIgIkhQRVQxIiBmcmVxdWVuY3kg MTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQyIiBmcmVxdWVuY3kgMTQz MTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQzIiBmcmVxdWVuY3kgMTQzMTgx ODAgSHogcXVhbGl0eSA0NDAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4g cG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAx IG9uIGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQp1YXJ0MDog PDE2NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBv biBhY3BpMApzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6 IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnZnYTA6IDxHZW5lcmljIElT QSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAK cHBjMDogY2Fubm90IHJlc2VydmUgSS9PIHBvcnQgcmFuZ2UKZXN0MDogPEVuaGFuY2VkIFNwZWVk U3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MApwNHRjYzA6IDxDUFUgRnJlcXVlbmN5IFRo ZXJtYWwgQ29udHJvbD4gb24gY3B1MAplc3QxOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5j eSBDb250cm9sPiBvbiBjcHUxCnA0dGNjMTogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9s PiBvbiBjcHUxClpGUyBOT1RJQ0U6IFByZWZldGNoIGlzIGRpc2FibGVkIGJ5IGRlZmF1bHQgaWYg bGVzcyB0aGFuIDRHQiBvZiBSQU0gaXMgcHJlc2VudDsKICAgICAgICAgICAgdG8gZW5hYmxlLCBh ZGQgInZmcy56ZnMucHJlZmV0Y2hfZGlzYWJsZT0wIiB0byAvYm9vdC9sb2FkZXIuY29uZi4KWkZT IGZpbGVzeXN0ZW0gdmVyc2lvbiA1ClpGUyBzdG9yYWdlIHBvb2wgdmVyc2lvbiAyOApUaW1lY291 bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjCmhkYWMwOiBIREEgQ29kZWMgIzA6IFJlYWx0ZWsg QUxDODg4CnBjbTA6IDxIREEgUmVhbHRlayBBTEM4ODggUENNICMwIEFuYWxvZz4gYXQgY2FkIDAg bmlkIDEgb24gaGRhYzAKcGNtMTogPEhEQSBSZWFsdGVrIEFMQzg4OCBQQ00gIzEgQW5hbG9nPiBh dCBjYWQgMCBuaWQgMSBvbiBoZGFjMApwY20yOiA8SERBIFJlYWx0ZWsgQUxDODg4IFBDTSAjMiBE aWdpdGFsPiBhdCBjYWQgMCBuaWQgMSBvbiBoZGFjMApwY20zOiA8SERBIFJlYWx0ZWsgQUxDODg4 IFBDTSAjMyBEaWdpdGFsPiBhdCBjYWQgMCBuaWQgMSBvbiBoZGFjMAp1c2J1czA6IDEyTWJwcyBG dWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzMTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNi dXMyOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czM6IDQ4ME1icHMgSGlnaCBTcGVl ZCBVU0IgdjIuMAp1c2J1czQ6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzNTogMTJN YnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXM2OiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEu MAp1c2J1czc6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1Z2VuMC4xOiA8SW50ZWw+IGF0 IHVzYnVzMAp1aHViMDogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAv MS4wMCwgYWRkciAxPiBvbiB1c2J1czAKdWdlbjEuMTogPEludGVsPiBhdCB1c2J1czEKdWh1YjE6 IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4g b24gdXNidXMxCnVnZW4yLjE6IDxJbnRlbD4gYXQgdXNidXMyCnVodWIyOiA8SW50ZWwgVUhDSSBy b290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMgp1Z2Vu My4xOiA8SW50ZWw+IGF0IHVzYnVzMwp1aHViMzogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNz IDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czMKdWdlbjQuMTogPEludGVsPiBh dCB1c2J1czQKdWh1YjQ6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAw LzEuMDAsIGFkZHIgMT4gb24gdXNidXM0CnVnZW41LjE6IDxJbnRlbD4gYXQgdXNidXM1CnVodWI1 OiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+ IG9uIHVzYnVzNQp1Z2VuNi4xOiA8SW50ZWw+IGF0IHVzYnVzNgp1aHViNjogPEludGVsIFVIQ0kg cm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czYKdWdl bjcuMTogPEludGVsPiBhdCB1c2J1czcKdWh1Yjc6IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFz cyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM3CnVodWIwOiAyIHBvcnRzIHdp dGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3Zh YmxlLCBzZWxmIHBvd2VyZWQKdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBw b3dlcmVkCnVodWI0OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHVi NTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjY6IDIgcG9ydHMg d2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCmFkYTAgYXQgYWhjaWNoNSBidXMgMCBzY2J1 czYgdGFyZ2V0IDAgbHVuIDAKYWRhMDogPFdEQyBXRDEwMDJGQUVYLTAwWjNBMCAwNS4wMUQwNT4g QVRBLTggU0FUQSAyLnggZGV2aWNlCmFkYTA6IDMwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAy LngsIFVETUE2LCBQSU8gODE5MmJ5dGVzKQphZGEwOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQK YWRhMDogOTUzODY5TUIgKDE5NTM1MjUxNjggNTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2 MzgzQykKYWRhMDogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQxNgpTTVA6IEFQIENQVSAjMSBM YXVuY2hlZCEKVGltZWNvdW50ZXIgIlRTQy1sb3ciIGZyZXF1ZW5jeSAxNDA2MzMwNyBIeiBxdWFs aXR5IDEwMDAKY2QwIGF0IGF0YTIgYnVzIDAgc2NidXMwIHRhcmdldCAwIGx1biAwCmNkMDogPEhM LURULVNUIERWRFJBTSBHU0EtSDQyTCBTTDAwPiBSZW1vdmFibGUgQ0QtUk9NIFNDU0ktMCBkZXZp Y2UgCmNkMDogNjYuNzAwTUIvcyB0cmFuc2ZlcnMgKFVETUE0LCBBVEFQSSAxMmJ5dGVzLCBQSU8g NjU1MzRieXRlcykKY2QwOiBBdHRlbXB0IHRvIHF1ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogTk9U IFJFQURZLCBNZWRpdW0gbm90IHByZXNlbnQKY2QxIGF0IGF0YTIgYnVzIDAgc2NidXMwIHRhcmdl dCAxIGx1biAwCmNkMTogPExJVEUtT04gQ0QtUlcgU09IUi01MjM4UyA0UzA0PiBSZW1vdmFibGUg Q0QtUk9NIFNDU0ktMCBkZXZpY2UgCmNkMTogMzMuMzAwTUIvcyB0cmFuc2ZlcnMgKFVETUEyLCBB VEFQSSAxMmJ5dGVzLCBQSU8gNjU1MzRieXRlcykKY2QxOiBBdHRlbXB0IHRvIHF1ZXJ5IGRldmlj ZSBzaXplIGZhaWxlZDogTk9UIFJFQURZLCBNZWRpdW0gbm90IHByZXNlbnQKUm9vdCBtb3VudCB3 YWl0aW5nIGZvcjogdXNidXM3IHVzYnVzMwp1aHViMzogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxl LCBzZWxmIHBvd2VyZWQKdWh1Yjc6IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dl cmVkClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNwp1Z2VuNy4yOiA8dmVuZG9yIDB4MDQ2 ZD4gYXQgdXNidXM3CnVhdWRpbzA6IDx2ZW5kb3IgMHgwNDZkIHByb2R1Y3QgMHgwODFiLCBjbGFz cyAyMzkvMiwgcmV2IDIuMDAvMC4xMCwgYWRkciAyPiBvbiB1c2J1czcKdWF1ZGlvMDogTm8gcGxh eWJhY2shCnVhdWRpbzA6IFJlY29yZDogNDgwMDAgSHosIDEgY2gsIDE2LWJpdCBTLUxFIFBDTSBm b3JtYXQKdWF1ZGlvMDogTm8gbWlkaSBzZXF1ZW5jZXIKcGNtNDogPFVTQiBhdWRpbz4gb24gdWF1 ZGlvMApUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHpmczp0YW5rMCBbXS4uLgpTZXR0aW5nIGhv c3R1dWlkOiAwMDdhZThjMC0wMDAxLWRlMTEtYTg5OS0wMDI0OGM0NzFjZmYuClNldHRpbmcgaG9z dGlkOiAweDA5ZmIxZGYyLgpFbnRyb3B5IGhhcnZlc3Rpbmc6IGludGVycnVwdHMgZXRoZXJuZXQg cG9pbnRfdG9fcG9pbnQKdWdlbjYuMjogPE1pY3Jvc29mdD4gYXQgdXNidXM2CiBraWNrc3RhcnQu ClN0YXJ0aW5nIGZpbGUgc3lzdGVtIGNoZWNrczoKL2Rldi9sYWJlbC9ib290MDogRklMRSBTWVNU RU0gQ0xFQU47IFNLSVBQSU5HIENIRUNLUwovZGV2L2xhYmVsL2Jvb3QwOiBjbGVhbiwgODQwMTgg ZnJlZSAoNDU4IGZyYWdzLCAxMDQ0NSBibG9ja3MsIDAuMiUgZnJhZ21lbnRhdGlvbikKTW91bnRp bmcgbG9jYWwgZmlsZSBzeXN0ZW1zOi4KU2V0dGluZyBob3N0bmFtZTogYmVhc3RpZS4KdmJveGRy djogZkFzeW5jPTAgb2ZmTWluPTB4NDUzIG9mZk1heD0weDEwMjMKdmJveG5ldDA6IEV0aGVybmV0 IGFkZHJlc3M6IDBhOjAwOjI3OjAwOjAwOjAwClN0YXJ0aW5nIE5ldHdvcms6IGxvMCBhbGUwIHJs MC4KbG8wOiBmbGFncz04MDQ5PFVQLExPT1BCQUNLLFJVTk5JTkcsTVVMVElDQVNUPiBtZXRyaWMg MCBtdHUgMTYzODQKCW9wdGlvbnM9MzxSWENTVU0sVFhDU1VNPgoJaW5ldCAxMjcuMC4wLjEgbmV0 bWFzayAweGZmMDAwMDAwIAphbGUwOiBmbGFncz04ODQzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLFNJ TVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAoJb3B0aW9ucz1jMzE5YTxUWENTVU0s VkxBTl9NVFUsVkxBTl9IV1RBR0dJTkcsVkxBTl9IV0NTVU0sVFNPNCxXT0xfTUNBU1QsV09MX01B R0lDLFZMQU5fSFdUU08sTElOS1NUQVRFPgoJZXRoZXIgMDA6MjQ6OGM6NDc6MWM6ZmYKCW1lZGlh OiBFdGhlcm5ldCBhdXRvc2VsZWN0IChub25lKQoJc3RhdHVzOiBubyBjYXJyaWVyCnJsMDogZmxh Z3M9ODg0MzxVUCxCUk9BRENBU1QsUlVOTklORyxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAg bXR1IDE1MDAKCW9wdGlvbnM9MzgwODxWTEFOX01UVSxXT0xfVUNBU1QsV09MX01DQVNULFdPTF9N QUdJQz4KCWV0aGVyIDAwOjI0OjAxOjJmOmE1OjhmCgltZWRpYTogRXRoZXJuZXQgYXV0b3NlbGVj dCAobm9uZSkKCXN0YXR1czogbm8gY2FycmllcgpTdGFydGluZyBkZXZkLgpTdGFydGluZyB3ZWJj YW1kLgpBdHRhY2hlZCB1Z2VuNy4yWzBdIHRvIGN1c2UgdW5pdCAtMQpTdGFydGluZyB3ZWJjYW1k LgpBdHRhY2hlZCB1Z2VuNy4yWzBdIHRvIGN1c2UgdW5pdCAtMQp1bXMwOiA8TWljcm9zb2Z0IE1p Y3Jvc29mdCA1LUJ1dHRvbiBNb3VzZSB3aXRoIEludGVsbGlFeWVUTSwgY2xhc3MgMC8wLCByZXYg MS4xMC8zLjAwLCBhZGRyIDI+IG9uIHVzYnVzNgp1bXMwOiA1IGJ1dHRvbnMgYW5kIFtYWVpdIGNv b3JkaW5hdGVzIElEPTAKU3RhcnRpbmcgdW1zMCBtb3VzZWQuCldhaXRpbmcgMzBzIGZvciB0aGUg ZGVmYXVsdCByb3V0ZSBpbnRlcmZhY2U6IC4oYWxlMCkKRUxGIGxkY29uZmlnIHBhdGg6IC9saWIg L3Vzci9saWIgL3Vzci9saWIvY29tcGF0IC91c3IvbG9jYWwvbGliIC91c3IvbG9jYWwvbGliL2Nv bXBhdCAvdXNyL2xvY2FsL2xpYi9ldmVudDIgL3Vzci9sb2NhbC9saWIvZ2VnbC0wLjEgL3Vzci9s b2NhbC9saWIvZ3JhcGh2aXogL3Vzci9sb2NhbC9saWIvbGlieHVsIC91c3IvbG9jYWwvbGliL25z cyAvdXNyL2xvY2FsL2xpYi9xdDQgL3Vzci9sb2NhbC9saWIvdmlydHVhbGJveAozMi1iaXQgY29t cGF0aWJpbGl0eSBsZGNvbmZpZyBwYXRoOiAvdXNyL2xpYjMyIC91c3IvbG9jYWwvbGliMzIvY29t cGF0CkNyZWF0aW5nIGFuZC9vciB0cmltbWluZyBsb2cgZmlsZXMuClN0YXJ0aW5nIHN5c2xvZ2Qu CnNhdmVjb3JlOiByZWJvb3QgYWZ0ZXIgcGFuaWM6IHBhZ2UgZmF1bHQKU2VwIDE2IDIyOjMxOjEy IGJlYXN0aWUgc2F2ZWNvcmU6IHJlYm9vdCBhZnRlciBwYW5pYzogcGFnZSBmYXVsdApzYXZlY29y ZTogd3JpdGluZyBjb3JlIHRvIHZtY29yZS4yCldyaXRpbmcgY3Jhc2ggc3VtbWFyeSB0byAvdmFy L2NyYXNoL2NvcmUudHh0LjIuCkFkZGl0aW9uYWwgQUJJIHN1cHBvcnQ6IGxpbnV4LgpDbGVhcmlu ZyAvdG1wIChYIHJlbGF0ZWQpLgpVcGRhdGluZyBtb3RkOi4KU3RhcnRpbmcgZnVzZWZzLgpmdXNl NGJzZDogdmVyc2lvbiAwLjMuOS1wcmUxLCBGVVNFIEFCSSA3LjgKU3RhcnRpbmcgc2xpbS4KU3Rh cnRpbmcgZGJ1cy4KU3RhcnRpbmcgaGFsZC4KU3RhcnRpbmcgZGRjbGllbnQuClN0YXJ0aW5nIGJs b2Nrc3NoZC4KU2VwIDE2IDIyOjMxOjUwIGJlYXN0aWUgYmxvY2tzc2hkWzE5OTVdOiBTdGFydGlu ZyBCbG9ja1NTSEQKU2VwIDE2IDIyOjMxOjUwIGJlYXN0aWUgYmxvY2tzc2hkWzE5OTVdOiBGbHVz aGluZyBleGlzdGluZyBydWxlcyBpbiBibG9ja3NzaGQuClNlcCAxNiAyMjozMTo1MCBiZWFzdGll IGJsb2Nrc3NoZFsxOTk1XTogVW5hYmxlIHRvIGZsdXNoIGV4aXN0aW5nIGZpcmV3YWxscyBydWxl cyBmcm9tIGJsb2Nrc3NoZApDb25maWd1cmluZyBzeXNjb25zOiBibGFua3RpbWUuClN0YXJ0aW5n IHNzaGQuClN0YXJ0aW5nIGNyb24uClN0YXJ0aW5nIGJhY2tncm91bmQgZmlsZSBzeXN0ZW0gY2hl Y2tzIGluIDYwIHNlY29uZHMuCgpGcmkgU2VwIDE2IDIyOjMxOjUxIENFU1QgMjAxMQpTZXAgMTYg MjI6MzI6MjQgYmVhc3RpZSBsb2dpbjogUk9PVCBMT0dJTiAocm9vdCkgT04gdHR5djAKU2VwIDE2 IDIyOjMzOjE5IGJlYXN0aWUgbG9naW46IFJPT1QgTE9HSU4gKHJvb3QpIE9OIHR0eXYxCgoKRmF0 YWwgdHJhcCAxMjogcGFnZSBmYXVsdCB3aGlsZSBpbiBrZXJuZWwgbW9kZQpjcHVpZCA9IDA7IGFw aWMgaWQgPSAwMApmYXVsdCB2aXJ0dWFsIGFkZHJlc3MJPSAweDgKZmF1bHQgY29kZQkJPSBzdXBl cnZpc29yIHJlYWQgZGF0YSwgcGFnZSBub3QgcHJlc2VudAppbnN0cnVjdGlvbiBwb2ludGVyCT0g MHgyMDoweGZmZmZmZmZmODAzZGQ1ODUKc3RhY2sgcG9pbnRlcgkgICAgICAgID0gMHgyODoweGZm ZmZmZjgxMWQ0Y2I2YjAKZnJhbWUgcG9pbnRlcgkgICAgICAgID0gMHgyODoweGZmZmZmZjgxMWQ0 Y2I2ZTAKY29kZSBzZWdtZW50CQk9IGJhc2UgMHgwLCBsaW1pdCAweGZmZmZmLCB0eXBlIDB4MWIK CQkJPSBEUEwgMCwgcHJlcyAxLCBsb25nIDEsIGRlZjMyIDAsIGdyYW4gMQpwcm9jZXNzb3IgZWZs YWdzCT0gaW50ZXJydXB0IGVuYWJsZWQsIHJlc3VtZSwgSU9QTCA9IDAKY3VycmVudCBwcm9jZXNz CQk9IDMxNjUxIChoYWxkKQp0cmFwIG51bWJlcgkJPSAxMgpwYW5pYzogcGFnZSBmYXVsdApjcHVp ZCA9IDAKVXB0aW1lOiA5bTNzCkR1bXBpbmcgMTYxNSBvdXQgb2YgNDA2NyBNQjouLjElLi4xMSUu LjIxJS4uMzElLi40MSUuLjUxJS4uNjElLi43MSUuLjgxJS4uOTElQ29weXJpZ2h0IChjKSAxOTky LTIwMTEgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgz LCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0CglUaGUgUmVnZW50cyBv ZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVl QlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4K RnJlZUJTRCA5LjAtQkVUQTIgIzY6IEZyaSBTZXAgMTYgMDA6MzU6NDMgQ0VTVCAyMDExCiAgICBy b290QGJlYXN0aWU6L3Vzci9vYmovdXNyL3NyYy9zeXMvQkVBU1RJRSBhbWQ2NApDUFU6IEludGVs KFIpIENvcmUoVE0pMiBDUFUgICAgICAgICAgNDMwMCAgQCAxLjgwR0h6ICgxODAwLjEwLU1IeiBL OC1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHg2ZjIgIEZhbWls eSA9IDYgIE1vZGVsID0gZiAgU3RlcHBpbmcgPSAyCiAgRmVhdHVyZXM9MHhiZmViZmJmZjxGUFUs Vk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9W LFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQ QkU+CiAgRmVhdHVyZXMyPTB4ZTM5ZDxTU0UzLERURVM2NCxNT04sRFNfQ1BMLEVTVCxUTTIsU1NT RTMsQ1gxNix4VFBSLFBEQ00+CiAgQU1EIEZlYXR1cmVzPTB4MjAxMDA4MDA8U1lTQ0FMTCxOWCxM TT4KICBBTUQgRmVhdHVyZXMyPTB4MTxMQUhGPgogIFRTQzogUC1zdGF0ZSBpbnZhcmlhbnQsIHBl cmZvcm1hbmNlIHN0YXRpc3RpY3MKcmVhbCBtZW1vcnkgID0gNDI5NDk2NzI5NiAoNDA5NiBNQikK YXZhaWwgbWVtb3J5ID0gNDA4NTA0NzI5NiAoMzg5NSBNQikKRXZlbnQgdGltZXIgIkxBUElDIiBx dWFsaXR5IDQwMApBQ1BJIEFQSUMgVGFibGU6IDxBX01fSV8gT0VNQVBJQyA+CkZyZWVCU0QvU01Q OiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDIgQ1BVcwpGcmVlQlNEL1NNUDogMSBw YWNrYWdlKHMpIHggMiBjb3JlKHMpCiBjcHUwIChCU1ApOiBBUElDIElEOiAgMAogY3B1MSAoQVAp OiBBUElDIElEOiAgMQppb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1vdGhlcmJv YXJkCmtiZDEgYXQga2JkbXV4MAphY3BpMDogPEFfTV9JXyBPRU1YU0RUPiBvbiBtb3RoZXJib2Fy ZAphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkKYWNwaTA6IHJlc2VydmF0aW9uIG9mIDAsIGEw MDAwICgzKSBmYWlsZWQKYWNwaTA6IHJlc2VydmF0aW9uIG9mIDEwMDAwMCwgY2ZmMDAwMDAgKDMp IGZhaWxlZApUaW1lY291bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFs aXR5IDkwMAphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAw eDgwOC0weDgwYiBvbiBhY3BpMApjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCkFDUEkgV2Fybmlu ZzogSW5jb3JyZWN0IGNoZWNrc3VtIGluIHRhYmxlIFtPRU1CXSAtIDB4QkUsIHNob3VsZCBiZSAw eEJEICgyMDExMDUyNy90YnV0aWxzLTI3OSkKY3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMApwY2li MDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJx IDE2IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQp2 Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gcG9ydCAweGJjMDAtMHhiYzdmIG1lbSAw eGZkMDAwMDAwLTB4ZmRmZmZmZmYsMHhkMDAwMDAwMC0weGRmZmZmZmZmLDB4ZmMwMDAwMDAtMHhm Y2ZmZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2kxCm52aWRpYTA6IDxHZUZvcmNlIDc2 MDAgR1Q+IG9uIHZnYXBjaTAKdmdhcGNpMDogY2hpbGQgbnZpZGlhMCByZXF1ZXN0ZWQgcGNpX2Vu YWJsZV9pbwp2Z2FwY2kwOiBjaGlsZCBudmlkaWEwIHJlcXVlc3RlZCBwY2lfZW5hYmxlX2lvCnVo Y2kwOiA8SW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiBjb250cm9sbGVyIFVTQi1EPiBwb3J0IDB4 YTgwMC0weGE4MWYgaXJxIDE2IGF0IGRldmljZSAyNi4wIG9uIHBjaTAKdWhjaTA6IExlZ1N1cCA9 IDB4MmYwMAp1c2J1czA6IDxJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIgVVNC LUQ+IG9uIHVoY2kwCnVoY2kxOiA8SW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiBjb250cm9sbGVy IFVTQi1FPiBwb3J0IDB4YTg4MC0weGE4OWYgaXJxIDIxIGF0IGRldmljZSAyNi4xIG9uIHBjaTAK dWhjaTE6IExlZ1N1cCA9IDB4MmYwMAp1c2J1czE6IDxJbnRlbCA4MjgwMUpJIChJQ0gxMCkgVVNC IGNvbnRyb2xsZXIgVVNCLUU+IG9uIHVoY2kxCnVoY2kyOiA8SW50ZWwgODI4MDFKSSAoSUNIMTAp IFVTQiBjb250cm9sbGVyIFVTQi1GPiBwb3J0IDB4YWMwMC0weGFjMWYgaXJxIDE4IGF0IGRldmlj ZSAyNi4yIG9uIHBjaTAKdWhjaTI6IExlZ1N1cCA9IDB4MmYwMAp1c2J1czI6IDxJbnRlbCA4Mjgw MUpJIChJQ0gxMCkgVVNCIGNvbnRyb2xsZXIgVVNCLUY+IG9uIHVoY2kyCmVoY2kwOiA8SW50ZWwg ODI4MDFKSSAoSUNIMTApIFVTQiAyLjAgY29udHJvbGxlciBVU0ItQj4gbWVtIDB4ZmJmZmZjMDAt MHhmYmZmZmZmZiBpcnEgMTggYXQgZGV2aWNlIDI2Ljcgb24gcGNpMAp1c2J1czM6IEVIQ0kgdmVy c2lvbiAxLjAKdXNidXMzOiA8SW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiAyLjAgY29udHJvbGxl ciBVU0ItQj4gb24gZWhjaTAKaGRhYzA6IDxJbnRlbCA4MjgwMUpJIEhpZ2ggRGVmaW5pdGlvbiBB dWRpbyBDb250cm9sbGVyPiBtZW0gMHhmYmZmODAwMC0weGZiZmZiZmZmIGlycSAyMiBhdCBkZXZp Y2UgMjcuMCBvbiBwY2kwCnBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE3IGF0IGRl dmljZSAyOC4wIG9uIHBjaTAKcGNpNDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIKcGNpYjM6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTcgYXQgZGV2aWNlIDI4LjQgb24gcGNpMApwY2kzOiA8 QUNQSSBQQ0kgYnVzPiBvbiBwY2liMwphdGFwY2kwOiA8TWFydmVsbCA4OFNYNjEwMSBVRE1BMTMz IGNvbnRyb2xsZXI+IHBvcnQgMHhkYzAwLTB4ZGMwNywweGQ4ODAtMHhkODgzLDB4ZDgwMC0weGQ4 MDcsMHhkNDgwLTB4ZDQ4MywweGQ0MDAtMHhkNDBmIG1lbSAweGZlYWZmYzAwLTB4ZmVhZmZkZmYg aXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpMwphdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRh cGNpMApwY2liNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgMjguNSBv biBwY2kwCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0CmFsZTA6IDxBdGhlcm9zIEFSODEy MS9BUjgxMTMvQVI4MTE0IFBDSWUgRXRoZXJuZXQ+IHBvcnQgMHhjYzAwLTB4Y2M3ZiBtZW0gMHhm ZTljMDAwMC0weGZlOWZmZmZmIGlycSAxNyBhdCBkZXZpY2UgMC4wIG9uIHBjaTIKYWxlMDogOTYw IFR4IEZJRk8sIDEwMjQgUnggRklGTwphbGUwOiBVc2luZyAxIE1TSSBtZXNzYWdlcy4KYWxlMDog NEdCIGJvdW5kYXJ5IGNyb3NzZWQsIHN3aXRjaGluZyB0byAzMmJpdCBETUEgYWRkcmVzc2luZyBt b2RlLgptaWlidXMwOiA8TUlJIGJ1cz4gb24gYWxlMAphdHBoeTA6IDxBdGhlcm9zIEYxIDEwLzEw MC8xMDAwIFBIWT4gUEhZIDAgb24gbWlpYnVzMAphdHBoeTA6ICBub25lLCAxMGJhc2VULCAxMGJh c2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFzZVQtRkRYLCAxMDAwYmFz ZVQtRkRYLW1hc3RlciwgYXV0bwphbGUwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoyNDo4Yzo0Nzox YzpmZgp1aGNpMzogPEludGVsIDgyODAxSkkgKElDSDEwKSBVU0IgY29udHJvbGxlciBVU0ItQT4g cG9ydCAweGEwODAtMHhhMDlmIGlycSAyMyBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwCnVoY2kzOiBM ZWdTdXAgPSAweDJmMDAKdXNidXM0OiA8SW50ZWwgODI4MDFKSSAoSUNIMTApIFVTQiBjb250cm9s bGVyIFVTQi1BPiBvbiB1aGNpMwp1aGNpNDogPEludGVsIDgyODAxSkkgKElDSDEwKSBVU0IgY29u dHJvbGxlciBVU0ItQj4gcG9ydCAweGE0MDAtMHhhNDFmIGlycSAxOSBhdCBkZXZpY2UgMjkuMSBv biBwY2kwCnVoY2k0OiBMZWdTdXAgPSAweDJmMDAKdXNidXM1OiA8SW50ZWwgODI4MDFKSSAoSUNI MTApIFVTQiBjb250cm9sbGVyIFVTQi1CPiBvbiB1aGNpNAp1aGNpNTogPEludGVsIDgyODAxSkkg KElDSDEwKSBVU0IgY29udHJvbGxlciBVU0ItQz4gcG9ydCAweGE0ODAtMHhhNDlmIGlycSAxOCBh dCBkZXZpY2UgMjkuMiBvbiBwY2kwCnVoY2k1OiBMZWdTdXAgPSAweDJmMDAKdXNidXM2OiA8SW50 ZWwgODI4MDFKSSAoSUNIMTApIFVTQiBjb250cm9sbGVyIFVTQi1DPiBvbiB1aGNpNQplaGNpMTog PEludGVsIDgyODAxSkkgKElDSDEwKSBVU0IgMi4wIGNvbnRyb2xsZXIgVVNCLUE+IG1lbSAweGZi ZmZmODAwLTB4ZmJmZmZiZmYgaXJxIDIzIGF0IGRldmljZSAyOS43IG9uIHBjaTAKdXNidXM3OiBF SENJIHZlcnNpb24gMS4wCnVzYnVzNzogPEludGVsIDgyODAxSkkgKElDSDEwKSBVU0IgMi4wIGNv bnRyb2xsZXIgVVNCLUE+IG9uIGVoY2kxCnBjaWI1OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQg ZGV2aWNlIDMwLjAgb24gcGNpMApwY2k1OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNQpybDA6IDxE LUxpbmsgREZFLTUzMFRYKyAxMC8xMDBCYXNlVFg+IHBvcnQgMHhlODAwLTB4ZThmZiBtZW0gMHhm ZWJmZmMwMC0weGZlYmZmY2ZmIGlycSAxNyBhdCBkZXZpY2UgMS4wIG9uIHBjaTUKbWlpYnVzMTog PE1JSSBidXM+IG9uIHJsMApybHBoeTA6IDxSZWFsVGVrIGludGVybmFsIG1lZGlhIGludGVyZmFj ZT4gUEhZIDAgb24gbWlpYnVzMQpybHBoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFz ZVRYLCAxMDBiYXNlVFgtRkRYLCBhdXRvCnJsMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MjQ6MDE6 MmY6YTU6OGYKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMApp c2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKYWhjaTA6IDxJbnRlbCBJQ0gxMCBBSENJIFNBVEEgY29u dHJvbGxlcj4gcG9ydCAweDljMDAtMHg5YzA3LDB4OTg4MC0weDk4ODMsMHg5ODAwLTB4OTgwNyww eDk0ODAtMHg5NDgzLDB4OTQwMC0weDk0MWYgbWVtIDB4ZmJmZmU4MDAtMHhmYmZmZWZmZiBpcnEg MTkgYXQgZGV2aWNlIDMxLjIgb24gcGNpMAphaGNpMDogQUhDSSB2MS4yMCB3aXRoIDYgM0dicHMg cG9ydHMsIFBvcnQgTXVsdGlwbGllciBzdXBwb3J0ZWQKYWhjaWNoMDogPEFIQ0kgY2hhbm5lbD4g YXQgY2hhbm5lbCAwIG9uIGFoY2kwCmFoY2ljaDE6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwg MSBvbiBhaGNpMAphaGNpY2gyOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDIgb24gYWhjaTAK YWhjaWNoMzogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAzIG9uIGFoY2kwCmFoY2ljaDQ6IDxB SENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgNCBvbiBhaGNpMAphaGNpY2g1OiA8QUhDSSBjaGFubmVs PiBhdCBjaGFubmVsIDUgb24gYWhjaTAKcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZp Y2UgMzEuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0b24+ IG9uIGFjcGkwCmF0dGltZXIwOiA8QVQgdGltZXI+IHBvcnQgMHg0MC0weDQzIGlycSAwIG9uIGFj cGkwClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwCkV2 ZW50IHRpbWVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAxMDAKYXRydGMw OiA8QVQgcmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3MC0weDcxIGlycSA4IG9uIGFjcGkwCkV2ZW50 IHRpbWVyICJSVEMiIGZyZXF1ZW5jeSAzMjc2OCBIeiBxdWFsaXR5IDAKaHBldDA6IDxIaWdoIFBy ZWNpc2lvbiBFdmVudCBUaW1lcj4gaW9tZW0gMHhmZWQwMDAwMC0weGZlZDAwM2ZmIG9uIGFjcGkw ClRpbWVjb3VudGVyICJIUEVUIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA5NTAKRXZl bnQgdGltZXIgIkhQRVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDQ1MApFdmVudCB0 aW1lciAiSFBFVDEiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDQ0MApFdmVudCB0aW1l ciAiSFBFVDIiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDQ0MApFdmVudCB0aW1lciAi SFBFVDMiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDQ0MAphdGtiZGMwOiA8S2V5Ym9h cmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMAphdGti ZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6 IFtHSUFOVC1MT0NLRURdCnVhcnQwOiA8MTY1NTAgb3IgY29tcGF0aWJsZT4gcG9ydCAweDNmOC0w eDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkwCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBm bGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0w eDMwMD4KdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAw eGEwMDAwLTB4YmZmZmYgb24gaXNhMApwcGMwOiBjYW5ub3QgcmVzZXJ2ZSBJL08gcG9ydCByYW5n ZQplc3QwOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUwCnA0 dGNjMDogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUwCmVzdDE6IDxFbmhh bmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTEKcDR0Y2MxOiA8Q1BVIEZy ZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTEKWkZTIE5PVElDRTogUHJlZmV0Y2ggaXMg ZGlzYWJsZWQgYnkgZGVmYXVsdCBpZiBsZXNzIHRoYW4gNEdCIG9mIFJBTSBpcyBwcmVzZW50Owog ICAgICAgICAgICB0byBlbmFibGUsIGFkZCAidmZzLnpmcy5wcmVmZXRjaF9kaXNhYmxlPTAiIHRv IC9ib290L2xvYWRlci5jb25mLgpaRlMgZmlsZXN5c3RlbSB2ZXJzaW9uIDUKWkZTIHN0b3JhZ2Ug cG9vbCB2ZXJzaW9uIDI4ClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKaGRhYzA6 IEhEQSBDb2RlYyAjMDogUmVhbHRlayBBTEM4ODgKcGNtMDogPEhEQSBSZWFsdGVrIEFMQzg4OCBQ Q00gIzAgQW5hbG9nPiBhdCBjYWQgMCBuaWQgMSBvbiBoZGFjMApwY20xOiA8SERBIFJlYWx0ZWsg QUxDODg4IFBDTSAjMSBBbmFsb2c+IGF0IGNhZCAwIG5pZCAxIG9uIGhkYWMwCnBjbTI6IDxIREEg UmVhbHRlayBBTEM4ODggUENNICMyIERpZ2l0YWw+IGF0IGNhZCAwIG5pZCAxIG9uIGhkYWMwCnBj bTM6IDxIREEgUmVhbHRlayBBTEM4ODggUENNICMzIERpZ2l0YWw+IGF0IGNhZCAwIG5pZCAxIG9u IGhkYWMwCnVzYnVzMDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMxOiAxMk1icHMg RnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czI6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVz YnVzMzogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVzYnVzNDogMTJNYnBzIEZ1bGwgU3Bl ZWQgVVNCIHYxLjAKdXNidXM1OiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czY6IDEy TWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzNzogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2 Mi4wCnVnZW4wLjE6IDxJbnRlbD4gYXQgdXNidXMwCnVodWIwOiA8SW50ZWwgVUhDSSByb290IEhV QiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMAp1Z2VuMS4xOiA8 SW50ZWw+IGF0IHVzYnVzMQp1aHViMTogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwg cmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czEKdWdlbjIuMTogPEludGVsPiBhdCB1c2J1 czIKdWh1YjI6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAs IGFkZHIgMT4gb24gdXNidXMyCnVnZW4zLjE6IDxJbnRlbD4gYXQgdXNidXMzCnVodWIzOiA8SW50 ZWwgRUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVz YnVzMwp1Z2VuNC4xOiA8SW50ZWw+IGF0IHVzYnVzNAp1aHViNDogPEludGVsIFVIQ0kgcm9vdCBI VUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czQKdWdlbjUuMTog PEludGVsPiBhdCB1c2J1czUKdWh1YjU6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAs IHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM1CnVnZW42LjE6IDxJbnRlbD4gYXQgdXNi dXM2CnVodWI2OiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAw LCBhZGRyIDE+IG9uIHVzYnVzNgp1Z2VuNy4xOiA8SW50ZWw+IGF0IHVzYnVzNwp1aHViNzogPElu dGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1 c2J1czcKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWIx OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMjogMiBwb3J0cyB3 aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjQ6IDIgcG9ydHMgd2l0aCAyIHJlbW92 YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI1OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYg cG93ZXJlZAp1aHViNjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKYWRh MCBhdCBhaGNpY2g1IGJ1cyAwIHNjYnVzNiB0YXJnZXQgMCBsdW4gMAphZGEwOiA8V0RDIFdEMTAw MkZBRVgtMDBaM0EwIDA1LjAxRDA1PiBBVEEtOCBTQVRBIDIueCBkZXZpY2UKYWRhMDogMzAwLjAw ME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTYsIFBJTyA4MTkyYnl0ZXMpCmFkYTA6IENv bW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEwOiA5NTM4NjlNQiAoMTk1MzUyNTE2OCA1MTIgYnl0 ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTYzODNDKQphZGEwOiBQcmV2aW91c2x5IHdhcyBrbm93biBh cyBhZDE2ClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQpUaW1lY291bnRlciAiVFNDLWxvdyIgZnJl cXVlbmN5IDE0MDYzMjc1IEh6IHF1YWxpdHkgMTAwMApjZDAgYXQgYXRhMiBidXMgMCBzY2J1czAg dGFyZ2V0IDAgbHVuIDAKY2QwOiA8SEwtRFQtU1QgRFZEUkFNIEdTQS1INDJMIFNMMDA+IFJlbW92 YWJsZSBDRC1ST00gU0NTSS0wIGRldmljZSAKY2QwOiA2Ni43MDBNQi9zIHRyYW5zZmVycyAoVURN QTQsIEFUQVBJIDEyYnl0ZXMsIFBJTyA2NTUzNGJ5dGVzKQpjZDA6IEF0dGVtcHQgdG8gcXVlcnkg ZGV2aWNlIHNpemUgZmFpbGVkOiBOT1QgUkVBRFksIE1lZGl1bSBub3QgcHJlc2VudApjZDEgYXQg YXRhMiBidXMgMCBzY2J1czAgdGFyZ2V0IDEgbHVuIDAKY2QxOiA8TElURS1PTiBDRC1SVyBTT0hS LTUyMzhTIDRTMDQ+IFJlbW92YWJsZSBDRC1ST00gU0NTSS0wIGRldmljZSAKY2QxOiAzMy4zMDBN Qi9zIHRyYW5zZmVycyAoVURNQTIsIEFUQVBJIDEyYnl0ZXMsIFBJTyA2NTUzNGJ5dGVzKQpjZDE6 IEF0dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNpemUgZmFpbGVkOiBOT1QgUkVBRFksIE1lZGl1bSBu b3QgcHJlc2VudApSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czcgdXNidXMzCnVodWIzOiA2 IHBvcnRzIHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViNzogNiBwb3J0cyB3aXRo IDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM3 CnVnZW43LjI6IDx2ZW5kb3IgMHgwNDZkPiBhdCB1c2J1czcKdWF1ZGlvMDogPHZlbmRvciAweDA0 NmQgcHJvZHVjdCAweDA4MWIsIGNsYXNzIDIzOS8yLCByZXYgMi4wMC8wLjEwLCBhZGRyIDI+IG9u IHVzYnVzNwp1YXVkaW8wOiBObyBwbGF5YmFjayEKdWF1ZGlvMDogUmVjb3JkOiA0ODAwMCBIeiwg MSBjaCwgMTYtYml0IFMtTEUgUENNIGZvcm1hdAp1YXVkaW8wOiBObyBtaWRpIHNlcXVlbmNlcgpw Y200OiA8VVNCIGF1ZGlvPiBvbiB1YXVkaW8wClRyeWluZyB0byBtb3VudCByb290IGZyb20gemZz OnRhbmswIFtdLi4uCnVnZW42LjI6IDxNaWNyb3NvZnQ+IGF0IHVzYnVzNgpTZXR0aW5nIGhvc3R1 dWlkOiAwMDdhZThjMC0wMDAxLWRlMTEtYTg5OS0wMDI0OGM0NzFjZmYuClNldHRpbmcgaG9zdGlk OiAweDA5ZmIxZGYyLgpFbnRyb3B5IGhhcnZlc3Rpbmc6IGludGVycnVwdHMgZXRoZXJuZXQgcG9p bnRfdG9fcG9pbnQga2lja3N0YXJ0LgpTdGFydGluZyBmaWxlIHN5c3RlbSBjaGVja3M6Ci9kZXYv bGFiZWwvYm9vdDA6IDM4MzAgZmlsZXMsIDE3MzkwOSB1c2VkLCA4NDAxOCBmcmVlICg0NTggZnJh Z3MsIDEwNDQ1IGJsb2NrcywgMC4yJSBmcmFnbWVudGF0aW9uKQpNb3VudGluZyBsb2NhbCBmaWxl IHN5c3RlbXM6LgpTZXR0aW5nIGhvc3RuYW1lOiBiZWFzdGllLgp2Ym94ZHJ2OiBmQXN5bmM9MCBv ZmZNaW49MHg0NTMgb2ZmTWF4PTB4Yjc2CnZib3huZXQwOiBFdGhlcm5ldCBhZGRyZXNzOiAwYTow MDoyNzowMDowMDowMApTdGFydGluZyBOZXR3b3JrOiBsbzAgYWxlMCBybDAuCmxvMDogZmxhZ3M9 ODA0OTxVUCxMT09QQkFDSyxSVU5OSU5HLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE2Mzg0Cglv cHRpb25zPTM8UlhDU1VNLFRYQ1NVTT4KCWluZXQgMTI3LjAuMC4xIG5ldG1hc2sgMHhmZjAwMDAw MCAKYWxlMDogZmxhZ3M9ODg0MzxVUCxCUk9BRENBU1QsUlVOTklORyxTSU1QTEVYLE1VTFRJQ0FT VD4gbWV0cmljIDAgbXR1IDE1MDAKCW9wdGlvbnM9YzMxOWE8VFhDU1VNLFZMQU5fTVRVLFZMQU5f SFdUQUdHSU5HLFZMQU5fSFdDU1VNLFRTTzQsV09MX01DQVNULFdPTF9NQUdJQyxWTEFOX0hXVFNP LExJTktTVEFURT4KCWV0aGVyIDAwOjI0OjhjOjQ3OjFjOmZmCgltZWRpYTogRXRoZXJuZXQgYXV0 b3NlbGVjdCAobm9uZSkKCXN0YXR1czogbm8gY2FycmllcgpybDA6IGZsYWdzPTg4NDM8VVAsQlJP QURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCglvcHRp b25zPTM4MDg8VkxBTl9NVFUsV09MX1VDQVNULFdPTF9NQ0FTVCxXT0xfTUFHSUM+CglldGhlciAw MDoyNDowMToyZjphNTo4ZgoJbWVkaWE6IEV0aGVybmV0IGF1dG9zZWxlY3QgKG5vbmUpCglzdGF0 dXM6IG5vIGNhcnJpZXIKU3RhcnRpbmcgZGV2ZC4KU3RhcnRpbmcgd2ViY2FtZC4KQXR0YWNoZWQg dWdlbjcuMlswXSB0byBjdXNlIHVuaXQgLTEKU3RhcnRpbmcgd2ViY2FtZC4KQXR0YWNoZWQgdWdl bjcuMlswXSB0byBjdXNlIHVuaXQgLTEKdW1zMDogPE1pY3Jvc29mdCBNaWNyb3NvZnQgNS1CdXR0 b24gTW91c2Ugd2l0aCBJbnRlbGxpRXllVE0sIGNsYXNzIDAvMCwgcmV2IDEuMTAvMy4wMCwgYWRk ciAyPiBvbiB1c2J1czYKdW1zMDogNSBidXR0b25zIGFuZCBbWFlaXSBjb29yZGluYXRlcyBJRD0w ClN0YXJ0aW5nIHVtczAgbW91c2VkLgpXYWl0aW5nIDMwcyBmb3IgdGhlIGRlZmF1bHQgcm91dGUg aW50ZXJmYWNlOiAoYWxlMCkKRUxGIGxkY29uZmlnIHBhdGg6IC9saWIgL3Vzci9saWIgL3Vzci9s aWIvY29tcGF0IC91c3IvbG9jYWwvbGliIC91c3IvbG9jYWwvbGliL2NvbXBhdCAvdXNyL2xvY2Fs L2xpYi9ldmVudDIgL3Vzci9sb2NhbC9saWIvZ2VnbC0wLjEgL3Vzci9sb2NhbC9saWIvZ3JhcGh2 aXogL3Vzci9sb2NhbC9saWIvbGlieHVsIC91c3IvbG9jYWwvbGliL25zcyAvdXNyL2xvY2FsL2xp Yi9xdDQgL3Vzci9sb2NhbC9saWIvdmlydHVhbGJveAozMi1iaXQgY29tcGF0aWJpbGl0eSBsZGNv bmZpZyBwYXRoOiAvdXNyL2xpYjMyIC91c3IvbG9jYWwvbGliMzIvY29tcGF0CkNyZWF0aW5nIGFu ZC9vciB0cmltbWluZyBsb2cgZmlsZXMuClN0YXJ0aW5nIHN5c2xvZ2QuCnNhdmVjb3JlOiByZWJv b3QgYWZ0ZXIgcGFuaWM6IHBhZ2UgZmF1bHQKU2VwIDE2IDIyOjQxOjI2IGJlYXN0aWUgc2F2ZWNv cmU6IHJlYm9vdCBhZnRlciBwYW5pYzogcGFnZSBmYXVsdApzYXZlY29yZTogd3JpdGluZyBjb3Jl IHRvIHZtY29yZS4zCldyaXRpbmcgY3Jhc2ggc3VtbWFyeSB0byAvdmFyL2NyYXNoL2NvcmUudHh0 LjMuCkFkZGl0aW9uYWwgQUJJIHN1cHBvcnQ6IGxpbnV4LgpDbGVhcmluZyAvdG1wIChYIHJlbGF0 ZWQpLgpVcGRhdGluZyBtb3RkOi4KU3RhcnRpbmcgZnVzZWZzLgpmdXNlNGJzZDogdmVyc2lvbiAw LjMuOS1wcmUxLCBGVVNFIEFCSSA3LjgKU3RhcnRpbmcgc2xpbS4KU3RhcnRpbmcgZGJ1cy4KU3Rh cnRpbmcgaGFsZC4KU3RhcnRpbmcgZGRjbGllbnQuClN0YXJ0aW5nIGJsb2Nrc3NoZC4KU2VwIDE2 IDIyOjQyOjMwIGJlYXN0aWUgYmxvY2tzc2hkWzE5OTVdOiBTdGFydGluZyBCbG9ja1NTSEQKU2Vw IDE2IDIyOjQyOjMwIGJlYXN0aWUgYmxvY2tzc2hkWzE5OTVdOiBGbHVzaGluZyBleGlzdGluZyBy dWxlcyBpbiBibG9ja3NzaGQuCkNvbmZpZ3VyaW5nIHN5c2NvbnM6IGJsYW5rdGltZS4KU2VwIDE2 IDIyOjQyOjMwIGJlYXN0aWUgYmxvY2tzc2hkWzE5OTVdOiBVbmFibGUgdG8gZmx1c2ggZXhpc3Rp bmcgZmlyZXdhbGxzIHJ1bGVzIGZyb20gYmxvY2tzc2hkClN0YXJ0aW5nIHNzaGQuClN0YXJ0aW5n IGNyb24uClN0YXJ0aW5nIGJhY2tncm91bmQgZmlsZSBzeXN0ZW0gY2hlY2tzIGluIDYwIHNlY29u ZHMuCgpGcmkgU2VwIDE2IDIyOjQyOjMyIENFU1QgMjAxMQoKCkZhdGFsIHRyYXAgMTI6IHBhZ2Ug ZmF1bHQgd2hpbGUgaW4ga2VybmVsIG1vZGUKY3B1aWQgPSAwOyBhcGljIGlkID0gMDAKZmF1bHQg dmlydHVhbCBhZGRyZXNzCT0gMHg4CmZhdWx0IGNvZGUJCT0gc3VwZXJ2aXNvciByZWFkIGRhdGEs IHBhZ2Ugbm90IHByZXNlbnQKaW5zdHJ1Y3Rpb24gcG9pbnRlcgk9IDB4MjA6MHhmZmZmZmZmZjgw M2RkNTg1CnN0YWNrIHBvaW50ZXIJICAgICAgICA9IDB4Mjg6MHhmZmZmZmY4MTFkNTBmNmIwCmZy YW1lIHBvaW50ZXIJICAgICAgICA9IDB4Mjg6MHhmZmZmZmY4MTFkNTBmNmUwCmNvZGUgc2VnbWVu dAkJPSBiYXNlIDB4MCwgbGltaXQgMHhmZmZmZiwgdHlwZSAweDFiCgkJCT0gRFBMIDAsIHByZXMg MSwgbG9uZyAxLCBkZWYzMiAwLCBncmFuIDEKcHJvY2Vzc29yIGVmbGFncwk9IGludGVycnVwdCBl bmFibGVkLCByZXN1bWUsIElPUEwgPSAwCmN1cnJlbnQgcHJvY2VzcwkJPSAyMTI4IChoYWxkKQp0 cmFwIG51bWJlcgkJPSAxMgpwYW5pYzogcGFnZSBmYXVsdApjcHVpZCA9IDAKVXB0aW1lOiAxbTIz cwpEdW1waW5nIDIwMzYgb3V0IG9mIDQwNjcgTUI6Li4xJS4uMTElLi4yMSUuLjMxJS4uNDElLi41 MSUuLjYxJS4uNzElLi44MSUuLjkxJQoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCmtlcm5lbCBjb25maWcKCm9w dGlvbnMJQ09ORklHX0FVVE9HRU5FUkFURUQKaWRlbnQJQkVBU1RJRQptYWNoaW5lCWFtZDY0CmNw dQlIQU1NRVIKbWFrZW9wdGlvbnMJREVCVUc9LWcKb3B0aW9ucwlWRVNBCm9wdGlvbnMJUDEwMDNf MUJfU0VNQVBIT1JFUwpvcHRpb25zCUxJTlNZU0ZTCm9wdGlvbnMJTElOUFJPQ0ZTCm9wdGlvbnMJ Q09NUEFUX0xJTlVYMzIKb3B0aW9ucwlVU0JfREVCVUcKb3B0aW9ucwlTQ19QSVhFTF9NT0RFCm9w dGlvbnMJQVRBX1NUQVRJQ19JRApvcHRpb25zCUFUQV9DQU0Kb3B0aW9ucwlTTVAKb3B0aW9ucwlJ TkNMVURFX0NPTkZJR19GSUxFCm9wdGlvbnMJTUFDCm9wdGlvbnMJQVVESVQKb3B0aW9ucwlIV1BN Q19IT09LUwpvcHRpb25zCUtCRF9JTlNUQUxMX0NERVYKb3B0aW9ucwlQUklOVEZfQlVGUl9TSVpF PTEyOApvcHRpb25zCV9LUE9TSVhfUFJJT1JJVFlfU0NIRURVTElORwpvcHRpb25zCVNZU1ZTRU0K b3B0aW9ucwlTWVNWTVNHCm9wdGlvbnMJU1lTVlNITQpvcHRpb25zCVNUQUNLCm9wdGlvbnMJS1RS QUNFCm9wdGlvbnMJU0NTSV9ERUxBWT01MDAwCm9wdGlvbnMJQ09NUEFUX0ZSRUVCU0Q3Cm9wdGlv bnMJQ09NUEFUX0ZSRUVCU0Q2Cm9wdGlvbnMJQ09NUEFUX0ZSRUVCU0QzMgpvcHRpb25zCUdFT01f TEFCRUwKb3B0aW9ucwlQU0VVRE9GUwpvcHRpb25zCVBST0NGUwpvcHRpb25zCUNEOTY2MApvcHRp b25zCU1TRE9TRlMKb3B0aW9ucwlORlNMT0NLRApvcHRpb25zCU1EX1JPT1QKb3B0aW9ucwlVRlNf R0pPVVJOQUwKb3B0aW9ucwlVRlNfRElSSEFTSApvcHRpb25zCVVGU19BQ0wKb3B0aW9ucwlTT0ZU VVBEQVRFUwpvcHRpb25zCUZGUwpvcHRpb25zCVNDVFAKb3B0aW9ucwlJTkVUCm9wdGlvbnMJUFJF RU1QVElPTgpvcHRpb25zCVNDSEVEX1VMRQpvcHRpb25zCU5FV19QQ0lCCm9wdGlvbnMJR0VPTV9Q QVJUX01CUgpvcHRpb25zCUdFT01fUEFSVF9FQlJfQ09NUEFUCm9wdGlvbnMJR0VPTV9QQVJUX0VC UgpvcHRpb25zCUdFT01fUEFSVF9CU0QKZGV2aWNlCWlzYQpkZXZpY2UJbWVtCmRldmljZQlpbwpk ZXZpY2UJdWFydF9uczgyNTAKZGV2aWNlCWNwdWZyZXEKZGV2aWNlCWFjcGkKZGV2aWNlCXBjaQpk ZXZpY2UJYWhjaQpkZXZpY2UJYXRhCmRldmljZQlzY2J1cwpkZXZpY2UJZGEKZGV2aWNlCXNhCmRl dmljZQljZApkZXZpY2UJcGFzcwpkZXZpY2UJYXRrYmRjCmRldmljZQlhdGtiZApkZXZpY2UJcHNt CmRldmljZQlrYmRtdXgKZGV2aWNlCXZnYQpkZXZpY2UJc3BsYXNoCmRldmljZQlzYwpkZXZpY2UJ Y2JiCmRldmljZQlwY2NhcmQKZGV2aWNlCWNhcmRidXMKZGV2aWNlCXVhcnQKZGV2aWNlCXBwYwpk ZXZpY2UJcHBidXMKZGV2aWNlCWxwdApkZXZpY2UJcGxpcApkZXZpY2UJcHBpCmRldmljZQltaWli dXMKZGV2aWNlCWFsZQpkZXZpY2UJcmwKZGV2aWNlCWxvb3AKZGV2aWNlCXJhbmRvbQpkZXZpY2UJ ZXRoZXIKZGV2aWNlCXR1bgpkZXZpY2UJcHR5CmRldmljZQltZApkZXZpY2UJZmlybXdhcmUKZGV2 aWNlCWJwZgpkZXZpY2UJdWhjaQpkZXZpY2UJb2hjaQpkZXZpY2UJZWhjaQpkZXZpY2UJeGhjaQpk ZXZpY2UJdXNiCmRldmljZQl1aGlkCmRldmljZQl1bHB0CmRldmljZQl1bWFzcwpkZXZpY2UJdXJp bwpkZXZpY2UJdWlwYXEKZGV2aWNlCXNvdW5kCmRldmljZQlzbmRfaGRhCmRldmljZQlzbmRfdWF1 ZGlvCmRldmljZQlsaW5kZXYKZGV2aWNlCWF0YXBpY2FtCmRldmljZQlwZgpkZXZpY2UJcGZsb2cK ZGV2aWNlCXBmc3luYwoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCmRkYiBjYXB0dXJlIGJ1ZmZlcgoKZGRiOiBk ZGJfY2FwdHVyZToga3ZtX25saXN0Cg== --20cf307f375e08272604ad34ead8-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 11:56:52 2011 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 A3DED106566B; Sun, 18 Sep 2011 11:56:52 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 3F87D8FC15; Sun, 18 Sep 2011 11:56:52 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id D6CF5358C4E; Sun, 18 Sep 2011 13:56:50 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id CD69517467; Sun, 18 Sep 2011 13:56:50 +0200 (CEST) Date: Sun, 18 Sep 2011 13:56:50 +0200 From: Jilles Tjoelker To: Kostik Belousov Message-ID: <20110918115650.GA36162@stack.nl> References: <20110914123607.GM65366@felucia.tataz.chchile.org> <20110914125953.GX17489@deviant.kiev.zoral.com.ua> <20110914154221.GB7863@felucia.tataz.chchile.org> <20110914200456.GE17489@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110914200456.GE17489@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Peter Pentchev , freebsd-current@freebsd.org, Jeremie Le Hen , David Xu , Oliver Lehmann Subject: Re: Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW) 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, 18 Sep 2011 11:56:52 -0000 On Wed, Sep 14, 2011 at 11:04:56PM +0300, Kostik Belousov wrote: > tzload() allocates ~80KB for the local variables. The backtrace you provided > shows the nested call to tzload(), so there is total 160KB of the stack > space consumed. > By default, stack for the amd64 thread is 4MB, that should be plenty. This > is not the case for ezm3. Possibly, stunnel also reduces the size of the > thread stack. > Please, try the patch below. I did not tested it, only compiled. I see > that now tzload allocates only ~300 bytes on the stack. 80KB seems quite a lot indeed, good to bring it down. > diff --git a/contrib/tzcode/stdtime/localtime.c b/contrib/tzcode/stdtime/localtime.c > index 80b70ac..55d55e0 100644 > --- a/contrib/tzcode/stdtime/localtime.c > +++ b/contrib/tzcode/stdtime/localtime.c [snip] > @@ -406,16 +409,24 @@ register const int doextend; > ** to hold the longest file name string that the implementation > ** guarantees can be opened." > */ > - char fullname[FILENAME_MAX + 1]; > + char *fullname; > + > + fullname = malloc(FILENAME_MAX + 1); > + if (fullname == NULL) > + goto out; > > if (name[0] == ':') > ++name; > doaccess = name[0] == '/'; > if (!doaccess) { > - if ((p = TZDIR) == NULL) > + if ((p = TZDIR) == NULL) { > + free(fullname); > return -1; > - if ((strlen(p) + 1 + strlen(name) + 1) >= sizeof fullname) > + } > + if ((strlen(p) + 1 + strlen(name) + 1) >= sizeof fullname) { This sizeof is now the sizeof of a pointer. The comparison should be against FILENAME_MAX + 1 instead. Alternatively, the name could be created using asprintf(). -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 12:46:27 2011 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 0AF0110657D2 for ; Sun, 18 Sep 2011 12:46:27 +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 3798E8FC17 for ; Sun, 18 Sep 2011 12:46:25 +0000 (UTC) Received: (qmail 36661 invoked by uid 80); 18 Sep 2011 12:46:24 -0000 Received: from dsdf-4db53ddf.pool.mediaWays.net (dsdf-4db53ddf.pool.mediaWays.net [77.181.61.223]) by avocado.salatschuessel.net (Horde Framework) with HTTP; Sun, 18 Sep 2011 14:46:24 +0200 Date: Sun, 18 Sep 2011 14:46:24 +0200 Message-ID: <20110918144624.Horde.NmhwTKQd9PdOdeggfTJhVsc@avocado.salatschuessel.net> From: Oliver Lehmann To: Kostik Belousov References: <20110908221356.Horde.MFEsZ6Qd9PdOaSIEaid2X_A@avocado.salatschuessel.net> <4E692F87.5010708@sentex.net> <20110909073305.Horde.oi-EGaQd9PdOaaURAsTRVJk@avocado.salatschuessel.net> <4E6A076D.7040309@wintek.com> <20110918122253.Horde.tJj2ZaQd9PdOdcZ9N4nRVsI@avocado.salatschuessel.net> <20110918102741.GV1511@deviant.kiev.zoral.com.ua> In-Reply-To: <20110918102741.GV1511@deviant.kiev.zoral.com.ua> User-Agent: Internet Messaging Program (IMP) H4 (5.0.11) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Cc: Adrian Chadd , freebsd-current , Alexander Zagrebin Subject: Re: cvsup broken on 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: Sun, 18 Sep 2011 12:46:27 -0000 Kostik Belousov wrote: > Did you saw the message with the patch for tzcode I mailed to you ? Mmmh... no didn't reached my mailbox - can you resend it please? From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 13:45:06 2011 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 A6E0F106564A for ; Sun, 18 Sep 2011 13:45:06 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.94]) by mx1.freebsd.org (Postfix) with ESMTP id 5FD728FC1B for ; Sun, 18 Sep 2011 13:45:06 +0000 (UTC) Received: from [87.79.159.218] (helo=fabiankeil.de) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1R5Hg8-0007zK-S4; Sun, 18 Sep 2011 15:45:04 +0200 Date: Sun, 18 Sep 2011 15:44:55 +0200 From: Fabian Keil To: Andrew Thompson Message-ID: <20110918154455.208425e4@fabiankeil.de> In-Reply-To: <201109042206.p84M6W8e008867@svn.freebsd.org> References: <201109042206.p84M6W8e008867@svn.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/O.ZD.f_jZsQCx0nytWElGuO"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-current@freebsd.org Subject: Re: svn commit: r225380 - head/sys/net 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, 18 Sep 2011 13:45:06 -0000 --Sig_/O.ZD.f_jZsQCx0nytWElGuO Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andrew Thompson wrote: > Author: thompsa > Date: Sun Sep 4 22:06:32 2011 > New Revision: 225380 > URL: http://svn.freebsd.org/changeset/base/225380 >=20 > Log: > On the first loop for generating a bridge MAC address use the local > hostid, this gives a good chance of keeping the same address over > reboots. This is intended to help IPV6 and similar which generate > their addresses from the mac. > =20 > PR: kern/160300 > Submitted by: mdodd > Approved by: re (kib) >=20 > Modified: > head/sys/net/if_bridge.c Are there other places where the system advertises the hostid on the network? I always assumed it to be a somewhat private identifier, so I'm a bit surprised by this commit. BTW, the man page still claims that the MAC address is chosen randomly. Fabian --Sig_/O.ZD.f_jZsQCx0nytWElGuO Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk519egACgkQBYqIVf93VJ2EkgCgvfaMkQDVaWm25hj4+QpLw0Bl YtgAoLZ37iyv/gNLzn3GD2rTIuA925Fs =Ynlu -----END PGP SIGNATURE----- --Sig_/O.ZD.f_jZsQCx0nytWElGuO-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 13:53:33 2011 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 A855A106566C for ; Sun, 18 Sep 2011 13:53:33 +0000 (UTC) (envelope-from olivares14031@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 759138FC13 for ; Sun, 18 Sep 2011 13:53:33 +0000 (UTC) Received: by iadk27 with SMTP id k27so6801923iad.13 for ; Sun, 18 Sep 2011 06:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=C4uGFPlkQmqLSRCazc1CviLlPu+SnCS9BQjNFzVk8GA=; b=Q5Su8DPmkyeayJssb2ApmtZ1gPvqKwuWXFWbFWOyLYJqBlqNipxZMTtC1yeLNO96jB l4iJ5lUn9czHADgKDy9KrYPhPrtJJzcEIAUgtRriyhO2GZMCBaDC8neCs46tOvxLIp7l afzEjlIzmN2NhtzmJotoRPR6xQ8eId4qWfbGE= MIME-Version: 1.0 Received: by 10.42.137.1 with SMTP id w1mr2597065ict.29.1316354012135; Sun, 18 Sep 2011 06:53:32 -0700 (PDT) Received: by 10.42.177.199 with HTTP; Sun, 18 Sep 2011 06:53:32 -0700 (PDT) In-Reply-To: <20110918095526.D866D1065670@hub.freebsd.org> References: <20110918095526.D866D1065670@hub.freebsd.org> Date: Sun, 18 Sep 2011 08:53:32 -0500 Message-ID: From: Antonio Olivares To: "Thomas Mueller List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 13:53:33 -0000 On Sun, Sep 18, 2011 at 4:55 AM, <"Thomas Mueller wrote: > Some more ideas on the new bsdinstaller cross my mind. > > Since the way the bsdinstaller would make partitions is unpredictable, at= least to the uninitiated, and in all likelihood at variance with how much = space the user wants to allocate, it might be better to offer a roadmap to = help guide the user to allocating space for FreeBSD using gpart or Rod Smit= h's gdisk. > > Also, I can't see the function of the 64 KB boot partition with no file s= ystem, which does not boot for me, though I can boot the main partition usi= ng grub2 from the System Rescue CD (http://sysresccd.org/). > > Another concern is updating to the next beta (BETA3?) without trashing th= e installed application software (from ports). =A0So far, bsdinstaller hasn= 't offered any possibility of upgrading an existing installation. =A0I don'= t think a user wants to rebuild all ports for every new beta or release can= didate. > This also concerns me. I wanted to ask, if one updates 9.0-BETA 2 through ports, if it was the same as a possible BETA-3? and the big question, if updating, does one have to build all the ports? or when one updates BETA-2, do we really have BETA-3 already? What I would question, is that the choices are offered, but one has to use (+) or (-) keys instead of the up arrow/down arrow to select the packages. When I installed it on an amd64 bit machine, I wanted to select src/ and kernel + base, but I did not know how to change, later I found out that + or - keys would change the selections, I pressed enter and then I could not go back to previous screen. With sysinstall I knew how to go back and forth between the screens, but with bsdinstall it is completely revamped. > > Tom Regards, Antonio From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 14:00:41 2011 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 24E4E1065674 for ; Sun, 18 Sep 2011 14:00:41 +0000 (UTC) (envelope-from olivares14031@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E9BFF8FC18 for ; Sun, 18 Sep 2011 14:00:40 +0000 (UTC) Received: by iadk27 with SMTP id k27so6808693iad.13 for ; Sun, 18 Sep 2011 07:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=I65iMcE3jC5l9q2cqPASnxKtWGGvhIhza8Gj5hTpqnU=; b=Uar/EQDHVCifZfJ6vUefnSNClp7vEpqEYSKouTcbJcroAMb/ASnbu/5MzvR0tAuSm8 b5UaJHCo3dGTEob4JgUFrf3KhaPzURxXdxXHICDkqUOooHQakM0WSmZjwiKeG2kPjQgb wwjwL12ffqbSPT2xPBtCzI1jnpeeMO9kjqqgE= MIME-Version: 1.0 Received: by 10.42.158.72 with SMTP id g8mr2655830icx.145.1316354439083; Sun, 18 Sep 2011 07:00:39 -0700 (PDT) Received: by 10.42.177.199 with HTTP; Sun, 18 Sep 2011 07:00:39 -0700 (PDT) Date: Sun, 18 Sep 2011 09:00:39 -0500 Message-ID: From: Antonio Olivares To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: How does one install kernel sources and base 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, 18 Sep 2011 14:00:41 -0000 Dear folks, I have installed 9.0 - BETA 2, and I had no x, when I typed startx, some folks have suggested to check if I have xorg-server, I will do that as soon as I get to my machine on Monday. Also I will check if I put into /etc/rc.conf, hald_enable="YES" and dbus_enable="YES" as well, otherwise startx will not work. But my question is as follows, How do I get kernel sources and base installed? I tried sysinstall and used configure -> distributions -> kernel + sys + base as outlined in http://www.cyberciti.biz/faq/freebsd-install-kernel-source-code/ Did not work, got mirrors but timed out errors, I went through most mirrors in Japan, Sweden, USA, and it appears not to be found. I tried bsdinstall and reinserted 9.0-BETA2-amd64-dvd1 into drive and it would not mount and would return an error. I have read about using cvs or something like it, but I have not used it and would like some pointers on how to use it, or other form that would work to install kernel sources so I could try nvidia-driver since X was not working and nv driver is too old and might not work as one would like it to. Thanks in Advance for comments/advice/suggestions. Regards, Antonio From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 14:04:06 2011 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 8E555106566C for ; Sun, 18 Sep 2011 14:04:06 +0000 (UTC) (envelope-from olivares14031@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5A60D8FC14 for ; Sun, 18 Sep 2011 14:04:06 +0000 (UTC) Received: by iadk27 with SMTP id k27so6812038iad.13 for ; Sun, 18 Sep 2011 07:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zA1i892pv1oNTGdvqm7pw1OnLaAAssL8nYruXt/jDYM=; b=xy6+FBf2szk4ZhKY8UGh77OKQ9SB5sTgaTvHJa0ToaVq6j5XOM2+Q4WoQeNjApRDdj Jn9zJpuvzwewlNVUVhEnliH273To1dl9TxUH1VuPClJ8Ibjrtdj6IkooVJ7xiAkaWa+X WWGkjIcNpQt87+aej6HhwnhQwGmUyEnZXYLJs= MIME-Version: 1.0 Received: by 10.42.137.1 with SMTP id w1mr2611203ict.29.1316354644072; Sun, 18 Sep 2011 07:04:04 -0700 (PDT) Received: by 10.42.177.199 with HTTP; Sun, 18 Sep 2011 07:04:04 -0700 (PDT) In-Reply-To: References: <20110918042853.3D61C106566C@hub.freebsd.org> Date: Sun, 18 Sep 2011 09:04:04 -0500 Message-ID: From: Antonio Olivares To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, "Thomas Mueller List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 14:04:06 -0000 On Sat, Sep 17, 2011 at 11:36 PM, Garrett Cooper wrote= : > On Sat, Sep 17, 2011 at 9:28 PM, =A0<"Thomas Mueller > wrote: >>> I have successfully installed FreeBSD-9.0-BETA2 to an amd64 bit >>> machine, I have used the ports to install xfce and xorg. =A0When I type >>> startx, I get a screen with a bunch of colors no mouse, no keyboard, >>> just colors. =A0The machine has nvidia onboard graphics. =A0I am trying= to >>> get kernel sources installed via sysinstall to install nvidia-driver >>> but I can't get anywhere from any ftp site I select at random. =A0I hav= e >>> updated to latest sources available on the ports and it comes up the >>> same. =A0I have to use the nv driver, should I try the nouveau driver? >>> What should I do? =A0I want to help in testing and have no way to repor= t >>> bugs as without X there's not much one can do :( >> >>> Is it not automatically installed when one goes into >>> /usr/ports/x11/xorg, and runs make install clean? >> >> You would get the xorg server with the xorg metaport/megaport. >> >> One thing I can think of is a little dirty trick I have seen in FreeBSD = but not NetBSD or Linux, X comes up but no response to mouse or keyboard. >> >> I ran startx, got twm with its windows, but no response to mouse or keyb= oard. >> >> Cure was, to include in /etc/rc.conf >> >> >> hald_enable=3D"YES" >> dbus_enable=3D"YES" > > =A0 =A0This seems like more of a question@ issue. > =A0 =A0I doubt that the above claim is at fault, given past experience. > What does /var/log/Xorg.0.log say, and what does your xorg.conf > contain? > Thanks, > -Garrett > I will check on Monday as soon as I get to my machine to see if I have these in /etc/rc.conf and also output what is in /var/log/Xorg.0.log(if I can get to X to save it). Could it be that xorg-server is not installed? I have been fortunate to install xfce + xorg and things just worked(TM) for me. I will get back as soon as I have some results. Thank you all who have dropped some suggestions. Regards, Antonio From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 14:12:36 2011 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 4CEAB106566B for ; Sun, 18 Sep 2011 14:12:36 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id CE4BD8FC08 for ; Sun, 18 Sep 2011 14:12:35 +0000 (UTC) Received: by fxg9 with SMTP id 9so4233640fxg.13 for ; Sun, 18 Sep 2011 07:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=Gc2K1oW0qSiLMPIWqCoDveD1odAk9hrqNKfPcF5g0lY=; b=fSuzY/tDACrFkgEAtoXnWGV6KNDkRoxegBdlVI3jFYi93Vo3uVsrWphqYUheoVnmmf 8B/2EGCQrRvWQKOHxIvIgs0leNmTh2tmuXN52UFZ5yqeFKxaDJn640kkkNY5tcaQrxKa wkGHb+Ivo9bfwPoVcjIpBA0v2nxSJpkHOe2sA= Received: by 10.223.98.146 with SMTP id q18mr3355714fan.57.1316353566454; Sun, 18 Sep 2011 06:46:06 -0700 (PDT) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id f25sm18344218faf.7.2011.09.18.06.46.03 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Sep 2011 06:46:03 -0700 (PDT) From: Mikolaj Golub To: Anton Yuzhaninov References: <4E5E46A4.3060705@citrin.ru> <4E6A99A9.1000204@delphij.net> X-Comment-To: Anton Yuzhaninov Sender: Mikolaj Golub Date: Sun, 18 Sep 2011 16:46:01 +0300 In-Reply-To: (Anton Yuzhaninov's message of "Wed, 14 Sep 2011 06:17:45 +0000 (UTC)") Message-ID: <864o0adkva.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: truss 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, 18 Sep 2011 14:12:36 -0000 On Wed, 14 Sep 2011 06:17:45 +0000 (UTC) Anton Yuzhaninov wrote to Xin LI: AY> On Fri, 09 Sep 2011 15:56:41 -0700, Xin LI wrote: XL>> -----BEGIN PGP SIGNED MESSAGE----- XL>> Hash: SHA256 XL>> XL>> On 08/31/11 07:35, Anton Yuzhaninov wrote: >>> It seems to be truss(1) is broken on current >>> >>> :~> truss /bin/echo x x truss: can not get etype: No such process >>> >>> FreeBSD 9.0-BETA1 #0 r224884M i386 >>> >>> from ktrace of turss >>> >>> 3162 truss CALL >>> __sysctl(0xbfbfea00,0x4,0xbfbfe9e0,0xbfbfea10,0,0) 3162 truss >>> SCTL "kern.proc.sv_name.3163" 3162 truss RET __sysctl -1 >>> errno 3 No such process XL>> XL>> Can't seem to be reproducable here, did I missed anything? (note that XL>> you may need a full world/kernel build). XL>> AY> Problem still here after svn up and rebuild world/kernel AY> :~> ktrace -t+ truss /usr/bin/true AY> truss: can not get etype: No such process Could you please run ktrace with -i option? The behavior is like if ptrace(PT_TRACE_ME) failed in the child by some reason. Unfortunately, truss does not check this. AY> Full ktrace: AY> http://dl.dropbox.com/u/8798217/tmp/truss_ktrace.txt AY> FreeBSD 9.0-BETA2 #1 r225504M AY> i386 AY> Kernel config is not GENERIC - main difference - DTrace added: AY> http://dl.dropbox.com/u/8798217/tmp/kernconf.txt AY> -- AY> Anton Yuzhaninov AY> _______________________________________________ AY> freebsd-current@freebsd.org mailing list AY> http://lists.freebsd.org/mailman/listinfo/freebsd-current AY> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Mikolaj Golub From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 15:32:26 2011 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 ADBB7106564A for ; Sun, 18 Sep 2011 15:32:26 +0000 (UTC) (envelope-from varga.michal@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 38F8A8FC13 for ; Sun, 18 Sep 2011 15:32:26 +0000 (UTC) Received: by fxg9 with SMTP id 9so4288175fxg.13 for ; Sun, 18 Sep 2011 08:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:organization :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=IaZBps3mTCO9+VrpA6KH8L0RKqYmuGCPGohpeh0rLTk=; b=Yks1SM5yFFzqi/FlPZn+5IXCspHAplOlm3S4IhVgeWnB1MY8589irNmYdj/bRc3bBx OBH+rCd6kmQRiQ4whrWakPl6NtppppM0x98/hqOawJF9TeXwtEW4UGOEgftWPODD9xQI h2W2xQ9Etx/mjikjBUxJoqAexkJokEVZ/Ua8k= Received: by 10.223.88.23 with SMTP id y23mr3523398fal.95.1316359945193; Sun, 18 Sep 2011 08:32:25 -0700 (PDT) Received: from [10.0.101.2] (254.166.broadband10.iol.cz. [90.177.166.254]) by mx.google.com with ESMTPS id f10sm14079108fac.14.2011.09.18.08.32.22 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Sep 2011 08:32:23 -0700 (PDT) From: Michal Varga To: Antonio Olivares In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Organization: Stonehenge Date: Sun, 18 Sep 2011 17:32:20 +0200 Message-ID: <1316359940.1744.28.camel@xenon> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: How does one install kernel sources and base 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, 18 Sep 2011 15:32:26 -0000 On Sun, 2011-09-18 at 09:00 -0500, Antonio Olivares wrote: > Dear folks, > > I have installed 9.0 - BETA 2, and I had no x, when I typed startx, > some folks have suggested to check if I have xorg-server, I will do > that as soon as I get to my machine on Monday. Also I will check if I > put into /etc/rc.conf, hald_enable="YES" and dbus_enable="YES" as > well, otherwise startx will not work. xorg works very well (and actually much better) without HAL and as far as I know, doesn't even use dbus. Try checking xorg port's config in: # cd /usr/ports/x11-servers/xorg-server/ # make config You can then rebuild your xorg-server port if necessary. Note that for using xorg server without HAL, you will need to configure it properly (see manuals/howtos on xorg.conf, if you never done it before), what was the main 'issue' HAL was originally trying to solve. It failed miserably, which is the reason why newer xorg generations moved away from it and nowadays is only to be found as a sad reminder on FreeBSD. Generally, you will be better off without HAL as it only leads to more failures than running without it. > But my question is as follows, > How do I get kernel sources and base installed? You can download them via csup with a config file similar to this: *default host=cvsup5.FreeBSD.org *default base=/var/db *default prefix=/usr *default release=cvs tag=. *default compress delete use-rel-suffix src-all Save your config file (or so called supfile) someplace and run it as: # csup your.supfile csup will download the latest source tree for kernel and base OS. Also, see FreeBSD Handbook for more information on using csup (or the older, but functionally identical cvsup), and for many other questions regarding general FreeBSD installation and maintenance: http://www.freebsd.org/doc/handbook/cvsup.html m. -- Michal Varga, Stonehenge (Gmail account) From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 15:57:34 2011 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 4338A106564A; Sun, 18 Sep 2011 15:57:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 60B518FC0A; Sun, 18 Sep 2011 15:57:33 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p8IFurB4056854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Sep 2011 18:56:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id p8IFurij095009; Sun, 18 Sep 2011 18:56:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id p8IFunZR095008; Sun, 18 Sep 2011 18:56:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 18 Sep 2011 18:56:49 +0300 From: Kostik Belousov To: Jilles Tjoelker Message-ID: <20110918155649.GY1511@deviant.kiev.zoral.com.ua> References: <20110914123607.GM65366@felucia.tataz.chchile.org> <20110914125953.GX17489@deviant.kiev.zoral.com.ua> <20110914154221.GB7863@felucia.tataz.chchile.org> <20110914200456.GE17489@deviant.kiev.zoral.com.ua> <20110918115650.GA36162@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6749iDyxihQ87e9v" Content-Disposition: inline In-Reply-To: <20110918115650.GA36162@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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Peter Pentchev , freebsd-current@freebsd.org, Jeremie Le Hen , David Xu , Oliver Lehmann Subject: Re: Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW) 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, 18 Sep 2011 15:57:34 -0000 --6749iDyxihQ87e9v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 18, 2011 at 01:56:50PM +0200, Jilles Tjoelker wrote: > On Wed, Sep 14, 2011 at 11:04:56PM +0300, Kostik Belousov wrote: > > tzload() allocates ~80KB for the local variables. The backtrace you pro= vided > > shows the nested call to tzload(), so there is total 160KB of the stack > > space consumed. >=20 > > By default, stack for the amd64 thread is 4MB, that should be plenty. T= his > > is not the case for ezm3. Possibly, stunnel also reduces the size of the > > thread stack. >=20 > > Please, try the patch below. I did not tested it, only compiled. I see > > that now tzload allocates only ~300 bytes on the stack. >=20 > 80KB seems quite a lot indeed, good to bring it down. >=20 > > diff --git a/contrib/tzcode/stdtime/localtime.c b/contrib/tzcode/stdtim= e/localtime.c > > index 80b70ac..55d55e0 100644 > > --- a/contrib/tzcode/stdtime/localtime.c > > +++ b/contrib/tzcode/stdtime/localtime.c > [snip] > > @@ -406,16 +409,24 @@ register const int doextend; > > ** to hold the longest file name string that the implementation > > ** guarantees can be opened." > > */ > > - char fullname[FILENAME_MAX + 1]; > > + char *fullname; > > + > > + fullname =3D malloc(FILENAME_MAX + 1); > > + if (fullname =3D=3D NULL) > > + goto out; > > =20 > > if (name[0] =3D=3D ':') > > ++name; > > doaccess =3D name[0] =3D=3D '/'; > > if (!doaccess) { > > - if ((p =3D TZDIR) =3D=3D NULL) > > + if ((p =3D TZDIR) =3D=3D NULL) { > > + free(fullname); > > return -1; > > - if ((strlen(p) + 1 + strlen(name) + 1) >=3D sizeof fullname) > > + } > > + if ((strlen(p) + 1 + strlen(name) + 1) >=3D sizeof fullname) { >=20 > This sizeof is now the sizeof of a pointer. The comparison should be > against FILENAME_MAX + 1 instead. >=20 > Alternatively, the name could be created using asprintf(). You are right. I fixed the defect. Updated patch below. diff --git a/contrib/tzcode/stdtime/localtime.c b/contrib/tzcode/stdtime/lo= caltime.c index 80b70ac..b1981b6 100644 --- a/contrib/tzcode/stdtime/localtime.c +++ b/contrib/tzcode/stdtime/localtime.c @@ -380,13 +380,16 @@ register const int doextend; int fid; int stored; int nread; + int res; union { struct tzhead tzhead; char buf[2 * sizeof(struct tzhead) + 2 * sizeof *sp + 4 * TZ_MAX_TIMES]; - } u; + } *u; =20 + u =3D NULL; + res =3D -1; sp->goback =3D sp->goahead =3D FALSE; =20 /* XXX The following is from OpenBSD, and I'm not sure it is correct */ @@ -406,16 +409,24 @@ register const int doextend; ** to hold the longest file name string that the implementation ** guarantees can be opened." */ - char fullname[FILENAME_MAX + 1]; + char *fullname; + + fullname =3D malloc(FILENAME_MAX + 1); + if (fullname =3D=3D NULL) + goto out; =20 if (name[0] =3D=3D ':') ++name; doaccess =3D name[0] =3D=3D '/'; if (!doaccess) { - if ((p =3D TZDIR) =3D=3D NULL) + if ((p =3D TZDIR) =3D=3D NULL) { + free(fullname); return -1; - if ((strlen(p) + 1 + strlen(name) + 1) >=3D sizeof fullname) + } + if (strlen(p) + 1 + strlen(name) >=3D FILENAME_MAX) { + free(fullname); return -1; + } (void) strcpy(fullname, p); (void) strcat(fullname, "/"); (void) strcat(fullname, name); @@ -426,37 +437,45 @@ register const int doextend; doaccess =3D TRUE; name =3D fullname; } - if (doaccess && access(name, R_OK) !=3D 0) + if (doaccess && access(name, R_OK) !=3D 0) { + free(fullname); return -1; - if ((fid =3D _open(name, OPEN_MODE)) =3D=3D -1) + } + if ((fid =3D _open(name, OPEN_MODE)) =3D=3D -1) { + free(fullname); return -1; + } if ((_fstat(fid, &stab) < 0) || !S_ISREG(stab.st_mode)) { + free(fullname); _close(fid); return -1; } } - nread =3D _read(fid, u.buf, sizeof u.buf); + u =3D malloc(sizeof(*u)); + if (u =3D=3D NULL) + goto out; + nread =3D _read(fid, u->buf, sizeof u->buf); if (_close(fid) < 0 || nread <=3D 0) - return -1; + goto out; for (stored =3D 4; stored <=3D 8; stored *=3D 2) { int ttisstdcnt; int ttisgmtcnt; =20 - ttisstdcnt =3D (int) detzcode(u.tzhead.tzh_ttisstdcnt); - ttisgmtcnt =3D (int) detzcode(u.tzhead.tzh_ttisgmtcnt); - sp->leapcnt =3D (int) detzcode(u.tzhead.tzh_leapcnt); - sp->timecnt =3D (int) detzcode(u.tzhead.tzh_timecnt); - sp->typecnt =3D (int) detzcode(u.tzhead.tzh_typecnt); - sp->charcnt =3D (int) detzcode(u.tzhead.tzh_charcnt); - p =3D u.tzhead.tzh_charcnt + sizeof u.tzhead.tzh_charcnt; + ttisstdcnt =3D (int) detzcode(u->tzhead.tzh_ttisstdcnt); + ttisgmtcnt =3D (int) detzcode(u->tzhead.tzh_ttisgmtcnt); + sp->leapcnt =3D (int) detzcode(u->tzhead.tzh_leapcnt); + sp->timecnt =3D (int) detzcode(u->tzhead.tzh_timecnt); + sp->typecnt =3D (int) detzcode(u->tzhead.tzh_typecnt); + sp->charcnt =3D (int) detzcode(u->tzhead.tzh_charcnt); + p =3D u->tzhead.tzh_charcnt + sizeof u->tzhead.tzh_charcnt; if (sp->leapcnt < 0 || sp->leapcnt > TZ_MAX_LEAPS || sp->typecnt <=3D 0 || sp->typecnt > TZ_MAX_TYPES || sp->timecnt < 0 || sp->timecnt > TZ_MAX_TIMES || sp->charcnt < 0 || sp->charcnt > TZ_MAX_CHARS || (ttisstdcnt !=3D sp->typecnt && ttisstdcnt !=3D 0) || (ttisgmtcnt !=3D sp->typecnt && ttisgmtcnt !=3D 0)) - return -1; - if (nread - (p - u.buf) < + goto out; + if (nread - (p - u->buf) < sp->timecnt * stored + /* ats */ sp->timecnt + /* types */ sp->typecnt * 6 + /* ttinfos */ @@ -464,7 +483,7 @@ register const int doextend; sp->leapcnt * (stored + 4) + /* lsinfos */ ttisstdcnt + /* ttisstds */ ttisgmtcnt) /* ttisgmts */ - return -1; + goto out; for (i =3D 0; i < sp->timecnt; ++i) { sp->ats[i] =3D (stored =3D=3D 4) ? detzcode(p) : detzcode64(p); @@ -473,7 +492,7 @@ register const int doextend; for (i =3D 0; i < sp->timecnt; ++i) { sp->types[i] =3D (unsigned char) *p++; if (sp->types[i] >=3D sp->typecnt) - return -1; + goto out; } for (i =3D 0; i < sp->typecnt; ++i) { struct ttinfo * ttisp; @@ -483,11 +502,11 @@ register const int doextend; p +=3D 4; ttisp->tt_isdst =3D (unsigned char) *p++; if (ttisp->tt_isdst !=3D 0 && ttisp->tt_isdst !=3D 1) - return -1; + goto out; ttisp->tt_abbrind =3D (unsigned char) *p++; if (ttisp->tt_abbrind < 0 || ttisp->tt_abbrind > sp->charcnt) - return -1; + goto out; } for (i =3D 0; i < sp->charcnt; ++i) sp->chars[i] =3D *p++; @@ -512,7 +531,7 @@ register const int doextend; ttisp->tt_ttisstd =3D *p++; if (ttisp->tt_ttisstd !=3D TRUE && ttisp->tt_ttisstd !=3D FALSE) - return -1; + goto out; } } for (i =3D 0; i < sp->typecnt; ++i) { @@ -525,7 +544,7 @@ register const int doextend; ttisp->tt_ttisgmt =3D *p++; if (ttisp->tt_ttisgmt !=3D TRUE && ttisp->tt_ttisgmt !=3D FALSE) - return -1; + goto out; } } /* @@ -558,11 +577,11 @@ register const int doextend; /* ** If this is an old file, we're done. */ - if (u.tzhead.tzh_version[0] =3D=3D '\0') + if (u->tzhead.tzh_version[0] =3D=3D '\0') break; - nread -=3D p - u.buf; + nread -=3D p - u->buf; for (i =3D 0; i < nread; ++i) - u.buf[i] =3D p[i]; + u->buf[i] =3D p[i]; /* ** If this is a narrow integer time_t system, we're done. */ @@ -570,39 +589,43 @@ register const int doextend; break; } if (doextend && nread > 2 && - u.buf[0] =3D=3D '\n' && u.buf[nread - 1] =3D=3D '\n' && + u->buf[0] =3D=3D '\n' && u->buf[nread - 1] =3D=3D '\n' && sp->typecnt + 2 <=3D TZ_MAX_TYPES) { - struct state ts; + struct state *ts; register int result; =20 - u.buf[nread - 1] =3D '\0'; - result =3D tzparse(&u.buf[1], &ts, FALSE); - if (result =3D=3D 0 && ts.typecnt =3D=3D 2 && - sp->charcnt + ts.charcnt <=3D TZ_MAX_CHARS) { + ts =3D malloc(sizeof(*ts)); + if (ts =3D=3D NULL) + goto out; + u->buf[nread - 1] =3D '\0'; + result =3D tzparse(&u->buf[1], ts, FALSE); + if (result =3D=3D 0 && ts->typecnt =3D=3D 2 && + sp->charcnt + ts->charcnt <=3D TZ_MAX_CHARS) { for (i =3D 0; i < 2; ++i) - ts.ttis[i].tt_abbrind +=3D + ts->ttis[i].tt_abbrind +=3D sp->charcnt; - for (i =3D 0; i < ts.charcnt; ++i) + for (i =3D 0; i < ts->charcnt; ++i) sp->chars[sp->charcnt++] =3D - ts.chars[i]; + ts->chars[i]; i =3D 0; - while (i < ts.timecnt && - ts.ats[i] <=3D + while (i < ts->timecnt && + ts->ats[i] <=3D sp->ats[sp->timecnt - 1]) ++i; - while (i < ts.timecnt && + while (i < ts->timecnt && sp->timecnt < TZ_MAX_TIMES) { sp->ats[sp->timecnt] =3D - ts.ats[i]; + ts->ats[i]; sp->types[sp->timecnt] =3D sp->typecnt + - ts.types[i]; + ts->types[i]; ++sp->timecnt; ++i; } - sp->ttis[sp->typecnt++] =3D ts.ttis[0]; - sp->ttis[sp->typecnt++] =3D ts.ttis[1]; + sp->ttis[sp->typecnt++] =3D ts->ttis[0]; + sp->ttis[sp->typecnt++] =3D ts->ttis[1]; } + free(ts); } if (sp->timecnt > 1) { for (i =3D 1; i < sp->timecnt; ++i) @@ -620,7 +643,10 @@ register const int doextend; break; } } - return 0; + res =3D 0; +out: + free(u); + return (res); } =20 static int --6749iDyxihQ87e9v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk52FMEACgkQC3+MBN1Mb4gsYgCgvVypsbgE/rSIdiNeCk2D5oDx 1vsAn1Zpa4zeGTuXYWrB6n2abT95wVO7 =Gczh -----END PGP SIGNATURE----- --6749iDyxihQ87e9v-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 15:59:26 2011 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 CDB0A1065676; Sun, 18 Sep 2011 15:59:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2C0CE8FC14; Sun, 18 Sep 2011 15:59:25 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p8IFwCTu057896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Sep 2011 18:58:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id p8IFwC8U095028; Sun, 18 Sep 2011 18:58:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id p8IFw7q2095027; Sun, 18 Sep 2011 18:58:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 18 Sep 2011 18:58:07 +0300 From: Kostik Belousov To: Oliver Lehmann Message-ID: <20110918155807.GZ1511@deviant.kiev.zoral.com.ua> References: <20110908221356.Horde.MFEsZ6Qd9PdOaSIEaid2X_A@avocado.salatschuessel.net> <4E692F87.5010708@sentex.net> <20110909073305.Horde.oi-EGaQd9PdOaaURAsTRVJk@avocado.salatschuessel.net> <4E6A076D.7040309@wintek.com> <20110918122253.Horde.tJj2ZaQd9PdOdcZ9N4nRVsI@avocado.salatschuessel.net> <20110918102741.GV1511@deviant.kiev.zoral.com.ua> <20110918144624.Horde.NmhwTKQd9PdOdeggfTJhVsc@avocado.salatschuessel.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6JAe/4X0qssghT2u" Content-Disposition: inline In-Reply-To: <20110918144624.Horde.NmhwTKQd9PdOdeggfTJhVsc@avocado.salatschuessel.net> 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Adrian Chadd , freebsd-current , Alexander Zagrebin Subject: Re: cvsup broken on 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: Sun, 18 Sep 2011 15:59:26 -0000 --6JAe/4X0qssghT2u Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 18, 2011 at 02:46:24PM +0200, Oliver Lehmann wrote: >=20 > Kostik Belousov wrote: >=20 > >Did you saw the message with the patch for tzcode I mailed to you ? >=20 > Mmmh... no didn't reached my mailbox - can you resend it please? See the "Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW)" thread on the current@, where you are explicitely Cc:ed. I posted updated patch a minute ago. --6JAe/4X0qssghT2u Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk52FQ4ACgkQC3+MBN1Mb4g8TACggQi39GOg3CFrVbiUBytisPiW cpEAnRRRs1so5Bdhhi5JyqNN0enooXT+ =zsgB -----END PGP SIGNATURE----- --6JAe/4X0qssghT2u-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 16:44:23 2011 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 55ED0106564A for ; Sun, 18 Sep 2011 16:44:23 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id 2E2598FC0A for ; Sun, 18 Sep 2011 16:44:23 +0000 (UTC) Received: by pzk33 with SMTP id 33so13968853pzk.4 for ; Sun, 18 Sep 2011 09:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:references:from:content-type:x-mailer:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; bh=lTadckLrUkn+ON53TJ6IYAOkkN53SgfaLtLoP3o0v7E=; b=L2ApLgpyo54oqCwkG9k2gped+xq+xdQnF7tTQF/C7HKnmWAtLjhzPCmxvBJYOy78oe 4LDIjRrEikNc6nYsPKuAThgE2lb+NEwUyUVYF4/lFBJ2CFpssdFF8+ztCZzGfktlKzB3 tt0h85RFtNX4TKxEOPDaNJpkxIi7CgqF+qtUk= Received: by 10.68.11.230 with SMTP id t6mr2690246pbb.522.1316364262230; Sun, 18 Sep 2011 09:44:22 -0700 (PDT) Received: from [192.168.20.56] (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id f8sm57641155pbc.3.2011.09.18.09.44.20 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Sep 2011 09:44:21 -0700 (PDT) References: <20110918095526.D866D1065670@hub.freebsd.org> From: Garrett Cooper Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (8L1) In-Reply-To: <20110918095526.D866D1065670@hub.freebsd.org> Message-Id: Date: Sun, 18 Sep 2011 09:44:17 -0700 To: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPhone Mail 8L1) Subject: Re: 9.0 beta2 & the new bsdinstaller 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, 18 Sep 2011 16:44:23 -0000 On Sep 18, 2011, at 2:55 AM, "Thomas Mueller Some more ideas on the new bsdinstaller cross my mind. >=20 > Since the way the bsdinstaller would make partitions is unpredictable, at l= east to the uninitiated, and in all likelihood at variance with how much spa= ce the user wants to allocate, it might be better to offer a roadmap to help= guide the user to allocating space for FreeBSD using gpart or Rod Smith's g= disk. >=20 > Also, I can't see the function of the 64 KB boot partition with no file sy= stem, which does not boot for me, though I can boot the main partition using= grub2 from the System Rescue CD (http://sysresccd.org/). >=20 > Another concern is updating to the next beta (BETA3?) without trashing the= installed application software (from ports). So far, bsdinstaller hasn't o= ffered any possibility of upgrading an existing installation. I don't think= a user wants to rebuild all ports for every new beta or release candidate. Upgrading installs is nontrivial, depending on the install options. The fact= that sysinstall allowed this was a mistake. -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 17:49:30 2011 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 0255C106566B for ; Sun, 18 Sep 2011 17:49:30 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id B4E2C8FC14 for ; Sun, 18 Sep 2011 17:49:29 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id p8IHnHoa041775; Sun, 18 Sep 2011 11:49:17 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id p8IHnHCi041772; Sun, 18 Sep 2011 11:49:17 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 18 Sep 2011 11:49:17 -0600 (MDT) From: Warren Block To: "Thomas Mueller Message-ID: References: <20110918095526.D866D1065670@hub.freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sun, 18 Sep 2011 11:49:17 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: 9.0 beta2 & the new bsdinstaller 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, 18 Sep 2011 17:49:30 -0000 On Sun, 18 Sep 2011, Thomas Mueller Also, I can't see the function of the 64 KB boot partition with no file system, which does not boot for me (Warning: guesswork and supposition ahead. Set your puzzler in low gear for traction.) AFAIK this is space for boot1 and boot2: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-blocks.html It used to be 16K, but newer boot code like gptzfsboot (33K) needs more room. From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 19:30:30 2011 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 629931065676 for ; Sun, 18 Sep 2011 19:30:30 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f178.google.com (mail-wy0-f178.google.com [74.125.82.178]) by mx1.freebsd.org (Postfix) with ESMTP id ED2EF8FC14 for ; Sun, 18 Sep 2011 19:30:29 +0000 (UTC) Received: by wyf23 with SMTP id 23so5746854wyf.37 for ; Sun, 18 Sep 2011 12:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vl3TORzEE9zJBoKxf5vhbFyxoWWes0GZfI/xl4zMRWE=; b=AFDnr2yRWNIrpGct+0EhCzLmeVBHfJgYhupNa4NFMgNstfkrlJLAKhcIJVEVezt9Ri RAg+0vMKuc7VZl78uMw10O142+4NmV+kSSKlG6HzTuVFNukzEAb7OOat2GpE2cBZuUmO Io62FVAinO97lf5qcMkiqpUf0WYdye0tUWAjA= MIME-Version: 1.0 Received: by 10.227.200.147 with SMTP id ew19mr1876712wbb.38.1316374228872; Sun, 18 Sep 2011 12:30:28 -0700 (PDT) Received: by 10.180.95.169 with HTTP; Sun, 18 Sep 2011 12:30:28 -0700 (PDT) In-Reply-To: <45558.1316240251@critter.freebsd.dk> References: <45558.1316240251@critter.freebsd.dk> Date: Sun, 18 Sep 2011 15:30:28 -0400 Message-ID: From: Arnaud Lacombe To: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD-Current Subject: Re: Very imprecise watchdogd(8) timeout 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, 18 Sep 2011 19:30:30 -0000 Hi, On Sat, Sep 17, 2011 at 2:17 AM, Poul-Henning Kamp wrote: > In message > , Arnaud Lacombe writes: > >>I do not really care actually, but the manpage is wrong, and the code >>needlessly complicated. > > As I said: Feel free to improve. > How can I expect anything to get through, when I cannot even get an obvious use-after-free in the ipfw code fixed after months ? Or when I've been waiting to play with Warner's external compiler support patch for months ? Or when I can not get a build fix for 7-STABLE to get committed ? [and the list goes on...] ? Thanks, - Arnaud From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 19:31:51 2011 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 AD30E1065686 for ; Sun, 18 Sep 2011 19:31:51 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6DAEF8FC23 for ; Sun, 18 Sep 2011 19:31:50 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 26F6F5DA8; Sun, 18 Sep 2011 19:31:49 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id p8IJVm6U097151; Sun, 18 Sep 2011 19:31:48 GMT (envelope-from phk@phk.freebsd.dk) To: Arnaud Lacombe From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 18 Sep 2011 15:30:28 -0400." Content-Type: text/plain; charset=ISO-8859-1 Date: Sun, 18 Sep 2011 19:31:48 +0000 Message-ID: <97150.1316374308@critter.freebsd.dk> Cc: FreeBSD-Current Subject: Re: Very imprecise watchdogd(8) timeout 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, 18 Sep 2011 19:31:51 -0000 In message , Arnaud Lacombe writes: >>>I do not really care actually, but the manpage is wrong, and the code >>>needlessly complicated. >> >> As I said: Feel free to improve. >> >How can I expect anything to get through, when I cannot even get an >obvious use-after-free in the ipfw code fixed after months ? Or when >I've been waiting to play with Warner's external compiler support >patch for months ? Or when I can not get a build fix for 7-STABLE to >get committed ? [and the list goes on...] The oracle says: Try next answer. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 20:18:50 2011 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 A3B4D106566B for ; Sun, 18 Sep 2011 20:18:50 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 70E478FC0A for ; Sun, 18 Sep 2011 20:18:50 +0000 (UTC) Received: by iadk27 with SMTP id k27so7187934iad.13 for ; Sun, 18 Sep 2011 13:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=esk7WjcN6s+U7C5FsgmsbMHCEzDDFDqbAsnmnFKGr1s=; b=tCuvohsx7eA/JegnBV0hlBXbI2cRdU0XRvP42i5GUpHEY7l/ZmeGZJ/jmf++IAGw7o 54MwzalpToS+bJZpiS2rcLuaNtZnHt9dDXYk3H/Nf+1l8wB/XefjiEUfAh6CD05Be73/ Ja3kbkiw3cN0Q9pDTxZYlcxqS9GC7Vbvbf7AI= MIME-Version: 1.0 Received: by 10.231.82.131 with SMTP id b3mr2813619ibl.74.1316377129369; Sun, 18 Sep 2011 13:18:49 -0700 (PDT) Received: by 10.231.36.69 with HTTP; Sun, 18 Sep 2011 13:18:49 -0700 (PDT) In-Reply-To: <20110918095526.D866D1065670@hub.freebsd.org> References: <20110918095526.D866D1065670@hub.freebsd.org> Date: Sun, 18 Sep 2011 13:18:49 -0700 Message-ID: From: Kevin Oberman To: "Thomas Mueller List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 20:18:50 -0000 On Sun, Sep 18, 2011 at 2:55 AM, <"Thomas Mueller wrote: > Some more ideas on the new bsdinstaller cross my mind. > > Since the way the bsdinstaller would make partitions is unpredictable, at= least to the uninitiated, and in all likelihood at variance with how much = space the user wants to allocate, it might be better to offer a roadmap to = help guide the user to allocating space for FreeBSD using gpart or Rod Smit= h's gdisk. > > Also, I can't see the function of the 64 KB boot partition with no file s= ystem, which does not boot for me, though I can boot the main partition usi= ng grub2 from the System Rescue CD (http://sysresccd.org/). The 64KB freebsd-boot partition is to contain the GPT boot code which is used by UEFI BIOS in place of the old MBR used by legacy BIOS. You need to use gpart(8) to write the GPT boot code to that partition, but I don't know if bsdinstall does so. It might just write the PMBR that is used for booting with legacy BIOS. I'll admit that I have not checked. (See the gpart(8) man page for details on writing the pmbr and gptboot.) I assume bsdinstall writes both so that AMD64 machines with EFI and 32-bit systems will both work. This is very different from the old traditional slice/partition system. --=20 R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 23:43:11 2011 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 D6587106566C for ; Sun, 18 Sep 2011 23:43:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 94A038FC15 for ; Sun, 18 Sep 2011 23:43:11 +0000 (UTC) Received: by ywp17 with SMTP id 17so4677507ywp.13 for ; Sun, 18 Sep 2011 16:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3t7aaBb+y6gV6RNve7Xy9xwTgQzrJMHCJ201NrOUAwk=; b=CnMhS4lda0DwyYLAKnLulMO1sXvMjA5LXv9ZI3gQuXVzXM3fcOo7mTaLwLpEUUXgkj g8n9HxkNrN4TqRa+dmuWTNBfDMNhNBJQtboIf74Hfnj2kHRfosgw3URAZP6HuuBEQqU1 WkKE8JG6T1rGzxIhRcRbmhB44xrPGYqxhWqr0= MIME-Version: 1.0 Received: by 10.236.79.72 with SMTP id h48mr10351912yhe.4.1316389390790; Sun, 18 Sep 2011 16:43:10 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Sun, 18 Sep 2011 16:43:10 -0700 (PDT) In-Reply-To: References: <45558.1316240251@critter.freebsd.dk> Date: Mon, 19 Sep 2011 07:43:10 +0800 X-Google-Sender-Auth: cwZiYH56WnwgveM9gCFFIpYIVVM Message-ID: From: Adrian Chadd To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Cc: Poul-Henning Kamp , FreeBSD-Current Subject: Re: Very imprecise watchdogd(8) timeout 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, 18 Sep 2011 23:43:11 -0000 .. just a note: people who in your situation keep filing PRs, fixing bugs and hounding committers with tested, correct fixes - end up getting commit bits. :-) Adrian From owner-freebsd-current@FreeBSD.ORG Sun Sep 18 20:00:38 2011 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 698DC106567F for ; Sun, 18 Sep 2011 20:00:38 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3180D8FC0C for ; Sun, 18 Sep 2011 20:00:38 +0000 (UTC) Received: by iadk27 with SMTP id k27so7169108iad.13 for ; Sun, 18 Sep 2011 13:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iUEl6l/rKnQE/mcd1QGGpKucvdEoYDCgxwput39tv5Y=; b=AN8CwrQtzZeKkRq+UHcngZj8HfDXSwBtq4dG7siUcNrQV6xMVrEnnHBtTzku1EC4yi P8IeFh0hkpMHpDcpZmB0QZReJF9xEGSXp77gteoPPQi4KZiFivTeEmtDxJnlKyMoJ1VA VK/vFX6N2P9NImqMOkvqvl5stPkb/kH2vsaC4= MIME-Version: 1.0 Received: by 10.42.29.68 with SMTP id q4mr3164955icc.99.1316376037758; Sun, 18 Sep 2011 13:00:37 -0700 (PDT) Received: by 10.231.35.194 with HTTP; Sun, 18 Sep 2011 13:00:37 -0700 (PDT) Received: by 10.231.35.194 with HTTP; Sun, 18 Sep 2011 13:00:37 -0700 (PDT) In-Reply-To: References: <45558.1316240251@critter.freebsd.dk> Date: Sun, 18 Sep 2011 21:00:37 +0100 Message-ID: From: Chris Rees To: Arnaud Lacombe X-Mailman-Approved-At: Sun, 18 Sep 2011 23:57:28 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Poul-Henning Kamp , FreeBSD-Current Subject: Re: Very imprecise watchdogd(8) timeout 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, 18 Sep 2011 20:00:38 -0000 On 18 Sep 2011 20:31, "Arnaud Lacombe" wrote: > > Hi, > > On Sat, Sep 17, 2011 at 2:17 AM, Poul-Henning Kamp wrote: > > In message < CACqU3MVF5MwqeC+s9VKk4mLJenmoS9Q_bJWkbYeFzaBFjo67gQ@mail.gmail.com> > > , Arnaud Lacombe writes: > > > >>I do not really care actually, but the manpage is wrong, and the code > >>needlessly complicated. > > > > As I said: Feel free to improve. > > > How can I expect anything to get through, when I cannot even get an > obvious use-after-free in the ipfw code fixed after months ? Or when > I've been waiting to play with Warner's external compiler support > patch for months ? Or when I can not get a build fix for 7-STABLE to > get committed ? [and the list goes on...] > > ? Hey Arnaud, I'm sorry to hear you're having trouble getting your fixes included. If you provide some PR numbers I'll gladly try to get them in as quickly as possible. Chris From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 00:52:53 2011 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 C7EDC106566B for ; Mon, 19 Sep 2011 00:52:53 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id 9C02F8FC13 for ; Mon, 19 Sep 2011 00:52:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; q=dns/txt; s=DKIM-NAME-SERVICES; d=a1poweruser.com; h=From:To:Cc:Subject:Message-ID:X-Sender:X-Envelope-From; l=500; bh=vEJdjw+95d8E2wu/tkN/XJEzrF6otRU/vZfEX5fIUw8=; b=PO8LqnMckA60fcGkcBcLoIcuCUTBNuYWncA74wAExosp7FoPihPTo6JbgN6yfhhADsdaZUMtVmA9wTV2zf2GIKWcmXbSs9FRnlKgN2MYrsLFB9vIQVWvsPxCCIaT0U31rJBWbphkJ7b+r/1EqUGm3YkCO90TB2ZF97MMJQ6EKes= Received: from [192.168.1.64] ([76.240.47.196]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Sep 2011 17:52:52 -0700 Message-ID: <4E769252.4040101@a1poweruser.com> Date: Sun, 18 Sep 2011 20:52:34 -0400 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 CC: freebsd-current@freebsd.org References: <20110918095526.D866D1065670@hub.freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2011 00:52:52.0472 (UTC) FILETIME=[75F64F80:01CC7666] X-Sender: fbsd8@a1poweruser.com X-Envelope-From: fbsd8*a1poweruser.com Subject: Re: 9.0 beta2 & the new bsdinstaller 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, 19 Sep 2011 00:52:53 -0000 Kevin Oberman wrote: > On Sun, Sep 18, 2011 at 2:55 AM, <"Thomas Mueller > wrote: >> Some more ideas on the new bsdinstaller cross my mind. >> >> Since the way the bsdinstaller would make partitions is unpredictable, at least to the uninitiated, and in all likelihood at variance with how much space the user wants to allocate, it might be better to offer a roadmap to help guide the user to allocating space for FreeBSD using gpart or Rod Smith's gdisk. >> >> Also, I can't see the function of the 64 KB boot partition with no file system, which does not boot for me, though I can boot the main partition using grub2 from the System Rescue CD (http://sysresccd.org/). > > The 64KB freebsd-boot partition is to contain the GPT boot code which > is used by UEFI BIOS in > place of the old MBR used by legacy BIOS. You need to use gpart(8) to > write the GPT boot code to that partition, but I don't know if > bsdinstall does so. It might just write the PMBR that is used for > booting with legacy BIOS. I'll admit that I have not checked. (See the > gpart(8) man page for details on writing the pmbr and gptboot.) I > assume bsdinstall writes both so that AMD64 machines with EFI and > 32-bit systems will both work. This is very different from the old > traditional slice/partition system. The above info is another example of the type of information that should be added to a "help" option on the dialog screen for the bsdinstall disk configuration function. I also think that the bsdinstaller should offer the user an option to select between using the old MBR configuration used by legacy BIOS that sysinstall uses and the new gpart configuration which bsdinstall offers now. From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 01:40:07 2011 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 C51DC106566B; Mon, 19 Sep 2011 01:40:07 +0000 (UTC) (envelope-from poyopoyo@puripuri.plala.or.jp) Received: from msa04b.plala.or.jp (msa04.plala.or.jp [58.93.240.4]) by mx1.freebsd.org (Postfix) with ESMTP id 0AA8D8FC13; Mon, 19 Sep 2011 01:40:06 +0000 (UTC) Received: from i125-202-7-242.s02.a026.ap.plala.or.jp ([125.202.7.242]) by msa04b.plala.or.jp with ESMTP id <20110919014005.VOWJ10746.msa04b.plala.or.jp@i125-202-7-242.s02.a026.ap.plala.or.jp>; Mon, 19 Sep 2011 10:40:05 +0900 Date: Mon, 19 Sep 2011 10:40:04 +0900 Message-ID: <86ehzds423.wl%poyopoyo@puripuri.plala.or.jp> From: poyopoyo@puripuri.plala.or.jp To: Gabor Kovesdan User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.3 (amd64-portbld-freebsd9.0) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-VirusScan: Outbound; msa04b; Mon, 19 Sep 2011 10:40:05 +0900 Cc: freebsd-current@FreeBSD.org Subject: bsdgrep-20110912: -F/fgrep enbug 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, 19 Sep 2011 01:40:07 -0000 Hi, I found another issue, this time in bsdgrep-20110912 in port. == #! /bin/sh echo 1 echo 90123456789.|grep -F 0123456789. echo 2 echo 90123456789.|grep 0123456789. echo 3 echo 0123456789.|grep -F 0123456789. echo 4 echo 90123456789.|grep -F 0123456789 echo 5 echo 90123456789x|grep -F 0123456789x == result: 1 2 90123456789. 3 0123456789. 4 90123456789. 5 90123456789x == (1) this should match but does not. (2) without -F it matches. (3) trim leading 1 byte from input string it matches. (4) trim last period from query string it matches. (5) replace period with another character (no matter what it is) it matches. bsdgrep in -CURRENT and GNU grep match all cases. -- kuro From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 03:56:47 2011 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 63F94106564A for ; Mon, 19 Sep 2011 03:56:47 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 30FE08FC15 for ; Mon, 19 Sep 2011 03:56:47 +0000 (UTC) Received: by iadk27 with SMTP id k27so7631917iad.13 for ; Sun, 18 Sep 2011 20:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=r33FCbs/aOUOk8M1V91nybdpCuM4EyiDZRQSKmZqKqc=; b=FbWLSbfC6b5GZ41vawESaNsKBLR6O3iSvYG0WFcSau7TeuaEPVnMENseXB4bkqNcWD hmV94NM20Pv5gljGn/4jkEUjf4QNoPIv6Hy8la3Wuot01pBVI2wfimpoAEi1BR0mSC+P udcjJD/WmEfik41+K87sbS31uSV7MZxMmiSjE= MIME-Version: 1.0 Received: by 10.231.46.66 with SMTP id i2mr3334898ibf.0.1316404606166; Sun, 18 Sep 2011 20:56:46 -0700 (PDT) Received: by 10.231.36.69 with HTTP; Sun, 18 Sep 2011 20:56:46 -0700 (PDT) In-Reply-To: <4E769252.4040101@a1poweruser.com> References: <20110918095526.D866D1065670@hub.freebsd.org> <4E769252.4040101@a1poweruser.com> Date: Sun, 18 Sep 2011 20:56:46 -0700 Message-ID: From: Kevin Oberman To: Fbsd8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: 9.0 beta2 & the new bsdinstaller 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, 19 Sep 2011 03:56:47 -0000 On Sun, Sep 18, 2011 at 5:52 PM, Fbsd8 wrote: > Kevin Oberman wrote: >> >> On Sun, Sep 18, 2011 at 2:55 AM, =A0<"Thomas Mueller >> wrote: >>> >>> Some more ideas on the new bsdinstaller cross my mind. >>> >>> Since the way the bsdinstaller would make partitions is unpredictable, = at >>> least to the uninitiated, and in all likelihood at variance with how mu= ch >>> space the user wants to allocate, it might be better to offer a roadmap= to >>> help guide the user to allocating space for FreeBSD using gpart or Rod >>> Smith's gdisk. >>> >>> Also, I can't see the function of the 64 KB boot partition with no file >>> system, which does not boot for me, though I can boot the main partitio= n >>> using grub2 from the System Rescue CD (http://sysresccd.org/). >> >> The 64KB freebsd-boot partition is to contain the GPT boot code which >> is used by UEFI BIOS in >> place of the old MBR used by legacy BIOS. You need to use gpart(8) to >> write the GPT boot code to that partition, but I don't know if >> bsdinstall does so. It might just write the PMBR that is used for >> booting with legacy BIOS. I'll admit that I have not checked. (See the >> gpart(8) man page for details on writing the pmbr and gptboot.) =A0I >> assume bsdinstall writes both so that AMD64 machines with EFI and >> 32-bit systems will both work. This is very different from the old >> traditional slice/partition system. > > The above info is another example of the type of information that should = be > added to a "help" option on the dialog screen for the bsdinstall disk > configuration function. > > I also think that the bsdinstaller should offer the user an option to sel= ect > between using the old MBR configuration used by legacy BIOS that sysinsta= ll > uses and the new gpart configuration which bsdinstall offers now. I can only see two advantages of the old MBR scheme over GPT. 1. Booteasy is not available, so you need to use gpart to designate booting from a different partition 2. Some other OSes don't support it. 32-bit Windows, Solaris, 64-bit Window= s on systems lacking EFI While GPT has major advantages over the old MBR system, I think these two justify maintaining the ability to install FreeBSD with MBR. I also should be clear in that sysinstall does work fine on a disk that is already configured with MBR partitioning. I am sure of this because I have done it and had no problems with that part of the install. It's only if you want to partition a new disk with the intent of later installing an OS that does not support GPT. --=20 R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 05:53:09 2011 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 3040E106566B; Mon, 19 Sep 2011 05:53:09 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id DB4EA8FC0A; Mon, 19 Sep 2011 05:53:08 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1R5Wmw-00017Y-IZ; Mon, 19 Sep 2011 09:53:06 +0400 From: "Alexander Zagrebin" To: "'Adrian Chadd'" References: <20110908221356.Horde.MFEsZ6Qd9PdOaSIEaid2X_A@avocado.salatschuessel.net><4E692F87.5010708@sentex.net><20110909073305.Horde.oi-EGaQd9PdOaaURAsTRVJk@avocado.salatschuessel.net><4E6A076D.7040309@wintek.com> In-Reply-To: Date: Mon, 19 Sep 2011 09:53:06 +0400 Keywords: freebsd-current Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17514 Thread-Index: Acx163zkFzEMLOvqTXWMvAOpW2xp4gAozYkg Cc: freebsd-current@freebsd.org Subject: RE: cvsup broken on 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, 19 Sep 2011 05:53:09 -0000 Hi! > So I've taken a look at the csup source. > > The problem here is the updater thread setting the "closed" state > (fixups_closed()) before calling updater_batch() again to handle > fixups. > > Checking for size != 0 at that point may not be valid at the list size > may actually be 0 for a short period of time. > > What about this patch: > > Index: updater.c > =================================================================== > --- updater.c (revision 224905) > +++ updater.c (working copy) > @@ -240,9 +240,9 @@ > * Make sure to close the fixups even in case of an error, > * so that the lister thread doesn't block indefinitely. > */ > - fixups_close(up->config->fixups); > if (!error) > error = updater_batch(up, 1); > + fixups_close(up->config->fixups); > switch (error) { > case UPDATER_ERR_PROTO: > xasprintf(&args->errmsg, "Updater failed: > Protocol error"); I've tried this patch. Now csup "hangs" before handling fixups. So there is no message "Applying fixups..." at all. -- Alexander Zagrebin From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 06:26:51 2011 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 CA777106566B for ; Mon, 19 Sep 2011 06:26:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 87A788FC0C for ; Mon, 19 Sep 2011 06:26:51 +0000 (UTC) Received: by yia13 with SMTP id 13so2799083yia.13 for ; Sun, 18 Sep 2011 23:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EHR/maAhSuZZmTgfF8SFaKy2UgDgYA0vJ5y7WDXQsTY=; b=vMy+6Nv2TEasYoOv/4iTuERO6a0OPLklWz0U9cWxcQEL0ghZxSmMRM8MLm8z5b25LJ Zq7ecrMV2SrYjjIWGgKN/AkaAxrhNQXqJG2rB/rz1C1fVidCHuHmd9D9LgKF2IzdqWR3 FKS7NwjVjMgYquSJ9Emo8xPF2OUJeMW3lDfq4= MIME-Version: 1.0 Received: by 10.236.177.73 with SMTP id c49mr11231041yhm.89.1316413610992; Sun, 18 Sep 2011 23:26:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Sun, 18 Sep 2011 23:26:50 -0700 (PDT) In-Reply-To: References: <20110908221356.Horde.MFEsZ6Qd9PdOaSIEaid2X_A@avocado.salatschuessel.net> <4E692F87.5010708@sentex.net> <20110909073305.Horde.oi-EGaQd9PdOaaURAsTRVJk@avocado.salatschuessel.net> <4E6A076D.7040309@wintek.com> Date: Mon, 19 Sep 2011 14:26:50 +0800 X-Google-Sender-Auth: WV0em-vb8jv3DtSA3k9pVszMpDc Message-ID: From: Adrian Chadd To: Alexander Zagrebin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: cvsup broken on 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, 19 Sep 2011 06:26:51 -0000 2011/9/19 Alexander Zagrebin : > I've tried this patch. Now csup "hangs" before handling fixups. > So there is no message "Applying fixups..." at all. Wow. Hm. Where's the author when one needs them.. Adrian From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 07:51:39 2011 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 E53F3106566C for ; Mon, 19 Sep 2011 07:51:39 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 383258FC13 for ; Mon, 19 Sep 2011 07:51:38 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA03999; Mon, 19 Sep 2011 10:51:33 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1R5YdZ-000HVm-DL; Mon, 19 Sep 2011 10:51:33 +0300 Message-ID: <4E76F485.10404@FreeBSD.org> Date: Mon, 19 Sep 2011 10:51:33 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110907 Thunderbird/6.0.2 MIME-Version: 1.0 To: Kevin Oberman References: <20110918095526.D866D1065670@hub.freebsd.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Mueller , freebsd-current@FreeBSD.org Subject: Re: 9.0 beta2 & the new bsdinstaller 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, 19 Sep 2011 07:51:40 -0000 on 18/09/2011 23:18 Kevin Oberman said the following: > On Sun, Sep 18, 2011 at 2:55 AM, <"Thomas Mueller > wrote: >> Some more ideas on the new bsdinstaller cross my mind. >> >> Since the way the bsdinstaller would make partitions is unpredictable, at least to the uninitiated, and in all likelihood at variance with how much space the user wants to allocate, it might be better to offer a roadmap to help guide the user to allocating space for FreeBSD using gpart or Rod Smith's gdisk. >> >> Also, I can't see the function of the 64 KB boot partition with no file system, which does not boot for me, though I can boot the main partition using grub2 from the System Rescue CD (http://sysresccd.org/). > > The 64KB freebsd-boot partition is to contain the GPT boot code which > is used by UEFI BIOS in > place of the old MBR used by legacy BIOS. You need to use gpart(8) to > write the GPT boot code to that partition, but I don't know if > bsdinstall does so. It might just write the PMBR that is used for > booting with legacy BIOS. I'll admit that I have not checked. (See the > gpart(8) man page for details on writing the pmbr and gptboot.) I > assume bsdinstall writes both so that AMD64 machines with EFI and > 32-bit systems will both work. This is very different from the old > traditional slice/partition system. I don't think that we create a GPT boot partition that is going to be used by UEFI BIOS. We use specific "freebsd-boot" partition type, which, I am sure, is unknown to BIOSes. So, as you say, we install PMBR, which will be booted by BIOS, and which will then load the "main boot code" from the boot partition. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 07:59:23 2011 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 5DAF9106564A for ; Mon, 19 Sep 2011 07:59:23 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id 303F58FC12 for ; Mon, 19 Sep 2011 07:59:23 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LRR00K00FIYYH00@smtpauth3.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Mon, 19 Sep 2011 02:59:22 -0500 (CDT) Received: from wanderer.tachypleus.net (nl119-145-4.student.uu.se [212.25.145.4]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LRR00C5QFIWXV40@smtpauth3.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Mon, 19 Sep 2011 02:59:21 -0500 (CDT) Date: Mon, 19 Sep 2011 09:59:20 +0200 From: Nathan Whitehorn In-reply-to: <4E769252.4040101@a1poweruser.com> To: freebsd-current@freebsd.org Message-id: <4E76F658.7080008@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=212.25.145.4 X-Spam-PmxInfo: Server=avs-13, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.9.19.75118, SenderIP=212.25.145.4 References: <20110918095526.D866D1065670@hub.freebsd.org> <4E769252.4040101@a1poweruser.com> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110917 Thunderbird/6.0.2 Subject: Re: 9.0 beta2 & the new bsdinstaller 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, 19 Sep 2011 07:59:23 -0000 On 09/19/11 02:52, Fbsd8 wrote: > Kevin Oberman wrote: >> On Sun, Sep 18, 2011 at 2:55 AM, <"Thomas Mueller >> wrote: >>> Some more ideas on the new bsdinstaller cross my mind. >>> >>> Since the way the bsdinstaller would make partitions is >>> unpredictable, at least to the uninitiated, and in all likelihood at >>> variance with how much space the user wants to allocate, it might be >>> better to offer a roadmap to help guide the user to allocating space >>> for FreeBSD using gpart or Rod Smith's gdisk. >>> >>> Also, I can't see the function of the 64 KB boot partition with no >>> file system, which does not boot for me, though I can boot the main >>> partition using grub2 from the System Rescue CD (http://sysresccd.org/). >> >> The 64KB freebsd-boot partition is to contain the GPT boot code which >> is used by UEFI BIOS in >> place of the old MBR used by legacy BIOS. You need to use gpart(8) to >> write the GPT boot code to that partition, but I don't know if >> bsdinstall does so. It might just write the PMBR that is used for >> booting with legacy BIOS. I'll admit that I have not checked. (See the >> gpart(8) man page for details on writing the pmbr and gptboot.) I >> assume bsdinstall writes both so that AMD64 machines with EFI and >> 32-bit systems will both work. This is very different from the old >> traditional slice/partition system. > > The above info is another example of the type of information that should > be added to a "help" option on the dialog screen for the bsdinstall disk > configuration function. > > I also think that the bsdinstaller should offer the user an option to > select between using the old MBR configuration used by legacy BIOS that > sysinstall uses and the new gpart configuration which bsdinstall offers > now. You absolutely can do new MBR installs, as well as new straight bsdlabel installs ("dangerously dedicated"). You just have to use the partition editor instead of the autopartitioner, and then choose to use the appropriate partition type. -Nathan From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 12:14:13 2011 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 EBDC71065676 for ; Mon, 19 Sep 2011 12:14:13 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id A75BE8FC12 for ; Mon, 19 Sep 2011 12:14:13 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R5cjj-0005r0-GN for freebsd-current@freebsd.org; Mon, 19 Sep 2011 14:14:11 +0200 Received: from 178.214.36.169 ([178.214.36.169]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Sep 2011 14:14:11 +0200 Received: from citrin by 178.214.36.169 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Sep 2011 14:14:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Anton Yuzhaninov Date: Mon, 19 Sep 2011 12:13:56 +0000 (UTC) Organization: Vega Lines: 10 Sender: Anton Yuzhaninov Message-ID: References: <4E5E46A4.3060705@citrin.ru> <4E6A99A9.1000204@delphij.net> <864o0adkva.fsf@kopusha.home.net> X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 178.214.36.169 X-Comment-To: Mikolaj Golub User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/9.0-BETA2 (i386)) Subject: Re: truss 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, 19 Sep 2011 12:14:14 -0000 On Sun, 18 Sep 2011 16:46:01 +0300, Mikolaj Golub wrote: MG> Could you please run ktrace with -i option? The behavior is like if MG> ptrace(PT_TRACE_ME) failed in the child by some reason. Unfortunately, truss MG> does not check this. ktrace -i for truss sleep 5 http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt -- Anton Yuzhaninov From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 12:25:30 2011 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 6D498106566C; Mon, 19 Sep 2011 12:25:30 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id F1F8D8FC08; Mon, 19 Sep 2011 12:25:29 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 0057CE6A02; Mon, 19 Sep 2011 13:25:28 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=CSjH1MCWzFt5 4xyeWklFwtzS6Wc=; b=pjKaBv/+ki7mSvo4/O1ULoieu6L762qHkSfLUZJ1xwaI xyZSyEU19kRSab7iKxdR95pu4ErDp1WGGkAd1pIAPJZ7sSb2e08XD2n/RdToHavb JFHSUud/XEw0/Z1+iJfUo2QpbqmhBSH+1ZXyvrAQrgFJzR1cUX/58kcekz1LCok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=nxPkBd GhZVX0lcIAJ7q8FM9j6EyRCiAKbqr2ZCEHnkBYq0Rma/WYfbKNwLfloZxLKOxYXb kxFKmocgMJAp29YDMIC0ZqR5nfjVhYRoU1wFkILzXcsLRu4r+imc5KWv7beqs3rf ifkM+EJaEYDOr0K8NjW5ltygZ57qeGhe5N8lA= Received: from [192.168.1.104] (188-222-18-231.zone13.bethere.co.uk [188.222.18.231]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id CC898E699F; Mon, 19 Sep 2011 13:25:28 +0100 (BST) Message-ID: <4E7734B7.8030507@cran.org.uk> Date: Mon, 19 Sep 2011 13:25:27 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Thomas Mueller References: <20110918095526.D866D1065670@hub.freebsd.org> In-Reply-To: <20110918095526.D866D1065670@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Nathan Whitehorn Subject: Re: 9.0 beta2 & the new bsdinstaller 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, 19 Sep 2011 12:25:30 -0000 On 18/09/2011 10:55, "Thomas Mueller Also, I can't see the function of the 64 KB boot partition with no file system, which does not boot for me, though I can boot the main partition using grub2 from the System Rescue CD (http://sysresccd.org/). I seem to remember (perhaps incorrectly) there was a discussion about bumping the default to 128 kB or more for the freebsd-boot partition. Will 64 kB be enough for 9.x? -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 12:49:19 2011 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 82500106566B for ; Mon, 19 Sep 2011 12:49:19 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CFA178FC0A for ; Mon, 19 Sep 2011 12:49:18 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA11219; Mon, 19 Sep 2011 15:49:13 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E773A49.20300@FreeBSD.org> Date: Mon, 19 Sep 2011 15:49:13 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110907 Thunderbird/6.0.2 MIME-Version: 1.0 To: Arnaud Lacombe References: <58772.1316203388@critter.freebsd.dk> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Poul-Henning Kamp , FreeBSD-Current Subject: Re: Very imprecise watchdogd(8) timeout 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, 19 Sep 2011 12:49:19 -0000 on 16/09/2011 23:59 Arnaud Lacombe said the following: > in which case the current notifier-based architecture is broken. You > may want to have a soft-watchdog triggering after 5s, and a fallback > hardware watchdog triggering after 60s. So let's start with the real problem, FreeBSD watchdog infrastructure doesn't expose an API to do what you described above. I think that it would be a rather small part to change the representation of timeouts from current form to, say, value + unit encoding. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 12:52:25 2011 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 18882106567B; Mon, 19 Sep 2011 12:52:25 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id EE16A8FC28; Mon, 19 Sep 2011 12:52:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; q=dns/txt; s=DKIM-NAME-SERVICES; d=a1poweruser.com; h=From:To:Cc:Subject:Message-ID:X-Sender:X-Envelope-From; l=500; bh=2zd51lGwtsCCDJ1J3q7KLjPL7y7x9bANmLNnQQKfOoo=; b=H9l1jXIH0fdrQnQAlZVsJkLHmvfOUVnSM6ndmbUdfkqelkEj87B1MWRflGFIMkIaq3+IkrvtFQBu4BDsQDRtWORmNmsSkVeUP7QNhPqpXSR5Rxz+XoZceMIgSOzWO7Him5jMdVmjs+5fZim432sQJrhUSM+u4q92ddUfxilgShM= Received: from [192.168.1.64] ([76.240.47.196]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Sep 2011 05:52:25 -0700 Message-ID: <4E773B0B.80501@a1poweruser.com> Date: Mon, 19 Sep 2011 08:52:27 -0400 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Nathan Whitehorn , FreeBSD Questions References: <20110918095526.D866D1065670@hub.freebsd.org> <4E769252.4040101@a1poweruser.com> <4E76F658.7080008@freebsd.org> In-Reply-To: <4E76F658.7080008@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2011 12:52:25.0295 (UTC) FILETIME=[FAF84DF0:01CC76CA] X-Sender: fbsd8@a1poweruser.com X-Envelope-From: fbsd8*a1poweruser.com Cc: freebsd-current@freebsd.org Subject: Re: 9.0 beta2 & the new bsdinstaller 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, 19 Sep 2011 12:52:25 -0000 Nathan Whitehorn wrote: > On 09/19/11 02:52, Fbsd8 wrote: >> Kevin Oberman wrote: >>> On Sun, Sep 18, 2011 at 2:55 AM, <"Thomas Mueller >>> wrote: >>>> Some more ideas on the new bsdinstaller cross my mind. >>>> >>>> Since the way the bsdinstaller would make partitions is >>>> unpredictable, at least to the uninitiated, and in all likelihood at >>>> variance with how much space the user wants to allocate, it might be >>>> better to offer a roadmap to help guide the user to allocating space >>>> for FreeBSD using gpart or Rod Smith's gdisk. >>>> >>>> Also, I can't see the function of the 64 KB boot partition with no >>>> file system, which does not boot for me, though I can boot the main >>>> partition using grub2 from the System Rescue CD >>>> (http://sysresccd.org/). >>> >>> The 64KB freebsd-boot partition is to contain the GPT boot code which >>> is used by UEFI BIOS in >>> place of the old MBR used by legacy BIOS. You need to use gpart(8) to >>> write the GPT boot code to that partition, but I don't know if >>> bsdinstall does so. It might just write the PMBR that is used for >>> booting with legacy BIOS. I'll admit that I have not checked. (See the >>> gpart(8) man page for details on writing the pmbr and gptboot.) I >>> assume bsdinstall writes both so that AMD64 machines with EFI and >>> 32-bit systems will both work. This is very different from the old >>> traditional slice/partition system. >> >> The above info is another example of the type of information that should >> be added to a "help" option on the dialog screen for the bsdinstall disk >> configuration function. >> >> I also think that the bsdinstaller should offer the user an option to >> select between using the old MBR configuration used by legacy BIOS that >> sysinstall uses and the new gpart configuration which bsdinstall offers >> now. > > You absolutely can do new MBR installs, as well as new straight bsdlabel > installs ("dangerously dedicated"). You just have to use the partition > editor instead of the autopartitioner, and then choose to use the > appropriate partition type. > -Nathan > > I think you missed the point here. What is being requested is the partitioning dialog from sysinstall to be included in bsdinstall. The bsdinstall partitioning dialog should inform users about the differences between older and newer PCs and offer options to auto-configure the H.D appropriately. Or better yet have bsdinstall check the hardwares bios to determine if the bios are UEFI aware and what methods can be used to partition. The key here is that bsdinstall should provide at least the same level of automation as sysinstall has on this subject. From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 12:58:07 2011 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 D15141065672 for ; Mon, 19 Sep 2011 12:58:07 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5B72D8FC13 for ; Mon, 19 Sep 2011 12:58:06 +0000 (UTC) Received: by fxg9 with SMTP id 9so5256518fxg.13 for ; Mon, 19 Sep 2011 05:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:organization:references:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=tTqDhM04pjFcLgw4VvJ5K/NQldPHKL3OmOWwsvR6eNQ=; b=jGKk1K6ICudBeEBWtc19zMWHKvUgTa4GKBKWYywEnRgEFJ/ZqP3rXty730qzf3OF4k XlzR9MMW9rF6Y7VjZXm/L4+PDrte6AqhATxnmUZZaynIPmncFdaVdIDF10qEn62UuKnD FakaD/D4S48avU7ceSDAJOPYsL7DLV7tynx28= Received: by 10.223.37.26 with SMTP id v26mr5120543fad.100.1316437086151; Mon, 19 Sep 2011 05:58:06 -0700 (PDT) Received: from localhost ([94.27.39.186]) by mx.google.com with ESMTPS id f25sm21715944faf.7.2011.09.19.05.58.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Sep 2011 05:58:04 -0700 (PDT) From: Mikolaj Golub To: Anton Yuzhaninov Organization: TOA Ukraine References: <4E5E46A4.3060705@citrin.ru> <4E6A99A9.1000204@delphij.net> <864o0adkva.fsf@kopusha.home.net> Sender: Mikolaj Golub Date: Mon, 19 Sep 2011 15:58:02 +0300 In-Reply-To: (Anton Yuzhaninov's message of "Mon, 19 Sep 2011 12:13:56 +0000 (UTC)") Message-ID: <86mxe0r8o5.fsf@in138.ua3> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: truss 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, 19 Sep 2011 12:58:07 -0000 On Mon, 19 Sep 2011 12:13:56 +0000 (UTC) Anton Yuzhaninov wrote to Mikolaj Golub: AY> On Sun, 18 Sep 2011 16:46:01 +0300, Mikolaj Golub wrote: MG>> Could you please run ktrace with -i option? The behavior is like if MG>> ptrace(PT_TRACE_ME) failed in the child by some reason. Unfortunately, truss MG>> does not check this. AY> ktrace -i for truss sleep 5 AY> http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop after execve() and wait4() in parent (which was actually waiting for this stop) returned only after the child exit. No I idea why so far :-). -- Mikolaj Golub From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 14:05:54 2011 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 4C5F81065672 for ; Mon, 19 Sep 2011 14:05:54 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 076728FC0C for ; Mon, 19 Sep 2011 14:05:53 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 2962414E6051; Mon, 19 Sep 2011 15:50:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ka-BgolroeFv; Mon, 19 Sep 2011 15:50:33 +0200 (CEST) Received: from [192.168.1.106] (catv-80-98-232-12.catv.broadband.hu [80.98.232.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 6E3FA14E604C; Mon, 19 Sep 2011 15:50:33 +0200 (CEST) Message-ID: <4E7748A3.8060104@FreeBSD.org> Date: Mon, 19 Sep 2011 15:50:27 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0a1) Gecko/20110904 Thunderbird/9.0a1 MIME-Version: 1.0 To: poyopoyo@puripuri.plala.or.jp References: <86ehzds423.wl%poyopoyo@puripuri.plala.or.jp> In-Reply-To: <86ehzds423.wl%poyopoyo@puripuri.plala.or.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: bsdgrep-20110912: -F/fgrep enbug 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, 19 Sep 2011 14:05:54 -0000 On 2011.09.19. 3:40, poyopoyo@puripuri.plala.or.jp wrote: > Hi, > > I found another issue, this time in bsdgrep-20110912 in port. > > Thanks for using BSD grep and reporting bugs! I've checked and confirmed these issues. In my development branch I have already committed a partial fix. It will be fixed shortly in the development version and in ports and I'll also try to get it fixed in 9.0 before it is released. Gabor From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 15:00:49 2011 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 4E3BF106566B for ; Mon, 19 Sep 2011 15:00:49 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 0A0478FC17 for ; Mon, 19 Sep 2011 15:00:48 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R5fKy-0006CZ-14 for freebsd-current@freebsd.org; Mon, 19 Sep 2011 17:00:48 +0200 Received: from 178.214.36.169 ([178.214.36.169]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Sep 2011 17:00:48 +0200 Received: from citrin by 178.214.36.169 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Sep 2011 17:00:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Anton Yuzhaninov Date: Mon, 19 Sep 2011 15:00:31 +0000 (UTC) Organization: Vega Lines: 23 Sender: Anton Yuzhaninov Message-ID: References: <4E5E46A4.3060705@citrin.ru> <4E6A99A9.1000204@delphij.net> <864o0adkva.fsf@kopusha.home.net> <86mxe0r8o5.fsf@in138.ua3> X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 178.214.36.169 X-Comment-To: Mikolaj Golub User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/9.0-BETA2 (i386)) Subject: Re: truss 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, 19 Sep 2011 15:00:49 -0000 On Mon, 19 Sep 2011 15:58:02 +0300, Mikolaj Golub wrote: AY>> ktrace -i for truss sleep 5 AY>> http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt MG> MG> Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop after MG> execve() and wait4() in parent (which was actually waiting for this stop) MG> returned only after the child exit. No I idea why so far :-). MG> As I understand SIGTRAP used to stop child process after execve(), but this signal ignored: citrin:~> sleep 300 & citrin:~> procstat -i 1991 | fgrep TRAP 1991 sleep TRAP -I- Under FreeBSD 8, where ptrace works for me, this signal is not ignored: x:~> sleep 300 & x:~> procstat -i 78716 | fgrep TRAP 78716 sleep TRAP --- -- Anton Yuzhaninov From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 15:24:46 2011 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 39D03106564A for ; Mon, 19 Sep 2011 15:24:46 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id ECBED8FC0C for ; Mon, 19 Sep 2011 15:24:45 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R5fi8-000323-Q2 for freebsd-current@freebsd.org; Mon, 19 Sep 2011 17:24:44 +0200 Received: from 178.214.36.169 ([178.214.36.169]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Sep 2011 17:24:44 +0200 Received: from citrin by 178.214.36.169 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Sep 2011 17:24:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Anton Yuzhaninov Date: Mon, 19 Sep 2011 15:24:32 +0000 (UTC) Organization: Vega Lines: 21 Sender: Anton Yuzhaninov Message-ID: X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 178.214.36.169 User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/9.0-BETA2 (i386)) Subject: Dtrace: type mismatch in sys/kern/kern_sig.c 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, 19 Sep 2011 15:24:46 -0000 In the file sys/kern/kern_sig.c defined DTrace probe proc:::signal-discard SDT_PROBE_DEFINE(proc, kernel, , signal_discard, signal-discard); SDT_PROBE_ARGTYPE(proc, kernel, , signal_discard, 0, "struct thread *"); SDT_PROBE_ARGTYPE(proc, kernel, , signal_discard, 1, "struct proc *"); SDT_PROBE_ARGTYPE(proc, kernel, , signal_discard, 2, "int"); Then latter this proble called as: SDT_PROBE(proc, kernel, , signal_discard, ps, td, sig, 0, 0 ); type for var ps is struct sigacts* =! struct thread * (bug?) type for var td is struct thread * =! struct proc * (bug?) type for var sig is int == int (ok) To match solaris DTrace probe shuild called as: SDT_PROBE(proc, kernel, , signal_discard, td, p, sig, 0, 0 ); -- Anton Yuzhaninov From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 16:01:51 2011 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 DAD1B1065673 for ; Mon, 19 Sep 2011 16:01:51 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id 9DBDB8FC0A for ; Mon, 19 Sep 2011 16:01:51 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 471D57F383F; Mon, 19 Sep 2011 17:52:53 +0200 (CEST) Date: Mon, 19 Sep 2011 17:52:53 +0200 From: Roman Divacky To: Jason Harmening Message-ID: <20110919155253.GA35727@freebsd.org> References: <20110917062309.GA82256@freebsd.org> <20110917214448.GA87874@freebsd.org> <20110919154654.GA35232@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110919154654.GA35232@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Crashes in world built w/ clang: FP registers? 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, 19 Sep 2011 16:01:51 -0000 On Mon, Sep 19, 2011 at 05:46:54PM +0200, Roman Divacky wrote: > On Sun, Sep 18, 2011 at 11:05:55AM -0500, Jason Harmening wrote: > > > Can you try building just tcsh ? I wonder if -O0 makes any difference... > > > > > > in either case, can you give me preprocessed (clang -E) source that > > > exhibits this bug (check with objdump -d that the unaligned sse read > > > is there) and show me how to reproduce that... I'll try that here. > > > > > > > > > To be honest, I am not sure why others are not seeing this behaviour :( > > > > > > roman > > > > > > > Building w/ -O0 eliminated the crash in csh at least. In that case, > > tw_collect() isn't even using the SSE registers. > > I've attached the objdump output for csh for both the -O2 and -O0 > > cases, along w/ the preprocessor output for tw.parse.c. > > it doesnt build for me.. with tons of errors like > > pes ~$ clang tw.parse.cpp > In file included from ../../contrib/tcsh/tw.parse.c:1: > In file included from ../../contrib/tcsh/tw.parse.c:36: > In file included from ../../contrib/tcsh/sh.h:38: > /usr/include/stddef.h:57:19: error: cannot combine with previous 'type-name' > declaration specifier > typedef __wchar_t wchar_t; > ^ > > how did you get the preprocessed file? and/or how do you compile it? Nevermind... I managed to save the file as a .cpp file :) But I am not seeing any misaligned SSE reads/writes: pes ~$ clang -O2 -c tw.parse.c && objdump -d tw.parse.o | grep movaps 23: 0f 29 85 60 ff ff ff movaps %xmm0,0xffffffffffffff60(%rbp) 3f6: 0f 29 85 10 ff ff ff movaps %xmm0,0xffffffffffffff10(%rbp) 6b6: 0f 29 85 f0 fe ff ff movaps %xmm0,0xfffffffffffffef0(%rbp) 85b: 0f 29 45 c0 movaps %xmm0,0xffffffffffffffc0(%rbp) 867: 0f 29 45 a0 movaps %xmm0,0xffffffffffffffa0(%rbp) 873: 0f 29 45 80 movaps %xmm0,0xffffffffffffff80(%rbp) b37: 0f 29 85 d0 fe ff ff movaps %xmm0,0xfffffffffffffed0(%rbp) e2c: 0f 29 85 c0 fe ff ff movaps %xmm0,0xfffffffffffffec0(%rbp) e3e: 0f 29 85 a0 fe ff ff movaps %xmm0,0xfffffffffffffea0(%rbp) e50: 0f 29 85 80 fe ff ff movaps %xmm0,0xfffffffffffffe80(%rbp) 1a4b: 0f 29 45 c0 movaps %xmm0,0xffffffffffffffc0(%rbp) 21e3: 0f 29 45 d0 movaps %xmm0,0xffffffffffffffd0(%rbp) 2647: 0f 29 85 50 fe ff ff movaps %xmm0,0xfffffffffffffe50(%rbp) 2659: 0f 29 85 30 fe ff ff movaps %xmm0,0xfffffffffffffe30(%rbp) How exactly are you compiling it? roman From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 16:04:07 2011 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 060B4106566B for ; Mon, 19 Sep 2011 16:04:07 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 8879B8FC14 for ; Mon, 19 Sep 2011 16:04:06 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R5gKC-00006W-Bl for freebsd-current@freebsd.org; Mon, 19 Sep 2011 18:04:04 +0200 Received: from 178.214.36.169 ([178.214.36.169]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Sep 2011 18:04:04 +0200 Received: from citrin by 178.214.36.169 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Sep 2011 18:04:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Anton Yuzhaninov Date: Mon, 19 Sep 2011 16:03:42 +0000 (UTC) Organization: Vega Lines: 46 Sender: Anton Yuzhaninov Message-ID: References: <4E5E46A4.3060705@citrin.ru> <4E6A99A9.1000204@delphij.net> <864o0adkva.fsf@kopusha.home.net> <86mxe0r8o5.fsf@in138.ua3> X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 178.214.36.169 X-Comment-To: Anton Yuzhaninov User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/9.0-BETA2 (i386)) Subject: Re: truss 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, 19 Sep 2011 16:04:07 -0000 On Mon, 19 Sep 2011 15:00:31 +0000 (UTC), Anton Yuzhaninov wrote: AY> On Mon, 19 Sep 2011 15:58:02 +0300, Mikolaj Golub wrote: AY>>> ktrace -i for truss sleep 5 AY>>> http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt MG>> MG>> Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop after MG>> execve() and wait4() in parent (which was actually waiting for this stop) MG>> returned only after the child exit. No I idea why so far :-). MG>> AY> AY> As I understand SIGTRAP used to stop child process after execve(), but AY> this signal ignored: AY> AY> citrin:~> sleep 300 & AY> citrin:~> procstat -i 1991 | fgrep TRAP AY> 1991 sleep TRAP -I- AY> AY> Under FreeBSD 8, where ptrace works for me, this signal is not ignored: AY> x:~> sleep 300 & AY> x:~> procstat -i 78716 | fgrep TRAP AY> 78716 sleep TRAP --- SIGTRAP is ignored by X window manager used by me, and this is inherited across forks/execs up to the truss. IMHO truss should restore default signal handler for SIGTRAP. With this patch truss works for me: --- usr.bin/truss/main.c (revision 225504) +++ usr.bin/truss/main.c (working copy) @@ -255,6 +255,11 @@ main(int ac, char **av) if (trussinfo->pid == 0) { /* Start a command ourselves */ command = av; + /* + * SIGTRUP used to stop traced process after execve + * un-ignore this signal (it can be ignored by parents) + */ + signal(SIGTRAP, SIG_DFL); trussinfo->pid = setup_and_wait(command); signal(SIGINT, SIG_IGN); signal(SIGTERM, SIG_IGN); -- Anton Yuzhaninov From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 16:06:51 2011 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 E6B8E106566C for ; Mon, 19 Sep 2011 16:06:51 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id A8CC88FC14 for ; Mon, 19 Sep 2011 16:06:51 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id A76017F383A; Mon, 19 Sep 2011 17:46:54 +0200 (CEST) Date: Mon, 19 Sep 2011 17:46:54 +0200 From: Roman Divacky To: Jason Harmening Message-ID: <20110919154654.GA35232@freebsd.org> References: <20110917062309.GA82256@freebsd.org> <20110917214448.GA87874@freebsd.org> 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: freebsd-current@freebsd.org Subject: Re: Crashes in world built w/ clang: FP registers? 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, 19 Sep 2011 16:06:52 -0000 On Sun, Sep 18, 2011 at 11:05:55AM -0500, Jason Harmening wrote: > > Can you try building just tcsh ? I wonder if -O0 makes any difference... > > > > in either case, can you give me preprocessed (clang -E) source that > > exhibits this bug (check with objdump -d that the unaligned sse read > > is there) and show me how to reproduce that... I'll try that here. > > > > > > To be honest, I am not sure why others are not seeing this behaviour :( > > > > roman > > > > Building w/ -O0 eliminated the crash in csh at least. In that case, > tw_collect() isn't even using the SSE registers. > I've attached the objdump output for csh for both the -O2 and -O0 > cases, along w/ the preprocessor output for tw.parse.c. it doesnt build for me.. with tons of errors like pes ~$ clang tw.parse.cpp In file included from ../../contrib/tcsh/tw.parse.c:1: In file included from ../../contrib/tcsh/tw.parse.c:36: In file included from ../../contrib/tcsh/sh.h:38: /usr/include/stddef.h:57:19: error: cannot combine with previous 'type-name' declaration specifier typedef __wchar_t wchar_t; ^ how did you get the preprocessed file? and/or how do you compile it? roman From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 19:20:18 2011 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 DE4C1106566B for ; Mon, 19 Sep 2011 19:20:18 +0000 (UTC) (envelope-from alissonfer@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id AEAEE8FC17 for ; Mon, 19 Sep 2011 19:20:18 +0000 (UTC) Received: by iadk27 with SMTP id k27so8881632iad.13 for ; Mon, 19 Sep 2011 12:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Z2IZFPo4weD8LIWNACL5DGToMhis/lHyMPNpD7E2zwU=; b=kLWRGTR1U4ziDMC5U1Lwk7Q3W7HB9lo8ECCQGroxjS9p5z4ILu1KlwOvVQ+3DtYaKg ZCkfY2OdecDysupOO5g3bxzx6JaNpVRM6eabzOfDStJG1qgLcJWcd6PB7axB3w5fGSM4 yJ7A9qBumFO6CkSnTdRpdVfOcK+JNuZgcgLs8= MIME-Version: 1.0 Received: by 10.42.131.7 with SMTP id x7mr5213887ics.187.1316460018340; Mon, 19 Sep 2011 12:20:18 -0700 (PDT) Received: by 10.42.241.65 with HTTP; Mon, 19 Sep 2011 12:20:18 -0700 (PDT) Date: Mon, 19 Sep 2011 16:20:18 -0300 Message-ID: From: Alisson To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: USB Keyboard doesn't work 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, 19 Sep 2011 19:20:18 -0000 Hi.. in a new installation of freebsd 8.2 (amd64) if the machine doesn't have a PS2 port to use keyboard... and have only USB port its impossible to use an keyboard on mountroot prompt From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 21:29:02 2011 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 2F522106564A for ; Mon, 19 Sep 2011 21:29:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id C13548FC16 for ; Mon, 19 Sep 2011 21:29:01 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p8JLRMiP047529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Sep 2011 00:27:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id p8JLRM3M005495; Tue, 20 Sep 2011 00:27:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id p8JLRMFE005494; Tue, 20 Sep 2011 00:27:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 20 Sep 2011 00:27:22 +0300 From: Kostik Belousov To: Anton Yuzhaninov Message-ID: <20110919212722.GQ1511@deviant.kiev.zoral.com.ua> References: <4E5E46A4.3060705@citrin.ru> <4E6A99A9.1000204@delphij.net> <864o0adkva.fsf@kopusha.home.net> <86mxe0r8o5.fsf@in138.ua3> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OWK2L5TNMedLh6HD" Content-Disposition: inline In-Reply-To: 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=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no 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: truss 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, 19 Sep 2011 21:29:02 -0000 --OWK2L5TNMedLh6HD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 19, 2011 at 04:03:42PM +0000, Anton Yuzhaninov wrote: > On Mon, 19 Sep 2011 15:00:31 +0000 (UTC), Anton Yuzhaninov wrote: > AY> On Mon, 19 Sep 2011 15:58:02 +0300, Mikolaj Golub wrote: > AY>>> ktrace -i for truss sleep 5 > AY>>> http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt > MG>>=20 > MG>> Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not st= op after > MG>> execve() and wait4() in parent (which was actually waiting for this = stop) > MG>> returned only after the child exit. No I idea why so far :-). > MG>>=20 > AY>=20 > AY> As I understand SIGTRAP used to stop child process after execve(), but > AY> this signal ignored: > AY>=20 > AY> citrin:~> sleep 300 & > AY> citrin:~> procstat -i 1991 | fgrep TRAP > AY> 1991 sleep TRAP -I- > AY>=20 > AY> Under FreeBSD 8, where ptrace works for me, this signal is not ignore= d: > AY> x:~> sleep 300 & > AY> x:~> procstat -i 78716 | fgrep TRAP > AY> 78716 sleep TRAP --- >=20 > SIGTRAP is ignored by X window manager used by me, and this is inherited = across > forks/execs up to the truss. >=20 > IMHO truss should restore default signal handler for SIGTRAP. >=20 > With this patch truss works for me: >=20 > --- usr.bin/truss/main.c (revision 225504) > +++ usr.bin/truss/main.c (working copy) > @@ -255,6 +255,11 @@ main(int ac, char **av) >=20 > if (trussinfo->pid =3D=3D 0) { /* Start a command ourselves = */ > command =3D av; > + /* > + * SIGTRUP used to stop traced process after execve > + * un-ignore this signal (it can be ignored by parents) > + */ > + signal(SIGTRAP, SIG_DFL); > trussinfo->pid =3D setup_and_wait(command); > signal(SIGINT, SIG_IGN); > signal(SIGTERM, SIG_IGN); This is quite a hack. The proper fix should go in kernel, otherwise we cannot debug programs that decided to ignore SIGTRAP. The reason there is that tdsendsignal() does nothing for attempt to deliver ignored signal, and kern_execve() simply tries to send a signal to self. BTW, it seems we might also have similar issues for threads that masks SIGTRAP, now because issignal() does nothing in that case too. But lets handle it by small steps. Could you, please, test the change below ? For me, I still can truss(1) or debug with gdb after the change applied. Does truss work for you with only this change, without resetting SIGTRAP handler in truss process ? commit 2ae586c039a55399edc3b34cd40410e0d690a16c Author: Konstantin Belousov Date: Tue Sep 20 00:25:07 2011 +0300 Do not deliver SIGTRAP on exec as the normal signal, use ptracestop() on syscall exit path. Otherwise, if SIGTRAP is ignored, that tdsendsign= al() do not want to deliver, and debugger never get a notification of exec. =20 Found by: Anton Yuzhaninov diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c index fe01142..4545848 100644 --- a/sys/kern/kern_exec.c +++ b/sys/kern/kern_exec.c @@ -777,16 +777,6 @@ interpret: KNOTE_LOCKED(&p->p_klist, NOTE_EXEC); p->p_flag &=3D ~P_INEXEC; =20 - /* - * If tracing the process, trap to the debugger so that - * breakpoints can be set before the program executes. We - * have to use tdsignal() to deliver the signal to the current - * thread since any other threads in this process will exit if - * execve() succeeds. - */ - if (p->p_flag & P_TRACED) - tdsignal(td, SIGTRAP); - /* clear "fork but no exec" flag, as we _are_ execing */ p->p_acflag &=3D ~AFORK; =20 diff --git a/sys/kern/subr_syscall.c b/sys/kern/subr_syscall.c index cb0d929..bba4479 100644 --- a/sys/kern/subr_syscall.c +++ b/sys/kern/subr_syscall.c @@ -204,9 +204,17 @@ syscallret(struct thread *td, int error, struct syscal= l_args *sa __unused) * is not the case, this code will need to be revisited. */ STOPEVENT(p, S_SCX, sa->code); - PTRACESTOP_SC(p, td, S_PT_SCX); if (traced || (td->td_dbgflags & (TDB_EXEC | TDB_FORK)) !=3D 0) { PROC_LOCK(p); + /* + * If tracing the execed process, trap to the debugger + * so that breakpoints can be set before the program + * executes. If debugger requested tracing of syscall + * returns, do it now too. + */ + if (traced && ((td->td_dbgflags & TDB_EXEC) !=3D 0 || + (p->p_stops & S_PT_SCX) !=3D 0)) + ptracestop(td, SIGTRAP); td->td_dbgflags &=3D ~(TDB_SCX | TDB_EXEC | TDB_FORK); PROC_UNLOCK(p); } --OWK2L5TNMedLh6HD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk53s7oACgkQC3+MBN1Mb4gVnQCeNaNaGJ66YRXh1LbdzO6b7EU7 JQYAn0IYN6P92oPCqHCKROzwIv5di0Xg =87+g -----END PGP SIGNATURE----- --OWK2L5TNMedLh6HD-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 23:03:40 2011 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 4E08F106564A for ; Mon, 19 Sep 2011 23:03:40 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id C7AC28FC0A for ; Mon, 19 Sep 2011 23:03:39 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-8-217.lns20.adl2.internode.on.net [118.210.8.217]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p8JN3Vm7074696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Sep 2011 08:33:36 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: Date: Tue, 20 Sep 2011 08:33:31 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alisson X-Mailer: Apple Mail (2.1244.3) X-Spam-Score: 2.162 (**) BAYES_00,KHOP_DYNAMIC,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-current@freebsd.org Subject: Re: USB Keyboard doesn't work 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, 19 Sep 2011 23:03:40 -0000 On 20/09/2011, at 4:50, Alisson wrote: > in a new installation of freebsd 8.2 (amd64) >=20 > if the machine doesn't have a PS2 port to use keyboard... and have = only USB > port its impossible to use an keyboard on mountroot prompt Try typing this in the loader prompt.. set kern.cam.boot_delay=3D10000 Or putting kern.cam.boot_delay=3D10000 in /boot/loader.conf. Stolen from = http://lists.freebsd.org/pipermail/freebsd-usb/2010-July/008847.html > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >=20 -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Mon Sep 19 23:14:09 2011 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 0FD25106564A; Mon, 19 Sep 2011 23:14:09 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id 910A48FC15; Mon, 19 Sep 2011 23:14:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; q=dns/txt; s=DKIM-NAME-SERVICES; d=a1poweruser.com; h=From:To:Cc:Subject:Message-ID:X-Sender:X-Envelope-From; l=500; bh=2cF2FWFsVV3NgggXXUMAduHV1hvTprV9TE8KuDp9pgE=; b=YGhrPCX6+0Dmpv8BC2nEuKFrVTrtF4E1SlDAbQjOBHHH8VDBaB1fM9/bYNPG8xC8yRm8uWG9tqubQUZVA5hpSgGb/7EEd0vwwVR32mh9usLwZr/UHrlPCnGOj/a0blZFtTGQ0TAq5gOKFUKjqAejxixdniINigmZD/4v+EOCKXE= Received: from [192.168.1.64] ([76.240.47.196]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Sep 2011 16:14:08 -0700 Message-ID: <4E77CCC2.1000103@a1poweruser.com> Date: Mon, 19 Sep 2011 19:14:10 -0400 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Nathan Whitehorn References: <4E71F647.2050007@a1poweruser.com> <4E7453CB.1040908@freebsd.org> <4E74C9B7.2090901@a1poweruser.com> In-Reply-To: <4E74C9B7.2090901@a1poweruser.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2011 23:14:08.0544 (UTC) FILETIME=[D5706200:01CC7721] X-Sender: fbsd8@a1poweruser.com X-Envelope-From: fbsd8*a1poweruser.com Cc: freebsd-current@freebsd.org, FreeBSD Questions Subject: Re: 9.0 bata2 & keymap 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, 19 Sep 2011 23:14:09 -0000 > Now I must point out that I tested hitting the cancel button in the > kbdmap command. It worked in that no keymap= statement was inserted into > /etc/rc.conf but it must also make some other changes some where else in > the system because if you do select an entry from the kbdmap database > and them remove the keymap= statement that was inserted into > /etc/rc.conf and then reboot the system, it will hang on reboot. > > Another point of interest is when selecting "cancel for the default > keyboard" still results in the block of 9 keys above the arrow keys to > not function. Issuing the "man cmd_name" command does display the man > page, but the {Page up, Page down keys } don't work. Also when using the > "ee" edit command the {delete, Page up, Page down don't work. There may > be more system utility commands with the same flaw. > > This may indicate that the default keyboard map in kbdmap command has > changed, is not the same as in previous releases or some thing else in > the 9.0 system has changed. In either case this needs research. > > Joe > I continued to research this problem and found the cause. The content of 9.0 /etc/ttys has changed, (IE; cons25 is now xtern). I have some changes in ttys on 8.2 and I just copied that file over to 9.0 without looking at the content. The block of 9 keys above the arrow keys now work correctly. From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 00:20:31 2011 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 1F0BC1065672 for ; Tue, 20 Sep 2011 00:20:31 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [66.90.118.40]) by mx1.freebsd.org (Postfix) with ESMTP id E60218FC12 for ; Tue, 20 Sep 2011 00:20:30 +0000 (UTC) Received: from feathers.peganest.com ([46.69.94.2]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id p8JNi3wI002280 for ; Mon, 19 Sep 2011 23:44:04 GMT (envelope-from ken@mthelicon.com) From: Pegasus Mc Cleaft Organization: Feathers To: freebsd-current@freebsd.org Date: Tue, 20 Sep 2011 00:39:48 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-BETA2; KDE/4.6.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109200039.48139.ken@mthelicon.com> X-Spam-Status: No, score=-1.1 required=15.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on hercules.mthelicon.com Subject: Re: USB Keyboard doesn't work 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, 20 Sep 2011 00:20:31 -0000 On Monday 19 September 2011 20:20:18 Alisson wrote: > if the machine doesn't have a PS2 port to use keyboard... and have only USB > port its impossible to use an keyboard on mountroot prompt Hi Alisson, I dont know the complete ins and outs of this, but I think it has a lot to do with the BIOS on your machine and/or how it is configured (IE: PS2 emulation). I have a machine that used to work just fine during the boot-loader and mountroot part of booting, but after a BIOS upgrade, it would no longer work; only the PS2 keyboard was active until the machine had booted far enough to bring up the USB stack. Check your BIOS settings and see if any of them mention something about USB keyboards. Ta Peg From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 00:20:56 2011 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 A69851065670; Tue, 20 Sep 2011 00:20:56 +0000 (UTC) (envelope-from olivares14031@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 590FC8FC18; Tue, 20 Sep 2011 00:20:56 +0000 (UTC) Received: by iadk27 with SMTP id k27so9236377iad.13 for ; Mon, 19 Sep 2011 17:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9UCBojVnLKF7TVrKcc4R9mc+mlFAMPvz9z55npxMAwQ=; b=j2fHfKWxU6cs6gVnnsWiHYNtne17KQW3TSDhINorutEKuP8jvKmP2GzowwQvmRk/Kd LgPz68xEq+QT1s4OhgztjglZ+8aYKJyr5TGiORLezpNYyjzLY0GgkcsaWACtV4VEioqU y5TXYae3tJFW+DmnwJrvjj1LNvftpV1xDz2tA= MIME-Version: 1.0 Received: by 10.42.159.130 with SMTP id l2mr216778icx.203.1316477901535; Mon, 19 Sep 2011 17:18:21 -0700 (PDT) Received: by 10.42.177.199 with HTTP; Mon, 19 Sep 2011 17:18:21 -0700 (PDT) In-Reply-To: <4E77CCC2.1000103@a1poweruser.com> References: <4E71F647.2050007@a1poweruser.com> <4E7453CB.1040908@freebsd.org> <4E74C9B7.2090901@a1poweruser.com> <4E77CCC2.1000103@a1poweruser.com> Date: Mon, 19 Sep 2011 19:18:21 -0500 Message-ID: From: Antonio Olivares To: Fbsd8 Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Nathan Whitehorn , FreeBSD Questions Subject: Re: 9.0 bata2 & keymap 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, 20 Sep 2011 00:20:56 -0000 > > I continued to research this problem and found the cause. > The content of 9.0 /etc/ttys has changed, (IE; cons25 is now xtern). > I have some changes in ttys on 8.2 and I just copied that file over to 9.0 > without looking at the content. The block of 9 keys above the arrow keys now > work correctly. > > I saw the keyboard layout and there are many :(, I don't even know if I have a standard 101/105 US keyboard. When I press up arrow, I get an 8 on the screen :( I was going to ask on another thread/create a new thread, but I guess this one is the correct one to ask? Regards, Antonio From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 00:25:30 2011 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 14FD61065670 for ; Tue, 20 Sep 2011 00:25:30 +0000 (UTC) (envelope-from olivares14031@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id D501B8FC0A for ; Tue, 20 Sep 2011 00:25:29 +0000 (UTC) Received: by iadk27 with SMTP id k27so9241150iad.13 for ; Mon, 19 Sep 2011 17:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GB30iVCIT4A7G6sL+g/PzR2Hx+iJXZN2RwZwPhjcB48=; b=e9XcgY9ARykWO2JM+QsuE6AhcZq9WNg9h3XUrynEWEwnlVmhYs+O8/Os/DZAiviEqs gHi1N39WlYrjekGmuG+pehiMGENY8w/lWqHvYMcuHaQtzMaqYlPavY3K3TmRCKJ8b/ir lNlIHb9FZSzrBfhSjsKPrivfrZf24TfiD9hww= MIME-Version: 1.0 Received: by 10.42.154.135 with SMTP id q7mr254271icw.87.1316478133985; Mon, 19 Sep 2011 17:22:13 -0700 (PDT) Received: by 10.42.177.199 with HTTP; Mon, 19 Sep 2011 17:22:13 -0700 (PDT) In-Reply-To: <1316359940.1744.28.camel@xenon> References: <1316359940.1744.28.camel@xenon> Date: Mon, 19 Sep 2011 19:22:13 -0500 Message-ID: From: Antonio Olivares To: Michal Varga Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: How does one install kernel sources and base 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, 20 Sep 2011 00:25:30 -0000 >> =A0 But my question is as follows, >> How do I get kernel sources and base installed? > > You can download them via csup with a config file similar to this: > > *default host=3Dcvsup5.FreeBSD.org > *default base=3D/var/db > *default prefix=3D/usr > *default release=3Dcvs tag=3D. > *default compress delete use-rel-suffix > src-all > > Save your config file (or so called supfile) someplace and run it as: > # csup your.supfile > > csup will download the latest source tree for kernel and base OS. > > Also, see FreeBSD Handbook for more information on using csup (or the > older, but functionally identical cvsup), and for many other questions > regarding general FreeBSD installation and maintenance: > > http://www.freebsd.org/doc/handbook/cvsup.html > > m. > > -- > Michal Varga, > Stonehenge (Gmail account) > Michal, Thank you very much for your detailed instruction. I was able to get all of the sources and built nvidia driver successfully :) However, when I run kldload nvidia, I get a mismatch with the running kernel and an incompatible ?????. I cannot post exact error as the machine gives me no X :(, I checked to see if enabling hald and dbus at /etc/rc.conf would make a difference and they have not :(, I have also tried nouveau and it also does not work. No working X on FreeBSD 9.0 BETA 2 amd64, ports updated to latest, xorg, xorg-server, xfce4, ... I will post in the thread I created on this issue. Regards, Antonio From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 00:31:34 2011 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 1935B1065675 for ; Tue, 20 Sep 2011 00:31:34 +0000 (UTC) (envelope-from olivares14031@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id D94B28FC16 for ; Tue, 20 Sep 2011 00:31:33 +0000 (UTC) Received: by iadk27 with SMTP id k27so9248095iad.13 for ; Mon, 19 Sep 2011 17:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=akdDLTQzPXTXceApCkSm5iiPWElusX+57u+w/2dzGpI=; b=Lb8bSKfUnFjO9xCYezw+slZONFdaC4O+ZcVt2voleRofHjsXp2YepFwcvMSkKsqLBO IEoVrEFqBUtEwykrDaLTecgTZ+z5BYwy+CZSa44YpRMK2Go9hb6y3oDpejYu3zD1KML9 D+TSU5qSULrk0CinUMOgtXumS2wBEd+a7PDj4= MIME-Version: 1.0 Received: by 10.42.154.135 with SMTP id q7mr264152icw.87.1316478693133; Mon, 19 Sep 2011 17:31:33 -0700 (PDT) Received: by 10.42.177.199 with HTTP; Mon, 19 Sep 2011 17:31:33 -0700 (PDT) In-Reply-To: References: <20110918042853.3D61C106566C@hub.freebsd.org> Date: Mon, 19 Sep 2011 19:31:33 -0500 Message-ID: From: Antonio Olivares To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, "Thomas Mueller List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 00:31:34 -0000 I added this to /etc/rc.conf >>> hald_enable=3D"YES" >>> dbus_enable=3D"YES" but machine still gives no working X :( >> >> =A0 =A0This seems like more of a question@ issue. >> =A0 =A0I doubt that the above claim is at fault, given past experience. >> What does /var/log/Xorg.0.log say, and what does your xorg.conf >> contain? I would like to return this, but have no way of saving output :( I have updated via ports to latest tree available and have used csup to get kernel sources to install nvidia-driver, but kldload nvidia, returns a mismatch another type of error, I recompiled xorg-server and no hal was in configuration, but X does not work. with nv, nvidia(after compilation), and noveau no working X :( What can I do? I have two machines with nvidia chipsets one integrated in the motherboard and another nvidia Gforce card and amd64 8.2 works great. This is an integrated motherboard. As I am not an expert, I ask for advice/suggestions/comments to get this go= ing. Regards, Antonio From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 00:33:08 2011 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 C9A3B106567B for ; Tue, 20 Sep 2011 00:33:08 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 8CF478FC12 for ; Tue, 20 Sep 2011 00:33:08 +0000 (UTC) Received: by iagv1 with SMTP id v1so8222829iag.30 for ; Mon, 19 Sep 2011 17:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=sclp7bEMeQ8cZxWRnJkqVOOAzR/Z6MlI4NboSGceZSw=; b=XDxZ84IXsVaXyjtvldpOKY61lcGzpfBpNPmwQQSLKgLkaltcpTYa7Sdf/qEgf3U+Ws worf2m6tKcHwhk9QuOfrUV70hgxpJtNcu4RbdHh72l6lI52J6r0hDry9c6kqWn/2oWyH 8VAFLwUm9QpOlIP9Ef1CZa6Lt6WHP4cBStAs4= Received: by 10.231.28.3 with SMTP id k3mr211241ibc.91.1316478787792; Mon, 19 Sep 2011 17:33:07 -0700 (PDT) Received: from kruse-111.3.ixsystems.com (drawbridge.ixsystems.com. [206.40.55.65]) by mx.google.com with ESMTPS id g16sm27900195ibs.8.2011.09.19.17.33.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Sep 2011 17:33:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: Garrett Cooper In-Reply-To: Date: Mon, 19 Sep 2011 17:33:03 -0700 Message-Id: <5A201C93-8E29-4067-896E-42F07D5AE60A@gmail.com> References: <1316359940.1744.28.camel@xenon> To: Antonio Olivares X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Michal Varga Subject: Re: How does one install kernel sources and base 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, 20 Sep 2011 00:33:08 -0000 On Sep 19, 2011, at 5:22 PM, Antonio Olivares wrote: >>=20 >> *default host=3Dcvsup5.FreeBSD.org >> *default base=3D/var/db >> *default prefix=3D/usr >> *default release=3Dcvs tag=3D. >> *default compress delete use-rel-suffix >> src-all >>=20 >> Save your config file (or so called supfile) someplace and run it as: >> # csup your.supfile >>=20 >> csup will download the latest source tree for kernel and base OS. >>=20 >> Also, see FreeBSD Handbook for more information on using csup (or the >> older, but functionally identical cvsup), and for many other = questions >> regarding general FreeBSD installation and maintenance: >>=20 >> http://www.freebsd.org/doc/handbook/cvsup.html >=20 > Michal, >=20 > Thank you very much for your detailed instruction. I was able to get > all of the sources and built nvidia driver successfully :) >=20 > However, when I run kldload nvidia, I get a mismatch with the running > kernel and an incompatible ?????. I cannot post exact error as the > machine gives me no X :(, I checked to see if enabling hald and dbus > at /etc/rc.conf would make a difference and they have not :(, I have > also tried nouveau and it also does not work. No working X on FreeBSD > 9.0 BETA 2 amd64, ports updated to latest, xorg, xorg-server, xfce4, > ... I will post in the thread I created on this issue. A not very well documented hint.. $ grep PORTS_MODULES=3D /etc/src.conf=20 PORTS_MODULES=3D emulators/virtualbox-ose-kmod = x11/nvidia-driver You'll also need to boot with the new kernel. Be sure to read = the complete handbook chapter on how to update your system from source = if you plan to go that route. Once things go release you might be able to update your binaries = via freebsd-update. If this seems really complicated and you want a simplified = desktop experience, there's also PCBSD. HTH, -Garrett= From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 00:35:28 2011 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 3487B1065672 for ; Tue, 20 Sep 2011 00:35:28 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id F14E88FC0C for ; Tue, 20 Sep 2011 00:35:27 +0000 (UTC) Received: by iadk27 with SMTP id k27so9251421iad.13 for ; Mon, 19 Sep 2011 17:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=Ifw2FRSbSab+Q30BV2vHIIssuLwCOEW1N/K1u33FDgI=; b=JjPdPS9gIBimUFkm/xOXioNr5Y5aBbHqtKITZXSAgHxbkA47qkd6+CytX62vzej/EC Ci8ioGQSPVwSN7TuPKbmY4tDRY2eElPM1WERbVo0isTLo6WPn+uHr2h2rE3qteJc+w+2 zi9oS4Ju9ma8WMgCo4sXuCA6FS0z/nglR3rQM= Received: by 10.42.153.130 with SMTP id m2mr231661icw.155.1316478927350; Mon, 19 Sep 2011 17:35:27 -0700 (PDT) Received: from kruse-111.3.ixsystems.com (drawbridge.ixsystems.com. [206.40.55.65]) by mx.google.com with ESMTPS id by18sm16156344ibb.1.2011.09.19.17.35.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Sep 2011 17:35:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <201109200039.48139.ken@mthelicon.com> Date: Mon, 19 Sep 2011 17:35:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1DEF7FE4-F2EA-422F-A4E5-911226E96AEF@gmail.com> References: <201109200039.48139.ken@mthelicon.com> To: Pegasus Mc Cleaft X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org Subject: Re: USB Keyboard doesn't work 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, 20 Sep 2011 00:35:28 -0000 On Sep 19, 2011, at 4:39 PM, Pegasus Mc Cleaft wrote: > On Monday 19 September 2011 20:20:18 Alisson wrote: >=20 >> if the machine doesn't have a PS2 port to use keyboard... and have = only USB >> port its impossible to use an keyboard on mountroot prompt >=20 > Hi Alisson,=20 >=20 > I dont know the complete ins and outs of this, but I think it = has a lot=20 > to do with the BIOS on your machine and/or how it is configured (IE: = PS2=20 > emulation). Many BIOS vendors label this as "legacy keyboard emulation", = etc. You might want to play with the plug-n-play settings as well (but I = doubt that that would help). HTH, -Garrett= From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 00:56:58 2011 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 25917106566B for ; Tue, 20 Sep 2011 00:56:58 +0000 (UTC) (envelope-from olivares14031@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E42C08FC0A for ; Tue, 20 Sep 2011 00:56:57 +0000 (UTC) Received: by iadk27 with SMTP id k27so21361iad.13 for ; Mon, 19 Sep 2011 17:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=G8GQEL3BkI1iXILp0x4v/ZxOKJM6lkKaEPmlxwlrt5Q=; b=snzH+5oqVvRMHjmILh3z1XUMlmBtzcYaxaweRE3MDi5uOscqUtkehmETnoEToRx9+R n9sspSe+7F8dOLJbW4NQFtY7jW+r7rE3GWf09zREzTYH41VzttKW+zpYZ4jrfZC470ES qkPbJ/wYzpkChVS7Nhb0e1Y3C4ZQbzrxLuz8k= MIME-Version: 1.0 Received: by 10.42.137.1 with SMTP id w1mr331940ict.29.1316480217290; Mon, 19 Sep 2011 17:56:57 -0700 (PDT) Received: by 10.42.177.199 with HTTP; Mon, 19 Sep 2011 17:56:57 -0700 (PDT) In-Reply-To: <5A201C93-8E29-4067-896E-42F07D5AE60A@gmail.com> References: <1316359940.1744.28.camel@xenon> <5A201C93-8E29-4067-896E-42F07D5AE60A@gmail.com> Date: Mon, 19 Sep 2011 19:56:57 -0500 Message-ID: From: Antonio Olivares To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Michal Varga Subject: Re: How does one install kernel sources and base 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, 20 Sep 2011 00:56:58 -0000 > However, when I run kldload nvidia, I get a mismatch with the running > kernel and an incompatible ?????. =A0I cannot post exact error as the > machine gives me no X :(, I checked to see if enabling hald and dbus > at /etc/rc.conf would make a difference and they have not :(, I have > also tried nouveau and it also does not work. =A0No working X on FreeBSD > 9.0 BETA 2 amd64, ports updated to latest, xorg, xorg-server, xfce4, > ... I will post in the thread I created on this issue. > > A not very well documented hint.. > $ grep PORTS_MODULES=3D /etc/src.conf > PORTS_MODULES=3D emulators/virtualbox-ose-kmod x11/nvidia-driver Garrett, I had installed from 9.0-amd64-BETA2-dvd1 iso, but the bsdinstall flew so fast and I could not use arrow keys to select the src for the kernel, I updated the whole system via ports using portmaster -a, and no matter what I try X does not work. > You'll also need to boot with the new kernel. Be sure to read the complet= e > handbook chapter on how to update your system from source if you plan to = go > that route. It takes a great while to build the system like this, but since it is a BETA, it might not be worth it and then to figure out that X does still not work. Might have to wipe disk clean and reinstall? > Once things go release you might be able to update your binaries via > freebsd-update. > If this seems really complicated and you want a simplified desktop > experience, there's also PCBSD. Nah, prefer native FreeBSD as PCBSD will make it too easy :( + I would like to help out in testing and learn more about FreeBSD. I have tested linux distros before, but they work differently than FreeBSD, and there is not as much fun*, things to try* as they are in FreeBSD beta2? > HTH, > -Garrett Regards, Antonio From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 01:10:10 2011 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 323C8106564A for ; Tue, 20 Sep 2011 01:10:10 +0000 (UTC) (envelope-from varga.michal@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id B85BA8FC14 for ; Tue, 20 Sep 2011 01:10:09 +0000 (UTC) Received: by fxg9 with SMTP id 9so53105fxg.13 for ; Mon, 19 Sep 2011 18:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:organization :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=XoZC/WdUU1VgtbT8NuBYGlZg5EinocpdeKuzv00RUok=; b=Mel/XxiZZQXeE4ZZgfZVWHgSRGTlU6Ziyt/dW3iYBu/PiHXDqy2YAWAXq4rsiODTxj KjubUvSoVqZ5eiXl/qFk62qJ9BluL/fUHGOwCo9cMfpI7XyGBy1XmAPFCVdyZIoCPoxC 7GV/U6tA27Ng7oX0NHC0lCxtygYW87xZYK1gM= Received: by 10.223.39.154 with SMTP id g26mr346890fae.7.1316481008604; Mon, 19 Sep 2011 18:10:08 -0700 (PDT) Received: from [10.0.101.2] (254.166.broadband10.iol.cz. [90.177.166.254]) by mx.google.com with ESMTPS id h21sm11708407fab.25.2011.09.19.18.10.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Sep 2011 18:10:07 -0700 (PDT) From: Michal Varga To: Antonio Olivares In-Reply-To: References: <1316359940.1744.28.camel@xenon> Content-Type: text/plain; charset="UTF-8" Organization: Stonehenge Date: Tue, 20 Sep 2011 03:10:04 +0200 Message-ID: <1316481004.1744.62.camel@xenon> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: How does one install kernel sources and base 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, 20 Sep 2011 01:10:10 -0000 On Mon, 2011-09-19 at 19:22 -0500, Antonio Olivares wrote: > Michal, > > Thank you very much for your detailed instruction. I was able to get > all of the sources and built nvidia driver successfully :) > > However, when I run kldload nvidia, I get a mismatch with the running > kernel and an incompatible ?????. I cannot post exact error as the > machine gives me no X :(, I checked to see if enabling hald and dbus > at /etc/rc.conf would make a difference and they have not :(, I have > also tried nouveau and it also does not work. No working X on FreeBSD > 9.0 BETA 2 amd64, ports updated to latest, xorg, xorg-server, xfce4, > ... I will post in the thread I created on this issue. > > Regards, > > Antonio Some details about the "incompatible ?????" error would be quite useful as without an actual (and exact) error message it's only guessing... But it is possible that your downloaded (latest -HEAD) sources are no longer compatible with your currently running OS, though there being like about a week difference, I find it somewhat unlikely (but always possible). If that's the case, you have two possible routes to take: You can either bring your system up to date corresponding to the latest sources; that is, rebuilding and installing new FreeBSD kernel and world. That should get rid of any incompatibilities you currently experience. It's a pretty straightforward process which in your case amounts to just about - # cd /usr/src # make buildworld installworld kernel - but note that the above mentioned IS NOT an officially supported procedure and you are first REQUIRED to read FreeBSD Handbook and understand the basics of building and updating FreeBSD. I just mention it to illustrate how simple the procedure generally is. But again, don't run it blindly. When unsure, always use the officially supported, while somewhat lenghtier, procedure described in FreeBSD Handbook. Now the other possible route that doesn't involve building and updating FreeBSD at all, is to download the sources that closely match your currently running system. As far as I know (and I wasn't able to find), there is no CVS tag for BETA2, so you can't pull the exact sources that way, but you should be able to get very close with: $ uname -a - and notice when the kernel was built, which was hopefully very close to the time when the sources were pulled from CVS (this is more or less only a guess, so someone involved in release engineering might be of more help with this issue, if there even is any). To do this, you just need to edit your supfile and include the specific date from when to pull the sources: That is, replacing the line: *default release=cvs tag=. With: *default release=cvs tag=. date=2011.09.??.??.??.?? (Just fill in the missing dd, hh, mm, ss values based on the date you already know from uname.) This modified supfile will let you pull sources that should be a very close - if not perfect - match to your current system. You can then rebuild your drivers (i.e. that non-working nvidia module) the regular way. By my humble estimate, that should be enough to fix your issue. m. -- Michal Varga, Stonehenge (Gmail account) From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 01:10:49 2011 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 07C781065686 for ; Tue, 20 Sep 2011 01:10:49 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7DE218FC1F for ; Tue, 20 Sep 2011 01:10:44 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p8K1AZlP093932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Sep 2011 10:40:40 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <1DEF7FE4-F2EA-422F-A4E5-911226E96AEF@gmail.com> Date: Tue, 20 Sep 2011 10:40:35 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <69A71E62-DD35-40AD-8A3C-E9C90DF7CA25@gsoft.com.au> References: <201109200039.48139.ken@mthelicon.com> <1DEF7FE4-F2EA-422F-A4E5-911226E96AEF@gmail.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1244.3) X-Spam-Score: -4.391 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: Pegasus Mc Cleaft , freebsd-current@freebsd.org Subject: Re: USB Keyboard doesn't work 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, 20 Sep 2011 01:10:49 -0000 On 20/09/2011, at 10:05, Garrett Cooper wrote: > On Sep 19, 2011, at 4:39 PM, Pegasus Mc Cleaft wrote: >=20 >> On Monday 19 September 2011 20:20:18 Alisson wrote: >>=20 >>> if the machine doesn't have a PS2 port to use keyboard... and have = only USB >>> port its impossible to use an keyboard on mountroot prompt >>=20 >> Hi Alisson,=20 >>=20 >> I dont know the complete ins and outs of this, but I think it = has a lot=20 >> to do with the BIOS on your machine and/or how it is configured (IE: = PS2=20 >> emulation). >=20 > Many BIOS vendors label this as "legacy keyboard emulation", = etc. You might want to play with the plug-n-play settings as well (but I = doubt that that would help). I think you would need "legacy emulation" for the keyboard to work in = the loader. However that will have no effect at mountroot (and after) as the kernel = has taken over by then. The kern.cam.boot_delay=3D10000 work around helps by giving the USB = stack some time to find devices before mountroot. Unfortunately I believe the USB stack is effectively frozen once the = mountroot prompt appears hence the need for the work around. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 01:23:34 2011 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 124DB106564A for ; Tue, 20 Sep 2011 01:23:34 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by mx1.freebsd.org (Postfix) with ESMTP id B61118FC13 for ; Tue, 20 Sep 2011 01:23:33 +0000 (UTC) X-AuditID: 1209190e-b7c60ae000000a26-ef-4e77ea816451 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 77.9A.02598.18AE77E4; Mon, 19 Sep 2011 21:21:05 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p8K1NWga021211; Mon, 19 Sep 2011 21:23:32 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p8K1NTSh022845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Sep 2011 21:23:32 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p8K1NS9v011575; Mon, 19 Sep 2011 21:23:28 -0400 (EDT) Date: Mon, 19 Sep 2011 21:23:27 -0400 (EDT) From: Benjamin Kaduk To: Michal Varga In-Reply-To: <1316481004.1744.62.camel@xenon> Message-ID: References: <1316359940.1744.28.camel@xenon> <1316481004.1744.62.camel@xenon> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEIsWRmVeSWpSXmKPExsUixCmqrNv4qtzPYPlBbos5bz4wWXz8qmrR 8+8rswOzx4xP81k8ds66yx7AFMVlk5Kak1mWWqRvl8CV0X3+EXPBVbmKY5eOMjYwrpXoYuTk kBAwkdgxvZ0VwhaTuHBvPVsXIxeHkMA+RonmWXeZIJwNjBInG75BOQeYJBZM/w5V1sAosWdJ ExtIP4uAtsS/mX+YQGw2ARWJmW82gsVFBDQl5j/aDxZnFvCW2HCtmxnEFhawlPjXchDI5uDg FNCVOHpJGyTMK2AvsfL8F3aI+dcZJT5ffAU2R1RAR2L1/iksEEWCEidnPmGBmGkpce7PdbYJ jIKzkKRmIUktYGRaxSibklulm5uYmVOcmqxbnJyYl5dapGusl5tZopeaUrqJERy0knw7GL8e VDrEKMDBqMTDO3NhuZ8Qa2JZcWXuIUZJDiYlUV4pYMgL8SXlp1RmJBZnxBeV5qQWH2KU4GBW EuEt2AaU401JrKxKLcqHSUlzsCiJ867e4eAnJJCeWJKanZpakFoEk5Xh4FCS4F0CMlSwKDU9 tSItM6cEIc3EwQkynAdoeAdIDW9xQWJucWY6RP4Uo6KUOG8xSEIAJJFRmgfXC0sqrxjFgV4R 5p0AUsUDTEhw3a+ABjMBDS7zKAEZXJKIkJJqYDQ6/frXiY9iuft0jqnanjA4fsvi0VaRaWVJ Za6X93z76D7Tv3+x2csU4Yip8hk8vddMFwQaO86ICX36TdF8+9yPKn0pPHY95Uaq/19V+jul nee/4fE7/smSNZatjFVLGuf83343IHrhz2ib0uPqRYsdo7hehezvZy4RTtGuOSe2VT7y9t+a A0osxRmJhlrMRcWJAM9QiqkFAwAA Cc: freebsd-current@freebsd.org, Antonio Olivares Subject: Re: How does one install kernel sources and base 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, 20 Sep 2011 01:23:34 -0000 On Tue, 20 Sep 2011, Michal Varga wrote: > On Mon, 2011-09-19 at 19:22 -0500, Antonio Olivares wrote: >> Michal, >> >> Thank you very much for your detailed instruction. I was able to get >> all of the sources and built nvidia driver successfully :) >> >> However, when I run kldload nvidia, I get a mismatch with the running >> kernel and an incompatible ?????. I cannot post exact error as the >> machine gives me no X :(, I checked to see if enabling hald and dbus >> at /etc/rc.conf would make a difference and they have not :(, I have >> also tried nouveau and it also does not work. No working X on FreeBSD >> 9.0 BETA 2 amd64, ports updated to latest, xorg, xorg-server, xfce4, >> ... I will post in the thread I created on this issue. >> >> Regards, >> >> Antonio > > Some details about the "incompatible ?????" error would be quite useful > as without an actual (and exact) error message it's only guessing... > > But it is possible that your downloaded (latest -HEAD) sources are no > longer compatible with your currently running OS, though there being > like about a week difference, I find it somewhat unlikely (but always > possible). It is in fact quite likely, as a bunch of kernel functions corresponding to system calls have been renamed in the interim by kmacy, around r225617. I believe the quoted text below to be accurate, for the OPs choice of actions. -Ben Kaduk > > If that's the case, you have two possible routes to take: > > You can either bring your system up to date corresponding to the latest > sources; that is, rebuilding and installing new FreeBSD kernel and > world. That should get rid of any incompatibilities you currently > experience. It's a pretty straightforward process which in your case > amounts to just about - > > # cd /usr/src > # make buildworld installworld kernel > > - but note that the above mentioned IS NOT an officially supported > procedure and you are first REQUIRED to read FreeBSD Handbook and > understand the basics of building and updating FreeBSD. I just mention > it to illustrate how simple the procedure generally is. But again, don't > run it blindly. When unsure, always use the officially supported, while > somewhat lenghtier, procedure described in FreeBSD Handbook. > > Now the other possible route that doesn't involve building and updating > FreeBSD at all, is to download the sources that closely match your > currently running system. > > As far as I know (and I wasn't able to find), there is no CVS tag for > BETA2, so you can't pull the exact sources that way, but you should be > able to get very close with: > > $ uname -a > > - and notice when the kernel was built, which was hopefully very close > to the time when the sources were pulled from CVS (this is more or less > only a guess, so someone involved in release engineering might be of > more help with this issue, if there even is any). > > To do this, you just need to edit your supfile and include the specific > date from when to pull the sources: > > That is, replacing the line: > > *default release=cvs tag=. > > With: > > *default release=cvs tag=. date=2011.09.??.??.??.?? > > (Just fill in the missing dd, hh, mm, ss values based on the date you > already know from uname.) > > This modified supfile will let you pull sources that should be a very > close - if not perfect - match to your current system. You can then > rebuild your drivers (i.e. that non-working nvidia module) the regular > way. By my humble estimate, that should be enough to fix your issue. > > m. > > > -- > Michal Varga, > Stonehenge (Gmail account) > > > _______________________________________________ > 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 Sep 20 03:35:44 2011 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 2B62D1065672 for ; Tue, 20 Sep 2011 03:35:44 +0000 (UTC) (envelope-from eric@shadowsun.net) Received: from mail.atlantawebhost.com (dns1.atlantawebhost.com [66.223.40.39]) by mx1.freebsd.org (Postfix) with ESMTP id D19AA8FC1D for ; Tue, 20 Sep 2011 03:35:43 +0000 (UTC) Received: (qmail 29728 invoked from network); 19 Sep 2011 23:09:02 -0400 Received: from c-76-28-30-220.hsd1.ma.comcast.net (HELO ?172.16.0.8?) (76.28.30.220) by mail.atlantawebhost.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Sep 2011 23:09:02 -0400 Message-ID: <4E7803C3.4080406@shadowsun.net> Date: Mon, 19 Sep 2011 23:08:51 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110916 Thunderbird/6.0.2 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDFA09C09903177A023127134" Cc: Subject: ACPI battery problem and solution 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, 20 Sep 2011 03:35:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDFA09C09903177A023127134 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, I'm running 9.0-CURRENT on a MacbookPro 5,5. Following a recent update, I found that the acpi battery functionality had stopped working. I suspect, given the nature of it, that other people may have seen this problem as well. I did some work, and traced the problem to its source. The driver (in dev/acpica/acpi_cmbat.c) attempts to dispatch a call to acpi_cmbat_init_battery() via the AcpiOsExecute() mechanism. However, it seemed that the queue was filling up during kernel initialization, and the call was getting dropped on the floor. The cmbat driver reads part of the battery info (the bif structure) into its own structures at initialization, and then uses it, rather than querying the battery directly. Because AcpiOsExecute was dropping the initialization request on the floor, the bif information was left uninitialized, which caused the driver to mistakenly report the battery as not present when queried from sysctl/ioctl. I was able to workaround the problem by setting debug.acpi.max_tasks to a higher value, which restored functionality. Several possible solutions come to mind: 1) keep track of whether or not acpi_cmbat_init_battery (and possibly other initialization routines) have actually been successfully queued and run, to distinguish "genuine" failures, rather than failures resulting from a full queue 2) run acpi_cmbat_init_battery (and possibly other initialization routines) directly, rather than sending them through the queue. 3) something else But I'll leave the decision of what to do up to people with more knowledge of the acpi system. Hope this helps someone. --------------enigDFA09C09903177A023127134 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.18 (FreeBSD) iQIcBAEBAgAGBQJOeAPNAAoJENSCzbQ+koZ72OQQALD2EbbTkbHtcxkzsMHdNVxv /7SLVOzfPjgPgGbWCOz8Cjf0/81Q9bln7fYfnnKhdzf74DYHE384iKgObIgO4o0c Zc0UgbrEyeHetj1k6IJEI7AeY6BXZqeNVNPEeOBIfI4ngM/u/J11v+vvVoN1OPnH VEkfhQmyhODweWUjLIM033fhOhJQErTKSAKnfPzxZI8a4zDKfisRWckIF2vVROjW 3CSnno7yk9EeP4StL4DsdGyPRIRd8XAtVWvdAE8+zM93RqqQrePEYWUtNckIeHYL SsHTfhRNhfZsPhsAMN81GXW2WBH3gxy474shaognfvtUw2dyR9W0l25wcn+vKN3m OxUudUtL/vy37hLiuEEb8FADtpf8ytGQJpN6igYsKuGAhO/RmVnXF9rZ4DcIytAQ 91hbTCkvEEXvpTMhtfKmLeb/JUoMcXvKhOGaZeI4Tu6DfK/nwNYgKd5pOST1LKRA aApLvH2uz/CEd/bE5cYcEQZyx0lMWj4hT6bVL/AIWQmO47Yc1K0Lwo8ZWaXUUDR/ B6uRd834KIL6wBqXYsWhynUZTRzEO4XcBck56A7r8gj8IGEwzTSjTnq0XcULfzrs JT272NrU1Ip9QkQboPFA2VfqQdj4PYq7LSFu1hWAAGby8R3LPOfcoXfCwNwRSS27 KN5YRAs1VRI6W1l0Gd8y =jXcB -----END PGP SIGNATURE----- --------------enigDFA09C09903177A023127134-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 03:46:25 2011 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 6270B106564A for ; Tue, 20 Sep 2011 03:46:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0008D8FC17 for ; Tue, 20 Sep 2011 03:46:24 +0000 (UTC) Received: by vws5 with SMTP id 5so184645vws.17 for ; Mon, 19 Sep 2011 20:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5Wr2bEapRXkUAVSri7k0cpRmR24SkVgOpx0aSv9wI8A=; b=D10OG0O9z1MmmtDJeWQ2YmZhMcf14vrkpHoPz4/BDV4OqItNYaokxjYjGxZFZ7Akly l0NFsCa0yAJDf1kfKSiM3Pn0lx6jIV0tfKm0BUolBZ+eWYt3Pm5Kk6tgLzndDvgEIJE+ riHiALqpt/DmYhJfAsyC38O1gXkR7ATOCiRhI= MIME-Version: 1.0 Received: by 10.52.29.99 with SMTP id j3mr240325vdh.60.1316490384187; Mon, 19 Sep 2011 20:46:24 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.52.161.138 with HTTP; Mon, 19 Sep 2011 20:46:24 -0700 (PDT) In-Reply-To: <4E7803C3.4080406@shadowsun.net> References: <4E7803C3.4080406@shadowsun.net> Date: Tue, 20 Sep 2011 11:46:24 +0800 X-Google-Sender-Auth: MJPdA5utj-XF0LZ-YsllLggR-AE Message-ID: From: Adrian Chadd To: Eric McCorkle Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: ACPI battery problem and solution 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, 20 Sep 2011 03:46:25 -0000 Would you mind filing a PR? This kind of thing is important and best not to get lost. :) Adrian From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 04:45:43 2011 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 73374106566B for ; Tue, 20 Sep 2011 04:45:43 +0000 (UTC) (envelope-from eric@shadowsun.net) Received: from mail.atlantawebhost.com (dns1.atlantawebhost.com [66.223.40.39]) by mx1.freebsd.org (Postfix) with ESMTP id 0B6648FC13 for ; Tue, 20 Sep 2011 04:45:42 +0000 (UTC) Received: (qmail 4241 invoked from network); 20 Sep 2011 00:45:42 -0400 Received: from c-76-28-30-220.hsd1.ma.comcast.net (HELO ?172.16.0.8?) (76.28.30.220) by mail.atlantawebhost.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 20 Sep 2011 00:45:42 -0400 Message-ID: <4E781A6C.90509@shadowsun.net> Date: Tue, 20 Sep 2011 00:45:32 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110916 Thunderbird/6.0.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4E7803C3.4080406@shadowsun.net> In-Reply-To: X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig853D3268D24F754AA8D601BA" Subject: Re: ACPI battery problem and solution 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, 20 Sep 2011 04:45:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig853D3268D24F754AA8D601BA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/19/11 23:46, Adrian Chadd wrote: > Would you mind filing a PR? > > This kind of thing is important and best not to get lost. :) Done. Identifier is kern/160838. --------------enig853D3268D24F754AA8D601BA 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.18 (FreeBSD) iQIcBAEBAgAGBQJOeBp1AAoJENSCzbQ+koZ7TlEP/3q/3dsbCS9ybNKPp8k7E7FU 00kl9IpTNcxsWSWR8eD0jMhjKOUUElaUbB7N6iZRgEvu7js9BKxSGc6R9ym7EH+x XCZXVO5JtM0BHSpDAF8SQqYtRhSkpKa6K2YdjXGL5fPr7+it4CpDaEjiv99fIDmc R2Cq2gcrQt3MLYpyc4XAEq5ErNCKkmoTVox2mXcDvdln2jo06IaayS+2BM25SdxJ 4thHrSJEn+tRKyvzs76RSyAe2TojkN15k7BnXsedg2jPbuetnQ9RrcJE38aUJDDx VyDbivV680EzBrcatlVUOttX/L6R8ScjliYSJ9ftZ+IOdv3KYzwUNezK+2g+BaiU pCel/is/RoFTnks6yOG/V86Wo/B0Vo632sc7rjO02GtyvIgMoawZzLiqogetzP7H sNOVY2ylkWt+8Qn/ruZ++S7kmztOSzcYunF21H7KTeCEfwyXtoA0igATzSepTik4 CmEB/s2OexiD/SszkI2Lesmjafs0WUWdZaovOK7m0Xy325aPzKD8YdPOhUFPRRzp wHCrCaDFa4M0jGwD09/guLLhdVyg+in4EHaiQ4I9Ct0KBcTFXe4NWK9ZMgd/w27p BBH6EE8jjpReHOod1CBZ2eO5o+F7PiOQblWA1xDpZcLLINoiDWAFKqWKpUnwx8Cb kNjuQiX1MymmDup8htu2 =b9EQ -----END PGP SIGNATURE----- --------------enig853D3268D24F754AA8D601BA-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 06:16:03 2011 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 248E2106566B for ; Tue, 20 Sep 2011 06:16:03 +0000 (UTC) (envelope-from antxxxx@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id AF7E88FC17 for ; Tue, 20 Sep 2011 06:16:02 +0000 (UTC) Received: by wwe3 with SMTP id 3so213250wwe.31 for ; Mon, 19 Sep 2011 23:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=b9DkDZMC9tBUmR7rq0+mxh2IM8dhOFs/7Rx9Qa37Ci4=; b=IJU8r0Yrq/oHFrS30D+5q2s1B1iWns3Xi+NeB0GW7nd+P2qw5r1AcPPykfc3mBMliC JjBq6bhx2WBzDRC3CNdfq1LRGhHweUx66PCvF+XA2JoDHrSmHTVYfve1skMTOdFv9Uqh N811xhryfyRA3hqdUVWw2ti/nkS2LJTVg+9JE= MIME-Version: 1.0 Received: by 10.216.14.220 with SMTP id d70mr369456wed.75.1316497950816; Mon, 19 Sep 2011 22:52:30 -0700 (PDT) Sender: antxxxx@gmail.com Received: by 10.216.24.147 with HTTP; Mon, 19 Sep 2011 22:52:30 -0700 (PDT) In-Reply-To: References: <20110918042853.3D61C106566C@hub.freebsd.org> Date: Tue, 20 Sep 2011 06:52:30 +0100 X-Google-Sender-Auth: fqMGso8l33dQdxVd6O3yQF0894s Message-ID: From: Anthony Brown To: Antonio Olivares Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: no X after installing xorg + xfce 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, 20 Sep 2011 06:16:03 -0000 On Tue, Sep 20, 2011 at 1:31 AM, Antonio Olivares wrote: > I added =A0this to /etc/rc.conf > >>>> hald_enable=3D"YES" >>>> dbus_enable=3D"YES" > > but machine still gives no working X :( > >>> >>> =A0 =A0This seems like more of a question@ issue. >>> =A0 =A0I doubt that the above claim is at fault, given past experience. >>> What does /var/log/Xorg.0.log say, and what does your xorg.conf >>> contain? > I would like to return this, but have no way of saving output :( > > I have updated via ports to latest tree available and have used csup > to get kernel sources to install nvidia-driver, but kldload nvidia, > returns a mismatch another type of error, I recompiled xorg-server and > no hal was in configuration, but X does not work. > > with nv, nvidia(after compilation), and noveau no working X :( > > What can I do? =A0I have two machines with nvidia chipsets one > integrated in the motherboard and another nvidia Gforce card and amd64 > 8.2 works great. =A0This is an integrated motherboard. > > As I am not an expert, I ask for advice/suggestions/comments to get this = going. > The first thing to try is reading the handbook section on configuring X at http://www.freebsd.org/doc/handbook/x-config.html - specifically try running Xorg -configure as root to get a basic xorg.conf file that you can then tweak Once you have this working, you may like to try the binary nvidia driver available from http://www.nvidia.co.uk/Download/index.aspx?lang=3Den-uk which should provide the all the features of the graphics card Anthony From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 06:24:02 2011 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 29AE0106564A for ; Tue, 20 Sep 2011 06:24:02 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.freebsd.org (Postfix) with ESMTP id AE4CD8FC17 for ; Tue, 20 Sep 2011 06:24:01 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p8K6NobK012272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Sep 2011 16:23:52 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id p8K6Nonb084113; Tue, 20 Sep 2011 16:23:50 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id p8K6Nnk8084112; Tue, 20 Sep 2011 16:23:49 +1000 (EST) (envelope-from peter) Date: Tue, 20 Sep 2011 16:23:49 +1000 From: Peter Jeremy To: Bruce Cran Message-ID: <20110920062349.GA84006@server.vk2pj.dyndns.org> References: <20110918095526.D866D1065670@hub.freebsd.org> <4E7734B7.8030507@cran.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: <4E7734B7.8030507@cran.org.uk> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: 9.0 beta2 & the new bsdinstaller 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, 20 Sep 2011 06:24:02 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Sep-19 13:25:27 +0100, Bruce Cran wrote: >I seem to remember (perhaps incorrectly) there was a discussion about=20 >bumping the default to 128 kB or more for the freebsd-boot partition.=20 >Will 64 kB be enough for 9.x? At least for x86 architectures, it seems adequate. The GPT loaders are 13K (UFS) and 33K (ZFS). Even if they were combined with no code overlap, that's only 46KB. As for missing functionality, the only things I can think of would be: 1) multiboot support - which is implemented in <<512 bytes for MBR so it's difficult to see how it could require more than a few KB. 2) "nextboot" support for ZFS - writing to ZFS is not feasible in the bootloader so this implies some other alternative. 3) Potentially linked to the above - provision for booting off ZFS clones or snapshots. I'm not sure how much code the latter two features might require. As for size, I'd suggest that if the default freebsd-boot size is going to be changed, it should be adjusted so that the following partition is aligned to a reasonably sized power of 2 - 128KB or 256KB. --=20 Peter Jeremy --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk54MXUACgkQ/opHv/APuIfl0ACgnvMKF3vxt0iRKiC6fIvIiSxx UHsAoJgEKMX2/TbuZIgiFr+xxe+acu2A =2TSu -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 06:49:03 2011 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 2F6791065672; Tue, 20 Sep 2011 06:49:03 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 89E998FC08; Tue, 20 Sep 2011 06:49:02 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so224251bkb.13 for ; Mon, 19 Sep 2011 23:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IWA8n2fiTof049bjODx2+wRWm0r8/zHCPlIeYiqYofY=; b=SZEVEj4q2pEd72Rq6C4JN7wd9v583nLU2VvWI+eywf8Np3lrOAgOHklzYaGXG6ZZjP wU/spVGhi+Ysishig8KeJ8y7cY83KA/6A85pZ2h3IERlLoca05nOkz4+/SWFa4h+brT/ K4S7fyOxPAFIdOkW0GGH7EE6rtFmPEMGRPaZM= MIME-Version: 1.0 Received: by 10.204.154.136 with SMTP id o8mr232752bkw.355.1316501341537; Mon, 19 Sep 2011 23:49:01 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.204.140.24 with HTTP; Mon, 19 Sep 2011 23:49:01 -0700 (PDT) In-Reply-To: References: <4E5941D6.9090106@zedat.fu-berlin.de> <20110907133646.29b11668@desktop.pc> Date: Mon, 19 Sep 2011 23:49:01 -0700 X-Google-Sender-Auth: 50V-2v2l1yePEJltY7flZLvxqAc Message-ID: From: Craig Rodrigues To: Chris Brennan Content-Type: text/plain; charset=ISO-8859-1 Cc: Aldis Berjoza , freebsd-current@freebsd.org, "freebsd-performance@freebsd.org" Subject: Re: http://www.freebsd.org/marketing/os-comparison.html 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, 20 Sep 2011 06:49:03 -0000 Chris Brennan wrote: > Anything gonna be done with this? It has promise but needs some more people > involved. The original web page which started this thread was removed from the FreeBSD.org web site: http://lists.freebsd.org/pipermail/cvs-all/2011-September/345334.html For anyone who wants to help update the web site content, the best thing to do is to check out the FreeBSD web site from the "www" module in CVS (see http://www.freebsd.org/cgi/cvsweb.cgi/ ) and submit patches to freebsd-www@freebsd.org, or "www" category via send-pr. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 07:43:23 2011 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 34FB7106566B for ; Tue, 20 Sep 2011 07:43:23 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id B56008FC20 for ; Tue, 20 Sep 2011 07:43:22 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=yVKV3zusvCapyMfYJBNW2j35FMEuTKq6vh/tt/1L5+g= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=2qdppO70Lh8A:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8NdF9qhyBsQsG5498okA:9 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 13795348; Tue, 20 Sep 2011 09:43:19 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 20 Sep 2011 09:40:28 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <1DEF7FE4-F2EA-422F-A4E5-911226E96AEF@gmail.com> <69A71E62-DD35-40AD-8A3C-E9C90DF7CA25@gsoft.com.au> In-Reply-To: <69A71E62-DD35-40AD-8A3C-E9C90DF7CA25@gsoft.com.au> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109200940.29013.hselasky@c2i.net> Cc: Garrett Cooper , Pegasus Mc Cleaft Subject: Re: USB Keyboard doesn't work 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, 20 Sep 2011 07:43:23 -0000 On Tuesday 20 September 2011 03:10:35 Daniel O'Connor wrote: > Unfortunately I believe the USB stack is effectively frozen once the > mountroot prompt appears hence the need for the work around. Hi, It is not frozen. The problem is that the thread polling for key-presses runs at higher priority than the USB threads. And it doesn't call pause() at any time. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 08:36:54 2011 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 7D888106564A for ; Tue, 20 Sep 2011 08:36:54 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 409758FC14 for ; Tue, 20 Sep 2011 08:36:53 +0000 (UTC) Received: by yxk36 with SMTP id 36so199358yxk.13 for ; Tue, 20 Sep 2011 01:36:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dz6R75l0pNK23YZB7mUNDU8KtWg8eULZ2VcKhkEWR50=; b=iNdzwINPDfx4tMh/x6bt67yU4P+s03VY22YOATdfrfxsG7iYdhNhAk7w5B5S+8CVds V03OHI9AiXvSLiUlP0bmer4zFeqX2qFi8jUdhSVjzECqBkAbPNlEj9a48N1Z3JKt7wOE 7nPjyOxAQx0KshTlFwqUu6DMNdYOspzcz2NYU= MIME-Version: 1.0 Received: by 10.151.108.10 with SMTP id k10mr396787ybm.212.1316507813478; Tue, 20 Sep 2011 01:36:53 -0700 (PDT) Received: by 10.150.53.2 with HTTP; Tue, 20 Sep 2011 01:36:53 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 Sep 2011 12:36:53 +0400 Message-ID: From: Sergey Kandaurov To: Anton Yuzhaninov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Dtrace: type mismatch in sys/kern/kern_sig.c 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, 20 Sep 2011 08:36:54 -0000 On 19 September 2011 19:24, Anton Yuzhaninov wrote: > In the file sys/kern/kern_sig.c defined DTrace probe proc:::signal-discard > > SDT_PROBE_DEFINE(proc, kernel, , signal_discard, signal-discard); > SDT_PROBE_ARGTYPE(proc, kernel, , signal_discard, 0, "struct thread *"); > SDT_PROBE_ARGTYPE(proc, kernel, , signal_discard, 1, "struct proc *"); > SDT_PROBE_ARGTYPE(proc, kernel, , signal_discard, 2, "int"); > > Then latter this proble called as: > > SDT_PROBE(proc, kernel, , signal_discard, ps, td, sig, 0, 0 ); > > type for var ps is struct sigacts* =! struct thread * (bug?) > type for var td is struct thread * =! struct proc * (bug?) > type for var sig is int == int (ok) > > To match solaris DTrace probe shuild called as: > > SDT_PROBE(proc, kernel, , signal_discard, td, p, sig, 0, 0 ); > Yes, seems a typo there. Also conforms to the Solaris Dynamic Tracing Guide: http://download.oracle.com/docs/cd/E19082-01/819-3620/gelse/index.html (Also, td and p are somewhat different wrt. psinfo_t and lwpsinfo_t in Solaris). -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 09:25:47 2011 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 9FB4F106566B for ; Tue, 20 Sep 2011 09:25:47 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost06.isp.att.net (fmailhost06.isp.att.net [204.127.217.106]) by mx1.freebsd.org (Postfix) with ESMTP id 8DBDB8FC13 for ; Tue, 20 Sep 2011 09:25:47 +0000 (UTC) Date: Tue, 20 Sep 2011 09:25:45 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-72-147-183-55.sdf.bellsouth.net[72.147.183.55]) by isp.att.net (frfwmhc06) with SMTP id <20110920092545H0600a74oke>; Tue, 20 Sep 2011 09:25:45 +0000 X-Originating-IP: [72.147.183.55] From: "Thomas Mueller" To: freebsd-current@freebsd.org References: <20110920062349.GA84006@server.vk2pj.dyndns.org> Message-Id: <20110920092547.9FB4F106566B@hub.freebsd.org> Subject: Re: 9.0 beta2 & the new bsdinstaller 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, 20 Sep 2011 09:25:47 -0000 ><"Thomas Mueller There was a typo on my part that I failed to correct, missing > at the end of From: "Thomas Mueller" and others on the boot partition: So the 64 KB boot partition, nonbootable on my computer, is for legacy BIOS and no good on UEFI? But I was able to boot the installation memstick for BETA1 and BETA2. If the 64 KB boot partition is nonfunctional for me, I'd like it to be optional. Or maybe the installation would go through even without the boot partition? I notice there is no /usr/mdec directory in FreeBSD 9.0-to-be as there was in FreeBSD 8.2 and still is in NetBSD. Another question on the same general topic, the new bsdinstaller: Is the home directory supposed to be /home or /usr/home? I wanted /home, but the installer made /home into a symbolic link to /usr/home, I corrected this successfully, but later saw, regarding PC-BSD 9.0-BETA2: (quoting) Auto correct if user tries to use /home to /usr/home (end of quote) I think I did rm /home mv /usr/home / Tom From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 11:41:07 2011 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 AD686106566C for ; Tue, 20 Sep 2011 11:41:07 +0000 (UTC) (envelope-from olivares14031@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 778E78FC18 for ; Tue, 20 Sep 2011 11:41:07 +0000 (UTC) Received: by iadk27 with SMTP id k27so815750iad.13 for ; Tue, 20 Sep 2011 04:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+yZuaAgnEPJeLlToWHJpD+KVFRZeETVnLjCTevIrvAc=; b=EWGhfekw3D/rAHa6jD025YcnOvjdJxwKWHp3/MY6PRDzqyltthPbnVfALbpsve19us NGYD7j6SIWqCT6QMhWsOeaCRn8l6vsUpTvbiyzEaoPyFIN4DmtVnjSGNw1Nf3jx3HKQ4 YGGVybmzRtMVifLg4hdaglGhkUtgPzT0H3bJE= MIME-Version: 1.0 Received: by 10.42.159.130 with SMTP id l2mr1314658icx.203.1316518866369; Tue, 20 Sep 2011 04:41:06 -0700 (PDT) Received: by 10.42.177.199 with HTTP; Tue, 20 Sep 2011 04:41:06 -0700 (PDT) In-Reply-To: References: <20110918042853.3D61C106566C@hub.freebsd.org> Date: Tue, 20 Sep 2011 06:41:06 -0500 Message-ID: From: Antonio Olivares To: Anthony Brown Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: no X after installing xorg + xfce 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, 20 Sep 2011 11:41:07 -0000 > The first thing to try is reading the handbook section on configuring > X at http://www.freebsd.org/doc/handbook/x-config.html - specifically > try running > > Xorg -configure > > as root to get a basic xorg.conf file that you can then tweak > > Once you have this working, you may like to try the binary nvidia > driver available from > http://www.nvidia.co.uk/Download/index.aspx?lang=en-uk which should > provide the all the features of the graphics card > > Anthony > Been there! Done that! Makes no difference. X hangs and returns screen with many lines in colors but X does not work correctly. So thanks for advice, but no that does not help. Maybe what do I have to lose, I should try to rebuild system or reinstall to see if it makes a difference? Regards, Antonio From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 11:55:18 2011 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 E78BD106566C for ; Tue, 20 Sep 2011 11:55:17 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9B1CD8FC1A for ; Tue, 20 Sep 2011 11:55:17 +0000 (UTC) Received: by vws11 with SMTP id 11so777001vws.13 for ; Tue, 20 Sep 2011 04:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8WedAOb2LHR7UrVF/OOiKH6gAXom5MktjWmKmaLVk5k=; b=qpnG7zTQ19T1eXIzV8UOxNrQT24yOV6LzHEUtDzGcKH5NCHV/MqWl5MxDg4Jx6L9UT IdAS1CJokXsewlJDVeT8Xpqw8oilgjgLVSPogXAHJVL6E1sc300O4bXZfx0zObkNi7q+ 4htrTA4E2GwWde4cS+/43OYVi1U27dzeVH66Y= MIME-Version: 1.0 Received: by 10.52.33.228 with SMTP id u4mr552920vdi.141.1316519716921; Tue, 20 Sep 2011 04:55:16 -0700 (PDT) Received: by 10.52.169.98 with HTTP; Tue, 20 Sep 2011 04:55:16 -0700 (PDT) In-Reply-To: References: <20110918042853.3D61C106566C@hub.freebsd.org> Date: Tue, 20 Sep 2011 12:55:16 +0100 Message-ID: From: Tom Evans To: Antonio Olivares Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: no X after installing xorg + xfce 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, 20 Sep 2011 11:55:19 -0000 On Tue, Sep 20, 2011 at 12:41 PM, Antonio Olivares wrote: >> The first thing to try is reading the handbook section on configuring >> X at http://www.freebsd.org/doc/handbook/x-config.html - specifically >> try running >> >> Xorg -configure >> >> as root to get a basic xorg.conf file that you can then tweak >> >> Once you have this working, you may like to try the binary nvidia >> driver available from >> http://www.nvidia.co.uk/Download/index.aspx?lang=3Den-uk which should >> provide the all the features of the graphics card >> >> Anthony >> > > Been there! =C2=A0Done that! =C2=A0 Makes no difference. =C2=A0X hangs an= d returns > screen with many lines in colors but X does not work correctly. =C2=A0So > thanks for advice, but no that does not help. =C2=A0Maybe what do I have = to > lose, I should try to rebuild system or reinstall to see if it makes a > difference? > > Regards, > > Antonio 'Does not work correctly' covers everything from the background the wrong colour to the mouse being inverted and everything inbetween. I've skimmed the thread, (apologies if I've missed it), but I haven't yet seen your Xorg log or your config file. Almost every graphics card should work with VESA at a minimum. With an ancient graphics 'card' like a 6050, x11/nvidia-driver is the wrong driver, you want x11/nvidia-driver-173. However, the 173 series drivers do not support amd64 IIRC. With logs someone may be able to help you, without logs its just shouting out ideas why your X11 installation isn't working. Cheers Tom From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 12:01:16 2011 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 436061065670 for ; Tue, 20 Sep 2011 12:01:16 +0000 (UTC) (envelope-from olivares14031@gmail.com) Received: from mail-gw0-f45.google.com (mail-gw0-f45.google.com [74.125.83.45]) by mx1.freebsd.org (Postfix) with ESMTP id F3EB58FC0C for ; Tue, 20 Sep 2011 12:01:15 +0000 (UTC) Received: by gwb19 with SMTP id 19so441805gwb.18 for ; Tue, 20 Sep 2011 05:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=33Y3tseK0GCobjL9llWUYjQ8U8BBqNpxAI0PTxqigKU=; b=dq+wYwahNRM9a2PCY3luMrJeuPTGenrxhGnCqgGv38oavfHJbV+8LYKKou6QRVgPJs EIPqdPXrehoIXDi/XMKfMseEDJprvdYsmXkHGYuRD8WjS/qLvpSXoP5cUvu385QHxUtx BODuIHOWcZ4PkDSLgGvnRHVhXbuQ2VnZ7QUIM= MIME-Version: 1.0 Received: by 10.42.159.3 with SMTP id j3mr1288960icx.210.1316520075125; Tue, 20 Sep 2011 05:01:15 -0700 (PDT) Received: by 10.42.177.199 with HTTP; Tue, 20 Sep 2011 05:01:15 -0700 (PDT) In-Reply-To: References: <20110918042853.3D61C106566C@hub.freebsd.org> Date: Tue, 20 Sep 2011 07:01:15 -0500 Message-ID: From: Antonio Olivares To: Tom Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: no X after installing xorg + xfce 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, 20 Sep 2011 12:01:16 -0000 On Tue, Sep 20, 2011 at 6:55 AM, Tom Evans wrote= : > On Tue, Sep 20, 2011 at 12:41 PM, Antonio Olivares > wrote: >>> The first thing to try is reading the handbook section on configuring >>> X at http://www.freebsd.org/doc/handbook/x-config.html - specifically >>> try running >>> >>> Xorg -configure >>> >>> as root to get a basic xorg.conf file that you can then tweak >>> >>> Once you have this working, you may like to try the binary nvidia >>> driver available from >>> http://www.nvidia.co.uk/Download/index.aspx?lang=3Den-uk which should >>> provide the all the features of the graphics card >>> >>> Anthony >>> >> >> Been there! =A0Done that! =A0 Makes no difference. =A0X hangs and return= s >> screen with many lines in colors but X does not work correctly. =A0So >> thanks for advice, but no that does not help. =A0Maybe what do I have to >> lose, I should try to rebuild system or reinstall to see if it makes a >> difference? >> >> Regards, >> >> Antonio > > 'Does not work correctly' covers everything from the background the > wrong colour to the mouse being inverted and everything inbetween. > > I've skimmed the thread, (apologies if I've missed it), but I haven't > yet seen your Xorg log or your config file. Almost every graphics card > should work with VESA at a minimum. I have no Xorg.conf file as it is not needed anymore. I tried to rebuild i= t, # Xorg -configure process hangs and returns colors on the screen :( > > With an ancient graphics 'card' like a 6050, x11/nvidia-driver is the > wrong driver, you want x11/nvidia-driver-173. However, the 173 series > drivers do not support amd64 IIRC. > > With logs someone may be able to help you, without logs its just > shouting out ideas why your X11 installation isn't working. > > Cheers > > Tom > I can't attach Xorg.0.log, I know which driver to use, as I have X working correctly with Linux(Slackware) on that same machine[another hard drive]. It is just that I have no way of saving logs or posting information without taking a picture, I would to put all doubts away. As of know I will rebuild world, install new kernel remove all ports and start from scratch. If I can't get it to work with a fresh start. I will wait for BETA 3 or an RC :) I just want to help in testing, it is that I can't supply the information as I would like to :( But I will keep many posted on this. Regards, Antonio From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 12:29:44 2011 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 A61F0106566B for ; Tue, 20 Sep 2011 12:29:44 +0000 (UTC) (envelope-from varga.michal@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 30DB78FC14 for ; Tue, 20 Sep 2011 12:29:43 +0000 (UTC) Received: by wyh15 with SMTP id 15so606790wyh.13 for ; Tue, 20 Sep 2011 05:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:organization :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=yca+/v3Ei3Miu8011zcW7kPo5u3zv0zjDsrNMPzEXgQ=; b=C8lbzh/jm9LVqYDFMgr8xsabmUvBYEbdfpOB5tb74Rxni/r8YhH2dwRQdNVqWpLadJ n+n5XziC996BvefskgBXmTpi7bp+YCIudXbZ4bw+3afBbxNj37ISQPm+3JMsUdko8ud2 WQt9dvsdhIDVEbiNslJ4fPv/wyI0OfUFipwL0= Received: by 10.227.3.2 with SMTP id 2mr4353249wbl.4.1316521782988; Tue, 20 Sep 2011 05:29:42 -0700 (PDT) Received: from [10.0.101.2] (254.166.broadband10.iol.cz. [90.177.166.254]) by mx.google.com with ESMTPS id z9sm2066460wbn.19.2011.09.20.05.29.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 05:29:41 -0700 (PDT) From: Michal Varga To: Antonio Olivares In-Reply-To: References: <20110918042853.3D61C106566C@hub.freebsd.org> Content-Type: text/plain; charset="UTF-8" Organization: Stonehenge Date: Tue, 20 Sep 2011 14:29:38 +0200 Message-ID: <1316521778.1744.92.camel@xenon> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tom Evans , freebsd-current@freebsd.org Subject: Re: no X after installing xorg + xfce 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, 20 Sep 2011 12:29:44 -0000 On Tue, 2011-09-20 at 07:01 -0500, Antonio Olivares wrote: > > I've skimmed the thread, (apologies if I've missed it), but I haven't > > yet seen your Xorg log or your config file. Almost every graphics card > > should work with VESA at a minimum. > > I have no Xorg.conf file as it is not needed anymore. I tried to rebuild it, > # Xorg -configure xorg.conf isn't "needed" in case you wish to rely purely on xorg's and HAL's autodetection (this is a perfectly bad idea), and if you do not need to change any single xorg option from defaults (this would be very strange in my book). There are tons of manuals on the Internet detailing how to write a proper xorg configuration file (it even has its own man page - man xorg.conf) and as with any properly configured software - it pays off. > process hangs and returns colors on the screen :( Autodetection blows. You will have to write your configuration manually. > I can't attach Xorg.0.log, I know which driver to use, as I have X > working correctly with Linux(Slackware) on that same machine[another > hard drive]. It is just that I have no way of saving logs or posting > information without taking a picture, I would to put all doubts away. Honestly, I really don't understand the "I can't attach Xorg.log" wording. It's a physical log file, just a regular file. How is it that you cannot copy it from the particular machine/hard drive/filesystem and put it someplace on the Internet, or paste the relevant parts inline in one of the emails? > As of know I will rebuild world, install new kernel remove all ports > and start from scratch. If I can't get it to work with a fresh start. There's really nothing wrong with your ports and you'll be only wasting your time with this generic and pointless "Windows-style reinstall everything" procedure, without actually looking at the issue itself. The other poster(s) already told you. If you need any help, you will have to provide error messages, you will have to provide error logs (and you will have to properly configure your xorg, because as you already noticed, autodetection clearly doesn't work the way you expect it to). > I will wait for BETA 3 or an RC :) I just want to help in testing, > it is that I can't supply the information as I would like to :( I can 100% guarantee that BETA3 nor RC won't change anything in regard to the issue you're experiencing. Your problem lies elsewhere and you didn't even start systematically investigating it. m. -- Michal Varga, Stonehenge (Gmail account) From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 13:20:02 2011 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 52B5F106564A for ; Tue, 20 Sep 2011 13:20:02 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id D13FA8FC0A for ; Tue, 20 Sep 2011 13:20:01 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R60Ex-00058e-1K for freebsd-current@freebsd.org; Tue, 20 Sep 2011 15:19:59 +0200 Received: from 178.214.36.169 ([178.214.36.169]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Sep 2011 15:19:59 +0200 Received: from citrin by 178.214.36.169 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Sep 2011 15:19:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Anton Yuzhaninov Date: Tue, 20 Sep 2011 13:19:45 +0000 (UTC) Organization: Vega Lines: 46 Sender: Anton Yuzhaninov Message-ID: References: <4E5E46A4.3060705@citrin.ru> <4E6A99A9.1000204@delphij.net> <864o0adkva.fsf@kopusha.home.net> <86mxe0r8o5.fsf@in138.ua3> <20110919212722.GQ1511@deviant.kiev.zoral.com.ua> X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 178.214.36.169 X-Comment-To: Kostik Belousov User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/9.0-BETA2 (i386)) Subject: Re: truss 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, 20 Sep 2011 13:20:02 -0000 On Tue, 20 Sep 2011 00:27:22 +0300, Kostik Belousov wrote: >> With this patch truss works for me: >> >> --- usr.bin/truss/main.c (revision 225504) >> +++ usr.bin/truss/main.c (working copy) >> @@ -255,6 +255,11 @@ main(int ac, char **av) >> >> if (trussinfo->pid == 0) { /* Start a command ourselves */ >> command = av; >> + /* >> + * SIGTRUP used to stop traced process after execve >> + * un-ignore this signal (it can be ignored by parents) >> + */ >> + signal(SIGTRAP, SIG_DFL); >> trussinfo->pid = setup_and_wait(command); >> signal(SIGINT, SIG_IGN); >> signal(SIGTERM, SIG_IGN); KB> This is quite a hack. The proper fix should go in kernel, otherwise KB> we cannot debug programs that decided to ignore SIGTRAP. The reason It seems to be, that in gdb used similar hack: citrin:~> procstat -i 2433 | fgrep TRAP 2433 dd TRAP -I- :~> gdb /bin/dd 2433 ... (gdb) next Single stepping until exit from function write, which has no line number information. dd_out (force=1) at dd.c:458 458 if (nw <= 0) { (gdb) ... :~> procstat -i 2433 | fgrep TRAP 2433 dd TRAP --- KB> Could you, please, test the change below ? For me, I still can truss(1) KB> or debug with gdb after the change applied. Does truss work for you KB> with only this change, without resetting SIGTRAP handler in truss process ? I'll test this patch. -- Anton Yuzhaninov From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 14:49:31 2011 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 81FC9106564A for ; Tue, 20 Sep 2011 14:49:31 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 3DD848FC08 for ; Tue, 20 Sep 2011 14:49:31 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Tue, 20 Sep 2011 10:38:41 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id DFFF133C02; Tue, 20 Sep 2011 10:38:41 -0400 (EDT) Date: Tue, 20 Sep 2011 10:38:41 -0400 From: Ed Maste To: Message-ID: <20110920143841.GA67532@sandvine.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Request for testing - mfiutil(8) patch 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, 20 Sep 2011 14:49:31 -0000 Mfiutil(8) is a commandline management tool for RAID controllers supported by the mfi(4) driver. I have a couple of changes to the way battery back up unit (BBU) state is reported and I would like to request testing from any mfi(4) users who are able to try my patch. If you're able to test it for me please grab the modified source tarball from http://people.freebsd.org/~emaste/mfiutil.tar and build the patched mfiutil. Then send me the output of "mfiutil show battery" for both the stock and patched mfiutil, as well as the controller model number and the type of back up unit (none, battery, or supercap). (If you're running CURRENT already and want just the patch, it is at http://people.freebsd.org/~emaste/patches/mfi_show.c.diff .) Thanks Ed From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 16:08:15 2011 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 91F82106566C for ; Tue, 20 Sep 2011 16:08:15 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 3FD598FC08 for ; Tue, 20 Sep 2011 16:08:14 +0000 (UTC) Received: by qyk10 with SMTP id 10so3908241qyk.13 for ; Tue, 20 Sep 2011 09:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tcK24gUNDvdOplGmnchaWbMwNwuAP6UIRE7HG+9G9po=; b=FnIv7Ca4EjqBHb/pXsWU91RUl11lILXxNn6iXMISIAmYfvOE3ZrsuWeV5lusiYPglp jdRX0jV7jkAYhR9AEHu22e00eqTmyR5pkpcxFCAJ6wyuwCjgWEVk76szAnK40CjASG/K /5SaEn1xyOedt/gjCaUuMdzZq8ptTwiBuQdoc= MIME-Version: 1.0 Received: by 10.224.215.133 with SMTP id he5mr832309qab.224.1316534894331; Tue, 20 Sep 2011 09:08:14 -0700 (PDT) Received: by 10.224.74.82 with HTTP; Tue, 20 Sep 2011 09:08:13 -0700 (PDT) In-Reply-To: <1316521778.1744.92.camel@xenon> References: <20110918042853.3D61C106566C@hub.freebsd.org> <1316521778.1744.92.camel@xenon> Date: Tue, 20 Sep 2011 09:08:13 -0700 Message-ID: From: Garrett Cooper To: Michal Varga Content-Type: multipart/mixed; boundary=20cf300514b0b6081c04ad61aafa Cc: Tom Evans , freebsd-current@freebsd.org, Antonio Olivares Subject: Re: no X after installing xorg + xfce 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, 20 Sep 2011 16:08:15 -0000 --20cf300514b0b6081c04ad61aafa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Sep 20, 2011 at 5:29 AM, Michal Varga wrot= e: > On Tue, 2011-09-20 at 07:01 -0500, Antonio Olivares wrote: >> > I've skimmed the thread, (apologies if I've missed it), but I haven't >> > yet seen your Xorg log or your config file. Almost every graphics card >> > should work with VESA at a minimum. >> >> I have no Xorg.conf file as it is not needed anymore. =A0I tried to rebu= ild it, >> # Xorg -configure > > xorg.conf isn't "needed" in case you wish to rely purely on xorg's and > HAL's autodetection (this is a perfectly bad idea), and if you do not > need to change any single xorg option from defaults (this would be very > strange in my book). > > There are tons of manuals on the Internet detailing how to write a > proper xorg configuration file (it even has its own man page - man > xorg.conf) and as with any properly configured software - it pays off. > > >> process hangs and returns colors on the screen :( > > Autodetection blows. You will have to write your configuration manually. > > >> I can't attach Xorg.0.log, I know which driver to use, as I have X >> working correctly with Linux(Slackware) on that same machine[another >> hard drive]. =A0It is just that I have no way of saving logs or posting >> information without taking a picture, I would to put all doubts away. > > Honestly, I really don't understand the "I can't attach Xorg.log" > wording. > > It's a physical log file, just a regular file. How is it that you cannot > copy it from the particular machine/hard drive/filesystem and put it > someplace on the Internet, or paste the relevant parts inline in one of > the emails? > > >> As of know I will rebuild world, install new kernel remove all ports >> and start from scratch. =A0If I can't get it to work with a fresh start. > > There's really nothing wrong with your ports and you'll be only wasting > your time with this generic and pointless "Windows-style reinstall > everything" procedure, without actually looking at the issue itself. > > The other poster(s) already told you. If you need any help, you will > have to provide error messages, you will have to provide error logs (and > you will have to properly configure your xorg, because as you already > noticed, autodetection clearly doesn't work the way you expect it to). > > >> =A0I will wait for BETA 3 or an RC :) =A0I just want to help in testing, >> it is that I can't supply the information as I would like to :( > > I can 100% guarantee that BETA3 nor RC won't change anything in regard > to the issue you're experiencing. Your problem lies elsewhere and you > didn't even start systematically investigating it. Newb hacker tip number one: try CTRL-ALT-F1 when you get the technicolor screen. If your system isn't hosed then you'll get the first tty. The only time I can think of where /var/log/Xorg.0.log wouldn't be populated with something useful is if the kernel module livelocks talking to the card and/or fsck takes out the file on the next reboot because it was in use. And yes Michal is right, IIRC. 64-bit drivers didn't exist on that vers= ion. Just try this file and get back to us please with something more useful than "it doesn't work". Otherwise we can't help you . -Garrett --20cf300514b0b6081c04ad61aafa Content-Type: application/octet-stream; name="xorg.conf" Content-Disposition: attachment; filename="xorg.conf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gst2tuvo0 U2VjdGlvbiAiU2VydmVyTGF5b3V0IgogICAgSWRlbnRpZmllciAgICAgIkxheW91dDAiCiAgICBT Y3JlZW4gICAgICAwICAiU2NyZWVuMCIgMCAwCiAgICBJbnB1dERldmljZSAgICAiTW91c2UwIiAi Q29yZVBvaW50ZXIiCiAgICBJbnB1dERldmljZSAgICAiS2V5Ym9hcmQwIiAiQ29yZUtleWJvYXJk IgojICAgIE9wdGlvbiAgICAgICAgICJYaW5lcmFtYSIgIjAiCkVuZFNlY3Rpb24KClNlY3Rpb24g IkZpbGVzIgogICAgTW9kdWxlUGF0aCAgICAgICIvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMi CiAgICBGb250UGF0aCAgICAgICAgIi91c3IvbG9jYWwvbGliL1gxMS9mb250cy9taXNjLyIKICAg IEZvbnRQYXRoICAgICAgICAiL3Vzci9sb2NhbC9saWIvWDExL2ZvbnRzL1RURi8iCiAgICBGb250 UGF0aCAgICAgICAgIi91c3IvbG9jYWwvbGliL1gxMS9mb250cy9PVEYiCiAgICBGb250UGF0aCAg ICAgICAgIi91c3IvbG9jYWwvbGliL1gxMS9mb250cy9UeXBlMS8iCiAgICBGb250UGF0aCAgICAg ICAgIi91c3IvbG9jYWwvbGliL1gxMS9mb250cy8xMDBkcGkvIgogICAgRm9udFBhdGggICAgICAg ICIvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvNzVkcGkvIgpFbmRTZWN0aW9uCgpTZWN0aW9uICJN b2R1bGUiCiAgICBMb2FkICAgICAgICAgICAiZXh0bW9kIgogICAgTG9hZCAgICAgICAgICAgImRi ZSIKIyAgICBMb2FkICAgICAgICAgICAiZ2x4IgogICAgTG9hZCAgICAgICAgICAgImRyaSIKICAg IExvYWQgICAgICAgICAgICJkcmkyIgpFbmRTZWN0aW9uCgpTZWN0aW9uICJJbnB1dERldmljZSIK ICAgIElkZW50aWZpZXIgICAgICJLZXlib2FyZDAiCiAgICBEcml2ZXIgICAgICAgICAia2JkIgpF bmRTZWN0aW9uCgpTZWN0aW9uICJJbnB1dERldmljZSIKICAgIElkZW50aWZpZXIgICAgICJNb3Vz ZTAiCiAgICBEcml2ZXIgICAgICAgICAibW91c2UiCiAgICBPcHRpb24gICAgICAgICAiUHJvdG9j b2wiICJhdXRvIgogICAgT3B0aW9uICAgICAgICAgIkRldmljZSIgIi9kZXYvc3lzbW91c2UiCkVu ZFNlY3Rpb24KClNlY3Rpb24gIk1vbml0b3IiCiAgICBJZGVudGlmaWVyICAgICAiTW9uaXRvcjAi CiAgICBWZW5kb3JOYW1lICAgICAiTXlWZW5kb3IiCiAgICBNb2RlbE5hbWUgICAgICAiTXlNb25p dG9yIgpFbmRTZWN0aW9uCgpTZWN0aW9uICJEZXZpY2UiCgogICAgSWRlbnRpZmllciAgICAgIkNh cmQwIgogICAgRHJpdmVyICAgICAgICAgInZlc2EiCiAgICBWZW5kb3JOYW1lICAgICAiTXlWZW5k b3IiCiAgICBCb2FyZE5hbWUgICAgICAiTXlDYXJkIgpFbmRTZWN0aW9uCgpTZWN0aW9uICJTY3Jl ZW4iCiAgICBJZGVudGlmaWVyICAgICAiU2NyZWVuMCIKICAgIERldmljZSAgICAgICAgICJEZXZp Y2UwIgogICAgTW9uaXRvciAgICAgICAgIk1vbml0b3IwIgogICAgRGVmYXVsdERlcHRoICAgIDI0 CiAgICBTdWJTZWN0aW9uICAgICAiRGlzcGxheSIKICAgICAgICBEZXB0aCAgICAgICAyNAogICAg RW5kU3ViU2VjdGlvbgpFbmRTZWN0aW9uCgo= --20cf300514b0b6081c04ad61aafa-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 17:02:17 2011 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 8C782106566C for ; Tue, 20 Sep 2011 17:02:17 +0000 (UTC) (envelope-from olivares14031@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4400D8FC12 for ; Tue, 20 Sep 2011 17:02:17 +0000 (UTC) Received: by ywp17 with SMTP id 17so649298ywp.13 for ; Tue, 20 Sep 2011 10:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=sGK4RshpISx8XN6xGQ6ERCBjj4rxeTfMloYQhgHxmWM=; b=HiB5D53lhNk9XMyTVYFZaWCIYBZ1ZHsCHLJ0kP7BdIntVJr1xIGDfdwTpT2spVpxY7 JYtqPIfthAOSkIB6KUiSvDx7sPs29Lov95RA2b0fHrtqnjq9yQsBB35nK7H1N8bVOp9T 07PEj1AoOfi8Ka1SYpxFN0DeZbYdmnj0rJtp8= MIME-Version: 1.0 Received: by 10.42.158.72 with SMTP id g8mr1889825icx.145.1316538136493; Tue, 20 Sep 2011 10:02:16 -0700 (PDT) Received: by 10.42.177.199 with HTTP; Tue, 20 Sep 2011 10:02:16 -0700 (PDT) In-Reply-To: References: <20110918042853.3D61C106566C@hub.freebsd.org> <1316521778.1744.92.camel@xenon> Date: Tue, 20 Sep 2011 12:02:16 -0500 Message-ID: From: Antonio Olivares To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Tom Evans , freebsd-current@freebsd.org, Michal Varga Subject: Re: no X after installing xorg + xfce 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, 20 Sep 2011 17:02:17 -0000 On Tue, Sep 20, 2011 at 11:08 AM, Garrett Cooper wrote= : > On Tue, Sep 20, 2011 at 5:29 AM, Michal Varga wr= ote: >> On Tue, 2011-09-20 at 07:01 -0500, Antonio Olivares wrote: >>> > I've skimmed the thread, (apologies if I've missed it), but I haven't >>> > yet seen your Xorg log or your config file. Almost every graphics car= d >>> > should work with VESA at a minimum. >>> >>> I have no Xorg.conf file as it is not needed anymore. =A0I tried to reb= uild it, >>> # Xorg -configure >> >> xorg.conf isn't "needed" in case you wish to rely purely on xorg's and >> HAL's autodetection (this is a perfectly bad idea), and if you do not >> need to change any single xorg option from defaults (this would be very >> strange in my book). >> >> There are tons of manuals on the Internet detailing how to write a >> proper xorg configuration file (it even has its own man page - man >> xorg.conf) and as with any properly configured software - it pays off. >> >> >>> process hangs and returns colors on the screen :( >> >> Autodetection blows. You will have to write your configuration manually. >> >> >>> I can't attach Xorg.0.log, I know which driver to use, as I have X >>> working correctly with Linux(Slackware) on that same machine[another >>> hard drive]. =A0It is just that I have no way of saving logs or posting >>> information without taking a picture, I would to put all doubts away. >> >> Honestly, I really don't understand the "I can't attach Xorg.log" >> wording. >> >> It's a physical log file, just a regular file. How is it that you cannot >> copy it from the particular machine/hard drive/filesystem and put it >> someplace on the Internet, or paste the relevant parts inline in one of >> the emails? >> >> >>> As of know I will rebuild world, install new kernel remove all ports >>> and start from scratch. =A0If I can't get it to work with a fresh start= . >> >> There's really nothing wrong with your ports and you'll be only wasting >> your time with this generic and pointless "Windows-style reinstall >> everything" procedure, without actually looking at the issue itself. >> >> The other poster(s) already told you. If you need any help, you will >> have to provide error messages, you will have to provide error logs (and >> you will have to properly configure your xorg, because as you already >> noticed, autodetection clearly doesn't work the way you expect it to). >> >> >>> =A0I will wait for BETA 3 or an RC :) =A0I just want to help in testing= , >>> it is that I can't supply the information as I would like to :( >> >> I can 100% guarantee that BETA3 nor RC won't change anything in regard >> to the issue you're experiencing. Your problem lies elsewhere and you >> didn't even start systematically investigating it. > > =A0 =A0Newb hacker tip number one: try CTRL-ALT-F1 when you get the > technicolor screen. If your system isn't hosed then you'll get the > first tty. I do know this, before it was CTRL + ALT + BACKSPACE and now it is CTRL + ALT + F1 :) I am not exactly a ``newbie'' but I am not an ``expert'' as I am still learning :) system was not hosed, 'nv' driver was not getting it done :( It is old and unmaintained anymore. > =A0 =A0The only time I can think of where /var/log/Xorg.0.log wouldn't be > populated with something useful is if the kernel module livelocks > talking to the card and/or fsck takes out the file on the next reboot > because it was in use. > =A0 =A0And yes Michal is right, IIRC. 64-bit drivers didn't exist on that= version. > =A0 =A0Just try this file and get back to us please with something more > useful than "it doesn't work". Otherwise we can't help you . > -Garrett > Garrett & all, I have X working :) Used nvidia-driver, as specified in FreeBSD howto (handbook page). changed 'nv' to 'nvidia', added nvidia_enable=3D"YES" to /etc/rc.conf and now X works. I am loading more software that is needed and I will post back from that machine. I followed instructions here: http://www.freebsd.org/doc/handbook/makeworld.html I ran makeworld and it did make ``a world of a difference'' and now i have X. I am compiling openjdk on it and I will build more software that is needed for work. Thanks to all for helping. Regards, Antonio From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 17:04:32 2011 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 A70F1106566C for ; Tue, 20 Sep 2011 17:04:32 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by mx1.freebsd.org (Postfix) with ESMTP id 4F7418FC14 for ; Tue, 20 Sep 2011 17:04:32 +0000 (UTC) Received: by qwb8 with SMTP id 8so1941223qwb.3 for ; Tue, 20 Sep 2011 10:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6zp4+YFQDUnpHdtyUdEDaEhCNNrK1ekwqCt457hlPAU=; b=tM8bxzy+9et203ooEITc7XaFPOU8cvwkhQOPHbOOkD8j7HQvb+UrGpcSQNN1ST2wXz lYXJDXApq5qUx/yvjHWiLQNwzmyvWLYYsDnM+xjJIZovJsHzfuGnqDwLIej58mAbAWmH 9PHQed9AcZkMMlIL7gLzFkZXiEa/+nl3al3bE= MIME-Version: 1.0 Received: by 10.224.17.135 with SMTP id s7mr740545qaa.274.1316538271459; Tue, 20 Sep 2011 10:04:31 -0700 (PDT) Received: by 10.224.74.82 with HTTP; Tue, 20 Sep 2011 10:04:31 -0700 (PDT) In-Reply-To: <20110920143841.GA67532@sandvine.com> References: <20110920143841.GA67532@sandvine.com> Date: Tue, 20 Sep 2011 10:04:31 -0700 Message-ID: From: Garrett Cooper To: Ed Maste Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Request for testing - mfiutil(8) patch 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, 20 Sep 2011 17:04:32 -0000 On Tue, Sep 20, 2011 at 7:38 AM, Ed Maste wrote: > Mfiutil(8) is a commandline management tool for RAID controllers > supported by the mfi(4) driver. =A0I have a couple of changes to the way > battery back up unit (BBU) state is reported and I would like to request > testing from any mfi(4) users who are able to try my patch. > > If you're able to test it for me please grab the modified source tarball > from http://people.freebsd.org/~emaste/mfiutil.tar and build the patched > mfiutil. =A0Then send me the output of "mfiutil show battery" for both th= e > stock and patched mfiutil, as well as the controller model number and > the type of back up unit (none, battery, or supercap). > > (If you're running CURRENT already and want just the patch, it is at > http://people.freebsd.org/~emaste/patches/mfi_show.c.diff .) 1. It properly detects "no battery" when I tried to use a "new" battery with an incompatible daughter board (the firmware in the MegaRAID BIOS reported it was missing): # ./mfiutil show battery mfi0: No battery present 2. With the busted battery: # mfiutil show battery status =3D 0x0000 mfi0: Battery State: Manufacture Date: 9/19/2009 Serial Number: 1022 Manufacturer: LS1111001B Model: 3598301 Chemistry: LION Design Capacity: 1215 mAh Full Charge Capacity: 417 mAh Current Capacity: 404 mAh Charge Cycles: 59 Current Charge: 97% Design Voltage: 3700 mV Current Voltage: 4048 mV Temperature: 30 C Status: Firmware status: 0c00 normal Please note that this is what the controller firmware says about the batter= y: mfi0: 36830 (boot + 4s/0x0008/info) - Battery Present mfi0: 36831 (boot + 4s/0x0008/FATAL) - Battery has failed and cannot support data retention. Please replace the battery ... mfi0: 36842 (boot + 27s/0x0008/WARN) - BBU disabled; changing WB virtual disks to WT 3. With the new battery, properly installed, BBU learn in progress: # mfiutil show adapter mfi0 Adapter: Product Name: MegaRAID SAS 8704ELP Serial Number: P391734409 Firmware: 11.0.1-0042 RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 Battery Backup: not present NVRAM: 32K Onboard Memory: 128M Minimum Stripe: 8k Maximum Stripe: 1M I'll provide the last output once it's done relearning. My test patch can be found here as a reference (please note that the #if 0 stuff was stuff I was testing from the Linux megaraid driver that doesn't appear to work), including your change: http://pastebin.com/ZMac0T53 Some of the states like MFI_BBU_STATE_DISCHARGE_ACTIVE don't make sense in mfiutil because they overlap with other BBU states, and thus can't be distinguished from one another. Thanks! -Garrett PS This resolves the PR I filed at least (bin/160581). From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 17:32:36 2011 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 90F40106566C for ; Tue, 20 Sep 2011 17:32:36 +0000 (UTC) (envelope-from varga.michal@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 137008FC12 for ; Tue, 20 Sep 2011 17:32:34 +0000 (UTC) Received: by wyh15 with SMTP id 15so997456wyh.13 for ; Tue, 20 Sep 2011 10:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:organization :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=wUG7L7k5ctJM67pHuq+k5Z+Vy9uoTzX/9yJLPrszs20=; b=c/4M+fL7ohdXV7Obz7cGy/XxNBq58jR3FvC2Q4bf41gf82cshiqWeuFrdG0+PbxO6g 5uPnEKr7FfNWZqw/p2kSu1xXc0v3eMn5urhvHXw6eC1P0CriNjuTS5iV73eyVDdofujL 3wuWpNGZVxTTzl8vqo8R26taNg5VGyLuW59XY= Received: by 10.227.5.193 with SMTP id 1mr4372367wbw.57.1316539954121; Tue, 20 Sep 2011 10:32:34 -0700 (PDT) Received: from [10.0.101.2] (254.166.broadband10.iol.cz. [90.177.166.254]) by mx.google.com with ESMTPS id f26sm3282609wbp.7.2011.09.20.10.32.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 10:32:30 -0700 (PDT) From: Michal Varga To: Antonio Olivares In-Reply-To: References: <20110918042853.3D61C106566C@hub.freebsd.org> <1316521778.1744.92.camel@xenon> Content-Type: text/plain; charset="UTF-8" Organization: Stonehenge Date: Tue, 20 Sep 2011 19:32:27 +0200 Message-ID: <1316539947.1744.103.camel@xenon> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , Tom Evans , freebsd-current@freebsd.org Subject: Re: no X after installing xorg + xfce 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, 20 Sep 2011 17:32:36 -0000 On Tue, 2011-09-20 at 12:02 -0500, Antonio Olivares wrote: > > Newb hacker tip number one: try CTRL-ALT-F1 when you get the > > technicolor screen. If your system isn't hosed then you'll get the > > first tty. > > I do know this, before it was CTRL + ALT + BACKSPACE and now it is > CTRL + ALT + F1 :) I am not exactly a ``newbie'' but I am not an > ``expert'' as I am still learning :) > Those two are very different kinds of beasts. CTRL+ALT+Fx is an xf86/xorg substitute for the regular ALT+Fx (console switching), so that ALT+Fx can be still used within X applications. On the other hand, CTRL+ALT+BACKSPACE is a "zap" command, that will let you instantly kill a currently running X server. Note that in more recent versions of xorg (incl. 7.5), CTRL+ALT+BACKSPACE is disabled by default. To get it working again, you will need to setup xorg.conf with at least: Section "ServerLayout" Identifier "Main Layout" [...] InputDevice "Main Keyboard" "CoreKeyboard" EndSection Section "ServerFlags" [...] Option "DontZap" "False" EndSection Section "InputDevice" Identifier "Main Keyboard" Driver "kbd" Option "XkbOptions" "terminate:ctrl_alt_bksp" EndSection > Garrett & all, > > I have X working :) Used nvidia-driver, as specified in FreeBSD howto > (handbook page). changed 'nv' to 'nvidia', added nvidia_enable="YES" > to /etc/rc.conf and now X works. I am loading more software that is That's good to hear. Congratulations. m. -- Michal Varga, Stonehenge (Gmail account) From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 18:33:12 2011 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 575FA106564A for ; Tue, 20 Sep 2011 18:33:12 +0000 (UTC) (envelope-from ddkprog@yahoo.com) Received: from nm22.bullet.mail.ne1.yahoo.com (nm22.bullet.mail.ne1.yahoo.com [98.138.90.85]) by mx1.freebsd.org (Postfix) with SMTP id 076EE8FC08 for ; Tue, 20 Sep 2011 18:33:11 +0000 (UTC) Received: from [98.138.90.48] by nm22.bullet.mail.ne1.yahoo.com with NNFMP; 20 Sep 2011 18:20:38 -0000 Received: from [98.138.89.253] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 20 Sep 2011 18:20:38 -0000 Received: from [127.0.0.1] by omp1045.mail.ne1.yahoo.com with NNFMP; 20 Sep 2011 18:20:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 702715.48348.bm@omp1045.mail.ne1.yahoo.com Received: (qmail 16928 invoked by uid 60001); 20 Sep 2011 18:20:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1316542838; bh=loLvEiSc3WNJBg2MfGrsfTghjB4OyvK6+eafgrxLxWc=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=h3mWQjZoxPeZ/Z8OP+XbkbBRlMM6G+grEgK7ajkGaPDgeUE/lB+xO1dWqfV/yfdigauA+WyRU3jmsM4Lz3FUAS1fVVd0soI5eeylpmdLewdYqv4ePEE7gFDq0sDCfGIFUEiMvkXGzA3MhlOVvO0UgUd+wZflAWVrqkf476jbqWw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=G+J1bolRpKeVc7Yrus7L0U2yRAcXY0u6HOfdpH76uOIbdM+2VQpIBdO9kVuXbU+8jLh4Jkm3cnP4AVhEgu6pJF7SYpZrC6j3nkBsTnivwc4XfyCm2aoYJ/cn64Lrg2XCBjUR6i2elqBkWoEZyiWV0Fh5vWKHSjLvdwGO+LmqEgI=; X-YMail-OSG: KlgrUoYVM1mC6LmeLPY5MzQqR0GvsWiCCwaGW52KTGjbHIu kYm2glh32EQMto6ASLGMz3JDfFCkvIYTv6j7J1fcsxZxdyImnpVKhJa1DW6K u8kUrbE37waC5y4l57TCe.BexZ_5piNMXsF6hrp.bpWbmwOr7pihcHqsmCGJ j3L7aPMBBiis_Dqv8lLFaK.xNrtN.nhuRy7adEdi.lxIb4OD9tJJCnBKu84n 6e5M2QWUU5OJpbAZSLeimBR7g9BW_jDxO1jJIY6TgmbOkgpUtkWLbDJrfwz. hDss10XT9mR2OUAtGyTqGTXBoxSNiF7rO8ICh4NSbzrvBqUEc_fExDR1urmN iwFtkpLzhjx3PsOJKb6dvrreebdUxfD_4SFYwwE4frbxxffPPCvhtgOoX9Fd NPwcQ12VL1v7n Received: from [95.109.218.128] by web120526.mail.ne1.yahoo.com via HTTP; Tue, 20 Sep 2011 11:20:38 PDT X-Mailer: YahooMailClassic/14.0.5 YahooMailWebService/0.8.113.315625 Message-ID: <1316542838.11969.YahooMailClassic@web120526.mail.ne1.yahoo.com> Date: Tue, 20 Sep 2011 11:20:38 -0700 (PDT) From: paradox To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 20 Sep 2011 18:38:02 +0000 Subject: which "include" being 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: Tue, 20 Sep 2011 18:33:12 -0000 Why build the world uses /usr/include ? why not use "include" from the /obj/...include ? issue to "build world" with loss of multiple files at /usr/include/ From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 20:21:34 2011 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 5FD031065673 for ; Tue, 20 Sep 2011 20:21:34 +0000 (UTC) (envelope-from olivares14031@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 229728FC08 for ; Tue, 20 Sep 2011 20:21:33 +0000 (UTC) Received: by iadk27 with SMTP id k27so1475723iad.13 for ; Tue, 20 Sep 2011 13:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ilJBJfrOjXe7WNKfH5YlBln5GA6i3FqP/oc6Mmo8IKg=; b=Vm7X3fKKoAn0V4QqxyPQUX2VUHYw3THOgruQ9YTAxhXgzg4yWHkFC4ohUzCH7876Uw oz7p0lCPIUvy4J6ns+Bwy386ZRnlgT0EeW+O4TtPrrWv6DPNv/q8uBsf1TPeG8ked0PJ RpuEssjS7wbZUTJj3AD6+dkbM8bB24djw9EK0= MIME-Version: 1.0 Received: by 10.231.8.78 with SMTP id g14mr1965801ibg.85.1316550092726; Tue, 20 Sep 2011 13:21:32 -0700 (PDT) Received: by 10.42.177.199 with HTTP; Tue, 20 Sep 2011 13:21:32 -0700 (PDT) In-Reply-To: <1316539947.1744.103.camel@xenon> References: <20110918042853.3D61C106566C@hub.freebsd.org> <1316521778.1744.92.camel@xenon> <1316539947.1744.103.camel@xenon> Date: Tue, 20 Sep 2011 15:21:32 -0500 Message-ID: From: Antonio Olivares To: Michal Varga Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , Tom Evans , freebsd-current@freebsd.org Subject: Re: no X after installing xorg + xfce 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, 20 Sep 2011 20:21:34 -0000 On Tue, Sep 20, 2011 at 12:32 PM, Michal Varga wro= te: > On Tue, 2011-09-20 at 12:02 -0500, Antonio Olivares wrote: > >> > =A0 =A0Newb hacker tip number one: try CTRL-ALT-F1 when you get the >> > technicolor screen. If your system isn't hosed then you'll get the >> > first tty. >> >> I do know this, before it was CTRL + ALT + BACKSPACE and now it is >> CTRL + ALT + F1 :) =A0I am not exactly a ``newbie'' but I am not an >> ``expert'' as I am still learning :) >> > > Those two are very different kinds of beasts. CTRL+ALT+Fx is an > xf86/xorg substitute for the regular ALT+Fx (console switching), so that > ALT+Fx can be still used within X applications. > Yes :) I meant to kill X server, but it was depracated and now CTRL+ALT+BACKSPACE needs to be in xorg.conf with the Zap as you mention it. The CTRL + ALT + FX FX =3D f1, ... f12 to change virtual terminals :) But in this case did the same thing, killed X and then CTRL+C to try from stopping loading automatically. > On the other hand, CTRL+ALT+BACKSPACE is a "zap" command, that will let > you instantly kill a currently running X server. Note that in more > recent versions of xorg (incl. 7.5), CTRL+ALT+BACKSPACE is disabled by > default. To get it working again, you will need to setup xorg.conf with > at least: > > Section "ServerLayout" > =A0Identifier =A0 =A0"Main Layout" > [...] > =A0InputDevice =A0 "Main Keyboard" =A0 =A0 =A0 =A0 "CoreKeyboard" > EndSection > > Section "ServerFlags" > [...] > =A0Option =A0 =A0 =A0 =A0"DontZap" =A0 =A0 =A0 =A0 =A0 =A0 =A0 "False" > EndSection > > Section "InputDevice" > =A0Identifier =A0 =A0"Main Keyboard" > =A0Driver =A0 =A0 =A0 =A0"kbd" > =A0Option =A0 =A0 =A0 =A0"XkbOptions" =A0 =A0 =A0 =A0 =A0 =A0"terminate:c= trl_alt_bksp" > EndSection > > > >> Garrett & all, >> >> I have X working :) =A0Used nvidia-driver, as specified in FreeBSD howto >> (handbook page). =A0changed 'nv' to 'nvidia', added nvidia_enable=3D"YES= " >> to /etc/rc.conf and now X works. =A0I am loading more software that is > > That's good to hear. Congratulations. > > m. > $ uname -a FreeBSD e213-amd64-1.grullahighschool.org 9.0-BETA2 FreeBSD 9.0-BETA2 #0: Tue Sep 20 10:02:05 CDT 2011 root@e213-amd64-1:/usr/obj/usr/src/sys/GENERIC amd64 $ > > -- > Michal Varga, > Stonehenge (Gmail account) > > > Regards, Antonio From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 21:34:07 2011 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 8EA34106564A for ; Tue, 20 Sep 2011 21:34:07 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 3941B8FC08 for ; Tue, 20 Sep 2011 21:34:06 +0000 (UTC) Received: from draco.over-yonder.net (c-174-50-4-38.hsd1.ms.comcast.net [174.50.4.38]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 0292B37B65C; Tue, 20 Sep 2011 16:09:07 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 71209178BC; Tue, 20 Sep 2011 16:09:06 -0500 (CDT) Date: Tue, 20 Sep 2011 16:09:06 -0500 From: "Matthew D. Fuller" To: Peter Jeremy Message-ID: <20110920210906.GG14862@over-yonder.net> References: <20110918095526.D866D1065670@hub.freebsd.org> <4E7734B7.8030507@cran.org.uk> <20110920062349.GA84006@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110920062349.GA84006@server.vk2pj.dyndns.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.2 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: Bruce Cran , freebsd-current@freebsd.org Subject: Re: 9.0 beta2 & the new bsdinstaller 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, 20 Sep 2011 21:34:07 -0000 On Tue, Sep 20, 2011 at 04:23:49PM +1000 I heard the voice of Peter Jeremy, and lo! it spake thus: > On 2011-Sep-19 13:25:27 +0100, Bruce Cran wrote: > >Will 64 kB be enough for 9.x? > > At least for x86 architectures, it seems adequate. [...] > > As for size, I'd suggest that if the default freebsd-boot size is > going to be changed, it should be adjusted so that the following > partition is aligned to a reasonably sized power of 2 - 128KB or > 256KB. I've been meaning to mention this, but we really should document somewhere that it has a _MAXIMUM_ size. I setup a system a few weeks back with GPT, and figured I'd just make the first 'real' partition start at the 1 meg mark. And make everything before that (1 meg - the however many sectors for the pmbr) the freebsd-boot partition. It worked fine, up 'till the point that I tried to boot, and it completely failed to, complaining that the boot code was too big. I had to track around in pmbr to find . . cmp $0x9000,%ax.. . # Don't load past 0x90000, . . jae err_big.. . # 545k should be enough for . . mov %ax,%es.. . # any boot code. :) and redo the partition to 512k (leaving a few hundred k unused before the next partition started) before it would boot. That's a little nerve-wracking to hit on a critical system... -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 21:42:39 2011 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 3ED79106566C for ; Tue, 20 Sep 2011 21:42:39 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0EAFE8FC0A for ; Tue, 20 Sep 2011 21:42:38 +0000 (UTC) Received: by iadk27 with SMTP id k27so1570108iad.13 for ; Tue, 20 Sep 2011 14:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KRJ79WpSqjaiOLSuEo8ELn3sW3nz0pt0Eqg1BrMeJNM=; b=vOTk9UepDhhaiR/fsCN6lA1H8T+A2hZLOrEaqVQt7Jq+Tovyx5w+i8I9HfSB/3NtfU vGNKIlkd7YeXytLgK6znrcoYRToMcZnKT3APIxWwi0n9JMR4onbKMgO7lF+kMUFQ9mAh gSwCleoUG+t7c6rKBs9fDHiYAPU5dODnyRZHk= MIME-Version: 1.0 Received: by 10.231.82.131 with SMTP id b3mr2124776ibl.74.1316554958328; Tue, 20 Sep 2011 14:42:38 -0700 (PDT) Received: by 10.231.36.69 with HTTP; Tue, 20 Sep 2011 14:42:38 -0700 (PDT) In-Reply-To: <1316542838.11969.YahooMailClassic@web120526.mail.ne1.yahoo.com> References: <1316542838.11969.YahooMailClassic@web120526.mail.ne1.yahoo.com> Date: Tue, 20 Sep 2011 14:42:38 -0700 Message-ID: From: Kevin Oberman To: paradox Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: which "include" being 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: Tue, 20 Sep 2011 21:42:39 -0000 On Tue, Sep 20, 2011 at 11:20 AM, paradox wrote: > Why build the world uses /usr/include ? > why not use "include" from the /obj/...include ? > > issue to "build world" with loss of multiple files at /usr/include/ Did your make "build world" or "buildworld"? It should be all one word and it does use the header files in /usr/obj/... or /usr/src/... At least for me, it does. Failing to do so would break a lot of things. You should also look at the magic done by the .mk files. This does make some of the header files look like they were pulled from /usr/includes because of the things the .mk files do to your environment. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Sep 21 00:14:55 2011 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 161F9106566C for ; Wed, 21 Sep 2011 00:14:55 +0000 (UTC) (envelope-from freebsd-current-local@be-well.ilk.org) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.42]) by mx1.freebsd.org (Postfix) with ESMTP id E284D8FC19 for ; Wed, 21 Sep 2011 00:14:54 +0000 (UTC) Received: (qmail 2999 invoked from network); 20 Sep 2011 23:45:16 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Sep 2011 23:45:15 -0000 Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.8]) by be-well.ilk.org (Postfix) with ESMTP id 2139D2E0CE; Tue, 20 Sep 2011 19:45:09 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id CF8DD39830; Tue, 20 Sep 2011 19:45:08 -0400 (EDT) From: Lowell Gilbert To: paradox References: <1316542838.11969.YahooMailClassic@web120526.mail.ne1.yahoo.com> Date: Tue, 20 Sep 2011 19:45:08 -0400 In-Reply-To: <1316542838.11969.YahooMailClassic@web120526.mail.ne1.yahoo.com> (paradox's message of "Tue, 20 Sep 2011 11:20:38 -0700 (PDT)") Message-ID: <447h52ye0r.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: which "include" being used? 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: Wed, 21 Sep 2011 00:14:55 -0000 paradox writes: > Why build the world uses /usr/include ? > why not use "include" from the /obj/...include ? First it builds the toolchain, including the include files (as well as the compiler, etc.). To do this, it has to use the system include files. Once that is done, it uses the newly built tools and not the system ones. > issue to "build world" with loss of multiple files at /usr/include/ You'll need to restore them some other way to be able to run buildworld. Assuming you build and install the world successfully, you will then have a correct set of files in /usr/include. From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 23:10:33 2011 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 2C01B106564A for ; Tue, 20 Sep 2011 23:10:33 +0000 (UTC) (envelope-from ddkprog@yahoo.com) Received: from nm21.bullet.mail.ne1.yahoo.com (nm21.bullet.mail.ne1.yahoo.com [98.138.90.84]) by mx1.freebsd.org (Postfix) with SMTP id E27778FC0A for ; Tue, 20 Sep 2011 23:10:32 +0000 (UTC) Received: from [98.138.90.50] by nm21.bullet.mail.ne1.yahoo.com with NNFMP; 20 Sep 2011 23:10:32 -0000 Received: from [98.138.89.232] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 20 Sep 2011 23:10:32 -0000 Received: from [127.0.0.1] by omp1047.mail.ne1.yahoo.com with NNFMP; 20 Sep 2011 23:10:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 413916.57685.bm@omp1047.mail.ne1.yahoo.com Received: (qmail 64597 invoked by uid 60001); 20 Sep 2011 23:10:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1316560232; bh=COYScraqud8thUqiWBWDeqJIaR968+UTC7XNTJuYB5M=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=A3oz3evtRPgIrbftn+eA0ociki9oLZ589QcOrY40t9KnKBuNOQViKOxQpTOHKbabP5xoFpITWRWidiosBFbD7U6g+NLJdI3xeOdEP8lBqtuOVgidDfVCiq7pBizgjnFfHJKKdU6s2NWRcAWTEuhfYHJOdqMK5qre3wC2282G7wU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=u8EezM45K97/8K/oBDHvcaFOEJVjR/aBciDLjZEPtuIyPgzvRNsC8cMH+lJPKWuJBShlkSTKOOex55NQ8hlzh2F4CgkEtyHkEAbdLkkVm++CXKWRCgwABP5AWCrRM/cupUMitwT4aj+LFMyF5+yF9P3D/+Al3Lp4sahwoclD9wY=; X-YMail-OSG: NpI08_sVM1k5LjpMRcRzykHd1QwbJYP.aal1Laicfw8kr.l FtDTTgTFjXMkg7RzIN13.IJ1GzHKfGPsx4B731ptG93yXV2_zj9MLsFBxNg0 31KcvRYf9ktxUYDQL2_3ndCXXCY9Ui4TSkA_CWigYDlb3HgI.BYs6NI7lNML h3q6ue.aol1yYDWxpLqb3LN8HCz_iuSYzKjyAC2tDK1oINJWts6mdP3alvbw diVxw5cImLJr3B_Fu.8wTB0rQDYjnB5vHIX46ESp33tByso3Cskjn0ZSWNbD qTJifMo6I0FNWGYqgO89IWicaEqnNS4ZZZm_CgUnYqvXwzF_.sS4ybGJZpKq UxkuWw.VoHq9vO9d6iMVmlX96Q0qjwS3PJgwviwFJ5tWcVGa_gBu3CSrqL9E U9do07JCfyIViwNWz0EMIyNsqZM6.9Oor4bTb Received: from [95.109.221.220] by web120530.mail.ne1.yahoo.com via HTTP; Tue, 20 Sep 2011 16:10:32 PDT X-Mailer: YahooMailClassic/14.0.5 YahooMailWebService/0.8.113.315625 Message-ID: <1316560232.58213.YahooMailClassic@web120530.mail.ne1.yahoo.com> Date: Tue, 20 Sep 2011 16:10:32 -0700 (PDT) From: paradox To: freebsd-current@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Wed, 21 Sep 2011 01:08:45 +0000 Subject: Re: which "include" being 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: Tue, 20 Sep 2011 23:10:33 -0000 try remove or move /usr/include and rebuild the world > wrote: > > Why build the world uses /usr/include ? > > why not use "include" from the /obj/...include ? > > > > issue to "build world" with loss of multiple files at > /usr/include/ > > Did your make "build world" or "buildworld"? It should be > all one word > and it does use > the header files in /usr/obj/... or /usr/src/... At least > for me, it > does. Failing to do so > would break a lot of things. > > You should also look at the magic done by the .mk files. > This does > make some of the > header files look like they were pulled from /usr/includes > because of > the things the .mk > files do to your environment. From owner-freebsd-current@FreeBSD.ORG Wed Sep 21 01:19:18 2011 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 280F7106564A for ; Wed, 21 Sep 2011 01:19:18 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E61C58FC08 for ; Wed, 21 Sep 2011 01:19:17 +0000 (UTC) Received: by iadk27 with SMTP id k27so1846806iad.13 for ; Tue, 20 Sep 2011 18:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m8VIS+YOJtK3IqtFWAmBuuR8XAT81JFGH7TYi2fJi/U=; b=taGyAo5qt1s2o5GKgwwdg8HPWoZ1sda+UTDoX8xnsvO6Bkf0+z7QzmIYQKeiCbbsJJ IFqhn8PXIMHUZ6hQJ85UowgORMuJWnBB2Y2xjxeWy7IAxSJYITByPQq/cETz3zTHlXWW jdkacaoren+21sXfANkah98KYOi++r/EIMwJU= MIME-Version: 1.0 Received: by 10.231.82.131 with SMTP id b3mr81219ibl.74.1316567957240; Tue, 20 Sep 2011 18:19:17 -0700 (PDT) Received: by 10.231.36.69 with HTTP; Tue, 20 Sep 2011 18:19:17 -0700 (PDT) Received: by 10.231.36.69 with HTTP; Tue, 20 Sep 2011 18:19:17 -0700 (PDT) In-Reply-To: <1316560232.58213.YahooMailClassic@web120530.mail.ne1.yahoo.com> References: <1316560232.58213.YahooMailClassic@web120530.mail.ne1.yahoo.com> Date: Tue, 20 Sep 2011 18:19:17 -0700 Message-ID: From: Kevin Oberman To: paradox Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: which "include" being 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, 21 Sep 2011 01:19:18 -0000 On Sep 20, 2011 6:09 PM, "paradox" wrote: > > try remove or move /usr/include > and rebuild the world > > > wrote: > > > Why build the world uses /usr/include ? > > > why not use "include" from the /obj/...include ? > > > > > > issue to "build world" with loss of multiple files at > > /usr/include/ > > > > Did your make "build world" or "buildworld"? It should be > > all one word > > and it does use > > the header files in /usr/obj/... or /usr/src/... At least > > for me, it > > does. Failing to do so > > would break a lot of things. > > > > You should also look at the magic done by the .mk files. > > This does > > make some of the > > header files look like they were pulled from /usr/includes > > because of > > the things the .mk > > files do to your environment. Sorry. I misunderstood. To build a new system, you have to start with something. You build the toolcain and gcc. Those have to be built first with the existing compiler and toolchain which uses the existing system include files. Later in buildworld, they are re-built using the new toolchain, compiler, and header files. If you lost your system header files, you will need to restore them before you can re-build the system. Sorry. R. Kevin Oberman, Network Engineer Retired kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Sep 21 02:34:29 2011 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 66688106564A for ; Wed, 21 Sep 2011 02:34:29 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2240B8FC08 for ; Wed, 21 Sep 2011 02:34:29 +0000 (UTC) Received: by gyf2 with SMTP id 2so1068180gyf.13 for ; Tue, 20 Sep 2011 19:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=qQP56I/pXhiBV+qqt1vmZMrjxVGIWv0MB+9lhApT9DE=; b=m4PkmJas3VLSXP27tpK9oI/+8xVjXYlzIj51b/3U7pFxNGNBpbO7LqkhzIWcHP3Ibd mpODvWGtXhBUU7U2sYyrvKE4GQCk1VQwsMrb4qlaXytGKFvkouejDj9PYUyi3nMdFUmV e2kMqIL5gpX44OoGhkWMqhA/y3M0rpvWzVVM4= Received: by 10.236.129.238 with SMTP id h74mr1112174yhi.99.1316572468630; Tue, 20 Sep 2011 19:34:28 -0700 (PDT) Received: from [10.48.78.188] (mobile-166-205-137-195.mycingular.net. [166.205.137.195]) by mx.google.com with ESMTPS id x65sm4629915yhh.26.2011.09.20.19.34.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 19:34:27 -0700 (PDT) References: <1316560232.58213.YahooMailClassic@web120530.mail.ne1.yahoo.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8L1) From: Garrett Cooper Date: Tue, 20 Sep 2011 19:34:16 -0700 To: Kevin Oberman Cc: "freebsd-current@freebsd.org" , paradox Subject: Re: which "include" being 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, 21 Sep 2011 02:34:29 -0000 On Sep 20, 2011, at 6:19 PM, Kevin Oberman wrote: > On Sep 20, 2011 6:09 PM, "paradox" wrote: >>=20 >> try remove or move /usr/include >> and rebuild the world >>=20 >>> wrote: >>>> Why build the world uses /usr/include ? >>>> why not use "include" from the /obj/...include ? >>>>=20 >>>> issue to "build world" with loss of multiple files at >>> /usr/include/ >>>=20 >>> Did your make "build world" or "buildworld"? It should be >>> all one word >>> and it does use >>> the header files in /usr/obj/... or /usr/src/... At least >>> for me, it >>> does. Failing to do so >>> would break a lot of things. >>>=20 >>> You should also look at the magic done by the .mk files. >>> This does >>> make some of the >>> header files look like they were pulled from /usr/includes >>> because of >>> the things the .mk >>> files do to your environment. >=20 > Sorry. I misunderstood. >=20 > To build a new system, you have to start with something. You build the > toolcain and gcc. Those have to be built first with the existing compiler= > and toolchain which uses the existing system include files. >=20 > Later in buildworld, they are re-built using the new toolchain, compiler, > and header files. >=20 > If you lost your system header files, you will need to restore them before= > you can re-build the system. > Sorry. I'd unpack a tarball from the most recent release. It's the easiest way to f= ix things :).. -Garrett= From owner-freebsd-current@FreeBSD.ORG Wed Sep 21 02:40:39 2011 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 15465106564A for ; Wed, 21 Sep 2011 02:40:39 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id AB2688FC0C for ; Wed, 21 Sep 2011 02:40:38 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id p8L1k4Rp055213 for ; Tue, 20 Sep 2011 19:46:04 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id p8L1k4lf055210 for ; Tue, 20 Sep 2011 19:46:04 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Tue, 20 Sep 2011 19:46:04 -0600 (MDT) From: Warren Block To: current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Tue, 20 Sep 2011 19:46:05 -0600 (MDT) Cc: Subject: Improving the FreeBSD-9 boot menu 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, 21 Sep 2011 02:40:39 -0000 The patch in PR 160818 makes some clarifications and improvements to the new boot menu. Obviously this is not for 9.0-RELEASE, just wanting to get it out there so people can look at it. http://www.freebsd.org/cgi/query-pr.cgi?pr=160818 Among other things, the patch removes the word "boot" from options that don't actually boot. The options are lined up, and enabled options are drawn in reverse video when loader_color=1 is set in /boot/loader.conf. From owner-freebsd-current@FreeBSD.ORG Wed Sep 21 04:41:29 2011 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 5F5AB1065673 for ; Wed, 21 Sep 2011 04:41:29 +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 4B6068FC12 for ; Wed, 21 Sep 2011 04:41:27 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id p8L4fEvS058527 for ; Wed, 21 Sep 2011 13:41:24 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p8L4fCJV039539 for ; Wed, 21 Sep 2011 13:41:13 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 21 Sep 2011 13:38:28 +0900 (JST) Message-Id: <20110921.133828.1346903263789064527.hrs@allbsd.org> To: current@FreeBSD.org From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Wed_Sep_21_13_38_28_2011_901)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Wed, 21 Sep 2011 13:41:25 +0900 (JST) X-Spam-Status: No, score=-104.6 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: Subject: RFC: /etc/pccard_ether triggered by usbus 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, 21 Sep 2011 04:41:29 -0000 ----Security_Multipart0(Wed_Sep_21_13_38_28_2011_901)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Sep_21_13_38_28_2011_390)--" Content-Transfer-Encoding: 7bit ----Next_Part(Wed_Sep_21_13_38_28_2011_390)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I would like your comments about adding NOT operator into string match rule in devd.conf. The reason is as follows. After the USB packet filter was added, devctl attach notifications from an IFT_USB interface like "!system=IFNET subsystem=usbus0 type=ATTACH" trigger a default rule for interface initialization in devd.conf. Although it is harmless in most cases, it would be great if we can filter out the notifications because it can result in a slower booting. However, the devd supports no NOT operator in a string match. The attached patch is to add the "!" operator into the match sub-statement. For example, match "bus" "pccard[0-9]+" matches the content of bus against a regex pccard[0-9]+. The "!" operator like the following match "bus" "!pccard[0-9]+" inverts the logic. I am still not sure if this is the best approach but I could not find another way. Filtering out it in if_attach() or adding a new variable like "configurable=yes" in the notification looks overkill to me. Any comments/suggestions? -- Hiroki ----Next_Part(Wed_Sep_21_13_38_28_2011_390)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="devd.cc.20110921-1.diff" Index: etc/devd.conf =================================================================== --- etc/devd.conf (revision 225668) +++ etc/devd.conf (working copy) @@ -38,6 +38,7 @@ # notify 0 { match "system" "IFNET"; + match "subsystem" "!usbus[0-9]+"; match "type" "ATTACH"; action "/etc/pccard_ether $subsystem start"; }; Index: sbin/devd/devd.hh =================================================================== --- sbin/devd/devd.hh (revision 225668) +++ sbin/devd/devd.hh (working copy) @@ -92,6 +92,7 @@ private: std::string _var; std::string _re; + bool _inv; regex_t _regex; }; Index: sbin/devd/devd.cc =================================================================== --- sbin/devd/devd.cc (revision 225668) +++ sbin/devd/devd.cc (working copy) @@ -251,7 +251,14 @@ : _var(var) { _re = "^"; - _re.append(c.expand_string(string(re))); + if (!c.expand_string(string(re)).empty() && + c.expand_string(string(re)).at(0) == '!') { + _re.append(c.expand_string(string(re)).substr(1)); + _inv = 1; + } else { + _re.append(c.expand_string(string(re))); + _inv = 0; + } _re.append("$"); regcomp(&_regex, _re.c_str(), REG_EXTENDED | REG_NOSUB | REG_ICASE); } @@ -268,10 +275,13 @@ bool retval; if (Dflag) - fprintf(stderr, "Testing %s=%s against %s\n", _var.c_str(), - value.c_str(), _re.c_str()); + fprintf(stderr, "Testing %s=%s against %s, invert=%d\n", + _var.c_str(), value.c_str(), _re.c_str(), _inv); retval = (regexec(&_regex, value.c_str(), 0, NULL, 0) == 0); + if (_inv == 1) + retval = (retval == 0) ? 1 : 0; + return retval; } ----Next_Part(Wed_Sep_21_13_38_28_2011_390)---- ----Security_Multipart0(Wed_Sep_21_13_38_28_2011_901)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk55akQACgkQTyzT2CeTzy0pcACfRFxTb9mcajHA8alf8CK4xl1e DkMAoJUlHb2HIv8jvX8+R8/SPFbz6zlx =wldQ -----END PGP SIGNATURE----- ----Security_Multipart0(Wed_Sep_21_13_38_28_2011_901)---- From owner-freebsd-current@FreeBSD.ORG Wed Sep 21 07:44:02 2011 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 0B5FA106564A for ; Wed, 21 Sep 2011 07:44:02 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id B907A8FC12 for ; Wed, 21 Sep 2011 07:44:01 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R6HTM-0006mw-5I for freebsd-current@freebsd.org; Wed, 21 Sep 2011 09:44:00 +0200 Received: from 178.214.36.169 ([178.214.36.169]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2011 09:44:00 +0200 Received: from citrin by 178.214.36.169 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2011 09:44:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Anton Yuzhaninov Date: Wed, 21 Sep 2011 07:43:44 +0000 (UTC) Organization: Vega Lines: 17 Sender: Anton Yuzhaninov Message-ID: References: <4E5E46A4.3060705@citrin.ru> <4E6A99A9.1000204@delphij.net> <864o0adkva.fsf@kopusha.home.net> <86mxe0r8o5.fsf@in138.ua3> <20110919212722.GQ1511@deviant.kiev.zoral.com.ua> X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 178.214.36.169 X-Comment-To: Kostik Belousov User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/9.0-BETA2 (i386)) Subject: Re: truss 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, 21 Sep 2011 07:44:02 -0000 On Tue, 20 Sep 2011 00:27:22 +0300, Kostik Belousov wrote: KB> Could you, please, test the change below ? For me, I still can truss(1) KB> or debug with gdb after the change applied. Does truss work for you KB> with only this change, without resetting SIGTRAP handler in truss process ? KB> KB> commit 2ae586c039a55399edc3b34cd40410e0d690a16c KB> Author: Konstantin Belousov KB> Date: Tue Sep 20 00:25:07 2011 +0300 KB> KB> Do not deliver SIGTRAP on exec as the normal signal, use ptracestop() KB> on syscall exit path. Otherwise, if SIGTRAP is ignored, that tdsendsignal() KB> do not want to deliver, and debugger never get a notification of exec. I can confirm - with this patch unmodified truss works when SIGTRAP is ignored. -- Anton Yuzhaninov From owner-freebsd-current@FreeBSD.ORG Wed Sep 21 08:26:49 2011 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 9616D1065672 for ; Wed, 21 Sep 2011 08:26:49 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost02.isp.att.net (fmailhost02.isp.att.net [204.127.217.102]) by mx1.freebsd.org (Postfix) with ESMTP id 854628FC08 for ; Wed, 21 Sep 2011 08:26:49 +0000 (UTC) Date: Wed, 21 Sep 2011 08:26:47 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-72-147-183-55.sdf.bellsouth.net[72.147.183.55]) by isp.att.net (frfwmhc02) with SMTP id <20110921082647H0200ce825e>; Wed, 21 Sep 2011 08:26:47 +0000 X-Originating-IP: [72.147.183.55] From: "Thomas Mueller" To: freebsd-current@freebsd.org References: <20110920210906.GG14862@over-yonder.net> Message-Id: <20110921082649.9616D1065672@hub.freebsd.org> Subject: Re: 9.0 beta2 & the new bsdinstaller 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, 21 Sep 2011 08:26:49 -0000 >From "Matthew D. Fuller" : > I've been meaning to mention this, but we really should document > somewhere that it has a _MAXIMUM_ size. > I setup a system a few weeks back with GPT, and figured I'd just make > the first 'real' partition start at the 1 meg mark. And make > everything before that (1 meg - the however many sectors for the pmbr) > the freebsd-boot partition. > It worked fine, up 'till the point that I tried to boot, and it > completely failed to, complaining that the boot code was too big. I > had to track around in pmbr to find > . . cmp $0x9000,%ax.. . # Don't load past 0x90000, > . . jae err_big.. . # 545k should be enough for > . . mov %ax,%es.. . # any boot code. :) > and redo the partition to 512k (leaving a few hundred k unused before > the next partition started) before it would boot. That's a little > nerve-wracking to hit on a critical system... I don't think there is any particular advantage in aligning GPT partitions on 1 MB boundaries. Nothing sacred about being an integer power of 2, wouldn't it be sufficient for boot partition size to be divisible by 4096 bytes, when the hard drive sector size is 4096 bytes? Tom From owner-freebsd-current@FreeBSD.ORG Wed Sep 21 11:54:45 2011 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 0CE41106564A for ; Wed, 21 Sep 2011 11:54:45 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 046B38FC08 for ; Wed, 21 Sep 2011 11:54:43 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R6LNz-0008O2-2a for freebsd-current@freebsd.org; Wed, 21 Sep 2011 13:54:43 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2011 13:54:43 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2011 13:54:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 21 Sep 2011 13:54:22 +0200 Lines: 48 Message-ID: References: <1316560232.58213.YahooMailClassic@web120530.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD140F3C1456C0178AC8BC9D0" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.1) Gecko/20110907 Thunderbird/6.0.1 In-Reply-To: X-Enigmail-Version: 1.1.2 Subject: Re: which "include" being 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, 21 Sep 2011 11:54:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD140F3C1456C0178AC8BC9D0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 21/09/2011 04:34, Garrett Cooper wrote: > On Sep 20, 2011, at 6:19 PM, Kevin Oberman wrote: >> To build a new system, you have to start with something. You build the= >> toolcain and gcc. Those have to be built first with the existing comp= iler >> and toolchain which uses the existing system include files. >> >> Later in buildworld, they are re-built using the new toolchain, compil= er, >> and header files. >> >> If you lost your system header files, you will need to restore them be= fore >> you can re-build the system. >> Sorry. >=20 > I'd unpack a tarball from the most recent release. It's the easiest way= to fix things :).. I second this suggestion - if the system is damaged enough, this is really the best and most painless way. Because of API & ABI stability in FreeBSD STABLE branches, there isn't much that can go wrong even if you repopulate it (temporarily) with another release's sources. --------------enigD140F3C1456C0178AC8BC9D0 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.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk550HQACgkQldnAQVacBchAvQCg/fGUybJOLyec9UYcj64uXP45 CxwAn0+svw7DTYNWCzqSEmd+0M7mSAsF =BtP1 -----END PGP SIGNATURE----- --------------enigD140F3C1456C0178AC8BC9D0-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 21 13:13:40 2011 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 4E13E1065673; Wed, 21 Sep 2011 13:13:40 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by mx1.freebsd.org (Postfix) with ESMTP id F1FF58FC0C; Wed, 21 Sep 2011 13:13:39 +0000 (UTC) Received: by gwj15 with SMTP id 15so2117718gwj.17 for ; Wed, 21 Sep 2011 06:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8Vc7obEy40KQXcUgrQpIEA+L8a2OqwgthJ3/8Y7wbD0=; b=DIU4MegVjnMZx4wbZbKKjfYA17/VMOkyajiIs0Nn7EAnk886jBYi4qDJ2DK1nTTr4H xwK6W+dwmclfHDCNX2Yl2PxF0KaD7YoOgQcubA5wCc4rGEfSYzdQyvHKIuBKVgP166Pw xM4yl0SKEbxu2WKIeWfBZHq9ZFZt3rBIF8HrA= MIME-Version: 1.0 Received: by 10.150.229.16 with SMTP id b16mr1007171ybh.155.1316610819386; Wed, 21 Sep 2011 06:13:39 -0700 (PDT) Received: by 10.150.53.2 with HTTP; Wed, 21 Sep 2011 06:13:39 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Sep 2011 17:13:39 +0400 Message-ID: From: Sergey Kandaurov To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, FreeBSD Current Subject: Re: LOR in route.c // scope6.c 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, 21 Sep 2011 13:13:40 -0000 On 19 August 2011 05:07, Garrett Cooper wrote: > Hi, > =A0 =A0I've periodically seen the following LOR when trying to repro a > panic after restarting my network configuration: > > :lock order reversal: > =A01st 0xc4142f1c rtentry (rtentry) @ /usr/src/sys/net/routec:362 > =A02nd 0xc3d08604 if_afdata (if_afdata) @ /usr/src/sys/netinet6/scope6.c:= 417 > KDB: stack backtrace: > db_trace_self_wrapper(...) > _witness_debugger(...) > _rw_wlock(...) > in6_setscope(...) > in6_purgeaddr(...) > in6_control(...) > ifioctl(...) > soo_ioctl(...) > kern_ioctl(...) > ioctl(...) > syscallenter(...) > syscall(...) > Xint0x80_syscall() > > I don't have a full backtrace or core for this. This was running > r224948 UP with WITNESS. > I just got exactly the same LOR on a very fresh current with /etc/rc.d/netif restart, and then I lost the system. Thanks for the report. I hope to dig out the solution... --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Sep 21 13:53:07 2011 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 6FC4C106566C for ; Wed, 21 Sep 2011 13:53:07 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 2E2348FC17 for ; Wed, 21 Sep 2011 13:53:06 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id p8LDr5Uk006069; Wed, 21 Sep 2011 07:53:05 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id p8LDr56H006066; Wed, 21 Sep 2011 07:53:05 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Wed, 21 Sep 2011 07:53:05 -0600 (MDT) From: Warren Block To: Thomas Mueller In-Reply-To: <20110921082649.9616D1065672@hub.freebsd.org> Message-ID: References: <20110920210906.GG14862@over-yonder.net> <20110921082649.9616D1065672@hub.freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Wed, 21 Sep 2011 07:53:05 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: 9.0 beta2 & the new bsdinstaller 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, 21 Sep 2011 13:53:07 -0000 On Wed, 21 Sep 2011, Thomas Mueller wrote: >>> From "Matthew D. Fuller" : > >> I've been meaning to mention this, but we really should document >> somewhere that it has a _MAXIMUM_ size. > >> I setup a system a few weeks back with GPT, and figured I'd just make >> the first 'real' partition start at the 1 meg mark. And make >> everything before that (1 meg - the however many sectors for the pmbr) >> the freebsd-boot partition. > >> It worked fine, up 'till the point that I tried to boot, and it >> completely failed to, complaining that the boot code was too big. I >> had to track around in pmbr to find > >> . . cmp $0x9000,%ax.. . # Don't load past 0x90000, >> . . jae err_big.. . # 545k should be enough for >> . . mov %ax,%es.. . # any boot code. :) > >> and redo the partition to 512k (leaving a few hundred k unused before >> the next partition started) before it would boot. That's a little >> nerve-wracking to hit on a critical system... > > I don't think there is any particular advantage in aligning GPT partitions on 1 MB boundaries. Agreed. But Windows 7 also starts the main partition at 1M. Taking that as a standard could provide compatibility with other (admittedly poorly-written) disk partitioning software. And it might not, but if it helps with POLA for people used to using GPT elsewhere, that's not a bad reason either. The bug shown above means the freebsd-boot partition should be limited to 512K at present. Another 512K of space after that doesn't really cost anything. If that extra space is needed later, it can be used without repartitioning. From owner-freebsd-current@FreeBSD.ORG Wed Sep 21 14:08:41 2011 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 7C201106564A for ; Wed, 21 Sep 2011 14:08:41 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 2172C8FC16 for ; Wed, 21 Sep 2011 14:08:40 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id p8LE8cPe006396; Wed, 21 Sep 2011 08:08:38 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id p8LE8cfX006393; Wed, 21 Sep 2011 08:08:38 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Wed, 21 Sep 2011 08:08:38 -0600 (MDT) From: Warren Block To: Thomas Mueller In-Reply-To: Message-ID: References: <20110920210906.GG14862@over-yonder.net> <20110921082649.9616D1065672@hub.freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Wed, 21 Sep 2011 08:08:38 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: 9.0 beta2 & the new bsdinstaller 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, 21 Sep 2011 14:08:41 -0000 Forgot to add this for reference earlier: http://msdn.microsoft.com/en-us/library/dd758814%28v=sql.100%29.aspx "Valid Starting Partition Offsets" has some justification for the 1M offset. From owner-freebsd-current@FreeBSD.ORG Wed Sep 21 14:24:49 2011 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 95775106566C for ; Wed, 21 Sep 2011 14:24:49 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 319158FC16 for ; Wed, 21 Sep 2011 14:24:49 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 682DF2A28CBF; Wed, 21 Sep 2011 16:24:48 +0200 (CEST) Date: Wed, 21 Sep 2011 16:24:48 +0200 From: Ed Schouten To: Garrett Cooper Message-ID: <20110921142448.GR33993@hoeg.nl> References: <1316560232.58213.YahooMailClassic@web120530.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W4pDZ/VvazBYHhxQ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-current@freebsd.org" , paradox Subject: Re: which "include" being 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, 21 Sep 2011 14:24:49 -0000 --W4pDZ/VvazBYHhxQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Garrett Cooper , 20110921 04:34: > I'd unpack a tarball from the most recent release. It's the easiest > way to fix things :).. Well, sometimes this is sufficient: cd /usr/src/include make install clean That way you'll at least get the default system headers back. --=20 Ed Schouten WWW: http://80386.nl/ --W4pDZ/VvazBYHhxQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOefOwAAoJEG5e2P40kaK7gR0P/3ZgobZwvYMvfTgrev+UfLbp AMzEuWWCfB0gOUV8xfhtnhmRSy4PyX8Y88uSFA3mDdCAtJHccRO2KN8KasZvxSvQ +iHvExRfGcLj1/P/an7jv6vpMwPjWLGmeSsbvLp61SpM0TgsJJz1LH6exRhwkW0v ZTYdoLigXMs+LObKIAbm55B+u+m58ph0nQfWwyJDcNbn9aMZ5NR2ratIq0QsutMn UyUnL7CbCZipiG4e3IHv1HP+zLLA6VEgsWDVNY+Y0r/GAXS4hHQhJoTWicF9RD46 cjy9rnOowI72O7NFv4ALLV4ha1yTsgvMW5G8Qbl2sudyY8x6XsWfcQZzRYwXho0s S8jhyRJ4GBA2GZuIaZaaP3kiz0IYzOS5DkrUEkpn5tECoyz0h+wO+EiTY6T7fJSK mQaQlxdXKKEQ1JDFGLWvYugooLyyPAHAhMJFfj1nsAOwPDMcAmrMKupfhGdltPPG 9kIPkUqiz6duftCdYh2XblZaTJO3UsyzY1vGAg6mW2K+dPMDmTgzPAlwbfT9zhcJ upZbpu9/3yBXxL/GGM9gXM/4TW3l8saCbgGPkisnzq5UJLRMO2EgOSCV1CCRZQbh z8U7VXO2U3Ro5zV4UK3YBM81vdvt5GxzgILqZPke8Ms8rtTEXjuYlbwaTT5kZKwV I17PtAx0FFVQztlxNM5i =ltGq -----END PGP SIGNATURE----- --W4pDZ/VvazBYHhxQ-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 21 17:47:37 2011 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 A6FDB106564A for ; Wed, 21 Sep 2011 17:47:37 +0000 (UTC) (envelope-from luke@foolishgames.com) Received: from stargazer.midnightbsd.org (cl-218.chi-02.us.sixxs.net [IPv6:2001:4978:f:d9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4AD348FC15 for ; Wed, 21 Sep 2011 17:47:37 +0000 (UTC) Received: from [10.3.129.232] (mobile-198-228-226-075.mycingular.net [198.228.226.75]) (authenticated bits=0) by stargazer.midnightbsd.org (8.14.5/8.14.5) with ESMTP id p8LHlVV5064175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 21 Sep 2011 13:47:34 -0400 (EDT) (envelope-from luke@foolishgames.com) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.2 at stargazer.midnightbsd.org X-Authentication-Warning: stargazer.midnightbsd.org: Host mobile-198-228-226-075.mycingular.net [198.228.226.75] claimed to be [10.3.129.232] References: <20110920210906.GG14862@over-yonder.net> <20110921082649.9616D1065672@hub.freebsd.org> In-Reply-To: <20110921082649.9616D1065672@hub.freebsd.org> Mime-Version: 1.0 (iPhone Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8L1) From: Lucas Holt Date: Wed, 21 Sep 2011 13:47:26 -0400 To: Thomas Mueller Cc: "freebsd-current@freebsd.org" Subject: Re: 9.0 beta2 & the new bsdinstaller 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, 21 Sep 2011 17:47:37 -0000 1MB is a magic number. It works with advanced format disks, traditional disk= s, some odd SSD and most raid configurations.=20 Lucas Holt On Sep 21, 2011, at 4:26 AM, "Thomas Mueller" wr= ote: >> =46rom "Matthew D. Fuller" : >=20 >> I've been meaning to mention this, but we really should document >> somewhere that it has a _MAXIMUM_ size. >=20 >> I setup a system a few weeks back with GPT, and figured I'd just make >> the first 'real' partition start at the 1 meg mark. And make >> everything before that (1 meg - the however many sectors for the pmbr) >> the freebsd-boot partition. >=20 >> It worked fine, up 'till the point that I tried to boot, and it >> completely failed to, complaining that the boot code was too big. I >> had to track around in pmbr to find >=20 >> . . cmp $0x9000,%ax.. . # Don't load past 0x90000, >> . . jae err_big.. . # 545k should be enough for >> . . mov %ax,%es.. . # any boot code. :) >=20 >> and redo the partition to 512k (leaving a few hundred k unused before >> the next partition started) before it would boot. That's a little >> nerve-wracking to hit on a critical system... >=20 > I don't think there is any particular advantage in aligning GPT partitions= on 1 MB boundaries. >=20 > Nothing sacred about being an integer power of 2, wouldn't it be sufficien= t for boot partition size to be divisible by 4096 bytes, when the hard drive= sector size is 4096 bytes? >=20 >=20 > Tom >=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 Thu Sep 22 17:46:33 2011 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 469A31065673; Thu, 22 Sep 2011 17:46:33 +0000 (UTC) (envelope-from david.somayajulu@qlogic.com) Received: from TX2EHSOBE001.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by mx1.freebsd.org (Postfix) with ESMTP id ED2168FC0A; Thu, 22 Sep 2011 17:46:32 +0000 (UTC) Received: from mail162-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Thu, 22 Sep 2011 17:31:26 +0000 Received: from mail162-tx2 (localhost.localdomain [127.0.0.1]) by mail162-tx2-R.bigfish.com (Postfix) with ESMTP id 8D5CD16B0246; Thu, 22 Sep 2011 17:31:26 +0000 (UTC) X-SpamScore: -6 X-BigFish: VPS-6(zzc85fh14ffOzz1202hzz8275bh8275dhz2ei2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:198.70.193.64; KIP:(null); UIP:(null); IPVD:NLI; H:avexcashub1.qlogic.com; RD:avexcashub2.qlogic.com; EFVD:NLI Received-SPF: neutral (mail162-tx2: 198.70.193.64 is neither permitted nor denied by domain of qlogic.com) client-ip=198.70.193.64; envelope-from=david.somayajulu@qlogic.com; helo=avexcashub1.qlogic.com ; 1.qlogic.com ; Received: from mail162-tx2 (localhost.localdomain [127.0.0.1]) by mail162-tx2 (MessageSwitch) id 1316712685878289_22446; Thu, 22 Sep 2011 17:31:25 +0000 (UTC) Received: from TX2EHSMHS045.bigfish.com (unknown [10.9.14.235]) by mail162-tx2.bigfish.com (Postfix) with ESMTP id C76329F004E; Thu, 22 Sep 2011 17:31:25 +0000 (UTC) Received: from avexcashub1.qlogic.com (198.70.193.64) by TX2EHSMHS045.bigfish.com (10.9.99.145) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 22 Sep 2011 17:31:18 +0000 Received: from avexmb1.qlogic.org ([fe80::9545:3a4f:c131:467d]) by avexcashub2.qlogic.org ([::1]) with mapi; Thu, 22 Sep 2011 10:31:17 -0700 From: David Somayajulu To: "freebsd-current@freebsd.org" , "freebsd-drivers@freebsd.org" Date: Thu, 22 Sep 2011 10:31:15 -0700 Thread-Topic: Recommended methods to upgrade firmware on HBAs Thread-Index: Acx5TW4ghoylo64wQjGQ7FegAezJ7g== Message-ID: <75E1A2A7D185F841A975979B0906BBA67BCCAB75FA@AVEXMB1.qlogic.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginatorOrg: qlogic.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Recommended methods to upgrade firmware on HBAs 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, 22 Sep 2011 17:46:33 -0000 Hi All, 1. What is the current recommended method for upgrading firmware for = HBAs? 2. Is there a mechanism wherein the firmware binary can be provided a= s a separate file, which is then made accessible to the corresponding devi= ce driver during device initialization? 3. Is there a restriction on the size of driver.ko file? If not, is i= t acceptable to provide the firmware as fw_file.c which is then compiled in= to the driver. Thanks david S. ________________________________ This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-current@FreeBSD.ORG Thu Sep 22 17:56:01 2011 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 BC7F7106566B; Thu, 22 Sep 2011 17:56:01 +0000 (UTC) (envelope-from david.somayajulu@qlogic.com) Received: from DB3EHSOBE003.bigfish.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by mx1.freebsd.org (Postfix) with ESMTP id 0D2A18FC12; Thu, 22 Sep 2011 17:56:00 +0000 (UTC) Received: from mail118-db3-R.bigfish.com (10.3.81.251) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.22; Thu, 22 Sep 2011 17:55:56 +0000 Received: from mail118-db3 (localhost.localdomain [127.0.0.1]) by mail118-db3-R.bigfish.com (Postfix) with ESMTP id 862651B38466; Thu, 22 Sep 2011 17:55:56 +0000 (UTC) X-SpamScore: 1 X-BigFish: VPS1(zzc85fhzz1202hzz8275bh8275dhz2ei2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:198.70.193.64; KIP:(null); UIP:(null); IPVD:NLI; H:avexcashub1.qlogic.com; RD:avexcashub2.qlogic.com; EFVD:NLI X-FB-SS: 0,0, Received-SPF: neutral (mail118-db3: 198.70.193.64 is neither permitted nor denied by domain of qlogic.com) client-ip=198.70.193.64; envelope-from=david.somayajulu@qlogic.com; helo=avexcashub1.qlogic.com ; 1.qlogic.com ; Received: from mail118-db3 (localhost.localdomain [127.0.0.1]) by mail118-db3 (MessageSwitch) id 1316714127740340_16124; Thu, 22 Sep 2011 17:55:27 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.254]) by mail118-db3.bigfish.com (Postfix) with ESMTP id A65D716B804F; Thu, 22 Sep 2011 17:55:27 +0000 (UTC) Received: from avexcashub1.qlogic.com (198.70.193.64) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 22 Sep 2011 17:55:26 +0000 Received: from avexmb1.qlogic.org ([fe80::9545:3a4f:c131:467d]) by avexcashub2.qlogic.org ([::1]) with mapi; Thu, 22 Sep 2011 10:55:24 -0700 From: David Somayajulu To: "freebsd-current@freebsd.org" , "freebsd-drivers@freebsd.org" Date: Thu, 22 Sep 2011 10:55:23 -0700 Thread-Topic: Choosing between DELAY(useconds) and pause() Thread-Index: Acx5UM0zVf9+7OruR7GrAyAHGLy0DA== Message-ID: <75E1A2A7D185F841A975979B0906BBA67BCCAB7609@AVEXMB1.qlogic.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginatorOrg: qlogic.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Choosing between DELAY(useconds) and pause() 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, 22 Sep 2011 17:56:01 -0000 It appears that the pause() function cannot be used in driver functions whi= ch are invoked early in the boot process. Is there is a kernel api which a = device driver can use to determine whether to use pause() or DELAY(), for d= elays which are say greater than 10hz - may be even 1 hz ? Cheers, David S. ________________________________ This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-current@FreeBSD.ORG Thu Sep 22 18:10:14 2011 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 067501065672 for ; Thu, 22 Sep 2011 18:10:14 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.c2i.net [212.247.154.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA4F8FC1B for ; Thu, 22 Sep 2011 18:10:13 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=G3me67YS4qRPZcaDO6kWttTShkFAyiMG89AbsUJ8MxU= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=uUbFkVXVqUkA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=qTTFKvau-as4jHQ0dEMA:9 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 182798277; Thu, 22 Sep 2011 20:10:11 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 22 Sep 2011 20:07:19 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <75E1A2A7D185F841A975979B0906BBA67BCCAB7609@AVEXMB1.qlogic.org> In-Reply-To: <75E1A2A7D185F841A975979B0906BBA67BCCAB7609@AVEXMB1.qlogic.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109222007.19182.hselasky@c2i.net> Cc: "freebsd-drivers@freebsd.org" , David Somayajulu Subject: Re: Choosing between DELAY(useconds) and pause() 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, 22 Sep 2011 18:10:14 -0000 On Thursday 22 September 2011 19:55:23 David Somayajulu wrote: > It appears that the pause() function cannot be used in driver functions > which are invoked early in the boot process. Is there is a kernel api > which a device driver can use to determine whether to use pause() or > DELAY(), for delays which are say greater than 10hz - may be even 1 hz ? Maybe you want to use something like this: if (cold) DELAY() else pause() In your code. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Sep 22 18:16:47 2011 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 C9662106566B; Thu, 22 Sep 2011 18:16:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4ACF68FC15; Thu, 22 Sep 2011 18:16:44 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p8MI9ABe030791 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 22 Sep 2011 12:09:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <75E1A2A7D185F841A975979B0906BBA67BCCAB7609@AVEXMB1.qlogic.org> Date: Thu, 22 Sep 2011 12:08:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <99C858FB-B215-4EFF-9EF1-09C5242091D4@bsdimp.com> References: <75E1A2A7D185F841A975979B0906BBA67BCCAB7609@AVEXMB1.qlogic.org> To: David Somayajulu X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Thu, 22 Sep 2011 12:09:11 -0600 (MDT) Cc: "freebsd-current@freebsd.org" , "freebsd-drivers@freebsd.org" Subject: Re: Choosing between DELAY(useconds) and pause() 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, 22 Sep 2011 18:16:47 -0000 if (cold) DELAY() else pause() On Sep 22, 2011, at 11:55 AM, David Somayajulu wrote: > It appears that the pause() function cannot be used in driver = functions which are invoked early in the boot process. Is there is a = kernel api which a device driver can use to determine whether to use = pause() or DELAY(), for delays which are say greater than 10hz - may be = even 1 hz ? >=20 > Cheers, > David S. >=20 >=20 > ________________________________ > This message and any attached documents contain information from = QLogic Corporation or its wholly-owned subsidiaries that may be = confidential. If you are not the intended recipient, you may not read, = copy, distribute, or use this information. If you have received this = transmission in error, please notify the sender immediately by reply = e-mail and then delete this message. > _______________________________________________ > freebsd-drivers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-drivers > To unsubscribe, send any mail to = "freebsd-drivers-unsubscribe@freebsd.org" >=20 >=20 From owner-freebsd-current@FreeBSD.ORG Thu Sep 22 18:40:49 2011 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 E7837106564A for ; Thu, 22 Sep 2011 18:40:49 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8D80E8FC08 for ; Thu, 22 Sep 2011 18:40:49 +0000 (UTC) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id p8MIemjJ089528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 11:40:48 -0700 (PDT) (envelope-from mj@feral.com) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.14.4/8.14.4/Submit) with ESMTP id p8MIelV8089525; Thu, 22 Sep 2011 11:40:47 -0700 (PDT) (envelope-from mj@feral.com) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Thu, 22 Sep 2011 11:40:47 -0700 (PDT) From: Matthew Jacob To: David Somayajulu In-Reply-To: <75E1A2A7D185F841A975979B0906BBA67BCCAB75FA@AVEXMB1.qlogic.org> Message-ID: References: <75E1A2A7D185F841A975979B0906BBA67BCCAB75FA@AVEXMB1.qlogic.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (ns1.feral.com [127.0.0.1]); Thu, 22 Sep 2011 11:40:48 -0700 (PDT) Cc: "freebsd-current@freebsd.org" , "freebsd-drivers@freebsd.org" Subject: Re: Recommended methods to upgrade firmware on HBAs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mj@feral.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, 22 Sep 2011 18:40:50 -0000 The current firmware(9) mechanism might work for you. The QLogic FC/SCSI cards in FreeBSD use that for loading firmware images to download to the cards, albeit to just load and reset, to update flash. This allows the drivers themselves to request updates. Note that the root filesystem has to be mounted for this mechanism to work. Other mechanisms include ioctl mechanisms as per what the LSI cards do via the mpiutil and mfiutil programs. On Thu, 22 Sep 2011, David Somayajulu wrote: > Hi All, > > 1. What is the current recommended method for upgrading firmware for HBAs? > > 2. Is there a mechanism wherein the firmware binary can be provided as a separate file, which is then made accessible to the corresponding device driver during device initialization? > > 3. Is there a restriction on the size of driver.ko file? If not, is it acceptable to provide the firmware as fw_file.c which is then compiled into the driver. > Thanks > david S. > > > ________________________________ > This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. > _______________________________________________ > 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 Sep 22 18:42:53 2011 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 C7E491065670 for ; Thu, 22 Sep 2011 18:42:53 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8CE6B8FC17 for ; Thu, 22 Sep 2011 18:42:53 +0000 (UTC) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id p8MIgq5g089540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Sep 2011 11:42:53 -0700 (PDT) (envelope-from mj@feral.com) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.14.4/8.14.4/Submit) with ESMTP id p8MIgqMh089537; Thu, 22 Sep 2011 11:42:52 -0700 (PDT) (envelope-from mj@feral.com) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Thu, 22 Sep 2011 11:42:52 -0700 (PDT) From: Matthew Jacob To: Matthew Jacob In-Reply-To: Message-ID: References: <75E1A2A7D185F841A975979B0906BBA67BCCAB75FA@AVEXMB1.qlogic.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (ns1.feral.com [127.0.0.1]); Thu, 22 Sep 2011 11:42:53 -0700 (PDT) Cc: "freebsd-current@freebsd.org" , "freebsd-drivers@freebsd.org" , David Somayajulu Subject: Re: Recommended methods to upgrade firmware on HBAs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mj@feral.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, 22 Sep 2011 18:42:53 -0000 > > The current firmware(9) mechanism might work for you. The QLogic FC/SCSI > cards in FreeBSD use that for loading firmware images to download to the > cards, albeit to just load and reset, to update flash. "not to update flash" (locations in flash where to put firmware are not documented by Qlogic) From owner-freebsd-current@FreeBSD.ORG Thu Sep 22 20:08:06 2011 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 1E7DD106564A; Thu, 22 Sep 2011 20:08:06 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id BA8898FC1F; Thu, 22 Sep 2011 20:08:04 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id p8MJX5sO037452; Thu, 22 Sep 2011 13:33:05 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id p8MJX5Op037451; Thu, 22 Sep 2011 13:33:05 -0600 (MDT) (envelope-from ken) Date: Thu, 22 Sep 2011 13:33:05 -0600 From: "Kenneth D. Merry" To: scsi@freebsd.org, current@freebsd.org Message-ID: <20110922193305.GA24939@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ibTvN161/egqYuK8" Content-Disposition: inline User-Agent: Mutt/1.4.2i Cc: Subject: SCSI descriptor sense changes, testing needed 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, 22 Sep 2011 20:08:06 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I have attached a set of patches against head that implement SCSI descriptor sense support for CAM. Descriptor sense is a new sense (SCSI error) format introduced in the SPC-3 spec in 2006. FreeBSD doesn't currently support it. Seagate's new 3TB SAS drives come with descriptor sense enabled by default, and it's possible that other newer drives do as well. Because all the sense key, additional sense code, and additional sense code qualifier fields are in different places, the CAM error recovery code will not do the right thing when it gets descriptor sense. These patches do bump up the size of struct scsi_sense_data, and so I have incremented CAM_VERSION as well. I have discussed this with re@, and it looks like we'll be putting the changes in before 9.0, so it ships with support for newer SCSI devices. A number of things have changed in these patches, but in particular, it would be good to test the following: - The sa(4) (SCSI tape) driver. The residual handling code, which looks at the sense data, has changed. - The Playstation 3 CDROM driver. - Firewire target mode. - umass devices with the NO_INQUIRY_EVPD quirk. Also, please let me know if you see any anomalies with the sense printing code. In the common cases the output should look identical to the old code, but in some cases it will be a little different. e.g.: # camcontrol inquiry da40 -v pass47: Fixed Direct Access SCSI-6 device pass47: Serial Number 9XK0GAJ70000S125XDNU pass47: 300.000MB/s transfers, Command Queueing Enabled (Seagate 3TB drive) # camcontrol modepage da40 -m 10 |grep D_SENSE D_SENSE: 1 (Descriptor sense is enabled) # camcontrol modepage da40 -m 15 -v (pass47:mps1:0:47:0): MODE SENSE(6). CDB: 1a 0 4f 0 ff 0 (pass47:mps1:0:47:0): CAM status: SCSI Status Error (pass47:mps1:0:47:0): SCSI status: Check Condition (pass47:mps1:0:47:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (pass47:mps1:0:47:0): Field Replaceable Unit: 1 (pass47:mps1:0:47:0): Command byte 2 bit 5 is invalid (pass47:mps1:0:47:0): Descriptor 0x80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 camcontrol: error sending mode sense command (The FRU and Sense Key Specific entries are on separate lines, and a vendor-specific sense descriptor is printed out in hex format.) Anyway, I'd appreciate any testing and feedback on these changes. As I said, they will probably be in 9.0, so if there are any issues it would be better to find them now. :) Thanks, Ken -- Kenneth Merry ken@FreeBSD.ORG --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="scsi_descriptor_sense.20110920.4.txt" Index: sbin/camcontrol/camcontrol.c =================================================================== --- sbin/camcontrol/camcontrol.c (revision 225710) +++ sbin/camcontrol/camcontrol.c (working copy) @@ -3810,15 +3810,14 @@ */ if ((sense_key == SSD_KEY_NOT_READY) && (asc == 0x04) && (ascq == 0x04)) { - if ((sense->extra_len >= 10) - && ((sense->sense_key_spec[0] & - SSD_SCS_VALID) != 0) + uint8_t sks[3]; + + if ((scsi_get_sks(sense, sks) == 0) && (quiet == 0)) { int val; u_int64_t percentage; - val = scsi_2btoul( - &sense->sense_key_spec[1]); + val = scsi_2btoul(&sks[1]); percentage = 10000 * val; fprintf(stdout, Index: share/misc/scsi_modes =================================================================== --- share/misc/scsi_modes (revision 225710) +++ share/misc/scsi_modes (working copy) @@ -50,19 +50,32 @@ # ALL DEVICE TYPES 0x0a "Control Mode Page" { - {Reserved} *t7 + {TST} t3 + {TMF_ONLY} t1 + {DPICZ} t1 + {D_SENSE} t1 + {GLTSD} t1 {RLEC} t1 {Queue Algorithm Modifier} t4 - {Reserved} *t2 - {QErr} t1 + {NUAR} t1 + {QErr} t2 {DQue} t1 {EECA} t1 - {Reserved} *t4 + {RAC} t1 + {UA_INTLCK_CTRL} t2 + {SWP} t1 {RAENP} t1 {UAAENP} t1 {EAENP} t1 - {Reserved} *i1 + {ATO} t1 + {TAS} t1 + {ATMPE} t1 + {RWWP} t1 + {Reserved} *t1 + {Autoload Mode} t3 {Ready AEN Holdoff Period} i2 + {Busy Timeout Period} i2 + {Extended Self-Test Completion Time} i2 } 0x02 "Disconnect-Reconnect Page" { Index: share/examples/scsi_target/scsi_cmds.c =================================================================== --- share/examples/scsi_target/scsi_cmds.c (revision 225710) +++ share/examples/scsi_target/scsi_cmds.c (working copy) @@ -242,22 +242,22 @@ u_int8_t asc, u_int8_t ascq) { struct initiator_state *istate; - struct scsi_sense_data *sense; + struct scsi_sense_data_fixed *sense; /* Set our initiator's istate */ istate = tcmd_get_istate(init_id); if (istate == NULL) return; istate->pending_ca |= CA_CMD_SENSE; /* XXX set instead of or? */ - sense = &istate->sense_data; + sense = (struct scsi_sense_data_fixed *)&istate->sense_data; bzero(sense, sizeof(*sense)); sense->error_code = SSD_CURRENT_ERROR; sense->flags = flags; sense->add_sense_code = asc; sense->add_sense_code_qual = ascq; sense->extra_len = - offsetof(struct scsi_sense_data, sense_key_spec[2]) - - offsetof(struct scsi_sense_data, extra_len); + offsetof(struct scsi_sense_data_fixed, sense_key_spec[2]) - + offsetof(struct scsi_sense_data_fixed, extra_len); /* Fill out the supplied CTIO */ if (ctio != NULL) { @@ -298,7 +298,7 @@ struct scsi_inquiry *inq; struct atio_descr *a_descr; struct initiator_state *istate; - struct scsi_sense_data *sense; + struct scsi_sense_data_fixed *sense; a_descr = (struct atio_descr *)atio->ccb_h.targ_descr; inq = (struct scsi_inquiry *)a_descr->cdb; @@ -310,7 +310,7 @@ * complain if EVPD or CMDDT is set. */ istate = tcmd_get_istate(ctio->init_id); - sense = &istate->sense_data; + sense = (struct scsi_sense_data_fixed *)&istate->sense_data; if ((inq->byte2 & SI_EVPD) != 0) { tcmd_illegal_req(atio, ctio); sense->sense_key_spec[0] = SSD_SCS_VALID | SSD_FIELDPTR_CMD | @@ -376,7 +376,7 @@ tcmd_req_sense(struct ccb_accept_tio *atio, struct ccb_scsiio *ctio) { struct scsi_request_sense *rsense; - struct scsi_sense_data *sense; + struct scsi_sense_data_fixed *sense; struct initiator_state *istate; size_t dlen; struct atio_descr *a_descr; @@ -385,7 +385,7 @@ rsense = (struct scsi_request_sense *)a_descr->cdb; istate = tcmd_get_istate(ctio->init_id); - sense = &istate->sense_data; + sense = (struct scsi_sense_data_fixed *)&istate->sense_data; if (debug) { cdb_debug(a_descr->cdb, "REQ SENSE from %u: ", atio->init_id); @@ -400,7 +400,7 @@ } bcopy(sense, ctio->data_ptr, sizeof(struct scsi_sense_data)); - dlen = offsetof(struct scsi_sense_data, extra_len) + + dlen = offsetof(struct scsi_sense_data_fixed, extra_len) + sense->extra_len + 1; ctio->dxfer_len = min(dlen, SCSI_CDB6_LEN(rsense->length)); ctio->ccb_h.flags |= CAM_DIR_IN | CAM_SEND_STATUS; @@ -482,7 +482,7 @@ c_descr = (struct ctio_descr *)ctio->ccb_h.targ_descr; /* Command needs to be decoded */ - if ((a_descr->flags & CAM_DIR_MASK) == CAM_DIR_RESV) { + if ((a_descr->flags & CAM_DIR_MASK) == CAM_DIR_BOTH) { if (debug) warnx("Calling rdwr_decode"); ret = tcmd_rdwr_decode(atio, ctio); Index: share/examples/scsi_target/scsi_target.c =================================================================== --- share/examples/scsi_target/scsi_target.c (revision 225710) +++ share/examples/scsi_target/scsi_target.c (working copy) @@ -651,7 +651,7 @@ * receiving this ATIO. */ if (atio->sense_len != 0) { - struct scsi_sense_data *sense; + struct scsi_sense_data_fixed *sense; if (debug) { warnx("ATIO with %u bytes sense received", @@ -825,9 +825,9 @@ /* If there is sense data, use it */ if (sense != 0) { - struct scsi_sense_data *sense; + struct scsi_sense_data_fixed *sense; - sense = &inot->sense_data; + sense = (struct scsi_sense_data_fixed *)&inot->sense_data; tcmd_sense(inot->initiator_id, NULL, sense->flags, sense->add_sense_code, sense->add_sense_code_qual); if (debug) Index: sys/powerpc/ps3/ps3cdrom.c =================================================================== --- sys/powerpc/ps3/ps3cdrom.c (revision 225710) +++ sys/powerpc/ps3/ps3cdrom.c (working copy) @@ -506,21 +506,19 @@ if (!ps3cdrom_decode_lv1_status(status, &sense_key, &asc, &ascq)) { - struct scsi_sense_data sense_data; CAM_DEBUG(ccb->ccb_h.path, CAM_DEBUG_TRACE, ("sense key 0x%02x asc 0x%02x ascq 0x%02x\n", sense_key, asc, ascq)); - bzero(&sense_data, sizeof(sense_data)); - sense_data.error_code = SSD_CURRENT_ERROR; - sense_data.flags |= sense_key; - sense_data.extra_len = 0xa; - sense_data.add_sense_code = asc; - sense_data.add_sense_code_qual = ascq; - ccb->csio.sense_len = sizeof(sense_data); - bcopy(&sense_data, &ccb->csio.sense_data, - ccb->csio.sense_len); + scsi_set_sense_data(&ccb->csio.sense_data, + /*sense_format*/ SSD_TYPE_NONE, + /*current_error*/ 1, + sense_key, + asc, + ascq, + SSD_ELEM_NONE); + ccb->csio.sense_len = SSD_FULL_SIZE; ccb->ccb_h.status = CAM_SCSI_STATUS_ERROR | CAM_AUTOSNS_VALID; } @@ -643,8 +641,6 @@ } if (err) { - struct scsi_sense_data sense_data; - device_printf(dev, "ATAPI command 0x%02x failed (%d)\n", cdb[0], err); @@ -653,11 +649,18 @@ xp->x_ccb = NULL; TAILQ_INSERT_TAIL(&sc->sc_free_xferq, xp, x_queue); - bzero(&sense_data, sizeof(sense_data)); - sense_data.error_code = SSD_CURRENT_ERROR; - sense_data.flags |= SSD_KEY_ILLEGAL_REQUEST; - ccb->csio.sense_len = sizeof(sense_data); - bcopy(&sense_data, &ccb->csio.sense_data, ccb->csio.sense_len); + bzero(&ccb->csio.sense_data, sizeof(ccb->csio.sense_data)); + /* Invalid field in parameter list */ + scsi_set_sense_data(&ccb->csio.sense_data, + /*sense_format*/ SSD_TYPE_NONE, + /*current_error*/ 1, + /*sense_key*/ SSD_KEY_ILLEGAL_REQUEST, + /*asc*/ 0x26, + /*ascq*/ 0x00, + SSD_ELEM_NONE); + + ccb->csio.sense_len = SSD_FULL_SIZE; + ccb->csio.scsi_status = SCSI_STATUS_CHECK_COND; ccb->ccb_h.status = CAM_SCSI_STATUS_ERROR | CAM_AUTOSNS_VALID; xpt_done(ccb); } else { Index: sys/cam/cam_periph.c =================================================================== --- sys/cam/cam_periph.c (revision 225710) +++ sys/cam/cam_periph.c (working copy) @@ -1085,7 +1085,6 @@ union ccb *saved_ccb = (union ccb *)done_ccb->ccb_h.saved_ccb_ptr; cam_status status; int frozen = 0; - u_int sense_key; int depth = done_ccb->ccb_h.recovery_depth; status = done_ccb->ccb_h.status; @@ -1101,14 +1100,16 @@ switch (status) { case CAM_REQ_CMP: { + int error_code, sense_key, asc, ascq; + + scsi_extract_sense(&saved_ccb->csio.sense_data, &error_code, + &sense_key, &asc, &ascq); /* * If we manually retrieved sense into a CCB and got * something other than "NO SENSE" send the updated CCB * back to the client via xpt_done() to be processed via * the error recovery code again. */ - sense_key = saved_ccb->csio.sense_data.flags; - sense_key &= SSD_KEY; if (sense_key != SSD_KEY_NO_SENSE) { saved_ccb->ccb_h.status |= CAM_AUTOSNS_VALID; Index: sys/cam/cam_ccb.h =================================================================== --- sys/cam/cam_ccb.h (revision 225710) +++ sys/cam/cam_ccb.h (working copy) @@ -539,7 +539,7 @@ /* * Definitions for the path inquiry CCB fields. */ -#define CAM_VERSION 0x15 /* Hex value for current version */ +#define CAM_VERSION 0x16 /* Hex value for current version */ typedef enum { PI_MDP_ABLE = 0x80, /* Supports MDP message */ Index: sys/cam/scsi/scsi_all.h =================================================================== --- sys/cam/scsi/scsi_all.h (revision 225710) +++ sys/cam/scsi/scsi_all.h (working copy) @@ -25,6 +25,7 @@ #define _SCSI_SCSI_ALL_H 1 #include +#include #ifdef _KERNEL /* @@ -171,9 +172,9 @@ { u_int8_t opcode; u_int8_t byte2; -#define SI_EVPD 0x01 +#define SI_EVPD 0x01 +#define SI_CMDDT 0x02 u_int8_t page_code; - u_int8_t reserved; u_int8_t length; u_int8_t control; }; @@ -200,7 +201,9 @@ #define SMS_PAGE_CTRL_CHANGEABLE 0x40 #define SMS_PAGE_CTRL_DEFAULT 0x80 #define SMS_PAGE_CTRL_SAVED 0xC0 - u_int8_t unused; + u_int8_t subpage; +#define SMS_SUBPAGE_PAGE_0 0x00 +#define SMS_SUBPAGE_ALL 0xff u_int8_t length; u_int8_t control; }; @@ -209,8 +212,10 @@ { u_int8_t opcode; u_int8_t byte2; /* same bits as small version */ +#define SMS10_LLBAA 0x10 u_int8_t page; /* same bits as small version */ - u_int8_t unused[4]; + u_int8_t subpage; + u_int8_t unused[3]; u_int8_t length[2]; u_int8_t control; }; @@ -263,6 +268,120 @@ u_int8_t block_len[3]; }; +struct scsi_per_res_in +{ + u_int8_t opcode; + u_int8_t action; +#define SPRI_RK 0x00 +#define SPRI_RR 0x01 +#define SPRI_RC 0x02 +#define SPRI_RS 0x03 + u_int8_t reserved[5]; + u_int8_t length[2]; + u_int8_t control; +}; + +struct scsi_per_res_in_header +{ + u_int8_t generation[4]; + u_int8_t length[4]; +}; + +struct scsi_per_res_key +{ + u_int8_t key[8]; +}; + +struct scsi_per_res_in_keys +{ + struct scsi_per_res_in_header header; + struct scsi_per_res_key keys[0]; +}; + +struct scsi_per_res_cap +{ + uint8_t length[2]; + uint8_t flags1; +#define SPRI_CRH 0x10 +#define SPRI_SIP_C 0x08 +#define SPRI_ATP_C 0x04 +#define SPRI_PTPL_C 0x01 + uint8_t flags2; +#define SPRI_TMV 0x80 +#define SPRI_PTPL_A 0x01 + uint8_t type_mask[2]; +#define SPRI_TM_WR_EX_AR 0x8000 +#define SPRI_TM_EX_AC_RO 0x4000 +#define SPRI_TM_WR_EX_RO 0x2000 +#define SPRI_TM_EX_AC 0x0800 +#define SPRI_TM_WR_EX 0x0200 +#define SPRI_TM_EX_AC_AR 0x0001 + uint8_t reserved[2]; +}; + +struct scsi_per_res_in_rsrv_data +{ + uint8_t reservation[8]; + uint8_t obsolete1[4]; + uint8_t reserved; + uint8_t scopetype; +#define SPRT_WE 0x01 +#define SPRT_EA 0x03 +#define SPRT_WERO 0x05 +#define SPRT_EARO 0x06 +#define SPRT_WEAR 0x07 +#define SPRT_EAAR 0x08 + uint8_t obsolete2[2]; +}; + +struct scsi_per_res_in_rsrv +{ + struct scsi_per_res_in_header header; + struct scsi_per_res_in_rsrv_data data; +}; + +struct scsi_per_res_out +{ + u_int8_t opcode; + u_int8_t action; +#define SPRO_REGISTER 0x00 +#define SPRO_RESERVE 0x01 +#define SPRO_RELEASE 0x02 +#define SPRO_CLEAR 0x03 +#define SPRO_PREEMPT 0x04 +#define SPRO_PRE_ABO 0x05 +#define SPRO_REG_IGNO 0x06 +#define SPRO_REG_MOVE 0x07 +#define SPRO_ACTION_MASK 0x1f + u_int8_t scope_type; +#define SPR_SCOPE_MASK 0xf0 +#define SPR_LU_SCOPE 0x00 +#define SPR_TYPE_MASK 0x0f +#define SPR_TYPE_WR_EX 0x01 +#define SPR_TYPE_EX_AC 0x03 +#define SPR_TYPE_WR_EX_RO 0x05 +#define SPR_TYPE_EX_AC_RO 0x06 +#define SPR_TYPE_WR_EX_AR 0x07 +#define SPR_TYPE_EX_AC_AR 0x08 + u_int8_t reserved[2]; + u_int8_t length[4]; + u_int8_t control; +}; + +struct scsi_per_res_out_parms +{ + struct scsi_per_res_key res_key; + u_int8_t serv_act_res_key[8]; + u_int8_t obsolete1[4]; + u_int8_t flags; +#define SPR_SPEC_I_PT 0x08 +#define SPR_ALL_TG_PT 0x04 +#define SPR_APTPL 0x01 + u_int8_t reserved1; + u_int8_t obsolete2[2]; +}; + + struct scsi_log_sense { u_int8_t opcode; @@ -337,7 +456,16 @@ u_int8_t page_code; u_int8_t page_length; u_int8_t rlec; -#define SCB_RLEC 0x01 /*Report Log Exception Cond*/ +#define SCP_RLEC 0x01 /*Report Log Exception Cond*/ +#define SCP_GLTSD 0x02 /*Global Logging target + save disable */ +#define SCP_DSENSE 0x04 /*Descriptor Sense */ +#define SCP_DPICZ 0x08 /*Disable Prot. Info Check + if Prot. Field is Zero */ +#define SCP_TMF_ONLY 0x10 /*TM Functions Only*/ +#define SCP_TST_MASK 0xE0 /*Task Set Type Mask*/ +#define SCP_TST_ONE 0x00 /*One Task Set*/ +#define SCP_TST_SEPARATE 0x20 /*Separate Task Sets*/ u_int8_t queue_flags; #define SCP_QUEUE_ALG_MASK 0xF0 #define SCP_QUEUE_ALG_RESTRICTED 0x00 @@ -368,6 +496,41 @@ u_int8_t max_prefetch_ceil[2]; }; +/* + * XXX KDM + * Updated version of the cache page, as of SBC. Update this to SBC-3 and + * rationalize the two. + */ +struct scsi_caching_page { + uint8_t page_code; +#define SMS_CACHING_PAGE 0x08 + uint8_t page_length; + uint8_t flags1; +#define SCP_IC 0x80 +#define SCP_ABPF 0x40 +#define SCP_CAP 0x20 +#define SCP_DISC 0x10 +#define SCP_SIZE 0x08 +#define SCP_WCE 0x04 +#define SCP_MF 0x02 +#define SCP_RCD 0x01 + uint8_t ret_priority; + uint8_t disable_pf_transfer_len[2]; + uint8_t min_prefetch[2]; + uint8_t max_prefetch[2]; + uint8_t max_pf_ceiling[2]; + uint8_t flags2; +#define SCP_FSW 0x80 +#define SCP_LBCSS 0x40 +#define SCP_DRA 0x20 +#define SCP_VS1 0x10 +#define SCP_VS2 0x08 + uint8_t cache_segments; + uint8_t cache_seg_size[2]; + uint8_t reserved; + uint8_t non_cache_seg_size[3]; +}; + struct scsi_info_exceptions_page { u_int8_t page_code; #define SIEP_PAGE_SAVABLE 0x80 /* Page is savable */ @@ -406,20 +569,49 @@ { u_int8_t opcode; u_int8_t byte2; - u_int8_t unused[2]; - u_int8_t length; +#define SR_EXTENT 0x01 +#define SR_ID_MASK 0x0e +#define SR_3RDPTY 0x10 +#define SR_LUN_MASK 0xe0 + u_int8_t resv_id; + u_int8_t length[2]; u_int8_t control; }; +struct scsi_reserve_10 { + uint8_t opcode; + uint8_t byte2; +#define SR10_3RDPTY 0x10 +#define SR10_LONGID 0x02 +#define SR10_EXTENT 0x01 + uint8_t resv_id; + uint8_t thirdparty_id; + uint8_t reserved[3]; + uint8_t length[2]; + uint8_t control; +}; + + struct scsi_release { u_int8_t opcode; u_int8_t byte2; - u_int8_t unused[2]; + u_int8_t resv_id; + u_int8_t unused[1]; u_int8_t length; u_int8_t control; }; +struct scsi_release_10 { + uint8_t opcode; + uint8_t byte2; + uint8_t resv_id; + uint8_t thirdparty_id; + uint8_t reserved[3]; + uint8_t length[2]; + uint8_t control; +}; + struct scsi_prevent { u_int8_t opcode; @@ -435,13 +627,61 @@ { u_int8_t opcode; u_int8_t byte2; +#define SSC_IMMED 0x02 +#define SSC_RELADR 0x01 u_int8_t begin_lba[4]; u_int8_t reserved; u_int8_t lb_count[2]; u_int8_t control; }; +struct scsi_sync_cache_16 +{ + uint8_t opcode; + uint8_t byte2; + uint8_t begin_lba[8]; + uint8_t lb_count[4]; + uint8_t reserved; + uint8_t control; +}; +struct scsi_format { + uint8_t opcode; + uint8_t byte2; +#define SF_LONGLIST 0x20 +#define SF_FMTDATA 0x10 +#define SF_CMPLIST 0x08 +#define SF_FORMAT_MASK 0x07 +#define SF_FORMAT_BLOCK 0x00 +#define SF_FORMAT_LONG_BLOCK 0x03 +#define SF_FORMAT_BFI 0x04 +#define SF_FORMAT_PHYS 0x05 + uint8_t vendor; + uint8_t interleave[2]; + uint8_t control; +}; + +struct scsi_format_header_short { + uint8_t reserved; +#define SF_DATA_FOV 0x80 +#define SF_DATA_DPRY 0x40 +#define SF_DATA_DCRT 0x20 +#define SF_DATA_STPF 0x10 +#define SF_DATA_IP 0x08 +#define SF_DATA_DSP 0x04 +#define SF_DATA_IMMED 0x02 +#define SF_DATA_VS 0x01 + uint8_t byte2; + uint8_t defect_list_len[2]; +}; + +struct scsi_format_header_long { + uint8_t reserved; + uint8_t byte2; + uint8_t reserved2[2]; + uint8_t defect_list_len[4]; +}; + struct scsi_changedef { u_int8_t opcode; @@ -459,6 +699,7 @@ u_int8_t byte2; #define RWB_MODE 0x07 #define RWB_MODE_HDR_DATA 0x00 +#define RWB_MODE_VENDOR 0x01 #define RWB_MODE_DATA 0x02 #define RWB_MODE_DOWNLOAD 0x04 #define RWB_MODE_DOWNLOAD_SAVE 0x05 @@ -529,6 +770,40 @@ u_int8_t control; }; +struct scsi_write_verify_10 +{ + uint8_t opcode; + uint8_t byte2; +#define SWV_BYTCHK 0x02 +#define SWV_DPO 0x10 +#define SWV_WRPROECT_MASK 0xe0 + uint8_t addr[4]; + uint8_t group; + uint8_t length[2]; + uint8_t control; +}; + +struct scsi_write_verify_12 +{ + uint8_t opcode; + uint8_t byte2; + uint8_t addr[4]; + uint8_t length[4]; + uint8_t group; + uint8_t control; +}; + +struct scsi_write_verify_16 +{ + uint8_t opcode; + uint8_t byte2; + uint8_t addr[8]; + uint8_t length[4]; + uint8_t group; + uint8_t control; +}; + + struct scsi_start_stop_unit { u_int8_t opcode; @@ -538,6 +813,14 @@ u_int8_t how; #define SSS_START 0x01 #define SSS_LOEJ 0x02 +#define SSS_PC_MASK 0xf0 +#define SSS_PC_START_VALID 0x00 +#define SSS_PC_ACTIVE 0x10 +#define SSS_PC_IDLE 0x20 +#define SSS_PC_STANDBY 0x30 +#define SSS_PC_LU_CONTROL 0x70 +#define SSS_PC_FORCE_IDLE_0 0xa0 +#define SSS_PC_FORCE_STANDBY_0 0xb0 u_int8_t control; }; @@ -562,6 +845,18 @@ u_int8_t control; }; +struct scsi_maintenance_in +{ + uint8_t opcode; + uint8_t byte2; +#define SERVICE_ACTION_MASK 0x1f +#define SA_RPRT_TRGT_GRP 0x0a + uint8_t reserved[4]; + uint8_t length[4]; + uint8_t reserved1; + uint8_t control; +}; + struct ata_pass_16 { u_int8_t opcode; u_int8_t protocol; @@ -607,6 +902,7 @@ #define READ_10 0x28 #define WRITE_10 0x2A #define POSITION_TO_ELEMENT 0x2B +#define WRITE_VERIFY_10 0x2E #define SYNCHRONIZE_CACHE 0x35 #define READ_DEFECT_DATA_10 0x37 #define WRITE_BUFFER 0x3B @@ -615,10 +911,16 @@ #define LOG_SELECT 0x4C #define LOG_SENSE 0x4D #define MODE_SELECT_10 0x55 +#define RESERVE_10 0x56 +#define RELEASE_10 0x57 #define MODE_SENSE_10 0x5A +#define PERSISTENT_RES_IN 0x5E +#define PERSISTENT_RES_OUT 0x5F #define ATA_PASS_16 0x85 #define READ_16 0x88 #define WRITE_16 0x8A +#define WRITE_VERIFY_16 0x8E +#define SYNCHRONIZE_CACHE_16 0x91 #define SERVICE_ACTION_IN 0x9E #define REPORT_LUNS 0xA0 #define ATA_PASS_12 0xA1 @@ -627,6 +929,7 @@ #define MOVE_MEDIUM 0xA5 #define READ_12 0xA8 #define WRITE_12 0xAA +#define WRITE_VERIFY_12 0xAE #define READ_ELEMENT_STATUS 0xB8 /* Maintenance In Service Action Codes */ @@ -737,10 +1040,12 @@ u_int8_t response_format; #define SID_AENC 0x80 #define SID_TrmIOP 0x40 +#define SID_NormACA 0x20 +#define SID_HiSup 0x10 u_int8_t additional_length; #define SID_ADDITIONAL_LENGTH(iqd) \ ((iqd)->additional_length + \ - offsetof(struct scsi_inquiry_data, additional_length) + 1) + __offsetof(struct scsi_inquiry_data, additional_length) + 1) u_int8_t spc3_flags; #define SPC3_SID_PROTECT 0x01 #define SPC3_SID_3PC 0x08 @@ -750,6 +1055,7 @@ #define SPC3_SID_ACC 0x40 #define SPC3_SID_SCCS 0x80 u_int8_t spc2_flags; +#define SPC2_SID_ADDR16 0x01 #define SPC2_SID_MChngr 0x08 #define SPC2_SID_MultiP 0x10 #define SPC2_SID_EncServ 0x40 @@ -809,6 +1115,10 @@ u_int8_t vendor_specific1[SID_VENDOR_SPECIFIC_1_SIZE]; }; +/* + * This structure is more suited to initiator operation, because the + * maximum number of supported pages is already allocated. + */ struct scsi_vpd_supported_page_list { u_int8_t device; @@ -852,11 +1162,11 @@ u_int8_t device; u_int8_t page_code; #define SVPD_DEVICE_ID 0x83 -#define SVPD_DEVICE_ID_MAX_SIZE 0xffff -#define SVPD_DEVICE_ID_HDR_LEN 4 -#define SVPD_DEVICE_ID_DESC_HDR_LEN 4 +#define SVPD_DEVICE_ID_MAX_SIZE 252 +#define SVPD_DEVICE_ID_HDR_LEN \ + __offsetof(struct scsi_vpd_device_id, desc_list) u_int8_t length[2]; - u_int8_t desc_list[0]; + u_int8_t desc_list[]; }; struct scsi_vpd_id_descriptor @@ -872,11 +1182,13 @@ #define SVPD_ID_PROTO_SHIFT 4 #define SVPD_ID_CODESET_BINARY 0x01 #define SVPD_ID_CODESET_ASCII 0x02 +#define SVPD_ID_CODESET_MASK 0x0f u_int8_t id_type; #define SVPD_ID_PIV 0x80 #define SVPD_ID_ASSOC_LUN 0x00 #define SVPD_ID_ASSOC_PORT 0x10 #define SVPD_ID_ASSOC_TARGET 0x20 +#define SVPD_ID_ASSOC_MASK 0x30 #define SVPD_ID_TYPE_VENDOR 0x00 #define SVPD_ID_TYPE_T10 0x01 #define SVPD_ID_TYPE_EUI64 0x02 @@ -889,7 +1201,9 @@ #define SVPD_ID_TYPE_MASK 0x0f u_int8_t reserved; u_int8_t length; - u_int8_t identifier[0]; +#define SVPD_DEVICE_ID_DESC_HDR_LEN \ + __offsetof(struct scsi_vpd_id_descriptor, identifier) + u_int8_t identifier[]; }; struct scsi_vpd_id_t10 @@ -990,12 +1304,23 @@ uint8_t name_string[256]; }; +struct scsi_service_action_in +{ + uint8_t opcode; + uint8_t service_action; + uint8_t action_dependent[13]; + uint8_t control; +}; + struct scsi_read_capacity { u_int8_t opcode; u_int8_t byte2; +#define SRC_RELADR 0x01 u_int8_t addr[4]; - u_int8_t unused[3]; + u_int8_t unused[2]; + u_int8_t pmi; +#define SRC_PMI 0x01 u_int8_t control; }; @@ -1038,18 +1363,11 @@ uint8_t control; }; -struct scsi_report_luns_data { - u_int8_t length[4]; /* length of LUN inventory, in bytes */ - u_int8_t reserved[4]; /* unused */ - /* - * LUN inventory- we only support the type zero form for now. - */ - struct { - u_int8_t lundata[8]; - } luns[0]; -}; +struct scsi_report_luns_lundata { + uint8_t lundata[8]; #define RPL_LUNDATA_PERIPH_BUS_MASK 0x3f #define RPL_LUNDATA_FLAT_LUN_MASK 0x3f +#define RPL_LUNDATA_FLAT_LUN_BITS 0x06 #define RPL_LUNDATA_LUN_TARG_MASK 0x3f #define RPL_LUNDATA_LUN_BUS_MASK 0xe0 #define RPL_LUNDATA_LUN_LUN_MASK 0x1f @@ -1062,7 +1380,17 @@ #define RPL_LUNDATA_ATYP_FLAT 0x40 #define RPL_LUNDATA_ATYP_LUN 0x80 #define RPL_LUNDATA_ATYP_EXTLUN 0xc0 +}; +struct scsi_report_luns_data { + u_int8_t length[4]; /* length of LUN inventory, in bytes */ + u_int8_t reserved[4]; /* unused */ + /* + * LUN inventory- we only support the type zero form for now. + */ + struct scsi_report_luns_lundata luns[0]; +}; + struct scsi_target_group { uint8_t opcode; @@ -1103,6 +1431,9 @@ uint8_t target_port_group[2]; uint8_t reserved; uint8_t status; +#define TPG_UNAVLBL 0 +#define TPG_SET_BY_STPG 0x01 +#define TPG_IMPLICIT 0x02 uint8_t vendor_specific; uint8_t target_port_count; struct scsi_target_port_descriptor descriptors[]; @@ -1122,8 +1453,49 @@ }; +typedef enum { + SSD_TYPE_NONE, + SSD_TYPE_FIXED, + SSD_TYPE_DESC +} scsi_sense_data_type; + +typedef enum { + SSD_ELEM_NONE, + SSD_ELEM_SKIP, + SSD_ELEM_DESC, + SSD_ELEM_SKS, + SSD_ELEM_COMMAND, + SSD_ELEM_INFO, + SSD_ELEM_FRU, + SSD_ELEM_STREAM, + SSD_ELEM_MAX +} scsi_sense_elem_type; + + struct scsi_sense_data { + uint8_t error_code; + /* + * SPC-4 says that the maximum length of sense data is 252 bytes. + * So this structure is exactly 252 bytes log. + */ +#define SSD_FULL_SIZE 252 + uint8_t sense_buf[SSD_FULL_SIZE - 1]; + /* + * XXX KDM is this still a reasonable minimum size? + */ +#define SSD_MIN_SIZE 18 + /* + * Maximum value for the extra_len field in the sense data. + */ +#define SSD_EXTRA_MAX 244 +}; + +/* + * Fixed format sense data. + */ +struct scsi_sense_data_fixed +{ u_int8_t error_code; #define SSD_ERRCODE 0x7F #define SSD_CURRENT_ERROR 0x70 @@ -1147,7 +1519,7 @@ #define SSD_KEY_EQUAL 0x0c #define SSD_KEY_VOLUME_OVERFLOW 0x0d #define SSD_KEY_MISCOMPARE 0x0e -#define SSD_KEY_RESERVED 0x0f +#define SSD_KEY_COMPLETED 0x0f #define SSD_ILI 0x20 #define SSD_EOM 0x40 #define SSD_FILEMARK 0x80 @@ -1162,11 +1534,304 @@ #define SSD_FIELDPTR_CMD 0x40 #define SSD_BITPTR_VALID 0x08 #define SSD_BITPTR_VALUE 0x07 -#define SSD_MIN_SIZE 18 u_int8_t extra_bytes[14]; -#define SSD_FULL_SIZE sizeof(struct scsi_sense_data) }; +/* + * Descriptor format sense data definitions. + * Introduced in SPC-3. + */ +struct scsi_sense_data_desc +{ + uint8_t error_code; +#define SSD_DESC_CURRENT_ERROR 0x72 +#define SSD_DESC_DEFERRED_ERROR 0x73 + uint8_t sense_key; + uint8_t add_sense_code; + uint8_t add_sense_code_qual; + uint8_t reserved[3]; + /* + * Note that SPC-4, section 4.5.2.1 says that the extra_len field + * must be less than or equal to 244. + */ + uint8_t extra_len; + uint8_t sense_desc[0]; +}; + +struct scsi_sense_desc_header +{ + uint8_t desc_type; + uint8_t length; +}; +/* + * The information provide in the Information descriptor is device type or + * command specific information, and defined in a command standard. + * + * Note that any changes to the field names or positions in this structure, + * even reserved fields, should be accompanied by an examination of the + * code in ctl_set_sense() that uses them. + * + * Maximum descriptors allowed: 1 (as of SPC-4) + */ +struct scsi_sense_info +{ + uint8_t desc_type; +#define SSD_DESC_INFO 0x00 + uint8_t length; + uint8_t byte2; +#define SSD_INFO_VALID 0x80 + uint8_t reserved; + uint8_t info[8]; +}; + +/* + * Command-specific information depends on the command for which the + * reported condition occured. + * + * Note that any changes to the field names or positions in this structure, + * even reserved fields, should be accompanied by an examination of the + * code in ctl_set_sense() that uses them. + * + * Maximum descriptors allowed: 1 (as of SPC-4) + */ +struct scsi_sense_command +{ + uint8_t desc_type; +#define SSD_DESC_COMMAND 0x01 + uint8_t length; + uint8_t reserved[2]; + uint8_t command_info[8]; +}; + +/* + * Sense key specific descriptor. The sense key specific data format + * depends on the sense key in question. + * + * Maximum descriptors allowed: 1 (as of SPC-4) + */ +struct scsi_sense_sks +{ + uint8_t desc_type; +#define SSD_DESC_SKS 0x02 + uint8_t length; + uint8_t reserved1[2]; + uint8_t sense_key_spec[3]; +#define SSD_SKS_VALID 0x80 + uint8_t reserved2; +}; + +/* + * This is used for the Illegal Request sense key (0x05) only. + */ +struct scsi_sense_sks_field +{ + uint8_t byte0; +#define SSD_SKS_FIELD_VALID 0x80 +#define SSD_SKS_FIELD_CMD 0x40 +#define SSD_SKS_BPV 0x08 +#define SSD_SKS_BIT_VALUE 0x07 + uint8_t field[2]; +}; + + +/* + * This is used for the Hardware Error (0x04), Medium Error (0x03) and + * Recovered Error (0x01) sense keys. + */ +struct scsi_sense_sks_retry +{ + uint8_t byte0; +#define SSD_SKS_RETRY_VALID 0x80 + uint8_t actual_retry_count[2]; +}; + +/* + * Used with the NO Sense (0x00) or Not Ready (0x02) sense keys. + */ +struct scsi_sense_sks_progress +{ + uint8_t byte0; +#define SSD_SKS_PROGRESS_VALID 0x80 + uint8_t progress[2]; +#define SSD_SKS_PROGRESS_DENOM 0x10000 +}; + +/* + * Used with the Copy Aborted (0x0a) sense key. + */ +struct scsi_sense_sks_segment +{ + uint8_t byte0; +#define SSD_SKS_SEGMENT_VALID 0x80 +#define SSD_SKS_SEGMENT_SD 0x20 +#define SSD_SKS_SEGMENT_BPV 0x08 +#define SSD_SKS_SEGMENT_BITPTR 0x07 + uint8_t field[2]; +}; + +/* + * Used with the Unit Attention (0x06) sense key. + * + * This is currently used to indicate that the unit attention condition + * queue has overflowed (when the overflow bit is set). + */ +struct scsi_sense_sks_overflow +{ + uint8_t byte0; +#define SSD_SKS_OVERFLOW_VALID 0x80 +#define SSD_SKS_OVERFLOW_SET 0x01 + uint8_t reserved[2]; +}; + +/* + * This specifies which component is associated with the sense data. There + * is no standard meaning for the fru value. + * + * Maximum descriptors allowed: 1 (as of SPC-4) + */ +struct scsi_sense_fru +{ + uint8_t desc_type; +#define SSD_DESC_FRU 0x03 + uint8_t length; + uint8_t reserved; + uint8_t fru; +}; + +/* + * Used for Stream commands, defined in SSC-4. + * + * Maximum descriptors allowed: 1 (as of SPC-4) + */ + +struct scsi_sense_stream +{ + uint8_t desc_type; +#define SSD_DESC_STREAM 0x04 + uint8_t length; + uint8_t reserved; + uint8_t byte3; +#define SSD_DESC_STREAM_FM 0x80 +#define SSD_DESC_STREAM_EOM 0x40 +#define SSD_DESC_STREAM_ILI 0x20 +}; + +/* + * Used for Block commands, defined in SBC-3. + * + * This is currently (as of SBC-3) only used for the Incorrect Length + * Indication (ILI) bit, which says that the data length requested in the + * READ LONG or WRITE LONG command did not match the length of the logical + * block. + * + * Maximum descriptors allowed: 1 (as of SPC-4) + */ +struct scsi_sense_block +{ + uint8_t desc_type; +#define SSD_DESC_BLOCK 0x05 + uint8_t length; + uint8_t reserved; + uint8_t byte3; +#define SSD_DESC_BLOCK_ILI 0x20 +}; + +/* + * Used for Object-Based Storage Devices (OSD-3). + * + * Maximum descriptors allowed: 1 (as of SPC-4) + */ +struct scsi_sense_osd_objid +{ + uint8_t desc_type; +#define SSD_DESC_OSD_OBJID 0x06 + uint8_t length; + uint8_t reserved[6]; + /* + * XXX KDM provide the bit definitions here? There are a lot of + * them, and we don't have an OSD driver yet. + */ + uint8_t not_init_cmds[4]; + uint8_t completed_cmds[4]; + uint8_t partition_id[8]; + uint8_t object_id[8]; +}; + +/* + * Used for Object-Based Storage Devices (OSD-3). + * + * Maximum descriptors allowed: 1 (as of SPC-4) + */ +struct scsi_sense_osd_integrity +{ + uint8_t desc_type; +#define SSD_DESC_OSD_INTEGRITY 0x07 + uint8_t length; + uint8_t integ_check_val[32]; +}; + +/* + * Used for Object-Based Storage Devices (OSD-3). + * + * Maximum descriptors allowed: 1 (as of SPC-4) + */ +struct scsi_sense_osd_attr_id +{ + uint8_t desc_type; +#define SSD_DESC_OSD_ATTR_ID 0x08 + uint8_t length; + uint8_t reserved[2]; + uint8_t attr_desc[0]; +}; + +/* + * Used with Sense keys No Sense (0x00) and Not Ready (0x02). + * + * Maximum descriptors allowed: 32 (as of SPC-4) + */ +struct scsi_sense_progress +{ + uint8_t desc_type; +#define SSD_DESC_PROGRESS 0x0a + uint8_t length; + uint8_t sense_key; + uint8_t add_sense_code; + uint8_t add_sense_code_qual; + uint8_t reserved; + uint8_t progress[2]; +}; + +/* + * This is typically forwarded as the result of an EXTENDED COPY command. + * + * Maximum descriptors allowed: 2 (as of SPC-4) + */ +struct scsi_sense_forwarded +{ + uint8_t desc_type; +#define SSD_DESC_FORWARDED 0x0c + uint8_t length; + uint8_t byte2; +#define SSD_FORWARDED_FSDT 0x80 +#define SSD_FORWARDED_SDS_MASK 0x0f +#define SSD_FORWARDED_SDS_UNK 0x00 +#define SSD_FORWARDED_SDS_EXSRC 0x01 +#define SSD_FORWARDED_SDS_EXDST 0x02 +}; + +/* + * Vendor-specific sense descriptor. The desc_type field will be in the + * range bewteen MIN and MAX inclusive. + */ +struct scsi_sense_vendor +{ + uint8_t desc_type; +#define SSD_DESC_VENDOR_MIN 0x80 +#define SSD_DESC_VENDOR_MAX 0xff + uint8_t length; + uint8_t data[0]; +}; + struct scsi_mode_header_6 { u_int8_t data_length; /* Sense data length */ @@ -1187,9 +1852,20 @@ struct scsi_mode_page_header { u_int8_t page_code; +#define SMPH_PS 0x80 +#define SMPH_SPF 0x40 +#define SMPH_PC_MASK 0x3f u_int8_t page_length; }; +struct scsi_mode_page_header_sp +{ + uint8_t page_code; + uint8_t subpage; + uint8_t page_length[2]; +}; + + struct scsi_mode_blk_desc { u_int8_t density; @@ -1292,6 +1968,81 @@ struct scsi_inquiry_data *inq_data, u_int32_t sense_flags); const char * scsi_status_string(struct ccb_scsiio *csio); + +uint8_t *scsi_find_desc(struct scsi_sense_data_desc *sense, uint8_t desc_type); +void scsi_set_sense_data(struct scsi_sense_data *sense_data, + scsi_sense_data_type sense_format, int current_error, + int sense_key, int asc, int ascq, ...) ; +void scsi_set_sense_data_va(struct scsi_sense_data *sense_data, + scsi_sense_data_type sense_format, + int current_error, int sense_key, int asc, + int ascq, va_list ap); +int scsi_asc_ascq_valid(struct scsi_sense_data *sense, int ascq); +int scsi_get_sense_info(struct scsi_sense_data *sense_data, uint8_t info_type, + uint64_t *info, int64_t *signed_info); +int scsi_get_sks(struct scsi_sense_data *sense_data, uint8_t *sks); +int scsi_get_block_info(struct scsi_sense_data *sense_data, + struct scsi_inquiry_data *inq_data, + uint8_t *block_bits); +int scsi_get_stream_info(struct scsi_sense_data *sense_data, + struct scsi_inquiry_data *inq_data, + uint8_t *stream_bits); +/* + * XXX KDM consider removing some of these routines once ctl_scsi_all.c + * has been refactored. + */ +void scsi_info_sbuf(struct sbuf *sb, uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, uint64_t info); +void scsi_command_sbuf(struct sbuf *sb, uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, uint64_t csi); +void scsi_progress_sbuf(struct sbuf *sb, uint16_t progress); +int scsi_sks_sbuf(struct sbuf *sb, int sense_key, uint8_t *sks); +void scsi_fru_sbuf(struct sbuf *sb, uint64_t fru); +void scsi_stream_sbuf(struct sbuf *sb, uint8_t stream_bits, uint64_t info); +void scsi_block_sbuf(struct sbuf *sb, uint8_t block_bits, uint64_t info); +void scsi_sense_info_sbuf(struct sbuf *sb, struct scsi_sense_data *sense, + uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, + struct scsi_sense_desc_header *header); + +void scsi_sense_command_sbuf(struct sbuf *sb, struct scsi_sense_data *sense, + uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, + struct scsi_sense_desc_header *header); +void scsi_sense_sks_sbuf(struct sbuf *sb, struct scsi_sense_data *sense, + uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, + struct scsi_sense_desc_header *header); +void scsi_sense_fru_sbuf(struct sbuf *sb, struct scsi_sense_data *sense, + uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, + struct scsi_sense_desc_header *header); +void scsi_sense_stream_sbuf(struct sbuf *sb, struct scsi_sense_data *sense, + uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, + struct scsi_sense_desc_header *header); +void scsi_sense_block_sbuf(struct sbuf *sb, struct scsi_sense_data *sense, + uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, + struct scsi_sense_desc_header *header); +void scsi_sense_progress_sbuf(struct sbuf *sb, struct scsi_sense_data *sense, + uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, + struct scsi_sense_desc_header *header); +void scsi_sense_generic_sbuf(struct sbuf *sb, struct scsi_sense_data *sense, + uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, + struct scsi_sense_desc_header *header); +void scsi_sense_desc_sbuf(struct sbuf *sb, struct scsi_sense_data *sense, + uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, + struct scsi_sense_desc_header *header); +scsi_sense_data_type scsi_sense_type(struct scsi_sense_data *sense_data); + +void scsi_sense_only_sbuf(struct scsi_sense_data *sense, struct sbuf *sb, + char *path_str, struct scsi_inquiry_data *inq_data, + uint8_t *cdb, int cdb_len); + #ifdef _KERNEL int scsi_command_string(struct ccb_scsiio *csio, struct sbuf *sb); int scsi_sense_sbuf(struct ccb_scsiio *csio, struct sbuf *sb, @@ -1500,28 +2251,80 @@ static __inline void scsi_extract_sense(struct scsi_sense_data *sense, int *error_code, int *sense_key, int *asc, int *ascq); +static __inline int scsi_get_sense_key(struct scsi_sense_data *sense); +static __inline int scsi_get_asc(struct scsi_sense_data *sense); +static __inline int scsi_get_ascq(struct scsi_sense_data *sense); static __inline void scsi_ulto2b(u_int32_t val, u_int8_t *bytes); static __inline void scsi_ulto3b(u_int32_t val, u_int8_t *bytes); static __inline void scsi_ulto4b(u_int32_t val, u_int8_t *bytes); static __inline void scsi_u64to8b(u_int64_t val, u_int8_t *bytes); -static __inline u_int32_t scsi_2btoul(u_int8_t *bytes); -static __inline u_int32_t scsi_3btoul(u_int8_t *bytes); -static __inline int32_t scsi_3btol(u_int8_t *bytes); -static __inline u_int32_t scsi_4btoul(u_int8_t *bytes); -static __inline u_int64_t scsi_8btou64(u_int8_t *bytes); +static __inline uint32_t scsi_2btoul(const uint8_t *bytes); +static __inline uint32_t scsi_3btoul(const uint8_t *bytes); +static __inline int32_t scsi_3btol(const uint8_t *bytes); +static __inline uint32_t scsi_4btoul(const uint8_t *bytes); +static __inline uint64_t scsi_8btou64(const uint8_t *bytes); static __inline void *find_mode_page_6(struct scsi_mode_header_6 *mode_header); static __inline void *find_mode_page_10(struct scsi_mode_header_10 *mode_header); -static __inline void scsi_extract_sense(struct scsi_sense_data *sense, +static __inline void scsi_extract_sense(struct scsi_sense_data *sense_data, int *error_code, int *sense_key, int *asc, int *ascq) { - *error_code = sense->error_code & SSD_ERRCODE; - *sense_key = sense->flags & SSD_KEY; - *asc = (sense->extra_len >= 5) ? sense->add_sense_code : 0; - *ascq = (sense->extra_len >= 6) ? sense->add_sense_code_qual : 0; + switch (sense_data->error_code & SSD_ERRCODE) { + case SSD_DESC_CURRENT_ERROR: + case SSD_DESC_DEFERRED_ERROR: { + struct scsi_sense_data_desc *sense; + + sense = (struct scsi_sense_data_desc *)sense_data; + *error_code = sense->error_code & SSD_ERRCODE; + *sense_key = sense->sense_key & SSD_KEY; + *asc = sense->add_sense_code; + *ascq = sense->add_sense_code_qual; + break; + } + case SSD_CURRENT_ERROR: + case SSD_DEFERRED_ERROR: + default: { + struct scsi_sense_data_fixed *sense; + + sense = (struct scsi_sense_data_fixed *)sense_data; + *error_code = sense->error_code & SSD_ERRCODE; + *sense_key = sense->flags & SSD_KEY; + *asc = (sense->extra_len >= 5) ? sense->add_sense_code : 0; + *ascq = (sense->extra_len >= 6) ?sense->add_sense_code_qual : 0; + break; + } + } } +static __inline int scsi_get_sense_key(struct scsi_sense_data *sense_data) +{ + int error_code, sense_key, asc, ascq; + + scsi_extract_sense(sense_data, &error_code, &sense_key, &asc, &ascq); + + return (sense_key); +} + +static __inline int scsi_get_asc(struct scsi_sense_data *sense_data) +{ + int error_code, sense_key, asc, ascq; + + scsi_extract_sense(sense_data, &error_code, &sense_key, &asc, &ascq); + + return (asc); +} + +static __inline int scsi_get_ascq(struct scsi_sense_data *sense_data) +{ + int error_code, sense_key, asc, ascq; + + scsi_extract_sense(sense_data, &error_code, &sense_key, &asc, &ascq); + + return (ascq); +} + + static __inline void scsi_ulto2b(u_int32_t val, u_int8_t *bytes) { @@ -1563,20 +2366,20 @@ bytes[7] = val & 0xff; } -static __inline u_int32_t -scsi_2btoul(u_int8_t *bytes) +static __inline uint32_t +scsi_2btoul(const uint8_t *bytes) { - u_int32_t rv; + uint32_t rv; rv = (bytes[0] << 8) | bytes[1]; return (rv); } -static __inline u_int32_t -scsi_3btoul(u_int8_t *bytes) +static __inline uint32_t +scsi_3btoul(const uint8_t *bytes) { - u_int32_t rv; + uint32_t rv; rv = (bytes[0] << 16) | (bytes[1] << 8) | @@ -1585,9 +2388,9 @@ } static __inline int32_t -scsi_3btol(u_int8_t *bytes) +scsi_3btol(const uint8_t *bytes) { - u_int32_t rc = scsi_3btoul(bytes); + uint32_t rc = scsi_3btoul(bytes); if (rc & 0x00800000) rc |= 0xff000000; @@ -1595,10 +2398,10 @@ return (int32_t) rc; } -static __inline u_int32_t -scsi_4btoul(u_int8_t *bytes) +static __inline uint32_t +scsi_4btoul(const uint8_t *bytes) { - u_int32_t rv; + uint32_t rv; rv = (bytes[0] << 24) | (bytes[1] << 16) | @@ -1608,7 +2411,7 @@ } static __inline uint64_t -scsi_8btou64(uint8_t *bytes) +scsi_8btou64(const uint8_t *bytes) { uint64_t rv; Index: sys/cam/scsi/scsi_sa.c =================================================================== --- sys/cam/scsi/scsi_sa.c (revision 225710) +++ sys/cam/scsi/scsi_sa.c (working copy) @@ -235,10 +235,10 @@ */ struct { struct scsi_sense_data _last_io_sense; - u_int32_t _last_io_resid; + u_int64_t _last_io_resid; u_int8_t _last_io_cdb[CAM_MAX_CDBLEN]; struct scsi_sense_data _last_ctl_sense; - u_int32_t _last_ctl_resid; + u_int64_t _last_ctl_resid; u_int8_t _last_ctl_cdb[CAM_MAX_CDBLEN]; #define last_io_sense errinfo._last_io_sense #define last_io_resid errinfo._last_io_resid @@ -2322,17 +2322,22 @@ struct sa_softc *softc; struct ccb_scsiio *csio; struct scsi_sense_data *sense; - u_int32_t resid = 0; - int32_t info = 0; + uint64_t resid = 0; + int64_t info = 0; cam_status status; - int error_code, sense_key, asc, ascq, error, aqvalid; + int error_code, sense_key, asc, ascq, error, aqvalid, stream_valid; + uint8_t stream_bits; periph = xpt_path_periph(ccb->ccb_h.path); softc = (struct sa_softc *)periph->softc; csio = &ccb->csio; sense = &csio->sense_data; scsi_extract_sense(sense, &error_code, &sense_key, &asc, &ascq); - aqvalid = sense->extra_len >= 6; + aqvalid = scsi_asc_ascq_valid(sense, /*ascq*/ 1); + if (scsi_get_stream_info(sense, NULL, &stream_bits) == 0) + stream_valid = 1; + else + stream_valid = 0; error = 0; status = csio->ccb_h.status & CAM_STATUS_MASK; @@ -2343,9 +2348,8 @@ * unit. */ if (status == CAM_SCSI_STATUS_ERROR) { - if ((sense->error_code & SSD_ERRCODE_VALID) != 0) { - info = (int32_t) scsi_4btoul(sense->info); - resid = info; + if (scsi_get_sense_info(sense, SSD_DESC_INFO, &resid, + &info) == 0) { if ((softc->flags & SA_FLAG_FIXED) != 0) resid *= softc->media_blksize; } else { @@ -2372,10 +2376,11 @@ softc->last_resid_was_io = 0; } CAM_DEBUG(periph->path, CAM_DEBUG_INFO, ("CDB[0]=0x%x Key 0x%x " - "ASC/ASCQ 0x%x/0x%x CAM STATUS 0x%x flags 0x%x resid %d " + "ASC/ASCQ 0x%x/0x%x CAM STATUS 0x%x flags 0x%x resid %jd " "dxfer_len %d\n", csio->cdb_io.cdb_bytes[0] & 0xff, sense_key, asc, ascq, status, - sense->flags & ~SSD_KEY_RESERVED, resid, csio->dxfer_len)); + (stream_valid) ? stream_bits : 0, (intmax_t)resid, + csio->dxfer_len)); } else { CAM_DEBUG(periph->path, CAM_DEBUG_INFO, ("Cam Status 0x%x\n", status)); @@ -2431,7 +2436,7 @@ if (sense_key == SSD_KEY_VOLUME_OVERFLOW) { csio->resid = resid; error = ENOSPC; - } else if (sense->flags & SSD_EOM) { + } else if ((stream_valid != 0) && (stream_bits & SSD_EOM)) { softc->flags |= SA_FLAG_EOM_PENDING; /* * Grotesque as it seems, the few times @@ -2450,7 +2455,7 @@ } else { error = EIO; } - } else if (sense->flags & SSD_FILEMARK) { + } else if ((stream_valid != 0) && (stream_bits & SSD_FILEMARK)){ if (softc->flags & SA_FLAG_FIXED) { error = -1; softc->flags |= SA_FLAG_EOF_PENDING; @@ -2470,7 +2475,7 @@ /* * Incorrect Length usually applies to read, but can apply to writes. */ - if (error == 0 && (sense->flags & SSD_ILI)) { + if (error == 0 && (stream_valid != 0) && (stream_bits & SSD_ILI)) { if (info < 0) { xpt_print(csio->ccb_h.path, toobig, csio->dxfer_len - info); @@ -2485,7 +2490,8 @@ * Bump the block number if we hadn't seen a filemark. * Do this independent of errors (we've moved anyway). */ - if ((sense->flags & SSD_FILEMARK) == 0) { + if ((stream_valid == 0) || + (stream_bits & SSD_FILEMARK) == 0) { if (softc->blkno != (daddr_t) -1) { softc->blkno++; csio->ccb_h.ccb_pflags |= Index: sys/cam/scsi/scsi_targ_bh.c =================================================================== --- sys/cam/scsi/scsi_targ_bh.c (revision 225710) +++ sys/cam/scsi/scsi_targ_bh.c (working copy) @@ -112,20 +112,20 @@ /* version */2, /* format version */2 }; -static struct scsi_sense_data no_lun_sense_data = +static struct scsi_sense_data_fixed no_lun_sense_data = { SSD_CURRENT_ERROR|SSD_ERRCODE_VALID, 0, SSD_KEY_NOT_READY, { 0, 0, 0, 0 }, - /*extra_len*/offsetof(struct scsi_sense_data, fru) - - offsetof(struct scsi_sense_data, extra_len), + /*extra_len*/offsetof(struct scsi_sense_data_fixed, fru) + - offsetof(struct scsi_sense_data_fixed, extra_len), { 0, 0, 0, 0 }, /* Logical Unit Not Supported */ /*ASC*/0x25, /*ASCQ*/0 }; -static const int request_sense_size = offsetof(struct scsi_sense_data, fru); +static const int request_sense_size = offsetof(struct scsi_sense_data_fixed, fru); static periph_init_t targbhinit; static void targbhasync(void *callback_arg, u_int32_t code, @@ -587,7 +587,9 @@ * This needs to have other than a * no_lun_sense_data response. */ - atio->sense_data = no_lun_sense_data; + bcopy(&no_lun_sense_data, &atio->sense_data, + min(sizeof(no_lun_sense_data), + sizeof(atio->sense_data))); atio->sense_len = sizeof(no_lun_sense_data); descr->data_resid = 0; descr->data_increment = 0; @@ -630,7 +632,9 @@ /* Direction is always relative to the initator */ atio->ccb_h.flags &= ~CAM_DIR_MASK; atio->ccb_h.flags |= CAM_DIR_NONE; - atio->sense_data = no_lun_sense_data; + bcopy(&no_lun_sense_data, &atio->sense_data, + min(sizeof(no_lun_sense_data), + sizeof(atio->sense_data))); atio->sense_len = sizeof (no_lun_sense_data); descr->data_resid = 0; descr->data_increment = 0; Index: sys/cam/scsi/scsi_low.c =================================================================== --- sys/cam/scsi/scsi_low.c (revision 225710) +++ sys/cam/scsi/scsi_low.c (working copy) @@ -2577,12 +2577,16 @@ #ifdef SCSI_LOW_DEBUG if (scsi_low_debug & SCSI_LOW_DEBUG_SENSE) { - printf("SENSE: [%x][%x][%x][%x][%x]\n", - (u_int) cb->ccb_sense.error_code, - (u_int) cb->ccb_sense.segment, - (u_int) cb->ccb_sense.flags, - (u_int) cb->ccb_sense.add_sense_code, - (u_int) cb->ccb_sense.add_sense_code_qual); + int error_code, sense_key, asc, ascq; + + scsi_extract_sense(&cb->ccb_sense, + &error_code, + &sense_key, + &asc, + &ascq); + printf("SENSE: [%x][%x][%x][%x]\n", + error_code, sense_key, asc, + ascq); } #endif /* SCSI_LOW_DEBUG */ } Index: sys/cam/scsi/scsi_all.c =================================================================== --- sys/cam/scsi/scsi_all.c (revision 225710) +++ sys/cam/scsi/scsi_all.c (working copy) @@ -31,6 +31,8 @@ __FBSDID("$FreeBSD$"); #include +#include +#include #ifdef _KERNEL #include @@ -54,6 +56,7 @@ #include #ifndef _KERNEL #include +#include #ifndef FALSE #define FALSE 0 @@ -608,14 +611,24 @@ struct op_table_entry *table[2]; int num_tables; - pd_type = SID_TYPE(inq_data); + /* + * If we've got inquiry data, use it to determine what type of + * device we're dealing with here. Otherwise, assume direct + * access. + */ + if (inq_data == NULL) { + pd_type = T_DIRECT; + match = NULL; + } else { + pd_type = SID_TYPE(inq_data); - match = cam_quirkmatch((caddr_t)inq_data, - (caddr_t)scsi_op_quirk_table, - sizeof(scsi_op_quirk_table)/ - sizeof(*scsi_op_quirk_table), - sizeof(*scsi_op_quirk_table), - scsi_inquiry_match); + match = cam_quirkmatch((caddr_t)inq_data, + (caddr_t)scsi_op_quirk_table, + sizeof(scsi_op_quirk_table)/ + sizeof(*scsi_op_quirk_table), + sizeof(*scsi_op_quirk_table), + scsi_inquiry_match); + } if (match != NULL) { table[0] = ((struct scsi_op_quirk_entry *)match)->op_table; @@ -699,7 +712,7 @@ { SSD_KEY_EQUAL, SS_NOP, "EQUAL" }, { SSD_KEY_VOLUME_OVERFLOW, SS_FATAL|EIO, "VOLUME OVERFLOW" }, { SSD_KEY_MISCOMPARE, SS_NOP, "MISCOMPARE" }, - { SSD_KEY_RESERVED, SS_FATAL|EIO, "RESERVED" } + { SSD_KEY_COMPLETED, SS_NOP, "RESERVED" } }; const int sense_key_table_size = @@ -1062,25 +1075,25 @@ { SST(0x10, 0x03, SS_RDEF, /* XXX TBD */ "Logical block reference tag check failed") }, /* DT WRO BK */ - { SST(0x11, 0x00, SS_RDEF, + { SST(0x11, 0x00, SS_FATAL|EIO, "Unrecovered read error") }, /* DT WRO BK */ - { SST(0x11, 0x01, SS_RDEF, + { SST(0x11, 0x01, SS_FATAL|EIO, "Read retries exhausted") }, /* DT WRO BK */ - { SST(0x11, 0x02, SS_RDEF, + { SST(0x11, 0x02, SS_FATAL|EIO, "Error too long to correct") }, /* DT W O BK */ - { SST(0x11, 0x03, SS_RDEF, + { SST(0x11, 0x03, SS_FATAL|EIO, "Multiple read errors") }, /* D W O BK */ - { SST(0x11, 0x04, SS_RDEF, + { SST(0x11, 0x04, SS_FATAL|EIO, "Unrecovered read error - auto reallocate failed") }, /* WRO B */ - { SST(0x11, 0x05, SS_RDEF, + { SST(0x11, 0x05, SS_FATAL|EIO, "L-EC uncorrectable error") }, /* WRO B */ - { SST(0x11, 0x06, SS_RDEF, + { SST(0x11, 0x06, SS_FATAL|EIO, "CIRC unrecovered error") }, /* W O B */ { SST(0x11, 0x07, SS_RDEF, @@ -1095,10 +1108,10 @@ { SST(0x11, 0x0A, SS_RDEF, "Miscorrected error") }, /* D W O BK */ - { SST(0x11, 0x0B, SS_RDEF, + { SST(0x11, 0x0B, SS_FATAL|EIO, "Unrecovered read error - recommend reassignment") }, /* D W O BK */ - { SST(0x11, 0x0C, SS_RDEF, + { SST(0x11, 0x0C, SS_FATAL|EIO, "Unrecovered read error - recommend rewrite the data") }, /* DT WRO B */ { SST(0x11, 0x0D, SS_RDEF, @@ -2819,7 +2832,8 @@ scsi_extract_sense(&csio->sense_data, &error_code, &sense_key, &asc, &ascq); - if (error_code == SSD_DEFERRED_ERROR) { + if ((error_code == SSD_DEFERRED_ERROR) + || (error_code == SSD_DESC_DEFERRED_ERROR)) { /* * XXX dufault@FreeBSD.org * This error doesn't relate to the command associated @@ -3040,8 +3054,1232 @@ return(0); } +/* + * Given a descriptor type, return a pointer to it if it is in the sense + * data and not truncated. Avoiding truncating sense data will simplify + * things significantly for the caller. + * + * We shouldn't run into truncated data very often, since we specify full + * sized sense data in most every case. + */ +uint8_t * +scsi_find_desc(struct scsi_sense_data_desc *sense, uint8_t desc_type) +{ + int cur_pos; + for (cur_pos = 0; cur_pos < MIN(sense->extra_len, SSD_EXTRA_MAX);) { + struct scsi_sense_desc_header *header; + + header = (struct scsi_sense_desc_header *) + &sense->sense_desc[cur_pos]; + if (header->desc_type == desc_type) { + if (header->length > (sense->extra_len - cur_pos)) + return (NULL); + else + return (uint8_t *)header; + } + cur_pos += sizeof(*header) + header->length; + } + + return (NULL); +} + /* + * Fill in SCSI sense data with the specified parameters. This routine can + * fill in either fixed or descriptor type sense data. + */ +void +scsi_set_sense_data_va(struct scsi_sense_data *sense_data, + scsi_sense_data_type sense_format, int current_error, + int sense_key, int asc, int ascq, va_list ap) +{ + int descriptor_sense; + scsi_sense_elem_type elem_type; + + /* + * Determine whether to return fixed or descriptor format sense + * data. If the user specifies SSD_TYPE_NONE for some reason, + * they'll just get fixed sense data. + */ + if (sense_format == SSD_TYPE_DESC) + descriptor_sense = 1; + else + descriptor_sense = 0; + + /* + * Zero the sense data, so that we don't pass back any garbage data + * to the user. + */ + memset(sense_data, 0, sizeof(*sense_data)); + + if (descriptor_sense != 0) { + struct scsi_sense_data_desc *sense; + + sense = (struct scsi_sense_data_desc *)sense_data; + /* + * The descriptor sense format eliminates the use of the + * valid bit. + */ + if (current_error != 0) + sense->error_code = SSD_DESC_CURRENT_ERROR; + else + sense->error_code = SSD_DESC_DEFERRED_ERROR; + sense->sense_key = sense_key; + sense->add_sense_code = asc; + sense->add_sense_code_qual = ascq; + /* + * Start off with no extra length, since the above data + * fits in the standard descriptor sense information. + */ + sense->extra_len = 0; + while ((elem_type = (scsi_sense_elem_type)va_arg(ap, + scsi_sense_elem_type)) != SSD_ELEM_NONE) { + int sense_len, len_to_copy; + uint8_t *data; + + if (elem_type >= SSD_ELEM_MAX) { + printf("%s: invalid sense type %d\n", __func__, + elem_type); + break; + } + + sense_len = (int)va_arg(ap, int); + len_to_copy = MIN(sense_len, SSD_EXTRA_MAX - + sense->extra_len); + data = (uint8_t *)va_arg(ap, uint8_t *); + + /* + * We've already consumed the arguments for this one. + */ + if (elem_type == SSD_ELEM_SKIP) + continue; + + switch (elem_type) { + case SSD_ELEM_DESC: { + + /* + * This is a straight descriptor. All we + * need to do is copy the data in. + */ + bcopy(data, &sense->sense_desc[ + sense->extra_len], len_to_copy); + sense->extra_len += len_to_copy; + break; + } + case SSD_ELEM_SKS: { + struct scsi_sense_sks sks; + + bzero(&sks, sizeof(sks)); + + /* + * This is already-formatted sense key + * specific data. We just need to fill out + * the header and copy everything in. + */ + bcopy(data, &sks.sense_key_spec, + MIN(len_to_copy, + sizeof(sks.sense_key_spec))); + + sks.desc_type = SSD_DESC_SKS; + sks.length = sizeof(sks) - + offsetof(struct scsi_sense_sks, reserved1); + bcopy(&sks,&sense->sense_desc[sense->extra_len], + sizeof(sks)); + sense->extra_len += sizeof(sks); + break; + } + case SSD_ELEM_INFO: + case SSD_ELEM_COMMAND: { + struct scsi_sense_command cmd; + struct scsi_sense_info info; + uint8_t *data_dest; + uint8_t *descriptor; + int descriptor_size, i, copy_len; + + bzero(&cmd, sizeof(cmd)); + bzero(&info, sizeof(info)); + + /* + * Command or information data. The + * operate in pretty much the same way. + */ + if (elem_type == SSD_ELEM_COMMAND) { + len_to_copy = MIN(len_to_copy, + sizeof(cmd.command_info)); + descriptor = (uint8_t *)&cmd; + descriptor_size = sizeof(cmd); + data_dest =(uint8_t *)&cmd.command_info; + cmd.desc_type = SSD_DESC_COMMAND; + cmd.length = sizeof(cmd) - + offsetof(struct scsi_sense_command, + reserved); + } else { + len_to_copy = MIN(len_to_copy, + sizeof(info.info)); + descriptor = (uint8_t *)&info; + descriptor_size = sizeof(cmd); + data_dest = (uint8_t *)&info.info; + info.desc_type = SSD_DESC_INFO; + info.byte2 = SSD_INFO_VALID; + info.length = sizeof(info) - + offsetof(struct scsi_sense_info, + byte2); + } + + /* + * Copy this in reverse because the spec + * (SPC-4) says that when 4 byte quantities + * are stored in this 8 byte field, the + * first four bytes shall be 0. + * + * So we fill the bytes in from the end, and + * if we have less than 8 bytes to copy, + * the initial, most significant bytes will + * be 0. + */ + for (i = sense_len - 1; i >= 0 && + len_to_copy > 0; i--, len_to_copy--) + data_dest[len_to_copy - 1] = data[i]; + + /* + * This calculation looks much like the + * initial len_to_copy calculation, but + * we have to do it again here, because + * we're looking at a larger amount that + * may or may not fit. It's not only the + * data the user passed in, but also the + * rest of the descriptor. + */ + copy_len = MIN(descriptor_size, + SSD_EXTRA_MAX - sense->extra_len); + bcopy(descriptor, &sense->sense_desc[ + sense->extra_len], copy_len); + sense->extra_len += copy_len; + break; + } + case SSD_ELEM_FRU: { + struct scsi_sense_fru fru; + int copy_len; + + bzero(&fru, sizeof(fru)); + + fru.desc_type = SSD_DESC_FRU; + fru.length = sizeof(fru) - + offsetof(struct scsi_sense_fru, reserved); + fru.fru = *data; + + copy_len = MIN(sizeof(fru), SSD_EXTRA_MAX - + sense->extra_len); + bcopy(&fru, &sense->sense_desc[ + sense->extra_len], copy_len); + sense->extra_len += copy_len; + break; + } + case SSD_ELEM_STREAM: { + struct scsi_sense_stream stream_sense; + int copy_len; + + bzero(&stream_sense, sizeof(stream_sense)); + stream_sense.desc_type = SSD_DESC_STREAM; + stream_sense.length = sizeof(stream_sense) - + offsetof(struct scsi_sense_stream, reserved); + stream_sense.byte3 = *data; + + copy_len = MIN(sizeof(stream_sense), + SSD_EXTRA_MAX - sense->extra_len); + bcopy(&stream_sense, &sense->sense_desc[ + sense->extra_len], copy_len); + sense->extra_len += copy_len; + break; + } + default: + /* + * We shouldn't get here, but if we do, do + * nothing. We've already consumed the + * arguments above. + */ + break; + } + } + } else { + struct scsi_sense_data_fixed *sense; + + sense = (struct scsi_sense_data_fixed *)sense_data; + + if (current_error != 0) + sense->error_code = SSD_ERRCODE_VALID | + SSD_CURRENT_ERROR; + else + sense->error_code = SSD_ERRCODE_VALID | + SSD_DEFERRED_ERROR; + sense->flags = sense_key; + sense->add_sense_code = asc; + sense->add_sense_code_qual = ascq; + /* + * We've set the ASC and ASCQ, so we have 6 more bytes of + * valid data. If we wind up setting any of the other + * fields, we'll bump this to 10 extra bytes. + */ + sense->extra_len = 6; + + while ((elem_type = (scsi_sense_elem_type)va_arg(ap, + scsi_sense_elem_type)) != SSD_ELEM_NONE) { + int sense_len, len_to_copy; + uint8_t *data; + + if (elem_type >= SSD_ELEM_MAX) { + printf("%s: invalid sense type %d\n", __func__, + elem_type); + break; + } + /* + * If we get in here, just bump the extra length to + * 10 bytes. That will encompass anything we're + * going to set here. + */ + sense->extra_len = 10; + sense_len = (int)va_arg(ap, int); + len_to_copy = MIN(sense_len, SSD_EXTRA_MAX - + sense->extra_len); + data = (uint8_t *)va_arg(ap, uint8_t *); + + switch (elem_type) { + case SSD_ELEM_SKS: + /* + * The user passed in pre-formatted sense + * key specific data. + */ + bcopy(data, &sense->sense_key_spec[0], + MIN(sizeof(sense->sense_key_spec), + sense_len)); + break; + case SSD_ELEM_INFO: + case SSD_ELEM_COMMAND: { + uint8_t *data_dest; + int i; + + if (elem_type == SSD_ELEM_COMMAND) + data_dest = &sense->cmd_spec_info[0]; + else + data_dest = &sense->info[0]; + + /* + * Copy this in reverse so that if we have + * less than 4 bytes to fill, the least + * significant bytes will be at the end. + * If we have more than 4 bytes, only the + * least significant bytes will be included. + */ + for (i = sense_len - 1; i >= 0 && + len_to_copy > 0; i--, len_to_copy--) + data_dest[len_to_copy - 1] = data[i]; + + break; + } + case SSD_ELEM_FRU: + sense->fru = *data; + break; + case SSD_ELEM_STREAM: + sense->flags |= *data; + break; + case SSD_ELEM_DESC: + default: + + /* + * If the user passes in descriptor sense, + * we can't handle that in fixed format. + * So just skip it, and any unknown argument + * types. + */ + break; + } + } + } +} + +void +scsi_set_sense_data(struct scsi_sense_data *sense_data, + scsi_sense_data_type sense_format, int current_error, + int sense_key, int asc, int ascq, ...) +{ + va_list ap; + + va_start(ap, ascq); + scsi_set_sense_data_va(sense_data, sense_format, current_error, + sense_key, asc, ascq, ap); + va_end(ap); +} + +/* + * Returns 1 if the ASC or ASCQ is valid, 0 if it is not valid. + */ +int +scsi_asc_ascq_valid(struct scsi_sense_data *sense, int ascq) +{ + switch (scsi_sense_type(sense)) { + case SSD_TYPE_DESC: + /* + * For descriptor sense, the ASC and ASCQ are always valid. + */ + return (1); + break; + case SSD_TYPE_FIXED: { + struct scsi_sense_data_fixed *fixed_sense; + + fixed_sense = (struct scsi_sense_data_fixed *)sense; + + /* + * For fixed sense, the ASC and ASCQ are only valid if + * extra_len is large enough to include them. + */ + if (fixed_sense->extra_len >= 6) + return (1); + else if ((ascq == 0) + && (fixed_sense->extra_len >= 5)) + return (1); + else + return (0); + break; + } + default: + return (0); + break; + } +} + +/* + * Get sense information for three similar sense data types. + */ +int +scsi_get_sense_info(struct scsi_sense_data *sense_data, uint8_t info_type, + uint64_t *info, int64_t *signed_info) +{ + scsi_sense_data_type sense_type; + + sense_type = scsi_sense_type(sense_data); + + switch (sense_type) { + case SSD_TYPE_DESC: { + struct scsi_sense_data_desc *sense; + uint8_t *desc; + + sense = (struct scsi_sense_data_desc *)sense_data; + + desc = scsi_find_desc(sense, info_type); + if (desc == NULL) + goto bailout; + + switch (info_type) { + case SSD_DESC_INFO: { + struct scsi_sense_info *info_desc; + + info_desc = (struct scsi_sense_info *)desc; + *info = scsi_8btou64(info_desc->info); + if (signed_info != NULL) + *signed_info = *info; + break; + } + case SSD_DESC_COMMAND: { + struct scsi_sense_command *cmd_desc; + + cmd_desc = (struct scsi_sense_command *)desc; + + *info = scsi_8btou64(cmd_desc->command_info); + if (signed_info != NULL) + *signed_info = *info; + break; + } + case SSD_DESC_FRU: { + struct scsi_sense_fru *fru_desc; + + fru_desc = (struct scsi_sense_fru *)desc; + + *info = fru_desc->fru; + if (signed_info != NULL) + *signed_info = (int8_t)fru_desc->fru; + break; + } + default: + goto bailout; + break; + } + break; + } + case SSD_TYPE_FIXED: { + struct scsi_sense_data_fixed *sense; + + sense = (struct scsi_sense_data_fixed *)sense_data; + + switch (info_type) { + case SSD_DESC_INFO: { + uint32_t info_val; + + if ((sense->error_code & SSD_ERRCODE_VALID) == 0) + goto bailout; + + info_val = scsi_4btoul(sense->info); + + *info = info_val; + if (signed_info != NULL) + *signed_info = (int32_t)info_val; + break; + } + case SSD_DESC_COMMAND: { + uint32_t cmd_val; + + if (sense->extra_len < 4) + goto bailout; + + cmd_val = scsi_4btoul(sense->cmd_spec_info); + if (cmd_val == 0) + goto bailout; + + *info = cmd_val; + if (signed_info != NULL) + *signed_info = (int32_t)cmd_val; + break; + } + case SSD_DESC_FRU: + if ((sense->extra_len < 7) + || (sense->fru == 0)) + goto bailout; + + *info = sense->fru; + if (signed_info != NULL) + *signed_info = (int8_t)sense->fru; + break; + default: + goto bailout; + break; + } + break; + } + default: + goto bailout; + break; + } + + return (0); +bailout: + return (1); +} + +int +scsi_get_sks(struct scsi_sense_data *sense_data, uint8_t *sks) +{ + scsi_sense_data_type sense_type; + + sense_type = scsi_sense_type(sense_data); + + switch (sense_type) { + case SSD_TYPE_DESC: { + struct scsi_sense_data_desc *sense; + struct scsi_sense_sks *desc; + + sense = (struct scsi_sense_data_desc *)sense_data; + + desc = (struct scsi_sense_sks *)scsi_find_desc(sense, + SSD_DESC_SKS); + if (desc == NULL) + goto bailout; + + bcopy(desc->sense_key_spec, sks, sizeof(desc->sense_key_spec)); + break; + } + case SSD_TYPE_FIXED: { + struct scsi_sense_data_fixed *sense; + + sense = (struct scsi_sense_data_fixed *)sense_data; + + if ((sense->extra_len < 10) + || ((sense->sense_key_spec[0] & SSD_SCS_VALID) == 0)) + goto bailout; + bcopy(sense->sense_key_spec, sks,sizeof(sense->sense_key_spec)); + break; + } + default: + goto bailout; + break; + } + return (0); +bailout: + return (1); +} + +/* + * Provide a common interface for fixed and descriptor sense to detect + * whether we have block-specific sense information. It is clear by the + * presence of the block descriptor in descriptor mode, but we have to + * infer from the inquiry data and ILI bit in fixed mode. + */ +int +scsi_get_block_info(struct scsi_sense_data *sense_data, + struct scsi_inquiry_data *inq_data, uint8_t *block_bits) +{ + scsi_sense_data_type sense_type; + + if (inq_data != NULL) { + switch (SID_TYPE(inq_data)) { + case T_DIRECT: + case T_RBC: + break; + default: + goto bailout; + break; + } + } + + sense_type = scsi_sense_type(sense_data); + + switch (sense_type) { + case SSD_TYPE_DESC: { + struct scsi_sense_data_desc *sense; + struct scsi_sense_block *block; + + sense = (struct scsi_sense_data_desc *)sense_data; + + block = (struct scsi_sense_block *)scsi_find_desc(sense, + SSD_DESC_BLOCK); + if (block == NULL) + goto bailout; + + *block_bits = block->byte3; + break; + } + case SSD_TYPE_FIXED: { + struct scsi_sense_data_fixed *sense; + + sense = (struct scsi_sense_data_fixed *)sense_data; + + if ((sense->flags & SSD_ILI) == 0) + goto bailout; + + *block_bits = sense->flags & SSD_ILI; + break; + } + default: + goto bailout; + break; + } + return (0); +bailout: + return (1); +} + +int +scsi_get_stream_info(struct scsi_sense_data *sense_data, + struct scsi_inquiry_data *inq_data, uint8_t *stream_bits) +{ + scsi_sense_data_type sense_type; + + if (inq_data != NULL) { + switch (SID_TYPE(inq_data)) { + case T_SEQUENTIAL: + break; + default: + goto bailout; + break; + } + } + + sense_type = scsi_sense_type(sense_data); + + switch (sense_type) { + case SSD_TYPE_DESC: { + struct scsi_sense_data_desc *sense; + struct scsi_sense_stream *stream; + + sense = (struct scsi_sense_data_desc *)sense_data; + + stream = (struct scsi_sense_stream *)scsi_find_desc(sense, + SSD_DESC_STREAM); + if (stream == NULL) + goto bailout; + + *stream_bits = stream->byte3; + break; + } + case SSD_TYPE_FIXED: { + struct scsi_sense_data_fixed *sense; + + sense = (struct scsi_sense_data_fixed *)sense_data; + + if ((sense->flags & (SSD_ILI|SSD_EOM|SSD_FILEMARK)) == 0) + goto bailout; + + *stream_bits = sense->flags & (SSD_ILI|SSD_EOM|SSD_FILEMARK); + break; + } + default: + goto bailout; + break; + } + return (0); +bailout: + return (1); +} + +void +scsi_info_sbuf(struct sbuf *sb, uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, uint64_t info) +{ + sbuf_printf(sb, "Info: %#jx", info); +} + +void +scsi_command_sbuf(struct sbuf *sb, uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, uint64_t csi) +{ + sbuf_printf(sb, "Command Specific Info: %#jx", csi); +} + + +void +scsi_progress_sbuf(struct sbuf *sb, uint16_t progress) +{ + sbuf_printf(sb, "Progress: %d%% (%d/%d) complete", + (progress * 100) / SSD_SKS_PROGRESS_DENOM, + progress, SSD_SKS_PROGRESS_DENOM); +} + +/* + * Returns 1 for failure (i.e. SKS isn't valid) and 0 for success. + */ +int +scsi_sks_sbuf(struct sbuf *sb, int sense_key, uint8_t *sks) +{ + if ((sks[0] & SSD_SKS_VALID) == 0) + return (1); + + switch (sense_key) { + case SSD_KEY_ILLEGAL_REQUEST: { + struct scsi_sense_sks_field *field; + int bad_command; + char tmpstr[40]; + + /*Field Pointer*/ + field = (struct scsi_sense_sks_field *)sks; + + if (field->byte0 & SSD_SKS_FIELD_CMD) + bad_command = 1; + else + bad_command = 0; + + tmpstr[0] = '\0'; + + /* Bit pointer is valid */ + if (field->byte0 & SSD_SKS_BPV) + snprintf(tmpstr, sizeof(tmpstr), "bit %d ", + field->byte0 & SSD_SKS_BIT_VALUE); + + sbuf_printf(sb, "%s byte %d %sis invalid", + bad_command ? "Command" : "Data", + scsi_2btoul(field->field), tmpstr); + break; + } + case SSD_KEY_UNIT_ATTENTION: { + struct scsi_sense_sks_overflow *overflow; + + overflow = (struct scsi_sense_sks_overflow *)sks; + + /*UA Condition Queue Overflow*/ + sbuf_printf(sb, "Unit Attention Condition Queue %s", + (overflow->byte0 & SSD_SKS_OVERFLOW_SET) ? + "Overflowed" : "Did Not Overflow??"); + break; + } + case SSD_KEY_RECOVERED_ERROR: + case SSD_KEY_HARDWARE_ERROR: + case SSD_KEY_MEDIUM_ERROR: { + struct scsi_sense_sks_retry *retry; + + /*Actual Retry Count*/ + retry = (struct scsi_sense_sks_retry *)sks; + + sbuf_printf(sb, "Actual Retry Count: %d", + scsi_2btoul(retry->actual_retry_count)); + break; + } + case SSD_KEY_NO_SENSE: + case SSD_KEY_NOT_READY: { + struct scsi_sense_sks_progress *progress; + int progress_val; + + /*Progress Indication*/ + progress = (struct scsi_sense_sks_progress *)sks; + progress_val = scsi_2btoul(progress->progress); + + scsi_progress_sbuf(sb, progress_val); + break; + } + case SSD_KEY_COPY_ABORTED: { + struct scsi_sense_sks_segment *segment; + char tmpstr[40]; + + /*Segment Pointer*/ + segment = (struct scsi_sense_sks_segment *)sks; + + tmpstr[0] = '\0'; + + if (segment->byte0 & SSD_SKS_SEGMENT_BPV) + snprintf(tmpstr, sizeof(tmpstr), "bit %d ", + segment->byte0 & SSD_SKS_SEGMENT_BITPTR); + + sbuf_printf(sb, "%s byte %d %sis invalid", (segment->byte0 & + SSD_SKS_SEGMENT_SD) ? "Segment" : "Data", + scsi_2btoul(segment->field), tmpstr); + break; + } + default: + sbuf_printf(sb, "Sense Key Specific: %#x,%#x", sks[0], + scsi_2btoul(&sks[1])); + break; + } + + return (0); +} + +void +scsi_fru_sbuf(struct sbuf *sb, uint64_t fru) +{ + sbuf_printf(sb, "Field Replaceable Unit: %d", (int)fru); +} + +void +scsi_stream_sbuf(struct sbuf *sb, uint8_t stream_bits, uint64_t info) +{ + int need_comma; + + need_comma = 0; + /* + * XXX KDM this needs more descriptive decoding. + */ + if (stream_bits & SSD_DESC_STREAM_FM) { + sbuf_printf(sb, "Filemark"); + need_comma = 1; + } + + if (stream_bits & SSD_DESC_STREAM_EOM) { + sbuf_printf(sb, "%sEOM", (need_comma) ? "," : ""); + need_comma = 1; + } + + if (stream_bits & SSD_DESC_STREAM_ILI) + sbuf_printf(sb, "%sILI", (need_comma) ? "," : ""); + + sbuf_printf(sb, ": Info: %#jx", (uintmax_t) info); +} + +void +scsi_block_sbuf(struct sbuf *sb, uint8_t block_bits, uint64_t info) +{ + if (block_bits & SSD_DESC_BLOCK_ILI) + sbuf_printf(sb, "ILI: residue %#jx", (uintmax_t) info); +} + +void +scsi_sense_info_sbuf(struct sbuf *sb, struct scsi_sense_data *sense, + uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, + struct scsi_sense_desc_header *header) +{ + struct scsi_sense_info *info; + + info = (struct scsi_sense_info *)header; + + scsi_info_sbuf(sb, cdb, cdb_len, inq_data, scsi_8btou64(info->info)); +} + +void +scsi_sense_command_sbuf(struct sbuf *sb, struct scsi_sense_data *sense, + uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, + struct scsi_sense_desc_header *header) +{ + struct scsi_sense_command *command; + + command = (struct scsi_sense_command *)header; + + scsi_command_sbuf(sb, cdb, cdb_len, inq_data, + scsi_8btou64(command->command_info)); +} + +void +scsi_sense_sks_sbuf(struct sbuf *sb, struct scsi_sense_data *sense, + uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, + struct scsi_sense_desc_header *header) +{ + struct scsi_sense_sks *sks; + int error_code, sense_key, asc, ascq; + + sks = (struct scsi_sense_sks *)header; + + scsi_extract_sense(sense, &error_code, &sense_key, &asc, &ascq); + + scsi_sks_sbuf(sb, sense_key, sks->sense_key_spec); +} + +void +scsi_sense_fru_sbuf(struct sbuf *sb, struct scsi_sense_data *sense, + uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, + struct scsi_sense_desc_header *header) +{ + struct scsi_sense_fru *fru; + + fru = (struct scsi_sense_fru *)header; + + scsi_fru_sbuf(sb, (uint64_t)fru->fru); +} + +void +scsi_sense_stream_sbuf(struct sbuf *sb, struct scsi_sense_data *sense, + uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, + struct scsi_sense_desc_header *header) +{ + struct scsi_sense_stream *stream; + uint64_t info; + + stream = (struct scsi_sense_stream *)header; + info = 0; + + scsi_get_sense_info(sense, SSD_DESC_INFO, &info, NULL); + + scsi_stream_sbuf(sb, stream->byte3, info); +} + +void +scsi_sense_block_sbuf(struct sbuf *sb, struct scsi_sense_data *sense, + uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, + struct scsi_sense_desc_header *header) +{ + struct scsi_sense_block *block; + uint64_t info; + + block = (struct scsi_sense_block *)header; + info = 0; + + scsi_get_sense_info(sense, SSD_DESC_INFO, &info, NULL); + + scsi_block_sbuf(sb, block->byte3, info); +} + +void +scsi_sense_progress_sbuf(struct sbuf *sb, struct scsi_sense_data *sense, + uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, + struct scsi_sense_desc_header *header) +{ + struct scsi_sense_progress *progress; + const char *sense_key_desc; + const char *asc_desc; + int progress_val; + + progress = (struct scsi_sense_progress *)header; + + /* + * Get descriptions for the sense key, ASC, and ASCQ in the + * progress descriptor. These could be different than the values + * in the overall sense data. + */ + scsi_sense_desc(progress->sense_key, progress->add_sense_code, + progress->add_sense_code_qual, inq_data, + &sense_key_desc, &asc_desc); + + progress_val = scsi_2btoul(progress->progress); + + /* + * The progress indicator is for the operation described by the + * sense key, ASC, and ASCQ in the descriptor. + */ + sbuf_cat(sb, sense_key_desc); + sbuf_printf(sb, " asc:%x,%x (%s): ", progress->add_sense_code, + progress->add_sense_code_qual, asc_desc); + scsi_progress_sbuf(sb, progress_val); +} + +/* + * Generic sense descriptor printing routine. This is used when we have + * not yet implemented a specific printing routine for this descriptor. + */ +void +scsi_sense_generic_sbuf(struct sbuf *sb, struct scsi_sense_data *sense, + uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, + struct scsi_sense_desc_header *header) +{ + int i; + uint8_t *buf_ptr; + + sbuf_printf(sb, "Descriptor %#x:", header->desc_type); + + buf_ptr = (uint8_t *)&header[1]; + + for (i = 0; i < header->length; i++, buf_ptr++) + sbuf_printf(sb, " %02x", *buf_ptr); +} + +/* + * Keep this list in numeric order. This speeds the array traversal. + */ +struct scsi_sense_desc_printer { + uint8_t desc_type; + /* + * The function arguments here are the superset of what is needed + * to print out various different descriptors. Command and + * information descriptors need inquiry data and command type. + * Sense key specific descriptors need the sense key. + * + * The sense, cdb, and inquiry data arguments may be NULL, but the + * information printed may not be fully decoded as a result. + */ + void (*print_func)(struct sbuf *sb, struct scsi_sense_data *sense, + uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, + struct scsi_sense_desc_header *header); +} scsi_sense_printers[] = { + {SSD_DESC_INFO, scsi_sense_info_sbuf}, + {SSD_DESC_COMMAND, scsi_sense_command_sbuf}, + {SSD_DESC_SKS, scsi_sense_sks_sbuf}, + {SSD_DESC_FRU, scsi_sense_fru_sbuf}, + {SSD_DESC_STREAM, scsi_sense_stream_sbuf}, + {SSD_DESC_BLOCK, scsi_sense_block_sbuf}, + {SSD_DESC_PROGRESS, scsi_sense_progress_sbuf} +}; + +void +scsi_sense_desc_sbuf(struct sbuf *sb, struct scsi_sense_data *sense, + uint8_t *cdb, int cdb_len, + struct scsi_inquiry_data *inq_data, + struct scsi_sense_desc_header *header) +{ + int i, found; + + for (i = 0, found = 0; i < (sizeof(scsi_sense_printers) / + sizeof(scsi_sense_printers[0])); i++) { + struct scsi_sense_desc_printer *printer; + + printer = &scsi_sense_printers[i]; + + /* + * The list is sorted, so quit if we've passed our + * descriptor number. + */ + if (printer->desc_type > header->desc_type) + break; + + if (printer->desc_type != header->desc_type) + continue; + + printer->print_func(sb, sense, cdb, cdb_len, inq_data, header); + + return; + } + + /* + * No specific printing routine, so use the generic routine. + */ + scsi_sense_generic_sbuf(sb, sense, cdb, cdb_len, inq_data, header); +} + +scsi_sense_data_type +scsi_sense_type(struct scsi_sense_data *sense_data) +{ + switch (sense_data->error_code & SSD_ERRCODE) { + case SSD_DESC_CURRENT_ERROR: + case SSD_DESC_DEFERRED_ERROR: + return (SSD_TYPE_DESC); + break; + case SSD_CURRENT_ERROR: + case SSD_DEFERRED_ERROR: + return (SSD_TYPE_FIXED); + break; + default: + break; + } + + return (SSD_TYPE_NONE); +} + +void +scsi_sense_only_sbuf(struct scsi_sense_data *sense, struct sbuf *sb, + char *path_str, struct scsi_inquiry_data *inq_data, + uint8_t *cdb, int cdb_len) +{ + int error_code, sense_key, asc, ascq; + + sbuf_cat(sb, path_str); + + scsi_extract_sense(sense, &error_code, &sense_key, &asc, &ascq); + + sbuf_printf(sb, "SCSI sense: "); + switch (error_code) { + case SSD_DEFERRED_ERROR: + case SSD_DESC_DEFERRED_ERROR: + sbuf_printf(sb, "Deferred error: "); + + /* FALLTHROUGH */ + case SSD_CURRENT_ERROR: + case SSD_DESC_CURRENT_ERROR: + { + struct scsi_sense_data_desc *desc_sense; + const char *sense_key_desc; + const char *asc_desc; + uint8_t sks[3]; + uint64_t val; + int cur_pos; + int info_valid; + + /* + * Get descriptions for the sense key, ASC, and ASCQ. + */ + scsi_sense_desc(sense_key, asc, ascq, inq_data, + &sense_key_desc, &asc_desc); + + /* + * We first print the sense key and ASC/ASCQ. + */ + sbuf_cat(sb, sense_key_desc); + sbuf_printf(sb, " asc:%x,%x (%s)\n", asc, ascq, asc_desc); + + /* + * Get the info field if it is valid. + */ + if (scsi_get_sense_info(sense, SSD_DESC_INFO, &val, NULL) == 0) + info_valid = 1; + else + info_valid = 0; + + if (info_valid != 0) { + uint8_t bits; + + /* + * Determine whether we have any block or stream + * device-specific information. + */ + if (scsi_get_block_info(sense, inq_data, &bits) == 0) { + sbuf_cat(sb, path_str); + scsi_block_sbuf(sb, bits, val); + sbuf_printf(sb, "\n"); + } else if (scsi_get_stream_info(sense, inq_data, + &bits) == 0) { + sbuf_cat(sb, path_str); + scsi_stream_sbuf(sb, bits, val); + sbuf_printf(sb, "\n"); + } else if (val != 0) { + /* + * The information field can be valid but 0. + * If the block or stream bits aren't set, + * and this is 0, it isn't terribly useful + * to print it out. + */ + sbuf_cat(sb, path_str); + scsi_info_sbuf(sb, cdb, cdb_len, inq_data, val); + sbuf_printf(sb, "\n"); + } + } + + /* + * Print the FRU. + */ + if (scsi_get_sense_info(sense, SSD_DESC_FRU, &val, NULL) == 0) { + sbuf_cat(sb, path_str); + scsi_fru_sbuf(sb, val); + sbuf_printf(sb, "\n"); + } + + /* + * Print any command-specific information. + */ + if (scsi_get_sense_info(sense, SSD_DESC_COMMAND, &val, + NULL) == 0) { + sbuf_cat(sb, path_str); + scsi_command_sbuf(sb, cdb, cdb_len, inq_data, val); + sbuf_printf(sb, "\n"); + } + + /* + * Print out any sense-key-specific information. + */ + if (scsi_get_sks(sense, sks) == 0) { + sbuf_cat(sb, path_str); + scsi_sks_sbuf(sb, sense_key, sks); + sbuf_printf(sb, "\n"); + } + + /* + * If this is fixed sense, we're done. If we have + * descriptor sense, we might have more information + * available. + */ + if (scsi_sense_type(sense) != SSD_TYPE_DESC) + break; + + desc_sense = (struct scsi_sense_data_desc *)sense; + + /* + * If we have descriptor sense, print out any remaining + * descriptors. + */ + for (cur_pos = 0; cur_pos < MIN(desc_sense->extra_len, + SSD_EXTRA_MAX);) { + struct scsi_sense_desc_header *header; + + header = (struct scsi_sense_desc_header *) + &desc_sense->sense_desc[cur_pos]; + switch (header->desc_type) { + case SSD_DESC_INFO: + case SSD_DESC_FRU: + case SSD_DESC_COMMAND: + case SSD_DESC_SKS: + /* + * We have already printed these + * descriptors, if they are present. + */ + break; + default: { + /* + * We only send a descriptor for printing + * if we have the entire descriptor. This + * simplifies things for the printing + * routines. + */ + if (header->length > + (desc_sense->extra_len - cur_pos)) + break; + sbuf_printf(sb, "%s", path_str); + scsi_sense_desc_sbuf(sb, sense, cdb, + cdb_len, inq_data, header); + sbuf_printf(sb, "\n"); + break; + } + } + cur_pos += sizeof(*header) + header->length; + } + break; + + } + default: { + sbuf_printf(sb, "Error code 0x%x", error_code); + if (sense->error_code & SSD_ERRCODE_VALID) { + struct scsi_sense_data_fixed *fixed_sense; + uint32_t info; + + fixed_sense = (struct scsi_sense_data_fixed *)sense; + + sbuf_printf(sb, " at block no. %d (decimal)", + info = scsi_4btoul(fixed_sense->info)); + } + sbuf_printf(sb, "\n"); + break; + } + } +} + +/* * scsi_sense_sbuf() returns 0 for success and -1 for failure. */ #ifdef _KERNEL @@ -3059,11 +4297,8 @@ #ifdef _KERNEL struct ccb_getdev *cgd; #endif /* _KERNEL */ - u_int32_t info; - int error_code; - int sense_key; - int asc, ascq; char path_str[64]; + uint8_t *cdb; #ifndef _KERNEL if (device == NULL) @@ -3161,129 +4396,13 @@ sense = &csio->sense_data; } + if (csio->ccb_h.flags & CAM_CDB_POINTER) + cdb = csio->cdb_io.cdb_ptr; + else + cdb = csio->cdb_io.cdb_bytes; - sbuf_cat(sb, path_str); - - error_code = sense->error_code & SSD_ERRCODE; - sense_key = sense->flags & SSD_KEY; - - sbuf_printf(sb, "SCSI sense: "); - switch (error_code) { - case SSD_DEFERRED_ERROR: - sbuf_printf(sb, "Deferred error: "); - - /* FALLTHROUGH */ - case SSD_CURRENT_ERROR: - { - const char *sense_key_desc; - const char *asc_desc; - - asc = (sense->extra_len >= 5) ? sense->add_sense_code : 0; - ascq = (sense->extra_len >= 6) ? sense->add_sense_code_qual : 0; - scsi_sense_desc(sense_key, asc, ascq, inq_data, - &sense_key_desc, &asc_desc); - sbuf_cat(sb, sense_key_desc); - - info = scsi_4btoul(sense->info); - - if (sense->error_code & SSD_ERRCODE_VALID) { - - switch (sense_key) { - case SSD_KEY_NOT_READY: - case SSD_KEY_ILLEGAL_REQUEST: - case SSD_KEY_UNIT_ATTENTION: - case SSD_KEY_DATA_PROTECT: - break; - case SSD_KEY_BLANK_CHECK: - sbuf_printf(sb, " req sz: %d (decimal)", info); - break; - default: - if (info) { - if (sense->flags & SSD_ILI) { - sbuf_printf(sb, " ILI (length " - "mismatch): %d", info); - - } else { - sbuf_printf(sb, " info:%x", - info); - } - } - } - } else if (info) { - sbuf_printf(sb, " info?:%x", info); - } - - if (sense->extra_len >= 4) { - if (bcmp(sense->cmd_spec_info, "\0\0\0\0", 4)) { - sbuf_printf(sb, " csi:%x,%x,%x,%x", - sense->cmd_spec_info[0], - sense->cmd_spec_info[1], - sense->cmd_spec_info[2], - sense->cmd_spec_info[3]); - } - } - - sbuf_printf(sb, " asc:%x,%x (%s)", asc, ascq, asc_desc); - - if (sense->extra_len >= 7 && sense->fru) { - sbuf_printf(sb, " field replaceable unit: %x", - sense->fru); - } - - if ((sense->extra_len >= 10) - && (sense->sense_key_spec[0] & SSD_SCS_VALID) != 0) { - switch(sense_key) { - case SSD_KEY_ILLEGAL_REQUEST: { - int bad_command; - char tmpstr2[40]; - - if (sense->sense_key_spec[0] & 0x40) - bad_command = 1; - else - bad_command = 0; - - tmpstr2[0] = '\0'; - - /* Bit pointer is valid */ - if (sense->sense_key_spec[0] & 0x08) - snprintf(tmpstr2, sizeof(tmpstr2), - "bit %d ", - sense->sense_key_spec[0] & 0x7); - sbuf_printf(sb, ": %s byte %d %sis invalid", - bad_command ? "Command" : "Data", - scsi_2btoul( - &sense->sense_key_spec[1]), - tmpstr2); - break; - } - case SSD_KEY_RECOVERED_ERROR: - case SSD_KEY_HARDWARE_ERROR: - case SSD_KEY_MEDIUM_ERROR: - sbuf_printf(sb, " actual retry count: %d", - scsi_2btoul( - &sense->sense_key_spec[1])); - break; - default: - sbuf_printf(sb, " sks:%#x,%#x", - sense->sense_key_spec[0], - scsi_2btoul( - &sense->sense_key_spec[1])); - break; - } - } - break; - - } - default: - sbuf_printf(sb, "Error code 0x%x", sense->error_code); - if (sense->error_code & SSD_ERRCODE_VALID) { - sbuf_printf(sb, " at block no. %d (decimal)", - info = scsi_4btoul(sense->info)); - } - } - - sbuf_printf(sb, "\n"); - + scsi_sense_only_sbuf(sense, sb, path_str, inq_data, cdb, csio->cdb_len); + #ifdef _KERNEL xpt_free_ccb((union ccb*)cgd); #endif /* _KERNEL/!_KERNEL */ Index: sys/cam/scsi/smp_all.h =================================================================== --- sys/cam/scsi/smp_all.h (revision 225710) +++ sys/cam/scsi/smp_all.h (working copy) @@ -27,7 +27,7 @@ * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGES. * - * $Id: //depot/users/kenm/FreeBSD-test/sys/cam/scsi/smp_all.h#4 $ + * $Id$ * $FreeBSD$ */ Index: sys/dev/mly/mly.c =================================================================== --- sys/dev/mly/mly.c (revision 225710) +++ sys/dev/mly/mly.c (working copy) @@ -1294,10 +1294,12 @@ static void mly_process_event(struct mly_softc *sc, struct mly_event *me) { - struct scsi_sense_data *ssd = (struct scsi_sense_data *)&me->sense[0]; - char *fp, *tp; - int bus, target, event, class, action; + struct scsi_sense_data_fixed *ssd; + char *fp, *tp; + int bus, target, event, class, action; + ssd = (struct scsi_sense_data_fixed *)&me->sense[0]; + /* * Errors can be reported using vendor-unique sense data. In this case, the * event code will be 0x1c (Request sense data present), the sense key will Index: sys/dev/firewire/sbp_targ.c =================================================================== --- sys/dev/firewire/sbp_targ.c (revision 225710) +++ sys/dev/firewire/sbp_targ.c (working copy) @@ -41,6 +41,7 @@ #include #include #include +#include #if __FreeBSD_version < 500000 #include #endif @@ -632,6 +633,11 @@ { struct sbp_cmd_status *sbp_cmd_status; struct scsi_sense_data *sense; + int error_code, sense_key, asc, ascq; + uint8_t stream_bits; + uint8_t sks[3]; + uint64_t info; + int64_t sinfo; if (debug) printf("%s: STATUS %d\n", __func__, @@ -659,36 +665,75 @@ #endif #endif - if ((sense->error_code & SSD_ERRCODE) == SSD_CURRENT_ERROR) + scsi_extract_sense(sense, &error_code, &sense_key, &asc, + &ascq); + + switch (error_code) { + case SSD_CURRENT_ERROR: + case SSD_DESC_CURRENT_ERROR: sbp_cmd_status->sfmt = SBP_SFMT_CURR; - else + break; + default: sbp_cmd_status->sfmt = SBP_SFMT_DEFER; + break; + } - sbp_cmd_status->valid = (sense->error_code & SSD_ERRCODE_VALID) - ? 1 : 0; - sbp_cmd_status->s_key = sense->flags & SSD_KEY; - sbp_cmd_status->mark = (sense->flags & SSD_FILEMARK)? 1 : 0; - sbp_cmd_status->eom = (sense->flags & SSD_EOM) ? 1 : 0; - sbp_cmd_status->ill_len = (sense->flags & SSD_ILI) ? 1 : 0; + if (scsi_get_sense_info(sense, SSD_DESC_INFO, &info, + &sinfo) == 0) { + uint32_t info_trunc; + sbp_cmd_status->valid = 1; + info_trunc = info; - bcopy(&sense->info[0], &sbp_cmd_status->info, 4); + sbp_cmd_status->info = htobe32(info_trunc); + } else { + sbp_cmd_status->valid = 0; + } - if (sense->extra_len <= 6) - /* add_sense_code(_qual), info, cmd_spec_info */ - sbp_status->len = 4; - else - /* fru, sense_key_spec */ + sbp_cmd_status->s_key = sense_key; + + if (scsi_get_stream_info(sense, NULL, &stream_bits) == 0) { + sbp_cmd_status->mark = + (stream_bits & SSD_FILEMARK) ? 1 : 0; + sbp_cmd_status->eom = + (stream_bits & SSD_EOM) ? 1 : 0; + sbp_cmd_status->ill_len = + (stream_bits & SSD_ILI) ? 1 : 0; + } else { + sbp_cmd_status->mark = 0; + sbp_cmd_status->eom = 0; + sbp_cmd_status->ill_len = 0; + } + + + /* add_sense_code(_qual), info, cmd_spec_info */ + sbp_status->len = 4; + + if (scsi_get_sense_info(sense, SSD_DESC_COMMAND, &info, + &sinfo) == 0) { + uint32_t cmdspec_trunc; + + cmdspec_trunc = info; + + sbp_cmd_status->cdb = htobe32(cmdspec_trunc); + + } + + sbp_cmd_status->s_code = asc; + sbp_cmd_status->s_qlfr = ascq; + + if (scsi_get_sense_info(sense, SSD_DESC_FRU, &info, + &sinfo) == 0) { + sbp_cmd_status->fru = (uint8_t)info; sbp_status->len = 5; - - bcopy(&sense->cmd_spec_info[0], &sbp_cmd_status->cdb, 4); + } else { + sbp_cmd_status->fru = 0; + } - sbp_cmd_status->s_code = sense->add_sense_code; - sbp_cmd_status->s_qlfr = sense->add_sense_code_qual; - sbp_cmd_status->fru = sense->fru; + if (scsi_get_sks(sense, sks) == 0) { + bcopy(sks, &sbp_cmd_status->s_keydep[0], sizeof(sks)); + sbp_status->len = 5; + } - bcopy(&sense->sense_key_spec[0], - &sbp_cmd_status->s_keydep[0], 3); - break; } default: Index: sys/dev/firewire/sbp.c =================================================================== --- sys/dev/firewire/sbp.c (revision 225710) +++ sys/dev/firewire/sbp.c (working copy) @@ -1515,10 +1515,10 @@ sbp_scsi_status(struct sbp_status *sbp_status, struct sbp_ocb *ocb) { struct sbp_cmd_status *sbp_cmd_status; - struct scsi_sense_data *sense; + struct scsi_sense_data_fixed *sense; sbp_cmd_status = (struct sbp_cmd_status *)sbp_status->data; - sense = &ocb->ccb->csio.sense_data; + sense = (struct scsi_sense_data_fixed *)&ocb->ccb->csio.sense_data; SBP_DEBUG(0) sbp_print_scsi_cmd(ocb); Index: sys/dev/ciss/ciss.c =================================================================== --- sys/dev/ciss/ciss.c (revision 225710) +++ sys/dev/ciss/ciss.c (working copy) @@ -3255,7 +3255,7 @@ #ifdef CISS_DEBUG { struct scsi_sense_data *sns = (struct scsi_sense_data *)&ce->sense_info[0]; - debug(0, "sense key %x", sns->flags & SSD_KEY); + debug(0, "sense key %x", scsi_get_sense_key(sns)); } #endif break; Index: sys/dev/iir/iir.c =================================================================== --- sys/dev/iir/iir.c (revision 225710) +++ sys/dev/iir/iir.c (working copy) @@ -1839,13 +1839,20 @@ } else { /* error */ if (gccb->gc_service == GDT_CACHESERVICE) { + struct scsi_sense_data *sense; + ccb->ccb_h.status |= CAM_SCSI_STATUS_ERROR | CAM_AUTOSNS_VALID; ccb->ccb_h.status &= ~CAM_SIM_QUEUED; ccb->csio.scsi_status = SCSI_STATUS_CHECK_COND; bzero(&ccb->csio.sense_data, ccb->csio.sense_len); - ccb->csio.sense_data.error_code = - SSD_CURRENT_ERROR | SSD_ERRCODE_VALID; - ccb->csio.sense_data.flags = SSD_KEY_NOT_READY; + sense = &ccb->csio.sense_data; + scsi_set_sense_data(sense, + /*sense_format*/ SSD_TYPE_NONE, + /*current_error*/ 1, + /*sense_key*/ SSD_KEY_NOT_READY, + /*asc*/ 0x4, + /*ascq*/ 0x01, + SSD_ELEM_NONE); gdt->sc_dvr.size = sizeof(gdt->sc_dvr.eu.sync); gdt->sc_dvr.eu.sync.ionode = gdt->sc_hanum; Index: sys/dev/iscsi/initiator/iscsi_subr.c =================================================================== --- sys/dev/iscsi/initiator/iscsi_subr.c (revision 225710) +++ sys/dev/iscsi/initiator/iscsi_subr.c (working copy) @@ -153,6 +153,7 @@ scsi_rsp_t *cmd = &pp->ipdu.scsi_rsp; caddr_t bp; int sense_len, mustfree = 0; + int error_code, sense_key, asc, ascq; bp = mtod(pq->mp, caddr_t); if((sense_len = scsi_2btoul(bp)) == 0) @@ -174,10 +175,13 @@ scsi->sense_resid = 0; if(cmd->flag & (BIT(1)|BIT(2))) scsi->sense_resid = ntohl(pp->ipdu.scsi_rsp.rcnt); + + scsi_extract_sense(sense, &error_code, &sense_key, &asc, &ascq); + debug(3, "sense_len=%d rcnt=%d sense_resid=%d dsl=%d error_code=%x flags=%x", sense_len, ntohl(pp->ipdu.scsi_rsp.rcnt), scsi->sense_resid, - pp->ds_len, sense->error_code, sense->flags); + pp->ds_len, error_code, sense_key); if(mustfree) free(bp, M_ISCSI); Index: sys/dev/usb/storage/umass.c =================================================================== --- sys/dev/usb/storage/umass.c (revision 225710) +++ sys/dev/usb/storage/umass.c (working copy) @@ -2344,14 +2344,14 @@ */ if ((sc->sc_quirks & (NO_INQUIRY_EVPD | NO_INQUIRY)) && (sc->sc_transfer.cmd_data[1] & SI_EVPD)) { - struct scsi_sense_data *sense; - sense = &ccb->csio.sense_data; - bzero(sense, sizeof(*sense)); - sense->error_code = SSD_CURRENT_ERROR; - sense->flags = SSD_KEY_ILLEGAL_REQUEST; - sense->add_sense_code = 0x24; - sense->extra_len = 10; + scsi_set_sense_data(&ccb->csio.sense_data, + /*sense_format*/ SSD_TYPE_NONE, + /*current_error*/ 1, + /*sense_key*/ SSD_KEY_ILLEGAL_REQUEST, + /*asc*/ 0x24, + /*ascq*/ 0x00, + /*extra args*/ SSD_ELEM_NONE); ccb->csio.scsi_status = SCSI_STATUS_CHECK_COND; ccb->ccb_h.status = CAM_SCSI_STATUS_ERROR | CAM_AUTOSNS_VALID; @@ -2631,21 +2631,22 @@ uint8_t status) { uint8_t *cmd; - uint8_t key; switch (status) { case STATUS_CMD_OK: case STATUS_CMD_UNKNOWN: - case STATUS_CMD_FAILED: + case STATUS_CMD_FAILED: { + int error_code, key, asc, ascq; + scsi_extract_sense(&ccb->csio.sense_data, &error_code, + &key, &asc, &ascq); + if (ccb->csio.ccb_h.flags & CAM_CDB_POINTER) { cmd = (uint8_t *)(ccb->csio.cdb_io.cdb_ptr); } else { cmd = (uint8_t *)(ccb->csio.cdb_io.cdb_bytes); } - key = (ccb->csio.sense_data.flags & SSD_KEY); - /* * Getting sense data always succeeds (apart from wire * failures): @@ -2704,7 +2705,7 @@ } xpt_done(ccb); break; - + } default: DPRINTF(sc, UDMASS_SCSI, "Autosense failed, " "status %d\n", status); Index: sys/dev/isp/isp_freebsd.h =================================================================== --- sys/dev/isp/isp_freebsd.h (revision 225710) +++ sys/dev/isp/isp_freebsd.h (working copy) @@ -440,9 +440,9 @@ #define XS_SNSLEN(ccb) \ imin((sizeof((ccb)->sense_data)), ccb->sense_len) -#define XS_SNSKEY(ccb) ((ccb)->sense_data.flags & 0xf) -#define XS_SNSASC(ccb) ((ccb)->sense_data.add_sense_code) -#define XS_SNSASCQ(ccb) ((ccb)->sense_data.add_sense_code_qual) +#define XS_SNSKEY(ccb) (scsi_get_sense_key(&(ccb)->sense_data)) +#define XS_SNSASC(ccb) (scsi_get_asc(&(ccb)->sense_data)) +#define XS_SNSASCQ(ccb) (scsi_get_ascq(&(ccb)->sense_data)) #define XS_TAG_P(ccb) \ (((ccb)->ccb_h.flags & CAM_TAG_ACTION_VALID) && \ (ccb)->tag_action != CAM_TAG_ACTION_NONE) --ibTvN161/egqYuK8-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 01:15:08 2011 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 92C19106564A; Fri, 23 Sep 2011 01:15:08 +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 5CE9F8FC08; Fri, 23 Sep 2011 01:15:08 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p8N1F7KY052100; Thu, 22 Sep 2011 21:15:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p8N1F7bg052003; Fri, 23 Sep 2011 01:15:07 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 23 Sep 2011 01:15:07 GMT Message-Id: <201109230115.p8N1F7bg052003@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 i386/i386 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: Fri, 23 Sep 2011 01:15:08 -0000 TB --- 2011-09-22 21:50:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-09-22 21:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-09-22 21:50:00 - cleaning the object tree TB --- 2011-09-22 21:50:47 - cvsupping the source tree TB --- 2011-09-22 21:50:47 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-09-22 21:56:11 - building world TB --- 2011-09-22 21:56:11 - MAKEOBJDIRPREFIX=/obj TB --- 2011-09-22 21:56:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-09-22 21:56:11 - TARGET=i386 TB --- 2011-09-22 21:56:11 - TARGET_ARCH=i386 TB --- 2011-09-22 21:56:11 - TZ=UTC TB --- 2011-09-22 21:56:11 - __MAKE_CONF=/dev/null TB --- 2011-09-22 21:56:11 - cd /src TB --- 2011-09-22 21:56:11 - /usr/bin/make -B buildworld >>> World build started on Thu Sep 22 21:56:11 UTC 2011 >>> 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 Thu Sep 22 23:59:38 UTC 2011 TB --- 2011-09-22 23:59:38 - generating LINT kernel config TB --- 2011-09-22 23:59:38 - cd /src/sys/i386/conf TB --- 2011-09-22 23:59:38 - /usr/bin/make -B LINT TB --- 2011-09-22 23:59:38 - building LINT kernel TB --- 2011-09-22 23:59:38 - MAKEOBJDIRPREFIX=/obj TB --- 2011-09-22 23:59:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-09-22 23:59:38 - TARGET=i386 TB --- 2011-09-22 23:59:38 - TARGET_ARCH=i386 TB --- 2011-09-22 23:59:38 - TZ=UTC TB --- 2011-09-22 23:59:38 - __MAKE_CONF=/dev/null TB --- 2011-09-22 23:59:38 - cd /src TB --- 2011-09-22 23:59:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Sep 22 23:59:38 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri Sep 23 00:30:40 UTC 2011 TB --- 2011-09-23 00:30:40 - cd /src/sys/i386/conf TB --- 2011-09-23 00:30:40 - /usr/sbin/config -m GENERIC TB --- 2011-09-23 00:30:40 - building GENERIC kernel TB --- 2011-09-23 00:30:40 - MAKEOBJDIRPREFIX=/obj TB --- 2011-09-23 00:30:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-09-23 00:30:40 - TARGET=i386 TB --- 2011-09-23 00:30:40 - TARGET_ARCH=i386 TB --- 2011-09-23 00:30:40 - TZ=UTC TB --- 2011-09-23 00:30:40 - __MAKE_CONF=/dev/null TB --- 2011-09-23 00:30:40 - cd /src TB --- 2011-09-23 00:30:40 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Sep 23 00:30:40 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Sep 23 00:55:24 UTC 2011 TB --- 2011-09-23 00:55:24 - cd /src/sys/i386/conf TB --- 2011-09-23 00:55:24 - /usr/sbin/config -m PAE TB --- 2011-09-23 00:55:24 - building PAE kernel TB --- 2011-09-23 00:55:24 - MAKEOBJDIRPREFIX=/obj TB --- 2011-09-23 00:55:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-09-23 00:55:24 - TARGET=i386 TB --- 2011-09-23 00:55:24 - TARGET_ARCH=i386 TB --- 2011-09-23 00:55:24 - TZ=UTC TB --- 2011-09-23 00:55:24 - __MAKE_CONF=/dev/null TB --- 2011-09-23 00:55:24 - cd /src TB --- 2011-09-23 00:55:24 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Fri Sep 23 00:55:25 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Fri Sep 23 01:01:39 UTC 2011 TB --- 2011-09-23 01:01:39 - cd /src/sys/i386/conf TB --- 2011-09-23 01:01:39 - /usr/sbin/config -m XBOX TB --- 2011-09-23 01:01:39 - building XBOX kernel TB --- 2011-09-23 01:01:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-09-23 01:01:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-09-23 01:01:39 - TARGET=i386 TB --- 2011-09-23 01:01:39 - TARGET_ARCH=i386 TB --- 2011-09-23 01:01:39 - TZ=UTC TB --- 2011-09-23 01:01:39 - __MAKE_CONF=/dev/null TB --- 2011-09-23 01:01:39 - cd /src TB --- 2011-09-23 01:01:39 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Fri Sep 23 01:01:40 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Fri Sep 23 01:05:27 UTC 2011 TB --- 2011-09-23 01:05:27 - cd /src/sys/i386/conf TB --- 2011-09-23 01:05:27 - /usr/sbin/config -m XEN TB --- 2011-09-23 01:05:27 - building XEN kernel TB --- 2011-09-23 01:05:27 - MAKEOBJDIRPREFIX=/obj TB --- 2011-09-23 01:05:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-09-23 01:05:27 - TARGET=i386 TB --- 2011-09-23 01:05:27 - TARGET_ARCH=i386 TB --- 2011-09-23 01:05:27 - TZ=UTC TB --- 2011-09-23 01:05:27 - __MAKE_CONF=/dev/null TB --- 2011-09-23 01:05:27 - cd /src TB --- 2011-09-23 01:05:27 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Fri Sep 23 01:05:27 UTC 2011 >>> 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 [...] ===> i2c/controllers (all) ===> i2c/controllers/alpm (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/i2c/controllers/alpm/../../../../pci/alpm.c /src/sys/modules/i2c/controllers/alpm/../../../../pci/alpm.c: In function 'alpm_recvb': /src/sys/modules/i2c/controllers/alpm/../../../../pci/alpm.c:404: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /src/sys/modules/i2c/controllers/alpm. *** Error code 1 Stop in /src/sys/modules/i2c/controllers. *** Error code 1 Stop in /src/sys/modules/i2c. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-09-23 01:15:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-09-23 01:15:06 - ERROR: failed to build XEN kernel TB --- 2011-09-23 01:15:06 - 9415.98 user 1688.76 system 12305.53 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 02:09:03 2011 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 D78111065672 for ; Fri, 23 Sep 2011 02:09:03 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id B34648FC18 for ; Fri, 23 Sep 2011 02:09:03 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 0F11A1CC68; Thu, 22 Sep 2011 23:08:55 -0300 (BRT) Received: from 186.214.131.16 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Thu, 22 Sep 2011 23:08:55 -0300 Message-ID: <103e1ad4999768aac3dbe1285438a4d0.squirrel@eternamente.info> Date: Thu, 22 Sep 2011 23:08:55 -0300 From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Intel Atom Board + 9.0-BETA2 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, 23 Sep 2011 02:09:03 -0000 hail again, has anyone seen these: ACPI Error: Method parse/execution failed [\\_SB_.PCI0.LPC_.SMBR] (Node 0xfffffe00024af9c0), AE_AML_INFINITE_LOOP (20110527/psparse-560) ACPI Error: Method parse/execution failed [\\_SB_.PCI0.LPC_.INIT] (Node 0xfffffe00024afa00), AE_AML_INFINITE_LOOP (20110527/psparse-560) ACPI Error: Method parse/execution failed [\\_GPE._L00] (Node 0xfffffe000220f440), AE_AML_INFINITE_LOOP (20110527/psparse-560) ACPI Exception: AE_AML_INFINITE_LOOP, while evaluating GPE method [_L00] (20110527/evgpe-606) its 9.0-BETA2 amd64. I got it compiling smartmontools and it began, but the box is cold, and after compiled it didn't stop. matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 02:09:08 2011 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 D356F106566B; Fri, 23 Sep 2011 02:09:08 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id B839B8FC08; Fri, 23 Sep 2011 02:09:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; q=dns/txt; s=DKIM-NAME-SERVICES; d=a1poweruser.com; h=From:To:Cc:Subject:Message-ID:X-Sender:X-Envelope-From; l=500; bh=WUtTOtx2knhN8GrrkBZpPmq0+cSLmK4CA3MHZO/fmAg=; b=LcKHoc+Q/TCdpm3+6sopLGpc9NWPuM0jgF3P2ppsWfmpDJLAPPyMelV/rmzamSA+gAGQ2LAUyLs+PkQOqWd2iRpLEVd88hHkdtBeZfGZK9xr0j+au8oa2EttJSwz6Q7cWJE0/qljFHc0F8XXGgPrkSty2tbVuD6ISYQ2PMiRSPg= Received: from [192.168.1.64] ([76.240.47.196]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Sep 2011 19:09:08 -0700 Message-ID: <4E7BEA42.4020004@a1poweruser.com> Date: Thu, 22 Sep 2011 22:09:06 -0400 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: FreeBSD Questions , freebsd-current@freebsd.org, Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Sep 2011 02:09:08.0640 (UTC) FILETIME=[C7392200:01CC7995] X-Sender: fbsd8@a1poweruser.com X-Envelope-From: fbsd8*a1poweruser.com Cc: Subject: 9.0 bsdinstall usage 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, 23 Sep 2011 02:09:08 -0000 I have installed 9.0 bata2 from cd and the net. In both cases after the completion of the install and rebooting, the bsdinstall scripts still remain on the new installed system. If I interpret the code logic correctly, bsdinstall can ONLY be used for an original install. It's not intended by design to be used any other time, unlike sysinstall. I think the "auto" script should have code added to remove all traces of the bsdinstall environment at the conclusion of the install. This way bsdinstall fulfills the original design goals and guarantees no one can exec it by accident and kill there running system. From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 02:09:30 2011 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 51E55106566C for ; Fri, 23 Sep 2011 02:09:30 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id 2DE148FC14 for ; Fri, 23 Sep 2011 02:09:30 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 158261CC68; Thu, 22 Sep 2011 23:09:22 -0300 (BRT) Received: from 186.214.131.16 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Thu, 22 Sep 2011 23:09:22 -0300 Message-ID: <0358f925e942c18628143030983146c5.squirrel@eternamente.info> In-Reply-To: <201109171602.17184.tijl@coosemans.org> References: <9d0932ce5781f670052d22d81434b11d.squirrel@eternamente.info> <201109171602.17184.tijl@coosemans.org> Date: Thu, 22 Sep 2011 23:09:22 -0300 From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: ataidle + notebook hdd + 9.0-BETA2 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, 23 Sep 2011 02:09:30 -0000 On Sat, September 17, 2011 11:02, Tijl Coosemans wrote: > On Wednesday 14 September 2011 05:59:05 Nenhum_de_Nos wrote: >> I just installed BETA2 on WD notebook disk: >> >> ada0 at ata2 bus 0 scbus1 target 0 lun 0 >> ada0: ATA-8 SATA 2.x device >> ada0: 150.000MB/s transfers (SATA, UDMA5, PIO 8192bytes) >> ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) >> ada0: Previously was known as ad4 >> >> and tried as usual to make the disk last a little longer: >> >> rush# ataidle -P 243 /dev/ad4 >> ataidle: error: identify device /dev/ad4 >> >> rush# ataidle -P 243 /dev/ada0 >> (pass0:ata2:0:0:0): SETFEATURES. ACB: ef 05 00 00 00 40 00 00 00 00 f3 >> 00 >> (pass0:ata2:0:0:0): CAM status: CCB request completed with an error >> Failed to configure APM: No error: 0 >> >> so, is this still needed after ada took place ? How can I do it now if >> needed ? > > Until a more elegant solution is found you can set the APM value like > this: > > camcontrol cmd ada0 -a "EF 05 00 00 00 00 00 00 00 00 F3 00" > > EF is setfeature command > 05 enables APM feature > F3 is 243 > > To disable APM you can use: > > camcontrol cmd ada0 -a "EF 85 00 00 00 00 00 00 00 00 00 00" > > You can check the value with: > > camcontrol identify ada0 thanks, problem solved :) matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 02:20:19 2011 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 81A94106566B; Fri, 23 Sep 2011 02:20:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1B27E8FC13; Fri, 23 Sep 2011 02:20:18 +0000 (UTC) Received: by ywp17 with SMTP id 17so3053081ywp.13 for ; Thu, 22 Sep 2011 19:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nnsZ35a0NpI9Ni5FO+He9lFNTC+Akhat+yn8DFVLDmA=; b=GbhQCY+VsE7cOk5sqkRGUGoao4ZyDhGrx3khHt04NNIRCI0eoQjVXQ4YkwrHY0nlt+ AojoHHV5wy++kGYZRWEtHnGIS58CfEft2F9KekLAc38keigLNdLkmf87rkpZkBddcFXF OyvWs80xeO1Ci6jIeWb6kF81wIk9du4D4icS4= MIME-Version: 1.0 Received: by 10.236.176.65 with SMTP id a41mr18668592yhm.72.1316744418388; Thu, 22 Sep 2011 19:20:18 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Thu, 22 Sep 2011 19:20:18 -0700 (PDT) In-Reply-To: <4E7BEA42.4020004@a1poweruser.com> References: <4E7BEA42.4020004@a1poweruser.com> Date: Fri, 23 Sep 2011 10:20:18 +0800 X-Google-Sender-Auth: LNeFGzP8YkAmWEnoKwKI6nSQd84 Message-ID: From: Adrian Chadd To: Fbsd8 Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, FreeBSD Questions , Nathan Whitehorn Subject: Re: 9.0 bsdinstall usage 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, 23 Sep 2011 02:20:19 -0000 On 23 September 2011 10:09, Fbsd8 wrote: > I have installed 9.0 bata2 from cd and the net. In both cases after the > completion of the install and rebooting, the bsdinstall scripts still remain > on the new installed system. If I interpret the code logic correctly, > bsdinstall can ONLY be used for an original install. It's not intended by > design to be used any other time, unlike sysinstall. I think the "auto" > script should have code added to remove all traces of the bsdinstall > environment at the conclusion of the install. This way bsdinstall fulfills > the original design goals and guarantees no one can exec it by accident and > kill there running system. Have you thought about filing PRs for your installer suggestions, just so they don't get lost? I've just filed a bsdinstaller PR for a wifi config bug; I'm likely going to file a few more PRs based on my interaction with the installer. Thanks, Adrian From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 02:49:53 2011 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 A84D4106564A for ; Fri, 23 Sep 2011 02:49:53 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 7F8AA8FC08 for ; Fri, 23 Sep 2011 02:49:53 +0000 (UTC) Received: from draco.over-yonder.net (c-174-50-4-38.hsd1.ms.comcast.net [174.50.4.38]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 5899A37B50E; Thu, 22 Sep 2011 21:49:52 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id AC298178F5; Thu, 22 Sep 2011 21:49:51 -0500 (CDT) Date: Thu, 22 Sep 2011 21:49:51 -0500 From: "Matthew D. Fuller" To: Thomas Mueller Message-ID: <20110923024951.GJ14862@over-yonder.net> References: <20110920210906.GG14862@over-yonder.net> <20110921082649.9616D1065672@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110921082649.9616D1065672@hub.freebsd.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.2 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: 9.0 beta2 & the new bsdinstaller 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, 23 Sep 2011 02:49:53 -0000 On Wed, Sep 21, 2011 at 08:26:47AM +0000 I heard the voice of Thomas Mueller, and lo! it spake thus: > > I don't think there is any particular advantage in aligning GPT > partitions on 1 MB boundaries. No, but it's biiiig, and roooound! (http://dilbert.com/fast/1994-03-24/) It's a nice round number, and with even the by-modern-standards smallish drives I was using, it rounds to 0 "wasted" space. So I figured, what does it hurt? My mail was just to say IWBNI the hurt was more "Hey, this probably isn't going to work, are you sure?" rather than "Hahaha, you think you can boot?? Sucker!" -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 04:41:02 2011 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 5A991106566B for ; Fri, 23 Sep 2011 04:41:02 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id C42548FC08 for ; Fri, 23 Sep 2011 04:41:01 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p8N4emqg030775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Sep 2011 14:10:54 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: <4E7BEA42.4020004@a1poweruser.com> Date: Fri, 23 Sep 2011 14:10:47 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <94B70CFD-D1EA-4C64-8384-BBE00185280D@gsoft.com.au> References: <4E7BEA42.4020004@a1poweruser.com> To: Fbsd8 X-Mailer: Apple Mail (2.1244.3) X-Spam-Score: -4.391 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-current@freebsd.org, FreeBSD Questions , Nathan Whitehorn Subject: Re: 9.0 bsdinstall usage 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, 23 Sep 2011 04:41:02 -0000 On 23/09/2011, at 11:39, Fbsd8 wrote: > I have installed 9.0 bata2 from cd and the net. In both cases after = the completion of the install and rebooting, the bsdinstall scripts = still remain on the new installed system. If I interpret the code logic = correctly, bsdinstall can ONLY be used for an original install. It's not = intended by design to be used any other time, unlike sysinstall. I think = the "auto" script should have code added to remove all traces of the = bsdinstall environment at the conclusion of the install. This way = bsdinstall fulfills the original design goals and guarantees no one can = exec it by accident and kill there running system. The binary is installed by default, but there it isn't run at startup. If it is being run then I would expect you are booting off your install = media again by accident. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 08:21:44 2011 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 C45401065670; Fri, 23 Sep 2011 08:21:44 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id 9924B8FC0A; Fri, 23 Sep 2011 08:21:44 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LRY00A00V87CY00@smtpauth1.wiscmail.wisc.edu>; Fri, 23 Sep 2011 03:21:43 -0500 (CDT) Received: from wanderer.tachypleus.net (78-70-168-180-no110.tbcn.telia.com [78.70.168.180]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LRY004VOV852F10@smtpauth1.wiscmail.wisc.edu>; Fri, 23 Sep 2011 03:21:42 -0500 (CDT) Date: Fri, 23 Sep 2011 10:21:28 +0200 From: Nathan Whitehorn In-reply-to: <4E7BEA42.4020004@a1poweruser.com> To: Fbsd8 Message-id: <4E7C4188.2050508@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=78.70.168.180 X-Spam-PmxInfo: Server=avs-13, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.9.23.81214, SenderIP=78.70.168.180 References: <4E7BEA42.4020004@a1poweruser.com> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110917 Thunderbird/6.0.2 Cc: freebsd-current@freebsd.org, FreeBSD Questions Subject: Re: 9.0 bsdinstall usage 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, 23 Sep 2011 08:21:44 -0000 On 09/23/11 04:09, Fbsd8 wrote: > I have installed 9.0 bata2 from cd and the net. In both cases after the > completion of the install and rebooting, the bsdinstall scripts still > remain on the new installed system. If I interpret the code logic > correctly, bsdinstall can ONLY be used for an original install. It's not > intended by design to be used any other time, unlike sysinstall. I think > the "auto" script should have code added to remove all traces of the > bsdinstall environment at the conclusion of the install. This way > bsdinstall fulfills the original design goals and guarantees no one can > exec it by accident and kill there running system. It's quite useful after install time for installing new systems (e.g. jails). It also uses approximately zero disk space. -Nathan From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 13:23:56 2011 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 2B74F1065679; Fri, 23 Sep 2011 13:23:56 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id F33A28FC08; Fri, 23 Sep 2011 13:23:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; q=dns/txt; s=DKIM-NAME-SERVICES; d=a1poweruser.com; h=From:To:Cc:Subject:Message-ID:X-Sender:X-Envelope-From; l=500; bh=g2CjeT3ApLK2NZOFiGzJiKUXyp6HdiF2oeExcYdl86k=; b=gSq6w4XCNZ2BEaoHOTpuAnjNVEzMWeRi23gqO6wynY4V1/4yhPRjGbUk9zxABdmlsce9WiQFK6bI835hVEl0/H132UzRM+AeWhOdpvIxpI/Qp5I8d0HMqgvPUIiZfeggNRHTFWlRa/F2Nn9QFE6nr0dythM2TYPSp5OszD3qmkg= Received: from [192.168.1.64] ([76.240.47.196]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Sep 2011 06:23:51 -0700 Message-ID: <4E7C885F.10100@a1poweruser.com> Date: Fri, 23 Sep 2011 09:23:43 -0400 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Nathan Whitehorn References: <4E7BEA42.4020004@a1poweruser.com> <4E7C4188.2050508@freebsd.org> In-Reply-To: <4E7C4188.2050508@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Sep 2011 13:23:51.0241 (UTC) FILETIME=[08BBD390:01CC79F4] X-Sender: fbsd8@a1poweruser.com X-Envelope-From: fbsd8*a1poweruser.com Cc: freebsd-current@freebsd.org, FreeBSD Questions Subject: Re: 9.0 bsdinstall usage 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, 23 Sep 2011 13:23:56 -0000 Nathan Whitehorn wrote: > On 09/23/11 04:09, Fbsd8 wrote: >> I have installed 9.0 bata2 from cd and the net. In both cases after the >> completion of the install and rebooting, the bsdinstall scripts still >> remain on the new installed system. If I interpret the code logic >> correctly, bsdinstall can ONLY be used for an original install. It's not >> intended by design to be used any other time, unlike sysinstall. I think >> the "auto" script should have code added to remove all traces of the >> bsdinstall environment at the conclusion of the install. This way >> bsdinstall fulfills the original design goals and guarantees no one can >> exec it by accident and kill there running system. > > It's quite useful after install time for installing new systems (e.g. > jails). It also uses approximately zero disk space. > -Nathan > > bsdinstall/auto logic falls down through the partition hard drive logic with no way to bypass it. It will look for free space on the H.D. you booted from and issue message about no free space, ask you if you want to try another drive and then use the booted drive as target to redo the partitioning again thus scratching your running system. In the normal sense there is no way bsdinstall can be used to create jails. A jail does not occupies a whole H.D nor do you boot a jail as a standalone host. The qjail port is there for the purpose of creating and administration of jails. Its not a question of how much space bsdinstall occupies on the H.D. after the original install. Its that some poor soul may try to use it and trash there newly installed running system by accident. And if there were multiple os's on that H.D. there all gone in a heart beat. We have to protect the poor user from them selfs doing stupid things. As I understand it bsdinstall is a replacement for sysinstall. Sysinstall tried to be everything to everybody and turned into a can of worms. There is nothing wrong about limiting bsdinstall to a roll of "original installs" only. KISS These 2 statements should be added at the end of bsdinstall/auto to complete the clean up of the install process. rm /usr/sbin/bsdinstall rm -rf /usr/libexec/bsdinstall Another benefit of doing this is it will no longer be necessary to create man pages for bsdinstall. From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 13:33:56 2011 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 C0F36106566C; Fri, 23 Sep 2011 13:33:56 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id A54818FC16; Fri, 23 Sep 2011 13:33:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; q=dns/txt; s=DKIM-NAME-SERVICES; d=a1poweruser.com; h=From:To:Cc:Subject:Message-ID:X-Sender:X-Envelope-From; l=500; bh=UnyuxQwU7n9lH5SxTW48ZUYU2IWmJRlX9rnFYZdPKeo=; b=f/Ayy4NoRJFaLXYjo7s/RAjuTOehoTG9zCr5rCB5VBfRCfcJEiZtZSMvPJdxz1E0B/g4Bat8XKwS7NzG9GIbgIkAvtWxQDylR+Q35EQRsaS/Jpqm2m/BtQUN79B9I1h56fpLAgCUyG7fuRvQ/TTslWLVHV174hiGeYWNqqpkdm8= Received: from [192.168.1.64] ([76.240.47.196]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Sep 2011 06:33:56 -0700 Message-ID: <4E7C8AC2.6020704@a1poweruser.com> Date: Fri, 23 Sep 2011 09:33:54 -0400 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Daniel O'Connor References: <4E7BEA42.4020004@a1poweruser.com> <94B70CFD-D1EA-4C64-8384-BBE00185280D@gsoft.com.au> In-Reply-To: <94B70CFD-D1EA-4C64-8384-BBE00185280D@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Sep 2011 13:33:56.0862 (UTC) FILETIME=[71B641E0:01CC79F5] X-Sender: fbsd8@a1poweruser.com X-Envelope-From: fbsd8*a1poweruser.com Cc: freebsd-current@freebsd.org, FreeBSD Questions Subject: Re: 9.0 bsdinstall usage 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, 23 Sep 2011 13:33:56 -0000 Daniel O'Connor wrote: > On 23/09/2011, at 11:39, Fbsd8 wrote: >> I have installed 9.0 bata2 from cd and the net. >>In both cases after the completion of the install and rebooting, the bsdinstall >>scripts still remain on the new installed system. If I interpret the code logic correctly, >>bsdinstall can ONLY be used for an original install. It's not intended by design to be >>used any other time, unlike sysinstall. I think the "auto" script should have code added >>to remove all traces of the bsdinstall environment at the conclusion of the install. >>This way bsdinstall fulfills the original design goals and guarantees no one can exec >>it by accident and kill there running system. > > > The binary is installed by default, but there it isn't run at startup. > > If it is being run then I would expect you are booting off your install media again by accident. > > -- > Daniel O'Connor > You did not read my post correctly. I dont say bsdinstall is run every time I boot. I said "the bsdinstall scripts still remain on the new installed system." The point I was making is it should not remain. From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 13:40:57 2011 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 7A0331065670; Fri, 23 Sep 2011 13:40:57 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id 5D2618FC08; Fri, 23 Sep 2011 13:40:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; q=dns/txt; s=DKIM-NAME-SERVICES; d=a1poweruser.com; h=From:To:Cc:Subject:Message-ID:X-Sender:X-Envelope-From; l=500; bh=g7mSSH0DKvkc9US00lbuNIz9UwUNp3P2gK8ZHUGupo8=; b=h4edN+qz6vLhzqkXEY7D4VCdCTUJTcjkuP90Y3eXGgeaqCUW30SUEGyMJnwS44uihnrF/YtuSwsvChRfYmFpKwqsstIIG+fPrFNNZjsaE5C9lZ+ULmTFbbam6XXKJNjIeoMOvDUVQRRNtj5TrMZ1yAod3k6fVIBTAnFePMyBAHs= Received: from [192.168.1.64] ([76.240.47.196]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Sep 2011 06:40:57 -0700 Message-ID: <4E7C8C67.2090709@a1poweruser.com> Date: Fri, 23 Sep 2011 09:40:55 -0400 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Adrian Chadd References: <4E7BEA42.4020004@a1poweruser.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Sep 2011 13:40:57.0649 (UTC) FILETIME=[6C854210:01CC79F6] X-Sender: fbsd8@a1poweruser.com X-Envelope-From: fbsd8*a1poweruser.com Cc: freebsd-current@freebsd.org, FreeBSD Questions Subject: Re: 9.0 bsdinstall usage 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, 23 Sep 2011 13:40:57 -0000 Adrian Chadd wrote: > On 23 September 2011 10:09, Fbsd8 wrote: >> I have installed 9.0 bata2 from cd and the net. In both cases after the >> completion of the install and rebooting, the bsdinstall scripts still remain >> on the new installed system. If I interpret the code logic correctly, >> bsdinstall can ONLY be used for an original install. It's not intended by >> design to be used any other time, unlike sysinstall. I think the "auto" >> script should have code added to remove all traces of the bsdinstall >> environment at the conclusion of the install. This way bsdinstall fulfills >> the original design goals and guarantees no one can exec it by accident and >> kill there running system. > > Have you thought about filing PRs for your installer suggestions, just > so they don't get lost? > > I've just filed a bsdinstaller PR for a wifi config bug; I'm likely > going to file a few more PRs based on my interaction with the > installer. > > Thanks, > > > Adrian > > Yes I have been submitting PR's. From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 13:55:53 2011 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 0D235106566C; Fri, 23 Sep 2011 13:55:53 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id E3AE48FC15; Fri, 23 Sep 2011 13:55:51 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-8-217.lns20.adl2.internode.on.net [118.210.8.217]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id p8NDtasK068117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Sep 2011 23:25:43 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: <4E7C8AC2.6020704@a1poweruser.com> Date: Fri, 23 Sep 2011 23:25:36 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <3A411FD7-7C07-4536-9EDD-8F5D8F716027@gsoft.com.au> References: <4E7BEA42.4020004@a1poweruser.com> <94B70CFD-D1EA-4C64-8384-BBE00185280D@gsoft.com.au> <4E7C8AC2.6020704@a1poweruser.com> To: Fbsd8 X-Mailer: Apple Mail (2.1244.3) X-Spam-Score: 2.162 (**) BAYES_00,KHOP_DYNAMIC,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-current@freebsd.org, FreeBSD Questions Subject: Re: 9.0 bsdinstall usage 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, 23 Sep 2011 13:55:53 -0000 On 23/09/2011, at 23:03, Fbsd8 wrote: >> The binary is installed by default, but there it isn't run at = startup. >> If it is being run then I would expect you are booting off your = install media again by accident. >> -- >> Daniel O'Connor=20 >=20 > You did not read my post correctly. I dont say bsdinstall is run every = time I boot. I said "the bsdinstall scripts still remain on the new = installed system." The point I was making is it should not remain. I think that is pretty debatable, you could certainly use them to = install onto a new disk - say you had a machine you couldn't boot the = install media off so you put the disk in your PC. Also, it should be very difficult to destroy your installed setup while = you're actually booted into it because GEOM will prevent partition = changes to mounted disks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 14:15:01 2011 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 6258A106564A for ; Fri, 23 Sep 2011 14:15:01 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with SMTP id 0DCD98FC13 for ; Fri, 23 Sep 2011 14:15:00 +0000 (UTC) Received: (qmail 85580 invoked by uid 0); 23 Sep 2011 09:57:59 -0400 Received: from unknown (HELO schism.local) (gjb@75.146.225.65) by 0 with SMTP; 23 Sep 2011 09:57:59 -0400 Message-ID: <4E7C9066.2040407@FreeBSD.org> Date: Fri, 23 Sep 2011 09:57:58 -0400 From: Glen Barber User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Fbsd8 References: <4E7BEA42.4020004@a1poweruser.com> <4E7C4188.2050508@freebsd.org> <4E7C885F.10100@a1poweruser.com> In-Reply-To: <4E7C885F.10100@a1poweruser.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, Nathan Whitehorn Subject: Re: 9.0 bsdinstall usage 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, 23 Sep 2011 14:15:01 -0000 On 9/23/11 9:23 AM, Fbsd8 wrote: > We have to protect the poor user from them selfs doing stupid things. > I find your presumptuous "users are stupid" comment rather offensive. But, it did remind me of one of my favorite quotes: "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn -- Glen Barber | gjb@FreeBSD.org FreeBSD Documentation Project From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 14:56:42 2011 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 B1DAE106564A for ; Fri, 23 Sep 2011 14:56:42 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 494018FC13 for ; Fri, 23 Sep 2011 14:56:42 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p8NEue3I006337; Fri, 23 Sep 2011 16:56:40 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p8NEuehx006336; Fri, 23 Sep 2011 16:56:40 +0200 (CEST) (envelope-from marius) Date: Fri, 23 Sep 2011 16:56:40 +0200 From: Marius Strobl To: "Kenneth D. Merry" Message-ID: <20110923145640.GA6316@alchemy.franken.de> References: <20110922193305.GA24939@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110922193305.GA24939@nargothrond.kdm.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org, scsi@freebsd.org Subject: Re: SCSI descriptor sense changes, testing needed 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, 23 Sep 2011 14:56:42 -0000 On Thu, Sep 22, 2011 at 01:33:05PM -0600, Kenneth D. Merry wrote: > > I have attached a set of patches against head that implement SCSI > descriptor sense support for CAM. > > Descriptor sense is a new sense (SCSI error) format introduced in the SPC-3 > spec in 2006. FreeBSD doesn't currently support it. > > Seagate's new 3TB SAS drives come with descriptor sense enabled by default, > and it's possible that other newer drives do as well. Because all the > sense key, additional sense code, and additional sense code qualifier > fields are in different places, the CAM error recovery code will not do the > right thing when it gets descriptor sense. > > These patches do bump up the size of struct scsi_sense_data, and so I have > incremented CAM_VERSION as well. I have discussed this with re@, and it > looks like we'll be putting the changes in before 9.0, so it ships with > support for newer SCSI devices. Hi Ken, as far as I understand this also requires consumers of scsi_sense_data and SSD_FULL_SIZE etc in userland to be recompiled. So while you are at breaking the API and ABI of CAM anyway, could you please take the opportunity to change CAM_XPT_PATH_ID and CAM_BUS_WILDCARD to not use the same value so incorrect uses will fail? Currently, there seems to be a lot of confusion when to use which one, including camcontrol(8) just encoding this as -1: /* * We don't want to rescan or reset the xpt bus. * See above. */ if ((int)bus_result->path_id == -1) continue; Moreover, AFAICT CAM_XPT_PATH_ID corresponds to what the ANSI CAM Draft refers to as "XPT Path ID" and specifies a value of 0xff for. Marius From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 15:26:06 2011 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 62477106566C for ; Fri, 23 Sep 2011 15:26:06 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 001D68FC0C for ; Fri, 23 Sep 2011 15:26:05 +0000 (UTC) Received: by wyj26 with SMTP id 26so1394149wyj.13 for ; Fri, 23 Sep 2011 08:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=UiffjBcSx86lq1Y3fGxRNCLo3S902N/zLD1efGlwDIw=; b=G2DGdh4/VeanZbKgu2o5+LUk/Qe1zZdiVU/CUGcPvaZ3dsXvzLDCWSLc2hFvkWLKXM atR4ibOaY7zEKyCVLinOlq+94xUugCJN9lrsyQUbgC6mDlWpNPn8x47fYmg+hEyAsP9j k+CZbY/2jlg4JV4NWUyu9NjNFrrnyxS6xJFdk= MIME-Version: 1.0 Received: by 10.216.186.79 with SMTP id v57mr3658577wem.72.1316790246783; Fri, 23 Sep 2011 08:04:06 -0700 (PDT) Received: by 10.216.36.134 with HTTP; Fri, 23 Sep 2011 08:04:06 -0700 (PDT) Date: Fri, 23 Sep 2011 17:04:06 +0200 Message-ID: From: "deeptech71@gmail.com" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: 9.0 beta2 & the new bsdinstaller 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, 23 Sep 2011 15:26:06 -0000 Fbsd8 wrote: > 6. At the "Complete screen" when the reboot option is selected the > cd/dvd drive should automatically open so the install media can be > removed just like sysinstall does. If disc1.iso or dvd.iso was installed > to memstick and used to boot from to install the system, then a message > screen should pop out saying the memstick has to be removed now before > the reboot starts. Don't let the reboot occur until the memstick is removed. Do NOT alter! More often than not, (1) you keep floppies, optical discs, and memory sticks in your computer without intending to boot from them, and (2) you'll want to use your BIOS's boot-once functionality (press a specific keyboard button to bring up the media choser menu for that boot; otherwise boot from the hard drives) whenever you do want to boot from floppies, optical discs, or memory sticks. From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 15:29:03 2011 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 68AB11065670; Fri, 23 Sep 2011 15:29:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1A02E8FC0A; Fri, 23 Sep 2011 15:29:02 +0000 (UTC) Received: by gxk26 with SMTP id 26so2489319gxk.13 for ; Fri, 23 Sep 2011 08:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=LkogNfKzKqbF5NNemCjmICu3TtZnNntlzTSJQzfJSlo=; b=YyoP1YDxUgxUs5nmEzvbaFjmHxoQPyaSjyw8Yfc3W08fi8hmmUlbdmVCvW4L7FswlF haV4CGczQsxVNKVDLtvw0l1HMeXMDxXlpuczEvh+9Pxvzef8ce9/1lKTGGyGGPW+VM7+ ESZ4ahJxCZGgfitMjKMGFvLzi6i2/nQeboJeU= MIME-Version: 1.0 Received: by 10.236.176.65 with SMTP id a41mr22899565yhm.72.1316791742513; Fri, 23 Sep 2011 08:29:02 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Fri, 23 Sep 2011 08:29:02 -0700 (PDT) Date: Fri, 23 Sep 2011 23:29:02 +0800 X-Google-Sender-Auth: QGLawnFSGzKJ8BeM8NYeSVIX3KY Message-ID: From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: ath / 802.11n performance issues and timer code 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, 23 Sep 2011 15:29:03 -0000 Hi Alexander, I've been looking at issues with 802.11n RX performance on these MIPS24k based MIPS boards. After doing a bit of digging, I discovered what looked like strange scheduler issues where the RX and TX completion schedulers weren't being invoked quickly. The ath driver schedules these functions using taskqueues. Here's the time keeper configuration for my mips24k board: # sysctl kern.eventtimer kern.eventtimer.choice: MIPS32(800) kern.eventtimer.et.MIPS32.flags: 7 kern.eventtimer.et.MIPS32.frequency: 360000000 kern.eventtimer.et.MIPS32.quality: 800 kern.eventtimer.periodic: 1 kern.eventtimer.timer: MIPS32 kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 When I set kern.eventtimer.periodic=1, the 11n TX/RX performance suddenly jumps to where it should be. Would you mind helping me figure out what the problem is? I didn't think kern.eventtimer.periodic was needed? Thanks, Adrian From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 15:38:40 2011 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 59EE4106564A; Fri, 23 Sep 2011 15:38:40 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from ixe-mta-27.emailfiltering.com (ixe-mta-27-tx.emailfiltering.com [194.116.199.158]) by mx1.freebsd.org (Postfix) with ESMTP id 881F38FC12; Fri, 23 Sep 2011 15:38:39 +0000 (UTC) Received: from mail-gw14.york.ac.uk ([144.32.129.164]) by ixe-mta-27.emailfiltering.com with emfmta (version 4.8.3.54) by TLS id 1295691174 for hselasky@c2i.net; 3a0a1a60edd1a086; Fri, 23 Sep 2011 16:21:08 +0100 Received: from buffy-128.york.ac.uk ([144.32.128.160]:24806) by mail-gw14.york.ac.uk with esmtpsa (SSL3.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1R77Yo-0005mq-VN; Fri, 23 Sep 2011 16:21:06 +0100 X-Authenticated-User: ga9 From: Gavin Atkinson To: Hans Petter Selasky In-Reply-To: <201109222007.19182.hselasky@c2i.net> References: <75E1A2A7D185F841A975979B0906BBA67BCCAB7609@AVEXMB1.qlogic.org> <201109222007.19182.hselasky@c2i.net> Content-Type: text/plain; charset="ASCII" Date: Fri, 23 Sep 2011 16:21:06 +0100 Message-ID: <1316791266.39972.3.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, "freebsd-drivers@freebsd.org" , David Somayajulu Subject: Re: Choosing between DELAY(useconds) and pause() 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, 23 Sep 2011 15:38:40 -0000 On Thu, 2011-09-22 at 20:07 +0200, Hans Petter Selasky wrote: > On Thursday 22 September 2011 19:55:23 David Somayajulu wrote: > > It appears that the pause() function cannot be used in driver functions > > which are invoked early in the boot process. Is there is a kernel api > > which a device driver can use to determine whether to use pause() or > > DELAY(), for delays which are say greater than 10hz - may be even 1 hz ? > > Maybe you want to use something like this: > > if (cold) > DELAY() > else > pause() > > In your code. Note that this still shouldn't be done in your suspend/resume paths, as "cold" isn't set there, however there also appears to be no guarantee that pause() will ever return (as you could be running after the timer has been suspended, or before it resumes). I'm not sure what the correct answer is for suspend/resume code. Gavin From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 16:23:26 2011 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 B4DF2106566B for ; Fri, 23 Sep 2011 16:23:26 +0000 (UTC) (envelope-from peter@netkey.at) Received: from xena.netkey.at (xena.netkey.at [83.64.50.179]) by mx1.freebsd.org (Postfix) with ESMTP id AC8B68FC15 for ; Fri, 23 Sep 2011 16:23:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by xena.netkey.at (Postfix) with ESMTP id 4EDBA8C2804 for ; Fri, 23 Sep 2011 18:08:20 +0200 (CEST) Received: from xena.netkey.at ([127.0.0.1]) by localhost (xena.netkey.at [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 09946-04 for ; Fri, 23 Sep 2011 18:08:18 +0200 (CEST) Received: from xena.netkey.at (localhost [127.0.0.1]) (Authenticated sender: peter@netkey.at) by xena.netkey.at (Postfix) with ESMTPA id D6C668C2803 for ; Fri, 23 Sep 2011 18:08:18 +0200 (CEST) Received: from chello084112169112.22.11.vie.surfer.at ([84.112.169.112]) by xena.netkey.at with HTTP (HTTP/1.1 POST); Fri, 23 Sep 2011 18:08:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 23 Sep 2011 18:08:18 +0200 From: Peter Klett To: Organization: netkey information technology gmbh Message-ID: X-Sender: peter@netkey.at User-Agent: Roundcube Webmail/0.5.3 X-Virus-Scanned: Maia Mailguard Subject: panic without swap partition in single user mode 9.0-BETA2 spoiling cp->ace = 1 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, 23 Sep 2011 16:23:26 -0000 Hello, maybe this is "a bad thing to do", I'm trying to to change the active partition on the device (ada1) which is booted from in single user mode. I changed kern.geom.debugflags to 16. Calling fdisk with -a or -u flags, panics immediately: panic: spoiling cp->ace = 1 Maybe it is related to kern/112707, but I don't know. The panic only occuers, if there is no swap partition enabled. Doing a swapon /dev/ada1s4b for instance before the fdisk call does not yield to the panic. I could not find any mention of this issue in the fdisk(8) or swapon(8), geom(4) has a section about spoiling, but I couldn't figure out how this is related to swaping or fdisk. I can't remember having to use swapon before using fdisk in the past (but I'm not sure...) If this is a requirement, I think it should be documented somewhere in fdisk(8). Note that the panic does also not occur if kern.geom.debugflags is 0. uname -a FreeBSD antec 9.0-BETA2 FreeBSD 9.0-BETA2 #0: Sat Sep 17 12:51:24 CEST 2011 root@antec:/usr/obj/usr/src/sys/GENERIC amd64 Below is a backtrace and the kernel config, I can reproduce the panic every time in this setup, how should I proceed to get more information form the dump? Greetings Peter P.S. FreeBSD-9 rocks! kernel backtrace: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: <118>Terminated <118>. <118>Sep 22 18:43:53 antec syslogd: exiting on signal 15 <6>pid 2139 (hald), uid 560: exited on signal 10 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...3 1 1 0 0 done All buffers synced. lock order reversal: 1st 0xfffffe000d2a7bd8 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1194 2nd 0xfffffe000d31ebd8 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2246 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 __lockmgr_args() at __lockmgr_args+0xdc6 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vputx() at vputx+0x328 dounmount() at dounmount+0x2a8 vfs_unmountall() at vfs_unmountall+0x4c kern_reboot() at kern_reboot+0x7f9 sys_reboot() at sys_reboot+0x68 amd64_syscall() at amd64_syscall+0x3ba Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40e9ac, rsp = 0x7fffffffd6d8, rbp = 0x9b --- lock order reversal: 1st 0xfffffe0006ad4818 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1194 2nd 0xfffffe0006ab0458 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2134 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 __lockmgr_args() at __lockmgr_args+0xdc6 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x7b devfs_allocv() at devfs_allocv+0x13f devfs_root() at devfs_root+0x4d dounmount() at dounmount+0x48e vfs_unmountall() at vfs_unmountall+0x4c kern_reboot() at kern_reboot+0x7f9 sys_reboot() at sys_reboot+0x68 amd64_syscall() at amd64_syscall+0x3ba Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40e9ac, rsp = 0x7fffffffd6d8, rbp = 0x9b --- Uptime: 23m40s Rebooting... cpu_reset: Stopping other CPUs Copyright (c) 1992-2011 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-BETA2 #0: Sat Sep 17 12:51:24 CEST 2011 root@antec:/usr/obj/usr/src/sys/GENERIC amd64 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz (2400.05-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f7 Family = 6 Model = f Stepping = 7 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 4082712576 (3893 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dfde0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xb000-0xb07f mem 0xf6000000-0xf6ffffff,0xe0000000-0xefffffff,0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io uhci0: port 0xe100-0xe11f irq 16 at device 26.0 on pci0 uhci0: LegSup = 0x2f00 usbus0: on uhci0 uhci1: port 0xe200-0xe21f irq 21 at device 26.1 on pci0 uhci1: LegSup = 0x2f00 usbus1: on uhci1 uhci2: port 0xe000-0xe01f irq 18 at device 26.2 on pci0 uhci2: LegSup = 0x2f00 usbus2: on uhci2 ehci0: mem 0xfa104000-0xfa1043ff irq 18 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3: on ehci0 hdac0: mem 0xfa100000-0xfa103fff irq 22 at device 27.0 on pci0 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 19 at device 28.3 on pci0 pci3: on pcib3 atapci0: irq 19 at device 0.0 on pci3 ahci0: on atapci0 ahci0: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ata2: on atapci0 pcib4: irq 16 at device 28.4 on pci0 pci4: on pcib4 re0: port 0xd000-0xd0ff mem 0xf9000000-0xf9000fff irq 16 at device 0.0 on pci4 re0: Using 1 MSI message re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:1a:4d:48:56:e2 uhci3: port 0xe300-0xe31f irq 23 at device 29.0 on pci0 usbus4: on uhci3 uhci4: port 0xe400-0xe41f irq 19 at device 29.1 on pci0 usbus5: on uhci4 uhci5: port 0xe500-0xe51f irq 18 at device 29.2 on pci0 usbus6: on uhci5 ehci1: mem 0xfa105000-0xfa1053ff irq 23 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7: on ehci1 pcib5: at device 30.0 on pci0 pci5: on pcib5 isab0: at device 31.0 on pci0 isa0: on isab0 ahci1: port 0xe600-0xe607,0xe700-0xe703,0xe800-0xe807,0xe900-0xe903,0xea00-0xea1f mem 0xfa106000-0xfa1067ff irq 19 at device 31.2 on pci0 ahci1: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported ahcich2: at channel 0 on ahci1 ahcich3: at channel 1 on ahci1 ahcich4: at channel 2 on ahci1 ahcich5: at channel 3 on ahci1 ahcich6: at channel 4 on ahci1 ahcich7: at channel 5 on ahci1 pci0: at device 31.3 (no driver attached) attimer0: port 0x40-0x43 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x73 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] acpi_perf0: on cpu0 coretemp0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 926092606000926 device_attach: est1 attach returned 6 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 926092606000926 device_attach: est2 attach returned 6 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 926092606000926 device_attach: est3 attach returned 6 p4tcc3: on cpu3 Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x1a7 offMax=0x3d5 hdac0: HDA Codec #2: Realtek ALC885 pcm0: at cad 2 nid 1 on hdac0 pcm1: at cad 2 nid 1 on hdac0 pcm2: at cad 2 nid 1 on hdac0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 ada0 at ahcich2 bus 0 scbus3 target 0 lun 0 ada0: ATA-7 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad10 ada1 at ahcich3 bus 0 scbus4 target 0 lun 0 ada1: ATA-7 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad12 ada2 at ahcich4 bus 0 scbus5 target 0 lun 0 ada2: ATA-7 SATA 2.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 476938MB (976771055 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad14 ada3 at ahcich5 bus 0 scbus6 target 0 lun 0 ada3: ATA-7 SATA 2.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: Command Queueing enabled ada3: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada3: Previously was known as ad16 SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Timecounter "TSC-low" frequency 9375184 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub7: 6 ports with 6 removable, self powered uhub3: 6 ports with 6 removable, self powered cd1 at ahcich7 bus 0 scbus8 target 0 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd1: Attempt to query device size failed: NOT READY, Medium not present cd0 at ahcich6 bus 0 scbus7 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present Root mount waiting for: usbus3 Trying to mount root from ufs:/dev/ufs/root9 [rw]... <118>Enter root password, or ^D to go multi-user <118>Password: ugen0.2: at usbus0 ums0: on usbus0 ums0: 5 buttons and [XYZ] coordinates ID=0 ugen1.2: at usbus1 ukbd0: on usbus1 kbd2 at ukbd0 uhid0: on usbus1 <118> <118>Enter full pathname of shell or RETURN for /bin/sh: # dumpon -v /dev/ada1s4 <118>/dev/ada1s4 /dev/ada1s4b <118><118># dumpon -v /dev/ada1s4b <118>kernel dumps on /dev/ada1s4b <118># sysctl kern.geom.debugflags=16 <118>kern.geom.debugflags: 0 -> 16 <118># fdisk -u3 ada1 panic: spoiling cp->ace = 1 cpuid = 0 KDB: enter: panic Dumping 275 out of 4058 MB:..6%..12%..24%..35%..41%..53%..64%..76%..82%..93% Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boot/kernel/coretemp.ko.symbols...done. done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/sem.ko...Reading symbols from /boot/kernel/sem.ko.symbols...done. done. Loaded symbols for /boot/kernel/sem.ko Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko #0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:260 260 if (textdump && textdump_pending) { Ready to go. Enter 'tr' to connect to the remote target with /dev/cuad0, 'tr /dev/cuad1' to connect to a different port or 'trf portno' to connect to the remote target with the firewire interface. portno defaults to 5556. Type 'getsyms' after connection to load kld symbols. If you're debugging a local system, you can use 'kldsyms' instead to load the kld symbols. That's a less obnoxious interface. (kgdb) bt #0 doadump (textdump=0x0) at /usr/src/sys/kern/kern_shutdown.c:260 During symbol reading, Incomplete CFI data; unspecified registers at 0xffffffff80822fa9. #1 0xffffffff802f7eb0 in db_dump (dummy=dwarf2_read_address: Corrupted DWARF expression. ) at /usr/src/sys/ddb/db_command.c:537 #2 0xffffffff802f74a1 in db_command (last_cmdp=0xffffffff810e8f40, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:448 #3 0xffffffff802f76f0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:501 #4 0xffffffff802f9844 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff80858c21 in kdb_trap (type=0x3, code=0x0, tf=0xffffff811d6614f0) at /usr/src/sys/kern/subr_kdb.c:631 #6 0xffffffff80b0b876 in trap (frame=0xffffff811d6614f0) at /usr/src/sys/amd64/amd64/trap.c:590 #7 0xffffffff80af5ccf in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #8 0xffffffff808589cb in kdb_enter (why=0xffffffff80d2359b "panic", msg=0x80
) at cpufunc.h:63 #9 0xffffffff8082329c in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:599 #10 0xffffffff807c313b in g_spoil (pp=Variable "pp" is not available. ) at /usr/src/sys/geom/geom_subr.c:1001 #11 0xffffffff807c33c1 in g_access (cp=0xfffffe000676eb80, dcr=0x1, dcw=0x1, dce=0x0) at /usr/src/sys/geom/geom_subr.c:835 #12 0xffffffff807bc78e in g_dev_open (dev=0xfffffe0006744400, flags=0x1, fmt=Variable "fmt" is not available. ) at /usr/src/sys/geom/geom_dev.c:253 #13 0xffffffff80747d5c in devfs_open (ap=0xffffff811d661930) at /usr/src/sys/fs/devfs/devfs_vnops.c:1066 During symbol reading, unsupported tag: 'DW_TAG_const_type'. #14 0xffffffff808cb159 in vn_open_cred (ndp=0xffffff811d6619e0, flagp=0xffffff811d6619dc, cmode=0x1, vn_open_flags=Variable "vn_open_flags" is not available. ) at vnode_if.h:196 #15 0xffffffff808ca097 in kern_openat (td=0xfffffe000c166000, fd=0xffffff9c, path=0x801407080
, pathseg=UIO_USERSPACE, flags=0x3, mode=Variable "mode" is not available. ) at /usr/src/sys/kern/vfs_syscalls.c:1123 #16 0xffffffff80b0ac0a in amd64_syscall (td=0xfffffe000c166000, traced=0x0) at subr_syscall.c:131 #17 0xffffffff80af5fb7 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #18 0x0000000800f607ec in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) bt full #0 doadump (textdump=0x0) at /usr/src/sys/kern/kern_shutdown.c:260 No locals. #1 0xffffffff802f7eb0 in db_dump (dummy=dwarf2_read_address: Corrupted DWARF expression. ) at /usr/src/sys/ddb/db_command.c:537 error = Variable "error" is not available. (kgdb) i loc No locals. (kgdb) f 10 #10 0xffffffff807c313b in g_spoil (pp=Variable "pp" is not available. ) at /usr/src/sys/geom/geom_subr.c:1001 1001 KASSERT(cp2->ace == 0, ("spoiling cp->ace = %d", cp2->ace)); (kgdb) l 996 continue; 997 /* 998 KASSERT(cp2->acr == 0, ("spoiling cp->acr = %d", cp2->acr)); 999 KASSERT(cp2->acw == 0, ("spoiling cp->acw = %d", cp2->acw)); 1000 */ 1001 KASSERT(cp2->ace == 0, ("spoiling cp->ace = %d", cp2->ace)); 1002 cp2->spoiled++; 1003 } 1004 g_post_event(g_spoil_event, pp, M_WAITOK, pp, NULL); 1005 } (kgdb) kern.conftxt: options CONFIG_AUTOGENERATED ident GENERIC machine amd64 cpu HAMMER makeoptions DEBUG=-g options USB_DEBUG options AH_SUPPORT_AR5416 options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options SC_PIXEL_MODE options AHD_REG_PRETTY_PRINT options AHC_REG_PRETTY_PRINT options ATA_STATIC_ID options ATA_CAM options SMP options MALLOC_DEBUG_MAXZONES=8 options WITNESS_SKIPSPIN options WITNESS options INVARIANT_SUPPORT options INVARIANTS options DEADLKRES options GDB options DDB options KDB options INCLUDE_CONFIG_FILE options MAC options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=128 options _KPOSIX_PRIORITY_SCHEDULING options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options COMPAT_FREEBSD32 options GEOM_LABEL options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSD options NFSCL options MD_ROOT options UFS_GJOURNAL options UFS_DIRHASH options UFS_ACL options SOFTUPDATES options FFS options SCTP options INET6 options INET options PREEMPTION options SCHED_ULE options NEW_PCIB options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD device isa device mem device io device uart_ns8250 device cpufreq device acpi device pci device fdc device ahci device ata device mvs device siis device ahc device ahd device amd device hptiop device isp device mpt device mps device sym device trm device adv device adw device aic device bt device scbus device ch device da device sa device cd device pass device ses device amr device arcmsr device ciss device dpt device hptmv device hptrr device iir device ips device mly device twa device aac device aacp device ida device mfi device mlx device twe device atkbdc device atkbd device psm device kbdmux device vga device splash device sc device agp device cbb device pccard device cardbus device uart device ppc device ppbus device lpt device plip device ppi device puc device bxe device de device em device igb device ixgbe device le device ti device txp device vx device miibus device ae device age device alc device ale device bce device bfe device bge device dc device et device fxp device jme device lge device msk device nfe device nge device pcn device re device rl device sf device sge device sis device sk device ste device stge device tl device tx device vge device vr device wb device xl device cs device ed device ex device ep device fe device sn device xe device wlan device wlan_wep device wlan_ccmp device wlan_tkip device wlan_amrr device an device ath device ath_pci device ath_hal device ath_rate_sample device ipw device iwi device iwn device malo device mwl device ral device wi device wpi device loop device random device ether device vlan device tun device pty device md device gif device faith device firmware device bpf device uhci device ohci device ehci device xhci device usb device uhid device ukbd device ulpt device umass device ums device urio device u3g device uark device ubsa device uftdi device uipaq device uplcom device uslcom device uvisor device uvscom device aue device axe device cdce device cue device kue device rue device udav device rum device run device uath device upgt device ural device urtw device zyd device firewire device sbp device fwe device fwip device dcons device dcons_crom device sound device snd_es137x device snd_hda device snd_ich device snd_uaudio device snd_via8233 From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 17:56:13 2011 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 49B0C106564A; Fri, 23 Sep 2011 17:56:13 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from ixe-mta-27.emailfiltering.com (ixe-mta-27-tx.emailfiltering.com [194.116.199.158]) by mx1.freebsd.org (Postfix) with ESMTP id 4FAF68FC15; Fri, 23 Sep 2011 17:56:12 +0000 (UTC) Received: from mail-gw13.york.ac.uk ([144.32.129.163]) by ixe-mta-27.emailfiltering.com with emfmta (version 4.8.3.54) by TLS id 1295923726 for fbsd8@a1poweruser.com; 2acd4eeea3fc1981; Fri, 23 Sep 2011 18:45:06 +0100 Received: from buffy-128.york.ac.uk ([144.32.128.160]:28072 helo=buffy.york.ac.uk) by mail-gw13.york.ac.uk with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1R79o9-0007MP-LV; Fri, 23 Sep 2011 18:45:05 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.4/8.14.4) with ESMTP id p8NHj5Iw060496; Fri, 23 Sep 2011 18:45:05 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.4/8.14.4/Submit) id p8NHj4G3060495; Fri, 23 Sep 2011 18:45:04 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Fbsd8 In-Reply-To: <4E74C9B7.2090901@a1poweruser.com> References: <4E71F647.2050007@a1poweruser.com> <4E7453CB.1040908@freebsd.org> <4E74C9B7.2090901@a1poweruser.com> Content-Type: text/plain; charset="ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Sep 2011 18:45:04 +0100 Message-ID: <1316799904.39972.12.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-current@FreeBSD.org, Nathan Whitehorn , FreeBSD Questions Subject: Re: 9.0 bata2 & keymap 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, 23 Sep 2011 17:56:13 -0000 On Sat, 2011-09-17 at 12:24 -0400, Fbsd8 wrote: > Changing the cancel button in the kbdmap command to skip, does not=20 > address the problem, which is the lack of knowledge of the standard=20 > bsdinstall user. I've been using Freebsd since 4.0 and never used the=20 > kbdmap command or for that matter even knew it existed. Interesting. Sysinstall has asked for country information and then asked you to choose a keymap (using kbdmap) if you selected a non-default country as the first two questions (i.e. before you get the sysinstall menu) since 6.1. Would that be a good solution still? Some of the other points brought up later about wanting to switch between two different keymaps seem sensible too, though I don't initially see how that would be possible. Gavin --=20 Gavin Atkinson FreeBSD committer and bugmeister GPG: A093262B (313A A79F 697D 3A5C 216A EDF5 935D EF44 A093 262B) From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 18:41:38 2011 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 5560F106566C for ; Fri, 23 Sep 2011 18:41:38 +0000 (UTC) (envelope-from gull@gull.us) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id E30B18FC16 for ; Fri, 23 Sep 2011 18:41:37 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so4810363bkb.13 for ; Fri, 23 Sep 2011 11:41:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.0.74 with SMTP id 10mr1755077bka.140.1316801712028; Fri, 23 Sep 2011 11:15:12 -0700 (PDT) Received: by 10.204.148.66 with HTTP; Fri, 23 Sep 2011 11:15:11 -0700 (PDT) X-Originating-IP: [128.95.17.219] In-Reply-To: <4E71F647.2050007@a1poweruser.com> References: <4E71F647.2050007@a1poweruser.com> Date: Fri, 23 Sep 2011 11:15:11 -0700 Message-ID: From: David Brodbeck To: FreeBSD Questions , freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 23 Sep 2011 18:54:19 +0000 Cc: Subject: Re: 9.0 bata2 & keymap 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, 23 Sep 2011 18:41:38 -0000 I don't think not asking the question is the right answer. Asking about the keyboard layout during installation is the right thing to do; working with the wrong one is difficult and not everyone has a standard US keyboard. I think the problem is that the keymap names are kind of obscure, making it hard for users who aren't already familiar with FreeBSD internals to know which one to pick. Many Linux installers ask for a keymap during installation, but they give fairly clear names for the keymaps like "US English 105-key", making it easy to pick one that's likely to work. When I installed FreeBSD-9.0-BETA it took me two tries to find a layout that works because it's far from clear what will yield "normal" behavior. I tried the "United States of America Traditional UNIX Workstation" one first (traditional! It must be standard, right?) and found I had no working Ctrl key. Eventually I landed on "United States of America ISO-8859-1", which worked, but I'm not sure it's reasonable to expect a new user to know what "ISO-8859-1" is and whether they have it. Surely we can name these layouts a bit more clearly? I think that would solve most of the problem. I would offer a patch but I'm the wrong person to do it, since they make no sense to me. ;) From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 19:12:54 2011 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 571991065673 for ; Fri, 23 Sep 2011 19:12:54 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 1C0638FC15 for ; Fri, 23 Sep 2011 19:12:53 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 4E2FD5DAC for ; Fri, 23 Sep 2011 19:12:52 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id p8NJCqLF066073 for ; Fri, 23 Sep 2011 19:12:52 GMT (envelope-from phk@phk.freebsd.dk) To: current@freebsd.org From: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 23 Sep 2011 19:12:52 +0000 Message-ID: <66072.1316805172@critter.freebsd.dk> Cc: Subject: Boot FreeBSD-current on macbook from 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: Fri, 23 Sep 2011 19:12:54 -0000 Has anybody managed this on an unadultered MacBook ? I've tried with rEFIt and it sees the FreeBSD, but it doesn't boot for me :-/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 20:50:42 2011 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 BCF961065672 for ; Fri, 23 Sep 2011 20:50:42 +0000 (UTC) (envelope-from eric@shadowsun.net) Received: from mail.atlantawebhost.com (dns1.atlantawebhost.com [66.223.40.39]) by mx1.freebsd.org (Postfix) with ESMTP id 6EF418FC16 for ; Fri, 23 Sep 2011 20:50:42 +0000 (UTC) Received: (qmail 3515 invoked from network); 23 Sep 2011 16:50:40 -0400 Received: from thingy.cs.umass.edu (HELO ?10.1.40.200?) (128.119.40.196) by mail.atlantawebhost.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Sep 2011 16:50:40 -0400 Message-ID: <4E7CF115.5000103@shadowsun.net> Date: Fri, 23 Sep 2011 16:50:30 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110916 Thunderbird/6.0.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <66072.1316805172@critter.freebsd.dk> In-Reply-To: <66072.1316805172@critter.freebsd.dk> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig549EA2D197115EF98120D58E" Subject: Re: Boot FreeBSD-current on macbook from 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: Fri, 23 Sep 2011 20:50:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig549EA2D197115EF98120D58E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/23/11 15:12, Poul-Henning Kamp wrote: > Has anybody managed this on an unadultered MacBook ? > > I've tried with rEFIt and it sees the FreeBSD, but it doesn't > boot for me :-/ > I have. There's some information which isn't easy co come by: Macs use a non-standard EFI boot process. They search for an HFS+ partition, which has a special "blessed" file containing the EFI bootloader. They also set the graphics hardware into framebuffer mode.=20 To boot a standards-compliant EFI OS, you'd have to have an HFS+ partition containing an EFI program that sets the graphics hardware back to text mode, then exits, dropping you back to the EFI boot console. You can boot in legacy BIOS mode, which I do. You have to create an MBR/BSD label installation, as if you have a GPT, the firmware will do what I described above. Now, the mac firmware will wait 30 seconds before doing the legacy BIOS boot. You can get around this by holding ALT at power on, and selecting "windows" (*sigh*). I have the following partition scheme: MBR---BSD---+---ZFS | +---Swap I do not use refit. --------------enig549EA2D197115EF98120D58E 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.18 (FreeBSD) iQIcBAEBAgAGBQJOfPEdAAoJENSCzbQ+koZ7VnsQAMJLTuq6JlANKDKBJTEyQOOc ifPL7kTfp1ta/Bqf4g3FVb3FhQw77qXbiKHzGqW6SFpxR0iZxbKbz/OCDOZROr6c M9OoZ7K6Vuk/MctukpWipJvejfVUnojL8YjbGmZxiW+CYmNPSEVjBVGtYbBI1gyI +T9q1X58iITjy4JyWOOC3F1XCYhQ2nwSGF9n1uRCcs2+n0KCogzF1yA0TM5NzwaD PikHtwDoBq9il1sVTozmZ2mHw4sqszFZSMf21PFj3TOC6VATQwjLfktwxdeTMzN+ Uhl0pVWtZu3sLbET4Lj4pWUvAv9s0tR9/0N/PtcwJpfEQtdVA6CSaN60Fh1/rZ/0 MTn+u32ft3uPzrKDOBlKydiv8MuDibB14jsXCb2SpIq9M62k60ofwUk90Pa305Xs emU07gCiKtE7xqjVDnxiKPzClUP6dtoZIJizeyS9rNsRR5+JqZlvDwNHrCDk9MUs N35jfq6SKFvy34k09mStpzqOKc8WXIQkrjdVy9lbT5jBEOcLw/BIE0Pi2Qa9kjyd PE68lHHQxSK5Mru0izU9bOXkOdnyb31bOzo9iHN4z44ptPlg7xDaQwN5Mz6YzgWI ZOneR3qd8JNgohxEwe7FLCp+bUY2g2mmRiI0nM3rd5VnN2EedDgaAghJ1MW+wFyJ 8GUrIdPGlp14RmrfYGqj =YMCi -----END PGP SIGNATURE----- --------------enig549EA2D197115EF98120D58E-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 20:56:57 2011 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 BEAF8106564A for ; Fri, 23 Sep 2011 20:56:57 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 81ACA8FC13 for ; Fri, 23 Sep 2011 20:56:56 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 23F985DA3; Fri, 23 Sep 2011 20:56:55 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id p8NKusaS066599; Fri, 23 Sep 2011 20:56:54 GMT (envelope-from phk@phk.freebsd.dk) To: Eric McCorkle From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 23 Sep 2011 16:50:30 -0400." <4E7CF115.5000103@shadowsun.net> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 23 Sep 2011 20:56:54 +0000 Message-ID: <66598.1316811414@critter.freebsd.dk> Cc: freebsd-current@freebsd.org Subject: Re: Boot FreeBSD-current on macbook from 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: Fri, 23 Sep 2011 20:56:57 -0000 In message <4E7CF115.5000103@shadowsun.net>, Eric McCorkle writes: >You can boot in legacy BIOS mode, which I do. You have to create an >MBR/BSD label installation, as if you have a GPT, the firmware will do >what I described above. Now, the mac firmware will wait 30 seconds >before doing the legacy BIOS boot. You can get around this by holding >ALT at power on, and selecting "windows" (*sigh*). > >I have the following partition scheme: > >MBR---BSD---+---ZFS > | > +---Swap > >I do not use refit. That does not seem to work for me, I have USB stick with a NanoBSD on it, and it never gets recognized by the macbook, so there is no 'windows' to select... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 21:44:08 2011 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 727DC106564A for ; Fri, 23 Sep 2011 21:44:08 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id EFB278FC16 for ; Fri, 23 Sep 2011 21:44:07 +0000 (UTC) Received: by fxg9 with SMTP id 9so5477236fxg.13 for ; Fri, 23 Sep 2011 14:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=XAy/NACuOWiilpdwS7vbrORidPj+Nbfbwb62OiSy8lY=; b=CNCspt6owm+RJ7ZpJIYqoE3snIg0J/QLXgtvfj6yQSkDV+6cGDmUV0muMRe3hvN+V8 6HbhfW6UKTWaTT7/DR8l1U38q8aZ8Ohqic0SuMXscLlQXqqz2tHh8SL4uC1RMl0j3gDi njq3xTOZO9F+ixFLT28tA0Y3nJz39rcFdlpSk= Received: by 10.223.59.137 with SMTP id l9mr5717346fah.15.1316813921468; Fri, 23 Sep 2011 14:38:41 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (advisory-appointer.volia.net. [93.73.242.53]) by mx.google.com with ESMTPS id f10sm12441153fac.14.2011.09.23.14.38.39 (version=SSLv3 cipher=OTHER); Fri, 23 Sep 2011 14:38:40 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E7CFC42.8000409@FreeBSD.org> Date: Sat, 24 Sep 2011 00:38:10 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110910 Thunderbird/6.0.2 MIME-Version: 1.0 To: Adrian Chadd References: In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ath / 802.11n performance issues and timer code 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, 23 Sep 2011 21:44:08 -0000 On 23.09.2011 18:29, Adrian Chadd wrote: > I've been looking at issues with 802.11n RX performance on these > MIPS24k based MIPS boards. > After doing a bit of digging, I discovered what looked like strange > scheduler issues where the RX and TX completion schedulers weren't > being invoked quickly. > The ath driver schedules these functions using taskqueues. > > Here's the time keeper configuration for my mips24k board: > > # sysctl kern.eventtimer > kern.eventtimer.choice: MIPS32(800) > kern.eventtimer.et.MIPS32.flags: 7 > kern.eventtimer.et.MIPS32.frequency: 360000000 > kern.eventtimer.et.MIPS32.quality: 800 > kern.eventtimer.periodic: 1 > kern.eventtimer.timer: MIPS32 > kern.eventtimer.idletick: 0 > kern.eventtimer.singlemul: 2 > > When I set kern.eventtimer.periodic=1, the 11n TX/RX performance > suddenly jumps to where it should be. > > Would you mind helping me figure out what the problem is? I would be glad to help, but at this moment I am not sure how network traffic related to timer. May be wireless has some specifics, but for wired adapters traffic processing happens on network interrupts. > I didn't think kern.eventtimer.periodic was needed? It should not be needed. Have you tried to set kern.eventtimer.idletick=1 instead? kern.eventtimer.periodic=1 on UP system effectively includes kern.eventtimer.idletick=1. kern.eventtimer.idletick=0 may somewhat increase interrupts overhead due to need to reprogram timer before context switch, but under high interrupt rate (about few KHz) kernel should dynamically switch to "quick" mode skipping it. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 21:54:51 2011 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 CE6C8106566B for ; Fri, 23 Sep 2011 21:54:51 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 91CFB8FC13 for ; Fri, 23 Sep 2011 21:54:51 +0000 (UTC) Received: by qyk10 with SMTP id 10so7857594qyk.13 for ; Fri, 23 Sep 2011 14:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=42Vnwagpb6egt74qnkhZEaf/1bhXqSno+44PM3knc4U=; b=JL6Yi5s45jXibk5fzp7ZxfByP1YfGEUdt3+zW4EvjHgkiHj8EWRbzShgKdnRdJkwI2 NmhjwYgO9MaGe1r7SwRTo7rnp0kYql/ZUEjGEcHuPWHWXZAcd1aRSlKun7TTxCbOiIfX mODHhG9kewZA7gcYT44IPAgtwT1+dZEtpTc7I= MIME-Version: 1.0 Received: by 10.224.185.6 with SMTP id cm6mr3323235qab.174.1316814890797; Fri, 23 Sep 2011 14:54:50 -0700 (PDT) Received: by 10.224.74.82 with HTTP; Fri, 23 Sep 2011 14:54:50 -0700 (PDT) In-Reply-To: <66598.1316811414@critter.freebsd.dk> References: <4E7CF115.5000103@shadowsun.net> <66598.1316811414@critter.freebsd.dk> Date: Fri, 23 Sep 2011 14:54:50 -0700 Message-ID: From: Garrett Cooper To: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Eric McCorkle , freebsd-current@freebsd.org Subject: Re: Boot FreeBSD-current on macbook from 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: Fri, 23 Sep 2011 21:54:51 -0000 On Fri, Sep 23, 2011 at 1:56 PM, Poul-Henning Kamp wro= te: > In message <4E7CF115.5000103@shadowsun.net>, Eric McCorkle writes: > >>You can boot in legacy BIOS mode, which I do. =A0You have to create an >>MBR/BSD label installation, as if you have a GPT, the firmware will do >>what I described above. =A0Now, the mac firmware will wait 30 seconds >>before doing the legacy BIOS boot. =A0You can get around this by holding >>ALT at power on, and selecting "windows" (*sigh*). >> >>I have the following partition scheme: >> >>MBR---BSD---+---ZFS >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +---Swap >> >>I do not use refit. > > That does not seem to work for me, I have USB stick with a > NanoBSD on it, and it never gets recognized by the macbook, > so there is no 'windows' to select... What does gpart list say for the USB stick? -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Sep 23 21:57:36 2011 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 EB123106564A for ; Fri, 23 Sep 2011 21:57:36 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id AAE1A8FC13 for ; Fri, 23 Sep 2011 21:57:36 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id A4CE15DA9; Fri, 23 Sep 2011 21:57:34 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id p8NLvY9x066911; Fri, 23 Sep 2011 21:57:34 GMT (envelope-from phk@phk.freebsd.dk) To: Garrett Cooper From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 23 Sep 2011 14:54:50 MST." Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 23 Sep 2011 21:57:34 +0000 Message-ID: <66910.1316815054@critter.freebsd.dk> Cc: Eric McCorkle , freebsd-current@freebsd.org Subject: Re: Boot FreeBSD-current on macbook from 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: Fri, 23 Sep 2011 21:57:37 -0000 In message , Garrett Cooper writes: >> That does not seem to work for me, I have USB stick with a >> NanoBSD on it, and it never gets recognized by the macbook, >> so there is no 'windows' to select... > >What does gpart list say for the USB stick? critter# gpart list da0 Geom name: da0 modified: false state: OK fwheads: 255 fwsectors: 63 last: 7925758 first: 63 entries: 4 scheme: MBR Providers: 1. Name: da0s1 Mediasize: 1048674816 (1G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 32256 Mode: r0w0e0 attrib: active rawtype: 165 length: 1048674816 offset: 32256 type: freebsd index: 1 end: 2048255 start: 63 2. Name: da0s2 Mediasize: 1048674816 (1G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 1048739328 Mode: r0w0e0 rawtype: 165 length: 1048674816 offset: 1048739328 type: freebsd index: 2 end: 4096511 start: 2048319 3. Name: da0s3 Mediasize: 1548288 (1.5M) Sectorsize: 512 Stripesize: 0 Stripeoffset: 2097414144 Mode: r0w0e0 rawtype: 165 length: 1548288 offset: 2097414144 type: freebsd index: 3 end: 4099535 start: 4096512 Consumers: 1. Name: da0 Mediasize: 4057988608 (3.8G) Sectorsize: 512 Mode: r0w0e0 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sat Sep 24 00:54:14 2011 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 0DD9B1065672 for ; Sat, 24 Sep 2011 00:54:14 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id 580A08FC15 for ; Sat, 24 Sep 2011 00:54:12 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=yVKV3zusvCapyMfYJBNW2j35FMEuTKq6vh/tt/1L5+g= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=I7wBR7KcOEAA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=1sqgOJNjxFUsWUkUUq0A:9 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 15639604; Sat, 24 Sep 2011 02:54:11 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 24 Sep 2011 02:51:15 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <66072.1316805172@critter.freebsd.dk> In-Reply-To: <66072.1316805172@critter.freebsd.dk> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109240251.15929.hselasky@c2i.net> Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: Boot FreeBSD-current on macbook from 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: Sat, 24 Sep 2011 00:54:14 -0000 On Friday 23 September 2011 21:12:52 Poul-Henning Kamp wrote: > Has anybody managed this on an unadultered MacBook ? > > I've tried with rEFIt and it sees the FreeBSD, but it doesn't > boot for me :-/ Hi, Yes - you need to put a dummy MBR there even if using GPT layout. There are some tools in ports that can do that. --HPS From owner-freebsd-current@FreeBSD.ORG Sat Sep 24 01:04:15 2011 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 80806106566C for ; Sat, 24 Sep 2011 01:04:15 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id 0400F8FC13 for ; Sat, 24 Sep 2011 01:04:14 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=yVKV3zusvCapyMfYJBNW2j35FMEuTKq6vh/tt/1L5+g= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=I7wBR7KcOEAA:10 a=WQU8e4WWZSUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=1sqgOJNjxFUsWUkUUq0A:9 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 15639604; Sat, 24 Sep 2011 02:54:11 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 24 Sep 2011 02:51:15 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <66072.1316805172@critter.freebsd.dk> In-Reply-To: <66072.1316805172@critter.freebsd.dk> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109240251.15929.hselasky@c2i.net> Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: Boot FreeBSD-current on macbook from 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: Sat, 24 Sep 2011 01:04:15 -0000 On Friday 23 September 2011 21:12:52 Poul-Henning Kamp wrote: > Has anybody managed this on an unadultered MacBook ? > > I've tried with rEFIt and it sees the FreeBSD, but it doesn't > boot for me :-/ Hi, Yes - you need to put a dummy MBR there even if using GPT layout. There are some tools in ports that can do that. --HPS From owner-freebsd-current@FreeBSD.ORG Sat Sep 24 01:14:00 2011 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 75ADC106564A; Sat, 24 Sep 2011 01:14:00 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2413D8FC0C; Sat, 24 Sep 2011 01:13:59 +0000 (UTC) Received: by gxk26 with SMTP id 26so2899541gxk.13 for ; Fri, 23 Sep 2011 18:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=50P4S2CfaEsIX0Phsalyi0M+fmsPUj23xoxSJngtEW8=; b=ogY8GyanXgm2mfizx4dOlHVlV9QEy7fuvukKRfncaM/fBQL3tQvEthU9uLH2iyosE5 gFm3N92PHCrEMt8fMx/qSW9BFAMb9veT0d+LA4+f4DYN2Py+hD1zGFN0RY5xxtN+Z7kC bgh4MKymlQPFIbESrnVcXzLRE72Sl3v5X9FLU= MIME-Version: 1.0 Received: by 10.236.176.65 with SMTP id a41mr25956394yhm.72.1316826839431; Fri, 23 Sep 2011 18:13:59 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Fri, 23 Sep 2011 18:13:59 -0700 (PDT) In-Reply-To: <4E7CFC42.8000409@FreeBSD.org> References: <4E7CFC42.8000409@FreeBSD.org> Date: Sat, 24 Sep 2011 09:13:59 +0800 X-Google-Sender-Auth: VYf5mnljpbRcZ0iCKcR9G4gx9ik Message-ID: From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: ath / 802.11n performance issues and timer code 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, 24 Sep 2011 01:14:00 -0000 On 24 September 2011 05:38, Alexander Motin wrote: >> When I set kern.eventtimer.periodic=1, the 11n TX/RX performance >> suddenly jumps to where it should be. >> >> Would you mind helping me figure out what the problem is? > > I would be glad to help, but at this moment I am not sure how network > traffic related to timer. May be wireless has some specifics, but for > wired adapters traffic processing happens on network interrupts. Well, here the interrupt handler just sets up some deferred tasks to run via taskqueue_schedule(). This isn't the only driver which does this - I think the gige/10gige NICs also do this. >> I didn't think kern.eventtimer.periodic was needed? > > It should not be needed. > > Have you tried to set kern.eventtimer.idletick=1 instead? I just tested it - it has the same effect. > kern.eventtimer.periodic=1 on UP system effectively includes > kern.eventtimer.idletick=1. kern.eventtimer.idletick=0 may somewhat > increase interrupts overhead due to need to reprogram timer before > context switch, but under high interrupt rate (about few KHz) kernel > should dynamically switch to "quick" mode skipping it. The clock rate interrupt difference is quite startling - at 150mbit 11n bridging (from wlan0 -> arge0 wired) the clock interrupt rate is around 300/sec for idletick=0, and about 1150/sec for idletick=1. The other thing to keep in mind is that the wlreless NIC isn't interrupting per RX or TX completed packet. So although I'm doing ~ 19,000 pps, it's only interrupting me ~ 390 times a second. Adrian From owner-freebsd-current@FreeBSD.ORG Sat Sep 24 05:14:08 2011 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 AF4201065672; Sat, 24 Sep 2011 05:14:08 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 184F08FC12; Sat, 24 Sep 2011 05:14:07 +0000 (UTC) Received: by fxg9 with SMTP id 9so5722321fxg.13 for ; Fri, 23 Sep 2011 22:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=ceaBdLOUEN91ZlqkmxVObJQK9QfO57pIZ0ER8SmhAKs=; b=oklUQjOKcAXnj4kJMQwvFvmxwjLzIxfVenqY3l6vciG6EQAs+YFv0K002GmeGvNm1Y W94HSTEUgxSDVfBBR3iTSWXRX70qTSYMH52OD4HkxsXPdnFYumLjNXcLAtpeheoyJw0n D3JUiyPSQXE7Y8VO5Sy1/hybOSRWOzdRcOlqI= Received: by 10.223.40.203 with SMTP id l11mr5974466fae.107.1316841246930; Fri, 23 Sep 2011 22:14:06 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (advisory-appointer.volia.net. [93.73.242.53]) by mx.google.com with ESMTPS id t19sm13401347faj.23.2011.09.23.22.14.05 (version=SSLv3 cipher=OTHER); Fri, 23 Sep 2011 22:14:06 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E7D6700.4080302@FreeBSD.org> Date: Sat, 24 Sep 2011 08:13:36 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110910 Thunderbird/6.0.2 MIME-Version: 1.0 To: Adrian Chadd References: <4E7CFC42.8000409@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ath / 802.11n performance issues and timer code 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, 24 Sep 2011 05:14:08 -0000 On 24.09.2011 04:13, Adrian Chadd wrote: > On 24 September 2011 05:38, Alexander Motin wrote: >>> When I set kern.eventtimer.periodic=1, the 11n TX/RX performance >>> suddenly jumps to where it should be. >>> >>> Would you mind helping me figure out what the problem is? >> >> I would be glad to help, but at this moment I am not sure how network >> traffic related to timer. May be wireless has some specifics, but for >> wired adapters traffic processing happens on network interrupts. > > Well, here the interrupt handler just sets up some deferred tasks to > run via taskqueue_schedule(). > This isn't the only driver which does this - I think the gige/10gige > NICs also do this. OK, but how taskqueue related to the timer? Taskqueue uses SWI that are called in separate thread and except "swi4: clock" AFAIR they are not anyhow related to the timer. >>> I didn't think kern.eventtimer.periodic was needed? >> >> It should not be needed. >> >> Have you tried to set kern.eventtimer.idletick=1 instead? > > I just tested it - it has the same effect. Interesting. So either it is what I've described below (but it's strange, I have doubt it may consume so much time, at least I haven't seen it on x86), or network traffic is still somehow depends on timer events and timer events are delayed more then needed. >> kern.eventtimer.periodic=1 on UP system effectively includes >> kern.eventtimer.idletick=1. kern.eventtimer.idletick=0 may somewhat >> increase interrupts overhead due to need to reprogram timer before >> context switch, but under high interrupt rate (about few KHz) kernel >> should dynamically switch to "quick" mode skipping it. > > The clock rate interrupt difference is quite startling - at 150mbit > 11n bridging (from wlan0 -> arge0 wired) the clock interrupt rate is > around 300/sec for idletick=0, and about 1150/sec for idletick=1. The numbers themselves look fine. 1150 int/sec should mean 1000 of hz and 127 of stathz. Lower rate with idletick=0 means that eventtimer subsystem is dropping some timer ticks. > The other thing to keep in mind is that the wlreless NIC isn't > interrupting per RX or TX completed packet. So although I'm doing ~ > 19,000 pps, it's only interrupting me ~ 390 times a second. So low interrupt rate means large queuing, that should make bandwidth even less affected by side influences. Can you try to build kernel with KTR_SPARE2 KTR and send me a trace when the traffic flows. I would like to check whether timer events are generated close to a proper time. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Sep 24 05:38:33 2011 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 E46F0106564A; Sat, 24 Sep 2011 05:38:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 940698FC0C; Sat, 24 Sep 2011 05:38:33 +0000 (UTC) Received: by ywp17 with SMTP id 17so4031292ywp.13 for ; Fri, 23 Sep 2011 22:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6e9hDOLfVU1/Sn9nPJIUe/uMEbaXDBwEJft89FQsuhA=; b=sKQj/Pc9udQE2evb5M47LyGv7FKzWqrZSlppQP1JW8Jj6Xt4P674eimcmFOhyQNhp7 ADDy282GncEmlsytl1j/f0BMqWgAokqz9Z/Yqcdd3NXJr5iAfqU7cvKB3A56p92oyD+d 227OookQvkYPR2saEShh4q8IlDQskovgfpMeY= MIME-Version: 1.0 Received: by 10.236.79.72 with SMTP id h48mr27226931yhe.4.1316842712883; Fri, 23 Sep 2011 22:38:32 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Fri, 23 Sep 2011 22:38:32 -0700 (PDT) In-Reply-To: <4E7D6700.4080302@FreeBSD.org> References: <4E7CFC42.8000409@FreeBSD.org> <4E7D6700.4080302@FreeBSD.org> Date: Sat, 24 Sep 2011 13:38:32 +0800 X-Google-Sender-Auth: Zv8EYAFgno9YrQcW9pcY5OIeaCo Message-ID: From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: ath / 802.11n performance issues and timer code 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, 24 Sep 2011 05:38:34 -0000 I'll get you a trace soon. I noticed a much smaller but valid looking effect when doing this on my eeepc. If I enable idletick, I get an extra 15-25mbit/sec 11n TX throughput. kern.eventtimer.choice: LAPIC(400) i8254(100) RTC(0) kern.eventtimer.et.LAPIC.flags: 15 kern.eventtimer.et.LAPIC.frequency: 35003954 kern.eventtimer.et.LAPIC.quality: 400 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.periodic: 0 kern.eventtimer.timer: LAPIC kern.eventtimer.idletick: 1 kern.eventtimer.singlemul: 4 That's running r222417 -HEAD though. Thanks, adrian From owner-freebsd-current@FreeBSD.ORG Sat Sep 24 17:30:36 2011 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 DEC6C1065672; Sat, 24 Sep 2011 17:30:36 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id C22E98FC23; Sat, 24 Sep 2011 17:30:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; q=dns/txt; s=DKIM-NAME-SERVICES; d=a1poweruser.com; h=From:To:Cc:Subject:Message-ID:X-Sender:X-Envelope-From; l=500; bh=wxdoXaHhlXCPpZ61yaN+Vc7zBYl6RL4VWrkmxqWhuVM=; b=fDoWWunXYmiCd8lJ5DCGTIrPSxQijwGcdFHnVxxEEISmWkFSMGj3Hdn652Q8yndplY0VqqeDBaA4PyW2c/5Sk2kLnOxgeZ9oDGla2RfI/uo/Nuu6Vg67tWsLwx49ixboIO7waxYeVFMcPPBhpU5fFPC7nqb36jytO+6wR3PA4As= Received: from [192.168.1.64] ([76.240.47.196]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Sep 2011 10:30:37 -0700 Message-ID: <4E7E13BA.1070304@a1poweruser.com> Date: Sat, 24 Sep 2011 13:30:34 -0400 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Gavin Atkinson References: <4E71F647.2050007@a1poweruser.com> <4E7453CB.1040908@freebsd.org> <4E74C9B7.2090901@a1poweruser.com> <1316799904.39972.12.camel@buffy.york.ac.uk> In-Reply-To: <1316799904.39972.12.camel@buffy.york.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Sep 2011 17:30:37.0115 (UTC) FILETIME=[AC22A8B0:01CC7ADF] X-Sender: fbsd8@a1poweruser.com X-Envelope-From: fbsd8*a1poweruser.com Cc: freebsd-current@FreeBSD.org, FreeBSD Questions Subject: Re: 9.0 bata2 & keymap 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, 24 Sep 2011 17:30:37 -0000 Gavin Atkinson wrote: > On Sat, 2011-09-17 at 12:24 -0400, Fbsd8 wrote: > >> Changing the cancel button in the kbdmap command to skip, does not >> address the problem, which is the lack of knowledge of the standard >> bsdinstall user. I've been using Freebsd since 4.0 and never used the >> kbdmap command or for that matter even knew it existed. > > Interesting. Sysinstall has asked for country information and then > asked you to choose a keymap (using kbdmap) if you selected a > non-default country as the first two questions (i.e. before you get the > sysinstall menu) since 6.1. Would that be a good solution still? > > Some of the other points brought up later about wanting to switch > between two different keymaps seem sensible too, though I don't > initially see how that would be possible. > > Gavin > In sysinstall you are presented with a dailog that asks you if you want to change the keyboard map and if answered yes them issues the kbdmap command. In bsdinstall you have no option to bypass the keymap step. It just issues the kbdmap command. I agree that some method to bypass the keymap step in bsdinstall needs to be added or an dialog informing the user that selecting the cancel button in kbdmap will result in the default map used in previous releases to be used. From owner-freebsd-current@FreeBSD.ORG Sat Sep 24 19:47:22 2011 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 5DFF6106566B for ; Sat, 24 Sep 2011 19:47:22 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) by mx1.freebsd.org (Postfix) with ESMTP id 9AF2E8FC0C for ; Sat, 24 Sep 2011 19:47:21 +0000 (UTC) Received: from [78.35.74.150] (helo=fabiankeil.de) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1R7YBz-0005JX-Pf; Sat, 24 Sep 2011 21:47:20 +0200 Date: Sat, 24 Sep 2011 21:27:22 +0200 From: Fabian Keil To: "Kenneth D. Merry" Message-ID: <20110924212722.4ce229e9@fabiankeil.de> In-Reply-To: <20110922193305.GA24939@nargothrond.kdm.org> References: <20110922193305.GA24939@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/fTzeD+fX2KOHTIiU3YSEE/0"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-current@freebsd.org Subject: Re: SCSI descriptor sense changes, testing needed 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, 24 Sep 2011 19:47:22 -0000 --Sig_/fTzeD+fX2KOHTIiU3YSEE/0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable "Kenneth D. Merry" wrote: > I have attached a set of patches against head that implement SCSI > descriptor sense support for CAM. > Anyway, I'd appreciate any testing and feedback on these changes. As I > said, they will probably be in 9.0, so if there are any issues it would > be better to find them now. :) I've been using the patch on a ThinkPad R500 since yesterday and just reverted it today again to get my kernel closer to HEAD before looking into some (probably unrelated) panics. I didn't notice it while using the patch, but it looks like the kernel wasn't able to pick up cd0 anymore: fk@r500 ~ $grep -h "new dis" /var/log/messages /var/log/messages.[123] | so= rt Sep 21 23:40:23 r500 kernel: GEOM: new disk da0 Sep 21 23:40:30 r500 kernel: GEOM: new disk da1 Sep 21 23:45:21 r500 kernel: GEOM: new disk ada0 Sep 21 23:45:21 r500 kernel: GEOM: new disk cd0 Sep 21 23:45:21 r500 kernel: GEOM: new disk da0 Sep 21 23:45:21 r500 kernel: GEOM: new disk da1 Sep 21 23:52:44 r500 kernel: GEOM: new disk ada0 Sep 21 23:52:44 r500 kernel: GEOM: new disk cd0 Sep 21 23:53:14 r500 kernel: GEOM: new disk da0 Sep 21 23:56:23 r500 kernel: GEOM: new disk da1 Sep 22 21:14:17 r500 kernel: GEOM: new disk ada0 Sep 22 21:14:17 r500 kernel: GEOM: new disk cd0 Sep 22 22:10:20 r500 kernel: GEOM: new disk da0 [patch applied] Sep 22 23:29:45 r500 kernel: GEOM: new disk da0 Sep 23 14:38:31 r500 kernel: GEOM: new disk ada0 Sep 23 17:19:40 r500 kernel: GEOM: new disk da0 Sep 23 19:20:21 r500 kernel: GEOM: new disk da0 Sep 23 19:20:42 r500 kernel: GEOM: new disk da1 Sep 23 22:58:56 r500 kernel: GEOM: new disk da0 Sep 24 09:31:02 r500 kernel: GEOM: new disk ada0 Sep 24 14:17:22 r500 kernel: GEOM: new disk da0 Sep 24 14:44:03 r500 kernel: GEOM: new disk ada0 Sep 24 14:44:03 r500 kernel: GEOM: new disk da0 Sep 24 14:53:30 r500 kernel: GEOM: new disk ada0 Sep 24 15:03:24 r500 kernel: GEOM: new disk da0 Sep 24 15:06:03 r500 kernel: GEOM: new disk da0 Sep 24 15:13:57 r500 kernel: GEOM: new disk ada0 Sep 24 15:14:16 r500 kernel: GEOM: new disk da0 Sep 24 15:27:11 r500 kernel: GEOM: new disk ada0 Sep 24 15:28:05 r500 kernel: GEOM: new disk da0 Sep 24 15:32:10 r500 kernel: GEOM: new disk ada0 Sep 24 15:32:10 r500 kernel: GEOM: new disk da0 Sep 24 15:38:16 r500 kernel: GEOM: new disk ada0 Sep 24 15:38:16 r500 kernel: GEOM: new disk da0 Sep 24 15:43:33 r500 kernel: GEOM: new disk ada0 Sep 24 15:43:33 r500 kernel: GEOM: new disk da0 Sep 24 15:49:30 r500 kernel: GEOM: new disk ada0 [patch reverted] Sep 24 19:32:51 r500 kernel: GEOM: new disk ada0 Sep 24 19:32:51 r500 kernel: GEOM: new disk cd0 Sep 24 19:32:51 r500 kernel: GEOM: new disk da0 Sep 24 19:38:07 r500 kernel: GEOM: new disk ada0 Sep 24 19:38:07 r500 kernel: GEOM: new disk cd0 Without the patch I'm used to getting the following kernel messages when booting (without a disc in cd0): Sep 24 19:32:51 r500 kernel: ahcich0: AHCI reset: device ready after 100ms Sep 24 19:32:51 r500 kernel: (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 Sep 24 19:32:51 r500 kernel: ahcich1: AHCI reset: device ready after 100ms Sep 24 19:32:51 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Sep 24 19:32:51 r500 kernel: GEOM: new disk cd0 Sep 24 19:32:51 r500 kernel: pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 Sep 24 19:32:51 r500 kernel: pass0: ATA-= 8 SATA 1.x device Sep 24 19:32:51 r500 kernel: pass0: Serial Number 090509FB2F32LLEY6D8A Sep 24 19:32:51 r500 kernel: pass0: 150.000MB/s transfers (SATA 1.x, UDMA5,= PIO 8192bytes) Sep 24 19:32:51 r500 kernel: pass0: Command Queueing enabled Sep 24 19:32:51 r500 kernel: pass1 at ahcich1 bus 0 scbus1 target 0 lun 0 Sep 24 19:32:51 r500 kernel: pass1: Removab= le CD-ROM SCSI-0 device=20 Sep 24 19:32:51 r500 kernel: pass1: Serial Number M2R96NC0647 Sep 24 19:32:51 r500 kernel: pass1: 150.000MB/s transfers (SATA 1.x, UDMA6,= ATAPI 12bytes, PIO 8192bytes) Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status error Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 0 = 0 0 0 0 0 0 0 0=20 Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): CAM status: SCSI Status E= rror Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status: Check Condit= ion Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI sense: UNIT ATTENTIO= N asc:29,0 (Power on, reset, or bus device reset occurred) Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): Retrying command (per sen= se data) Sep 24 19:32:51 r500 kernel: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 Sep 24 19:32:51 r500 kernel: ada0: ATA-8= SATA 1.x device Sep 24 19:32:51 r500 kernel: ada0: Serial Number 090509FB2F32LLEY6D8A Sep 24 19:32:51 r500 kernel: ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, = PIO 8192bytes) Sep 24 19:32:51 r500 kernel: ada0: Command Queueing enabled Sep 24 19:32:51 r500 kernel: ada0: 238475MB (488397168 512 byte sectors: 16= H 63S/T 16383C) Sep 24 19:32:51 r500 kernel: ada0: Previously was known as ad4 Sep 24 19:32:51 r500 kernel: SMP: AP CPU #1 Launched! Sep 24 19:32:51 r500 kernel: cpu1 AP: Sep 24 19:32:51 r500 kernel: ID: 0x01000000 VER: 0x00050014 LDR: 0x000000= 00 DFR: 0xffffffff Sep 24 19:32:51 r500 kernel: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x000= 00000 SVR: 0x000001ff Sep 24 19:32:51 r500 kernel: timer: 0x000100ef therm: 0x00010200 err: 0x000= 000f0 pmc: 0x00010400 Sep 24 19:32:51 r500 kernel: TSC timecounter disabled: C3 enabled. Sep 24 19:32:51 r500 kernel: Timecounter "TSC" frequency 1995048630 Hz qual= ity -1000 Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status error Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 0 = 0 0 0 0 0 0 0 0=20 Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): CAM status: SCSI Status E= rror Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status: Check Condit= ion Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI sense: NOT READY asc= :4,1 (Logical unit is in process of becoming ready) Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): Polling device for readin= ess Sep 24 19:32:51 r500 kernel: uhub0: 2 ports with 2 removable, self powered Sep 24 19:32:51 r500 kernel: uhub1: 2 ports with 2 removable, self powered Sep 24 19:32:51 r500 kernel: uhub2: 2 ports with 2 removable, self powered Sep 24 19:32:51 r500 kernel: uhub4: 2 ports with 2 removable, self powered Sep 24 19:32:51 r500 kernel: uhub5: 2 ports with 2 removable, self powered Sep 24 19:32:51 r500 kernel: uhub6: 2 ports with 2 removable, self powered Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status error Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 0 = 0 0 0 0 0 0 0 0=20 Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): CAM status: SCSI Status E= rror Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status: Check Condit= ion Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI sense: NOT READY asc= :3a,1 (Medium not present - tray closed) Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): Error 6, Unretryable error Sep 24 19:32:51 r500 kernel: cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 Sep 24 19:32:51 r500 kernel: cd0: Removable= CD-ROM SCSI-0 device=20 Sep 24 19:32:51 r500 kernel: cd0: Serial Number M2R96NC0647 Sep 24 19:32:51 r500 kernel: cd0: 150.000MB/s transfers (SATA 1.x, UDMA6, A= TAPI 12bytes, PIO 8192bytes) Sep 24 19:32:51 r500 kernel: cd0: Attempt to query device size failed: NOT = READY, Medium not present - tray closed Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status error Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 0 = 0 0 0 0 0 0 0 0=20 Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): CAM status: SCSI Status E= rror Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status: Check Condit= ion Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI sense: NOT READY asc= :3a,1 (Medium not present - tray closed) Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): Error 6, Unretryable error Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status error Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 0 = 0 0 0 0 0 0 0 0=20 Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): CAM status: SCSI Status E= rror Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status: Check Condit= ion Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI sense: NOT READY asc= :3a,1 (Medium not present - tray closed) Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): Error 6, Unretryable error Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status error Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 0 = 0 0 0 0 0 0 0 0=20 Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): CAM status: SCSI Status E= rror Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status: Check Condit= ion Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI sense: NOT READY asc= :3a,1 (Medium not present - tray closed) Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): Error 6, Unretryable error Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status error Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 0 = 0 0 0 0 0 0 0 0=20 Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): CAM status: SCSI Status E= rror Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status: Check Condit= ion Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI sense: NOT READY asc= :3a,1 (Medium not present - tray closed) Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): Error 6, Unretryable error Sep 24 19:32:51 r500 kernel: GEOM: new disk ada0 Sep 24 19:32:51 r500 kernel: GEOM: ada0s1: geometry does not match label (2= 55h,63s !=3D 16h,63s). With the patch I got: Sep 24 17:29:16 r500 kernel: ahcich0: AHCI reset... Sep 24 17:29:16 r500 kernel: ahcich0: SATA connect time=3D900us status=3D00= 000113 Sep 24 17:29:16 r500 kernel: ahcich0: AHCI reset: device found Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset... Sep 24 17:29:16 r500 kernel: ahcich1: SATA connect time=3D1000us status=3D0= 0000113 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device found Sep 24 17:29:16 r500 kernel: battery0: battery initialization start Sep 24 17:29:16 r500 kernel: ugen0.1: at usbus0 Sep 24 17:29:16 r500 kernel: uhub0: on usbus0 Sep 24 17:29:16 r500 kernel: ugen1.1: at usbus1 Sep 24 17:29:16 r500 kernel: uhub1: on usbus1 Sep 24 17:29:16 r500 kernel: ugen2.1: at usbus2 Sep 24 17:29:16 r500 kernel: uhub2: on usbus2 Sep 24 17:29:16 r500 kernel: ugen3.1: at usbus3 Sep 24 17:29:16 r500 kernel: uhub3: on usbus3 Sep 24 17:29:16 r500 kernel: ugen4.1: at usbus4 Sep 24 17:29:16 r500 kernel: uhub4: on usbus4 Sep 24 17:29:16 r500 kernel: ugen5.1: at usbus5 Sep 24 17:29:16 r500 kernel: uhub5: on usbus5 Sep 24 17:29:16 r500 kernel: ugen6.1: at usbus6 Sep 24 17:29:16 r500 kernel: uhub6: on usbus6 Sep 24 17:29:16 r500 kernel: ugen7.1: at usbus7 Sep 24 17:29:16 r500 kernel: uhub7: on usbus7 Sep 24 17:29:16 r500 kernel: acpi_acad0: acline initialization start Sep 24 17:29:16 r500 kernel: battery0: battery initialization done, tried 1= times Sep 24 17:29:16 r500 kernel: acpi_acad0: On Line Sep 24 17:29:16 r500 kernel: acpi_acad0: acline initialization done, tried = 1 times Sep 24 17:29:16 r500 kernel: ahcich0: AHCI reset: device ready after 100ms Sep 24 17:29:16 r500 kernel: (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device ready after 100ms Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset... Sep 24 17:29:16 r500 kernel: ahcich1: SATA connect time=3D1000us status=3D0= 0000113 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device found Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): INQUIRY. CDB: 12 0 0 = 24 0 0=20 Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): CAM status: CCB reque= st was invalid Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device ready after 100ms Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset... Sep 24 17:29:16 r500 kernel: ahcich1: SATA connect time=3D1000us status=3D0= 0000113 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device found Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): INQUIRY. CDB: 12 0 0 = 24 0 0=20 Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): CAM status: CCB reque= st was invalid Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device ready after 100ms Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset... Sep 24 17:29:16 r500 kernel: ahcich1: SATA connect time=3D1000us status=3D0= 0000113 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device found Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): INQUIRY. CDB: 12 0 0 = 24 0 0=20 Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): CAM status: CCB reque= st was invalid Sep 24 17:29:16 r500 kernel: uhub0: 2 ports with 2 removable, self powered Sep 24 17:29:16 r500 kernel: uhub1: 2 ports with 2 removable, self powered Sep 24 17:29:16 r500 kernel: uhub2: 2 ports with 2 removable, self powered Sep 24 17:29:16 r500 kernel: uhub4: 2 ports with 2 removable, self powered Sep 24 17:29:16 r500 kernel: uhub5: 2 ports with 2 removable, self powered Sep 24 17:29:16 r500 kernel: uhub6: 2 ports with 2 removable, self powered Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device ready after 200ms Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset... Sep 24 17:29:16 r500 kernel: ahcich1: SATA connect time=3D1000us status=3D0= 0000113 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device found Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): INQUIRY. CDB: 12 0 0 = 24 0 0=20 Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): CAM status: CCB reque= st was invalid Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device ready after 101ms Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset... Sep 24 17:29:16 r500 kernel: ahcich1: SATA connect time=3D1000us status=3D0= 0000113 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device found Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): INQUIRY. CDB: 12 0 0 = 24 0 0=20 Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): CAM status: CCB reque= st was invalid Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device ready after 100ms Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset... Sep 24 17:29:16 r500 kernel: ahcich1: SATA connect time=3D1000us status=3D0= 0000113 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device found Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): INQUIRY. CDB: 12 0 0 = 24 0 0=20 Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): CAM status: CCB reque= st was invalid Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device ready after 200ms Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset... Sep 24 17:29:16 r500 kernel: ahcich1: SATA connect time=3D1000us status=3D0= 0000113 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device found Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): INQUIRY. CDB: 12 0 0 = 24 0 0=20 Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): CAM status: CCB reque= st was invalid Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device ready after 200ms Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset... Sep 24 17:29:16 r500 kernel: ahcich1: SATA connect time=3D1000us status=3D0= 0000113 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device found Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): INQUIRY. CDB: 12 0 0 = 24 0 0=20 Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): CAM status: CCB reque= st was invalid Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device ready after 200ms Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset... Sep 24 17:29:16 r500 kernel: ahcich1: SATA connect time=3D1000us status=3D0= 0000113 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device found Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): INQUIRY. CDB: 12 0 0 = 24 0 0=20 Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): CAM status: CCB reque= st was invalid Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device ready after 101ms Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset... Sep 24 17:29:16 r500 kernel: ahcich1: SATA connect time=3D1000us status=3D0= 0000113 Sep 24 17:29:16 r500 kernel: ahcich1: AHCI reset: device found Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): INQUIRY. CDB: 12 0 0 = 24 0 0=20 Sep 24 17:29:16 r500 kernel: (aprobe1:ahcich1:0:0:0): CAM status: CCB reque= st was invalid Sep 24 17:29:16 r500 kernel: pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 Sep 24 17:29:16 r500 kernel: pass0: ATA-= 8 SATA 1.x device Sep 24 17:29:16 r500 kernel: pass0: Serial Number 090509FB2F32LLEY6D8A Sep 24 17:29:16 r500 kernel: pass0: 150.000MB/s transfers (SATA 1.x, UDMA5,= PIO 8192bytes) Sep 24 17:29:16 r500 kernel: pass0: Command Queueing enabled Sep 24 17:29:16 r500 kernel: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 Sep 24 17:29:16 r500 kernel: GEOM: new disk ada0 Sep 24 17:29:16 r500 kernel: ada0: ATA-8= SATA 1.x device Sep 24 17:29:16 r500 kernel: ada0: Serial Number 090509FB2F32LLEY6D8A Sep 24 17:29:16 r500 kernel: ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, = PIO 8192bytes) Sep 24 17:29:16 r500 kernel: ada0: Command Queueing enabled Sep 24 17:29:16 r500 kernel: ada0: 238475MB (488397168 512 byte sectors: 16= H 63S/T 16383C) Sep 24 17:29:16 r500 kernel: ada0: Previously was known as ad4 I'm using a couple of other patches, but the only one that is related to SCSI is: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D159611 Fabian --Sig_/fTzeD+fX2KOHTIiU3YSEE/0 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk5+Lx4ACgkQBYqIVf93VJ13CACfX2tbvtxmOs0GpX28Ay5mjNtX IcoAn1mryqZH4vhRUaU29C86cvSGVw3v =OhgE -----END PGP SIGNATURE----- --Sig_/fTzeD+fX2KOHTIiU3YSEE/0--