From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 01:39:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 686BF16A4CE for ; Sun, 8 Aug 2004 01:39:39 +0000 (GMT) Received: from gateway.nixsys.be (gateway.nixsys.be [195.144.77.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7C3743D3F for ; Sun, 8 Aug 2004 01:39:38 +0000 (GMT) (envelope-from philip@paeps.cx) Received: from erda.home.paeps.cx (erda.home.paeps.cx [IPv6:2001:838:37f:10::1]) by gateway.nixsys.be (Postfix) with ESMTP id BDFD159 for ; Sun, 8 Aug 2004 03:39:37 +0200 (CEST) Received: from fasolt.home.paeps.cx (fasolt.home.paeps.cx [10.0.0.2]) by erda.home.paeps.cx (Postfix) with ESMTP id D862020EE for ; Sun, 8 Aug 2004 03:39:29 +0200 (CEST) Received: from fasolt.home.paeps.cx (philip@localhost [127.0.0.1]) i781daiG008671 for ; Sun, 8 Aug 2004 03:39:36 +0200 (CEST) (envelope-from philip@fasolt.home.paeps.cx) Received: (from philip@localhost) by fasolt.home.paeps.cx (8.12.11/8.12.11/Submit) id i781daLU008670 for freebsd-current@freebsd.org; Sun, 8 Aug 2004 03:39:36 +0200 (CEST) (envelope-from philip) Date: Sun, 8 Aug 2004 03:39:36 +0200 From: Philip Paeps To: freebsd-current@freebsd.org Message-ID: <20040808013936.GN11982@fasolt.home.paeps.cx> Mail-Followup-To: freebsd-current@freebsd.org References: <20040805071236.GA595@loge.nixsys.be> <20040806160610.GD803@loge.nixsys.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040806160610.GD803@loge.nixsys.be> X-Date-in-Rome: ante diem VII Idius Augustas MMDCCLVII ab Urbe Condida X-PGP-Fingerprint: FA74 3C27 91A6 79D5 F6D3 FC53 BF4B D0E6 049D B879 X-Message-Flag: Get a proper mailclient! User-Agent: Mutt/1.5.6i Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 01:39:39 -0000 On 2004-08-06 18:06:10 (+0200), Philip Paeps wrote: > On 2004-08-05 09:12:36 (+0200), Philip Paeps wrote: > > If you happen to own a laptop with a synaptics touchpad, please help test: > > > > > > I updated the patch to be a bit cleaner. I also fixed the sensitivity > issues many have reported. That fix also appears to (at least partly) solve > the sticky issue. This was committed to -current a while ago. I'll make patches for releng_4 too if noone complains :-) > Still to do [...] proper support for guest devices. Arne Schwabe submitted a patch for that which I'll commit later on. Thanks guys :-) - Philip -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. All warranties expire upon payment of invoice. From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 02:48:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70CE316A4CE; Sun, 8 Aug 2004 02:48:26 +0000 (GMT) Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C9A243D1F; Sun, 8 Aug 2004 02:48:26 +0000 (GMT) (envelope-from allbery@ece.cmu.edu) Received: from [10.9.204.1] (dsl093-061-215.pit1.dsl.speakeasy.net [66.93.61.215]) by bache.ece.cmu.edu (Postfix) with ESMTP id 4F56982; Sat, 7 Aug 2004 22:48:24 -0400 (EDT) From: "Brandon S. Allbery KF8NH" To: "Bruce A. Mah" In-Reply-To: <1091824128.23206.52.camel@tomcat.kitchenlab.org> References: <16659.6061.369420.562800@roam.psg.com> <1091822755.23206.39.camel@tomcat.kitchenlab.org> <16659.58793.887526.631294@roam.psg.com> <1091824128.23206.52.camel@tomcat.kitchenlab.org> Content-Type: text/plain Message-Id: <1091933302.56646.1.camel@rushlight.kf8nh.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 07 Aug 2004 22:48:23 -0400 Content-Transfer-Encoding: 7bit cc: Randy Bush cc: FreeBSD Current Subject: Re: usb palm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 02:48:26 -0000 On Fri, 2004-08-06 at 16:28, Bruce A. Mah wrote: > If you're coming from a sync-over-serial situation (or if you haven't > tried this at all) it might be natural to treat /dev/uvisor like a > serial port over which you can do a sync. For some set of PalmOS > devices (which includes my Sony TJ37) this doesn't work. I had to do a (...) > Grenville had a Tungsten-C so this might be applicable to you. For what it's worth, my Tungsten T3 syncs fine over USB with -STABLE. -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [WAY too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon univ. KF8NH From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 03:16:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E12EE16A4CE for ; Sun, 8 Aug 2004 03:16:35 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A06543D2F for ; Sun, 8 Aug 2004 03:16:35 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i783Dtl5040956 for ; Sat, 7 Aug 2004 21:13:56 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 07 Aug 2004 21:13:54 -0600 (MDT) Message-Id: <20040807.211354.115654900.imp@bsdimp.com> To: current@freebsd.org From: "M. Warner Losh" In-Reply-To: <20040807.081536.72687734.imp@bsdimp.com> References: <20040807.081536.72687734.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: world breakage? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 03:16:36 -0000 In message: <20040807.081536.72687734.imp@bsdimp.com> "M. Warner Losh" writes: : With sources from last night (approx 0300 UTC) : : ===> lib/libcom_err/doc : cc -O -pipe -I/dell/imp/FreeBSD/src/lib/libcom_err/../../contrib/com_err -c /dell/imp/FreeBSD/src/lib/libcom_err/../../contrib/com_err/com_err.c : cc -O -pipe -I/dell/imp/FreeBSD/src/lib/libcom_err/../../contrib/com_err -c /dell/imp/FreeBSD/src/lib/libcom_err/../../contrib/com_err/error.c : building static com_err library : ranlib libcom_err.a : cc -fpic -DPIC -O -pipe -I/dell/imp/FreeBSD/src/lib/libcom_err/../../contrib/com_err -c /dell/imp/FreeBSD/src/lib/libcom_err/../../contrib/com_err/com_err.c -o com_err.So : cc -fpic -DPIC -O -pipe -I/dell/imp/FreeBSD/src/lib/libcom_err/../../contrib/com_err -c /dell/imp/FreeBSD/src/lib/libcom_err/../../contrib/com_err/error.c -o error.So : building shared library libcom_err.so.2 : /dell/imp/obj/dell/imp/FreeBSD/src/i386/usr/bin/ld: cannot find -lgcc_pic : *** Error code 1 : : Has anybody else seen this? Rule number 1: don't complain about problems until you try it on a virgin tree. One of my silly little patches causes this to happen... I removed it, and I can compile w/o a hassle now. Warner From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 03:59:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02DEF16A4CF for ; Sun, 8 Aug 2004 03:59:05 +0000 (GMT) Received: from mail.tellme3times.com (dsl-yul-102.e-scape.net [209.47.218.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23F6A43D54 for ; Sun, 8 Aug 2004 03:59:04 +0000 (GMT) (envelope-from chris@tellme3times.com) Received: from tellme3times.com (halla.tellme3times.com [192.168.7.29]) by mail.tellme3times.com (Postfix) with ESMTP id 282124095; Sat, 7 Aug 2004 23:53:31 -0400 (EDT) Message-ID: <4115A68E.8000006@tellme3times.com> Date: Sun, 08 Aug 2004 00:05:34 -0400 From: Chris User-Agent: Mozilla Thunderbird 0.5 (X11/20040413) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <4110F5AE.6030403@tellme3times.com> <20040804.212242.112819552.imp@bsdimp.com> <41124C8B.2060902@tellme3times.com> <20040806.231231.33567668.imp@bsdimp.com> In-Reply-To: <20040806.231231.33567668.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: USB drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 03:59:06 -0000 M. Warner Losh wrote: > >I think that the first thing that should be done is to look at the usb >configuration. /usr/ports/sysutils/udesc_dump is a good place to >start to investigate things. Also, the usb mindshare book is good to >understand usb and the layers of the configuation onion. There's a >book in the works that should help, but I'm afraid that I can't say >more than that at this time. > >Warner > > Here is the output from udesc_dump which is fine. I could not figure out how to kldunload just ulpt.ko so I recompiled a new kernel. halla# udesc_dump Standard Device Descriptor: bLength 18 bDescriptorType 01 bcdUSB 0110 bDeviceClass 00 bDeviceSubClass 00 bDeviceProtocol 00 bMaxPacketSize 8 idVendor 04b8 idProduct 0808 bcdDevice 0100 iManufacturer 1 iProduct 2 iSerialNumber 3 bNumConfigurations 1 Configuration 0: Standard Configuration Descriptor: bLength 9 bDescriptorType 02 wTotalLength 55 bNumInterface 2 bConfigurationValue 1 iConfiguration 4 bmAttributes c0 (self-powered) bMaxPower 1 (2 mA) Standard Interface Descriptor: bLength 9 bDescriptorType 04 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass ff bInterfaceSubClass ff bInterfaceProtocol ff iInterface 5 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 81 (in) bmAttributes 02 (Bulk) wMaxPacketSize 64 bInterval 0 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 02 (out) bmAttributes 02 (Bulk) wMaxPacketSize 64 bInterval 0 Standard Interface Descriptor: bLength 9 bDescriptorType 04 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 07 bInterfaceSubClass 01 bInterfaceProtocol 02 iInterface 6 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 04 (out) bmAttributes 02 (Bulk) wMaxPacketSize 64 bInterval 0 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 83 (in) bmAttributes 02 (Bulk) wMaxPacketSize 64 bInterval 0 Codes Representing Languages by the Device: bLength 4 bDescriptorType 03 wLANGID[0] 0409 String (index 1): EPSON String (index 2): USB MFP String (index 3): RC0438001041259320 String (index 4): USB MFP String (index 5): EPSON Scanner String (index 6): USB Printer halla# From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 04:01:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8528D16A4CF for ; Sun, 8 Aug 2004 04:01:52 +0000 (GMT) Received: from mail.tellme3times.com (dsl-yul-102.e-scape.net [209.47.218.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34FE743D31 for ; Sun, 8 Aug 2004 04:01:52 +0000 (GMT) (envelope-from chris@tellme3times.com) Received: from tellme3times.com (halla.tellme3times.com [192.168.7.29]) by mail.tellme3times.com (Postfix) with ESMTP id EF00D4261; Sat, 7 Aug 2004 23:56:19 -0400 (EDT) Message-ID: <4115A736.9000705@tellme3times.com> Date: Sun, 08 Aug 2004 00:08:22 -0400 From: Chris User-Agent: Mozilla Thunderbird 0.5 (X11/20040413) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Darren Pilgrim References: <000001c47cb8$8ef1bb50$142a15ac@spud> In-Reply-To: <000001c47cb8$8ef1bb50$142a15ac@spud> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: "'M. Warner Losh'" Subject: Re: USB drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 04:01:52 -0000 Darren Pilgrim wrote: >>From: M. Warner Losh >> >>In message: <41124C8B.2060902@tellme3times.com> >> Chris writes: >>: >>: What I am trying to determine is why my multifunction >> >> >printer/scanner > > >>: receives only one of the two drivers. Is it because the printer >> >> >does > > >>: not respond properly? Is it because the printer is not defined? I >>: have many questions here. >> >>Yes. Usb is a little complicated in this area, and there are a number >>of details that are hard to get right. It wouldn't surprise me if the >>current set of drivers are less than completely optimal. >> >> > >On a bit of a side-track, I'm wondering if it could be due to how the >multifunction device presents itself? A bit back in this thread someone >mentioned that a pointer must be present for a driver to attach to a >device. If there is only one pointer for a device, only one driver may >attach. Since a single USB bus can have a LOT of devices and each >device's capabilities are determined through the presence of usage >pages, I see two ways for a multifunction device to present itself: > >- A single device ID with more than one usage page. All the >functionality is there and is compatible with FreeBSD drivers, but since >there is only one device probed on the bus, only one driver may attach. >Perhaps a "simple" mux driver would be useful? > >- A multiple single-usage device IDs. Same functionality as before, but >now FreeBSD can probe unique printer and scanner devices and thus let >both ulpt and uscanner attach simutaneously. > >Am I way off base? > > > > What I would like to know is where are these tests done. Or should I say where does USB start to load and what are the steps in between. Chris From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 04:13:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 575E416A4CF for ; Sun, 8 Aug 2004 04:13:44 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AA9B43D5A for ; Sun, 8 Aug 2004 04:13:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i784AuFV041366; Sat, 7 Aug 2004 22:10:56 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 07 Aug 2004 22:10:55 -0600 (MDT) Message-Id: <20040807.221055.107701749.imp@bsdimp.com> To: chris@tellme3times.com From: "M. Warner Losh" In-Reply-To: <4115A736.9000705@tellme3times.com> References: <000001c47cb8$8ef1bb50$142a15ac@spud> <4115A736.9000705@tellme3times.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: dmp@bitfreak.org cc: freebsd-current@freebsd.org Subject: Re: USB drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 04:13:44 -0000 In message: <4115A736.9000705@tellme3times.com> Chris writes: : Darren Pilgrim wrote: : : >>From: M. Warner Losh : >> : >>In message: <41124C8B.2060902@tellme3times.com> : >> Chris writes: : >>: : >>: What I am trying to determine is why my multifunction : >> : >> : >printer/scanner : > : > : >>: receives only one of the two drivers. Is it because the printer : >> : >> : >does : > : > : >>: not respond properly? Is it because the printer is not defined? I : >>: have many questions here. : >> : >>Yes. Usb is a little complicated in this area, and there are a number : >>of details that are hard to get right. It wouldn't surprise me if the : >>current set of drivers are less than completely optimal. : >> : >> : > : >On a bit of a side-track, I'm wondering if it could be due to how the : >multifunction device presents itself? A bit back in this thread someone : >mentioned that a pointer must be present for a driver to attach to a : >device. If there is only one pointer for a device, only one driver may : >attach. Since a single USB bus can have a LOT of devices and each : >device's capabilities are determined through the presence of usage : >pages, I see two ways for a multifunction device to present itself: : > : >- A single device ID with more than one usage page. All the : >functionality is there and is compatible with FreeBSD drivers, but since : >there is only one device probed on the bus, only one driver may attach. : >Perhaps a "simple" mux driver would be useful? : > : >- A multiple single-usage device IDs. Same functionality as before, but : >now FreeBSD can probe unique printer and scanner devices and thus let : >both ulpt and uscanner attach simutaneously. : > : >Am I way off base? : > : > : > : > : What I would like to know is where are these tests done. Or should I say : where does USB start to load and what are the steps in between. In usb_subr.c, routine usbd_probe_and_attach is where the child's config stuff is done that I posted before. Warner From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 05:10:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id BA08416A4E2; Sun, 8 Aug 2004 05:10:42 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i785AerZ022740; Sun, 8 Aug 2004 01:10:40 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i785AdF5022739; Sun, 8 Aug 2004 01:10:39 -0400 (EDT) (envelope-from green) Date: Sun, 8 Aug 2004 01:10:38 -0400 From: Brian Fundakowski Feldman To: "Bruce A. Mah" Message-ID: <20040808051038.GA14657@green.homeunix.org> References: <16659.6061.369420.562800@roam.psg.com> <1091822755.23206.39.camel@tomcat.kitchenlab.org> <16659.58793.887526.631294@roam.psg.com> <1091824128.23206.52.camel@tomcat.kitchenlab.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1091824128.23206.52.camel@tomcat.kitchenlab.org> User-Agent: Mutt/1.5.6i cc: Randy Bush cc: FreeBSD Current Subject: Re: usb palm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 05:10:43 -0000 On Fri, Aug 06, 2004 at 01:28:48PM -0700, Bruce A. Mah wrote: > Compounding this problem for me was that the uvisor driver somehow > couldn't find the right attachment point (port?) on the TJ37. This is > the part that green@ and I did a couple of iterations on. (He was > trying to get a Handspring Treo to work.) This was in a thread on > current@ that started on 1 July 2004 with this email: > > Message-ID: <20040701154429.GA3543@tomcat.kitchenlab.org> > > The end result was a patch to uvisor that lets me sync. It's not > committed to the tree yet. Not sure what green@'s plans are for this. > I'm happy to keep it as a local mod. I haven't really had the opportunity to get back to that and re-add the local support for another device I removed at the time of making that.... for some reason NetBSD has support for it disabled like it never worked at all, so I have no idea what's going on there. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 05:11:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AEAF16A4CE for ; Sun, 8 Aug 2004 05:11:14 +0000 (GMT) Received: from mail.tellme3times.com (dsl-yul-102.e-scape.net [209.47.218.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 086A443D5E for ; Sun, 8 Aug 2004 05:11:14 +0000 (GMT) (envelope-from chris@tellme3times.com) Received: from tellme3times.com (halla.tellme3times.com [192.168.7.29]) by mail.tellme3times.com (Postfix) with ESMTP id DF8DC41F1; Sun, 8 Aug 2004 01:05:40 -0400 (EDT) Message-ID: <4115B777.7070008@tellme3times.com> Date: Sun, 08 Aug 2004 01:17:43 -0400 From: Chris User-Agent: Mozilla Thunderbird 0.5 (X11/20040413) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <20040806.231231.33567668.imp@bsdimp.com> <000001c47cb8$8ef1bb50$142a15ac@spud> <20040807.155920.66760165.imp@bsdimp.com> In-Reply-To: <20040807.155920.66760165.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: dmp@bitfreak.org cc: freebsd-current@freebsd.org Subject: Re: USB drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 05:11:14 -0000 M. Warner Losh wrote: > >No. You are exactly on base. That's why I pointed at you at the usb >information program. Run it with the device plugged in, and we'll be >able to know the details. > >Warner > > If I read this correctly 1 device with two interfaces. The first for the scanner and the second for the printer. Standard Device Descriptor: bLength 18 bDescriptorType 01 bcdUSB 0110 bDeviceClass 00 bDeviceSubClass 00 bDeviceProtocol 00 bMaxPacketSize 8 idVendor 04b8 idProduct 0808 bcdDevice 0100 iManufacturer 1 iProduct 2 iSerialNumber 3 bNumConfigurations 1 Configuration 0: Standard Configuration Descriptor: bLength 9 bDescriptorType 02 wTotalLength 55 bNumInterface 2 bConfigurationValue 1 iConfiguration 4 bmAttributes c0 (self-powered) bMaxPower 1 (2 mA) Standard Interface Descriptor: bLength 9 bDescriptorType 04 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass ff bInterfaceSubClass ff bInterfaceProtocol ff iInterface 5 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 81 (in) bmAttributes 02 (Bulk) wMaxPacketSize 64 bInterval 0 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 02 (out) bmAttributes 02 (Bulk) wMaxPacketSize 64 bInterval 0 Standard Interface Descriptor: bLength 9 bDescriptorType 04 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 07 bInterfaceSubClass 01 bInterfaceProtocol 02 iInterface 6 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 04 (out) bmAttributes 02 (Bulk) wMaxPacketSize 64 bInterval 0 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 83 (in) bmAttributes 02 (Bulk) wMaxPacketSize 64 bInterval 0 Codes Representing Languages by the Device: bLength 4 bDescriptorType 03 wLANGID[0] 0409 String (index 1): EPSON String (index 2): USB MFP String (index 3): RC0438001041259320 String (index 4): USB MFP String (index 5): EPSON Scanner String (index 6): USB Printer From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 06:49:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1680E16A4CE for ; Sun, 8 Aug 2004 06:49:24 +0000 (GMT) Received: from les.ath.cx (12.41.244.43.ap.yournet.ne.jp [43.244.41.12]) by mx1.FreeBSD.org (Postfix) with SMTP id 44B7543D53 for ; Sun, 8 Aug 2004 06:49:23 +0000 (GMT) (envelope-from qhwt+freebsd-current@les.ath.cx) Received: (qmail 37092 invoked by uid 1000); 8 Aug 2004 06:49:12 -0000 Date: Sun, 8 Aug 2004 15:49:12 +0900 From: YONETANI Tomokazu To: "Michael C. Shultz" Message-ID: <20040808064912.GA27705@les.ath.cx> References: <200408071057.06960.ringworm@inbox.lv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408071057.06960.ringworm@inbox.lv> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: Need help: buildworld for CURRENT while under STABLE is not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 06:49:24 -0000 Hi. On Sat, Aug 07, 2004 at 10:57:06AM -0700, Michael C. Shultz wrote: > I have STABLE on ad0 and a working snapshot of CURRENT on ad1, I am trying > to run: > > make buildworld -DDESTDIR=/ad1 while booted from STABLE and I keep getting the > following error: (Note: cvsup'ed just before running make build world still > didn't help, neither does cleaning before hand...) I'll attach my make.conf > in case that helps... Do you get the same error if you run `make buildworld' without -DDESTDIR=/ad1 ? From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 09:06:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12D7F16A4CE for ; Sun, 8 Aug 2004 09:06:33 +0000 (GMT) Received: from sv07e.atm-tzs.kmjeuro.com (sv07e.atm-tzs.kmjeuro.com [193.81.94.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7AB343D3F for ; Sun, 8 Aug 2004 09:06:31 +0000 (GMT) (envelope-from k.joch@kmjeuro.com) Received: from [192.168.2.30] (adsl.sbg.kmjeuro.com [62.99.198.46]) (authenticated bits=0)i7895luR093961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 8 Aug 2004 11:05:49 +0200 (CEST) (envelope-from k.joch@kmjeuro.com) Message-ID: <4115ECE6.30005@kmjeuro.com> Date: Sun, 08 Aug 2004 11:05:42 +0200 From: "Karl M. Joch" Organization: KMJ Consulting User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-CTS-SV07-Mailserver-Information: please visit www.ctseuro.com for further instructions. Protected by www.ctseuro.com X-CTS-SV07-Mailserver: Found to be clean X-CTS-SV07-Mailserver-From: k.joch@kmjeuro.com Subject: Dummynet with IPv6 freezes the box X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 09:06:33 -0000 Upgraded a box from 5.2.1-p6 to p8 and added the dummynet options. wehen the system boots is also starts hf6to4 initializing IPv6 over v4. at the time hf6to4 starts the box freezes. i moved back to a kernel without dummynet now and everything is ok again. are there any known problems with IPv6 and DUMMYNET options? many thanks, karl # # CTSSINGLECPU -- Generic kernel configuration file for FreeBSD/i386 # # $FreeBSD: src/sys/i386/conf/CTSSINGLECPU,v 1.394.2.3 2004/01/26 19:42:11 nectar Exp $ machine i386 #cpu I486_CPU cpu I586_CPU cpu I686_CPU ident CTSSINGLECPU #To statically compile in device wiring instead of /boot/device.hints #hints "CTSSINGLECPU.hints" #Default places to look for devices. #makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options SCHED_4BSD #4BSD scheduler options INET #InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options MD_ROOT #MD is a potential root device options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server options NFS_ROOT #NFS usable as /, requires NFSCLIENT options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options SCSI_DELAY=15000 #Delay (in ms) before probing SCSI ##options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options PFIL_HOOKS # pfil(9) framework # Debugging for use in -current #options DDB #Enable the kernel debugger #options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS #Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN #Don't run witness on spinlocks for speed # To make an SMP kernel, the next two are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC device isa device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices device ahd # AHA39320/29320 and onboard AIC79xx devices device amd # AMD 53C974 (Tekram DC-390(T)) device isp # Qlogic family device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aha # Adaptec 154x SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI adapters device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device ciss # Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) device ida # Compaq Smart RAID device mlx # Mylex DAC960 family device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # Pcmcia and cardbus bridge support device cbb # cardbus (yenta) bridge #device pcic # ExCA ISA and PCI bridges device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bfe # Broadcom BCM440x 10/100 ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device pcn # AMD Am79C97x PCI 10/100 (precedence over 'lnc') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x and SK-982x gigabit ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device ti # Alteon Networks Tigon I/II gigabit ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard nics included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. device lnc # NE2100, NE32-VL Lance Ethernet cards device sn # SMC's 9000 series of ethernet chips device xe # Xircom pccard ethernet # ISA devices that use the old ISA shims #device le # Wireless NIC cards device wlan # 802.11 support device an # Aironet 4500/4800 802.11 wireless NICs. device awi # BayStack 660 and others device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices - the number indicates how many units to allocate. device random # Entropy device device loop # Network loopback device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Ethernet, requires mii device aue # ADMtek USB ethernet device axe # ASIX Electronics USB ethernet device cue # CATC USB ethernet device kue # Kawasaki LSI USB ethernet # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) ################################################################################ ## out additions for Firewall && Filssystems. ################################################################################ options IPFIREWALL options IPFIREWALL_VERBOSE options IPDIVERT ################################################################################ ## IPV6 and IPSEC Tunnelinf IPV4 IPV6 ################################################################################ device stf #6to4 IPv6 over IPv4 encapsulation options IPSEC options IPSEC_ESP options IPV6FIREWALL options IPV6FIREWALL_VERBOSE #options IPV6FIREWALL_VERBOSE_LIMIT=100 ################################################################################ ## We really want Dummynet for traffic shaping here ################################################################################ options DUMMYNET options HZ=1000 ################################################################################ ## we want quotas here! ################################################################################ options QUOTA From owner-freebsd-current@FreeBSD.ORG Sat Aug 7 20:13:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8080716A4CE; Sat, 7 Aug 2004 20:13:11 +0000 (GMT) Received: from av9-1-sn4.m-sp.skanova.net (av9-1-sn4.m-sp.skanova.net [81.228.10.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF71443D2F; Sat, 7 Aug 2004 20:13:10 +0000 (GMT) (envelope-from petero2@telia.com) Received: by av9-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 26B3E37F01; Sat, 7 Aug 2004 22:13:10 +0200 (CEST) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av9-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 16A1537E56; Sat, 7 Aug 2004 22:13:10 +0200 (CEST) Received: from p4.localdomain (h29n2fls305o1035.telia.com [81.227.177.29]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id D41D937E50; Sat, 7 Aug 2004 22:13:09 +0200 (CEST) Received: from localhost (p4.localdomain [127.0.0.1]) by p4.localdomain (8.12.11/8.12.11) with ESMTP id i77KD9jf006186; Sat, 7 Aug 2004 22:13:09 +0200 Date: Sat, 7 Aug 2004 22:13:09 +0200 (CEST) From: Peter Osterlund X-X-Sender: petero@p4.localdomain To: Arne Schwabe In-Reply-To: <86u0veq3en.fsf@kamino.rfc1149.org> Message-ID: References: <86u0veq3en.fsf@kamino.rfc1149.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Sun, 08 Aug 2004 11:45:01 +0000 cc: freebsd-current@freebsd.org cc: freebsd-mobile@freebsd.org Subject: Re: Synaptics Driver Patch (new Version) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 07 Aug 2004 20:13:11 -0000 On Sat, 7 Aug 2004, Arne Schwabe wrote: > Peter Osterlund writes: > > >> > http://w1.894.telia.com/~u89404340/syn.tar.bz2 > >> > >> Okay let me hear If you got something, so I can test it. > > > > Now I have uploaded a new version to the same URL. You should set > > Protocol to "psm" in XF86Config to enable the FreeBSD psm driver > > protocol. > > > > Feedback is wanted, because I don't have a FreeBSD system to test on. > > I am very sorry that I did not reply. > It works ;) Good. > But since the synpatics support is now in FreeBSD-current kernel, the > ioctl change a little bit, patch is attached. > > There is no need to support the older ioctl. Thanks, I'll include this patch in the next release. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340 From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 06:22:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A995A16A4CE for ; Sun, 8 Aug 2004 06:22:52 +0000 (GMT) Received: from www1.pochta.ru (www1.pochta.ru [81.211.64.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD43943D1D for ; Sun, 8 Aug 2004 06:22:51 +0000 (GMT) (envelope-from jamper@hotbox.ru) Received: by HotBOX.Ru WebMail v2.1 id i786Mnhe017474; Sun, 8 Aug 2004 10:22:49 +0400 (MSD) Date: Sun, 8 Aug 2004 10:22:49 +0400 (MSD) Message-Id: <200408080622.i786Mnhe017474@www1.pochta.ru> From: Jamper To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-Mailer: Free WebMail POCHTA.RU X-Proxy-IP: [62.205.183.36] X-Originating-IP: [unknown] X-Mailman-Approved-At: Sun, 08 Aug 2004 11:45:01 +0000 Subject: IPSec + 5.2.current Problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 06:22:52 -0000 Have worked computer with racoon 17a freebsd 5.2.cur(Jan-Feb) try to recompile kernel to freebsd 5.2.cur(Aug) Ipsec stop to work. Look in maillist. This problem is discribed, but im not found the solve. My tring with FAST_IPSEC, disable gif, manual route configureation,rtfm goes to nothing. Thanks From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 07:24:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFABA16A4CE for ; Sun, 8 Aug 2004 07:24:08 +0000 (GMT) Received: from mails.tsinghua.edu.cn (mails.tsinghua.edu.cn [166.111.8.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 7E40143D41 for ; Sun, 8 Aug 2004 07:24:07 +0000 (GMT) (envelope-from luohong99@mails.tsinghua.edu.cn) Received: (eyou send program); Sun, 08 Aug 2004 15:19:16 +0800 Message-ID: <291949556.22743@mails.tsinghua.edu.cn> Received: from unknown (HELO mails.tsinghua.edu.cn) (unknown@127.0.0.1) by 127.0.0.1 with SMTP; Sun, 08 Aug 2004 15:19:16 +0800 X-scanvirus: By Symantec Scan Engine X-scanresult: CLEAN Received: (eqmail ); 8 Aug 2004 07:19:15 -0000 Received: from localhost (HELO ?166.111.172.64?) (luohong99@127.0.0.1) by localhost with SMTP; 8 Aug 2004 07:19:15 -0000 Message-ID: <4115D510.5010806@mails.tsinghua.edu.cn> Date: Sun, 08 Aug 2004 15:24:00 +0800 From: Luo Hong User-Agent: Mozilla Thunderbird 0.7 (X11/20040629) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <41131EEC.4050909@root.org> In-Reply-To: <41131EEC.4050909@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 08 Aug 2004 11:45:16 +0000 Subject: Re: PLEASE TEST: acpi pci irq routing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 07:24:08 -0000 With the new code, the system did not generate any wrong printf during the boot, but the PS/2 mouse could not be used, just like in PR55473. After I have applied the following patch, the system really generated some wrong printf's, but the mouse worked again. My motherboard is Iwill KK266 with Award BIOS. The patch is here: --- acpi_pci_link.c.orig Sun Aug 8 13:12:14 2004 +++ acpi_pci_link.c Sun Aug 8 13:44:34 2004 @@ -467,10 +467,11 @@ * PCI link status (_STA) is unreliable. Many systems return * erroneous values so we ignore it. */ - if ((sta & (ACPI_STA_PRESENT | ACPI_STA_FUNCTIONAL)) == 0) { + if ((sta & ACPI_STA_ENABLED) == 0) { #ifndef ACPI_OLD_PCI_LINK device_printf(pcidev, "acpi PRT ignoring status for %s\n", acpi_name(handle)); + return_ACPI_STATUS (AE_ERROR); #else ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "interrupt link is not functional - %s\n", and the dmesg when the mouse works well is here: Copyright (c) 1992-2004 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 5.2-CURRENT #11: Sun Aug 8 13:50:55 CST 2004 root@bfdream.9966.org:/freebsd/obj/freebsd/HEAD/src/sys/BFDREAM Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) processor (997.80-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183f9ff AMD Features=0xc0440000 real memory = 805240832 (767 MB) avail memory = 782893056 (746 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [GIANT-LOCKED] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pcib0: acpi PRT ignoring status for \\_SB_.PCI0.LNKB pcib0: acpi PRT ignoring status for \\_SB_.PCI0.LNKB pcib0: acpi PRT ignoring status for \\_SB_.PCI0.LNKB pcib0: acpi PRT ignoring status for \\_SB_.PCI0.LNKB pcib0: acpi PRT ignoring status for \\_SB_.PCI0.LNKB pcib0: acpi PRT ignoring status for \\_SB_.PCI0.LNKB pcib0: acpi PRT ignoring status for \\_SB_.PCI0.LNKB pcib0: acpi PRT ignoring status for \\_SB_.PCI0.LNKB pcib0: acpi PRT ignoring status for \\_SB_.PCI0.LNKB pcib0: acpi PRT ignoring status for \\_SB_.PCI0.LNKB pci0: on pcib0 agp0: mem 0xd0000000-0xd7ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 drm0: port 0xc000-0xc0ff mem 0xe1000000-0xe107ffff,0xd8000000-0xdfffffff irq 9 at device 0.0 on pci1 info: [drm] AGP at 0xd0000000 128MB info: [drm] Initialized radeon 1.11.0 20020828 on minor 0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xd000-0xd00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Correcting VIA config for southbridge data corruption bug ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 7.2 (no driver attached) pci0: at device 7.3 (no driver attached) pci0: at device 7.4 (no driver attached) fxp0: port 0xdc00-0xdc3f mem 0xe3000000-0xe30fffff,0xe3100000-0xe3100fff irq 10 at device 11.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:90:27:59:62:91 fxp0: [GIANT-LOCKED] pci0: at device 12.0 (no driver attached) pcm0: port 0xe400-0xe4ff irq 10 at device 15.0 on pci0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 orm0: at iomem 0xc0000-0xc7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 997803424 Hz quality 800 Timecounters tick every 10.000 msec acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% ATAPI_RESET time = 20us ad0: 117800MB [239340/16/63] at ata0-master UDMA100 acd0: CDROM at ata0-slave UDMA33 ad1: 39266MB [79780/16/63] at ata1-master UDMA100 Mounting root from ufs:/dev/ad0s1a Thanks, Hong Luo From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 11:55:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98AE216A4CE for ; Sun, 8 Aug 2004 11:55:51 +0000 (GMT) Received: from joostm.nl (62-177-151-10.bbeyond.nl [62.177.151.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B67943D5C for ; Sun, 8 Aug 2004 11:55:50 +0000 (GMT) (envelope-from j@joostm.nl) Received: from joostm.nl (asterix-114.gallia [172.17.114.2]) by onix.gallia (8.12.10/8.13.1) with ESMTP id i78BPLSB011314 for ; Sun, 8 Aug 2004 13:25:21 +0200 (CEST) (envelope-from j@joostm.nl) Message-ID: <41160EDA.40800@joostm.nl> Date: Sun, 08 Aug 2004 13:30:34 +0200 From: Joost Mulders User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.4) Gecko/20040524 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: D-Link DFE-690TXD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: j@joostm.nl List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2004 11:55:51 -0000 Hi, I happen to own a D-Link DFE-690TXD cardbus network adapter for my laptop. After reading the comments if_rl.c, I regret to have bought it this "redefinition of low end" :-) With 5.2.1-RELEASE and this card, if_rl hangs in rl_probe() at hwrev = CSR_READ_4(sc, RL_TXCFG) & RL_TXCFG_HWREV; I saw quite some modifications in current for if_rl, so I upgraded last night to current. The good news is that the card now just works: > rl0: port 0x1100-0x11ff mem 0x88000000-0x880001ff irq 10 at device 0.0 on cardbus0 > miibus1: on rl0 > rlphy0: on miibus1 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > rl0: Ethernet address: 00:0d:88:2c:a3:f7 > rl0: [GIANT-LOCKED] Running ttcp over this card showed about 8.5MB/s at the expense of quite some CPU cycles. However, while doing this, I noticed these messages > rl0: discard oversize frame (ether type 800 flags 3 len 21569 > max 1514) > rl0: discard oversize frame (ether type 8001 flags 3 len 4520 > max 1514) > rl0: discard oversize frame (ether type ef27 flags 3 len 32684 > max 1514) > rl0: discard oversize frame (ether type 2f1a flags 3 len 49420 > max 1514) So, if_rl is receiving bogus frames. I'm happy to track this one down but have no clue where to start :-) * is it switch/cable? (it it is fine with the builtin fxp nic or is fxp just ignoring bogus frames without logging?) * is it cardbus or if_rl Any pointers appreciated, Joost -- j@joostm.nl From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 13:25:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A09716A4CF for ; Sun, 8 Aug 2004 13:25:22 +0000 (GMT) Received: from beagle2.mehnert.org (beagle2.mehnert.org [212.42.235.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A398843D53 for ; Sun, 8 Aug 2004 13:25:21 +0000 (GMT) (envelope-from hannes@mehnert.org) Received: from localhost (port-195-158-171-122.dynamic.qsc.de [195.158.171.122]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Hannes Mehnert", Issuer "mehnert root CA" (verified OK)) by beagle2.mehnert.org (Postfix) with ESMTP id 2E6DE9585D; Sun, 8 Aug 2004 15:25:15 +0200 (CEST) Date: Sun, 8 Aug 2004 15:25:24 +0200 From: Hannes Mehnert To: Jamper Message-ID: <20040808132524.GB1033@mehnert.org> References: <200408080622.i786Mnhe017474@www1.pochta.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408080622.i786Mnhe017474@www1.pochta.ru> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: IPSec + 5.2.current Problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 13:25:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Sun, Aug 08, 2004 at 10:22:49AM +0400, Jamper wrote: > Have worked computer with racoon 17a freebsd 5.2.cur(Jan-Feb) > try to recompile kernel to freebsd 5.2.cur(Aug) > > Ipsec stop to work. > > Look in maillist. This problem is discribed, but im not found the solve. > > My tring with FAST_IPSEC, disable gif, manual route configureation,rtfm goes to > nothing. When I set 'options MSIZE=512' in the kernel config, IPSec works for me. Without this option I get 'ERROR: pfkey.c:1076:pk_sendupdate(): libipsec failed send update (No buffer space available)' from racoon. Full racoon.log is still at https://berlin.ccc.de/~hannes/racoon.log Best Regards, Hannes Mehnert -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBFinBRcuNlziBjRwRAoBLAJsGcpE0cUAJCuzDhfird7j8J/q2XwCcCJ5a U5uIIIheFD+Vx3w7mjn3nY4= =vd9z -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 13:52:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D641C16A4CE for ; Sun, 8 Aug 2004 13:52:46 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A54943D41 for ; Sun, 8 Aug 2004 13:52:46 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i78DpUJa046303; Sun, 8 Aug 2004 07:51:30 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 08 Aug 2004 07:51:29 -0600 (MDT) Message-Id: <20040808.075129.93807062.imp@bsdimp.com> To: chris@tellme3times.com From: "M. Warner Losh" In-Reply-To: <4115B777.7070008@tellme3times.com> References: <000001c47cb8$8ef1bb50$142a15ac@spud> <20040807.155920.66760165.imp@bsdimp.com> <4115B777.7070008@tellme3times.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: dmp@bitfreak.org cc: freebsd-current@freebsd.org Subject: Re: USB drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 13:52:46 -0000 In message: <4115B777.7070008@tellme3times.com> Chris writes: : If I read this correctly 1 device with two interfaces. The first for the : scanner and the second for the printer. I think you are reading it correctly. I need to grab my decoder ring to make sure that it is scanner/printer and not printer/scanner... Warner From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 13:55:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AC9816A4CE for ; Sun, 8 Aug 2004 13:55:56 +0000 (GMT) Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA74043D41 for ; Sun, 8 Aug 2004 13:55:55 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd03.aul.t-online.de by mailout01.sul.t-online.com with smtp id 1Bto9Q-0004wG-01; Sun, 08 Aug 2004 15:55:52 +0200 Received: from Andro-Beta.Leidinger.net (EPZq+6ZSZenR20i0y8tiWzOvkE10tkFkQGaE4cQP2-dndlXT2okY8U@[217.83.29.116]) by fmrl03.sul.t-online.com with esmtp id 1Bto9D-1KbXto0; Sun, 8 Aug 2004 15:55:39 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) i78Dtf5K036473; Sun, 8 Aug 2004 15:55:42 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Sun, 8 Aug 2004 15:56:23 +0200 From: Alexander Leidinger To: Hannes Mehnert Message-Id: <20040808155623.2fa6fb4b@Magellan.Leidinger.net> In-Reply-To: <20040808132524.GB1033@mehnert.org> References: <200408080622.i786Mnhe017474@www1.pochta.ru> <20040808132524.GB1033@mehnert.org> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: EPZq+6ZSZenR20i0y8tiWzOvkE10tkFkQGaE4cQP2-dndlXT2okY8U@t-dialin.net cc: freebsd-current@freebsd.org cc: Jamper Subject: Re: IPSec + 5.2.current Problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 13:55:56 -0000 On Sun, 8 Aug 2004 15:25:24 +0200 Hannes Mehnert wrote: > > My tring with FAST_IPSEC, disable gif, manual route configureation,rtfm goes to > > nothing. > > When I set 'options MSIZE=512' in the kernel config, IPSec works for > me. > Without this option I get 'ERROR: pfkey.c:1076:pk_sendupdate(): > libipsec failed send update (No buffer space available)' from racoon. I don't have a problem with racoon (because I use MSIZE too), but I have a problem with the actual data transfer over the encrypted tunnel, see Message-Id: <20040805223027.7df0732b@Magellan.Leidinger.net>. If I use FAST_IPSEC instead of IPSEC, everything works. So you're able to transfer data over the tunnel with IPSEC? It's a simple configuration, I've configured a gif tunnel between the FreeBSD box and a hardware appliance (I've only access to the FreeBSD system), added some SPD entries with setkey, configured racoon with a pre-shared key and added a static route. With 4.10 this worked without problems. After replacing the 4.10 box with a 5-current one, I had to switch to FAST_IPSEC to get it working. Bye, Alexander. -- I'm available to get hired (preferred in .lu). http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 14:09:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 460FE16A4CE for ; Sun, 8 Aug 2004 14:09:54 +0000 (GMT) Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDDEF43D39 for ; Sun, 8 Aug 2004 14:09:53 +0000 (GMT) (envelope-from the_mip_rvl@myrealbox.com) Received: from [10.0.0.150] the_mip_rvl [145.53.68.203] $ on Novell NetWare; Sun, 08 Aug 2004 08:09:54 -0600 Message-ID: <41163432.2060905@myrealbox.com> Date: Sun, 08 Aug 2004 16:09:54 +0200 From: Roland van Laar User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike References: <20040807080046.M43382@www.ideaway.net> In-Reply-To: <20040807080046.M43382@www.ideaway.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: "BTX Halted" on Toshiba Portege 3010 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 14:09:54 -0000 Mike wrote: >Taking a hard drive from a working install of almost -current >and placing it into the Portege 3010 shows a dump of reg >values and the message "BTX Halted". This happens shortly >after typing /boot/loader at the boot: prompt; >moments later the machine reboots. >Googling points at playing with DMA/PIO options in the BIOS >until the message goes away - there are no such options in >the Portege's BIOS, but I've pretty much tweaked every >setting that there is, and the results are exactly the same. >I've also found some posts of freebsd 3.x supposedly working >with this machine. So... was something broken along the >way, was support removed, or is there something I am missing >which will allow me to boot this machine into 5-current? >Mike > > > I had a 3020 which died 2 months ago, haven't had a current on it since februari, so at least 5.2.1 should work fine. regards, Roland ps. This is more an e-mail for mobile@ From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 15:13:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFAE816A4CF for ; Sun, 8 Aug 2004 15:13:30 +0000 (GMT) Received: from mail.tellme3times.com (dsl-yul-102.e-scape.net [209.47.218.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36B6943D1D for ; Sun, 8 Aug 2004 15:13:30 +0000 (GMT) (envelope-from chris@tellme3times.com) Received: from tellme3times.com (halla.tellme3times.com [192.168.7.29]) by mail.tellme3times.com (Postfix) with ESMTP id 8DF6540DD; Sun, 8 Aug 2004 11:07:55 -0400 (EDT) Message-ID: <411644A1.1030002@tellme3times.com> Date: Sun, 08 Aug 2004 11:20:01 -0400 From: Chris User-Agent: Mozilla Thunderbird 0.5 (X11/20040413) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <000001c47cb8$8ef1bb50$142a15ac@spud> <20040807.155920.66760165.imp@bsdimp.com> <4115B777.7070008@tellme3times.com> <20040808.075129.93807062.imp@bsdimp.com> In-Reply-To: <20040808.075129.93807062.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: dmp@bitfreak.org cc: freebsd-current@freebsd.org Subject: Re: USB drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 15:13:30 -0000 M. Warner Losh wrote: >In message: <4115B777.7070008@tellme3times.com> > Chris writes: >: If I read this correctly 1 device with two interfaces. The first for the >: scanner and the second for the printer. > >I think you are reading it correctly. I need to grab my decoder ring >to make sure that it is scanner/printer and not printer/scanner... > >Warner > > A quick Google search tells me I'm right. Now I just have to figure out why, when I identify the scanner it does not continue to attache the printer. Chris From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 15:25:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E68E16A4CE; Sun, 8 Aug 2004 15:25:11 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE46E43D45; Sun, 8 Aug 2004 15:25:09 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 7DA771FF9A6; Sun, 8 Aug 2004 17:25:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 7B7321FF92F; Sun, 8 Aug 2004 17:25:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 4846415665; Sun, 8 Aug 2004 15:21:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 4595A15329; Sun, 8 Aug 2004 15:21:41 +0000 (UTC) Date: Sun, 8 Aug 2004 15:21:41 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: FreeBSD current mailing list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: FreeBSD arch mailing list Subject: NO_YP_LIBC patch - please test/review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 15:25:11 -0000 Hi, I am looking for more tests and reviews of the NO_YP_LIBC patch. You can find the latest version to test on http://sources.zabbadoz.net/freebsd/patchset/10039-no-yp-libc.diff You will need to apply the whole patch in order to successfully build a world with NO_YP_LIBC=yes in make.conf and thus be able to also test the changes. Mostly things like bind, sendmail, amd, etc. that still get build will need testing. If there are any problems or if it works for you or of you have further additions please let me know. -- Greetings Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 17:50:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF02716A4CE for ; Sun, 8 Aug 2004 17:50:17 +0000 (GMT) Received: from lakermmtao01.cox.net (lakermmtao01.cox.net [68.230.240.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 540C343D58 for ; Sun, 8 Aug 2004 17:50:17 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.71.51]) by lakermmtao01.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040808175013.NBFT15539.lakermmtao01.cox.net@dolphin.local.net> for ; Sun, 8 Aug 2004 13:50:13 -0400 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with ESMTP id i78HoDsd001498 for ; Sun, 8 Aug 2004 12:50:13 -0500 (CDT) (envelope-from conrads@dolphin.local.net) Received: (from conrads@localhost) by dolphin.local.net (8.13.1/8.13.1/Submit) id i78Ho86n001497 for freebsd-current@freebsd.org; Sun, 8 Aug 2004 12:50:08 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 08 Aug 2004 12:50:08 -0500 (CDT) Organization: A Rag-Tag Band of Drug-Crazed Hippies From: "Conrad J. Sabatier" To: freebsd-current@freebsd.org Subject: sys/conf/NOTES needs pruning/distributing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conrads@cox.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2004 17:50:18 -0000 If I understand correctly, sys/conf/NOTES should contain only universal options that are useable on any platform, correct? If so, then there are a number of devices/options that need to be cut and moved to their respective architectures' conf dirs. Quite a few of them, actually. -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 17:54:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 584B516A4CE for ; Sun, 8 Aug 2004 17:54:07 +0000 (GMT) Received: from lakermmtao01.cox.net (lakermmtao01.cox.net [68.230.240.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF61043D55 for ; Sun, 8 Aug 2004 17:54:06 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.71.51]) by lakermmtao01.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040808175406.NCKG15539.lakermmtao01.cox.net@dolphin.local.net> for ; Sun, 8 Aug 2004 13:54:06 -0400 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with ESMTP id i78Hs5II001518 for ; Sun, 8 Aug 2004 12:54:06 -0500 (CDT) (envelope-from conrads@dolphin.local.net) Received: (from conrads@localhost) by dolphin.local.net (8.13.1/8.13.1/Submit) id i78Hs01v001517 for freebsd-current@freebsd.org; Sun, 8 Aug 2004 12:54:00 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 08 Aug 2004 12:54:00 -0500 (CDT) Organization: A Rag-Tag Band of Drug-Crazed Hippies From: "Conrad J. Sabatier" To: freebsd-current@freebsd.org Subject: INCLUDE_CONFIG_FILE doesn't work anymore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conrads@cox.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2004 17:54:07 -0000 Including "options INCLUDE_CONFIG_FILE", while it doesn't break the kernel build, no longer actually seems to include the config file in the kernel. Using the magic "strings -n 3 ..." incantation returns only a couple of lines of gibberish now. -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 18:32:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8F7C16A4CE; Sun, 8 Aug 2004 18:32:47 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 721DA43D62; Sun, 8 Aug 2004 18:32:47 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i78IVIH2023298; Sun, 8 Aug 2004 14:31:18 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i78IVIbI023295; Sun, 8 Aug 2004 14:31:18 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 8 Aug 2004 14:31:18 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Conrad J. Sabatier" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: kan@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: INCLUDE_CONFIG_FILE doesn't work anymore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 18:32:48 -0000 On Sun, 8 Aug 2004, Conrad J. Sabatier wrote: > Including "options INCLUDE_CONFIG_FILE", while it doesn't break the > kernel build, no longer actually seems to include the config file in the > kernel. Using the magic "strings -n 3 ..." incantation returns only a > couple of lines of gibberish now. It could be that gcc 3.4 is cleverly optimization out the unused symbols? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 18:49:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 809A916A4CE for ; Sun, 8 Aug 2004 18:49:43 +0000 (GMT) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4883343D2D for ; Sun, 8 Aug 2004 18:49:42 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) i78Infqv001244 for ; Sun, 8 Aug 2004 11:49:41 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.12.11/8.12.11/Submit) id i78InffL001243 for current@freebsd.org; Sun, 8 Aug 2004 11:49:41 -0700 (PDT) (envelope-from david) Date: Sun, 8 Aug 2004 11:49:41 -0700 (PDT) From: David Wolfskill Message-Id: <200408081849.i78InffL001243@bunrab.catwhisker.org> To: current@freebsd.org Subject: ATA issues: ad0: FAILURE - ATA_IDENTIFY no interrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 18:49:43 -0000 This looks fairly unpleasant. Local CVS repo synced between 03:45 - 03:53 hrs. US/Pacific (PDT). Had one lockup during the "make -j8 buildworld," in the "stage 4.2: building libraries" phase, while lic_r was being built. (This also happened 3 of the previous 4 days, but not yesterday; it's an SMP system.) Rest, reboot to single user, "fsck -p && reboot || fsck -y" rebooted to multi-user OK, and I started the "make -j8 buildworld" over again, and this time it completed without incident. Built & installed the new kernel, installed world, mergemaster, reboot. Started seeing a bit of oddness with respect to module g_md (I use a swap-backed /tmp), and then ata0 & ad0 reported problems. Here's a cut/paste from my (serial) console: Sun Aug 8 09:50:13 PDT 2004 FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: Augboot() called on cpu#1 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... Syncer syncing, vnodes remaining...5 0 3 0 1 0 1 0 1 0 1 0 0 0 done Uptime: 1h44m59s Shutting down ACPI ACPI-0265: *** Error: Hardware never changed modes Rebooting... cpu_reset called on cpu#1 cpu_reset: Stopping other CPUs cpu_reset: Restarting BSP cpu_reset_proxy: Stopped CPU 1 Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/523200kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (root@freebeast.catwhisker.org, Sun Aug 8 10:22:51 PDT 2004) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x2ac338 data=0x31e18+0x3e5e8 syms=[0x4+0x3e860+0x4+0x4e1b6] /boot/kernel/snd_cmi.ko text=0x2c50 data=0x29c syms=[0x4+0x9d0+0x4+0x9a8] loading required module 'sound' /boot/kernel/sound.ko text=0x13884 data=0x2794+0x10b8 syms=[0x4+0x2b80+0x4+0x30a0] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... /boot/kernel/acpi.ko text=0x3eba8 data=0x1a84+0xd2c syms=[0x4+0x6f60+0x4+0x90e8] GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009fc00 SMAP type=01 base=000000000009fc00 len=0000000000000400 SMAP type=02 base=00000000000f0000 len=0000000000010000 SMAP type=02 base=00000000fec00000 len=0000000001400000 SMAP type=01 base=0000000000100000 len=000000001fef0000 SMAP type=03 base=000000001fff3000 len=000000000000d000 SMAP type=04 base=000000001fff0000 len=0000000000003000 Copyright (c) 1992-2004 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 5.2-CURRENT #42: Sun Aug 8 11:08:52 PDT 2004 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/FREEBEAST WARNING: DIAGNOSTIC option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc0822000. Preloaded elf module "/boot/kernel/snd_cmi.ko" at 0xc08221f4. Preloaded elf module "/boot/kernel/sound.ko" at 0xc08222a0. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc082234c. Calibrating clock(s) ... i8254 clock: 1193283 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 876397877 Hz CPU: Intel Pentium III (876.40-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x383fbff real memory = 536805376 (511 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c29000 - 0x000000001f6bffff, 514420736 bytes (125591 pages) avail memory = 515739648 (491 MB) Table 'FACP' at 0x1fff3040 Table 'APIC' at 0x1fff6280 MADT: Found table at 0x1fff6280 MP Configuration Table version 1.4 found at 0xc00f1400 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) ACPI APIC Table: APIC ID: physical 0, logical 0:0 APIC ID: physical 1, logical 0:1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00faf20 bios32: Entry = 0xfb390 (c00fb390) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb3c0 pnpbios: Found PnP BIOS data at 0xc00fbde0 pnpbios: Entry = f0000:be10 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: intr override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00040011 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff wlan: <802.11 Link Layer> null: random: io: mem: Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [GIANT-LOCKED] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000060 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=30911106) pcibios: BIOS version 2.10 Found $PIR table, 8 entries at 0xc00fde30 PCI-Only Interrupts: 5 10 11 12 Location Bus Device Pin Link IRQs slot 1 0 9 A 0x01 3 4 5 7 9 10 11 12 14 15 slot 1 0 9 B 0x02 3 4 5 7 9 10 11 12 14 15 slot 1 0 9 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 1 0 9 D 0x04 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 C 0x04 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 D 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 A 0x03 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 B 0x04 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 C 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 D 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 A 0x04 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 B 0x01 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 C 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 D 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 A 0x01 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 B 0x02 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 D 0x04 3 4 5 7 9 10 11 12 14 15 slot 6 0 14 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 6 0 14 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 6 0 14 C 0x04 3 4 5 7 9 10 11 12 14 15 slot 6 0 14 D 0x01 3 4 5 7 9 10 11 12 14 15 slot 7 0 15 A 0x03 3 4 5 7 9 10 11 12 14 15 slot 7 0 15 B 0x04 3 4 5 7 9 10 11 12 14 15 slot 7 0 15 C 0x01 3 4 5 7 9 10 11 12 14 15 slot 7 0 15 D 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 1 A 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 1 B 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 1 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 1 D 0x04 3 4 5 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 17 func 0 acpi0: Power Button (fixed) ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 pcib0: port 0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pcib0: could not get PCI interrupt routing table for \_SB_.PCI0 - AE_BAD_DATA ACPI PCI link initial configuration: ACPI PCI link before setting link priority: ACPI PCI link before fixup for boot-disabled links: ACPI PCI link after fixup for boot-disabled links: ACPI PCI link arbitrated configuration: pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base da000000, size 22, enabled found-> vendor=0x1106, dev=0x3091, revid=0x01 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0xa210, cachelnsz=0 (dwords) lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0xb091, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 0000c000, size 7, enabled map[14]: type 1, range 32, base da401000, size 7, enabled pcib0: matched entry for 0.9.INTA (src ) pcib0: device is hardwired to IRQ 16 found-> vendor=0x10ec, dev=0x8129, revid=0x00 bus=0, slot=9, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=16 map[10]: type 4, range 32, base 0100c400, size 7, enabled map[14]: type 1, range 32, base d9000000, size 7, enabled map[18]: type 1, range 32, base 01000000, size 24, enabled map[1c]: type 1, range 32, base 01000000, size 24, enabled map[20]: type 1, range 32, base 01000000, size 24, enabled map[24]: type 1, range 32, base 01000000, size 24, enabled pcib0: matched entry for 0.10.INTA (src ) pcib0: device is hardwired to IRQ 17 found-> vendor=0x1106, dev=0x3143, revid=0x06 bus=0, slot=10, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0300, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x76 (29500 ns), maxlat=0x99 (38250 ns) intpin=a, irq=17 map[10]: type 4, range 32, base 0000c800, size 8, enabled pcib0: matched entry for 0.14.INTA (src ) pcib0: device is hardwired to IRQ 17 found-> vendor=0x13f6, dev=0x0111, revid=0x10 bus=0, slot=14, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x18 (6000 ns) intpin=a, irq=17 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000cc00, size 3, enabled map[14]: type 4, range 32, base 0000d000, size 2, enabled map[18]: type 4, range 32, base 0000d400, size 3, enabled map[1c]: type 4, range 32, base 0000d800, size 2, enabled map[20]: type 4, range 32, base 0000dc00, size 4, enabled pcib0: matched entry for 0.15.INTA (src ) pcib0: device is hardwired to IRQ 18 found-> vendor=0x1095, dev=0x0649, revid=0x02 bus=0, slot=15, func=0 class=01-04-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=18 powerspec 2 supports D0 D1 D2 D3 current D0 found-> vendor=0x1106, dev=0x3074, revid=0x00 bus=0, slot=17, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0087, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000e000, size 4, enabled found-> vendor=0x1106, dev=0x0571, revid=0x06 bus=0, slot=17, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xd0000000-0xd7ffffff pcib1: prefetched decode 0xfff00000-0xfffff pci1: on pcib1 pci1: physical bus=1 map[10]: type 1, range 32, base d0000000, size 26, enabled pcib1: device (null) requested decoded memory range 0xd0000000-0xd3ffffff found-> vendor=0x5333, dev=0x8a13, revid=0x02 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x04 (1000 ns), maxlat=0xff (63750 ns) powerspec 1 supports D0 D3 current D0 pci1: at device 0.0 (no driver attached) rl0: Reserved 0x80 bytes for rid 0x10 type 4 at 0xc000 rl0: port 0xc000-0xc07f mem 0xda401000-0xda40107f irq 16 at device 9.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: bpf attached rl0: Ethernet address: 00:80:c6:f9:08:58 rl0: [GIANT-LOCKED] pci0: at device 10.0 (no driver attached) pcm0: port 0xc800-0xc8ff irq 17 at device 14.0 on pci0 pcm0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc800 pcm0: [MPSAFE] pcm0: sndbuf_setmap 1f45c000, 4000; 0xd544e000 -> 1f45c000 pcm0: sndbuf_setmap 1f458000, 4000; 0xd5452000 -> 1f458000 atapci0: port 0xdc00-0xdc0f,0xd800-0xd803,0xd400-0xd407,0xd000-0xd003,0xcc00-0xcc07 irq 18 at device 15.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xdc00 atapci0: [MPSAFE] atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xcc00 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xd000 ata2: reset tp1 mask=03 ostat0=7f ostat1=7f ata2-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata2-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata2-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata2-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata2-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata2-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata2-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata2-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata2-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata2: reset tp2 stat0=ff stat1=ff devices=0x0 ata2: at 0xcc00 on atapci0 ata2: [MPSAFE] atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xd400 atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0xd800 ata3: reset tp1 mask=03 ostat0=7f ostat1=7f ata3-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata3-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata3-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata3-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata3-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata3-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata3-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata3-master: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata3-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata3: reset tp2 stat0=ff stat1=ff devices=0x0 ata3: at 0xd400 on atapci0 ata3: [MPSAFE] isab0: at device 17.0 on pci0 isa0: on isab0 atapci1: port 0xe000-0xe00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 17.1 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xe000 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: at 0x1f0 irq 14 on atapci1 ata0: [MPSAFE] atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci1: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=01 ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x00 err=0x04 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: at 0x170 irq 15 on atapci1 ata1: [MPSAFE] fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: irq maps: 0x4041 0x4051 0x4041 0x4041 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1: irq maps: 0x4041 0x4049 0x4041 0x4041 sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A unknown: not probed (disabled) ppc0: using extended I/O port range ppc0: SPP ppc0 port 0xf78-0xf7b,0xb78-0xb7b,0x778-0x77b,0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sc: sc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it vga: vga0 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc8000-0xcffff,0xc0000-0xc7fff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x0> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0067 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 876397877 Hz quality -100 Timecounters tick every 10.000 msec lo0: bpf attached ata0-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata0-master: setting PIO4 on VIA 8233 chip ata0-master: setting UDMA100 on VIA 8233 chip ad0: ATA-5 disk at ata0-master ad0: 39203MB (80288480 sectors), 79651 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA100 GEOM: new disk ad0 ata1-master: pio=0x0c wdma=0x22 udma=0xffffffff cable=40pin ATAPI_RESET time = 60us [0] f:00 typ:165 s(CHS):0/1/1 e(CHS):260/254/63 s:63 l:4192902 [1] f:00 typ:165 s(CHS):261/0/1 e(CHS):521/254/63 s:4192965 l:4192965 [2] f:00 typ:165 s(CHS):522/0/1 e(CHS):782/254/63 s:8385930 l:4192965 [3] f:80 typ:165 s(CHS):783/0/1 e(CHS):1023/254/63 s:12578895 l:67697910 GEOM: Configure ad0s1, start 32256 length 2146765824 end 2146798079 GEOM: Configure ad0s2, start 2146798080 length 2146798080 end 4293596159 GEOM: Configure ad0s3, start 4293596160 length 2146798080 end 6440394239 GEOM: Configure ad0s4, start 6440394240 length 34661329920 end 41101724159 ata1-master: setting PIO4 on VIA 8233 chip GEOM: Configure ad0s1a, start 0 length 167772160 end 167772159 GEOM: Configure ad0s1c, start 0 length 2146765824 end 2146765823 GEOM: Configure ad0s1e, start 167772160 length 1978993664 end 2146765823 acd0: CDROM drive at ata1 as master acd0: read 5500KB/s (5500KB/s), 128KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream, packet acd0: Writes: acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked, lock protected acd0: Medium: no/blank disc SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00040011 LDR: 0x02000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00010400 TPR: 0x00000000 SVR: 0x000001ff ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 3 (ISA IRQ 3) to cluster 0 ioapic0: routing intpin 4 (ISA IRQ 4) to cluster 0 ioapic0: routing intpin 6 (ISA IRQ 6) to cluster 0 ioapic0: routing intpin 7 (ISA IRQ 7) to cluster 0 ioapic0: routing intpin 8 (ISA IRQ 8) to cluster 0 ioapic0: routing intpin 9 (ISA IRQ 9) to cluster 0 ioapic0: routing intpin 13 (ISA IRQ 13) to cluster 0 ioapic0: routing intpin 14 (ISA IRQ 14) to cluster 0 ioapic0: routing intpin 15 (ISA IRQ 15) to cluster 0 ioapic0: routing intpin 16 (PCI IRQ 16) to cluster 0 ioapic0: routing intpin 17 (PCI IRQ 17) to cluster 0 ioapic0: routing intpin 18 (PCI IRQ 18) to cluster 0 GEOM: Configure ad0s2a, start 0 length 167772160 end 167772159 GEOM: Configure ad0s2c, start 0 length 2146798080 end 2146798079 GEOM: Configure ad0s2e, start 167772160 length 1979025920 end 2146798079 GEOM: Configure ad0s3a, start 0 length 167772160 end 167772159 GEOM: Configure ad0s3c, start 0 length 2146798080 end 2146798079 GEOM: Configure ad0s3e, start 167772160 length 1979025920 end 2146798079 GEOM: Configure ad0s4a, start 0 length 167772160 end 167772159 GEOM: Configure ad0s4b, start 167772160 length 1073741824 end 1241513983 GEOM: Configure ad0s4c, start 0 length 34661329920 end 34661329919 GEOM: Configure ad0s4e, start 1241513984 length 1978662912 end 3220176895 GEOM: Configure ad0s4g, start 3220176896 length 2147483648 end 5367660543 GEOM: Configure ad0s4h, start 5367660544 length 29293669376 end 34661329919 Mounting root from ufs:/dev/ad0s4a start_init: trying /sbin/init Pre-seeding PRNG: kickstart. Loading configuration files. Entropy harvesting: interrupts ethernet point_to_point kickstart. swapon: adding /dev/ad0s4b as swap device Starting file system checks: /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1a: clean, 110384 free (1184 frags, 13650 blocks, 0.7% fragmentation) /dev/ad0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1e: clean, 1128055 free (29175 frags, 137360 blocks, 1.6% fragmentation) /dev/ad0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2a: clean, 111586 free (298 frags, 13911 blocks, 0.2% fragmentation) /dev/ad0s2e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2e: clean, 932696 free (7984 frags, 115589 blocks, 0.4% fragmentation) /dev/ad0s3a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s3a: clean, 42892 free (1268 frags, 5203 blocks, 0.8% fragmentation) /dev/ad0s3e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s3e: clean, 990991 free (14519 frags, 122059 blocks, 0.8% fragmentation) /dev/ad0s4a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s4a: clean, 52152 free (1984 frags, 6271 blocks, 1.2% fragmentation) /dev/ad0s4e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s4e: clean, 963687 free (22791 frags, 117612 blocks, 1.2% fragmentation) /dev/ad0s4h: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s4h: clean, 9506741 free (301141 frags, 1150700 blocks, 1.1% fragmentation) /dev/ad0s4g: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s4g: clean, 1528937 free (1129 frags, 190976 blocks, 0.1% fragmentation) Setting hostname: freebeast.catwhisker.org. rl0: flags=8843 mtu 1500 options=8 inet 172.16.8.10 netmask 0xffffff00 broadcast 172.16.8.255 inet6 fe80::280:c6ff:fef9:858%rl0 prefixlen 64 tentative scopeid 0x1 ether 00:80:c6:f9:08:58 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 add net default: gateway 172.16.8.1 Additional routing options:. Starting devd. Mounting NFS file systems:. Starting syslogd. Aug 8 11:36:17 freebeast syslogd: kernel boot file is /boot/kernel/kernel Setting date via ntp. Looking for host 172.16.8.12 and service ntp host found : pogo.catwhisker.org Looking for host 172.16.8.1 and service ntp host found : janus.catwhisker.orgE Looking for hoxst 172.16.8.12 apnd service ntp ehost found : pogno.catwhisker.orgs ive timeout(9) function: 0xc05df89c(0xc1a4b800) 0.006611734 s 8 Aug 11:36:22 ntpdate[294]: adjust time server 172.16.8.1 offset -0.252324 sec NFS access cache time=2 module_register: module g_md already exists! Module g_md failed to register: 17 can't re-use a leaf (mddebug)! ad0: WARNING - WRITE_DMA interrupt was seen but timeout fired LBA=18969503 Expensive timeout(9) function: 0xc043cda4(0xc1bafca8) 0.087799366 s rl0: watchdog timeout ad0: WARNING - WRITE_DMA interrupt was seen but timeout fired LBA=18969503 ad0: WARNING - WRITE_DMA interrupt was seen but taskqueue stalled LBA=18969503 ad0: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=18969519 ata0: reiniting channel .. ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ad0: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: resetting done .. ad0: FAILURE - ATA_IDENTIFY no interrupt ad0: FAILURE - ATA_IDENTIFY no interrupt ata0: device config done .. ad0: FAILURE - ATA_IDENTIFY no interrupt ad0: FAILURE - ATA_IDENTIFY no interrupt ad0: FAILURE - ATA_IDENTIFY no interrupt ad0: FAILURE - ATA_IDENTIFY no interrupt ad0: FAILURE - ATA_IDENTIFY no interrupt ad0: FAILURE - ATA_IDENTIFY no interrupt ad0: FAILURE - ATA_IDENTIFY no interrupt ad0: FAILURE - ATA_IDENTIFY no interrupt That last line repeated; I hit ^S to stop the spewing so I could capture the above & send it before the scroll buffer overflowed. What may I do to help debug this? Thanks, david -- David H. Wolfskill david@catwhisker.org I do not "unsubscribe" from email "services" to which I have not explicitly subscribed. Rather, I block spammers' access to SMTP servers I control, and encourage others who are in a position to do so to do likewise. From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 18:49:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 401BA16A4CF; Sun, 8 Aug 2004 18:49:45 +0000 (GMT) Received: from gravy.kishka.net (pcp04097789pcs.neave01.pa.comcast.net [68.81.192.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 945BB43D39; Sun, 8 Aug 2004 18:49:44 +0000 (GMT) (envelope-from bryan@kishka.net) Received: from gravy.kishka.net (gravy.kishka.net [192.168.1.2]) by gravy.kishka.net (8.13.1/8.13.1) with ESMTP id i78InhTP001186; Sun, 8 Aug 2004 14:49:43 -0400 (EDT) (envelope-from bryan@kishka.net) Date: Sun, 8 Aug 2004 14:49:43 -0400 (EDT) From: Bryan Liesner To: Robert Watson In-Reply-To: Message-ID: <20040808144250.S1181@gravy.kishka.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: kan@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: INCLUDE_CONFIG_FILE doesn't work anymore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 18:49:45 -0000 On Sun, 8 Aug 2004, Robert Watson wrote: > > On Sun, 8 Aug 2004, Conrad J. Sabatier wrote: > >> Including "options INCLUDE_CONFIG_FILE", while it doesn't break the >> kernel build, no longer actually seems to include the config file in the >> kernel. Using the magic "strings -n 3 ..." incantation returns only a >> couple of lines of gibberish now. > > It could be that gcc 3.4 is cleverly optimization out the unused symbols? > The below works for me. I've been using it for quite some time now, definitely before gcc 3.4. Something changed a while back and I just adapted. ========================================================================== #!/bin/sh # the perl re now includes a "not underscore" for the fourth character # since a couple of bogus strings match the old three underscore pattern. # You have to put the character back with a back reference, or lose the # first character of the kernel config string. strings -n3 /boot/kernel/kernel | perl -ne 'print if s/^___([^_])/$1/' ========================================================================= -Bryan From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 19:32:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 610A316A4CE for ; Sun, 8 Aug 2004 19:32:26 +0000 (GMT) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32ED943D1D for ; Sun, 8 Aug 2004 19:32:26 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) i78JWPmx001476 for ; Sun, 8 Aug 2004 12:32:26 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.12.11/8.12.11/Submit) id i78JWPKs001475 for current@freebsd.org; Sun, 8 Aug 2004 12:32:25 -0700 (PDT) (envelope-from david) Date: Sun, 8 Aug 2004 12:32:25 -0700 (PDT) From: David Wolfskill Message-Id: <200408081932.i78JWPKs001475@bunrab.catwhisker.org> To: current@freebsd.org In-Reply-To: <200408081849.i78InffL001243@bunrab.catwhisker.org> Subject: Re: ATA issues: ad0: FAILURE - ATA_IDENTIFY no interrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 19:32:26 -0000 OK; small update: my laptop, updated with equivalent sources (CVS repo is a local mirror of the other local mirror), gets as far as module_register: module g_md already exists! Module g_md failed to register: 17 can't re-use a leaf (mddebug)! [the above lines in bold] then stops dead. Only way to get it to respond is power-cycling. I am able to boot today's kernel in single-user mode, and mount the UFS file systems OK. And I'm able to unload today's kernel, load yesterday's, and boot (otherwise) "normally". Reviewong the log from "cvs update," I see that there were updates in the last 24 hrs. (i.e., between the updates) that have plausble relevance: U sys/dev/ata/ata-lowlevel.c U sys/dev/ata/atapi-cd.c U sys/dev/md/md.c U sys/geom/geom.h U sys/geom/geom_aes.c U sys/geom/geom_apple.c U sys/geom/geom_bsd.c U sys/geom/geom_ccd.c U sys/geom/geom_dev.c U sys/geom/geom_disk.c U sys/geom/geom_fox.c U sys/geom/geom_gpt.c U sys/geom/geom_mbr.c U sys/geom/geom_pc98.c U sys/geom/geom_subr.c U sys/geom/geom_sunlabel.c U sys/geom/geom_vol_ffs.c U sys/geom/bde/g_bde.c U sys/geom/concat/g_concat.c U sys/geom/gate/g_gate.c U sys/geom/label/g_label.c U sys/geom/mirror/g_mirror.c U sys/geom/nop/g_nop.c U sys/geom/stripe/g_stripe.c I note that my sys/dev/md/md.c is at rev. 1.127. Anything strike anyone as suspicious here? Thanks, david -- David H. Wolfskill david@catwhisker.org I do not "unsubscribe" from email "services" to which I have not explicitly subscribed. Rather, I block spammers' access to SMTP servers I control, and encourage others who are in a position to do so to do likewise. From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 21:05:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 087CF16A4CE for ; Sun, 8 Aug 2004 21:05:25 +0000 (GMT) Received: from av3-1-sn1.fre.skanova.net (av3-1-sn1.fre.skanova.net [81.228.11.109]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5C5243D2F for ; Sun, 8 Aug 2004 21:05:24 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av3-1-sn1.fre.skanova.net (Postfix, from userid 502) id 1910338002; Sun, 8 Aug 2004 23:05:24 +0200 (CEST) Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av3-1-sn1.fre.skanova.net (Postfix) with ESMTP id E752837E4D; Sun, 8 Aug 2004 23:05:23 +0200 (CEST) Received: from gadget (h130n1fls11o822.telia.com [213.64.66.130]) by smtp3-1-sn1.fre.skanova.net (Postfix) with ESMTP id C5F6237E4E; Sun, 8 Aug 2004 23:05:23 +0200 (CEST) From: "Daniel Eriksson" To: =?iso-8859-1?Q?'S=F8ren_Schmidt'?= Date: Sun, 8 Aug 2004 23:05:10 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal cc: freebsd-current@freebsd.org cc: 'Ville-Pertti Keinonen' Subject: RE: ATA driver races with interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 21:05:25 -0000 I wrote: > Unfortunately the machine disconnected one of the SATA discs=20 > earlier today. It did so out-of-the-blue, because there was > no activity at all on either of the two discs other than the > SMART monitor. >=20 > Aug 5 11:45:47 fortify kernel: ad20: WARNING - removed from=20 > configuration > Aug 5 11:45:47 fortify kernel: ata10-master: FAILURE -=20 > unknown CMD (0xb0) > timed out > Aug 5 11:45:47 fortify smartd[882]: Device: /dev/ad20, not=20 > capable of SMART > self-check [...] > I have switched back to the patch from Ville-Pertti that > serializes the controller for now, to see if that is more > stable. After 3+ days of uptime, including continuous SMART monitoring (which without patch triggers an immediate disconnect, and with S=F6rens patch triggered a disconnect after ~16 hours) and a fair amount of disc = activity on both channels it looks like maybe the serialization patch from Ville-Pertti is enough to make my SATA controller work properly. Of = course, it also slows things down, but right now that is better than the alternative. S=F6ren, if you have any other patches you would like me to test just = let me know. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 21:11:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B9E116A4CE; Sun, 8 Aug 2004 21:11:09 +0000 (GMT) Received: from rip.psg.com (splat.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4386643D58; Sun, 8 Aug 2004 21:11:09 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Btuwe-00081W-JR; Sun, 08 Aug 2004 21:11:08 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Btuwc-000Cx8-4w; Sun, 08 Aug 2004 11:11:06 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16662.38633.549566.111706@roam.psg.com> Date: Sun, 8 Aug 2004 11:11:05 -1000 To: "Brandon S. Allbery KF8NH" References: <16659.6061.369420.562800@roam.psg.com> <1091822755.23206.39.camel@tomcat.kitchenlab.org> <16659.58793.887526.631294@roam.psg.com> <1091824128.23206.52.camel@tomcat.kitchenlab.org> <1091933302.56646.1.camel@rushlight.kf8nh.com> cc: "Bruce A. Mah" cc: FreeBSD Current Subject: Re: usb palm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 21:11:09 -0000 > For what it's worth, my Tungsten T3 syncs fine over USB with -STABLE. using /dev/??? randy From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 21:13:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8160516A4CE for ; Sun, 8 Aug 2004 21:13:39 +0000 (GMT) Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id E468743D2D for ; Sun, 8 Aug 2004 21:13:38 +0000 (GMT) (envelope-from stijn@pcwin002.win.tue.nl) Received: from pcwin002.win.tue.nl (orb_rules@localhost [127.0.0.1]) by pcwin002.win.tue.nl (8.12.11/8.12.11) with ESMTP id i78LDbr6096856 for ; Sun, 8 Aug 2004 23:13:37 +0200 (CEST) (envelope-from stijn@pcwin002.win.tue.nl) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.12.11/8.12.11/Submit) id i78LDbBJ096855 for freebsd-current@freebsd.org; Sun, 8 Aug 2004 23:13:37 +0200 (CEST) (envelope-from stijn) Date: Sun, 8 Aug 2004 23:13:37 +0200 From: Stijn Hoop To: freebsd-current@freebsd.org Message-ID: <20040808211337.GB91609@pcwin002.win.tue.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lEGEL1/lMxI0MVQ2" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Bright-Idea: Let's abolish HTML mail! Subject: slice weirdness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 21:13:39 -0000 --lEGEL1/lMxI0MVQ2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, while trying to migrate my FreeBSD -CURRENT partition to another disk, I ke= ep running into a slice weirdness issue which makes the kernel unable to find it's root fs. It seems that something about the partition table is fishy su= ch that GEOM doesn't find both slices: Script started on Mon Aug 9 01:05:46 2004 > sudo fdisk ad1 ******* Working on device /dev/ad1 ******* parameters extracted from in-core disklabel are: cylinders=3D119150 heads=3D16 sectors/track=3D63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=3D119150 heads=3D16 sectors/track=3D63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 7 (0x07),(OS/2 HPFS, NTFS, QNX-2 (16 bit) or Advanced UNIX) start 63, size 59392242 (29000 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 59392305, size 60709635 (29643 Meg), flag 81 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: The data for partition 4 is: > sudo ls -l /dev/ad1* crw-r----- 1 root operator 4, 24 Aug 9 01:04 /dev/ad1 crw-r----- 1 root operator 4, 26 Aug 9 01:04 /dev/ad1s1 > cat /dev/ad1s2a cat: /dev/ad1s2a: No such file or directory > cat /dev/ad1s2a cat: /dev/ad1s2a: No such file or directory > exit Script done on Mon Aug 9 01:06:10 2004 So where's my /dev/ad1s2? The disk layout is ad1s1 is my Windows partition, ad1s2 my targetted new partition for the FreeBSD installation currently residing at ad0s1. I first created ad1s2 by hand using fdisk, but got the exact same result. = The script above shows the values that I obtained when /sbin/sysinstall partitioned the drive. After partitioning the device nodes reappear, and I = was able to install{kernel,world} with DESTDIR pointing to the newly mounted ad1s2, but the device nodes disappear after having booted the newly install= ed slice. That boot ends with the kernel unable to find the root file system ad1s2a (which is not strange given the above). Am I looking at some sort of geometry bug? I've tried setting the BIOS geometry settings to LBA (from Auto), that didn't make a difference. Setti= ng them to CHS produced an unbootable Windows so I reverted that. In any case I thought that those values were of historical interest only... Any clues? --Stijn PS: I thought that there was a sysctl that showed the GEOM topology in XML; however I was unable to find it in sysctl -a. Is it still around? --=20 The rain it raineth on the just And also on the unjust fella, But chiefly on the just, because The unjust steals the just's umbrella. --lEGEL1/lMxI0MVQ2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBFpeBY3r/tLQmfWcRAvfOAJ9RzofU4/nTefwYQHsqgKkezG3xnQCggtad BbxbNBDqDXKvMZgyTh+6WAQ= =EzjV -----END PGP SIGNATURE----- --lEGEL1/lMxI0MVQ2-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 21:34:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADBB916A4CE; Sun, 8 Aug 2004 21:34:57 +0000 (GMT) Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DEED43D45; Sun, 8 Aug 2004 21:34:57 +0000 (GMT) (envelope-from allbery@ece.cmu.edu) Received: from [10.9.204.1] (dsl093-061-215.pit1.dsl.speakeasy.net [66.93.61.215]) by bache.ece.cmu.edu (Postfix) with ESMTP id 1191E7F; Sun, 8 Aug 2004 17:34:55 -0400 (EDT) From: "Brandon S. Allbery KF8NH" To: Randy Bush In-Reply-To: <16662.38633.549566.111706@roam.psg.com> References: <16659.6061.369420.562800@roam.psg.com> <1091822755.23206.39.camel@tomcat.kitchenlab.org> <16659.58793.887526.631294@roam.psg.com> <1091824128.23206.52.camel@tomcat.kitchenlab.org> <1091933302.56646.1.camel@rushlight.kf8nh.com> <16662.38633.549566.111706@roam.psg.com> Content-Type: text/plain Message-Id: <1092000894.56646.3.camel@rushlight.kf8nh.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 08 Aug 2004 17:34:55 -0400 Content-Transfer-Encoding: 7bit cc: "Bruce A. Mah" cc: FreeBSD Current Subject: Re: usb palm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 21:34:57 -0000 On Sun, 2004-08-08 at 17:11, Randy Bush wrote: > > For what it's worth, my Tungsten T3 syncs fine over USB with -STABLE. > using /dev/??? /dev/ucom0 -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [WAY too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon univ. KF8NH From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 22:29:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6F0E16A4CE for ; Sun, 8 Aug 2004 22:29:53 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id A56F143D31 for ; Sun, 8 Aug 2004 22:29:53 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id D67F0FD02B for ; Sun, 8 Aug 2004 15:29:52 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00629-02 for ; Sun, 8 Aug 2004 15:29:51 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id A1D48FD012 for ; Sun, 8 Aug 2004 15:29:51 -0700 (PDT) From: Sean McNeil To: freebsd-current@freebsd.org Content-Type: text/plain Message-Id: <1092004191.24004.4.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 08 Aug 2004 15:29:51 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Subject: latest changes to ata driver increases stability X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 22:29:53 -0000 Just wanted to show my appreciation for the latest work checked in by Soren. I've been plagued with system hangs on my amd64 system for quite a while and the latest changes have (so far) eliminated them. The PREEMPTION caused many failures, but the last myserious cause would seem to have been ATA. As an added bonus, by DVD writer is working again. Many thanks, Sean From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 23:16:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3422F16A4CE for ; Sun, 8 Aug 2004 23:16:39 +0000 (GMT) Received: from istari.subastral.com (istari.subastral.com [207.99.117.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EBD543D31 for ; Sun, 8 Aug 2004 23:16:39 +0000 (GMT) (envelope-from tim@istari.subastral.com) Received: by istari.subastral.com (Postfix, from userid 1000) id AA344B180; Sun, 8 Aug 2004 19:16:36 -0400 (EDT) Date: Sun, 8 Aug 2004 19:16:36 -0400 From: Tim To: freebsd-current@freebsd.org Message-ID: <20040808231636.GA6403@istari.subastral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: Signal 11/Signal 10 Instability? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 23:16:39 -0000 Hi, i've recently switched to -CURRENT after being a long time Linux user. That probably isn't working in my favor. Today's most recently supped and builded current (as well as for the past few days) has yielded some interesting problems: pid 31350 (glxinfo), uid 1001: exited on signal 11 (core dumped) pid 32991 (uic), uid 0: exited on signal 11 (core dumped) pid 34460 (uic), uid 0: exited on signal 11 (core dumped) pid 34480 (firefox-bin), uid 1001: exited on signal 10 (core dumped) pid 38612 (firefox-bin), uid 1001: exited on signal 10 pid 38653 (firefox-bin), uid 1001: exited on signal 10 pid 38673 (glxgears), uid 1001: exited on signal 11 pid 38707 (firefox-bin), uid 1001: exited on signal 10 pid 38744 (firefox-bin), uid 1001: exited on signal 10 (core dumped) pid 66084 (uic), uid 0: exited on signal 11 (core dumped) pid 66170 (uic), uid 0: exited on signal 11 (core dumped) pid 66255 (uic), uid 0: exited on signal 11 (core dumped) Those are from dmesg. The last three most recent ones are from attempts to build djvulibre, which depends on Qt. The system hasn't crashed or anything, but i'm wondering if i'm missing something. I do in fact have a libmap.conf: libc_r.so.5 libpthread.so.1 libc_r.so libpthread.so Which I understand is the general cause of this type of behavior. I'm curious as to what I need to be doing to debug this problem and determine whether it is something in -CURRENT. Feel free to respond privately if this isn't appropriate for the current ml. Thanks, Tim From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 00:27:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9274C16A52C for ; Mon, 9 Aug 2004 00:27:55 +0000 (GMT) Received: from web20223.mail.yahoo.com (web20223.mail.yahoo.com [216.136.227.0]) by mx1.FreeBSD.org (Postfix) with SMTP id 700D043D41 for ; Mon, 9 Aug 2004 00:27:55 +0000 (GMT) (envelope-from tonymontanadea@yahoo.com) Message-ID: <20040809002755.6968.qmail@web20223.mail.yahoo.com> Received: from [68.36.189.179] by web20223.mail.yahoo.com via HTTP; Sun, 08 Aug 2004 17:27:55 PDT Date: Sun, 8 Aug 2004 17:27:55 -0700 (PDT) From: Tony Montana To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: No text after portupgrade in Gnome solution. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 00:27:56 -0000 Ok the problem has been solved over a few posts. After running the upgrade script i still had no text. Im not sure if my original upgrade on Gnome kept it broken, but running portupgrade -rf pango and portupgrade -f gnomecontrolcenter2 eventualy took care of the problem and text and icons are now fine. Thanks for the help. _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 01:15:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 559A116A4CE for ; Mon, 9 Aug 2004 01:15:10 +0000 (GMT) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id E818543D45 for ; Mon, 9 Aug 2004 01:15:09 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) i791F905000830 for ; Sun, 8 Aug 2004 18:15:09 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.12.11/8.12.11/Submit) id i791F9ca000829 for current@freebsd.org; Sun, 8 Aug 2004 18:15:09 -0700 (PDT) (envelope-from david) Date: Sun, 8 Aug 2004 18:15:09 -0700 (PDT) From: David Wolfskill Message-Id: <200408090115.i791F9ca000829@bunrab.catwhisker.org> To: current@freebsd.org In-Reply-To: <200408081849.i78InffL001243@bunrab.catwhisker.org> Subject: Re: ATA issues: ad0: FAILURE - ATA_IDENTIFY no interrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 01:15:10 -0000 OK; Pawel Jakub Dawidek noted in that src/sys/geom/geom_vol_ffs.c rev. 1.12 had "One too much" declaration of a struct member .version. I removed one of them, then re-built & -installed the kernel. The symptoms are now different: as did the laptop, the SMP box now "hangs" after whining: module_register: module g_md already exists! Module g_md failed to register: 17 can't re-use a leaf (mddebug)! but then, after a few seconds, I see: rl0: watchdog timeout Expensive timeout(9) function: 0xc0541530(0) 0.028075977 s and I'm able to use ^T on the (serial) console to get: load: 0.06 cmd: mdmfs 315 [spread] 0.00u 0.00s 0% 784k and if I hit ^C, I see: ^CScript /etc/rc.d/tmp interrupted And sending a break does bring me to the debugger, but doing this after interrupting /etc/rc.d/tmp doesn't seem all that useful. Here's what I get if I break-to-debugger during /etc/rc.d/tmp execution: module_register: module g_md already exists! Module g_md failed to register: 17 can't re-use a leaf (mddebug)! ~KDB: enter: Line break on console [thread 100013] Stopped at kdb_enter+0x2b: nop db> tr kdb_enter(c06a3d54) at kdb_enter+0x2b siointr1(c1a4f800) at siointr1+0xce siointr(c1a4f800) at siointr+0x5e intr_execute_handlers(c199b890,d41bcc98,4,d41bcce4,c0650923) at intr_execute_handlers+0x89 lapic_handle_intr(34) at lapic_handle_intr+0x2e Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc04a9734, esp = 0xd41bccdc, ebp = 0xd41bcce4 --- g_new_provider_event(c1bec600,0) at g_new_provider_event+0x28 one_event(d41bcd1c,c04a82cd,3c,28,c196c2c0) at one_event+0x193 g_run_events(3c,28,c196c2c0,c19af8ac,d41bcd34) at g_run_events+0x9 g_event_procbody(0,d41bcd48) at g_event_procbody+0x21 fork_exit(c04a82ac,0,d41bcd48) at fork_exit+0x79 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd41bcd7c, ebp = 0 --- db> show pcpu 0 cpuid = 0 curthread = 0xc196c2c0: pid 2 "g_event" curpcb = 0xd41bcda0 fpcurthread = none idlethread = 0xc19676e0: pid 12 "idle: cpu0" APIC ID = 0 currentldt = 0x28 db> show pcpu 1 cpuid = 1 curthread = 0xc1967580: pid 11 "idle: cpu1" curpcb = 0xd41a1da0 fpcurthread = none idlethread = 0xc1967580: pid 11 "idle: cpu1" APIC ID = 1 currentldt = 0x28 db> Not sure what else might be useful; open to suggestions or hints. Thanks, david -- David H. Wolfskill david@catwhisker.org I do not "unsubscribe" from email "services" to which I have not explicitly subscribed. Rather, I block spammers' access to SMTP servers I control, and encourage others who are in a position to do so to do likewise. From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 02:46:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D31A16A4CE for ; Mon, 9 Aug 2004 02:46:11 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4801E43D76 for ; Mon, 9 Aug 2004 02:46:10 +0000 (GMT) (envelope-from jon.drews@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so97716rnl for ; Sun, 08 Aug 2004 19:46:09 -0700 (PDT) Received: by 10.38.11.79 with SMTP id 79mr833140rnk; Sun, 08 Aug 2004 19:46:09 -0700 (PDT) Message-ID: <8cb27cbf040808194617634e07@mail.gmail.com> Date: Sun, 8 Aug 2004 21:46:09 -0500 From: Jon Drews To: freebsd-current@freebsd.org In-Reply-To: <20040805071236.GA595@loge.nixsys.be> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040805071236.GA595@loge.nixsys.be> Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 02:46:11 -0000 Hi Philip: I get freezes when I attempt to configure my synaptics touchpad, with sysinstall. Here are the details: 5.2-CURRENT FreeBSD 5.2-CURRENT #0: Sun Aug 8 19:40:37 CDT 2004 On: Powernotebooks C 3:16 dmesg output: psm0: model Synaptics Touchpad, device ID 0 What happens: 1) Run /usr/sbin/sysinstall 2) I set the mouse to auto and then try and test it. It freezes FreeBSD requiring a hard reboot. I will apply your patch tonight and test again. On Thu, 5 Aug 2004 09:12:36 +0200, Philip Paeps wrote: > Hi gang :-) > > Since the original synaptics support was added to psm, there have been some > reports of malfunctions and missing magic. I've tried to fix all that, but > it's still work in progress. From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 03:04:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 279FD16A4CE for ; Mon, 9 Aug 2004 03:04:12 +0000 (GMT) Received: from veldy.net (fuggle.veldy.net [209.98.200.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id C93E343D49 for ; Mon, 9 Aug 2004 03:04:11 +0000 (GMT) (envelope-from veldy@veldy.net) Received: from localhost (localhost.veldy.net [127.0.0.1]) by veldy.net (Postfix) with ESMTP id 703B46164 for ; Sun, 8 Aug 2004 22:04:10 -0500 (CDT) Received: from veldy.net ([127.0.0.1]) by localhost (fuggle.veldy.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09559-08 for ; Sun, 8 Aug 2004 22:04:07 -0500 (CDT) Received: from [127.0.0.1] (cascade.veldy.net [192.168.1.1]) by veldy.net (Postfix) with ESMTP id 6192360F5 for ; Sun, 8 Aug 2004 22:04:07 -0500 (CDT) Message-ID: <4116E99C.4080600@veldy.net> Date: Sun, 08 Aug 2004 22:03:56 -0500 From: "Thomas T. Veldhouse" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0C8C5456AD40AE21045A4AD1" X-Virus-Scanned: by amavisd-new at veldy.net Subject: Hang during USB device probes on CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 03:04:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0C8C5456AD40AE21045A4AD1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have a Dell Dimension 8250 with typical hardware (RAMBUS option). With recent CURRENT, it seems that whenever a USB device is probed, FreeBSD will just hang. It will not respond to a three-finger salute, it will not respond to the ATX power switch and it will only respond to a hard boot via the power switch. I am not all to familiar with debugging the kernel, although what I was able to read in the FreeBSD documentation only applied to kernel panics and not out-right freezes? Is there a procedure I can follow to aid with finding the cause of this? Thanks in advance, Tom Veldhouse --------------enig0C8C5456AD40AE21045A4AD1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBFumgARgTFXYf0wARAuXzAKCBu/J5vYUeYqoo74FJLohmW923wACguMFq B2ABemKJ//mRmg/New6vsio= =NogF -----END PGP SIGNATURE----- --------------enig0C8C5456AD40AE21045A4AD1-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 03:12:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DD4F16A4CF for ; Mon, 9 Aug 2004 03:12:07 +0000 (GMT) Received: from les.ath.cx (12.41.244.43.ap.yournet.ne.jp [43.244.41.12]) by mx1.FreeBSD.org (Postfix) with SMTP id 7415D43D4C for ; Mon, 9 Aug 2004 03:12:06 +0000 (GMT) (envelope-from qhwt+freebsd-current@les.ath.cx) Received: (qmail 41124 invoked by uid 1000); 9 Aug 2004 03:11:54 -0000 Date: Mon, 9 Aug 2004 12:11:54 +0900 From: YONETANI Tomokazu To: "Michael C. Shultz" Message-ID: <20040809031154.GC27705@les.ath.cx> References: <200408071057.06960.ringworm@inbox.lv> <200408080031.11326.ringworm@inbox.lv> <20040808112028.GB27705@les.ath.cx> <200408080939.46872.ringworm@inbox.lv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408080939.46872.ringworm@inbox.lv> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org cc: harti@freebsd.org Subject: Re: Need help: buildworld for CURRENT while under STABLE is not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 03:12:07 -0000 [Cc on author and the list] On Sun, Aug 08, 2004 at 09:39:46AM -0700, Michael C. Shultz wrote: > > > > Do you get the same error if you run `make buildworld' without > > > > -DDESTDIR=/ad1 ? > > I just cleaned everything up and tried, yes same exact failure. Its trying to > pull stdint.h from /usr/include, I tested it by linking /usr/include/stdint.h > to /ad1/usr/include/stdint.h and it got past that one point. Now, why the > heck is buildworld goint to userland for header files??????? Hmm, the problem is when building on STABLE, gensnmptree gets built in bootstrap-tools stage (because it's not in STABLE but is needed to build libbsnmp), where necessary header files are not yet populated under obj tree. Probably you need to change contrib/gensnmptree/gensnmptree.c so as not to use at least when OSRELDATE < 500000. From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 03:24:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A024A16A4CE for ; Mon, 9 Aug 2004 03:24:49 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52E5E43D2F for ; Mon, 9 Aug 2004 03:24:49 +0000 (GMT) (envelope-from jon.drews@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so98384rnl for ; Sun, 08 Aug 2004 20:24:48 -0700 (PDT) Received: by 10.38.11.79 with SMTP id 79mr840497rnk; Sun, 08 Aug 2004 20:24:48 -0700 (PDT) Message-ID: <8cb27cbf04080820246e0e0f49@mail.gmail.com> Date: Sun, 8 Aug 2004 22:24:48 -0500 From: Jon Drews To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: (da1:umass-sim1:1:0:0): CAM Status: SCSI Status Error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 03:24:49 -0000 uname: FreeBSD notebook.covad.net 5.2-CURRENT FreeBSD 5.2-CURRENT #0: Sun Aug 8 19:40:37 CDT 2004 Computer: Powernotebooks C:316 w/ 4 usb ports. Hi: Even though I have a Lexar jump drive attached (from dmesg): umass0: LEXAR MEDIA JUMPDRIVE, rev 1.10/0.01, addr 2 I get these strange warnings from dmesg: da1: Removable Direct Access SCSI-2 device da1: 1.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present (da1:umass-sim1:1:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim1:1:0:0): CAM Status: SCSI Status Error (da1:umass-sim1:1:0:0): SCSI Status: Check Condition (da1:umass-sim1:1:0:0): NOT READY asc:3a,0 (da1:umass-sim1:1:0:0): Medium not present (da1:umass-sim1:1:0:0): Unretryable error Opened disk da1 -> 6 (da1:umass-sim1:1:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim1:1:0:0): CAM Status: SCSI Status Error (da1:umass-sim1:1:0:0): SCSI Status: Check Condition (da1:umass-sim1:1:0:0): NOT READY asc:3a,0 (da1:umass-sim1:1:0:0): Medium not present (da1:umass-sim1:1:0:0): Unretryable error Opened disk da1 -> 6 (da1:umass-sim1:1:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim1:1:0:0): CAM Status: SCSI Status Error (da1:umass-sim1:1:0:0): SCSI Status: Check Condition (da1:umass-sim1:1:0:0): NOT READY asc:3a,0 (da1:umass-sim1:1:0:0): Medium not present (da1:umass-sim1:1:0:0): Unretryable error I am using the defaults/loader.conf settings. From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 04:41:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B40FD16A4CE for ; Mon, 9 Aug 2004 04:41:30 +0000 (GMT) Received: from mta6.srv.hcvlny.cv.net (mta6.srv.hcvlny.cv.net [167.206.5.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77EA543D39 for ; Mon, 9 Aug 2004 04:41:30 +0000 (GMT) (envelope-from timothyk@devel.njit.edu) Received: from www.smsdesign.org (ool-4353d5dd.dyn.optonline.net [67.83.213.221]) by mta6.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I25003YFX1D6F@mta6.srv.hcvlny.cv.net> for freebsd-current@freebsd.org; Mon, 09 Aug 2004 00:41:37 -0400 (EDT) Date: Mon, 09 Aug 2004 00:41:28 -0400 From: T Kellers In-reply-to: <4116BD78.1000909@webvolution.net> To: Joao Pedras Message-id: <200408090041.28798.timothyk@devel.njit.edu> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.6.2 References: <200408072138.i77LcPxJ070334@bunrab.catwhisker.org> <4116BD78.1000909@webvolution.net> cc: freebsd-current@freebsd.org Subject: Re: x server breakage? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 04:41:30 -0000 On Sunday 08 August 2004 07:55 pm, Joao Pedras wrote: > Tim, > > did you figure this one out? After I added 'io' it started complaining > about /dev/vga not > being there. > > The xserver log error is 'xf86MapVidMem: Could not mmap /dev/vga > (Invalid argument) > > I do have 'device vga' in the kernel. > > Thanks! I added the following back into my kernel config: +# Pseudo devices. +device mem # Memory and kernel memory devices +device io # I/O device I already had this in the broken (now working with the 2 above lines added-in) kernel: device vga # VGA video card driver Everything is working, now. (Though mozilla still sometimes hogs the CPU and locks up X): FreeBSD www.smsdesign.org 5.2-CURRENT FreeBSD 5.2-CURRENT #4: Sat Aug 7 18:41:05 EDT 2004 timothyk@smsdesign.org:/usr/obj/usr/src/sys/BRASIDAS i386 Tim From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 05:55:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D42AD16A4CE for ; Mon, 9 Aug 2004 05:55:14 +0000 (GMT) Received: from dedi.fuckner.net (fuckner.net [81.169.152.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 758BB43D2D for ; Mon, 9 Aug 2004 05:55:14 +0000 (GMT) (envelope-from hscholz@raisdorf.net) Received: from localhost (localhost [127.0.0.1]) by dedi.fuckner.net (Postfix) with ESMTP id 08E87C204; Mon, 9 Aug 2004 07:55:13 +0200 (CEST) Received: from dedi.fuckner.net ([127.0.0.1]) by localhost (dedi.fuckner.net [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 39721-10; Mon, 9 Aug 2004 07:55:11 +0200 (CEST) Received: from [192.168.1.101] (pD958C737.dip.t-dialin.net [217.88.199.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dedi.fuckner.net (Postfix) with ESMTP id D20E9C1EA; Mon, 9 Aug 2004 07:55:10 +0200 (CEST) Message-ID: <411711BD.4040507@raisdorf.net> Date: Mon, 09 Aug 2004 07:55:09 +0200 From: Hendrik Scholz User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040806) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Drews References: <8cb27cbf04080820246e0e0f49@mail.gmail.com> In-Reply-To: <8cb27cbf04080820246e0e0f49@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at fuckner.net cc: freebsd-current@freebsd.org Subject: Re: (da1:umass-sim1:1:0:0): CAM Status: SCSI Status Error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 05:55:14 -0000 Hi! Jon Drews wrote: > I get these strange warnings from dmesg: > > da1: Removable Direct Access SCSI-2 device > da1: 1.000MB/s transfers > da1: Attempt to query device size failed: NOT READY, Medium not present > (da1:umass-sim1:1:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Do you have a memory card in the reader? Connecting a reader w/o a card resulted in the same error but since it's USB you have to connect the reader with a card already plugged in. Hendrik -- Hendrik Scholz - - http://www.wormulon.net/ drag me, drop me - treat me like an object From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 07:47:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB72C16A4CE for ; Mon, 9 Aug 2004 07:47:33 +0000 (GMT) Received: from afields.ca (afields.ca [216.194.67.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D6FC43D4C for ; Mon, 9 Aug 2004 07:47:33 +0000 (GMT) (envelope-from afields@afields.ca) Received: from afields.ca (localhost.afields.ca [127.0.0.1]) by afields.ca (8.12.11/8.12.11) with ESMTP id i797lWKu007170; Mon, 9 Aug 2004 03:47:32 -0400 (EDT) (envelope-from afields@afields.ca) Received: (from afields@localhost) by afields.ca (8.12.11/8.12.11/Submit) id i797lWIE007169; Mon, 9 Aug 2004 03:47:32 -0400 (EDT) (envelope-from afields) Date: Mon, 9 Aug 2004 03:47:32 -0400 From: Allan Fields To: Stijn Hoop Message-ID: <20040809074732.GA3155@afields.ca> References: <20040808211337.GB91609@pcwin002.win.tue.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <20040808211337.GB91609@pcwin002.win.tue.nl> User-Agent: Mutt/1.4i cc: freebsd-current@freebsd.org Subject: Re: slice weirdness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 07:47:33 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 08, 2004 at 11:13:37PM +0200, Stijn Hoop wrote: > Hi, >=20 > while trying to migrate my FreeBSD -CURRENT partition to another disk, I = keep > running into a slice weirdness issue which makes the kernel unable to find > it's root fs. It seems that something about the partition table is fishy = such > that GEOM doesn't find both slices: Which kernel: the one from your existing install, the install kernel (booting off CD), a new kernel? I've had some partition/slice issues in the past w/ install CD and missing device entries with non-standard slice (anything except s1 entry), can't recall details, but running sysinstall w/ newfs flag to N creates appropriate entries. Else I've found suitable device entries elsewhere or make them temporarily with mknod. Maybe this was only an issue in -stable. > So where's my /dev/ad1s2? >=20 > The disk layout is ad1s1 is my Windows partition, ad1s2 my targeted new > partition for the FreeBSD installation currently residing at ad0s1. Out of curiosity, did you disklabel the second slice anew or just copy/dd existing slice over to new drive? > I first created ad1s2 by hand using fdisk, but got the exact same result.= The But, does a newly created slice/disklabel/root filesystem have the same pro= blem? i.e. if you were to go the sysinstall route and do a fresh install on ad1, exhibit same behaviour? > script above shows the values that I obtained when /sbin/sysinstall > partitioned the drive. After partitioning the device nodes reappear, and = I was > able to install{kernel,world} with DESTDIR pointing to the newly mounted > ad1s2, but the device nodes disappear after having booted the newly insta= lled > slice. That boot ends with the kernel unable to find the root file system > ad1s2a (which is not strange given the above). >=20 > Am I looking at some sort of geometry bug? I've tried setting the BIOS > geometry settings to LBA (from Auto), that didn't make a difference. Set= ting > them to CHS produced an unbootable Windows so I reverted that. In any case > I thought that those values were of historical interest only... >=20 > Any clues? >=20 > --Stijn >=20 > PS: I thought that there was a sysctl that showed the GEOM topology in XM= L; > however I was unable to find it in sysctl -a. Is it still around? I believe so, phk recently (few months back) mentioned it's staying in. > --=20 > The rain it raineth on the just > And also on the unjust fella, > But chiefly on the just, because > The unjust steals the just's umbrella. --=20 Allan Fields, AFRSL - http://afields.ca 2D4F 6806 D307 0889 6125 C31D F745 0D72 39B4 5541 --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQFBFywT90UNcjm0VUERArQFAJ98ddFS6x5BPBFU+FOcwkPEiol18ACgjYii LOI8665mDR1xAK9UCi4YdEY= =pWDF -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 07:52:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3661416A4CE for ; Mon, 9 Aug 2004 07:52:32 +0000 (GMT) Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id B042143D1D for ; Mon, 9 Aug 2004 07:52:31 +0000 (GMT) (envelope-from stijn@pcwin002.win.tue.nl) Received: from pcwin002.win.tue.nl (orb_rules@localhost [127.0.0.1]) by pcwin002.win.tue.nl (8.12.11/8.12.11) with ESMTP id i797qSjL002627; Mon, 9 Aug 2004 09:52:29 +0200 (CEST) (envelope-from stijn@pcwin002.win.tue.nl) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.12.11/8.12.11/Submit) id i797qSRu002626; Mon, 9 Aug 2004 09:52:28 +0200 (CEST) (envelope-from stijn) Date: Mon, 9 Aug 2004 09:52:28 +0200 From: Stijn Hoop To: Allan Fields Message-ID: <20040809075228.GC91609@pcwin002.win.tue.nl> References: <20040808211337.GB91609@pcwin002.win.tue.nl> <20040809074732.GA3155@afields.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9Ek0hoCL9XbhcSqy" Content-Disposition: inline In-Reply-To: <20040809074732.GA3155@afields.ca> User-Agent: Mutt/1.4.2.1i X-Bright-Idea: Let's abolish HTML mail! cc: freebsd-current@freebsd.org Subject: Re: slice weirdness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 07:52:32 -0000 --9Ek0hoCL9XbhcSqy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 09, 2004 at 03:47:32AM -0400, Allan Fields wrote: > On Sun, Aug 08, 2004 at 11:13:37PM +0200, Stijn Hoop wrote: > > while trying to migrate my FreeBSD -CURRENT partition to another disk, > > I keep running into a slice weirdness issue which makes the kernel unab= le > > to find it's root fs. It seems that something about the partition table > > is fishy such that GEOM doesn't find both slices: >=20 > Which kernel: the one from your existing install, the install kernel > (booting off CD), a new kernel? The same kernel that boots my current installation; I just did a new 'make install{world,kernel} DESTDIR=3D/mnt/NEW' where /mnt/NEW is the mount= ed /dev/ad2s1a (ie the new slice after just having it partitioned). > I've had some partition/slice issues in the past w/ install CD and > missing device entries with non-standard slice (anything except s1 > entry), can't recall details, but running sysinstall w/ newfs > flag to N creates appropriate entries. Else I've found suitable > device entries elsewhere or make them temporarily with mknod. > Maybe this was only an issue in -stable. I don't know, but obviously I can't mknod / do something about it when the kernel has just been booted. > > So where's my /dev/ad1s2? > >=20 > > The disk layout is ad1s1 is my Windows partition, ad1s2 my targeted new > > partition for the FreeBSD installation currently residing at ad0s1. >=20 > Out of curiosity, did you disklabel the second slice anew or just > copy/dd existing slice over to new drive? I disklabeled anew. > > I first created ad1s2 by hand using fdisk, but got the exact same resul= t. > > But, does a newly created slice/disklabel/root filesystem have the same > problem? > i.e. if you were to go the sysinstall route and do a fresh install > on ad1, exhibit same behaviour? Yes, it does. I didn't use sysinstall but 'make installworld' but either do= ing fdisk / disklabel by hand or by doing it using sysinstall, both methods stop at the same 'cannot find root' prompt when booting off the slice. A reboot into the old install later and my device entry is gone again. > > script above shows the values that I obtained when /sbin/sysinstall > > partitioned the drive. After partitioning the device nodes reappear, and > > I was able to install{kernel,world} with DESTDIR pointing to the newly > > mounted ad1s2, but the device nodes disappear after having booted the > > newly installed slice. That boot ends with the kernel unable to find the > > root file systemad1s2a (which is not strange given the above). > >=20 > > Am I looking at some sort of geometry bug? I've tried setting the BIOS > > geometry settings to LBA (from Auto), that didn't make a difference. > > Setting them to CHS produced an unbootable Windows so I reverted that. > > In any case I thought that those values were of historical interest onl= y... > >=20 > > Any clues? > >=20 > > --Stijn > >=20 > > PS: I thought that there was a sysctl that showed the GEOM topology in = XML; > > however I was unable to find it in sysctl -a. Is it still around? >=20 > I believe so, phk recently (few months back) mentioned it's staying in. Too bad I couldn't find it... Thanks for your reply, --Stijn --=20 Fairy tales do not tell children that dragons exist. Children already know dragons exist. Fairy tales tell children the dragons can be killed. -- G.K. Chesterton --9Ek0hoCL9XbhcSqy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBFy08Y3r/tLQmfWcRAsPYAKCmvDsmbNKYjAWgH7Q4/bE/AyIQvACfYBTc haItERFDyLJSrN7OxBKhBr0= =rXLH -----END PGP SIGNATURE----- --9Ek0hoCL9XbhcSqy-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 08:19:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A97516A4D0 for ; Mon, 9 Aug 2004 08:19:02 +0000 (GMT) Received: from afields.ca (afields.ca [216.194.67.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13E2C43D41 for ; Mon, 9 Aug 2004 08:19:02 +0000 (GMT) (envelope-from afields@afields.ca) Received: from afields.ca (localhost.afields.ca [127.0.0.1]) by afields.ca (8.12.11/8.12.11) with ESMTP id i798J1J0007304; Mon, 9 Aug 2004 04:19:01 -0400 (EDT) (envelope-from afields@afields.ca) Received: (from afields@localhost) by afields.ca (8.12.11/8.12.11/Submit) id i798J1Vb007303; Mon, 9 Aug 2004 04:19:01 -0400 (EDT) (envelope-from afields) Date: Mon, 9 Aug 2004 04:19:01 -0400 From: Allan Fields To: Stijn Hoop Message-ID: <20040809081901.GB3155@afields.ca> References: <20040808211337.GB91609@pcwin002.win.tue.nl> <20040809074732.GA3155@afields.ca> <20040809075228.GC91609@pcwin002.win.tue.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20040809075228.GC91609@pcwin002.win.tue.nl> User-Agent: Mutt/1.4i cc: Allan Fields cc: freebsd-current@freebsd.org Subject: Re: slice weirdness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 08:19:02 -0000 On Mon, Aug 09, 2004 at 09:52:28AM +0200, Stijn Hoop wrote: > On Mon, Aug 09, 2004 at 03:47:32AM -0400, Allan Fields wrote: > > On Sun, Aug 08, 2004 at 11:13:37PM +0200, Stijn Hoop wrote: > > I've had some partition/slice issues in the past w/ install CD and > > missing device entries with non-standard slice (anything except s1 > > entry), can't recall details, but running sysinstall w/ newfs > > flag to N creates appropriate entries. Else I've found suitable > > device entries elsewhere or make them temporarily with mknod. > > Maybe this was only an issue in -stable. >=20 > I don't know, but obviously I can't mknod / do something about it when > the kernel has just been booted. True. ;) Something to try: once in a kernel, try either not using devfs or manually creating device nodes and see if you can make it work with ad1s2. > > i.e. if you were to go the sysinstall route and do a fresh install > > on ad1, exhibit same behaviour? >=20 > Yes, it does. I didn't use sysinstall but 'make installworld' but either = doing > fdisk / disklabel by hand or by doing it using sysinstall, both methods s= top > at the same 'cannot find root' prompt when booting off the slice. A reboot > into the old install later and my device entry is gone again. You mean you can't see the new ad1s2 slice from a kernel booted off ad0 either? Which would be consistent to the problem. > > > PS: I thought that there was a sysctl that showed the GEOM topology i= n XML; > > > however I was unable to find it in sysctl -a. Is it still around? > >=20 > > I believe so, phk recently (few months back) mentioned it's staying in. >=20 > Too bad I couldn't find it... Try: sysctl -b kern.geom.confxml > Thanks for your reply, >=20 > --Stijn >=20 > --=20 > Fairy tales do not tell children that dragons exist. Children already > know dragons exist. Fairy tales tell children the dragons can be > killed. > -- G.K. Chesterton --=20 Allan Fields, AFRSL - http://afields.ca 2D4F 6806 D307 0889 6125 C31D F745 0D72 39B4 5541 From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 08:20:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AEAF16A4CF for ; Mon, 9 Aug 2004 08:20:37 +0000 (GMT) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33AB243D2F for ; Mon, 9 Aug 2004 08:20:33 +0000 (GMT) (envelope-from cpghost@cordula.ws) Received: from bsdbox.farid-hajji.net (bsdbox [192.168.254.3]) by fw.farid-hajji.net (Postfix) with ESMTP id C41E24AF2E; Mon, 9 Aug 2004 10:21:06 +0200 (CEST) Date: Mon, 9 Aug 2004 10:25:20 +0200 From: cpghost@cordula.ws To: Tim Message-ID: <20040809082520.GA85910@bsdbox.farid-hajji.net> References: <20040808231636.GA6403@istari.subastral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040808231636.GA6403@istari.subastral.com> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: Signal 11/Signal 10 Instability? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 08:20:37 -0000 On Sun, Aug 08, 2004 at 07:16:36PM -0400, Tim wrote: > pid 31350 (glxinfo), uid 1001: exited on signal 11 (core dumped) > pid 32991 (uic), uid 0: exited on signal 11 (core dumped) > pid 34460 (uic), uid 0: exited on signal 11 (core dumped) > pid 34480 (firefox-bin), uid 1001: exited on signal 10 (core dumped) > pid 38612 (firefox-bin), uid 1001: exited on signal 10 > pid 38653 (firefox-bin), uid 1001: exited on signal 10 > pid 38673 (glxgears), uid 1001: exited on signal 11 > pid 38707 (firefox-bin), uid 1001: exited on signal 10 > pid 38744 (firefox-bin), uid 1001: exited on signal 10 (core dumped) > pid 66084 (uic), uid 0: exited on signal 11 (core dumped) > pid 66170 (uic), uid 0: exited on signal 11 (core dumped) > pid 66255 (uic), uid 0: exited on signal 11 (core dumped) > > Those are from dmesg. The last three most recent ones are from attempts > to build djvulibre, which depends on Qt. The system hasn't crashed or > anything, but i'm wondering if i'm missing something. This could have been caused by the recent gcc 3.4.2 upgrade. gcc broke ABI compat once again, and you need to recompile every C++ app. See /usr/src/UPDATING: 20040728: System compiler has been upgraded to GCC 3.4.2-pre. As with any major compiler upgrade, there are several issues to be aware of. GCC 3.4.x has broken C++ ABI compatibility with previous releases yet again and users will have to rebuild all their C++ programs with the new compiler. A new unit-at-a-time optimization mode, which is default in this compiler release, is more aggressive in removing unused static symbols. This is the likely cause of 'make buildworld' breakages with non-default CFLAGS where optimization level is set to -O2 or higher. G'luck! -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 08:21:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9CDA16A4CE for ; Mon, 9 Aug 2004 08:21:40 +0000 (GMT) Received: from n066.sc1.cp.net (h13.rdg.cp.net [209.228.29.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B1D843D49 for ; Mon, 9 Aug 2004 08:21:40 +0000 (GMT) (envelope-from bruce@cran.org.uk) Received: from [82.3.67.253] (82.3.67.253) by n066.sc1.cp.net (7.0.030.2) id 410F9A18000E3EB4 for current@freebsd.org; Mon, 9 Aug 2004 08:21:39 +0000 Mime-Version: 1.0 (Apple Message framework v618) To: current@freebsd.org Message-Id: <21C8C699-E9DD-11D8-944B-000D93ACEE20@cran.org.uk> Content-Type: multipart/mixed; boundary=Apple-Mail-13--84136162 From: Bruce Cran Date: Mon, 9 Aug 2004 09:21:37 +0100 X-Mailer: Apple Mail (2.618) Subject: PCMCIA bridge card won't initialise: 'bad Vcc request', 'cbb_power: 0V' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 08:21:41 -0000 --Apple-Mail-13--84136162 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I've been attempting to turn an old K6-200 machine into a wireless ADSL router. I started out by installing FreeBSD 5.2.1, but decided to upgrade to -CURRENT after a few panics. Under 5.2.1 my wireless card, which is installed via a PCI-PCMCIA bridge, worked perfectly. Now in -CURRENT, though, the bridge card fails to initialise: I keep getting: cbb0: bad Vcc request. ctrl=0xf000ef08, status=0xf000e2c3 cbb_power: 0V ACPI isn't loaded. This problem looks similar to bug #66290, but I get the message even if no card is plugged in. Is there anything I can do to help diagnose where the bug is? -- Bruce Cran --Apple-Mail-13--84136162 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="dmesg.log" Content-Disposition: attachment; filename=dmesg.log Copyright (c) 1992-2004 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 5.2-CURRENT #0: Mon Aug 9 08:20:46 BST 2004 brucec@neutron.cran:/usr/obj/usr/src/sys/MYKERNEL Preloaded elf kernel "/boot/kernel/kernel" at 0xc06ce000. Calibrating clock(s) ... i8254 clock: 1193077 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 200455528 Hz CPU: AMD-K6tm w/ multimedia extensions (200.46-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x561 Stepping = 1 Features=0x8001bf AMD Features=0x400<> Data TLB: 128 entries, 2-way associative Instruction TLB: 64 entries, 1-way associative L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative Write Allocate Enable Limit: 32M bytes Write Allocate 15-16M bytes: Enable Hardware Write Allocate Control: Disable real memory = 33554432 (32 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009ffff, 651264 bytes (159 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000826000 - 0x0000000001f3ffff, 24223744 bytes (5914 pages) avail memory = 27561984 (26 MB) bios32: Found BIOS32 Service Directory header at 0xc00fb190 bios32: Entry = 0xfb610 (c00fb610) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb640 pnpbios: Found PnP BIOS data at 0xc00fc1b0 pnpbios: Entry = f0000:c1d8 Rev = 1.0 Other BIOS signatures found: wlan: <802.11 Link Layer> null: mem: random: io: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pci_open(1): mode 1 addr port (0x0cf8) is 0x8000005c pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71008086) pcibios: BIOS version 2.10 Found $PIR table, 6 entries at 0xc00fde00 PCI-Only Interrupts: 5 10 11 12 Location Bus Device Pin Link IRQs slot 1 0 9 A 0x60 3 4 5 7 9 10 11 12 14 15 slot 1 0 9 B 0x61 3 4 5 7 9 10 11 12 14 15 slot 1 0 9 C 0x62 3 4 5 7 9 10 11 12 14 15 slot 1 0 9 D 0x63 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 A 0x61 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 B 0x62 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 C 0x63 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 D 0x60 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 A 0x62 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 B 0x63 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 C 0x60 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 D 0x61 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 A 0x63 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 B 0x60 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 C 0x61 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 D 0x62 3 4 5 7 9 10 11 12 14 15 embedded 0 7 D 0x63 3 4 5 7 9 10 11 12 14 15 pcib0: at pcibus 0 on motherboard pir0: on motherboard $PIR: Links after initial probe: Link IRQ Rtd Ref IRQs 0x60 255 N 4 3 4 5 7 9 10 11 12 14 15 0x61 255 N 4 3 4 5 7 9 10 11 12 14 15 0x62 255 N 4 3 4 5 7 9 10 11 12 14 15 0x63 255 N 5 3 4 5 7 9 10 11 12 14 15 $PIR: Found matching pin for 0.9.INTA at func 0: 10 $PIR: Found matching pin for 0.10.INTA at func 0: 12 $PIR: Found matching pin for 0.11.INTA at func 0: 5 $PIR: Found matching pin for 0.12.INTA at func 0: 11 $PIR: Found matching pin for 0.12.INTB at func 1: 10 $PIR: Found matching pin for 0.12.INTC at func 2: 12 $PIR: Found matching pin for 0.7.INTD at func 2: 11 $PIR: Links after initial IRQ discovery: Link IRQ Rtd Ref IRQs 0x60 10 Y 4 3 4 5 7 9 10 11 12 14 15 0x61 12 Y 4 3 4 5 7 9 10 11 12 14 15 0x62 5 Y 4 3 4 5 7 9 10 11 12 14 15 0x63 11 Y 5 3 4 5 7 9 10 11 12 14 15 $PIR: IRQs used by BIOS: 5 10 11 12 $PIR: Interrupt Weights: [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ] [ 0 0 0 0 0 4 0 0 0 0 4 5 4 0 0 0 ] pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x7100, revid=0x01 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2200, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7110, revid=0x01 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000f000, size 4, enabled found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=7, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 00006400, size 5, enabled $PIR: 0:7 INTD routed to irq 11 found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[90]: type 4, range 32, base 00005f00, size 4, enabled found-> vendor=0x8086, dev=0x7113, revid=0x01 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 1, range 32, base 00000000, size 12, memory disabled $PIR: 0:9 INTA routed to irq 10 found-> vendor=0x1180, dev=0x0475, revid=0x80 bus=0, slot=9, func=0 class=06-07-00, hdrtype=0x02, mfdev=0 cmdreg=0x0000, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x07 (1750 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base e0000000, size 26, enabled $PIR: 0:10 INTA routed to irq 12 found-> vendor=0x5333, dev=0x8901, revid=0x14 bus=0, slot=10, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 map[10]: type 4, range 32, base 00006800, size 8, enabled map[14]: type 1, range 32, base e4000000, size 8, enabled $PIR: 0:11 INTA routed to irq 5 found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=0, slot=11, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base e4001000, size 12, enabled $PIR: 0:12 INTA routed to irq 11 found-> vendor=0x1033, dev=0x0035, revid=0x41 bus=0, slot=12, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x01 (250 ns), maxlat=0x2a (10500 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base e4002000, size 12, enabled $PIR: 0:12 INTB routed to irq 10 found-> vendor=0x1033, dev=0x0035, revid=0x41 bus=0, slot=12, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x01 (250 ns), maxlat=0x2a (10500 ns) intpin=b, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base e4003000, size 8, enabled $PIR: 0:12 INTC routed to irq 12 found-> vendor=0x1033, dev=0x00e0, revid=0x02 bus=0, slot=12, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x10 (4000 ns), maxlat=0x22 (8500 ns) intpin=c, irq=12 powerspec 2 supports D0 D1 D2 D3 current D0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf000 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0xd0 err=0xd0 lsb=0xd0 msb=0xd0 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=51 ostat1=00 ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x00 err=0x00 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pci0: at device 7.2 (no driver attached) pci0: at device 7.3 (no driver attached) cbb0: irq 10 at device 9.0 on pci0 cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [MPSAFE] cbb0: bad Vcc request. ctrl=0xf000ef08, status=0xf000e2c3 cbb_power: 0V cbb0: PCI Configuration space: 0x00: 0x04751180 0x02100007 0x06070080 0x00024000 0x10: 0x00000000 0x020000dc 0x20030200 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x0700010a 0x40: 0x030a1154 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00000001 0x00000000 0x04630463 0x00000000 0x90: 0x00000000 0x00000000 0x00000000 0x00000000 0xa0: 0x00000000 0x00000000 0x00000000 0x00000000 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x030a1154 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0xfe0a0001 0xe0: 0x24c04000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 pci0: at device 10.0 (no driver attached) rl0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x6800 rl0: port 0x6800-0x68ff mem 0xe4000000-0xe40000ff irq 5 at device 11.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: bpf attached rl0: Ethernet address: 00:10:a7:17:ab:6e rl0: [GIANT-LOCKED] ohci0: mem 0xe4001000-0xe4001fff irq 11 at device 12.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xe4001000 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0 usb0: on ohci0 usb0: USB revision 1.0 uhub0: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xe4002000-0xe4002fff irq 10 at device 12.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xe4002000 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0 usb1: on ohci1 usb1: USB revision 1.0 uhub1: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at device 12.2 (no driver attached) cpu0 on motherboard pnpbios: 11 devices, largest 102 bytes PNP0200: adding dma mask 0x10 PNP0200: adding io range 0-0xf, size=0x10, align=0 PNP0200: adding io range 0x81-0x83, size=0x3, align=0 PNP0200: adding io range 0x87-0x87, size=0x1, align=0 PNP0200: adding io range 0x89-0x8b, size=0x3, align=0 PNP0200: adding io range 0x8f-0x91, size=0x3, align=0 PNP0200: adding io range 0xc0-0xdf, size=0x20, align=0 pnpbios: handle 1 device ID PNP0200 (0002d041) PNP0100: adding irq mask 0x1 PNP0100: adding io range 0x40-0x43, size=0x4, align=0 pnpbios: handle 2 device ID PNP0100 (0001d041) PNP0b00: adding irq mask 0x100 PNP0b00: adding io range 0x70-0x71, size=0x2, align=0 pnpbios: handle 3 device ID PNP0b00 (000bd041) PNP0303: adding irq mask 0x2 PNP0303: adding io range 0x60-0x60, size=0x1, align=0 PNP0303: adding io range 0x64-0x64, size=0x1, align=0 pnpbios: handle 4 device ID PNP0303 (0303d041) PNP0800: adding io range 0x61-0x61, size=0x1, align=0 pnpbios: handle 5 device ID PNP0800 (0008d041) PNP0c04: adding irq mask 0x2000 PNP0c04: adding io range 0xf0-0xff, size=0x10, align=0 pnpbios: handle 6 device ID PNP0c04 (040cd041) PNP0c01: adding fixed memory32 range 0xf0000-0xf3fff, size=0x4000 PNP0c01: adding fixed memory32 range 0xf4000-0xf7fff, size=0x4000 PNP0c01: adding fixed memory32 range 0xf8000-0xfbfff, size=0x4000 PNP0c01: adding fixed memory32 range 0xfc000-0xfffff, size=0x4000 PNP0c01: adding fixed memory32 range 0-0x9ffff, size=0xa0000 PNP0c01: adding fixed memory32 range 0xfffe0000-0xffffffff, size=0x20000 PNP0c01: adding fixed memory32 range 0x100000-0x1ffffff, size=0x1f00000 pnpbios: handle 7 device ID PNP0c01 (010cd041) PNP0a03: adding io range 0x4d0-0x4d1, size=0x2, align=0 PNP0a03: adding io range 0xcf8-0xcff, size=0x8, align=0 PNP0a03: adding io range 0x480-0x48f, size=0x10, align=0 PNP0a03: adding io range 0x4f00-0x4f3f, size=0x40, align=0 PNP0a03: adding io range 0x5f00-0x5f1f, size=0x20, align=0 pnpbios: handle 8 device ID PNP0a03 (030ad041) PNP0501: adding irq mask 0x10 PNP0501: adding io range 0x3f8-0x3ff, size=0x8, align=0 pnpbios: handle 9 device ID PNP0501 (0105d041) PNP0501: adding irq mask 0x8 PNP0501: adding io range 0x2f8-0x2ff, size=0x8, align=0 pnpbios: handle 10 device ID PNP0501 (0105d041) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xc7fff on isa0 pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices unknown: can't assign resources (port) unknown: at port 0x60 on isa0 unknown: failed to probe at port 0x61 on isa0 unknown: can't assign resources (memory) unknown: at iomem 0-0x9ffff,0xfc000-0xfffff,0xf8000-0xfbfff,0xf4000-0xf7fff,0xf0000-0xf3fff on isa0 unknown: can't assign resources (port) unknown: at port 0x4d0-0x4d1 on isa0 unknown: can't assign resources (port) unknown: at port 0x3f8-0x3ff on isa0 unknown: can't assign resources (port) unknown: at port 0x2f8-0x2ff on isa0 Device configuration finished. Timecounter "TSC" frequency 200455528 Hz quality 800 Timecounters tick every 10.000 msec pflog0: bpf attached pfsync0: bpf attached lo0: bpf attached ata0-master: pio=0x0c wdma=0x22 udma=0xffffffff cable=40pin ata0-master: setting PIO4 on Intel PIIX4 chip ata0-master: setting WDMA2 on Intel PIIX4 chip ad0: ATA-0 disk at ata0-master ad0: 2014MB (4124736 sectors), 4092 C, 16 H, 63 S, 512 B ad0: 1 secs/int, 1 depth queue, WDMA2 GEOM: new disk ad0 ata1-master: pio=0x0c wdma=0x22 udma=0xffffffff cable=40pin ATAPI_RESET time = 70us ata1-master: setting PIO4 on Intel PIIX4 chip acd0: CDROM drive at ata1 as master acd0: read 5511KB/s (5511KB/s), 128KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream acd0: Writes: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/15/63 s:63 l:4124673 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 32256 length 2111832576 end 2111864831 GEOM: Configure ad0s1a, start 0 length 1415577600 end 1415577599 GEOM: Configure ad0s1b, start 1572864000 length 538968576 end 2111832575 GEOM: Configure ad0s1c, start 0 length 2111832576 end 2111832575 GEOM: Configure ad0s1d, start 1415577600 length 157286400 end 1572863999 Mounting root from ufs:/dev/ad0s1a start_init: trying /sbin/init --Apple-Mail-13--84136162-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 08:28:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71CE516A4CE for ; Mon, 9 Aug 2004 08:28:22 +0000 (GMT) Received: from erg.verweg.com (erg.verweg.com [217.77.141.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA3C443D53 for ; Mon, 9 Aug 2004 08:28:21 +0000 (GMT) (envelope-from stephanb@whacky.net) Received: from [192.168.1.104] (152.14.static.dsl.luna.net [217.77.152.14]) (authenticated bits=0) by erg.verweg.com (8.12.11/8.12.11) with ESMTP id i798SF2l047451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Aug 2004 10:28:15 +0200 (CEST) (envelope-from stephanb@whacky.net) X-Authentication-Warning: erg.verweg.com: Host 152.14.static.dsl.luna.net [217.77.152.14] claimed to be [192.168.1.104] Message-ID: <4117359E.3000003@whacky.net> Date: Mon, 09 Aug 2004 10:28:14 +0200 From: Stephan van Beerschoten User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040808) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephan van Beerschoten References: <4113F7B1.6040906@whacky.net> In-Reply-To: <4113F7B1.6040906@whacky.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on erg.verweg.com cc: current@freebsd.org Subject: Re: world broken (due to gcc import?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 08:28:22 -0000 Stephan van Beerschoten wrote: > The following has occured I believe since yesterday or the day before. > I just cvsupped again and the problem is still there: > > <...> > > Any clue ? Nobody has any idea how to fix this ? This error happends right at the start of the following segment: >>> stage 4.2: building libraries I'm surprised nobody else has this error. CVSup is freshly done; tree has been cleaned multiple times with no effect. I haven't done anything odd with my tree, but make buildworld is not going anywhere. Let me copy in some more output: -------------------------------------------------------------- >>> stage 4.2: building libraries -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/i386/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/legacy/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 _SHLIBDIRPREFIX=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 -DNOFSCHG -DNOHTML -DNOINFO -DNOLINT -DNOMAN -DNOPROFILE libraries cd /usr/src; make -f Makefile.inc1 _startup_libs; make -f Makefile.inc1 _prebuild_libs; make -f Makefile.inc1 _generic_libs; ===> gnu/lib/csu make -f /usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/csu/../../../contrib/gcc tconfig.h echo '#ifndef GCC_TCONFIG_H' > tconfig.h echo '#define GCC_TCONFIG_H' >> tconfig.h echo '#ifdef IN_GCC' >> tconfig.h echo '# include "ansidecl.h"' >> tconfig.h echo '#endif' >> tconfig.h echo '#define USED_FOR_TARGET' >> tconfig.h echo '#endif /* GCC_TCONFIG_H */' >> tconfig.h make -f /usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/csu/../../../contrib/gcc tm.h echo '#ifndef GCC_TM_H' > tm.h echo '#define GCC_TM_H' >> tm.h echo '#ifdef IN_GCC' >> tm.h echo '#include "i386/i386.h"' >> tm.h echo '#include "i386/unix.h"' >> tm.h echo '#include "i386/att.h"' >> tm.h echo '#include "dbxelf.h"' >> tm.h echo '#include "elfos.h"' >> tm.h echo '#include "freebsd-native.h"' >> tm.h echo '#include "freebsd-spec.h"' >> tm.h echo '#include "freebsd.h"' >> tm.h echo '#include "i386/freebsd.h"' >> tm.h echo '#include "defaults.h"' >> tm.h echo '#if !defined GENERATOR_FILE && !defined USED_FOR_TARGET' >> tm.h echo '# include "insn-constants.h"' >> tm.h echo '# include "insn-flags.h"' >> tm.h echo '#endif' >> tm.h echo '#endif' >> tm.h echo '#define EXTRA_MODES_FILE "i386/i386-modes.def"' >> tm.h echo '#endif /* GCC_TM_H */' >> tm.h rm -f .depend mkdep -f .depend -a -DCRT_BEGIN -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config -I/usr/src/gnu/lib/csu/../../../contrib/gcc -I. -I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c In file included from /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:60: /usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools/auto-host.h:4:23: sys/param.h: No such file or directory /usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools/auto-host.h:5:24: sys/endian.h: No such file or directory In file included from /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:62: /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:44:20: stddef.h: No such file or directory /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:45:19: float.h: No such file or directory /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:76:20: stdarg.h: No such file or directory /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:79:19: stdio.h: No such file or directory /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:82:23: sys/types.h: No such file or directory /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:85:19: errno.h: No such file or directory /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:92:20: string.h: No such file or directory /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:93:20: stdlib.h: No such file or directory /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:94:20: unistd.h: No such file or directory /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:97:20: limits.h: No such file or directory /usr/src/gnu/lib/csu/../../../contrib/gcc/tsystem.h:100:18: time.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/gnu/lib/csu. *** Error code 1 Stop in /usr/src. *** Error code 1 /Stephan From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 09:07:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F72B16A4CE for ; Mon, 9 Aug 2004 09:07:25 +0000 (GMT) Received: from gateway.nixsys.be (gateway.nixsys.be [195.144.77.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BCCA43D2D for ; Mon, 9 Aug 2004 09:07:25 +0000 (GMT) (envelope-from philip@nixsys.be) Received: from loge.nixsys.be (loge.nixsys.be [195.144.77.45]) by gateway.nixsys.be (Postfix) with ESMTP id DCBD382 for ; Mon, 9 Aug 2004 11:07:23 +0200 (CEST) Received: from loge.nixsys.be (localhost [127.0.0.1]) by loge.nixsys.be (8.13.1/8.13.1) with ESMTP id i7997NtD051639 for ; Mon, 9 Aug 2004 11:07:23 +0200 (CEST) (envelope-from philip@loge.nixsys.be) Received: (from philip@localhost) by loge.nixsys.be (8.13.1/8.13.1/Submit) id i7997NWd051638 for freebsd-current@freebsd.org; Mon, 9 Aug 2004 11:07:23 +0200 (CEST) (envelope-from philip) Date: Mon, 9 Aug 2004 11:07:23 +0200 From: Philip Paeps To: freebsd-current@freebsd.org Message-ID: <20040809090723.GI642@loge.nixsys.be> Mail-Followup-To: freebsd-current@freebsd.org References: <20040805071236.GA595@loge.nixsys.be> <8cb27cbf040808194617634e07@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8cb27cbf040808194617634e07@mail.gmail.com> X-Date-in-Rome: ante diem V Idius Augustas MMDCCLVII ab Urbe Condida X-PGP-Fingerprint: FA74 3C27 91A6 79D5 F6D3 FC53 BF4B D0E6 049D B879 X-Message-Flag: Get a proper mailclient! User-Agent: Mutt/1.5.6i Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 09:07:25 -0000 On 2004-08-08 21:46:09 (-0500), Jon Drews wrote: > On Thu, 5 Aug 2004 09:12:36 +0200, Philip Paeps wrote: > > Since the original synaptics support was added to psm, there have been > > some reports of malfunctions and missing magic. I've tried to fix all > > that, but it's still work in progress. > > I get freezes when I attempt to configure my synaptics touchpad, > with sysinstall. Which revision of psm.c is this? r1.71 or r1.76? > dmesg output: psm0: model Synaptics Touchpad, device ID 0 Could you also post the 'info*' and 'cap*' lines from a verbose boot? > I will apply your patch tonight and test again. Thanks. It's in -current now by the way. - Philip -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. BOFH Excuse #29: It works the way the Wang did, what's the problem From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 09:09:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B49716A4CE for ; Mon, 9 Aug 2004 09:09:11 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11A2643D1F for ; Mon, 9 Aug 2004 09:09:11 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.13.1/8.12.11) with ESMTP id i7997gBm032225; Mon, 9 Aug 2004 02:07:43 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i7997fbh032223; Mon, 9 Aug 2004 02:07:41 -0700 (PDT) (envelope-from obrien) Date: Mon, 9 Aug 2004 02:07:40 -0700 From: "David O'Brien" To: Oliver Eikemeier Message-ID: <20040809090740.GB31766@dragon.nuxi.com> Mail-Followup-To: David O'Brien , Oliver Eikemeier , Jon Noack , current@freebsd.org, Edwin Groothuis References: <20040803170201.GA87300@dragon.nuxi.com> <4DA0F154-E57B-11D8-9C56-00039312D914@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DA0F154-E57B-11D8-9C56-00039312D914@fillmore-labs.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: Edwin Groothuis cc: current@freebsd.org Subject: Re: upgrade of file(1) to 4.10 (including FreeBSD elf(5) fixes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 09:09:11 -0000 On Tue, Aug 03, 2004 at 08:31:15PM +0200, Oliver Eikemeier wrote: > As usual, file(1) has to follow. Anyway, since it works for now, and > currently there is no reason to break it, why is it bad? I actually like > that feature, and it is useful for debugging ports that should have been > recompiled after a system upgrade. Sounds like you're trying to work around bugs in the Ports Collection, please go fix those bugs and use the proper tool for the job. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 09:18:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D79616A4CE; Mon, 9 Aug 2004 09:18:00 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F0A843D39; Mon, 9 Aug 2004 09:18:00 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-14.local ([172.16.0.14] helo=dhcp-11.local) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41 (FreeBSD)) id 1Bu6I0-0006X7-A9; Mon, 09 Aug 2004 11:17:59 +0200 Date: Mon, 9 Aug 2004 11:19:29 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) To: obrien@freebsd.org From: Oliver Eikemeier In-Reply-To: <20040809090740.GB31766@dragon.nuxi.com> Message-Id: <37C15666-E9E5-11D8-9C56-00039312D914@fillmore-labs.com> Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: Edwin Groothuis cc: current@freebsd.org Subject: Re: upgrade of file(1) to 4.10 (including FreeBSD elf(5) fixes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 09:18:00 -0000 David O'Brien wrote: > On Tue, Aug 03, 2004 at 08:31:15PM +0200, Oliver Eikemeier wrote: >> As usual, file(1) has to follow. Anyway, since it works for now, and >> currently there is no reason to break it, why is it bad? I actually >> like >> that feature, and it is useful for debugging ports that should have >> been >> recompiled after a system upgrade. > > Sounds like you're trying to work around bugs in the Ports Collection, > please go fix those bugs and use the proper tool for the job. Could you please elaborate which bugs you are referring to? The current file(1) works fine for me in this aspect, so what are better tools for the job? -Oliver From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 09:30:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51A5116A4CF for ; Mon, 9 Aug 2004 09:30:31 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22E1943D5E for ; Mon, 9 Aug 2004 09:30:31 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.13.1/8.12.11) with ESMTP id i799T1he033580; Mon, 9 Aug 2004 02:29:02 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i799Su6X033574; Mon, 9 Aug 2004 02:28:56 -0700 (PDT) (envelope-from obrien) Date: Mon, 9 Aug 2004 02:28:56 -0700 From: "David O'Brien" To: Oliver Eikemeier Message-ID: <20040809092856.GA33479@dragon.nuxi.com> Mail-Followup-To: David O'Brien , Oliver Eikemeier , Jon Noack , current@freebsd.org, Edwin Groothuis References: <20040809090740.GB31766@dragon.nuxi.com> <37C15666-E9E5-11D8-9C56-00039312D914@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37C15666-E9E5-11D8-9C56-00039312D914@fillmore-labs.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: Edwin Groothuis cc: current@freebsd.org Subject: Re: upgrade of file(1) to 4.10 (including FreeBSD elf(5) fixes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 09:30:31 -0000 On Mon, Aug 09, 2004 at 11:19:29AM +0200, Oliver Eikemeier wrote: > David O'Brien wrote: > > >On Tue, Aug 03, 2004 at 08:31:15PM +0200, Oliver Eikemeier wrote: > >>As usual, file(1) has to follow. Anyway, since it works for now, and > >>currently there is no reason to break it, why is it bad? I actually > >>like > >>that feature, and it is useful for debugging ports that should have > >>been > >>recompiled after a system upgrade. > > > >Sounds like you're trying to work around bugs in the Ports Collection, > >please go fix those bugs and use the proper tool for the job. > > Could you please elaborate which bugs you are referring to? The current > file(1) works fine for me in this aspect, so what are better tools for > the job? It appears you're concerned when FreeBSD X.Y comes out, you've got ports compiled on X.(Y-1). This is not a problem, and I'm not sure why you feel it is that you appear to run file(1) across all of /usr/local and /usr/X11R6 and reinstall any binaries you find from X.(Y-1). Since X.Y will run X.(Y-1) binaries just fine I'm not sure why you have this need. portupgrade(8) is the proper tool to refresh all your ports. If you find that X.Y can't run an X.(Y-1) binary then the root cause of that bug should be fixed. I don't see that your method of running file(1) across everything scales well to the typical user. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 09:31:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05B3816A4CE; Mon, 9 Aug 2004 09:31:44 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2FFD43D1D; Mon, 9 Aug 2004 09:31:43 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1Bu6VK-000PHH-KZ; Mon, 09 Aug 2004 12:31:42 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: "Michael C. Shultz" In-reply-to: Your message of Sun, 8 Aug 2004 09:16:50 -0700 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Aug 2004 12:31:42 +0300 From: Danny Braniss Message-Id: <20040809093143.B2FFD43D1D@mx1.FreeBSD.org> cc: YONETANI Tomokazu cc: harti@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Need help: buildworld for CURRENT while under STABLE is not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 09:31:44 -0000 > On Sunday 08 August 2004 06:51 am, you wrote: > > > --Boundary-00=_yfRFBa4bKiL1gzl > > > Content-Type: text/plain; > > > charset="us-ascii" > > > Content-Transfer-Encoding: 7bit > > > Content-Disposition: inline > > > > > > I have STABLE on ad0 and a working snapshot of CURRENT on ad1, I am > > > trying to run: > > > > > > make buildworld -DDESTDIR=/ad1 while booted from STABLE and I keep > > > getting the following error: (Note: cvsup'ed just before running make > > > build world still didn't help, neither does cleaning before hand...) > > > I'll attach my make.conf in case that helps... > > > > type > > make buildworld > > then when you are ready to install: > > make installworld DESTDIR=/ad1 > > (notice no -DESTDIR ...) > > > > danny > > OK, I just tried that after cleaning the tree and Igetexaclt y the same > failure: > > ===> usr.sbin/bsnmpd/gensnmptree > /usr/obj/ad1/usr/src/i386/ad1/usr/src/usr.sbin/bsnmpd/gensnmptree created > for /ad1/usr/src/usr.sbin/bsnmpd/gensnmptree > rm -f .depend > mkdep -f .depend -a > -I/ad1/usr/src/usr.sbin/bsnmpd/gensnmptree/../../../contrib/bsnmp/lib > -I/usr/obj/ad1/usr/src/i386/legacy/usr/include /ad1/usr/src/usr.sbin/bsnmpd/gensnmptree/../../../contrib/bsnmp/gensnmptree/gensnmptree.c > /ad1/usr/src/usr.sbin/bsnmpd/gensnmptree/../../../contrib/bsnmp/gensnmptree/gensnmptree.c:66: > stdint.h: No such file or directory > mkdep: compile failed > *** Error code 1 > > Stop in /ad1/usr/src/usr.sbin/bsnmpd/gensnmptree. > *** Error code 1 > > Stop in /ad1/usr/src. > *** Error code 1 > > Stop in /ad1/usr/src. > *** Error code 1 > > Stop in /ad1/usr/src. > > Now here are the locations of stdint.h on my system: > [mike]/ad1/usr/src>locate stdint.h > /ad1/usr/include/machine/_stdint.h > /ad1/usr/include/stdint.h > /ad1/usr/include/sys/stdint.h > /ad1/usr/src/sys/alpha/include/_stdint.h > /ad1/usr/src/sys/amd64/include/_stdint.h > /ad1/usr/src/sys/arm/include/_stdint.h > /ad1/usr/src/sys/i386/include/_stdint.h > /ad1/usr/src/sys/ia64/include/_stdint.h > /ad1/usr/src/sys/powerpc/include/_stdint.h > /ad1/usr/src/sys/sparc64/include/_stdint.h > /ad1/usr/src/sys/sys/stdint.h > [mike]/ad1/usr/src> > > It wants to pull from /usr/include. I tested this by putting a soft link > from /usr/include/stdint.h to /ad1/usr/include/stdint.h and it got past that > one error to only error on another header file. It is my understanding that > only header files from under (in my case)/ad1/usr/src should be needed to > compile the world correct? > > -Mike after my last cvsupdate, now im also suffering from this :-(, the problem is indeed in /usr/src/usr.sbin/bsnmpd/gensnmptree/gensnmptree.c, i simply removed the offending include and now it's at least cross compiling. danny From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 09:36:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D08916A4CE for ; Mon, 9 Aug 2004 09:36:56 +0000 (GMT) Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D9A143D48 for ; Mon, 9 Aug 2004 09:36:55 +0000 (GMT) (envelope-from stijn@pcwin002.win.tue.nl) Received: from pcwin002.win.tue.nl (orb_rules@localhost [127.0.0.1]) by pcwin002.win.tue.nl (8.12.11/8.12.11) with ESMTP id i799arti004108; Mon, 9 Aug 2004 11:36:53 +0200 (CEST) (envelope-from stijn@pcwin002.win.tue.nl) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.12.11/8.12.11/Submit) id i799aq95004107; Mon, 9 Aug 2004 11:36:52 +0200 (CEST) (envelope-from stijn) Date: Mon, 9 Aug 2004 11:36:52 +0200 From: Stijn Hoop To: Allan Fields Message-ID: <20040809093652.GE91609@pcwin002.win.tue.nl> References: <20040808211337.GB91609@pcwin002.win.tue.nl> <20040809074732.GA3155@afields.ca> <20040809075228.GC91609@pcwin002.win.tue.nl> <20040809081901.GB3155@afields.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8nsIa27JVQLqB7/C" Content-Disposition: inline In-Reply-To: <20040809081901.GB3155@afields.ca> User-Agent: Mutt/1.4.2.1i X-Bright-Idea: Let's abolish HTML mail! cc: freebsd-current@freebsd.org Subject: Re: slice weirdness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 09:36:56 -0000 --8nsIa27JVQLqB7/C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 09, 2004 at 04:19:01AM -0400, Allan Fields wrote: > Something to try: once in a kernel, try either not using devfs or > manually creating device nodes and see if you can make it work with > ad1s2. Will do tomorrow. > > > i.e. if you were to go the sysinstall route and do a fresh install > > > on ad1, exhibit same behaviour? > >=20 > > Yes, it does. I didn't use sysinstall but 'make installworld' but either > > doing fdisk / disklabel by hand or by doing it using sysinstall, both > > methods stop at the same 'cannot find root' prompt when booting off the > > slice. A reboot into the old install later and my device entry is gone > > again. >=20 > You mean you can't see the new ad1s2 slice from a kernel booted off > ad0 either? Which would be consistent to the problem. Exactly, but as far as I can determine it only disappears if I boot from the new slice (which is why I suspect geometry bugs; I guess something in the bootblocks/loader is writing something to the disk which foobar's the new slice). > Try: > sysctl -b kern.geom.confxml Great, will try tomorrow (machine's at home and I won't be until late tonig= ht). --Stijn --=20 In the force if Yoda's so strong, construct a sentence with words in the proper order then why can't he? --8nsIa27JVQLqB7/C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBF0W0Y3r/tLQmfWcRAkh7AJ47kYslZSWl1Zam0b9xrDJ7krXMcACdF5tV laa9uJ3vVlXsQTEkO45wg1U= =HbC6 -----END PGP SIGNATURE----- --8nsIa27JVQLqB7/C-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 09:39:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A77A16A4CE for ; Mon, 9 Aug 2004 09:39:24 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F70543D5D for ; Mon, 9 Aug 2004 09:39:23 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i799d8X486720; Mon, 9 Aug 2004 11:39:08 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) i799d8f194800; Mon, 9 Aug 2004 11:39:08 +0200 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i799d6e25614; Mon, 9 Aug 2004 11:39:06 +0200 (MET DST) Date: Mon, 9 Aug 2004 11:39:08 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: Danny Braniss In-Reply-To: <20040809093143.B2FFD43D1D@mx1.FreeBSD.org> Message-ID: <20040809113434.T12541@beagle.kn.op.dlr.de> References: <20040809093143.B2FFD43D1D@mx1.FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: YONETANI Tomokazu cc: "Michael C. Shultz" cc: freebsd-current@freebsd.org Subject: Re: Need help: buildworld for CURRENT while under STABLE is not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 09:39:24 -0000 On Mon, 9 Aug 2004, Danny Braniss wrote: DB>> On Sunday 08 August 2004 06:51 am, you wrote: DB>> > > --Boundary-00=_yfRFBa4bKiL1gzl DB>> > > Content-Type: text/plain; DB>> > > charset="us-ascii" DB>> > > Content-Transfer-Encoding: 7bit DB>> > > Content-Disposition: inline DB>> > > DB>> > > I have STABLE on ad0 and a working snapshot of CURRENT on ad1, I am DB>> > > trying to run: DB>> > > DB>> > > make buildworld -DDESTDIR=/ad1 while booted from STABLE and I keep DB>> > > getting the following error: (Note: cvsup'ed just before running make DB>> > > build world still didn't help, neither does cleaning before hand...) DB>> > > I'll attach my make.conf in case that helps... DB>> > DB>> > type DB>> > make buildworld DB>> > then when you are ready to install: DB>> > make installworld DESTDIR=/ad1 DB>> > (notice no -DESTDIR ...) DB>> > DB>> > danny DB>> DB>> OK, I just tried that after cleaning the tree and Igetexaclt y the same DB>> failure: DB>> DB>> ===> usr.sbin/bsnmpd/gensnmptree DB>> /usr/obj/ad1/usr/src/i386/ad1/usr/src/usr.sbin/bsnmpd/gensnmptree created DB>> for /ad1/usr/src/usr.sbin/bsnmpd/gensnmptree DB>> rm -f .depend DB>> mkdep -f .depend -a DB>> -I/ad1/usr/src/usr.sbin/bsnmpd/gensnmptree/../../../contrib/bsnmp/lib DB>> -I/usr/obj/ad1/usr/src/i386/legacy/usr/include /ad1/usr/src/usr.sbin/bsnmpd/gensnmptree/../../../contrib/bsnmp/gensnmptree/gensnmptree.c DB>> /ad1/usr/src/usr.sbin/bsnmpd/gensnmptree/../../../contrib/bsnmp/gensnmptree/gensnmptree.c:66: DB>> stdint.h: No such file or directory DB>> mkdep: compile failed DB>> *** Error code 1 DB>> DB>> Stop in /ad1/usr/src/usr.sbin/bsnmpd/gensnmptree. DB>> *** Error code 1 DB>> DB>> Stop in /ad1/usr/src. DB>> *** Error code 1 DB>> DB>> Stop in /ad1/usr/src. DB>> *** Error code 1 DB>> DB>> Stop in /ad1/usr/src. DB>> DB>> Now here are the locations of stdint.h on my system: DB>> [mike]/ad1/usr/src>locate stdint.h DB>> /ad1/usr/include/machine/_stdint.h DB>> /ad1/usr/include/stdint.h DB>> /ad1/usr/include/sys/stdint.h DB>> /ad1/usr/src/sys/alpha/include/_stdint.h DB>> /ad1/usr/src/sys/amd64/include/_stdint.h DB>> /ad1/usr/src/sys/arm/include/_stdint.h DB>> /ad1/usr/src/sys/i386/include/_stdint.h DB>> /ad1/usr/src/sys/ia64/include/_stdint.h DB>> /ad1/usr/src/sys/powerpc/include/_stdint.h DB>> /ad1/usr/src/sys/sparc64/include/_stdint.h DB>> /ad1/usr/src/sys/sys/stdint.h DB>> [mike]/ad1/usr/src> DB>> DB>> It wants to pull from /usr/include. I tested this by putting a soft link DB>> from /usr/include/stdint.h to /ad1/usr/include/stdint.h and it got past that DB>> one error to only error on another header file. It is my understanding that DB>> only header files from under (in my case)/ad1/usr/src should be needed to DB>> compile the world correct? DB>> DB>> -Mike DB> DB>after my last cvsupdate, now im also suffering from this :-(, DB>the problem is indeed in /usr/src/usr.sbin/bsnmpd/gensnmptree/gensnmptree.c, DB>i simply removed the offending include and now it's at least cross compiling. Removing the include is problematic because the program needs the fixed size integer types (uint32_t for example). The correct thing to get these is to include (see 7.19 of C99). There appears to be another header defining these types that probably shouldn't do this. I'm currently looking into properly getting tools/build/Makefile to install the necessary file into ${MAKEOBJDIRPREFIX}/usr/src/{MACHINE}/legacy/include. That appears to be not easy, because stdint.h is a symbolic link to sys/stdint.h which in turn needs sys/_types.h, machine/_stdint.h which in turn needs machine/_types.h. Argh.... harti From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 09:41:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E6A116A4CE for ; Mon, 9 Aug 2004 09:41:28 +0000 (GMT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 264E043D5A for ; Mon, 9 Aug 2004 09:41:27 +0000 (GMT) (envelope-from mike@urgle.com) Received: from singsing.eng.demon.net (singsing.eng.demon.net [194.217.90.11]) by internal.mail.demon.net with ESMTP id i799i3420365; Mon, 9 Aug 2004 09:44:03 GMT Received: from singsing.eng.demon.net (localhost [127.0.0.1]) i799fNtY021220 for ; Mon, 9 Aug 2004 10:41:23 +0100 (BST) (envelope-from mike@urgle.com) Received: (from michaelb@localhost) by singsing.eng.demon.net (8.12.10/8.12.10/Submit) id i799fMTq021219 for freebsd-current@freebsd.org; Mon, 9 Aug 2004 10:41:22 +0100 (BST) (envelope-from mike@urgle.com) X-Authentication-Warning: singsing.eng.demon.net: michaelb set sender to mike@urgle.com using -f From: Mike Bristow To: freebsd-current@freebsd.org In-Reply-To: <18860.1091899169@www66.gmx.net> References: <18860.1091899169@www66.gmx.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: (none) Message-Id: <1092044482.20927.35.camel@singsing.eng.demon.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 09 Aug 2004 10:41:22 +0100 Subject: Re: panic: mutex vr0 not owned at ...if_vr.c:571 when doing ifconfig X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 09:41:28 -0000 On Sat, 2004-08-07 at 18:19, Andreas Kohn wrote: > Hi, > > with sources from earlier today, I get a panic when doing ifconfig (no > arguments): I saw the same thing earlier this week; PR 70189 contains a patch that works for me. (Sorry for the repetition, Andreas: I forgot to CC the list) -- Mike Bristow - http://www.urgle.com/~mike/ - mike@urgle.com Why didn't the skeleton go to the New Years Eve party? A naughty bus From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 09:42:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F02316A4CE for ; Mon, 9 Aug 2004 09:42:11 +0000 (GMT) Received: from web.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85EB543D2D for ; Mon, 9 Aug 2004 09:42:10 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.20] (portacare.portaone.com [195.140.247.242]) (authenticated bits=0) by web.portaone.com (8.12.8p2/8.12.8) with ESMTP id i799g5x0076808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Aug 2004 11:42:07 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <411746EB.5030006@portaone.com> Date: Mon, 09 Aug 2004 12:42:03 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eriksson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@FreeBSD.ORG Subject: Re: Simple BDE disc encryption benchmark X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 09:42:11 -0000 Daniel Eriksson wrote: > Hi! I just ran a very simple benchmark on the GBDE disc encryption in > CURRENT. The benchmark setup looked like this: > > * Slow machine (Celeron 366, 128MB mem) > * 5-CURRENT from yesterday, running off of some old ATA disc > * 2 x 9GB 10k rpm SCSI discs hooked up to an Adaptec 2940 > > The benchmark was to copy the /usr directory (copied from the ATA disc, > 1.7GB) or a directory containing big files (/bigfiles, 1.7GB in 16 files > created by 'dd if=/dev/random ...') from scsi disc 1 to scsi disc 2. I ran > each benchmark twice and took a simple average of the results. > > unencrypted to unencrypted: > /usr : 697 real 10.6 user 235 sys (~50% idle) > /bigfiles: 123 real 0.4 user 84 sys (~25% idle) > > unencrypted to encrypted: > /usr : 1778 real 10.7 user 236 sys (~35% idle) > /bigfiles: 379 real 0.4 user 82 sys (~10% idle) > > encrypted to encrypted: > /usr : 1978 real 11.6 user 242 sys (~25% idle) > /bigfiles: 615 real 0.4 user 80 sys (0% idle) > > The only time the CPU was completely busy was when copying /bigfiles from > encrypted to encrypted. > > My question is: Why does the it take so much longer when encryption is > involved even though 'top' seems to think there are CPU cycles left to burn? The problem (well, not quite "the problem" since it is design decision) is that GBDE tries to rearrange sectors in pseudo-random fashion to make cryptoanalysis harder. Usually filesystem tries to place all sectors that belong to the same file consequently, to avoid expensive disk seeks. But on encrypted disk logically ajaced sectors are physically spread, so that reading them introduces seek delays. -Maxim From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 09:46:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 492C416A4CE; Mon, 9 Aug 2004 09:46:34 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BD4C43D39; Mon, 9 Aug 2004 09:46:34 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-14.local ([172.16.0.14] helo=dhcp-11.local) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41 (FreeBSD)) id 1Bu6je-0006a8-W1; Mon, 09 Aug 2004 11:46:33 +0200 Date: Mon, 9 Aug 2004 11:48:04 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) To: obrien@freebsd.org From: Oliver Eikemeier In-Reply-To: <20040809092856.GA33479@dragon.nuxi.com> Message-Id: <35CE94B0-E9E9-11D8-9C56-00039312D914@fillmore-labs.com> Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: Edwin Groothuis cc: current@freebsd.org Subject: Re: upgrade of file(1) to 4.10 (including FreeBSD elf(5) fixes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 09:46:34 -0000 David O'Brien wrote: > On Mon, Aug 09, 2004 at 11:19:29AM +0200, Oliver Eikemeier wrote: >> David O'Brien wrote: >> >>> On Tue, Aug 03, 2004 at 08:31:15PM +0200, Oliver Eikemeier wrote: >>>> As usual, file(1) has to follow. Anyway, since it works for now, and >>>> currently there is no reason to break it, why is it bad? I actually >>>> like >>>> that feature, and it is useful for debugging ports that should have >>>> been >>>> recompiled after a system upgrade. >>> >>> Sounds like you're trying to work around bugs in the Ports Collection, >>> please go fix those bugs and use the proper tool for the job. >> >> Could you please elaborate which bugs you are referring to? The current >> file(1) works fine for me in this aspect, so what are better tools for >> the job? > > It appears you're concerned when FreeBSD X.Y comes out, you've got ports > compiled on X.(Y-1). This is not a problem, and I'm not sure why you > feel it is that you appear to run file(1) across all of /usr/local and > /usr/X11R6 and reinstall any binaries you find from X.(Y-1). Since X.Y > will run X.(Y-1) binaries just fine I'm not sure why you have this need. > portupgrade(8) is the proper tool to refresh all your ports. If you > find > that X.Y can't run an X.(Y-1) binary then the root cause of that bug > should be fixed. You might notice that 5.3-RELEASE won't run all 5.2.1-RELEASE binaries. > I don't see that your method of running file(1) across everything scales > well to the typical user. The magic word here is `debugging' (see above). When you read src/UPDATING you might notice that some updates require recompilation of affected ports. It is very convenient to let users submitting bug reports run file(1) on the affected binary, and, given that it has been compiled on an older release, tell them that they missed the entry in UPDATING, which suggested to recompile the port. -Oliver From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 09:55:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70D2D16A4CF for ; Mon, 9 Aug 2004 09:55:50 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id D28B043D45 for ; Mon, 9 Aug 2004 09:55:49 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i799tlwU017521; Mon, 9 Aug 2004 11:55:47 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Maxim Sobolev From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 09 Aug 2004 12:42:03 +0300." <411746EB.5030006@portaone.com> Date: Mon, 09 Aug 2004 11:55:47 +0200 Message-ID: <17520.1092045347@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-current@freebsd.org cc: Daniel Eriksson Subject: Re: Simple BDE disc encryption benchmark X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 09:55:50 -0000 In message <411746EB.5030006@portaone.com>, Maxim Sobolev writes: >> The only time the CPU was completely busy was when copying /bigfiles from >> encrypted to encrypted. >> >> My question is: Why does the it take so much longer when encryption is >> involved even though 'top' seems to think there are CPU cycles left to burn? > >The problem (well, not quite "the problem" since it is design decision) >is that GBDE tries to rearrange sectors in pseudo-random fashion to make >cryptoanalysis harder. Usually filesystem tries to place all sectors >that belong to the same file consequently, to avoid expensive disk >seeks. But on encrypted disk logically ajaced sectors are physically >spread, so that reading them introduces seek delays. Uhm, this is not quite correct. It is true that I played around with pseudo-random sector mapping a fair bit, but since it _totally_ killed performance I dropped it again. The mapping GBDE performs is sequential with inserted key sectors, this was the most performance friendly layout I could come up with. Poul-Henning -- 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 Mon Aug 9 10:02:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id 2FCE616A4CF; Mon, 9 Aug 2004 10:02:44 +0000 (GMT) Date: Mon, 9 Aug 2004 10:02:44 +0000 From: David O'Brien To: Jon Noack Message-ID: <20040809100244.GA17314@hub.freebsd.org> References: <410E3AA2.4030800@alumni.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <410E3AA2.4030800@alumni.rice.edu> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.10-STABLE Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: Edwin Groothuis cc: current@freebsd.org cc: Oliver Eikemeier Subject: Re: upgrade of file(1) to 4.10 (including FreeBSD elf(5) fixes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 10:02:44 -0000 On Mon, Aug 02, 2004 at 07:59:14AM -0500, Jon Noack wrote: > On 08/02/04 07:15, Oliver Eikemeier wrote: > >I've prepared an upgrade to file-4.10 at: > > > >This fixes > > PR bin/63830: [patch] file(1) doesn't recognize FreeBSD 5.x > >executables properly > > > >and an MFC will fix the problems of FreeBSD 4.10 being identified as > >4.9.1. I'll do some more testing (GCC 3.4) and think we should commit > >this before the 5.3 src freeze, especially since it has been discussed > >over a month ago: > > > > *sigh* Why does Christos Zoulas ignore me? He keeps telling me he'll > include my patch and then includes someone else's that doesn't fix the > problems. In any case, my patch (against file 4.09) to fix the versioning: > http://www.noacks.org/freebsd/readelf.c.diff > > I made a test program to compare the output. Here's the way things > would look with file 4.10: > http://www.noacks.org/freebsd/output-4.10.txt This is getting really redicious. Edwin Groothuis should have never have submitted a patch that hardcoded -CURRENT in 4.08 and -STABLE in 4.10. And we don't have offical "revisions" (nor patchlevels, other than security branches), so that output is bad also. The only reasonable thing that doesn't have us chasing this all over the place is to print out the FreeBSD major version (and MAYBE the minor versoin) and leave it at that. The "FreeBSD" section of file(1)'s readelf.c has gotten beyond control. > few months when 5.x goes -STABLE and 6.x appears. Better not to print > branch names at all (for dev branches I just print the whole version > value in parentheses). There are other minor nits like 5.0.4 and 4.15.30... > > Here's the output of my patch: > http://www.noacks.org/freebsd/output.txt This output is mostly OK -- but I would drop the __FreeBSD_version. I can't see how knowing that helps anyone. If it is insisted on keeping it, it should be printed out consistently for *all* __FreeBSD_verions, not just some. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 10:18:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D907116A4CE; Mon, 9 Aug 2004 10:18:10 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1F0143D48; Mon, 9 Aug 2004 10:18:10 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-14.local ([172.16.0.14] helo=dhcp-11.local) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41 (FreeBSD)) id 1Bu7EE-0002iX-Vv; Mon, 09 Aug 2004 12:18:09 +0200 Date: Mon, 9 Aug 2004 12:19:40 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) To: obrien@freebsd.org From: Oliver Eikemeier In-Reply-To: <20040809100244.GA17314@hub.freebsd.org> Message-Id: <9FD3F4B2-E9ED-11D8-9C56-00039312D914@fillmore-labs.com> Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: Edwin Groothuis cc: current@freebsd.org Subject: Re: upgrade of file(1) to 4.10 (including FreeBSD elf(5) fixes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 10:18:11 -0000 David O'Brien wrote: > This output is mostly OK -- but I would drop the __FreeBSD_version. I > can't see how knowing that helps anyone. If it is insisted on keeping > it, it should be printed out consistently for *all* __FreeBSD_verions, > not just some. Please don't. This has been proven very valuable, for example for the 5.1 -> 5.2 transition, see entry 20031112 in src/UPDATING. -STABLEs mostly do not have such problems, but usually you'll notice stuff like this when it is too late. -Oliver From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 11:23:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC0C616A4CE; Mon, 9 Aug 2004 11:23:32 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8344243D5C; Mon, 9 Aug 2004 11:23:32 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smtp3.sentex.ca (8.12.11/8.12.11) with ESMTP id i79BNVVk032526; Mon, 9 Aug 2004 07:23:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i79BNVrV085532; Mon, 9 Aug 2004 07:23:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C05997303F; Mon, 9 Aug 2004 07:23:31 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040809112331.C05997303F@freebsd-current.sentex.ca> Date: Mon, 9 Aug 2004 07:23:31 -0400 (EDT) Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 11:23:32 -0000 TB --- 2004-08-09 11:14:54 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-09 11:14:54 - starting CURRENT tinderbox run for i386/i386 TB --- 2004-08-09 11:14:54 - checking out the source tree TB --- 2004-08-09 11:14:54 - cd /home/tinderbox/sandbox/CURRENT/i386/i386 TB --- 2004-08-09 11:14:54 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-09 11:20:53 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-09 11:20:53 - cd /home/tinderbox/sandbox/CURRENT/i386/i386/src TB --- 2004-08-09 11:20:53 - /usr/bin/make -B buildworld >>> 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 [...] ===> usr.bin/awk yacc -d -o awkgram.c /tinderbox/CURRENT/i386/i386/src/usr.bin/awk/../../contrib/one-true-awk/awkgram.y yacc: 43 shift/reduce conflicts yacc: 85 reduce/reduce conflicts ln -sf awkgram.h ytab.h cc -O2 -pipe -DHAS_ISBLANK -I. -I/tinderbox/CURRENT/i386/i386/src/usr.bin/awk/../../contrib/one-true-awk -I/home/tinderbox/sandbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/legacy/usr/include -L/home/tinderbox/sandbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/legacy/usr/lib /tinderbox/CURRENT/i386/i386/src/usr.bin/awk/../../contrib/one-true-awk/maketab.c -o maketab ===> usr.bin/file make: don't know how to make build-tools. Stop *** Error code 2 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2004-08-09 11:23:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-09 11:23:31 - ERROR: failed to build world TB --- 2004-08-09 11:23:31 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 11:28:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2879A16A4CE; Mon, 9 Aug 2004 11:28:39 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C82A743D49; Mon, 9 Aug 2004 11:28:38 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i79BScFO017734; Mon, 9 Aug 2004 07:28:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i79BSb1e087834; Mon, 9 Aug 2004 07:28:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4E5BA7303F; Mon, 9 Aug 2004 07:28:38 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040809112838.4E5BA7303F@freebsd-current.sentex.ca> Date: Mon, 9 Aug 2004 07:28:38 -0400 (EDT) Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 11:28:39 -0000 TB --- 2004-08-09 11:23:31 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-09 11:23:31 - starting CURRENT tinderbox run for i386/pc98 TB --- 2004-08-09 11:23:31 - checking out the source tree TB --- 2004-08-09 11:23:31 - cd /home/tinderbox/sandbox/CURRENT/i386/pc98 TB --- 2004-08-09 11:23:31 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-09 11:25:53 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-09 11:25:53 - cd /home/tinderbox/sandbox/CURRENT/i386/pc98/src TB --- 2004-08-09 11:25:53 - /usr/bin/make -B buildworld >>> 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 [...] ===> usr.bin/awk yacc -d -o awkgram.c /tinderbox/CURRENT/i386/pc98/src/usr.bin/awk/../../contrib/one-true-awk/awkgram.y yacc: 43 shift/reduce conflicts yacc: 85 reduce/reduce conflicts ln -sf awkgram.h ytab.h cc -O2 -pipe -DHAS_ISBLANK -I. -I/tinderbox/CURRENT/i386/pc98/src/usr.bin/awk/../../contrib/one-true-awk -I/home/tinderbox/sandbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/i386/legacy/usr/include -L/home/tinderbox/sandbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/i386/legacy/usr/lib /tinderbox/CURRENT/i386/pc98/src/usr.bin/awk/../../contrib/one-true-awk/maketab.c -o maketab ===> usr.bin/file make: don't know how to make build-tools. Stop *** Error code 2 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2004-08-09 11:28:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-09 11:28:38 - ERROR: failed to build world TB --- 2004-08-09 11:28:38 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 11:33:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AAEA16A4CF for ; Mon, 9 Aug 2004 11:33:24 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 956AF43D46 for ; Mon, 9 Aug 2004 11:33:23 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 6AB99ACAFE; Mon, 9 Aug 2004 13:33:22 +0200 (CEST) Date: Mon, 9 Aug 2004 13:33:22 +0200 From: Pawel Jakub Dawidek To: Sam Lawrance Message-ID: <20040809113322.GL628@darkness.comp.waw.pl> References: <1091792300.749.14.camel@dirk.no.domain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PpocKf6TCvdC9BKE" Content-Disposition: inline In-Reply-To: <1091792300.749.14.camel@dirk.no.domain> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: current@FreeBSD.org Subject: Re: geom stripe/concat metadata suggestion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 11:33:24 -0000 --PpocKf6TCvdC9BKE Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 06, 2004 at 09:38:21PM +1000, Sam Lawrance wrote: +> Would it be a good idea to store the device name, or something similar, +> in the metadata? +>=20 +> For example, if I have a disk divided like this: +>=20 +> |--------------ad0--------------| +> |-------------ad0s1-------------| +> |----ad0s1g-----|-----ad0s1d----| +>=20 +> The metadata is written into the last sector, so when the stripe/concat +> classes are tasting they can't work out whether it belongs to ad0s1d, +> ad0s1 or ad0. +>=20 +> I've had problems creating stripes and concats with this configuration. I added '-h' option for 'label' command in gconcat(8), gstripe(8) and gmirror(8), which hardcode providers' names into metadata. Thank you. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --PpocKf6TCvdC9BKE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBF2ECForvXbEpPzQRAoHyAKCrZgj2zptO01e45udLiaAeHC7nowCg0cxB UbUspTNDPx1UTbAeVye/mgM= =Cr95 -----END PGP SIGNATURE----- --PpocKf6TCvdC9BKE-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 11:38:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BF1416A4CE; Mon, 9 Aug 2004 11:38:41 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D66A43D1D; Mon, 9 Aug 2004 11:38:41 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i79Bceie021462; Mon, 9 Aug 2004 07:38:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i79BceB8044546; Mon, 9 Aug 2004 07:38:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 56CF47303F; Mon, 9 Aug 2004 07:38:40 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040809113840.56CF47303F@freebsd-current.sentex.ca> Date: Mon, 9 Aug 2004 07:38:40 -0400 (EDT) Subject: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 11:38:41 -0000 TB --- 2004-08-09 11:28:38 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-09 11:28:38 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2004-08-09 11:28:38 - cleaning the sandbox TB --- 2004-08-09 11:29:58 - checking out the source tree TB --- 2004-08-09 11:29:58 - cd /home/tinderbox/sandbox/CURRENT/ia64/ia64 TB --- 2004-08-09 11:29:58 - /usr/bin/cvs -f -R -Q -d/home/ncvs checkout -P -A src TB --- 2004-08-09 11:36:45 - WARNING: /home/tinderbox/sandbox/ia64.diff does not exist TB --- 2004-08-09 11:36:45 - building world (CFLAGS=-O -pipe) TB --- 2004-08-09 11:36:45 - cd /home/tinderbox/sandbox/CURRENT/ia64/ia64/src TB --- 2004-08-09 11:36:45 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> 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 [...] ===> usr.bin/awk yacc -d -o awkgram.c /tinderbox/CURRENT/ia64/ia64/src/usr.bin/awk/../../contrib/one-true-awk/awkgram.y yacc: 43 shift/reduce conflicts yacc: 85 reduce/reduce conflicts ln -sf awkgram.h ytab.h cc -O -pipe -DHAS_ISBLANK -I. -I/tinderbox/CURRENT/ia64/ia64/src/usr.bin/awk/../../contrib/one-true-awk -I/home/tinderbox/sandbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/i386/legacy/usr/include -L/home/tinderbox/sandbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/i386/legacy/usr/lib /tinderbox/CURRENT/ia64/ia64/src/usr.bin/awk/../../contrib/one-true-awk/maketab.c -o maketab ===> usr.bin/file make: don't know how to make build-tools. Stop *** Error code 2 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2004-08-09 11:38:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-09 11:38:40 - ERROR: failed to build world TB --- 2004-08-09 11:38:40 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 11:49:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8791A16A4CE; Mon, 9 Aug 2004 11:49:47 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26BD243D49; Mon, 9 Aug 2004 11:49:47 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smtp3.sentex.ca (8.12.11/8.12.11) with ESMTP id i79Bnjpi040611; Mon, 9 Aug 2004 07:49:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i79BnkxK091345; Mon, 9 Aug 2004 07:49:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A15D27303F; Mon, 9 Aug 2004 07:49:46 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040809114946.A15D27303F@freebsd-current.sentex.ca> Date: Mon, 9 Aug 2004 07:49:46 -0400 (EDT) Subject: [current tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 11:49:47 -0000 TB --- 2004-08-09 11:38:40 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-09 11:38:40 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2004-08-09 11:38:40 - cleaning the sandbox TB --- 2004-08-09 11:40:01 - checking out the source tree TB --- 2004-08-09 11:40:01 - cd /home/tinderbox/sandbox/CURRENT/powerpc/powerpc TB --- 2004-08-09 11:40:01 - /usr/bin/cvs -f -R -Q -d/home/ncvs checkout -P -A src TB --- 2004-08-09 11:47:52 - patching the sources TB --- 2004-08-09 11:47:52 - cd /home/tinderbox/sandbox/CURRENT/powerpc/powerpc/src TB --- 2004-08-09 11:47:52 - /usr/bin/patch -f -s -i/home/tinderbox/sandbox/powerpc.diff TB --- 2004-08-09 11:47:52 - building world (CFLAGS=-O -pipe) TB --- 2004-08-09 11:47:52 - cd /home/tinderbox/sandbox/CURRENT/powerpc/powerpc/src TB --- 2004-08-09 11:47:52 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> 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 [...] ===> usr.bin/awk yacc -d -o awkgram.c /tinderbox/CURRENT/powerpc/powerpc/src/usr.bin/awk/../../contrib/one-true-awk/awkgram.y yacc: 43 shift/reduce conflicts yacc: 85 reduce/reduce conflicts ln -sf awkgram.h ytab.h cc -O -pipe -DHAS_ISBLANK -I. -I/tinderbox/CURRENT/powerpc/powerpc/src/usr.bin/awk/../../contrib/one-true-awk -I/home/tinderbox/sandbox/CURRENT/powerpc/powerpc/obj/powerpc/tinderbox/CURRENT/powerpc/powerpc/src/i386/legacy/usr/include -L/home/tinderbox/sandbox/CURRENT/powerpc/powerpc/obj/powerpc/tinderbox/CURRENT/powerpc/powerpc/src/i386/legacy/usr/lib /tinderbox/CURRENT/powerpc/powerpc/src/usr.bin/awk/../../contrib/one-true-awk/maketab.c -o maketab ===> usr.bin/file make: don't know how to make build-tools. Stop *** Error code 2 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2004-08-09 11:49:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-09 11:49:46 - ERROR: failed to build world TB --- 2004-08-09 11:49:46 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 17:30:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF99616A4CE for ; Sun, 8 Aug 2004 17:30:33 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (80-219-164-131.dclient.hispeed.ch [80.219.164.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id C71A343D3F for ; Sun, 8 Aug 2004 17:30:31 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:50db:a483:0:20e:2eff:fe06:2376]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id i78HUOT20907 verified NO) for ; Sun, 8 Aug 2004 19:30:27 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id i78HUN320899; Sun, 8 Aug 2004 19:30:23 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Sun, 8 Aug 2004 19:30:23 +0200 (CEST) Message-Id: <200408081730.i78HUN320899@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma References: <200408071057.06960.ringworm@inbox.lv> <20040808064912.GA27705@les.ath.cx> To: freebsd-current@freebsd.org X-Mailman-Approved-At: Mon, 09 Aug 2004 11:55:19 +0000 Subject: Re: Need help: buildworld for CURRENT while under STABLE is not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 17:30:33 -0000 [keep replies to the list and I'll catch up later, thanks] > > make buildworld -DDESTDIR=/ad1 while booted from STABLE and I keep getting the > > following error > Do you get the same error if you run `make buildworld' without > -DDESTDIR=/ad1 ? I get the same error (new, since a successful build or at least a build way past that point, several days ago). is not present in my -stable. I'm able to work around this requirement in the newly-updated bsnmp by adding the following dirty hack: --- /stand/obj/hacks/FreeBSD-CURRENT-src/source-hacks/tools/build/Makefile-ORIG Mon Mar 1 18:47:38 2004 +++ /stand/obj/hacks/FreeBSD-CURRENT-src/source-hacks/tools/build/Makefile Sun Aug 8 18:32:44 2004 @@ -63,6 +63,11 @@ INCS+= regex.h .endif +### HACK -stable crossbuilds (at least mine) don't have +.if !exists(/usr/include/stdint.h) +INCS+= stdint.h +.endif + .if empty(SRCS) SRCS= dummy.c .endif (shoot me if it's /usr/include/something/stdint.h; I don't have a successful build for any OS in front of me. anyway...) For -stable, the mere presence of this file is enough to make the build progress past this point. Attempting to create a useful stdint.h file in tools/build didn't quite do the job, so I took the easy way out. Of course someone who knows what they're doing can properly unbreak crossbuilds on -stable; I can do little more than a hack. (whether my build breaks further down the line, time will tell, my machine is slow and old, like me) thanks barry bouwsma From owner-freebsd-current@FreeBSD.ORG Sun Aug 8 23:55:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9050316A4CE for ; Sun, 8 Aug 2004 23:55:46 +0000 (GMT) Received: from mail.portrait.com (mail.portrait.com [64.171.32.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FA3C43D2D for ; Sun, 8 Aug 2004 23:55:44 +0000 (GMT) (envelope-from jpedras@webvolution.net) Received: from [192.168.0.230] (ned.webvolution.net [64.174.136.225]) (authenticated bits=0) by mail.portrait.com (8.12.11/8.12.11) with ESMTP id i78NtNUn060642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Aug 2004 16:55:24 -0700 (PDT) (envelope-from jpedras@webvolution.net) Message-ID: <4116BD78.1000909@webvolution.net> Date: Sun, 08 Aug 2004 16:55:36 -0700 From: Joao Pedras User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: T Kellers References: <200408072138.i77LcPxJ070334@bunrab.catwhisker.org> <200408071744.46768.timothyk@devel.njit.edu> In-Reply-To: <200408071744.46768.timothyk@devel.njit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on mail.portrait.com X-Mailman-Approved-At: Mon, 09 Aug 2004 11:55:19 +0000 cc: freebsd-current@freebsd.org Subject: Re: x server breakage? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 08 Aug 2004 23:55:46 -0000 Tim, did you figure this one out? After I added 'io' it started complaining about /dev/vga not being there. The xserver log error is 'xf86MapVidMem: Could not mmap /dev/vga (Invalid argument) I do have 'device vga' in the kernel. Thanks! T Kellers wrote: >On Saturday 07 August 2004 05:38 pm, David Wolfskill wrote: > > >>Do you have >> >>device io # I/O device >> >> >>in your kernel config? If not, did you read /usr/src/UPDATING? >> >>Peace, >>david >> >> > >20040802: > making /dev/(null|zero) into a module proved to be too unpopular, > so this bit has been revoked from the previous (20040801) entry. > >20040801: > The /dev/mem, /dev/io /dev/(null/zero) devices are now modules, > so you may wish to add them to your kernel config file. See > GENERIC for examples. > >I thought the note on 20040802 backed out all the changes referenced in the >note from 20040801, including /dev/io. > >I'll try putting /dev/io in the kernel. > >Thanks > >Tim > > > From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 11:13:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B995F16A4CE; Mon, 9 Aug 2004 11:13:21 +0000 (GMT) Received: from mailout2.barnet.com.au (mailout2.barnet.com.au [218.185.88.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DCA843D46; Mon, 9 Aug 2004 11:13:21 +0000 (GMT) (envelope-from edwin@mavetju.org) Received: by mailout2.barnet.com.au (Postfix, from userid 27) id 3214B70747D; Mon, 9 Aug 2004 21:13:19 +1000 (EST) X-Viruscan-Id: <41175C4F00002074CAF91E@BarNet> Received: from mail2-auth.barnet.com.au (localhost.barnet.com.au [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Authority" (verified OK)) by mail2.barnet.com.au (Postfix) with ESMTP id E5F7A707477; Mon, 9 Aug 2004 21:13:18 +1000 (EST) Received: from k7.mavetju (edwin-3.int.barnet.com.au [10.10.12.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Certificate Authority" (verified OK)) by mail2-auth.barnet.com.au (Postfix) with ESMTP id 28EE270747C; Mon, 9 Aug 2004 21:13:18 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id D0FA061B5; Mon, 9 Aug 2004 21:13:16 +1000 (EST) Date: Mon, 9 Aug 2004 21:13:16 +1000 From: Edwin Groothuis To: David O'Brien Message-ID: <20040809111316.GJ1826@k7.mavetju> References: <410E3AA2.4030800@alumni.rice.edu> <20040809100244.GA17314@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040809100244.GA17314@hub.freebsd.org> User-Agent: Mutt/1.5.6i X-Mailman-Approved-At: Mon, 09 Aug 2004 11:55:19 +0000 cc: current@freebsd.org cc: Oliver Eikemeier Subject: Re: upgrade of file(1) to 4.10 (including FreeBSD elf(5) fixes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 11:13:21 -0000 On Mon, Aug 09, 2004 at 10:02:44AM +0000, David O'Brien wrote: > On Mon, Aug 02, 2004 at 07:59:14AM -0500, Jon Noack wrote: > > On 08/02/04 07:15, Oliver Eikemeier wrote: > > >I've prepared an upgrade to file-4.10 at: > > > > > >This fixes > > > PR bin/63830: [patch] file(1) doesn't recognize FreeBSD 5.x > > >executables properly > > > > > >and an MFC will fix the problems of FreeBSD 4.10 being identified as > > >4.9.1. I'll do some more testing (GCC 3.4) and think we should commit > > >this before the 5.3 src freeze, especially since it has been discussed > > >over a month ago: > > > > > > > *sigh* Why does Christos Zoulas ignore me? He keeps telling me he'll > > include my patch and then includes someone else's that doesn't fix the > > problems. In any case, my patch (against file 4.09) to fix the versioning: > > http://www.noacks.org/freebsd/readelf.c.diff > > > > I made a test program to compare the output. Here's the way things > > would look with file 4.10: > > http://www.noacks.org/freebsd/output-4.10.txt > > This is getting really redicious. Edwin Groothuis > should have never have submitted a patch that hardcoded -CURRENT in 4.08 > and -STABLE in 4.10. And we don't have offical "revisions" (nor > patchlevels, other than security branches), so that output is bad also. Please have a look at http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/freebsd-versions.html , please have a look at /usr/include/sys/param.h and come back with patches if you still have problems. This nonsense has gone on long enough. It will be better if you explain where my thinking went wrong in a constructive way instaed of this constant bickering like old women do. That way we all learn something from it. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://weblog.barnet.com.au/edwin/ From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 12:00:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3C5D16A4D0; Mon, 9 Aug 2004 12:00:08 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 640D243D39; Mon, 9 Aug 2004 12:00:08 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i79C07Hg025017; Mon, 9 Aug 2004 08:00:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i79C07OB004968; Mon, 9 Aug 2004 08:00:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A44BE7303F; Mon, 9 Aug 2004 08:00:07 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040809120007.A44BE7303F@freebsd-current.sentex.ca> Date: Mon, 9 Aug 2004 08:00:07 -0400 (EDT) Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 12:00:09 -0000 TB --- 2004-08-09 11:49:46 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-09 11:49:46 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-08-09 11:49:46 - cleaning the sandbox TB --- 2004-08-09 11:50:48 - checking out the source tree TB --- 2004-08-09 11:50:48 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64 TB --- 2004-08-09 11:50:48 - /usr/bin/cvs -f -R -Q -d/home/ncvs checkout -P -A src TB --- 2004-08-09 11:58:15 - WARNING: /home/tinderbox/sandbox/sparc64.diff does not exist TB --- 2004-08-09 11:58:15 - building world (CFLAGS=-O -pipe) TB --- 2004-08-09 11:58:15 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src TB --- 2004-08-09 11:58:15 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> 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 [...] ===> usr.bin/awk yacc -d -o awkgram.c /tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/awk/../../contrib/one-true-awk/awkgram.y yacc: 43 shift/reduce conflicts yacc: 85 reduce/reduce conflicts ln -sf awkgram.h ytab.h cc -O -pipe -DHAS_ISBLANK -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/awk/../../contrib/one-true-awk -I/home/tinderbox/sandbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/i386/legacy/usr/include -L/home/tinderbox/sandbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/i386/legacy/usr/lib /tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/awk/../../contrib/one-true-awk/maketab.c -o maketab ===> usr.bin/file make: don't know how to make build-tools. Stop *** Error code 2 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-08-09 12:00:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-09 12:00:07 - ERROR: failed to build world TB --- 2004-08-09 12:00:07 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 13:07:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1789416A4CE for ; Mon, 9 Aug 2004 13:07:16 +0000 (GMT) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id A884C43D48 for ; Mon, 9 Aug 2004 13:07:15 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd05.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1Bu9ru-0002Vj-04; Mon, 09 Aug 2004 15:07:14 +0200 Received: from Andro-Beta.Leidinger.net (SgQKO6ZAwe11+atIgQcNdXz40f6Y1mK8zKcY+dN8mkUyumGNSyjpYk@[217.229.208.124]) by fmrl05.sul.t-online.com with esmtp id 1Bu9rn-0aFyoi0; Mon, 9 Aug 2004 15:07:07 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) i79D7BlO033902; Mon, 9 Aug 2004 15:07:11 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Mon, 9 Aug 2004 15:07:54 +0200 From: Alexander Leidinger To: Hannes Mehnert Message-Id: <20040809150754.13ca108a@Magellan.Leidinger.net> In-Reply-To: <20040809112700.GB659@mehnert.org> References: <200408080622.i786Mnhe017474@www1.pochta.ru> <20040808132524.GB1033@mehnert.org> <20040808155623.2fa6fb4b@Magellan.Leidinger.net> <20040809112700.GB659@mehnert.org> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: SgQKO6ZAwe11+atIgQcNdXz40f6Y1mK8zKcY+dN8mkUyumGNSyjpYk@t-dialin.net cc: current@freebsd.org Subject: Re: IPSec + 5.2.current Problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 13:07:16 -0000 On Mon, 9 Aug 2004 13:27:00 +0200 Hannes Mehnert wrote: > > So you're able to transfer data over the tunnel with IPSEC? > > Yes, I'm able to transfer packets with IPSEC and IPSEC_ESP (just > verified this). But I use FAST_IPSEC because i have a soekris vpn1411 > (http://www.soekris.com/vpn1401.htm). > > I also had some problems with IPSEC and IPSEC_ESP, changing require > to use in the policies fixed that. With require racoon was not able > to initiate phase 1, because all non esp traffic was dropped. I think this is a datapoint... I use a "require" policy too. ATM I can't test with "use" instead. Bye, Alexander. -- I'm available to get hired (preferred in .lu). http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 13:25:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AA0616A4D0 for ; Mon, 9 Aug 2004 13:25:13 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id C770443D1F for ; Mon, 9 Aug 2004 13:25:08 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 1773C1FF9A6; Mon, 9 Aug 2004 15:25:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 1604B1FF92F; Mon, 9 Aug 2004 15:25:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 7A99B15384; Mon, 9 Aug 2004 13:21:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 77CB015329; Mon, 9 Aug 2004 13:21:01 +0000 (UTC) Date: Mon, 9 Aug 2004 13:21:01 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Alexander Leidinger In-Reply-To: <20040809150754.13ca108a@Magellan.Leidinger.net> Message-ID: References: <200408080622.i786Mnhe017474@www1.pochta.ru> <20040808132524.GB1033@mehnert.org><20040809112700.GB659@mehnert.org> <20040809150754.13ca108a@Magellan.Leidinger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: Hannes Mehnert cc: FreeBSD current mailing list Subject: Re: IPSec + 5.2.current Problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 13:25:13 -0000 On Mon, 9 Aug 2004, Alexander Leidinger wrote: > On Mon, 9 Aug 2004 13:27:00 +0200 > Hannes Mehnert wrote: > > > > So you're able to transfer data over the tunnel with IPSEC? > > > > Yes, I'm able to transfer packets with IPSEC and IPSEC_ESP (just > > verified this). But I use FAST_IPSEC because i have a soekris vpn1411 > > (http://www.soekris.com/vpn1401.htm). > > > > I also had some problems with IPSEC and IPSEC_ESP, changing require > > to use in the policies fixed that. With require racoon was not able > > to initiate phase 1, because all non esp traffic was dropped. whyever I hadn't seen this posting. > I think this is a datapoint... I use a "require" policy too. ATM I can't > test with "use" instead. but this problem had been fixed months ago for IPSEC. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 13:25:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83FAE16A505 for ; Mon, 9 Aug 2004 13:25:23 +0000 (GMT) Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F0E843D4C for ; Mon, 9 Aug 2004 13:25:23 +0000 (GMT) (envelope-from mike@inbox.lv) Received: from pool0041.cvx28-bradley.dialup.earthlink.net ([209.179.128.41] helo=ringworm.mojavegreen.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1BuA9S-0004YP-00 for freebsd-current@freebsd.org; Mon, 09 Aug 2004 06:25:22 -0700 Received: by ringworm.mojavegreen.com (Postfix, from userid 1001) id CFD22B47DF; Mon, 9 Aug 2004 05:54:21 -0700 (PDT) From: "Michael C. Shultz" To: freebsd-current@freebsd.org Date: Mon, 9 Aug 2004 05:54:16 -0700 User-Agent: KMail/1.6.2 References: <200408071057.06960.ringworm@inbox.lv> <20040808064912.GA27705@les.ath.cx> <200408081730.i78HUN320899@Mail.NOSPAM.DynDNS.dK> In-Reply-To: <200408081730.i78HUN320899@Mail.NOSPAM.DynDNS.dK> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408090554.17355.ringworm@inbox.lv> Subject: Re: Need help: buildworld for CURRENT while under STABLE is not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 13:25:23 -0000 On Sunday 08 August 2004 10:30 am, Barry Bouwsma wrote: > [keep replies to the list and I'll catch up later, thanks] > > > > make buildworld -DDESTDIR=/ad1 while booted from STABLE and I keep > > > getting the following error > > > > Do you get the same error if you run `make buildworld' without > > -DDESTDIR=/ad1 ? > > I get the same error (new, since a successful build or at least > a build way past that point, several days ago). > > is not present in my -stable. I'm able to work around > this requirement in the newly-updated bsnmp by adding the following > dirty hack: > > > --- > /stand/obj/hacks/FreeBSD-CURRENT-src/source-hacks/tools/build/Makefile-ORIG > Mon Mar 1 18:47:38 2004 +++ > /stand/obj/hacks/FreeBSD-CURRENT-src/source-hacks/tools/build/Makefile Sun > Aug 8 18:32:44 2004 @@ -63,6 +63,11 @@ > INCS+= regex.h > .endif > > +### HACK -stable crossbuilds (at least mine) don't have > +.if !exists(/usr/include/stdint.h) > +INCS+= stdint.h > +.endif > + > .if empty(SRCS) > SRCS= dummy.c > .endif > > > > (shoot me if it's /usr/include/something/stdint.h; I don't have a > successful build for any OS in front of me. anyway...) > > For -stable, the mere presence of this file is enough to make the > build progress past this point. Attempting to create a useful > stdint.h file in tools/build didn't quite do the job, so I took > the easy way out. > > Of course someone who knows what they're doing can properly > unbreak crossbuilds on -stable; I can do little more than a hack. > > (whether my build breaks further down the line, time will tell, > my machine is slow and old, like me) > > > thanks > barry bouwsma > I've received much help with this off list. What was suggested and seems to work is to comment out contrib/gensnmptree/gensnmptree.c but I've received another email saying that may cause other problems, anyways my buildworld is still in progress (for 10hrs now). I'm told the author of contrib/gensnmptree/gensnmptree.c ? is aware of the problem so I have no doubt it will be fixed sooner or later. -Mike From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 13:33:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 197C516A4CE for ; Mon, 9 Aug 2004 13:33:13 +0000 (GMT) Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2D4543D54 for ; Mon, 9 Aug 2004 13:33:12 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd11.aul.t-online.de by mailout10.sul.t-online.com with smtp id 1BuAGz-0005ue-03; Mon, 09 Aug 2004 15:33:09 +0200 Received: from Andro-Beta.Leidinger.net (rAFf26ZVge3-Rz-5vu5RVaCgohQxKJZRqqld45pC9Uy3mwBGLss-EP@[217.229.208.124]) by fmrl11.sul.t-online.com with esmtp id 1BuAGk-1ux1hA0; Mon, 9 Aug 2004 15:32:54 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) i79DWvOj037601; Mon, 9 Aug 2004 15:32:57 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Mon, 9 Aug 2004 15:33:41 +0200 From: Alexander Leidinger To: "Bjoern A. Zeeb" Message-Id: <20040809153341.24963cfd@Magellan.Leidinger.net> In-Reply-To: References: <200408080622.i786Mnhe017474@www1.pochta.ru> <20040808132524.GB1033@mehnert.org> <20040808155623.2fa6fb4b@Magellan.Leidinger.net> <20040809112700.GB659@mehnert.org> <20040809150754.13ca108a@Magellan.Leidinger.net> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: rAFf26ZVge3-Rz-5vu5RVaCgohQxKJZRqqld45pC9Uy3mwBGLss-EP@t-dialin.net cc: Hannes Mehnert cc: FreeBSD current mailing list Subject: Re: IPSec + 5.2.current Problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 13:33:13 -0000 On Mon, 9 Aug 2004 13:21:01 +0000 (UTC) "Bjoern A. Zeeb" wrote: > > > I also had some problems with IPSEC and IPSEC_ESP, changing require > > > to use in the policies fixed that. With require racoon was not able > > > to initiate phase 1, because all non esp traffic was dropped. > > whyever I hadn't seen this posting. Did you noticed Message-Id: <20040805223027.7df0732b@Magellan.Leidinger.net> on -current? > > I think this is a datapoint... I use a "require" policy too. ATM I can't > > test with "use" instead. > > but this problem had been fixed months ago for IPSEC. Any other idea for the cause of the observed behavior? Bye, Alexander. -- I'm available to get hired (preferred in .lu). http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 13:48:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C455716A4CE for ; Mon, 9 Aug 2004 13:48:17 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69C1443D2D for ; Mon, 9 Aug 2004 13:48:17 +0000 (GMT) (envelope-from jon.drews@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so108440rnl for ; Mon, 09 Aug 2004 06:48:16 -0700 (PDT) Received: by 10.38.209.1 with SMTP id h1mr386313rng; Mon, 09 Aug 2004 06:48:16 -0700 (PDT) Message-ID: <8cb27cbf0408090648159d34@mail.gmail.com> Date: Mon, 9 Aug 2004 08:48:16 -0500 From: Jon Drews To: freebsd-current@freebsd.org In-Reply-To: <20040809090723.GI642@loge.nixsys.be> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040805071236.GA595@loge.nixsys.be> <20040809090723.GI642@loge.nixsys.be> Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 13:48:17 -0000 Hi Philip: > Which revision of psm.c is this? r1.71 or r1.76? I have r1.76 > Could you also post the 'info*' and 'cap*' lines from a verbose boot? Yes, here is the entire verbose dmesg output: http://www.silbsd.org/bugreports/dmesgVerbose.txt Lines that contained info: acpi_ec0: info: new max delay is 10 us acpi_ec0: info: new max delay is 90 us acpi_ec0: info: new max delay is 110 us acpi_ec0: info: new max delay is 260 us acpi_ec0: info: new max delay is 11000 us No lines contained "cap". > Thanks. It's in -current now by the way. Yes, I saw that when I went to apply the patch. Kind regards, Jonathan From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 13:50:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9859016A4CE for ; Mon, 9 Aug 2004 13:50:08 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B57A43D3F for ; Mon, 9 Aug 2004 13:50:08 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 7FE4B1FFDD8; Mon, 9 Aug 2004 15:50:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 954611FFDD7; Mon, 9 Aug 2004 15:50:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 5E98E15384; Mon, 9 Aug 2004 13:45:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 5BD3215329; Mon, 9 Aug 2004 13:45:52 +0000 (UTC) Date: Mon, 9 Aug 2004 13:45:52 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Alexander Leidinger In-Reply-To: <20040809153341.24963cfd@Magellan.Leidinger.net> Message-ID: References: <200408080622.i786Mnhe017474@www1.pochta.ru> <20040808132524.GB1033@mehnert.org><20040809112700.GB659@mehnert.org> <20040809150754.13ca108a@Magellan.Leidinger.net> <20040809153341.24963cfd@Magellan.Leidinger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: FreeBSD current mailing list Subject: Re: IPSec + 5.2.current Problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 13:50:08 -0000 On Mon, 9 Aug 2004, Alexander Leidinger wrote: > On Mon, 9 Aug 2004 13:21:01 +0000 (UTC) > "Bjoern A. Zeeb" wrote: > > > > > I also had some problems with IPSEC and IPSEC_ESP, changing require > > > > to use in the policies fixed that. With require racoon was not able > > > > to initiate phase 1, because all non esp traffic was dropped. > > > > whyever I hadn't seen this posting. > > Did you noticed Message-Id: > <20040805223027.7df0732b@Magellan.Leidinger.net> on -current? I had seen that mail but I cannot see this paragraph in there. anyway.. > > > > I think this is a datapoint... I use a "require" policy too. ATM I can't > > > test with "use" instead. > > > > but this problem had been fixed months ago for IPSEC. > > Any other idea for the cause of the observed behavior? which on ? use vs. require ? I think this is just not HEAD. your problem: do you really need gif(4) ? if yes - what for ? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 13:54:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C1EC16A4CE for ; Mon, 9 Aug 2004 13:54:52 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 441D743D45 for ; Mon, 9 Aug 2004 13:54:52 +0000 (GMT) (envelope-from jon.drews@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so108653rnl for ; Mon, 09 Aug 2004 06:54:51 -0700 (PDT) Received: by 10.38.78.1 with SMTP id a1mr998820rnb; Mon, 09 Aug 2004 06:54:51 -0700 (PDT) Message-ID: <8cb27cbf0408090654331e3df9@mail.gmail.com> Date: Mon, 9 Aug 2004 08:54:51 -0500 From: Jon Drews To: freebsd-current@freebsd.org In-Reply-To: <411711BD.4040507@raisdorf.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <8cb27cbf04080820246e0e0f49@mail.gmail.com> <411711BD.4040507@raisdorf.net> Subject: Re: (da1:umass-sim1:1:0:0): CAM Status: SCSI Status Error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 13:54:52 -0000 On Mon, 09 Aug 2004 07:55:09 +0200, Hendrik Scholz wrote: > Do you have a memory card in the reader? > Connecting a reader w/o a card resulted in the same error but since > it's USB you have to connect the reader with a card already plugged in. Yes Hendrik: I have one the flat card readers built into the front of the laptop. It's for the memory cards that are used with digital cameras. So that is the cause I suppose. From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 13:55:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA20F16A4CE for ; Mon, 9 Aug 2004 13:55:50 +0000 (GMT) Received: from veldy.net (fuggle.veldy.net [209.98.200.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65DF043D5C for ; Mon, 9 Aug 2004 13:55:50 +0000 (GMT) (envelope-from veldy@veldy.net) Received: from localhost (localhost.veldy.net [127.0.0.1]) by veldy.net (Postfix) with ESMTP id 907326165 for ; Mon, 9 Aug 2004 08:55:49 -0500 (CDT) Received: from veldy.net ([127.0.0.1]) by localhost (fuggle.veldy.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14818-06 for ; Mon, 9 Aug 2004 08:55:46 -0500 (CDT) Received: from [127.0.0.1] (localhost.veldy.net [127.0.0.1]) by veldy.net (Postfix) with ESMTP id 8E6B56164 for ; Mon, 9 Aug 2004 08:55:46 -0500 (CDT) Message-ID: <41178262.4060707@veldy.net> Date: Mon, 09 Aug 2004 08:55:46 -0500 From: "Thomas T. Veldhouse" User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA4F13A7C5230E6864B3A27E6" X-Virus-Scanned: by amavisd-new at veldy.net Subject: options LINPROCFS fails in todays current .... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 13:55:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA4F13A7C5230E6864B3A27E6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit /sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror vers.c linking kernel linprocfs.o(.text+0x3f7): In function `linprocfs_domtab': : undefined reference to `linux_emul_path' linprocfs.o(.text+0x436): In function `linprocfs_domtab': : undefined reference to `linux_emul_path' linprocfs.o(.text+0xabf): In function `linprocfs_doversion': : undefined reference to `linux_get_osname' linprocfs.o(.text+0xad1): In function `linprocfs_doversion': : undefined reference to `linux_get_osrelease' linprocfs.o(.text+0x1fe8): In function `linprocfs_donetdev': : undefined reference to `linux_ifname' *** Error code 1 Stop in /usr/obj/usr/src/sys/CASCADE. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. --------------enigA4F13A7C5230E6864B3A27E6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBF4JlARgTFXYf0wARAnYsAJ9LEEL8XBbNzgOt/leVd9QBzHPL3wCgk+Gw hJ9HSopaQ//l36QsphdOB3E= =AZo3 -----END PGP SIGNATURE----- --------------enigA4F13A7C5230E6864B3A27E6-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 14:11:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7811716A4CE for ; Mon, 9 Aug 2004 14:11:05 +0000 (GMT) Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7DE743D3F for ; Mon, 9 Aug 2004 14:11:04 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd04.aul.t-online.de by mailout01.sul.t-online.com with smtp id 1BuArf-0004Ce-03; Mon, 09 Aug 2004 16:11:03 +0200 Received: from Andro-Beta.Leidinger.net (TJWSq6ZcreHPcCiBM6VbbpFxFQyQE-1u5u4B14q+F+aXR7sRm5lks9@[217.229.208.124]) by fmrl04.sul.t-online.com with esmtp id 1BuArQ-1AWEgS0; Mon, 9 Aug 2004 16:10:48 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) i79EAr05043000; Mon, 9 Aug 2004 16:10:53 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Mon, 9 Aug 2004 16:11:37 +0200 From: Alexander Leidinger To: "Bjoern A. Zeeb" Message-Id: <20040809161137.0bab2d07@Magellan.Leidinger.net> In-Reply-To: References: <200408080622.i786Mnhe017474@www1.pochta.ru> <20040808132524.GB1033@mehnert.org> <20040808155623.2fa6fb4b@Magellan.Leidinger.net> <20040809112700.GB659@mehnert.org> <20040809150754.13ca108a@Magellan.Leidinger.net> <20040809153341.24963cfd@Magellan.Leidinger.net> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: TJWSq6ZcreHPcCiBM6VbbpFxFQyQE-1u5u4B14q+F+aXR7sRm5lks9@t-dialin.net cc: FreeBSD current mailing list Subject: Re: IPSec + 5.2.current Problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 14:11:05 -0000 On Mon, 9 Aug 2004 13:45:52 +0000 (UTC) "Bjoern A. Zeeb" wrote: > On Mon, 9 Aug 2004, Alexander Leidinger wrote: > > > On Mon, 9 Aug 2004 13:21:01 +0000 (UTC) > > "Bjoern A. Zeeb" wrote: > > > > > > > I also had some problems with IPSEC and IPSEC_ESP, changing require > > > > > to use in the policies fixed that. With require racoon was not able > > > > > to initiate phase 1, because all non esp traffic was dropped. > > > > > > whyever I hadn't seen this posting. > > > > Did you noticed Message-Id: > > <20040805223027.7df0732b@Magellan.Leidinger.net> on -current? > > I had seen that mail but I cannot see this paragraph in there. anyway.. It's another thread without any discussion. > > > > I think this is a datapoint... I use a "require" policy too. ATM I can't > > > > test with "use" instead. > > > > > > but this problem had been fixed months ago for IPSEC. > > > > Any other idea for the cause of the observed behavior? > > which on ? use vs. require ? I think this is just not HEAD. In my case it's -current from Jul 18. > your problem: do you really need gif(4) ? if yes - what for ? In my case the problem doesn't matter, since using FAST_IPSEC works for me. But I think it should be fixed for 5.3. As you can see in the above mentioned mail, I converted a 4.x system to -current. On 4.x I've used gif for a tunnel (as documented in the handbook) between the FreeBSD system and a VPN appliance which isn't under my control. Is there another way to setup a tunnel in -current? Bye, Alexander. -- I'm available to get hired (preferred in .lu). http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 14:24:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 801CD16A4CE for ; Mon, 9 Aug 2004 14:24:40 +0000 (GMT) Received: from mediamonks.com (siripandita.mediamonks.net [62.192.127.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 120B143D55 for ; Mon, 9 Aug 2004 14:24:39 +0000 (GMT) (envelope-from root@mediamonks.net) Received: from manrikigusari [217.19.28.156] by mediamonks.com with ESMTP (SMTPD32-8.12) id A921D700A8; Mon, 09 Aug 2004 16:24:33 +0200 From: "Terrence Koeman" To: Date: Mon, 9 Aug 2004 16:24:29 +0200 Organization: MediaMonks B.V. MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcR9niuWTPfI/s1FTLqZmZuDbUFVqw== Message-Id: <200408091624384.SM01804@manrikigusari> X-Info: This e-mail was scanned for spam and viruses by mail.mediamonks.net. X-Info: Please send abuse reports about this e-mail to abuse@mediamonks.net. Subject: Compiler segmentation fault in 5-08 -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: root@mediamonks.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 14:24:40 -0000 Hi, I recently upgraded world and kernel to the 5 august -CURRENT, and now nearly anything that requires a compiler fails. Something is broken, and I can't figure out what it is, is this a bug or did I screw up while upgrading? I read the note about a new compiler in /usr/src/UPDATING, but I didn't think this would require some special steps for the base system to work. Please advice. For instance buildworld: ################################################ -------------------------------------------------------------- >>> stage 1.2: bootstrap tools -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/i386 DESTDIR= INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/src/i386/legacy/usr/ bin:/usr/obj/usr/src/i386/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/src/i386 MAKEFLAGS="-m /usr/src/tools/build/mk -m /usr/src/share/mk " make -f Makefile.inc1 BOOTSTRAPPING=502119 -DNOHTML -DNOINFO -DNOLINT -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -DNO_CPU_CFLAGS -DNO_WARNS bootstrap-tools ===> games/fortune/strfile /usr/obj/usr/src/i386/usr/src/games/fortune/strfile created for /usr/src/games/fortune/strfile rm -f .depend mkdep -f .depend -a -I/usr/obj/usr/src/i386/legacy/usr/include /usr/src/games/fortune/strfile/strfile.c echo strfile: /usr/lib/libc.a /usr/obj/usr/src/i386/legacy/usr/lib/libegacy.a >> .depend cc -O -pipe -I/usr/obj/usr/src/i386/legacy/usr/include -c /usr/src/games/fortune/strfile/strfile.c /usr/src/games/fortune/strfile/strfile.c: In function `main': /usr/src/games/fortune/strfile/strfile.c:164: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /usr/src/games/fortune/strfile. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ################################################ buildkernel: ################################################ -------------------------------------------------------------- >>> stage 2.3: build tools -------------------------------------------------------------- cd /usr/obj/usr/src/sys/DHAMMAPADA; MAKESRCPATH=/usr/src/sys/dev/aic7xxx/aicasm make -DNO_CPU_CFLAGS -f /usr/src/sys/dev/aic7xxx/aicasm/Makefile Warning: Object directory not changed from original /usr/obj/usr/src/sys/DHAMMAPADA cc -O -pipe -nostdinc -I/usr/include -I. -I/usr/src/sys/dev/aic7xxx/aicasm -c /usr/src/sys/dev/aic7xxx/aicasm/aicasm.c /usr/src/sys/dev/aic7xxx/aicasm/aicasm.c: In function `main': /usr/src/sys/dev/aic7xxx/aicasm/aicasm.c:171: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /usr/obj/usr/src/sys/DHAMMAPADA. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ################################################ mod_php4: ################################################ checking whether make sets ${MAKE}... yes checking for gcc... cc checking for C compiler default output... configure: error: C compiler cannot create executables check `config.log' for details. ===> Script "configure" failed unexpectedly. Please report the problem to ports@FreeBSD.org [maintainer] and attach the "/usr/ports/devel/bison/work/bison-1.75/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/devel/bison. *** Error code 1 Stop in /usr/ports/www/mod_php4. ################################################ config.log contains: ################################################ configure:1976: cc --version &5 cc (GCC) 3.4.2 [FreeBSD] 20040728 Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:1979: $? = 0 configure:1981: cc -v &5 Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.2 [FreeBSD] 20040728 configure:1984: $? = 0 configure:1986: cc -V &5 cc: `-V' option must have argument configure:1989: $? = 1 configure:2009: checking for C compiler default output configure:2012: cc -O -pipe -march=pentiumpro -I/usr/local/include -L/usr/local/lib conftest.c >&5 configure: In function `main': configure:2001: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. configure:2015: $? = 1 configure: failed program was: #line 1993 "configure" #include "confdefs.h" int main () { ; return 0; } configure:2052: error: C compiler cannot create executables check `config.log' for details. ################################################ -- Regards, Terrence Koeman MediaMonks B.V. (www.mediamonks.com) Please quote all replies in correspondence. From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 14:30:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFC6B16A4D4 for ; Mon, 9 Aug 2004 14:30:31 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2316143D39 for ; Mon, 9 Aug 2004 14:30:09 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 545D91FFDD4; Mon, 9 Aug 2004 16:30:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 47ECB1FF90C; Mon, 9 Aug 2004 16:30:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 6F2AC15384; Mon, 9 Aug 2004 14:27:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 6459215329; Mon, 9 Aug 2004 14:27:49 +0000 (UTC) Date: Mon, 9 Aug 2004 14:27:49 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Alexander Leidinger In-Reply-To: <20040809161137.0bab2d07@Magellan.Leidinger.net> Message-ID: References: <200408080622.i786Mnhe017474@www1.pochta.ru> <20040808132524.GB1033@mehnert.org><20040809112700.GB659@mehnert.org> <20040809150754.13ca108a@Magellan.Leidinger.net> <20040809153341.24963cfd@Magellan.Leidinger.net> <20040809161137.0bab2d07@Magellan.Leidinger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: FreeBSD current mailing list Subject: Re: IPSec + 5.2.current Problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 14:30:32 -0000 On Mon, 9 Aug 2004, Alexander Leidinger wrote: > > which on ? use vs. require ? I think this is just not HEAD. > > In my case it's -current from Jul 18. and use vs. require does make a difference for you ? > > your problem: do you really need gif(4) ? if yes - what for ? > > In my case the problem doesn't matter, since using FAST_IPSEC works for > me. But I think it should be fixed for 5.3. the MSIZE= should really be fixed I think, yes. > As you can see in the above mentioned mail, I converted a 4.x system to > -current. On 4.x I've used gif for a tunnel (as documented in the > handbook) I will have to read this. Nether had to use gif(4) with IPsec on the 4.[7-*] machines I co-configered. Perhaps the handbook is just outdated. > between the FreeBSD system and a VPN appliance which isn't > under my control. Is there another way to setup a tunnel in -current? only use IPSec w/o gif(4). gif(4) is currently needed for few things - IPv6 with FAST_IPSEC - running s.th. like a link bound routing protocol over IPsec (I think) That's what I can think of at the moment. but take care - whatever your applicance on the other side does and how it had worked up to now ... -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 14:34:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 155A916A4CE for ; Mon, 9 Aug 2004 14:34:25 +0000 (GMT) Received: from moo.sysabend.org (moo.sysabend.org [66.111.41.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8B4643D41 for ; Mon, 9 Aug 2004 14:34:24 +0000 (GMT) (envelope-from ragnar@sysabend.org) Received: by moo.sysabend.org (Postfix, from userid 1004) id 602FEFB; Mon, 9 Aug 2004 07:34:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by moo.sysabend.org (Postfix) with ESMTP id 5EFF2B0; Mon, 9 Aug 2004 07:34:24 -0700 (PDT) Date: Mon, 9 Aug 2004 07:34:24 -0700 (PDT) From: Jamie Bowden To: Arne Schwabe In-Reply-To: <86n0188cfa.fsf@kamino.rfc1149.org> Message-ID: <20040809072854.I22209-100000@moo.sysabend.org> X-representing: Only myself. X-badge: We don't need no stinking badges. X-obligatory-profanity: Fuck X-moo: Moo. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 14:34:25 -0000 On Fri, 6 Aug 2004, Arne Schwabe wrote: > Philip Paeps writes: > > Hi gang :-) > > Since the original synaptics support was added to psm, there have been > > some reports of malfunctions and missing magic. I've tried to fix all > > that, but it's still work in progress. > > If you happen to own a laptop with a synaptics touchpad, please help > > test: > > > Not using the stick would be masochistic in my opinion ;) And some of us are of a diametricly opposed opinion. > Anyway pressing buttons of the touchpad and moving the stick gives > _strange_ effects but I think this time I motivate myself by not using > the synaptics XFree86 driver, so either I fix it or my mouse is broken > :) What I want to know is if this addition gives the ability to turn tapping, and the added features off. I hate having inadvertant changes in pressure be interpreted by the mouse driver as a tap. It's hugely annoying, and the first thing I do in Windows is turn all of it off. I want the pad to track position deltas, and when I want to push a button, I'll push a button. If I want to scroll around, I mouse over to a scroll bar, push a button, and move the mouse. That's another bunch of shit that immediately gets turned off in winodws. Software that attempts to be smarter than the user never is. Jamie Bowden -- "It was half way to Rivendell when the drugs began to take hold" Hunter S Tolkien "Fear and Loathing in Barad Dur" Iain Bowen From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 16:13:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6571616A4CE for ; Mon, 9 Aug 2004 16:13:46 +0000 (GMT) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1153943D1D for ; Mon, 9 Aug 2004 16:13:46 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id i79GDjtd084206 for ; Mon, 9 Aug 2004 12:13:45 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca ([127.0.0.1]) by localhost (avscan1.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 83451-08 for ; Mon, 9 Aug 2004 12:13:44 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id i79GDiDg084189 for ; Mon, 9 Aug 2004 12:13:44 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i79GDcgQ069547 for ; Mon, 9 Aug 2004 12:13:38 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.1.2.0.0.20040809120635.08c4d090@64.7.153.2> X-Sender: mdtpop@64.7.153.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 09 Aug 2004 12:17:22 -0400 To: freebsd-current@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan1b Subject: VIA C3 AES code ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 16:13:46 -0000 Has anyone looked at making use of Via's ACE/AES encryption on FreeBSD ? (e.g. http://www.via.com.tw/en/viac3/padlock.jsp). OpenBSD has some patches to OpenSSL that will make use of the CPU's extra features. I think they make use of it as well for their IPSEC. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 16:41:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D729C16A4CE for ; Mon, 9 Aug 2004 16:41:03 +0000 (GMT) Received: from CPE000103d44c07-CM000f9f7ae88c.cpe.net.cable.rogers.com (CPE000103d44c07-CM000f9f7ae88c.cpe.net.cable.rogers.com [69.193.43.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E42043D39 for ; Mon, 9 Aug 2004 16:41:03 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from localhost (localhost [127.0.0.1]) with ESMTP id 611FC29542B for ; Mon, 9 Aug 2004 12:41:01 -0400 (EDT) Received: from CPE000103d44c07-CM000f9f7ae88c.cpe.net.cable.rogers.com ([127.0.0.1])10024) with ESMTP id 20771-08 for ; Mon, 9 Aug 2004 12:40:58 -0400 (EDT) Received: from cpe000103d44c07-cm000f9f7ae88c.cpe.net.cable.rogers.com (localhost [127.0.0.1])with ESMTP id DEE69295429 for ; Mon, 9 Aug 2004 12:40:57 -0400 (EDT) Received: from 66.11.183.182 (SquirrelMail authenticated user mikej); by cpe000103d44c07-cm000f9f7ae88c.cpe.net.cable.rogers.com with HTTP; Mon, 9 Aug 2004 12:40:57 -0400 (EDT) Message-ID: <1719.66.11.183.182.1092069657.squirrel@66.11.183.182> Date: Mon, 9 Aug 2004 12:40:57 -0400 (EDT) From: "Mike Jakubik" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at fbsd.wettoast.net Subject: PCI interrupt routing messages in boot (and stray irq 9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 16:41:04 -0000 Hello, I have recently obtained a dual Xeon supermicro system (MB# X5DP8-G2). Installed 5.2.1, and cvsupped to -current. I get the following messages when booting, that have me worried: pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.HLB_ - AE_NOT_FOUND pcib4: could not get PCI interrupt routing table for \\_SB_.PCI0.HLC_ - AE_NOT_FOUND Are these ok to ignore? I also get a weird message when shutting down the server, after the disks sync, and the shutting down ACPI message comes up, the following is displayed "stray irq9", which is assigned to ACPI. Below is a complete dmesg. Thanks. --- Copyright (c) 1992-2004 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 5.2-CURRENT #0: Mon Aug 9 12:08:00 EDT 2004 root@mail.xxx.com:/usr/obj/usr/src/sys/MAIL ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2799.21-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf25 Stepping = 5 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 2146959360 (2047 MB) avail memory = 2099777536 (2002 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard ioapic3 irqs 72-95 on motherboard ioapic4 irqs 96-119 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [GIANT-LOCKED] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pcib1: at device 2.0 on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.HLB_ - AE_NOT_FOUND pci1: on pcib1 pci1: at device 28.0 (no driver attached) pcib2: at device 29.0 on pci1 pci2: on pcib2 pci1: at device 30.0 (no driver attached) pcib3: at device 31.0 on pci1 pci3: on pcib3 em0: port 0x3000-0x303f mem 0xf8200000-0xf821ffff irq 28 at device 2.0 on pci3 em0: [GIANT-LOCKED] em0: Ethernet address: 00:30:48:2a:c0:ee em0: Speed:N/A Duplex:N/A em1: port 0x3040-0x307f mem 0xf8220000-0xf823ffff irq 29 at device 2.1 on pci3 em1: [GIANT-LOCKED] em1: Ethernet address: 00:30:48:2a:c0:ef em1: Speed:N/A Duplex:N/A pcib4: at device 3.0 on pci0 pcib4: could not get PCI interrupt routing table for \\_SB_.PCI0.HLC_ - AE_NOT_FOUND pci4: on pcib4 pci4: at device 28.0 (no driver attached) pcib5: at device 29.0 on pci4 pci5: on pcib5 pci4: at device 30.0 (no driver attached) pcib6: at device 31.0 on pci4 pci6: on pcib6 asr0: mem 0xfc000000-0xfdffffff,0xfb000000-0xfbffffff,0xf8400000-0xf84fffff irq 72 at device 1.0 on pci6 asr0: [GIANT-LOCKED] asr0: ADAPTEC 2010S FW Rev. 3B0A, 2 channel, 256 CCBs, Protocol I2O uhci0: port 0x2000-0x201f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x2020-0x203f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x2040-0x205f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pcib7: at device 30.0 on pci0 pci7: on pcib7 pci7: at device 1.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x2060-0x206f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port orm0: at iomem 0xe0000-0xe3fff,0xc9000-0xcefff,0xc8000-0xc8fff,0xc0000-0xc7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 10.000 msec ATAPI_RESET time = 370us acd0: CDROM at ata1-master UDMA33 ses0 at asr0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: SAF-TE Compliant Device SMP: AP CPU #1 Launched! da0 at asr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: Tagged Queueing Enabled da0: 70006MB (143372288 512 byte sectors: 255H 63S/T 8924C) Mounting root from ufs:/dev/da0s1a em0: Link is up 100 Mbps Full Duplex From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 16:54:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C66C16A4CF for ; Mon, 9 Aug 2004 16:54:10 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B75943D48 for ; Mon, 9 Aug 2004 16:54:08 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by mproxy.gmail.com with SMTP id 75so106201rnl for ; Mon, 09 Aug 2004 09:54:01 -0700 (PDT) Received: by 10.38.86.74 with SMTP id j74mr786690rnb; Mon, 09 Aug 2004 09:54:01 -0700 (PDT) Message-ID: Date: Tue, 10 Aug 2004 00:54:01 +0800 From: Jiawei Ye To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: kldload pf failed on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 16:54:10 -0000 root@chihiro:/usr/src# kldload -v pf kldload: can't load pf: No such file or directory root@chihiro:/usr/src# kldload /boot/kernel/pf.ko root@chihiro:/usr/src# /etc/rc.d/pf restart Enabling pf. pf enabled Somehow kldload cannot find pf.ko if no specific path is given. This is a 2 hours old -current. Jiawei From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 17:09:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 758F716A4CE for ; Mon, 9 Aug 2004 17:09:32 +0000 (GMT) Received: from otter3.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D633A43D4C for ; Mon, 9 Aug 2004 17:09:31 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by otter3.centtech.com (8.12.3/8.12.3) with ESMTP id i79H9VCw029832; Mon, 9 Aug 2004 12:09:31 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4117AFC4.5090801@centtech.com> Date: Mon, 09 Aug 2004 12:09:24 -0500 From: Eric Anderson User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Tancsa References: <6.1.2.0.0.20040809120635.08c4d090@64.7.153.2> In-Reply-To: <6.1.2.0.0.20040809120635.08c4d090@64.7.153.2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: VIA C3 AES code ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 17:09:32 -0000 Mike Tancsa wrote: > > Has anyone looked at making use of Via's ACE/AES encryption on FreeBSD > ? (e.g. http://www.via.com.tw/en/viac3/padlock.jsp). OpenBSD has some > patches to OpenSSL that will make use of the CPU's extra features. I > think they make use of it as well for their IPSEC. I think Mark Murray was working on getting it into -current. I think it is either there already, or should be there by 5.3. He has more details I'm sure.. Eric -- ------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Talk sense to a fool and he calls you foolish. ------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 17:30:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B843316A4CE for ; Mon, 9 Aug 2004 17:30:00 +0000 (GMT) Received: from afields.ca (afields.ca [216.194.67.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5ED8843D31 for ; Mon, 9 Aug 2004 17:30:00 +0000 (GMT) (envelope-from afields@afields.ca) Received: from afields.ca (localhost.afields.ca [127.0.0.1]) by afields.ca (8.12.11/8.12.11) with ESMTP id i79HTxoO009069; Mon, 9 Aug 2004 13:29:59 -0400 (EDT) (envelope-from afields@afields.ca) Received: (from afields@localhost) by afields.ca (8.12.11/8.12.11/Submit) id i79HTxnf009068; Mon, 9 Aug 2004 13:29:59 -0400 (EDT) (envelope-from afields) Date: Mon, 9 Aug 2004 13:29:59 -0400 From: Allan Fields To: Jon Drews Message-ID: <20040809172959.GA7838@afields.ca> References: <8cb27cbf04080820246e0e0f49@mail.gmail.com> <411711BD.4040507@raisdorf.net> <8cb27cbf0408090654331e3df9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8cb27cbf0408090654331e3df9@mail.gmail.com> User-Agent: Mutt/1.4i cc: freebsd-current@freebsd.org Subject: Re: (da1:umass-sim1:1:0:0): CAM Status: SCSI Status Error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 17:30:00 -0000 On Mon, Aug 09, 2004 at 08:54:51AM -0500, Jon Drews wrote: > On Mon, 09 Aug 2004 07:55:09 +0200, Hendrik Scholz wrote: > > > Do you have a memory card in the reader? > > Connecting a reader w/o a card resulted in the same error but since > > it's USB you have to connect the reader with a card already plugged in. > > Yes Hendrik: > > I have one the flat card readers built into the front of the laptop. > It's for the memory cards that are used with digital cameras. So that > is the cause I suppose. I get the same w/ my multi-card USB reader which prints out 4x the messages for each flash type: MMC/SD, SmartMedia, Memory Stick, CompactFlash. It's normal to see that as it emulates SCSI, so cam tries to query the devices at boot and finds no media. The setup works OK, but has caused panics in the past (when device is by accident disconnected from USB, then umount). -- Allan Fields, AFRSL - http://afields.ca 2D4F 6806 D307 0889 6125 C31D F745 0D72 39B4 5541 From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 17:31:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C98A16A4CE for ; Mon, 9 Aug 2004 17:31:16 +0000 (GMT) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46AEA43D4C for ; Mon, 9 Aug 2004 17:31:16 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) i79HVFsF003734; Mon, 9 Aug 2004 10:31:15 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.12.11/8.12.11/Submit) id i79HVFCY003733; Mon, 9 Aug 2004 10:31:15 -0700 (PDT) (envelope-from david) Date: Mon, 9 Aug 2004 10:31:15 -0700 (PDT) From: David Wolfskill Message-Id: <200408091731.i79HVFCY003733@bunrab.catwhisker.org> To: current@freebsd.org, david@catwhisker.org In-Reply-To: <200408081849.i78InffL001243@bunrab.catwhisker.org> Subject: Re: ATA issues: ad0: FAILURE - ATA_IDENTIFY no interrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 17:31:16 -0000 OK; whatever was causing the problem appears to have been fixed in the commits during the following 30 hrs.: freebeast(5.2-C)[1] uname -a FreeBSD freebeast.catwhisker.org 5.2-CURRENT FreeBSD 5.2-CURRENT #44: Mon Aug 9 10:05:07 PDT 2004 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/FREEBEAST i386 freebeast(5.2-C)[2] tail /var/log/cvsup-history.log CVSup begin from cvsup12.freebsd.org at Sun Aug 8 01:47:16 PDT 2004 CVSup ended from cvsup12.freebsd.org at Sun Aug 8 01:53:22 PDT 2004 CVSup begin from cvsup14.freebsd.org at Sun Aug 8 03:47:02 PDT 2004 CVSup ended from cvsup14.freebsd.org at Sun Aug 8 03:52:31 PDT 2004 CVSup begin from cvsup14.freebsd.org at Mon Aug 9 01:47:05 PDT 2004 CVSup ended from cvsup14.freebsd.org at Mon Aug 9 01:54:34 PDT 2004 CVSup begin from cvsup14.freebsd.org at Mon Aug 9 03:47:02 PDT 2004 CVSup ended from cvsup14.freebsd.org at Mon Aug 9 03:52:53 PDT 2004 CVSup begin from cvsup12.freebsd.org at Mon Aug 9 06:27:36 PDT 2004 CVSup ended from cvsup12.freebsd.org at Mon Aug 9 06:33:25 PDT 2004 freebeast(5.2-C)[3] [Catalyst for the manual CVSup @06:27 was to fix the make: don't know how to make build-tools. Stop issue -- which, I note, it did.] Peace, david -- David H. Wolfskill david@catwhisker.org I do not "unsubscribe" from email "services" to which I have not explicitly subscribed. Rather, I block spammers' access to SMTP servers I control, and encourage others who are in a position to do so to do likewise. From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 17:41:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F033216A4CE for ; Mon, 9 Aug 2004 17:41:12 +0000 (GMT) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71CA443D58 for ; Mon, 9 Aug 2004 17:41:12 +0000 (GMT) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) i79HeqAq023538; Mon, 9 Aug 2004 18:40:52 +0100 (BST) (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost)i79Heprx023537; Mon, 9 Aug 2004 18:40:51 +0100 (BST) (envelope-from mark@grondar.org) X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1])i79HcI89009474; Mon, 9 Aug 2004 18:38:18 +0100 (BST) (envelope-from mark@grondar.org) Message-Id: <200408091738.i79HcI89009474@grimreaper.grondar.org> To: Eric Anderson From: Mark Murray In-Reply-To: Your message of "Mon, 09 Aug 2004 12:09:24 CDT." <4117AFC4.5090801@centtech.com> Date: Mon, 09 Aug 2004 18:38:18 +0100 Sender: mark@grondar.org cc: freebsd-current@FreeBSD.ORG cc: Mike Tancsa Subject: Re: VIA C3 AES code ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 17:41:13 -0000 Eric Anderson writes: > Mike Tancsa wrote: > > > > > Has anyone looked at making use of Via's ACE/AES encryption on FreeBSD > > ? (e.g. http://www.via.com.tw/en/viac3/padlock.jsp). OpenBSD has some > > patches to OpenSSL that will make use of the CPU's extra features. I > > think they make use of it as well for their IPSEC. > > I think Mark Murray was working on getting it into -current. I think it > is either there already, or should be there by 5.3. He has more details > I'm sure.. Yup. It will be in 5.3. :-) M -- Mark Murray iumop ap!sdn w,I idlaH From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 17:56:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D75F216A4CE; Mon, 9 Aug 2004 17:56:47 +0000 (GMT) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78D2143D2D; Mon, 9 Aug 2004 17:56:47 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id i79HukR9015767; Mon, 9 Aug 2004 13:56:46 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca ([127.0.0.1]) by localhost (avscan1.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15402-05; Mon, 9 Aug 2004 13:56:46 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id i79Huk9O015759; Mon, 9 Aug 2004 13:56:46 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i79HudXU069820; Mon, 9 Aug 2004 13:56:39 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.1.2.0.0.20040809134944.058d4098@64.7.153.2> X-Sender: mdtpop@64.7.153.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 09 Aug 2004 14:01:18 -0400 To: Mark Murray From: Mike Tancsa In-Reply-To: <200408091738.i79HcI89009474@grimreaper.grondar.org> References: <200408091738.i79HcI89009474@grimreaper.grondar.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan1b cc: freebsd-current@FreeBSD.ORG Subject: Re: VIA C3 AES code ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 17:56:48 -0000 At 01:38 PM 09/08/2004, Mark Murray wrote: >Eric Anderson writes: > > Mike Tancsa wrote: > > > > > > > > Has anyone looked at making use of Via's ACE/AES encryption on FreeBSD > > > ? (e.g. http://www.via.com.tw/en/viac3/padlock.jsp). OpenBSD has some > > > patches to OpenSSL that will make use of the CPU's extra features. I > > > think they make use of it as well for their IPSEC. > > > > I think Mark Murray was working on getting it into -current. I think it > > is either there already, or should be there by 5.3. He has more details > > I'm sure.. > >Yup. It will be in 5.3. :-) Neato! Is this more than just the HRNG support ? ie will there be support for crypto offloading in OpenSSL or more ? How far along are you in it ? ---Mike From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 17:59:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D25816A4CE for ; Mon, 9 Aug 2004 17:59:12 +0000 (GMT) Received: from lakermmtao09.cox.net (lakermmtao09.cox.net [68.230.240.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9B2043D3F for ; Mon, 9 Aug 2004 17:59:11 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.71.51]) by lakermmtao09.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040809175909.EZJX20883.lakermmtao09.cox.net@dolphin.local.net> for ; Mon, 9 Aug 2004 13:59:09 -0400 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with ESMTP id i79HxAK3026941 for ; Mon, 9 Aug 2004 12:59:10 -0500 (CDT) (envelope-from conrads@dolphin.local.net) Received: (from conrads@localhost) by dolphin.local.net (8.13.1/8.13.1/Submit) id i79Hx5RP026940 for freebsd-current@freebsd.org; Mon, 9 Aug 2004 12:59:05 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Mon, 09 Aug 2004 12:59:05 -0500 (CDT) Organization: A Rag-Tag Band of Drug-Crazed Hippies From: "Conrad J. Sabatier" To: freebsd-current@freebsd.org Subject: Is anything being done re: the pcm timeout issue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conrads@cox.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 17:59:12 -0000 Sound has been broken now for I don't know how long. My machine's pcm device can be counted on to break, sometimes after only a very short period of usage after a reboot (which is the only way to get sound working again). This is getting extremely frustrating. Is anyone working on this at all? -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 18:05:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49D0D16A4CF for ; Mon, 9 Aug 2004 18:05:22 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAC0043D49 for ; Mon, 9 Aug 2004 18:05:21 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BuEWP-00048v-00; Mon, 09 Aug 2004 20:05:21 +0200 Received: from [217.227.146.85] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BuEWO-0007Aq-00; Mon, 09 Aug 2004 20:05:20 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Mon, 9 Aug 2004 20:03:22 +0200 User-Agent: KMail/1.6.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_wx7FB6/kXpNtL1u"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408092003.28922.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Jiawei Ye Subject: Re: kldload pf failed on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 18:05:22 -0000 --Boundary-02=_wx7FB6/kXpNtL1u Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 09 August 2004 18:54, Jiawei Ye wrote: > root@chihiro:/usr/src# kldload -v pf > kldload: can't load pf: No such file or directory > root@chihiro:/usr/src# kldload /boot/kernel/pf.ko > root@chihiro:/usr/src# /etc/rc.d/pf restart > Enabling pf. > pf enabled > > Somehow kldload cannot find pf.ko if no specific path is given. This > is a 2 hours old -current. Sounds like kldxref didn't finish it's job correctly. Try (as root): kldxref /boot/kernel /boot/modules and check the output of: kldxref -dv /boot/kernel for proper pf.ko entries. Please tell me if that did not help or if you see= =20 anything suspicious in the xref dump. There have been some changes to the src top-level Makefiles, might be worth= =20 looking at if the final kldxref got lost somewhere. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_wx7FB6/kXpNtL1u Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBF7xwXyyEoT62BG0RAmsUAJ9an6xul/2uwuWpjZQLU0eHt+LRjACdGyHl SxozL7GN7OAXJZnA3nkmAOI= =KvhH -----END PGP SIGNATURE----- --Boundary-02=_wx7FB6/kXpNtL1u-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 18:15:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1264A16A4FB; Mon, 9 Aug 2004 18:15:48 +0000 (GMT) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DD1743D48; Mon, 9 Aug 2004 18:15:47 +0000 (GMT) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) i79IFjrt024152; Mon, 9 Aug 2004 19:15:45 +0100 (BST) (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost)i79IFjw5024151; Mon, 9 Aug 2004 19:15:45 +0100 (BST) (envelope-from mark@grondar.org) X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1])i79IEjjv009798; Mon, 9 Aug 2004 19:14:45 +0100 (BST) (envelope-from mark@grondar.org) Message-Id: <200408091814.i79IEjjv009798@grimreaper.grondar.org> To: Mike Tancsa From: Mark Murray In-Reply-To: Your message of "Mon, 09 Aug 2004 14:01:18 EDT." <6.1.2.0.0.20040809134944.058d4098@64.7.153.2> Date: Mon, 09 Aug 2004 19:14:45 +0100 Sender: mark@grondar.org cc: freebsd-current@FreeBSD.ORG cc: Mark Murray Subject: Re: VIA C3 AES code ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 18:15:51 -0000 Mike Tancsa writes: > Neato! Is this more than just the HRNG support ? ie will there be support > for crypto offloading in OpenSSL or more ? How far along are you in it ? Yup. It means that if you ask OpenSSL for AES encryptionon a C3 Nehemiah, you get the full HW speed. In-kernel stuff is more involved, and as IPSEC is in poor shape, not too well tested. M -- Mark Murray iumop ap!sdn w,I idlaH From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 18:21:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A25DF16A4CE for ; Mon, 9 Aug 2004 18:21:38 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CCA143D49 for ; Mon, 9 Aug 2004 18:21:38 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.11/8.12.11) id i79ILQCr008114; Mon, 9 Aug 2004 13:21:26 -0500 (CDT) (envelope-from dan) Date: Mon, 9 Aug 2004 13:21:26 -0500 From: Dan Nelson To: "Conrad J. Sabatier" Message-ID: <20040809182126.GC4216@dan.emsphone.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.2-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: Is anything being done re: the pcm timeout issue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 18:21:38 -0000 In the last episode (Aug 09), Conrad J. Sabatier said: > Sound has been broken now for I don't know how long. My machine's > pcm device can be counted on to break, sometimes after only a very > short period of usage after a reboot (which is the only way to get > sound working again). Sound works fine for me on my Dell laptop (mss driver). I do get a mutex-related panic on my desktop (sb16 driver), but haven't sent in the stack trace to anyone yet. > This is getting extremely frustrating. Is anyone working on this at > all? -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 18:40:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98E0E16A4CF for ; Mon, 9 Aug 2004 18:40:14 +0000 (GMT) Received: from lakermmtao08.cox.net (lakermmtao08.cox.net [68.230.240.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3080943D41 for ; Mon, 9 Aug 2004 18:40:14 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.71.51]) by lakermmtao08.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040809184013.LIGQ2852.lakermmtao08.cox.net@dolphin.local.net>; Mon, 9 Aug 2004 14:40:13 -0400 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with ESMTP id i79IeDR8096319; Mon, 9 Aug 2004 13:40:13 -0500 (CDT) (envelope-from conrads@dolphin.local.net) Received: (from conrads@localhost) by dolphin.local.net (8.13.1/8.13.1/Submit) id i79Ie7AD096310; Mon, 9 Aug 2004 13:40:07 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20040809182126.GC4216@dan.emsphone.com> Date: Mon, 09 Aug 2004 13:40:07 -0500 (CDT) Organization: A Rag-Tag Band of Drug-Crazed Hippies From: "Conrad J. Sabatier" To: Dan Nelson cc: freebsd-current@freebsd.org Subject: Re: Is anything being done re: the pcm timeout issue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conrads@cox.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 18:40:14 -0000 On 09-Aug-2004 Dan Nelson wrote: > In the last episode (Aug 09), Conrad J. Sabatier said: >> Sound has been broken now for I don't know how long. My machine's >> pcm device can be counted on to break, sometimes after only a very >> short period of usage after a reboot (which is the only way to get >> sound working again). > > Sound works fine for me on my Dell laptop (mss driver). I do get a > mutex-related panic on my desktop (sb16 driver), but haven't sent in > the stack trace to anyone yet. My problems are occurring on an amd64 box (Athlon 64) with the nVidia nForce3 chipset (snd_ich driver). Sounds works fine for a while, then suddenly I get a pcm play timeout, and game over. Have to reboot to get sound to work again. Others have reported similar problems, but I've seen no followups indicating anything is being done about it. >> This is getting extremely frustrating. Is anyone working on this at >> all? -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 18:46:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AE4416A5AF for ; Mon, 9 Aug 2004 18:46:18 +0000 (GMT) Received: from tethys.ringofsaturn.com (tethys.ringofsaturn.com [66.13.175.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E59543D31 for ; Mon, 9 Aug 2004 18:46:17 +0000 (GMT) (envelope-from rnejdl@ringofsaturn.com) Received: from mail.ringofsaturn.com (localhost [127.0.0.1]) i79IkCeX034318; Mon, 9 Aug 2004 13:46:12 -0500 (CDT) (envelope-from rnejdl@ringofsaturn.com) Received: from 12.148.147.242 (SquirrelMail authenticated user rnejdl); by mail.ringofsaturn.com with HTTP; Mon, 9 Aug 2004 13:46:12 -0500 (CDT) Message-ID: <44129.12.148.147.242.1092077172.squirrel@[12.148.147.242]> In-Reply-To: References: <20040809182126.GC4216@dan.emsphone.com> Date: Mon, 9 Aug 2004 13:46:12 -0500 (CDT) From: "Rusty Nejdl" To: conrads@cox.net User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on tethys.ringofsaturn.com X-Virus-Status: Clean cc: freebsd-current@freebsd.org cc: Dan Nelson Subject: Re: Is anything being done re: the pcm timeout issue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rnejdl@ringofsaturn.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 18:46:18 -0000 Conrad J. Sabatier said: > >> Sound works fine for me on my Dell laptop (mss driver). I do get a >> mutex-related panic on my desktop (sb16 driver), but haven't sent in the >> stack trace to anyone yet. > > My problems are occurring on an amd64 box (Athlon 64) with the nVidia > nForce3 chipset (snd_ich driver). > > Sounds works fine for a while, then suddenly I get a pcm play timeout, > and game over. Have to reboot to get sound to work again. > > Others have reported similar problems, but I've seen no followups > indicating anything is being done about it. > I've been seeing a sound issue on 5.2.1-release and I wonder if it's related at all to what you are seeing. I have : hw.snd.maxautovchans: 4 hw.snd.pcm0.vchans: 4 And I have seen that these will eventually stop working one by one until I have none left. lsof and fstat don't show any programs using them, but nonetheless, programms like xmms and gaim can't use them anymore. Do you have any more details on the pcm play timeout? Are you using vchans? What program are you using? Rusty Nejdl >>> This is getting extremely frustrating. Is anyone working on this at >>> all? > > -- > Conrad J. Sabatier -- "In Unix veritas" > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 18:46:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4720416A4CF; Mon, 9 Aug 2004 18:46:34 +0000 (GMT) Received: from afields.ca (afields.ca [216.194.67.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18F1A43D1F; Mon, 9 Aug 2004 18:46:34 +0000 (GMT) (envelope-from afields@afields.ca) Received: from afields.ca (localhost.afields.ca [127.0.0.1]) by afields.ca (8.12.11/8.12.11) with ESMTP id i79IkXFZ009491; Mon, 9 Aug 2004 14:46:33 -0400 (EDT) (envelope-from afields@afields.ca) Received: (from afields@localhost) by afields.ca (8.12.11/8.12.11/Submit) id i79IkXNF009490; Mon, 9 Aug 2004 14:46:33 -0400 (EDT) (envelope-from afields) Date: Mon, 9 Aug 2004 14:46:33 -0400 From: Allan Fields To: Mark Murray Message-ID: <20040809184633.GC7838@afields.ca> References: <6.1.2.0.0.20040809134944.058d4098@64.7.153.2> <200408091814.i79IEjjv009798@grimreaper.grondar.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ADZbWkCsHQ7r3kzd" Content-Disposition: inline In-Reply-To: <200408091814.i79IEjjv009798@grimreaper.grondar.org> User-Agent: Mutt/1.4i cc: freebsd-fs@freebsd.org cc: freebsd-current@freebsd.org cc: Mike Tancsa Subject: Re: VIA C3 AES code ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 18:46:34 -0000 --ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 09, 2004 at 07:14:45PM +0100, Mark Murray wrote: > In-kernel stuff is more involved, and as IPSEC is in poor shape, not > too well tested. >=20 > M > -- > Mark Murray > iumop ap!sdn w,I idlaH I would certainly be interested in GBDE hardware acceleration support. I know phk had mentioned that work on this was pending and I've seen it discussed on list before, any updates? If I get my hands on supported hardware, I volunteer to help test. ;) Thanks, --=20 Allan Fields, AFRSL - http://afields.ca 2D4F 6806 D307 0889 6125 C31D F745 0D72 39B4 5541 --ADZbWkCsHQ7r3kzd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQFBF8aI90UNcjm0VUERAtsQAJwN9X0xDNKM5EJpoeXhl7+LwhS2wgCfY4a7 n8UGR9qp7MaFv3v5vknoR08= =0Smy -----END PGP SIGNATURE----- --ADZbWkCsHQ7r3kzd-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 18:57:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DF3D16A4CE; Mon, 9 Aug 2004 18:57:39 +0000 (GMT) Received: from sirius.firepipe.net (sirius.firepipe.net [69.13.116.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05B0143D58; Mon, 9 Aug 2004 18:57:39 +0000 (GMT) (envelope-from will@csociety.org) Received: by sirius.firepipe.net (Postfix, from userid 1000) id 96F22180EB; Mon, 9 Aug 2004 13:57:38 -0500 (EST) Date: Mon, 9 Aug 2004 13:57:38 -0500 From: Will Andrews To: Mark Murray Message-ID: <20040809185738.GY26004@sirius.firepipe.net> Mail-Followup-To: Mark Murray , Mike Tancsa , freebsd-current@FreeBSD.ORG References: <6.1.2.0.0.20040809134944.058d4098@64.7.153.2> <200408091814.i79IEjjv009798@grimreaper.grondar.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jn/MQTzma+jNUHFC" Content-Disposition: inline In-Reply-To: <200408091814.i79IEjjv009798@grimreaper.grondar.org> User-Agent: Mutt/1.5.6i cc: freebsd-current@FreeBSD.ORG cc: Mike Tancsa Subject: Re: VIA C3 AES code ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 18:57:39 -0000 --jn/MQTzma+jNUHFC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 09, 2004 at 07:14:45PM +0100, Mark Murray wrote: > Yup. It means that if you ask OpenSSL for AES encryptionon a C3 Nehemiah, > you get the full HW speed. I must be doing something wrong. will@crypt% uname -a;dmesg|grep ^CPU;openssl speed aes FreeBSD crypt.rcs.purdue.edu 4.10-STABLE FreeBSD 4.10-STABLE #1: Sun Aug 8= 12:27:52 EST 2004 will@crypt.rcs.purdue.edu:/usr/obj/usr/src/sys/CRYPT i3= 86 CPU: Intel Pentium III (930.32-MHz 686-class CPU) To get the most accurate results, try to run this program when this computer is idle. Doing aes-128 cbc for 3s on 16 size blocks: 2368526 aes-128 cbc's in 2.19s Doing aes-128 cbc for 3s on 64 size blocks: 577357 aes-128 cbc's in 2.09s Doing aes-128 cbc for 3s on 256 size blocks: 145718 aes-128 cbc's in 2.09s Doing aes-128 cbc for 3s on 1024 size blocks: 37833 aes-128 cbc's in 2.16s Doing aes-128 cbc for 3s on 8192 size blocks: 4742 aes-128 cbc's in 2.17s Doing aes-192 cbc for 3s on 16 size blocks: 2018530 aes-192 cbc's in 2.16s Doing aes-192 cbc for 3s on 64 size blocks: 507482 aes-192 cbc's in 2.13s Doing aes-192 cbc for 3s on 256 size blocks: 121887 aes-192 cbc's in 2.03s Doing aes-192 cbc for 3s on 1024 size blocks: 32369 aes-192 cbc's in 2.14s Doing aes-192 cbc for 3s on 8192 size blocks: 4169 aes-192 cbc's in 2.22s Doing aes-256 cbc for 3s on 16 size blocks: 1791005 aes-256 cbc's in 2.13s Doing aes-256 cbc for 3s on 64 size blocks: 460331 aes-256 cbc's in 2.15s Doing aes-256 cbc for 3s on 256 size blocks: 110531 aes-256 cbc's in 2.06s Doing aes-256 cbc for 3s on 1024 size blocks: 26678 aes-256 cbc's in 1.99s Doing aes-256 cbc for 3s on 8192 size blocks: 3653 aes-256 cbc's in 2.18s OpenSSL 0.9.7d 17 Mar 2004 built on: Sun Aug 8 10:58:31 EST 2004 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx)=20 compiler: cc available timing options: USE_TOD HZ=3D128 [sysconf value] timing function used: getrusage The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 17267.78k 17673.48k 17851.45k 17906.22k 17864.76k aes-192 cbc 14964.41k 15266.56k 15358.12k 15501.56k 15411.18k aes-256 cbc 13444.28k 13680.17k 13761.54k 13739.98k 13703.48k vs. will@puck% uname -a;dmesg|grep ^CPU;openssl speed aes FreeBSD puck.firepipe.net 5.2-CURRENT FreeBSD 5.2-CURRENT #1: Sat Aug 7 13= :19:23 EST 2004 root@puck.firepipe.net:/usr/obj/mnt/current/src/sys/PUCK i= 386 CPU: VIA C3 Nehemiah+RNG+ACE (1208.87-MHz 686-class CPU) To get the most accurate results, try to run this program when this computer is idle. Doing aes-128 cbc for 3s on 16 size blocks: 1884024 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 64 size blocks: 483936 aes-128 cbc's in 3.01s Doing aes-128 cbc for 3s on 256 size blocks: 122298 aes-128 cbc's in 3.01s Doing aes-128 cbc for 3s on 1024 size blocks: 30653 aes-128 cbc's in 2.99s Doing aes-128 cbc for 3s on 8192 size blocks: 3804 aes-128 cbc's in 2.98s Doing aes-192 cbc for 3s on 16 size blocks: 1656066 aes-192 cbc's in 3.01s Doing aes-192 cbc for 3s on 64 size blocks: 392134 aes-192 cbc's in 2.79s Doing aes-192 cbc for 3s on 256 size blocks: 106642 aes-192 cbc's in 3.00s Doing aes-192 cbc for 3s on 1024 size blocks: 26609 aes-192 cbc's in 2.99s Doing aes-192 cbc for 3s on 8192 size blocks: 3329 aes-192 cbc's in 2.98s Doing aes-256 cbc for 3s on 16 size blocks: 1474497 aes-256 cbc's in 3.01s Doing aes-256 cbc for 3s on 64 size blocks: 375919 aes-256 cbc's in 3.01s Doing aes-256 cbc for 3s on 256 size blocks: 94770 aes-256 cbc's in 3.01s Doing aes-256 cbc for 3s on 1024 size blocks: 23745 aes-256 cbc's in 3.01s Doing aes-256 cbc for 3s on 8192 size blocks: 2946 aes-256 cbc's in 2.98s OpenSSL 0.9.7d 17 Mar 2004 built on: Sat Aug 7 11:06:04 EST 2004 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx)=20 compiler: cc available timing options: USE_TOD HZ=3D128 [sysconf value] timing function used: getrusage The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 10049.22k 10301.48k 10414.26k 10495.10k 10450.72k aes-192 cbc 8814.47k 8999.87k 9093.22k 9115.31k 9145.70k aes-256 cbc 7846.55k 8002.02k 8070.34k 8087.53k 8092.58k Regards, --=20 wca --jn/MQTzma+jNUHFC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBF8kiF47idPgWcsURAg7UAJ9yGKFiWo0HLjJxn9ZZ73yMnHGrBQCfcFUQ HAUu0TaNrKdt+reRe7zcTQE= =rAR+ -----END PGP SIGNATURE----- --jn/MQTzma+jNUHFC-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 19:36:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E380716A4CE for ; Mon, 9 Aug 2004 19:36:03 +0000 (GMT) Received: from av2-1-sn3.vrr.skanova.net (av2-1-sn3.vrr.skanova.net [81.228.9.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76CC043D1F for ; Mon, 9 Aug 2004 19:36:03 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av2-1-sn3.vrr.skanova.net (Postfix, from userid 502) id D2B523813F; Mon, 9 Aug 2004 21:36:02 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av2-1-sn3.vrr.skanova.net (Postfix) with ESMTP id C52F337E81; Mon, 9 Aug 2004 21:36:02 +0200 (CEST) Received: from gadget (h130n1fls11o822.telia.com [213.64.66.130]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 9E2703801C; Mon, 9 Aug 2004 21:36:02 +0200 (CEST) From: "Daniel Eriksson" To: =?iso-8859-1?Q?'S=F8ren_Schmidt'?= Date: Mon, 9 Aug 2004 21:35:58 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcR9jGeWA5qoddy5Rd+Gw06RxTqnsQAuTKEQ cc: freebsd-current@freebsd.org cc: 'Ville-Pertti Keinonen' Subject: RE: ATA driver races with interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 19:36:04 -0000 I wrote: > After 3+ days of uptime, including continuous SMART monitoring (which > without patch triggers an immediate disconnect, and with S=F6rens = patch > triggered a disconnect after ~16 hours) and a fair amount of=20 > disc activity on both channels it looks like maybe the serialization > patch from Ville-Pertti is enough to make my SATA controller work=20 > properly. Of course, it also slows things down, but right now that is > better than the alternative. Ha, so much for thinking it was stable. Earlier today (after 4+ days of uptime) the machine disconnected one of the SATA discs despite the fact = that I'm running with Ville-Pertti's serialization patch. I have two 250GB SATA discs, one Western Digital and one Maxtor. After looking at the logs from today, and grep'ing some old logs, I noticed = that it seems more common for the channel with the WD disc to lock up. My = logs don't go back far enough that I can say it has always been like that, = but it looks that way from the logs right now (but I only switched channels for = the discs once, so the sampling is very limited and the result could be = entirely coincidental). I have updated my system to sources from 2004.08.09.13.00.00 without any patches (because I saw some commits to the ATA code in the last couple = of days). The base code now allows me to at least start the SMART monitor = and run some stress tests. I'll report back when/if it fails. By next week = I'll probably have a Promise SATA150 TX4 that I will use instead. It will be = very interesting to see if that one also will give me problems with the WD = disc. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 19:53:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DAFA16A4D0 for ; Mon, 9 Aug 2004 19:53:03 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE22E43D2D for ; Mon, 9 Aug 2004 19:53:02 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.102] (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0)i79JfNjr004333 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 9 Aug 2004 15:41:24 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-current@freebsd.org Date: Mon, 9 Aug 2004 15:54:18 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <200408091554.20689.mistry.7@osu.edu> X-Spam-Status: No, hits=-1.2 required=5.0 tests=PGP_SIGNATURE,RCVD_IN_ORBS,UPPERCASE_25_50,USER_AGENT_KMAIL version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: USB combo device HID fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 19:53:03 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The following patch I submitted in the following PR fixes my logitech usb=20 mouse combo set, it'll probably fix other combo hid devices. http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/63837 =2D --=20 Anish Mistry =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBF9ZqxqA5ziudZT0RAkzhAJ4vxsaAuvwibX2y3Vdh5n/X3sc5XACeK7k3 TyQfjnuZ4+6ZIAmKH/dtMW0=3D =3DqpJ2 =2D----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 20:05:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57ABC16A4CE for ; Mon, 9 Aug 2004 20:05:54 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2628A43D5A for ; Mon, 9 Aug 2004 20:05:54 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 935 invoked from network); 9 Aug 2004 20:05:53 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 9 Aug 2004 20:05:53 -0000 Received: from 10.50.40.208 (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i79K5krX076764; Mon, 9 Aug 2004 16:05:49 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Mon, 9 Aug 2004 15:37:44 -0400 User-Agent: KMail/1.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408091537.44075.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Poul-Henning Kamp cc: Robert Watson cc: current@FreeBSD.org Subject: Re: ath/ifstart panic: still, new fcntl panic. ACPI still hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 20:05:54 -0000 On Saturday 07 August 2004 10:01 am, Robert Watson wrote: > On Sat, 7 Aug 2004, Poul-Henning Kamp wrote: > > IBM Thinkpad T41p, -current from one hour ago. > > > > The Ath/if_start problem is still there (I have got sams commit). > > > > New one, looks like rwatsons baby: > > Giant owned > > mtx_assert > > kern_fcntl > > fcntl_common > > linux_fcntl > > syscall(linux_fcntl64) > > > > And without the CD drive installed my laptop still wedges solid if I > > press the ACPI sleep button. This works perfectly if the CD drive is > > installed. > > Doh. We probably need to comment out all the assertions that Giant isn't > owned in kern_fcntl() due to wrapping by ABIs. Or try this (untested) patch: http://www.FreeBSD.org/~jhb/patches/fcntl.patch -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 20:05:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A670816A4CE for ; Mon, 9 Aug 2004 20:05:54 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E68043D5A for ; Mon, 9 Aug 2004 20:05:54 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 935 invoked from network); 9 Aug 2004 20:05:53 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 9 Aug 2004 20:05:53 -0000 Received: from 10.50.40.208 (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i79K5krX076764; Mon, 9 Aug 2004 16:05:49 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Mon, 9 Aug 2004 15:37:44 -0400 User-Agent: KMail/1.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408091537.44075.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Poul-Henning Kamp cc: Robert Watson cc: current@FreeBSD.org Subject: Re: ath/ifstart panic: still, new fcntl panic. ACPI still hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 20:05:54 -0000 On Saturday 07 August 2004 10:01 am, Robert Watson wrote: > On Sat, 7 Aug 2004, Poul-Henning Kamp wrote: > > IBM Thinkpad T41p, -current from one hour ago. > > > > The Ath/if_start problem is still there (I have got sams commit). > > > > New one, looks like rwatsons baby: > > Giant owned > > mtx_assert > > kern_fcntl > > fcntl_common > > linux_fcntl > > syscall(linux_fcntl64) > > > > And without the CD drive installed my laptop still wedges solid if I > > press the ACPI sleep button. This works perfectly if the CD drive is > > installed. > > Doh. We probably need to comment out all the assertions that Giant isn't > owned in kern_fcntl() due to wrapping by ABIs. Or try this (untested) patch: http://www.FreeBSD.org/~jhb/patches/fcntl.patch -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 20:06:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E56516A4FE for ; Mon, 9 Aug 2004 20:06:01 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4977143D45 for ; Mon, 9 Aug 2004 20:06:01 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 31861 invoked from network); 9 Aug 2004 20:06:01 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 9 Aug 2004 20:06:00 -0000 Received: from 10.50.40.208 (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i79K5krZ076764; Mon, 9 Aug 2004 16:05:57 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Mon, 9 Aug 2004 15:51:48 -0400 User-Agent: KMail/1.6 References: <1719.66.11.183.182.1092069657.squirrel@66.11.183.182> In-Reply-To: <1719.66.11.183.182.1092069657.squirrel@66.11.183.182> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408091551.48309.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Mike Jakubik Subject: Re: PCI interrupt routing messages in boot (and stray irq 9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 20:06:01 -0000 On Monday 09 August 2004 12:40 pm, Mike Jakubik wrote: > Hello, > > I have recently obtained a dual Xeon supermicro system (MB# X5DP8-G2). > Installed 5.2.1, and cvsupped to -current. I get the following messages > when booting, that have me worried: > > pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.HLB_ - > AE_NOT_FOUND > pcib4: could not get PCI interrupt routing table for \\_SB_.PCI0.HLC_ - > AE_NOT_FOUND > > Are these ok to ignore? I also get a weird message when shutting down the > server, after the disks sync, and the shutting down ACPI message comes up, > the following is displayed "stray irq9", which is assigned to ACPI. Below > is a complete dmesg. Yes, the PCI messages are ok to be ignored. I will shut them up before 5.3 in fact. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 20:06:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19ED516A4CE; Mon, 9 Aug 2004 20:06:18 +0000 (GMT) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9117143D49; Mon, 9 Aug 2004 20:06:17 +0000 (GMT) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) i79K6C98025949; Mon, 9 Aug 2004 21:06:12 +0100 (BST) (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost)i79K6Cnh025948; Mon, 9 Aug 2004 21:06:12 +0100 (BST) (envelope-from mark@grondar.org) X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1])i79K1Ivm010845; Mon, 9 Aug 2004 21:01:18 +0100 (BST) (envelope-from mark@grondar.org) Message-Id: <200408092001.i79K1Ivm010845@grimreaper.grondar.org> To: Will Andrews From: Mark Murray In-Reply-To: Your message of "Mon, 09 Aug 2004 13:57:38 CDT." <20040809185738.GY26004@sirius.firepipe.net> Date: Mon, 09 Aug 2004 21:01:18 +0100 Sender: mark@grondar.org cc: freebsd-current@FreeBSD.ORG cc: Mark Murray cc: Mike Tancsa Subject: Re: VIA C3 AES code ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 20:06:18 -0000 Will Andrews writes: > On Mon, Aug 09, 2004 at 07:14:45PM +0100, Mark Murray wrote: > > Yup. It means that if you ask OpenSSL for AES encryptionon a C3 Nehemiah, > > you get the full HW speed. > > I must be doing something wrong. Are you assuming that the code is already committed? M -- Mark Murray iumop ap!sdn w,I idlaH From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 20:07:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E68D16A4CE for ; Mon, 9 Aug 2004 20:07:51 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A10443D49 for ; Mon, 9 Aug 2004 20:07:51 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 25439 invoked from network); 9 Aug 2004 20:05:58 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 9 Aug 2004 20:05:58 -0000 Received: from 10.50.40.208 (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i79K5krY076764; Mon, 9 Aug 2004 16:05:54 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Mon, 9 Aug 2004 15:39:49 -0400 User-Agent: KMail/1.6 References: <7m4qnfm71k.wl@black.imgsrc.co.jp> In-Reply-To: <7m4qnfm71k.wl@black.imgsrc.co.jp> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408091539.49714.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Jun Kuriyama Subject: Re: buildworld with MAKEOBJDIRPREFIX X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 20:07:51 -0000 On Saturday 07 August 2004 09:06 am, Jun Kuriyama wrote: > Since yesterday, my nightly buildworld is failing... > > -------------------------------------------------------------- > > >>> stage 1.1: legacy release compatibility shims > > -------------------------------------------------------------- > cd /work/HEAD/src; MAKEOBJDIRPREFIX=/work/HEAD/obj/work/HEAD/src/i386 > DESTDIR= INSTALL="sh /work/HEAD/src/tools/install.sh" > PATH=/work/HEAD/obj/work/HEAD/src/i386/legacy/usr/sbin:/work/HEAD/obj/work/ >HEAD/src/i386/legacy/usr/bin:/work/HEAD/obj/work/HEAD/src/i386/legacy/usr/ga >mes:/sbin:/bin:/usr/sbin:/usr/bin > WORLDTMP=/work/HEAD/obj/work/HEAD/src/i386 MAKEFLAGS="-m > /work/HEAD/src/tools/build/mk -m /work/HEAD/src/share/mk > MAKEOBJDIRPREFIX=/work/HEAD/obj OSRELDATE=500110" > /work/HEAD/obj/work/HEAD/src/make.i386/make -f Makefile.inc1 > BOOTSTRAPPING=500110 -DNOHTML -DNOINFO -DNOLINT -DNOMAN -DNOPIC > -DNOPROFILE -DNOSHARED -DNO_CPU_CFLAGS -DNO_WARNS legacy ===> tools/build > cd /work/HEAD/src/tools/build; /work/HEAD/obj/work/HEAD/src/make.i386/make > buildincludes; /work/HEAD/obj/work/HEAD/src/make.i386/make installincludes > sh /work/HEAD/src/tools/install.sh -C -o root -g wheel -m 444 > /work/HEAD/src/tools/build/../../include/getopt.h > /work/HEAD/obj/legacy/usr/include install: > /work/HEAD/obj/legacy/usr/include: No such file or directory *** Error code > 71 > > Stop in /work/HEAD/src/tools/build. > *** Error code 1 > > Stop in /work/HEAD/src/tools/build. > *** Error code 1 Yeah, the folks working on make(1) broke this feature. You have to define MAKEOBJDIRPREFIX as an environment variable rather than on the command line to make now. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 20:07:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2917816A4D2; Mon, 9 Aug 2004 20:07:55 +0000 (GMT) Received: from sirius.firepipe.net (sirius.firepipe.net [69.13.116.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09DDE43D2F; Mon, 9 Aug 2004 20:07:55 +0000 (GMT) (envelope-from will@csociety.org) Received: by sirius.firepipe.net (Postfix, from userid 1000) id A1A0A180EE; Mon, 9 Aug 2004 15:07:54 -0500 (EST) Date: Mon, 9 Aug 2004 15:07:54 -0500 From: Will Andrews To: Mark Murray Message-ID: <20040809200754.GZ26004@sirius.firepipe.net> Mail-Followup-To: Mark Murray , Will Andrews , Mike Tancsa , freebsd-current@FreeBSD.ORG References: <20040809185738.GY26004@sirius.firepipe.net> <200408092001.i79K1Ivm010845@grimreaper.grondar.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OEa2bCMk+rg6xBXy" Content-Disposition: inline In-Reply-To: <200408092001.i79K1Ivm010845@grimreaper.grondar.org> User-Agent: Mutt/1.5.6i cc: freebsd-current@FreeBSD.ORG cc: Will Andrews cc: Mike Tancsa Subject: Re: VIA C3 AES code ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 20:07:55 -0000 --OEa2bCMk+rg6xBXy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 09, 2004 at 09:01:18PM +0100, Mark Murray wrote: > Are you assuming that the code is already committed? Yes. Is there a reason it isn't? Feel free to send me a patch if it needs testing. Regards, --=20 wca --OEa2bCMk+rg6xBXy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBF9maF47idPgWcsURAr5LAJ4zHscXhQhZP15IPX41O7CYKEzUDwCfSPz4 FHSy3Nq1kMPSRhvxfD2uL6w= =eGj1 -----END PGP SIGNATURE----- --OEa2bCMk+rg6xBXy-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 21:25:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5696616A4CE for ; Mon, 9 Aug 2004 21:25:46 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 174A543D46 for ; Mon, 9 Aug 2004 21:25:46 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-67-115-74-195.dsl.lsan03.pacbell.net [67.115.74.195]) i79LPlnA013408 for ; Mon, 9 Aug 2004 17:25:47 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 579E451312; Mon, 9 Aug 2004 14:25:44 -0700 (PDT) Date: Mon, 9 Aug 2004 14:25:44 -0700 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20040809212544.GA86157@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: world broken (libbsnmp broken, and "+for: not found") X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 21:25:46 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline World seems to be broken in two ways (updating from -current from about a month ago): 1) > ===> lib/libbsnmp/modules > ===> lib/libbsnmp/modules/snmp_atm > make: don't know how to make snmp_atm.h. Stop > *** Error code 2 After reverting these commits, it gets a bit further before dying with 2) echo routed: /usr/obj/a/portbuild/i386/src-client/i386/usr/lib/libc.a /usr/obj/a/portbuild/i386/src-client/i386/usr/lib/libmd.a >> .depend +for: not found *** Error code 127 Stop in /a/portbuild/i386/src-client/sbin/routed. *** Error code 1 Stop in /a/obj/a/portbuild/i386/src-client/rescue/rescue. *** Error code 1 Kris --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBF+vYWry0BWjoQKURAjQOAKCEO0p5QU7mQdwivqfgfgcrVLkj8wCgpwPz oai3Uj0odk8VyNoqEJjyLqE= =WEqh -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 21:40:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE71916A4CE for ; Mon, 9 Aug 2004 21:40:38 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75ED643D5A for ; Mon, 9 Aug 2004 21:40:38 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 12E377A3D2 for ; Mon, 9 Aug 2004 14:40:38 -0700 (PDT) Message-ID: <4117EF55.4090409@elischer.org> Date: Mon, 09 Aug 2004 14:40:37 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: RFC.. defining __rangeof() in cdefs.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 21:40:38 -0000 I'm considdereing adding: Index: sys/cdefs.h =================================================================== RCS file: /home/ncvs/src/sys/sys/cdefs.h,v retrieving revision 1.83 diff -u -r1.83 cdefs.h --- sys/cdefs.h 28 Jul 2004 07:03:42 -0000 1.83 +++ sys/cdefs.h 9 Aug 2004 21:36:41 -0000 @@ -241,6 +241,8 @@ * require it. */ #define __offsetof(type, field) ((size_t)(&((type *)0)->field)) +#define __rangeof(type, start, end) \ + (__offsetof(type, end) - __offsetof(type, start)) /* * Compiler-dependent macros to declare that functions take printf-like it is used in several places. most importantly in fork1() and it is defined in several files (*).. we should probably just have one copy... (*) in the form RANGEOF() but if we define it in cdefs.h I'd change that to __rangeof() to match __offsetof() From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 21:42:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF53316A4CE for ; Mon, 9 Aug 2004 21:42:01 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93D7E43D41 for ; Mon, 9 Aug 2004 21:42:01 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 8AD4B530D; Mon, 9 Aug 2004 23:42:00 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 14E5E530C; Mon, 9 Aug 2004 23:41:53 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 92ADFB872; Mon, 9 Aug 2004 23:41:53 +0200 (CEST) To: "Thomas T. Veldhouse" References: <41178262.4060707@veldy.net> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Mon, 09 Aug 2004 23:41:53 +0200 In-Reply-To: <41178262.4060707@veldy.net> (Thomas T. Veldhouse's message of "Mon, 09 Aug 2004 08:55:46 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: freebsd-current@freebsd.org Subject: Re: options LINPROCFS fails in todays current .... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 21:42:02 -0000 "Thomas T. Veldhouse" writes: > linking kernel > linprocfs.o(.text+0x3f7): In function `linprocfs_domtab': undefined refer= ence to `linux_emul_path' LINPROCFS requires COMPAT_LINUX. You'd be better off simply using modules... DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 21:49:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F6F616A4CE for ; Mon, 9 Aug 2004 21:49:35 +0000 (GMT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7798B43D5D for ; Mon, 9 Aug 2004 21:49:35 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from [192.168.0.103] (c-24-21-18-195.client.comcast.net[24.21.18.195]) by comcast.net (rwcrmhc13) with SMTP id <20040809214931015008urade>; Mon, 9 Aug 2004 21:49:35 +0000 From: Eric Anholt To: Geoff Speicher In-Reply-To: <20040805172041.GB47734@sirius.speicher.org> References: <1091649533.29481.42.camel@lanshark.dmv.com> <411152D8.2050305@alumni.rice.edu><41115679.2030300@freebsd.org> <20040804220718.GA99590@sirius.speicher.org> <1091658373.893.15.camel@leguin> <20040805131628.GA47734@sirius.speicher.org> <1091725623.911.10.camel@leguin> <20040805172041.GB47734@sirius.speicher.org> Content-Type: text/plain Message-Id: <1092088170.893.76.camel@leguin> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 09 Aug 2004 14:49:30 -0700 Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: Instant Reboots (was: Re: Postgresql locks up server - no response at all) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 21:49:35 -0000 On Thu, 2004-08-05 at 10:20, Geoff Speicher wrote: > On Thu, Aug 05, 2004 at 10:07:04AM -0700, Eric Anholt wrote: > > On Thu, 2004-08-05 at 06:16, Geoff Speicher wrote: > > > On Wed, Aug 04, 2004 at 03:26:13PM -0700, Eric Anholt wrote: > > > > On Wed, 2004-08-04 at 15:07, Geoff Speicher wrote: > > > > > > > > > > Snippets from /var/log/XFree86.0.log: > > > > > > > > > > (II) ATI: ATI driver (version 6.4.18) for chipsets: ati, ativga > > > > > (--) RADEON(0): Chipset: "ATI Radeon VE/7000 QY (AGP)" (ChipID = 0x5159) > > > > > (II) Loading /usr/X11R6/lib/modules/drivers/radeon_drv.o > > > > > (II) Module radeon: vendor="The XFree86 Project" > > > > > compiled for 4.3.0, module version = 4.0.1 > > > > > Module class: XFree86 Video Driver > > > > > ABI class: XFree86 Video Driver, version 0.6 > > > > > > > > > > (II) RADEON(0): [drm] loaded kernel module for "radeon" driver > > > > > (II) RADEON(0): Direct rendering enabled > > > > > > > > Does this happen without using threaded apps? More specifically, does > > > > it continue if you disable DRI in your X config? If so, please send me > > > > your dmesg. > > > > > > Hey, disabling DRI did the trick. Aside from things being remarkably > > > slow, it's remarkably stable. ;) Threaded X apps or no, I'm running > > > a July 19 kernel with no instant reboots. PREEMPTION disabled, > > > WITNESS enabled (I misspoke in another message when I said WITNESS was > > > disabled---apparently I fiddled more than I had remembered). Toggling > > > DRI back on and restarting X/kdm reboots immediately. > > > > While you didn't send your dmesg, I'm betting that you've got VIA 8377 > > AGP. We're misconfiguring it, it seems. I'm working on a patch, please > > watch http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/69953 for a fix. > > Sorry, I thought you wanted the dmesg if and only if the reboots > continued with DRI disabled. > > You guessed right: > > agp0: mem 0xe0000000-0xe7ffffff at device 0.0 on pci0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > pci1: at device 0.0 (no driver attached) > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > > Geoff OK, I think it's fixed in CVS. Please tell me if it isn't. I'd love to get feedback from someone with specs for those AGP chipsets, or someone with a v3 card, on the other half of the patch in the PR. Also, anyone with DRI issues that involve hanging the system in things not involving 3D, please tell me! I'm very interested in getting these stability issues fixed. -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 22:12:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3611616A4CE for ; Mon, 9 Aug 2004 22:12:48 +0000 (GMT) Received: from gateway.nixsys.be (gateway.nixsys.be [195.144.77.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id C721343D5A for ; Mon, 9 Aug 2004 22:12:47 +0000 (GMT) (envelope-from philip@paeps.cx) Received: from erda.home.paeps.cx (erda.home.paeps.cx [IPv6:2001:838:37f:10::1]) by gateway.nixsys.be (Postfix) with ESMTP id 332708E for ; Tue, 10 Aug 2004 00:12:46 +0200 (CEST) Received: from fasolt.home.paeps.cx (fasolt.home.paeps.cx [10.0.0.2]) by erda.home.paeps.cx (Postfix) with ESMTP id 06C19210E for ; Tue, 10 Aug 2004 00:12:38 +0200 (CEST) Received: from fasolt.home.paeps.cx (philip@localhost [127.0.0.1]) i79MCjKq015758 for ; Tue, 10 Aug 2004 00:12:45 +0200 (CEST) (envelope-from philip@fasolt.home.paeps.cx) Received: (from philip@localhost) by fasolt.home.paeps.cx (8.12.11/8.12.11/Submit) id i79MCiDA015757 for freebsd-current@freebsd.org; Tue, 10 Aug 2004 00:12:44 +0200 (CEST) (envelope-from philip) Date: Tue, 10 Aug 2004 00:12:44 +0200 From: Philip Paeps To: freebsd-current@freebsd.org Message-ID: <20040809221244.GB14911@fasolt.home.paeps.cx> Mail-Followup-To: freebsd-current@freebsd.org References: <20040805071236.GA595@loge.nixsys.be> <20040809090723.GI642@loge.nixsys.be> <8cb27cbf0408090648159d34@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8cb27cbf0408090648159d34@mail.gmail.com> X-Date-in-Rome: ante diem V Idius Augustas MMDCCLVII ab Urbe Condida X-PGP-Fingerprint: FA74 3C27 91A6 79D5 F6D3 FC53 BF4B D0E6 049D B879 X-Message-Flag: Get a proper mailclient! User-Agent: Mutt/1.5.6i Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 22:12:48 -0000 On 2004-08-09 08:48:16 (-0500), Jon Drews wrote: > > Which revision of psm.c is this? r1.71 or r1.76? > > I have r1.76 > > > Could you also post the 'info*' and 'cap*' lines from a verbose boot? > > Yes, here is the entire verbose dmesg output: > http://www.silbsd.org/bugreports/dmesgVerbose.txt Mmm, oh, right. Verbose isn't verbose enough for psm, I'm afraid you'll have to compile a kernel with options PSM_DEBUG=2. I'll have to remember to stick the probe-messages under a normal verbose. - Philip -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. Forgive and remember. From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 22:22:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A442C16A4CE for ; Mon, 9 Aug 2004 22:22:49 +0000 (GMT) Received: from mail023.syd.optusnet.com.au (mail023.syd.optusnet.com.au [211.29.132.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EBF543D48 for ; Mon, 9 Aug 2004 22:22:48 +0000 (GMT) (envelope-from akm@theinternet.com.au) Received: from theinternet.com.au (c211-30-103-113.carlnfd1.nsw.optusnet.com.au [211.30.103.113]) i79MMff26368; Tue, 10 Aug 2004 08:22:42 +1000 Received: from theinternet.com.au (localhost [127.0.0.1]) by theinternet.com.au (8.12.11/8.12.11) with ESMTP id i79MLSTl028342; Tue, 10 Aug 2004 08:21:28 +1000 (EST) (envelope-from akm@theinternet.com.au) Received: (from akm@localhost) by theinternet.com.au (8.12.11/8.12.11/Submit) id i79MLRZt028340; Tue, 10 Aug 2004 08:21:27 +1000 (EST) (envelope-from akm) Date: Tue, 10 Aug 2004 08:21:27 +1000 From: Andrew Milton To: Max Laier Message-ID: <20040809222127.GU64690@camelot.theinternet.com.au> Mail-Followup-To: Max Laier , freebsd-current@freebsd.org, Jiawei Ye References: <200408092003.28922.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408092003.28922.max@love2party.net> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org cc: Jiawei Ye Subject: Re: kldload pf failed on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 22:22:49 -0000 +-------[ Max Laier ]---------------------- | On Monday 09 August 2004 18:54, Jiawei Ye wrote: | > root@chihiro:/usr/src# kldload -v pf | > kldload: can't load pf: No such file or directory | > root@chihiro:/usr/src# kldload /boot/kernel/pf.ko | > root@chihiro:/usr/src# /etc/rc.d/pf restart | > Enabling pf. | > pf enabled | > | > Somehow kldload cannot find pf.ko if no specific path is given. This | > is a 2 hours old -current. | | Sounds like kldxref didn't finish it's job correctly. Try (as root): | kldxref /boot/kernel /boot/modules | and check the output of: | kldxref -dv /boot/kernel | for proper pf.ko entries. Please tell me if that did not help or if you see | anything suspicious in the xref dump. I have this same problem with nfsclient and nfsserver being loaded. kldxref doesn't fix the problem (for me). I figured I just updated at a bad time since noone else had reported a similar thing occurring (it wasn't a big drama for me to load those by hand). ACPI also doesn't autoload at boot. This was from a -current from August 8th. -- Andrew Milton akm@theinternet.com.au From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 22:24:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F9DC16A4CE for ; Mon, 9 Aug 2004 22:24:04 +0000 (GMT) Received: from gateway.nixsys.be (gateway.nixsys.be [195.144.77.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B97E43D46 for ; Mon, 9 Aug 2004 22:24:03 +0000 (GMT) (envelope-from philip@paeps.cx) Received: from erda.home.paeps.cx (erda.home.paeps.cx [IPv6:2001:838:37f:10::1]) by gateway.nixsys.be (Postfix) with ESMTP id BA58054 for ; Tue, 10 Aug 2004 00:24:02 +0200 (CEST) Received: from fasolt.home.paeps.cx (fasolt.home.paeps.cx [10.0.0.2]) by erda.home.paeps.cx (Postfix) with ESMTP id 8B9692120 for ; Tue, 10 Aug 2004 00:23:54 +0200 (CEST) Received: from fasolt.home.paeps.cx (philip@localhost [127.0.0.1]) i79MO2QJ015791 for ; Tue, 10 Aug 2004 00:24:02 +0200 (CEST) (envelope-from philip@fasolt.home.paeps.cx) Received: (from philip@localhost) by fasolt.home.paeps.cx (8.12.11/8.12.11/Submit) id i79MO2s6015790 for freebsd-current@freebsd.org; Tue, 10 Aug 2004 00:24:02 +0200 (CEST) (envelope-from philip) Date: Tue, 10 Aug 2004 00:24:01 +0200 From: Philip Paeps To: freebsd-current@freebsd.org Message-ID: <20040809222401.GC14911@fasolt.home.paeps.cx> Mail-Followup-To: freebsd-current@freebsd.org References: <86n0188cfa.fsf@kamino.rfc1149.org> <20040809072854.I22209-100000@moo.sysabend.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040809072854.I22209-100000@moo.sysabend.org> X-Date-in-Rome: ante diem V Idius Augustas MMDCCLVII ab Urbe Condida X-PGP-Fingerprint: FA74 3C27 91A6 79D5 F6D3 FC53 BF4B D0E6 049D B879 X-Message-Flag: Get a proper mailclient! User-Agent: Mutt/1.5.6i Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 22:24:04 -0000 On 2004-08-09 07:34:24 (-0700), Jamie Bowden wrote: > On Fri, 6 Aug 2004, Arne Schwabe wrote: > > Anyway pressing buttons of the touchpad and moving the stick gives > > _strange_ effects but I think this time I motivate myself by not using the > > synaptics XFree86 driver, so either I fix it or my mouse is broken :) > > What I want to know is if this addition gives the ability to turn tapping, > and the added features off. If people want that option, we can provide a sysctl for it. I'd like to avoid turning psm into too much of a dumping ground though. Most of what it does should really already be done in moused... > I hate having inadvertant changes in pressure be interpreted by the mouse > driver as a tap. I see what you mean :-) > Software that attempts to be smarter than the user never is. Hardware that implements a kitchen-sink, a walk-in microwave and a hottub is really asking for it though *grin*. I'll see what I can do wrt sysctls to turn things off selectively. - Philip -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. No system is ever completely debugged: Attempts to debug a system will inevitably introduce new bugs that are even harder to find. From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 22:40:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6360316A4F3 for ; Mon, 9 Aug 2004 22:40:40 +0000 (GMT) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.145.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBC9B43D5E for ; Mon, 9 Aug 2004 22:40:39 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 69F384EFCD9; Tue, 10 Aug 2004 06:40:37 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 4A4124EFCD3; Tue, 10 Aug 2004 06:40:37 +0800 (CST) Date: Tue, 10 Aug 2004 06:40:37 +0800 (CST) From: Tai-hwa Liang To: Jiawei Ye In-Reply-To: Message-ID: <04081006355111.73606@www.mmlab.cse.yzu.edu.tw> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: kldload pf failed on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 22:40:47 -0000 On Tue, 10 Aug 2004, Jiawei Ye wrote: > root@chihiro:/usr/src# kldload -v pf > kldload: can't load pf: No such file or directory > root@chihiro:/usr/src# kldload /boot/kernel/pf.ko > root@chihiro:/usr/src# /etc/rc.d/pf restart > Enabling pf. > pf enabled > > Somehow kldload cannot find pf.ko if no specific path is given. This > is a 2 hours old -current. It looks like the default module path, /boot/kernel, was removed from /boot/default/loader.conf on Aug 6. Workaround 1: add /boot/kernel to your module_path. /boot/loader.conf: module_path="/boot/kernel;/boot/modules" Workaround 2: Either load your modules in /boot/loader.conf or load them with the full path. From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 22:42:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B21E16A4CE; Mon, 9 Aug 2004 22:42:17 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEADE43D45; Mon, 9 Aug 2004 22:42:16 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BuIqN-00058p-00; Tue, 10 Aug 2004 00:42:15 +0200 Received: from [217.227.146.85] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BuIqN-0003xj-00; Tue, 10 Aug 2004 00:42:15 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Tue, 10 Aug 2004 00:40:15 +0200 User-Agent: KMail/1.6.2 References: <200408092003.28922.max@love2party.net> <20040809222127.GU64690@camelot.theinternet.com.au> In-Reply-To: <20040809222127.GU64690@camelot.theinternet.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_X1/FBLHox8ZW1cM"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408100040.23324.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: John-Mark Gurney cc: Jiawei Ye Subject: Re: kldload pf failed on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 22:42:17 -0000 --Boundary-02=_X1/FBLHox8ZW1cM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 10 August 2004 00:21, Andrew Milton wrote: > +-------[ Max Laier ]---------------------- > > | On Monday 09 August 2004 18:54, Jiawei Ye wrote: > | > root@chihiro:/usr/src# kldload -v pf > | > kldload: can't load pf: No such file or directory > | > root@chihiro:/usr/src# kldload /boot/kernel/pf.ko > | > root@chihiro:/usr/src# /etc/rc.d/pf restart > | > Enabling pf. > | > pf enabled > | > > | > Somehow kldload cannot find pf.ko if no specific path is given. This > | > is a 2 hours old -current. > | > | Sounds like kldxref didn't finish it's job correctly. Try (as root): > | kldxref /boot/kernel /boot/modules > | and check the output of: > | kldxref -dv /boot/kernel > | for proper pf.ko entries. Please tell me if that did not help or if you > | see anything suspicious in the xref dump. > > I have this same problem with nfsclient and nfsserver being loaded. kldxr= ef > doesn't fix the problem (for me). I figured I just updated at a bad time > since noone else had reported a similar thing occurring (it wasn't a big > drama for me to load those by hand). > > ACPI also doesn't autoload at boot. > > This was from a -current from August 8th. Hmm ... I suspect it's this commit: > jmg =A0 =A0 =A0 =A0 2004-08-06 15:06:06 UTC >=20 > =A0 FreeBSD src repository >=20 > =A0 Modified files: > =A0 =A0 sys/boot/common =A0 =A0 =A0help.common=20 > =A0 =A0 sys/boot/forth =A0 =A0 =A0 loader.conf=20 > =A0 Log: > =A0 remove /boot/kernel from the default path.. =A0There is already code = that > =A0 will prepend the current kernel booting... =A0This prevents a problem= of > =A0 loading /boot/kernel's modules when a different kernel has no modules, > =A0 but you left your module_load=3D"YES" in loader.conf... Can you try to put back the line in question in /boot/loader.conf? I have no idea whatsoever, but don't find anything else suspicious. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_X1/FBLHox8ZW1cM Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBF/1XXyyEoT62BG0RAlApAJ40FsQMxAl9aKMulj5k6iRXyYeRZQCaA318 1h9ByhF4ynU72/fZBNkq4+0= =PX85 -----END PGP SIGNATURE----- --Boundary-02=_X1/FBLHox8ZW1cM-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 22:43:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3ADDA16A4CE for ; Mon, 9 Aug 2004 22:43:15 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3FCB43D4C for ; Mon, 9 Aug 2004 22:43:14 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i79MfhK2063544; Mon, 9 Aug 2004 18:41:44 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i79MfhHU063541; Mon, 9 Aug 2004 18:41:43 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 9 Aug 2004 18:41:43 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Mike Bristow In-Reply-To: <1092044482.20927.35.camel@singsing.eng.demon.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: panic: mutex vr0 not owned at ...if_vr.c:571 when doing ifconfig X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 22:43:15 -0000 On Mon, 9 Aug 2004, Mike Bristow wrote: > On Sat, 2004-08-07 at 18:19, Andreas Kohn wrote: > > Hi, > > > > with sources from earlier today, I get a panic when doing ifconfig (no > > arguments): > > I saw the same thing earlier this week; PR 70189 contains a patch that > works for me. > > (Sorry for the repetition, Andreas: I forgot to CC the list) Hmm. I actually committed a slightly different patch as if_vr.c:1.93 to acquire the lock around vr_setcfg() in vr_miibus_statchg(). Could you check that that also solves the problem? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 22:43:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6697E16A4CE for ; Mon, 9 Aug 2004 22:43:46 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id E386343D48 for ; Mon, 9 Aug 2004 22:43:45 +0000 (GMT) (envelope-from jon.drews@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so159305rnl for ; Mon, 09 Aug 2004 15:43:45 -0700 (PDT) Received: by 10.38.12.77 with SMTP id 77mr1044895rnl; Mon, 09 Aug 2004 15:43:45 -0700 (PDT) Message-ID: <8cb27cbf04080915434b4298de@mail.gmail.com> Date: Mon, 9 Aug 2004 17:43:45 -0500 From: Jon Drews To: freebsd-current@freebsd.org In-Reply-To: <20040809221244.GB14911@fasolt.home.paeps.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040805071236.GA595@loge.nixsys.be> <20040809090723.GI642@loge.nixsys.be> <20040809221244.GB14911@fasolt.home.paeps.cx> Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 22:43:46 -0000 Ok Philip: On Tue, 10 Aug 2004 00:12:44 +0200, Philip Paeps wrote: > Mmm, oh, right. Verbose isn't verbose enough for psm, I'm afraid you'll have > to compile a kernel with options PSM_DEBUG=2. I'll have to remember to stick > the probe-messages under a normal verbose. No problem -- give me two and a half hours and I will be back with a new posting. Kind regards, Jonathan From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 22:48:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BE4A16A4CE; Mon, 9 Aug 2004 22:48:06 +0000 (GMT) Received: from lakermmtao09.cox.net (lakermmtao09.cox.net [68.230.240.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id B28B343D41; Mon, 9 Aug 2004 22:48:05 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.71.51]) by lakermmtao09.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP <20040809224803.JSAA20883.lakermmtao09.cox.net@dolphin.local.net>; Mon, 9 Aug 2004 18:48:03 -0400 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with ESMTP id i79Mm454011101; Mon, 9 Aug 2004 17:48:04 -0500 (CDT) (envelope-from conrads@dolphin.local.net) Received: (from conrads@localhost) by dolphin.local.net (8.13.1/8.13.1/Submit) id i79MlxZu011100; Mon, 9 Aug 2004 17:47:59 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Mon, 09 Aug 2004 17:47:59 -0500 (CDT) Organization: A Rag-Tag Band of Drug-Crazed Hippies From: "Conrad J. Sabatier" To: freebsd-amd64@freebsd.org cc: freebsd-current@freebsd.org Subject: cvsup on amd64 just broke today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conrads@cox.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 22:48:06 -0000 # make update -------------------------------------------------------------- >>> Running /usr/local/bin/cvsup -------------------------------------------------------------- /usr/local/libexec/cvsup-static.i386.bin: 1: Syntax error: "(" unexpected *** Error code 2 Stop in /usr/ports. -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 22:53:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BC8816A4CE for ; Mon, 9 Aug 2004 22:53:07 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5944F43D1D for ; Mon, 9 Aug 2004 22:53:07 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 27118 invoked from network); 9 Aug 2004 22:53:07 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 9 Aug 2004 22:53:06 -0000 Received: from hydrogen.funkthat.com (lmrwvm@localhost.funkthat.com [127.0.0.1])i79Mr5uU063085; Mon, 9 Aug 2004 15:53:05 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i79Mqtvw063084; Mon, 9 Aug 2004 15:52:55 -0700 (PDT) Date: Mon, 9 Aug 2004 15:52:55 -0700 From: John-Mark Gurney To: Max Laier Message-ID: <20040809225255.GI991@funkthat.com> Mail-Followup-To: Max Laier , freebsd-current@freebsd.org, Andrew Milton , Jiawei Ye References: <200408092003.28922.max@love2party.net> <20040809222127.GU64690@camelot.theinternet.com.au> <200408100040.23324.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200408100040.23324.max@love2party.net> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-current@freebsd.org cc: Jiawei Ye Subject: Re: kldload pf failed on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 22:53:07 -0000 Max Laier wrote this message on Tue, Aug 10, 2004 at 00:40 +0200: > > | On Monday 09 August 2004 18:54, Jiawei Ye wrote: > > | > root@chihiro:/usr/src# kldload -v pf > > | > kldload: can't load pf: No such file or directory > > | > root@chihiro:/usr/src# kldload /boot/kernel/pf.ko > > | > root@chihiro:/usr/src# /etc/rc.d/pf restart > > | > Enabling pf. > > | > pf enabled > > | > > > | > Somehow kldload cannot find pf.ko if no specific path is given. This > > | > is a 2 hours old -current. > > | > > | Sounds like kldxref didn't finish it's job correctly. Try (as root): > > | kldxref /boot/kernel /boot/modules > > | and check the output of: > > | kldxref -dv /boot/kernel > > | for proper pf.ko entries. Please tell me if that did not help or if you > > | see anything suspicious in the xref dump. > > > > I have this same problem with nfsclient and nfsserver being loaded. kldxref > > doesn't fix the problem (for me). I figured I just updated at a bad time > > since noone else had reported a similar thing occurring (it wasn't a big > > drama for me to load those by hand). > > > > ACPI also doesn't autoload at boot. > > > > This was from a -current from August 8th. > > Hmm ... I suspect it's this commit: > > jmg         2004-08-06 15:06:06 UTC > > > >   FreeBSD src repository > > > >   Modified files: > >     sys/boot/common      help.common > >     sys/boot/forth       loader.conf > >   Log: > >   remove /boot/kernel from the default path..  There is already code that > >   will prepend the current kernel booting...  This prevents a problem of > >   loading /boot/kernel's modules when a different kernel has no modules, > >   but you left your module_load="YES" in loader.conf... > > Can you try to put back the line in question in /boot/loader.conf? > > I have no idea whatsoever, but don't find anything else suspicious. Ok, on the kernel boot, please send me: sysctl kern.bootfile kern.module_path ls /boot/ Make sure that you're current kernel is built to include modules. We no longer will load the default kernel's modules for other kernels. So if you boot kernel.test (or other kernel) that does not have pf.ko, you can't load pf.ko anymore. Note, I just tried to kldload pf on my system with the above change, and at first it failed just like your case, but that was because I was on a kernel w/o any kernel modules. When I rebooted back to the regular kernel, kldload pf worked perfectly... the unload didn't go so well: kldlopeabody# kldload pf peabody# kldunload pf panic: mutex if_clone loc -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 22:59:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 182F416A4CE for ; Mon, 9 Aug 2004 22:59:23 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id D02A343D39 for ; Mon, 9 Aug 2004 22:59:22 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BuJ6r-0003jl-00; Tue, 10 Aug 2004 00:59:17 +0200 Received: from [217.227.146.85] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BuJ6r-0006XC-00; Tue, 10 Aug 2004 00:59:17 +0200 From: Max Laier To: John-Mark Gurney Date: Tue, 10 Aug 2004 00:57:18 +0200 User-Agent: KMail/1.6.2 References: <200408100040.23324.max@love2party.net> <20040809225255.GI991@funkthat.com> In-Reply-To: <20040809225255.GI991@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_VFAGBuIGpWfWcKC"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408100057.25718.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: freebsd-current@freebsd.org cc: Jiawei Ye Subject: kldunload pf panic [Re: kldload pf failed on -current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 22:59:23 -0000 --Boundary-02=_VFAGBuIGpWfWcKC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 10 August 2004 00:52, John-Mark Gurney wrote: <...> > kldlopeabody# kldload pf > peabody# kldunload pf > panic: mutex if_clone loc That should be fixed with if_clone.c#rev.1.2 from 2weeks ago, please tell m= e=20 if it if persistent, though. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_VFAGBuIGpWfWcKC Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBGAFVXyyEoT62BG0RAowmAJ48Seg+wns9Q4JRJFPKQrxH5AZhUgCfUBIc EO/8cJF2F0pZhIuLsd4hVzE= =Yuyi -----END PGP SIGNATURE----- --Boundary-02=_VFAGBuIGpWfWcKC-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 23:49:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1F8D16A4CE for ; Mon, 9 Aug 2004 23:49:33 +0000 (GMT) Received: from smtp06.web.de (smtp06.web.de [217.72.192.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77F6843D1F for ; Mon, 9 Aug 2004 23:49:33 +0000 (GMT) (envelope-from eugene3@web.de) Received: from [217.228.127.32] (helo=[192.168.0.3]) by smtp06.web.de with asmtp (WEB.DE 4.101 #44) id 1BuJtU-0005yx-00 for freebsd-current@freebsd.org; Tue, 10 Aug 2004 01:49:32 +0200 Message-ID: <41180D8E.6010200@web.de> Date: Tue, 10 Aug 2004 01:49:34 +0200 From: Eugene User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.7.1) Gecko/20040707 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20040809200645.567FF16A4DC@hub.freebsd.org> In-Reply-To: <20040809200645.567FF16A4DC@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: eugene3@web.de X-Sender: eugene3@web.de Subject: panic: mutex Giant owned at /usr/src/sys/kern/kern_descrip.c:385 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 23:49:33 -0000 hi the following panic occured on the following system 5.2-current aug 07 2004 i386: panic: mutex Giant owned at /usr/src/sys/kern/kern_descrip.c:385 KDB: enter: panic [thread 100129] stopped at kbd_enter+0x30 panic() at panic+0xcc _mtx_assert() at _mtx_assert+0xfc kern_fcntl() at kern_fcntl+0x238 fcnt_common() at fcnt_common+0x70 linux_fnctl84() at linux_fcntl84+0x17c syscall(2f,2f,2f,0,bfbfef24) at syscall+0x272 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall(221,Linux ELF,linux_fcntl84,eip = 0x805aafc, esp = 0xbfbfed0c, ebp = 0xbfbfed58) --- i was at "make install" in /usr/ports/java/jdk14 and i guess from the kernel-panic-message that the linux emulation is broken i hope i have not too much typos in the panic message :-/ i noticed after i did a "make update" in /usr/src today that kern_descrip.c was updated... but it was updated in the past too, so maybe its allready fixed, but maybe it was broken in some recent commit... hope that helps, Eugene From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 23:51:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4F7E16A4CE for ; Mon, 9 Aug 2004 23:51:34 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id A734643D41 for ; Mon, 9 Aug 2004 23:51:34 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) i79NpYls042501; Mon, 9 Aug 2004 16:51:34 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)i79NpYrp042500; Mon, 9 Aug 2004 16:51:34 -0700 (PDT) (envelope-from sgk) Date: Mon, 9 Aug 2004 16:51:34 -0700 From: Steve Kargl To: Eugene Message-ID: <20040809235134.GA42449@troutmask.apl.washington.edu> References: <20040809200645.567FF16A4DC@hub.freebsd.org> <41180D8E.6010200@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41180D8E.6010200@web.de> User-Agent: Mutt/1.4.1i cc: freebsd-current@freebsd.org Subject: Re: panic: mutex Giant owned at /usr/src/sys/kern/kern_descrip.c:385 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 23:51:34 -0000 On Tue, Aug 10, 2004 at 01:49:34AM +0200, Eugene wrote: > hi > > the following panic occured on the following system > > 5.2-current aug 07 2004 i386: > > panic: mutex Giant owned at /usr/src/sys/kern/kern_descrip.c:385 > KDB: enter: panic > [thread 100129] (snip) > i noticed after i did a "make update" in /usr/src today that > kern_descrip.c was updated... but it was updated in the past too, so > maybe its allready fixed, but maybe it was broken in some recent commit... This is fixed. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 00:09:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85B3016A4CE for ; Tue, 10 Aug 2004 00:09:00 +0000 (GMT) Received: from lakermmtao03.cox.net (lakermmtao03.cox.net [68.230.240.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 168B843D1F for ; Tue, 10 Aug 2004 00:09:00 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.71.51]) by lakermmtao03.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP <20040810000852.FXSN16641.lakermmtao03.cox.net@dolphin.local.net>; Mon, 9 Aug 2004 20:08:52 -0400 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with ESMTP id i7A08rAf023541; Mon, 9 Aug 2004 19:08:53 -0500 (CDT) (envelope-from conrads@dolphin.local.net) Received: (from conrads@localhost) by dolphin.local.net (8.13.1/8.13.1/Submit) id i7A08mZB023540; Mon, 9 Aug 2004 19:08:48 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <44129.12.148.147.242.1092077172.squirrel@[12.148.147.242]> Date: Mon, 09 Aug 2004 19:08:48 -0500 (CDT) Organization: A Rag-Tag Band of Drug-Crazed Hippies From: "Conrad J. Sabatier" To: Rusty Nejdl cc: freebsd-current@freebsd.org cc: Dan Nelson Subject: Re: Is anything being done re: the pcm timeout issue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conrads@cox.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 00:09:00 -0000 On 09-Aug-2004 Rusty Nejdl wrote: > Conrad J. Sabatier said: >> >> My problems are occurring on an amd64 box (Athlon 64) with the >> nVidia nForce3 chipset (snd_ich driver). >> >> Sounds works fine for a while, then suddenly I get a pcm play >> timeout, and game over. Have to reboot to get sound to work again. >> >> Others have reported similar problems, but I've seen no followups >> indicating anything is being done about it. >> > > I've been seeing a sound issue on 5.2.1-release and I wonder if it's > related at all to what you are seeing. I have : > > hw.snd.maxautovchans: 4 > hw.snd.pcm0.vchans: 4 > > And I have seen that these will eventually stop working one by one > until I have none left. lsof and fstat don't show any programs using > them, but nonetheless, programms like xmms and gaim can't use them > anymore. > > Do you have any more details on the pcm play timeout? Are you using > vchans? What program are you using? No, no vchans in use here. My main audio app is madplay, which I run from a little "jukebox" script I wrote to play my MP3s. I've been unable to determine what's triggering the breakage myself. The script runs fine for a while, selecting random MP3 files and running madplay to play them one by one. Suddenly, madplay will output the message "output: write failed" (or something like that) and my system log will show "pcm0:play:0: play interrupt timeout, channel dead". After that, any further attempts to play a sound file of any sort result in only a split-second of sound followed by the same messages as above. The only cure is a reboot. I posted some truss output from madplay a while back, but it's probably not very useful, since a timeout had already occurred in a previous run, so the listing only showed what was happening once the device had already become broken. Catching it "in the act", so to speak, is tricky, as it may work fine for an hour or two before the first breakage occurs. This would require a HUGE amount of truss or ktrace logging. We had a discussion recently here about certain peculiarities in the sound code, but never reached any useful conclusions, and none of our sound experts ever joined in, either. I would hate to see 5.3 released with this problem still unsolved, but it's beginning to look like that may, in fact, be the case, unfortunately. I had hoped, too, that by this time we would have seen the new MIDI code incorporated into the tree as well, but it seems that sound (other than the abrupt yanking of the previous MIDI code and the recent renaming of devices/drivers) is being sadly neglected lately. Perhaps I'm wrong on that and there's a lot of behind-the-scenes work going on. We're just not hearing anything lately, though, as to the state of sound on FreeBSD, and it's really beginning to concern me a lot. I realize I'm running amd64, and that problems are to be expected still at this point, but the total lack of activity on the sound front lately is leaving me increasingly pessimistic about FreeBSD's potential for ever becoming a viable audio/music production environment. I hate to say it, but AGNULA, a highly customized version of Debian or Redhat (comes in both flavors) aimed at providing a rich environment for audio/music production, is looking more and more tempting all the time. I would hate to have to go that route, but I'm having serious doubts that FreeBSD will ever be competitive with Linux/ALSA in the sound arena, which is really a shame, as it is otherwise such a superb system. -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 01:09:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 850F716A4CF; Tue, 10 Aug 2004 01:09:47 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0593043D55; Tue, 10 Aug 2004 01:09:47 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7A19e8U012800; Mon, 9 Aug 2004 18:09:41 -0700 Message-ID: <41182054.7090109@root.org> Date: Mon, 09 Aug 2004 18:09:40 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org References: <41131EEC.4050909@root.org> <291946042.22742@mails.tsinghua.edu.cn> In-Reply-To: <291946042.22742@mails.tsinghua.edu.cn> Content-Type: multipart/mixed; boundary="------------090409010109040308080807" cc: Luo Hong Subject: Re: PLEASE TEST: acpi pci irq routing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 01:09:47 -0000 This is a multi-part message in MIME format. --------------090409010109040308080807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks for all the feedback to everyone who responded. I have finished reworking our PCI irq routing approach and the result is much simpler while retaining the existing weighting algorithm from acpi_pci_link.c (around since Oct. 2002). It removes the hack which causes the first IRQ to be chosen from possible IRQs if the BIOS hasn't routed an interrupt. The selection algorithm is to always use the BIOS irq, if valid, and then select from the weighted priority list if that fails. I've tested both approaches fully. Please test this patch to be sure all PCI devices continue (or begin) to function as expected. If something fails for you, please send me the dmesg from boot -v. Thanks, Nate --------------090409010109040308080807 Content-Type: text/plain; name="pci_link.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pci_link.diff" Index: acpi_pci_link.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_pci_link.c,v retrieving revision 1.18 diff -u -r1.18 acpi_pci_link.c --- acpi_pci_link.c 6 Aug 2004 04:50:56 -0000 1.18 +++ acpi_pci_link.c 10 Aug 2004 00:56:52 -0000 @@ -24,9 +24,6 @@ * SUCH DAMAGE. */ -/* XXX Uncomment this if you have new PCI IRQ problems starting 2004/8/5. */ -/* #define ACPI_OLD_PCI_LINK 1 */ - #include __FBSDID("$FreeBSD: src/sys/dev/acpica/acpi_pci_link.c,v 1.18 2004/08/06 04:50:56 njl Exp $"); @@ -39,43 +36,27 @@ #include #include +#include +#include "pcib_if.h" + /* Hooks for the ACPI CA debugging infrastructure. */ #define _COMPONENT ACPI_BUS ACPI_MODULE_NAME("PCI_LINK") -#define MAX_POSSIBLE_INTERRUPTS 16 -#define MAX_ISA_INTERRUPTS 16 -#define MAX_ACPI_INTERRUPTS 255 - -struct acpi_pci_link_entry { - TAILQ_ENTRY(acpi_pci_link_entry) links; - ACPI_HANDLE handle; - UINT8 current_irq; - UINT8 initial_irq; - ACPI_RESOURCE possible_resources; - UINT8 number_of_interrupts; - UINT8 interrupts[MAX_POSSIBLE_INTERRUPTS]; - UINT8 sorted_irq[MAX_POSSIBLE_INTERRUPTS]; - int references; - int priority; -}; - TAILQ_HEAD(acpi_pci_link_entries, acpi_pci_link_entry); static struct acpi_pci_link_entries acpi_pci_link_entries; -struct acpi_prt_entry { - TAILQ_ENTRY(acpi_prt_entry) links; - device_t pcidev; - int busno; - ACPI_PCI_ROUTING_TABLE prt; - struct acpi_pci_link_entry *pci_link; -}; - TAILQ_HEAD(acpi_prt_entries, acpi_prt_entry); static struct acpi_prt_entries acpi_prt_entries; static int irq_penalty[MAX_ACPI_INTERRUPTS]; +static int acpi_pci_link_is_valid_irq(struct acpi_pci_link_entry *link, + UINT8 irq); +static void acpi_pci_link_update_irq_penalty(device_t dev, int busno); +static void acpi_pci_link_set_bootdisabled_priority(void); +static void acpi_pci_link_fixup_bootdisabled_link(void); + /* * PCI link object management */ @@ -137,27 +118,31 @@ UINT8 i; ACPI_RESOURCE_IRQ *Irq; ACPI_RESOURCE_EXT_IRQ *ExtIrq; + struct acpi_pci_link_entry *link; if (entry == NULL || entry->pci_link == NULL) return; + link = entry->pci_link; - printf("%s irq %3d: ", acpi_name(entry->pci_link->handle), - entry->pci_link->current_irq); + printf("%s irq%c%2d: ", acpi_name(link->handle), + (link->flags & ACPI_LINK_ROUTED) ? '*' : ' ', link->current_irq); printf("["); - for (i = 0; i < entry->pci_link->number_of_interrupts; i++) - printf("%3d", entry->pci_link->interrupts[i]); - printf("] "); + if (link->number_of_interrupts) + printf("%2d", link->interrupts[0]); + for (i = 1; i < link->number_of_interrupts; i++) + printf("%3d", link->interrupts[i]); + printf("] %2d+ ", link->initial_irq); - switch (entry->pci_link->possible_resources.Id) { + switch (link->possible_resources.Id) { case ACPI_RSTYPE_IRQ: - Irq = &entry->pci_link->possible_resources.Data.Irq; + Irq = &link->possible_resources.Data.Irq; acpi_pci_link_dump_polarity(Irq->ActiveHighLow); acpi_pci_link_dump_trigger(Irq->EdgeLevel); acpi_pci_link_dump_sharemode(Irq->SharedExclusive); break; case ACPI_RSTYPE_EXT_IRQ: - ExtIrq = &entry->pci_link->possible_resources.Data.ExtendedIrq; + ExtIrq = &link->possible_resources.Data.ExtendedIrq; acpi_pci_link_dump_polarity(ExtIrq->ActiveHighLow); acpi_pci_link_dump_trigger(ExtIrq->EdgeLevel); acpi_pci_link_dump_sharemode(ExtIrq->SharedExclusive); @@ -370,17 +355,34 @@ buf.Length = ACPI_ALLOCATE_BUFFER; bzero(link, sizeof(struct acpi_pci_link_entry)); - link->handle = handle; + /* + * Get the IRQ configured at boot-time. If successful, set this + * as the initial IRQ. + */ error = acpi_pci_link_get_current_irq(link, &link->current_irq); - if (ACPI_FAILURE(error)) { + if (ACPI_SUCCESS(error)) { + link->initial_irq = link->current_irq; + } else { ACPI_DEBUG_PRINT((ACPI_DB_WARN, "couldn't get current IRQ from interrupt link %s - %s\n", acpi_name(handle), AcpiFormatException(error))); + link->initial_irq = 0; } - link->initial_irq = link->current_irq; + /* + * Try to disable this link. If successful, set the current IRQ to + * zero and flags to indicate this link is not routed. If we can't + * run _DIS (i.e., the method doesn't exist), assume the initial + * IRQ was routed by the BIOS. + */ + if (ACPI_SUCCESS(AcpiEvaluateObject(handle, "_DIS", NULL, NULL))) { + link->current_irq = 0; + link->flags = ACPI_LINK_NONE; + } else { + link->flags = ACPI_LINK_ROUTED; + } error = AcpiGetPossibleResources(handle, &buf); if (ACPI_FAILURE(error)) { @@ -396,6 +398,7 @@ goto out; } + /* XXX This only handles one resource, ignoring SourceIndex. */ resources = (ACPI_RESOURCE *) buf.Pointer; bcopy(resources, &link->possible_resources, sizeof(link->possible_resources)); @@ -417,6 +420,19 @@ goto out; } + /* + * If the initial IRQ is invalid (not in _PRS), set it to 0 and + * mark this link as not routed. We won't use it as the preferred + * interrupt later when we route. + */ + if (!acpi_pci_link_is_valid_irq(link, link->initial_irq) && + link->initial_irq != 0) { + printf("ACPI link %s has invalid initial irq %d, ignoring\n", + acpi_name(handle), link->initial_irq); + link->initial_irq = 0; + link->flags = ACPI_LINK_NONE; + } + link->references++; TAILQ_INSERT_TAIL(&acpi_pci_link_entries, link, links); @@ -467,17 +483,9 @@ * PCI link status (_STA) is unreliable. Many systems return * erroneous values so we ignore it. */ - if ((sta & (ACPI_STA_PRESENT | ACPI_STA_FUNCTIONAL)) == 0) { -#ifndef ACPI_OLD_PCI_LINK + if ((sta & (ACPI_STA_PRESENT | ACPI_STA_FUNCTIONAL)) == 0) device_printf(pcidev, "acpi PRT ignoring status for %s\n", acpi_name(handle)); -#else - ACPI_DEBUG_PRINT((ACPI_DB_ERROR, - "interrupt link is not functional - %s\n", - acpi_name(handle))); - return_ACPI_STATUS (AE_ERROR); -#endif /* !ACPI_OLD_PCI_LINK */ - } TAILQ_FOREACH(entry, &acpi_prt_entries, links) { if (entry->busno == busno && @@ -502,6 +510,17 @@ entry->busno = busno; bcopy(prt, &entry->prt, sizeof(entry->prt)); + /* + * Make sure the Source value is null-terminated. It is really a + * variable-length string (with a fixed size in the struct) so when + * we copy the entire struct, we truncate the string. Instead of + * trying to make a variable-sized PRT object to handle the string, + * we store its handle in prt_source. Callers should use that to + * look up the link object. + */ + entry->prt.Source[sizeof(prt->Source) - 1] = '\0'; + entry->prt_source = handle; + error = acpi_pci_link_add_link(handle, entry); if (ACPI_FAILURE(error)) { ACPI_DEBUG_PRINT((ACPI_DB_ERROR, @@ -520,6 +539,12 @@ return_ACPI_STATUS (error); } +/* + * Look up the given interrupt in the list of possible settings for + * this link. We don't special-case the initial link setting. Some + * systems return current settings that are outside the list of valid + * settings so only allow choices explicitly specified in _PRS. + */ static int acpi_pci_link_is_valid_irq(struct acpi_pci_link_entry *link, UINT8 irq) { @@ -528,28 +553,11 @@ if (irq == 0) return (FALSE); -#ifndef ACPI_OLD_PCI_LINK - /* - * Look up the given interrupt in the list of possible settings for - * this link. We don't special-case the initial link setting. Some - * systems return current settings that are outside the list of valid - * settings so only allow choices explicitly specified in _PRS. - */ -#endif for (i = 0; i < link->number_of_interrupts; i++) { if (link->interrupts[i] == irq) return (TRUE); } - /* allow initial IRQ as valid one. */ - if (link->initial_irq == irq) -#ifndef ACPI_OLD_PCI_LINK - printf("acpi link check: %d initial irq, %d irq to route\n", - link->initial_irq, irq); -#else - return (TRUE); -#endif - return (FALSE); } @@ -559,27 +567,24 @@ ACPI_STATUS error; ACPI_RESOURCE resbuf; ACPI_BUFFER crsbuf; - UINT32 sta; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + /* Make sure the new IRQ is valid before routing. */ if (!acpi_pci_link_is_valid_irq(link, irq)) { - ACPI_DEBUG_PRINT((ACPI_DB_ERROR, - "couldn't set invalid IRQ %d - %s\n", irq, - acpi_name(link->handle))); + printf("acpi link: can't set invalid IRQ %d on %s\n", + irq, acpi_name(link->handle)); return_ACPI_STATUS (AE_BAD_PARAMETER); } - error = acpi_pci_link_get_current_irq(link, &link->current_irq); - if (ACPI_FAILURE(error)) { - ACPI_DEBUG_PRINT((ACPI_DB_WARN, - "couldn't get current IRQ from interrupt link %s - %s\n", - acpi_name(link->handle), AcpiFormatException(error))); - } - - if (link->current_irq == irq) + /* If this this link has already been routed, just return. */ + if (link->flags & ACPI_LINK_ROUTED) { + printf("link %s already routed to %d\n", + acpi_name(link->handle), link->current_irq); return_ACPI_STATUS (AE_OK); + } + /* Set up the IRQ resource for _SRS. */ bzero(&resbuf, sizeof(resbuf)); crsbuf.Pointer = NULL; @@ -624,41 +629,16 @@ return_ACPI_STATUS (AE_NO_MEMORY); } + /* Make the new IRQ active via the link's _SRS method. */ error = AcpiSetCurrentResources(link->handle, &crsbuf); if (ACPI_FAILURE(error)) { ACPI_DEBUG_PRINT((ACPI_DB_WARN, "couldn't set link device _SRS %s - %s\n", acpi_name(link->handle), AcpiFormatException(error))); - return_ACPI_STATUS (error); + goto out; } - - AcpiOsFree(crsbuf.Pointer); + link->flags |= ACPI_LINK_ROUTED; link->current_irq = 0; - error = AE_OK; - - /* - * PCI link status (_STA) is unreliable. Many systems return - * erroneous values so we ignore it. - */ - error = acpi_pci_link_get_object_status(link->handle, &sta); - if (ACPI_FAILURE(error)) { - ACPI_DEBUG_PRINT((ACPI_DB_WARN, - "couldn't get object status %s - %s\n", - acpi_name(link->handle), AcpiFormatException(error))); - return_ACPI_STATUS (error); - } - - if ((sta & ACPI_STA_ENABLED) == 0) { -#ifndef ACPI_OLD_PCI_LINK - printf("acpi link set: ignoring status for %s\n", - acpi_name(link->handle)); -#else - ACPI_DEBUG_PRINT((ACPI_DB_WARN, - "interrupt link %s is disabled\n", - acpi_name(link->handle))); - return_ACPI_STATUS (AE_ERROR); -#endif /* !ACPI_OLD_PCI_LINK */ - } /* * Many systems always return invalid values for current settings @@ -670,26 +650,17 @@ ACPI_DEBUG_PRINT((ACPI_DB_WARN, "couldn't get current IRQ from interrupt link %s - %s\n", acpi_name(link->handle), AcpiFormatException(error))); - return_ACPI_STATUS (error); + goto out; } - - if (link->current_irq == irq) { - error = AE_OK; - } else { -#ifndef ACPI_OLD_PCI_LINK + if (link->current_irq != irq) { printf("acpi link set: curr irq %d != %d for %s (ignoring)\n", link->current_irq, irq, acpi_name(link->handle)); link->current_irq = irq; - error = AE_OK; -#else - ACPI_DEBUG_PRINT((ACPI_DB_WARN, - "couldn't set IRQ %d to PCI interrupt link %d - %s\n", - irq, link->current_irq, acpi_name(link->handle))); - link->current_irq = 0; - error = AE_ERROR; -#endif /* !ACPI_OLD_PCI_LINK */ } +out: + if (crsbuf.Pointer) + AcpiOsFree(crsbuf.Pointer); return_ACPI_STATUS (error); } @@ -709,49 +680,55 @@ if (link->current_irq != 0) continue; - printf("%s:\n", acpi_name(link->handle)); - printf(" interrupts: "); + printf("%s (references %d, priority %d):\n", + acpi_name(link->handle), link->references, link->priority); + printf("\tinterrupts:\t"); for (i = 0; i < link->number_of_interrupts; i++) { irq = link->sorted_irq[i]; printf("%6d", irq); } printf("\n"); - printf(" penalty: "); + printf("\tpenalty:\t"); for (i = 0; i < link->number_of_interrupts; i++) { irq = link->sorted_irq[i]; printf("%6d", irq_penalty[irq]); } printf("\n"); - printf(" references: %d\n", link->references); - printf(" priority: %d\n", link->priority); } } +/* + * Heuristics for choosing IRQs. We start with some static penalties, + * update them based on what IRQs are currently in use, then sort the + * result. This works ok but is not perfect. + * + * The PCI BIOS $PIR table offers "preferred PCI interrupts", but ACPI + * doesn't seem to offer a similar mechanism, so picking a good + * interrupt here is a difficult task. + */ static void acpi_pci_link_init_irq_penalty(void) { - int irq; bzero(irq_penalty, sizeof(irq_penalty)); - for (irq = 0; irq < MAX_ISA_INTERRUPTS; irq++) { - /* 0, 1, 2, 8: timer, keyboard, cascade */ - if (irq == 0 || irq == 1 || irq == 2 || irq == 8) { - irq_penalty[irq] = 100000; - continue; - } - - /* 13, 14, 15: npx, ATA controllers */ - if (irq == 13 || irq == 14 || irq == 15) { - irq_penalty[irq] = 10000; - continue; - } - /* 3,4,6,7,12: typicially used by legacy hardware */ - if (irq == 3 || irq == 4 || irq == 6 || irq == 7 || irq == 12) { - irq_penalty[irq] = 1000; - continue; - } - } + /* 0, 1, 2, 8: timer, keyboard, cascade, RTC */ + irq_penalty[0] = 100000; + irq_penalty[1] = 100000; + irq_penalty[2] = 100000; + irq_penalty[8] = 100000; + + /* 13, 14, 15: npx, ATA controllers */ + irq_penalty[13] = 10000; + irq_penalty[14] = 10000; + irq_penalty[15] = 10000; + + /* 3, 4, 6, 7, 12: typically used by legacy hardware */ + irq_penalty[3] = 1000; + irq_penalty[4] = 1000; + irq_penalty[6] = 1000; + irq_penalty[7] = 1000; + irq_penalty[12] = 1000; } static int @@ -761,15 +738,15 @@ if (res == NULL || (res->Id != ACPI_RSTYPE_IRQ && res->Id != ACPI_RSTYPE_EXT_IRQ)) - return (0); + return (FALSE); if ((res->Id == ACPI_RSTYPE_IRQ && res->Data.Irq.SharedExclusive == ACPI_EXCLUSIVE) || (res->Id == ACPI_RSTYPE_EXT_IRQ && res->Data.ExtendedIrq.SharedExclusive == ACPI_EXCLUSIVE)) - return (1); + return (TRUE); - return (0); + return (FALSE); } static void @@ -791,13 +768,7 @@ if (link == NULL) continue; - if (link->current_irq != 0) { - /* not boot-disabled link, we will use this IRQ. */ - irq_penalty[link->current_irq] += 100; - continue; - } - - /* boot-disabled link */ + /* Update penalties for all possible settings of this link. */ for (i = 0; i < link->number_of_interrupts; i++) { /* give 10 for each possible IRQs. */ irq = link->interrupts[i]; @@ -815,8 +786,8 @@ bus_release_resource(dev, SYS_RES_IRQ, rid, res); } else { - /* this is in use, give 100. */ - irq_penalty[irq] += 100; + /* this is in use, give 10. */ + irq_penalty[irq] += 10; } } @@ -835,18 +806,13 @@ struct acpi_pci_link_entry *link, *link_pri; TAILQ_HEAD(, acpi_pci_link_entry) sorted_list; - if (bootverbose) { - printf("ACPI PCI link before setting link priority:\n"); - acpi_pci_link_bootdisabled_dump(); - } - /* reset priority for all links. */ TAILQ_FOREACH(link, &acpi_pci_link_entries, links) link->priority = 0; TAILQ_FOREACH(link, &acpi_pci_link_entries, links) { - /* not boot-disabled link, give no chance to be arbitrated. */ - if (link->current_irq != 0) { + /* If already routed, don't include in arbitration. */ + if (link->flags & ACPI_LINK_ROUTED) { link->priority = 0; continue; } @@ -898,16 +864,10 @@ int i, j; int irq1, irq2; struct acpi_pci_link_entry *link; - ACPI_STATUS error; - - if (bootverbose) { - printf("ACPI PCI link before fixup for boot-disabled links:\n"); - acpi_pci_link_bootdisabled_dump(); - } TAILQ_FOREACH(link, &acpi_pci_link_entries, links) { - /* ignore non boot-disabled links. */ - if (link->current_irq != 0) + /* Ignore links that have been routed already. */ + if (link->flags & ACPI_LINK_ROUTED) continue; /* sort IRQs based on their penalty descending. */ @@ -923,21 +883,10 @@ irq1 = irq2; } } - - /* try with lower penalty IRQ. */ - for (i = 0; i < link->number_of_interrupts; i++) { - irq1 = link->sorted_irq[i]; - error = acpi_pci_link_set_irq(link, irq1); - if (error == AE_OK) { - /* OK, we use this. give another penalty. */ - irq_penalty[irq1] += 100 * link->references; - break; - } - } } if (bootverbose) { - printf("ACPI PCI link after fixup for boot-disabled links:\n"); + printf("ACPI PCI link arbitrated settings:\n"); acpi_pci_link_bootdisabled_dump(); } } @@ -953,7 +902,7 @@ ACPI_PCI_ROUTING_TABLE *prt; u_int8_t *prtp; ACPI_STATUS error; - static int first_time =1; + static int first_time = 1; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); @@ -1036,27 +985,14 @@ entry->pci_link->current_irq = 0; } - /* auto arbitration */ - acpi_pci_link_update_irq_penalty(dev, busno); - acpi_pci_link_set_bootdisabled_priority(); - acpi_pci_link_fixup_bootdisabled_link(); - - if (bootverbose) { - printf("ACPI PCI link arbitrated configuration:\n"); - TAILQ_FOREACH(entry, &acpi_prt_entries, links) { - if (entry->busno != busno) - continue; - acpi_pci_link_entry_dump(entry); - } - } - return (0); } int -acpi_pci_link_resume(device_t dev, ACPI_BUFFER *prtbuf, int busno) +acpi_pci_link_resume(device_t dev) { struct acpi_prt_entry *entry; + struct acpi_pci_link_entry *link; ACPI_STATUS error; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); @@ -1064,19 +1000,103 @@ if (acpi_disabled("pci_link")) return (0); + /* Walk through all PRT entries for this PCI bridge. */ TAILQ_FOREACH(entry, &acpi_prt_entries, links) { - if (entry->pcidev != dev) + if (entry->pcidev == dev || entry->pci_link == NULL) + continue; + link = entry->pci_link; + + /* If it's not routed, skip re-programming. */ + if ((link->flags & ACPI_LINK_ROUTED) == 0) continue; + link->flags &= ~ACPI_LINK_ROUTED; - error = acpi_pci_link_set_irq(entry->pci_link, - entry->pci_link->current_irq); + /* Program it to the same setting as before suspend. */ + error = acpi_pci_link_set_irq(link, link->current_irq); if (ACPI_FAILURE(error)) { ACPI_DEBUG_PRINT((ACPI_DB_WARN, "couldn't set IRQ to link entry %s - %s\n", - acpi_name(entry->pci_link->handle), + acpi_name(link->handle), AcpiFormatException(error))); } } return (0); } + +/* + * Look up a PRT entry for the given device. We match based on the slot + * number (high word of Address) and pin number (note that ACPI uses 0 + * for INTA). + * + * Note that the low word of the Address field (function number) is + * required by the specification to be 0xffff. We don't risk checking + * it here. + */ +struct acpi_prt_entry * +acpi_pci_find_prt(device_t pcibdev, device_t dev, int pin) +{ + struct acpi_prt_entry *entry; + ACPI_PCI_ROUTING_TABLE *prt; + + TAILQ_FOREACH(entry, &acpi_prt_entries, links) { + prt = &entry->prt; + if ((prt->Address & 0xffff0000) >> 16 == pci_get_slot(dev) && + prt->Pin == pin) + return (entry); + } + return (NULL); +} + +/* + * Perform the actual programming for this link. We attempt to route an + * IRQ, first the one set by the BIOS, and then a priority-sorted list. + * Only do the programming once per link. + */ +int +acpi_pci_link_route(device_t dev, struct acpi_prt_entry *prt) +{ + struct acpi_pci_link_entry *link; + int busno, i, irq; + ACPI_STATUS status; + + busno = pci_get_bus(dev); + link = prt->pci_link; + if (link == NULL || link->number_of_interrupts == 0) + return (PCI_INVALID_IRQ); + + /* If already routed, just return the current setting. */ + if (link->flags & ACPI_LINK_ROUTED) + return (link->current_irq); + + /* Update all IRQ weights to determine our priority list. */ + acpi_pci_link_update_irq_penalty(prt->pcidev, busno); + acpi_pci_link_set_bootdisabled_priority(); + acpi_pci_link_fixup_bootdisabled_link(); + + /* + * First, attempt to route the initial IRQ, if valid, since it was + * the one set up by the BIOS. If this fails, route according to + * our priority-sorted list of IRQs. + */ + status = AE_NOT_FOUND; + irq = link->initial_irq; + if (irq) + status = acpi_pci_link_set_irq(link, irq); + for (i = 0; ACPI_FAILURE(status) && i < link->number_of_interrupts; + i++) { + irq = link->sorted_irq[i]; + status = acpi_pci_link_set_irq(link, irq); + if (ACPI_FAILURE(status)) { + device_printf(dev, "_SRS failed, irq %d via %s\n", + irq, acpi_name(link->handle)); + } + } + if (ACPI_FAILURE(status)) + return (PCI_INVALID_IRQ); + + /* Update the penalty now that there's another user for this IRQ. */ + irq_penalty[irq] += 100 * link->references; + + return (irq); +} Index: acpi_pcib.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_pcib.c,v retrieving revision 1.46 diff -u -r1.46 acpi_pcib.c --- acpi_pcib.c 1 Jul 2004 07:46:27 -0000 1.46 +++ acpi_pcib.c 10 Aug 2004 00:04:33 -0000 @@ -90,316 +90,106 @@ } int -acpi_pcib_resume(device_t dev, ACPI_BUFFER *prt, int busno) +acpi_pcib_resume(device_t dev) { - acpi_pci_link_resume(dev, prt, busno); + acpi_pci_link_resume(dev); return (bus_generic_resume(dev)); } /* * Route an interrupt for a child of the bridge. - * - * XXX clean up error messages - * - * XXX this function is somewhat bulky */ int -acpi_pcib_route_interrupt(device_t pcib, device_t dev, int pin, - ACPI_BUFFER *prtbuf) +acpi_pcib_route_interrupt(device_t pcib, device_t dev, int pin) { + struct acpi_prt_entry *entry; + int i, interrupt; + struct acpi_pci_link_entry *link; + ACPI_RESOURCE *prsres; ACPI_PCI_ROUTING_TABLE *prt; - ACPI_HANDLE lnkdev; - ACPI_BUFFER crsbuf, prsbuf, buf; - ACPI_RESOURCE *crsres, *prsres, resbuf; - ACPI_DEVICE_INFO *devinfo; - ACPI_STATUS status; - UINT32 NumberOfInterrupts; - UINT32 *Interrupts; - u_int8_t *prtp; - int interrupt; - int i; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); - - crsres = NULL; - buf.Pointer = NULL; - crsbuf.Pointer = NULL; - prsbuf.Pointer = NULL; + + prsres = NULL; interrupt = PCI_INVALID_IRQ; /* ACPI numbers pins 0-3, not 1-4 like the BIOS. */ pin--; - /* We failed to retrieve the routing table. */ - prtp = prtbuf->Pointer; - if (prtp == NULL) - goto out; - - /* Scan the table to look for this device. */ - for (;;) { - prt = (ACPI_PCI_ROUTING_TABLE *)prtp; - - /* We hit the end of the table. */ - if (prt->Length == 0) - goto out; - - /* - * Compare the slot number (high word of Address) and pin number - * (note that ACPI uses 0 for INTA) to check for a match. - * - * Note that the low word of the Address field (function number) - * is required by the specification to be 0xffff. We don't risk - * checking it here. - */ - if (((prt->Address & 0xffff0000) >> 16) == pci_get_slot(dev) && - prt->Pin == pin) { - if (bootverbose) - device_printf(pcib, "matched entry for %d.%d.INT%c (src %s)\n", - pci_get_bus(dev), pci_get_slot(dev), 'A' + pin, - prt->Source); - break; - } - - /* Skip to the next entry. */ - prtp += prt->Length; - } + /* Look up the PRT entry for this device. */ + entry = acpi_pci_find_prt(pcib, dev, pin); + if (entry == NULL) + return (AE_ERROR); + prt = &entry->prt; + link = entry->pci_link; + if (bootverbose) + device_printf(pcib, "matched entry for %d.%d.INT%c (src %s)\n", + pci_get_bus(dev), pci_get_slot(dev), 'A' + pin, + acpi_name(entry->prt_source)); /* - * If source is empty/NULL, the source index is the global IRQ number. + * If source is empty/NULL, the source index is a global IRQ number + * and it's hard-wired so we're done. */ if (prt->Source == NULL || prt->Source[0] == '\0') { if (bootverbose) device_printf(pcib, "device is hardwired to IRQ %d\n", - prt->SourceIndex); - interrupt = prt->SourceIndex; - goto out; - } - - /* - * We have to find the source device (PCI interrupt link device). - */ - if (ACPI_FAILURE(AcpiGetHandle(ACPI_ROOT_OBJECT, prt->Source, &lnkdev))) { - device_printf(pcib, "couldn't find PCI interrupt link device %s\n", - prt->Source); - goto out; - } - - /* - * Verify that this is a PCI link device and that it's present. - */ - buf.Length = ACPI_ALLOCATE_BUFFER; - if (ACPI_FAILURE(AcpiGetObjectInfo(lnkdev, &buf))) { - device_printf(pcib, "couldn't validate PCI interrupt link device %s\n", - prt->Source); - goto out; - } - devinfo = (ACPI_DEVICE_INFO *)buf.Pointer; - if ((devinfo->Valid & ACPI_VALID_HID) == 0 || - strcmp("PNP0C0F", devinfo->HardwareId.Value) != 0) { - device_printf(pcib, "PCI interrupt link %s has invalid _HID (%s)\n", - prt->Source, devinfo->HardwareId.Value); - goto out; - } - if ((devinfo->Valid & ACPI_VALID_STA) != 0 && - (devinfo->CurrentStatus & 0x9) != 0x9) { - device_printf(pcib, "PCI interrupt link device %s not present\n", - prt->Source); - goto out; - } - - /* - * Get the current and possible resources for the interrupt link device. - * If we fail to get the current resources, this is a fatal error. - */ - crsbuf.Length = ACPI_ALLOCATE_BUFFER; - if (ACPI_FAILURE(status = AcpiGetCurrentResources(lnkdev, &crsbuf))) { - device_printf(pcib, "PCI interrupt link device _CRS failed - %s\n", - AcpiFormatException(status)); - goto out; - } - prsbuf.Length = ACPI_ALLOCATE_BUFFER; - if (ACPI_FAILURE(status = AcpiGetPossibleResources(lnkdev, &prsbuf))) { - device_printf(pcib, "PCI interrupt link device _PRS failed - %s\n", - AcpiFormatException(status)); - } - ACPI_DEBUG_PRINT((ACPI_DB_RESOURCES, "got %ld bytes for %s._CRS\n", - (long)crsbuf.Length, acpi_name(lnkdev))); - ACPI_DEBUG_PRINT((ACPI_DB_RESOURCES, "got %ld bytes for %s._PRS\n", - (long)prsbuf.Length, acpi_name(lnkdev))); - - /* - * The interrupt may already be routed, so check _CRS first. We don't - * check the 'decoding' bit in the _STA result, since there's nothing in - * the spec that mandates it be set, however some BIOS' will set it if - * the decode is active. - * - * The Source Index points to the particular resource entry we're - * interested in. - */ - if (ACPI_FAILURE(acpi_FindIndexedResource(&crsbuf, prt->SourceIndex, - &crsres))) { - device_printf(pcib, "_CRS buffer corrupt, cannot route interrupt\n"); + prt->SourceIndex); + if (prt->SourceIndex) + interrupt = prt->SourceIndex; + else + device_printf(pcib, "invalid hard-wired IRQ of 0\n"); goto out; } - /* Type-check the resource we've found. */ - if (crsres->Id != ACPI_RSTYPE_IRQ && crsres->Id != ACPI_RSTYPE_EXT_IRQ) { - device_printf(pcib, "_CRS resource entry has unsupported type %d\n", - crsres->Id); + /* XXX Support for multiple resources must be added to the link code. */ + if (prt->SourceIndex) { + device_printf(pcib, "src index %d not yet supported\n", + prt->SourceIndex); goto out; } - /* Set variables based on resource type. */ - if (crsres->Id == ACPI_RSTYPE_IRQ) { - NumberOfInterrupts = crsres->Data.Irq.NumberOfInterrupts; - Interrupts = crsres->Data.Irq.Interrupts; - } else { - NumberOfInterrupts = crsres->Data.ExtendedIrq.NumberOfInterrupts; - Interrupts = crsres->Data.ExtendedIrq.Interrupts; - } - - /* If there's more than one interrupt, this is an error. */ - if (NumberOfInterrupts > 1) { - device_printf(pcib, "device has too many interrupts (%d)\n", - NumberOfInterrupts); + /* There has to be at least one interrupt available. */ + if (link->number_of_interrupts == 0) { + device_printf(pcib, "device has no interrupts\n"); goto out; } /* - * If there's only one interrupt, and it's not zero, then it's already - * routed. - * - * Note that we could also check the 'decoding' bit in _STA, but can't - * depend on it since it's not part of the spec. - * - * XXX check ASL examples to see if this is an acceptable set of tests + * If the current interrupt has been routed, we're done. This is the + * case when the BIOS initializes it and we didn't disable it. */ - if (NumberOfInterrupts == 1 && Interrupts[0] != 0) { + if (link->flags & ACPI_LINK_ROUTED) { + interrupt = link->current_irq; if (bootverbose) - device_printf(pcib, "slot %d INT%c is routed to irq %d\n", - pci_get_slot(dev), 'A' + pin, Interrupts[0]); - interrupt = Interrupts[0]; - goto out; - } - - /* - * There isn't an interrupt, so we have to look at _PRS to get one. - * Get the set of allowed interrupts from the _PRS resource indexed - * by SourceIndex. - */ - if (prsbuf.Pointer == NULL) { - device_printf(pcib, "no routed irq and no _PRS on irq link device\n"); - goto out; - } - - /* - * Search through the _PRS resources, looking for an IRQ or extended - * IRQ resource. Skip dependent function resources for now. In the - * future, we might use these for priority but this is good enough for - * now until BIOS vendors actually mean something by using them. - */ - prsres = NULL; - for (i = prt->SourceIndex; prsres == NULL; i++) { - if (ACPI_FAILURE(acpi_FindIndexedResource(&prsbuf, i, &prsres))) { - device_printf(pcib, "_PRS lacks IRQ resource, routing failed\n"); - goto out; - } - switch (prsres->Id) { - case ACPI_RSTYPE_IRQ: - NumberOfInterrupts = prsres->Data.Irq.NumberOfInterrupts; - Interrupts = prsres->Data.Irq.Interrupts; - break; - case ACPI_RSTYPE_EXT_IRQ: - NumberOfInterrupts = prsres->Data.ExtendedIrq.NumberOfInterrupts; - Interrupts = prsres->Data.ExtendedIrq.Interrupts; - break; - case ACPI_RSTYPE_START_DPF: - prsres = NULL; - continue; - default: - device_printf(pcib, "_PRS has invalid type %d\n", prsres->Id); - goto out; - } - } - - /* There has to be at least one interrupt available. */ - if (NumberOfInterrupts < 1) { - device_printf(pcib, "device has no interrupts\n"); + device_printf(pcib, "slot %d INT%c is already routed to irq %d\n", + pci_get_slot(dev), 'A' + pin, interrupt); goto out; } - /* - * Pick an interrupt to use. Note that a more scientific approach than - * just taking the first one available would be desirable. - * - * The PCI BIOS $PIR table offers "preferred PCI interrupts", but ACPI - * doesn't seem to offer a similar mechanism, so picking a "good" - * interrupt here is a difficult task. - * - * Build a resource buffer and pass it to AcpiSetCurrentResources to - * route the new interrupt. - */ if (bootverbose) { device_printf(pcib, "possible interrupts:"); - for (i = 0; i < NumberOfInterrupts; i++) - printf(" %d", Interrupts[i]); + for (i = 0; i < link->number_of_interrupts; i++) + printf("%3d", link->interrupts[i]); printf("\n"); } - /* This should never happen. */ - if (crsbuf.Pointer != NULL) - AcpiOsFree(crsbuf.Pointer); - - /* XXX Data.Irq and Data.ExtendedIrq are implicitly structure-copied. */ - crsbuf.Pointer = NULL; - crsres = NULL; - if (prsres->Id == ACPI_RSTYPE_IRQ) { - resbuf.Id = ACPI_RSTYPE_IRQ; - resbuf.Length = ACPI_SIZEOF_RESOURCE(ACPI_RESOURCE_IRQ); - resbuf.Data.Irq = prsres->Data.Irq; - resbuf.Data.Irq.NumberOfInterrupts = 1; - resbuf.Data.Irq.Interrupts[0] = Interrupts[0]; - } else { - resbuf.Id = ACPI_RSTYPE_EXT_IRQ; - resbuf.Length = ACPI_SIZEOF_RESOURCE(ACPI_RESOURCE_EXT_IRQ); - resbuf.Data.ExtendedIrq = prsres->Data.ExtendedIrq; - resbuf.Data.ExtendedIrq.NumberOfInterrupts = 1; - resbuf.Data.ExtendedIrq.Interrupts[0] = Interrupts[0]; - } - if (ACPI_FAILURE(status = acpi_AppendBufferResource(&crsbuf, &resbuf))) { - device_printf(pcib, "buf append failed for interrupt %d via %s - %s\n", - Interrupts[0], acpi_name(lnkdev), - AcpiFormatException(status)); - goto out; - } - /* XXX Figure out how this is happening when the append succeeds. */ - if (crsbuf.Pointer == NULL) { - device_printf(pcib, "_CRS buf NULL after append?\n"); - goto out; - } - if (ACPI_FAILURE(status = AcpiSetCurrentResources(lnkdev, &crsbuf))) { - device_printf(pcib, "_SRS failed for interrupt %d via %s - %s\n", - Interrupts[0], acpi_name(lnkdev), - AcpiFormatException(status)); - goto out; - } - crsres = &resbuf; - - /* Return the interrupt we just routed. */ + /* + * Perform the link routing. If successful, use the _PRS value for + * setting the trigger/polarity via acpi_config_intr() below. + */ + interrupt = acpi_pci_link_route(dev, entry); + if (interrupt) + prsres = &link->possible_resources; + if (bootverbose) device_printf(pcib, "slot %d INT%c routed to irq %d via %s\n", - pci_get_slot(dev), 'A' + pin, Interrupts[0], acpi_name(lnkdev)); - interrupt = Interrupts[0]; + pci_get_slot(dev), 'A' + pin, interrupt, + acpi_name(entry->prt_source)); out: - if (PCI_INTERRUPT_VALID(interrupt) && crsres != NULL) - acpi_config_intr(dev, crsres); - if (crsbuf.Pointer != NULL) - AcpiOsFree(crsbuf.Pointer); - if (prsbuf.Pointer != NULL) - AcpiOsFree(prsbuf.Pointer); - if (buf.Pointer != NULL) - AcpiOsFree(buf.Pointer); + if (PCI_INTERRUPT_VALID(interrupt) && prsres) + acpi_config_intr(dev, prsres); return_VALUE (interrupt); } Index: acpi_pcib_acpi.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_pcib_acpi.c,v retrieving revision 1.38 diff -u -r1.38 acpi_pcib_acpi.c --- acpi_pcib_acpi.c 4 Jul 2004 16:23:25 -0000 1.38 +++ acpi_pcib_acpi.c 7 Aug 2004 04:58:12 -0000 @@ -234,9 +234,8 @@ static int acpi_pcib_acpi_resume(device_t dev) { - struct acpi_hpcib_softc *sc = device_get_softc(dev); - return (acpi_pcib_resume(dev, &sc->ap_prt, sc->ap_bus)); + return (acpi_pcib_resume(dev)); } /* @@ -297,11 +296,8 @@ static int acpi_pcib_acpi_route_interrupt(device_t pcib, device_t dev, int pin) { - struct acpi_hpcib_softc *sc; - /* Find the bridge softc. */ - sc = device_get_softc(pcib); - return (acpi_pcib_route_interrupt(pcib, dev, pin, &sc->ap_prt)); + return (acpi_pcib_route_interrupt(pcib, dev, pin)); } struct resource * Index: acpi_pcib_pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_pcib_pci.c,v retrieving revision 1.9 diff -u -r1.9 acpi_pcib_pci.c --- acpi_pcib_pci.c 30 May 2004 20:08:23 -0000 1.9 +++ acpi_pcib_pci.c 7 Aug 2004 04:57:49 -0000 @@ -139,9 +139,8 @@ static int acpi_pcib_pci_resume(device_t dev) { - struct acpi_pcib_softc *sc = device_get_softc(dev); - return (acpi_pcib_resume(dev, &sc->ap_prt, sc->ap_pcibsc.secbus)); + return (acpi_pcib_resume(dev)); } static int @@ -171,5 +170,5 @@ if (sc->ap_prt.Pointer == NULL) return (pcib_route_interrupt(pcib, dev, pin)); else - return (acpi_pcib_route_interrupt(pcib, dev, pin, &sc->ap_prt)); + return (acpi_pcib_route_interrupt(pcib, dev, pin)); } Index: acpi_pcibvar.h =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_pcibvar.h,v retrieving revision 1.2 diff -u -r1.2 acpi_pcibvar.h --- acpi_pcibvar.h 5 Oct 2002 02:01:02 -0000 1.2 +++ acpi_pcibvar.h 10 Aug 2004 00:48:31 -0000 @@ -31,11 +31,42 @@ #define _ACPI_PCIBVAR_H_ int acpi_pcib_attach(device_t bus, ACPI_BUFFER *prt, int busno); -int acpi_pcib_route_interrupt(device_t pcib, device_t dev, int pin, - ACPI_BUFFER *ptrbuf); -int acpi_pcib_resume(device_t bus, ACPI_BUFFER *prt, int busno); +int acpi_pcib_route_interrupt(device_t pcib, device_t dev, int pin); +int acpi_pcib_resume(device_t dev); + +#define MAX_POSSIBLE_INTERRUPTS 16 +#define MAX_ISA_INTERRUPTS 16 +#define MAX_ACPI_INTERRUPTS 255 + +struct acpi_pci_link_entry { + TAILQ_ENTRY(acpi_pci_link_entry) links; + ACPI_HANDLE handle; + UINT8 current_irq; + UINT8 initial_irq; + ACPI_RESOURCE possible_resources; + UINT8 number_of_interrupts; + UINT8 interrupts[MAX_POSSIBLE_INTERRUPTS]; + UINT8 sorted_irq[MAX_POSSIBLE_INTERRUPTS]; + int references; + int priority; + int flags; +#define ACPI_LINK_NONE 0 +#define ACPI_LINK_ROUTED (1 << 0) +}; + +struct acpi_prt_entry { + TAILQ_ENTRY(acpi_prt_entry) links; + device_t pcidev; + int busno; + ACPI_PCI_ROUTING_TABLE prt; + ACPI_HANDLE prt_source; + struct acpi_pci_link_entry *pci_link; +}; int acpi_pci_link_config(device_t pcib, ACPI_BUFFER *prt, int busno); -int acpi_pci_link_resume(device_t pcib, ACPI_BUFFER *prt, int busno); +int acpi_pci_link_resume(device_t pcib); +struct acpi_prt_entry *acpi_pci_find_prt(device_t pcibdev, device_t dev, + int pin); +int acpi_pci_link_route(device_t dev, struct acpi_prt_entry *prt); #endif --------------090409010109040308080807-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 01:28:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A57A16A4CE for ; Tue, 10 Aug 2004 01:28:14 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7080F43D1F for ; Tue, 10 Aug 2004 01:28:14 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.13.1/8.12.11) with ESMTP id i7A1SBiw066737; Mon, 9 Aug 2004 18:28:11 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i7A1SAER066736; Mon, 9 Aug 2004 18:28:10 -0700 (PDT) (envelope-from obrien) Date: Mon, 9 Aug 2004 18:28:10 -0700 From: "David O'Brien" To: "Conrad J. Sabatier" Message-ID: <20040810012810.GA49460@dragon.nuxi.com> References: <20040804214943.1dd07a68@dolphin.local.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040804214943.1dd07a68@dolphin.local.net> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-current@freebsd.org Subject: Re: bsd.cpu.mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@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: Tue, 10 Aug 2004 01:28:14 -0000 On Wed, Aug 04, 2004 at 09:49:43PM -0500, Conrad J. Sabatier wrote: > On Thu, 05 Aug 2004 01:40:10 +0000 > "Deng XueFeng" wrote: > > > Since Gcc 3.4.2 has imported. > > should src/share/mk/bsd.cpu.mk to be updated to support more CPU types > > which gcc[3.4.2] support? > > I asked a similar question recently re: adding CPUTYPE=athlon64. I > imagine someone will get around to it soon, at least before 5.3-RELEASE. I have a patch doing this; but it needs more testing before its ready to commit. CPUTYPE=athlon64 needs to be handled for both 64-bit and 32-bit OS's. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 01:34:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4741616A4CE for ; Tue, 10 Aug 2004 01:34:13 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 388C143D46 for ; Tue, 10 Aug 2004 01:34:13 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 3049C72DF2; Mon, 9 Aug 2004 18:34:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 2B7B972DB5; Mon, 9 Aug 2004 18:34:13 -0700 (PDT) Date: Mon, 9 Aug 2004 18:34:13 -0700 (PDT) From: Doug White To: Terrence Koeman In-Reply-To: <200408091624384.SM01804@manrikigusari> Message-ID: <20040809183302.X80973@carver.gumbysoft.com> References: <200408091624384.SM01804@manrikigusari> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: Compiler segmentation fault in 5-08 -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 01:34:13 -0000 On Mon, 9 Aug 2004, Terrence Koeman wrote: > I recently upgraded world and kernel to the 5 august -CURRENT, and now > nearly anything that requires a compiler fails. Can you compile a simple "hello world" program? Sometimes these types of faults can be caused by faulty memory, processor, overclocking, or temperature issues. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 01:42:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09F5316A4CE; Tue, 10 Aug 2004 01:42:11 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE65B43D62; Tue, 10 Aug 2004 01:42:10 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id CFCEF72DF4; Mon, 9 Aug 2004 18:42:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id CD21572DF2; Mon, 9 Aug 2004 18:42:10 -0700 (PDT) Date: Mon, 9 Aug 2004 18:42:10 -0700 (PDT) From: Doug White To: "Conrad J. Sabatier" In-Reply-To: Message-ID: <20040809184110.V80973@carver.gumbysoft.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: cvsup on amd64 just broke today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 01:42:11 -0000 On Mon, 9 Aug 2004, Conrad J. Sabatier wrote: > # make update > -------------------------------------------------------------- > >>> Running /usr/local/bin/cvsup > -------------------------------------------------------------- > /usr/local/libexec/cvsup-static.i386.bin: 1: Syntax error: "(" > unexpected > *** Error code 2 Can you run cvsup manually? It appears to be trying to execute a binary as a shell script here. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 01:47:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6ED3516A4CE for ; Tue, 10 Aug 2004 01:47:22 +0000 (GMT) Received: from CPE000103d44c07-CM000f9f7ae88c.cpe.net.cable.rogers.com (CPE000103d44c07-CM000f9f7ae88c.cpe.net.cable.rogers.com [69.193.43.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id D973E43D39 for ; Tue, 10 Aug 2004 01:47:21 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from localhost (localhost [127.0.0.1]) with ESMTP id F3EB729542B for ; Mon, 9 Aug 2004 21:47:18 -0400 (EDT) Received: from CPE000103d44c07-CM000f9f7ae88c.cpe.net.cable.rogers.com ([127.0.0.1])10024) with ESMTP id 46294-10 for ; Mon, 9 Aug 2004 21:47:16 -0400 (EDT) Received: from 192.168.0.1 (localhost [127.0.0.1]) with ESMTP id 5DD07295429 for ; Mon, 9 Aug 2004 21:47:16 -0400 (EDT) Received: from 192.168.0.200 (SquirrelMail authenticated user mikej); by 192.168.0.1 with HTTP; Mon, 9 Aug 2004 21:47:16 -0400 (EDT) Message-ID: <2352.192.168.0.200.1092102436.squirrel@192.168.0.200> Date: Mon, 9 Aug 2004 21:47:16 -0400 (EDT) From: "Mike Jakubik" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at fbsd.wettoast.net Subject: buildworld failiure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 01:47:22 -0000 Cvsuped 3 times, no go. Thanks. --- ===> include/rpc sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 /usr/src/include/rpc/auth.h /usr/src/include/rpc/auth_unix.h /usr/src/include/rpc/clnt.h /usr/src/include/rpc/clnt_soc.h /usr/src/include/rpc/clnt_stat.h /usr/src/include/rpc/nettype.h /usr/src/include/rpc/pmap_clnt.h /usr/src/include/rpc/pmap_prot.h /usr/src/include/rpc/pmap_rmt.h /usr/src/include/rpc/raw.h /usr/src/include/rpc/rpc.h /usr/src/include/rpc/rpc_msg.h /usr/src/include/rpc/rpcb_clnt.h /usr/src/include/rpc/rpcent.h /usr/src/include/rpc/rpc_com.h /usr/src/include/rpc/svc.h /usr/src/include/rpc/svc_auth.h /usr/src/include/rpc/svc_soc.h /usr/src/include/rpc/svc_dg.h /usr/src/include/rpc/types.h /usr/src/include/rpc/xdr.h /usr/src/include/rpc/auth_des.h /usr/src/include/rpc/des.h /usr/src/include/rpc/des_crypt.h /usr/src/include/rpc/auth_kerb.h /usr/src/include/rpc/rpcb_prot.x rpcb_prot.h /usr/obj/usr/src/i386/usr/include/rpc ===> lib cd /usr/src/lib; make buildincludes; make installincludes ===> lib/csu/i386-elf ===> lib/libcom_err ===> lib/libcom_err/doc ===> lib/libcrypt ===> lib/libkvm ===> lib/msun ===> lib/libmd ===> lib/libncurses ===> lib/libnetgraph ===> lib/libradius ===> lib/librpcsvc ===> lib/libsbuf ===> lib/libtacplus ===> lib/libutil ===> lib/libypclnt ===> lib/compat ===> lib/libalias ===> lib/libarchive cat /usr/src/lib/libarchive/archive.h.in | sed 's/@ARCHIVE_API_VERSION@/1/' | sed 's/@ARCHIVE_API_FEATURE@/2/' | cat > archive.h ===> lib/libatm ===> lib/libbind ===> lib/libbluetooth ===> lib/libbsnmp ===> lib/libbsnmp/libbsnmp ===> lib/libbsnmp/modules ===> lib/libbsnmp/modules/snmp_atm make: don't know how to make snmp_atm.h. Stop *** Error code 2 Stop in /usr/src/lib/libbsnmp/modules. *** Error code 1 Stop in /usr/src/lib/libbsnmp. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 01:50:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 322D816A4CF for ; Tue, 10 Aug 2004 01:50:22 +0000 (GMT) Received: from smtp002.bizmail.yahoo.com (smtp002.bizmail.yahoo.com [216.136.172.126]) by mx1.FreeBSD.org (Postfix) with SMTP id EAA0643D31 for ; Tue, 10 Aug 2004 01:50:21 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noackjr@supercrime.org@70.240.234.183 with login) by smtp002.bizmail.yahoo.com with SMTP; 10 Aug 2004 01:50:21 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 9449161C9; Mon, 9 Aug 2004 20:50:20 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 38874-08; Mon, 9 Aug 2004 20:50:19 -0500 (CDT) Received: from compgeek.noacks.org (compgeek [192.168.1.10]) by optimator.noacks.org (Postfix) with ESMTP id 1E51360CF; Mon, 9 Aug 2004 20:50:19 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by compgeek.noacks.org (8.13.1/8.13.1) with ESMTP id i7A1oHTE022409; Mon, 9 Aug 2004 20:50:17 -0500 (CDT) (envelope-from noackjr@alumni.rice.edu) Message-ID: <411829D9.9040509@alumni.rice.edu> Date: Mon, 09 Aug 2004 20:50:17 -0500 From: Jon Noack User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040806) X-Accept-Language: en-us, en MIME-Version: 1.0 To: obrien@freebsd.org References: <410E3AA2.4030800@alumni.rice.edu> <20040809100244.GA17314@hub.freebsd.org> In-Reply-To: <20040809100244.GA17314@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at noacks.org cc: Edwin Groothuis cc: current@freebsd.org cc: Oliver Eikemeier Subject: Re: upgrade of file(1) to 4.10 (including FreeBSD elf(5) fixes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 01:50:22 -0000 On 08/09/04 05:02, David O'Brien wrote: > On Mon, Aug 02, 2004 at 07:59:14AM -0500, Jon Noack wrote: >> Here's the output of my patch: >> http://www.noacks.org/freebsd/output.txt > > This output is mostly OK -- but I would drop the __FreeBSD_version. I > can't see how knowing that helps anyone. If it is insisted on keeping > it, it should be printed out consistently for *all* __FreeBSD_verions, > not just some. My reasoning here was the following: 1) Now that we have a fairly consistent versioning scheme for releases, we can avoid printing the version string in those cases. This preserves previous behavior and highlights at a glance what is (or is based on) "released" code. 2) Anything else is (or is based on) a development branch; I've found it highly useful on several occasions to know the version string to see if something was out of sync with the world. For example, some vendors have binary-only products that stop working in -CURRENT. Checking the version string and UPDATING is an easy way to see *at a high level* what the problem may be. This is not likely to be a problem with "released" code. Despite that, I will go with the consensus on printing the version string. I really don't know much about all this (thus, the "high level" comment) and was merely trying to improve a tool I found useful. If there's something better, I'm all ears. Jon From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 01:54:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89D7916A4CE; Tue, 10 Aug 2004 01:54:50 +0000 (GMT) Received: from lakermmtao11.cox.net (lakermmtao11.cox.net [68.230.240.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id E729743D1D; Tue, 10 Aug 2004 01:54:49 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.71.51]) by lakermmtao11.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP <20040810015447.PYVN10626.lakermmtao11.cox.net@dolphin.local.net>; Mon, 9 Aug 2004 21:54:47 -0400 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with ESMTP id i7A1smAw024847; Mon, 9 Aug 2004 20:54:48 -0500 (CDT) (envelope-from conrads@dolphin.local.net) Received: (from conrads@localhost) by dolphin.local.net (8.13.1/8.13.1/Submit) id i7A1shw8024846; Mon, 9 Aug 2004 20:54:43 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20040809184110.V80973@carver.gumbysoft.com> Date: Mon, 09 Aug 2004 20:54:43 -0500 (CDT) Organization: A Rag-Tag Band of Drug-Crazed Hippies From: "Conrad J. Sabatier" To: Doug White cc: freebsd-current@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: cvsup on amd64 just broke today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conrads@cox.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 01:54:50 -0000 On 10-Aug-2004 Doug White wrote: > On Mon, 9 Aug 2004, Conrad J. Sabatier wrote: > >> # make update >> -------------------------------------------------------------- >> >>> Running /usr/local/bin/cvsup >> -------------------------------------------------------------- >> /usr/local/libexec/cvsup-static.i386.bin: 1: Syntax error: "(" >> unexpected >> *** Error code 2 > > Can you run cvsup manually? It appears to be trying to execute a > binary as a shell script here. Tried that, got the same result. I hadn't noticed it before, but it does strike me as odd that the binary package for amd64 would include a file with "i386" in the name, and which is, in fact, an ELF 32 binary. Did something change today that would effect the handling of such a file, perhaps? -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 02:04:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D258816A4CE for ; Tue, 10 Aug 2004 02:04:39 +0000 (GMT) Received: from smtp003.bizmail.yahoo.com (smtp003.bizmail.yahoo.com [216.136.130.195]) by mx1.FreeBSD.org (Postfix) with SMTP id A01D543D49 for ; Tue, 10 Aug 2004 02:04:39 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noackjr@supercrime.org@70.240.234.183 with login) by smtp003.bizmail.yahoo.com with SMTP; 10 Aug 2004 02:04:39 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id A755E61C9; Mon, 9 Aug 2004 21:04:38 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 39571-01; Mon, 9 Aug 2004 21:04:37 -0500 (CDT) Received: from compgeek.noacks.org (compgeek [192.168.1.10]) by optimator.noacks.org (Postfix) with ESMTP id 4AF9660CF; Mon, 9 Aug 2004 21:04:37 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by compgeek.noacks.org (8.13.1/8.13.1) with ESMTP id i7A24bjC022462; Mon, 9 Aug 2004 21:04:37 -0500 (CDT) (envelope-from noackjr@alumni.rice.edu) Message-ID: <41182D34.3060409@alumni.rice.edu> Date: Mon, 09 Aug 2004 21:04:36 -0500 From: Jon Noack User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040806) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edwin Groothuis References: <410E3AA2.4030800@alumni.rice.edu> <20040809100244.GA17314@hub.freebsd.org> <20040809111316.GJ1826@k7.mavetju> In-Reply-To: <20040809111316.GJ1826@k7.mavetju> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at noacks.org cc: current@FreeBSD.ORG cc: David O'Brien cc: Oliver Eikemeier Subject: Re: upgrade of file(1) to 4.10 (including FreeBSD elf(5) fixes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 02:04:39 -0000 On 08/09/04 06:13, Edwin Groothuis wrote: > Please have a look at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/freebsd-versions.html > , please have a look at /usr/include/sys/param.h and come back with > patches if you still have problems. > > This nonsense has gone on long enough. It will be better if you > explain where my thinking went wrong in a constructive way instaed > of this constant bickering like old women do. That way we all learn > something from it. Someone may have already answered this (I'm just coming off working 66 hours in the past 80, so I'm a *bit* out_of_it/verging_on_hallucinations/etc.), but I think the biggest potential issue is the hard-coding of -CURRENT and -STABLE. As these are moving targets, hard-coding them means continued maintenance of the FILE code is necessary with each new major release (even if it is required only once every couple years). A programmatic solution that needed little or no maintenance would be preferred. I sidestepped the issue by printing out the __FreeBSD_version string whenever I came across a development branch. This still says "Hey, I'm not (based on) a release!" but doesn't need further maintenance and just happens to provide a little extra informative as well. Thanks for working on FILE; I'm glad I'm not the only one who was tired of seeing "FreeBSD 5.0.2" with recent -CURRENT... Jon From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 02:43:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3E7416A4CE for ; Tue, 10 Aug 2004 02:43:50 +0000 (GMT) Received: from huva.hittite.isp.9tel.net (huva.hittite.isp.9tel.net [62.62.156.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF46F43D54 for ; Tue, 10 Aug 2004 02:43:50 +0000 (GMT) (envelope-from martin.mato@wanadoo.fr) Received: from [192.168.0.2] (unknown [84.98.16.201]) by huva.hittite.isp.9tel.net (Postfix) with ESMTP id 1CBD114B5B3 for ; Tue, 10 Aug 2004 04:53:20 +0200 (CEST) Message-ID: <41183662.4010802@wanadoo.fr> Date: Tue, 10 Aug 2004 04:43:46 +0200 From: Martin MATO User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: fr, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ACPI autoload failed: no such file or directory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: martin.mato@wanadoo.fr List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 02:43:51 -0000 since several days; i ' got this message before the kernel load (not easy to see that, is not include in the logs) ACPI autoload failed: no such file or directory after the boot process, i logged in and try this command #kldload acpi.ko kldload: can't load usb.ko: No such file or directory #kldload /boot/kernel/acpi.ko in this case the system try to load the module and, of course, it can't. - the acpi.ko file is present in /boot/kernel - i didn't changed anything , except a fresh kernel build - kldload works with other modules in this directory. anyone could explain this.. strange thing? nota : the system boot and work perfectly. Only the ACPI functions are absent.. (it isn't a big problem for me, but i whish understand) From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 02:56:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DB5E16A4CE for ; Tue, 10 Aug 2004 02:56:06 +0000 (GMT) Received: from axe-inc.co.jp (axegw.axe-inc.co.jp [61.199.217.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 685DD43D1D for ; Tue, 10 Aug 2004 02:56:05 +0000 (GMT) (envelope-from takawata@axe-inc.co.jp) Received: from localhost (localhost [127.0.0.1]) by axe-inc.co.jp (8.9.3+3.2W/3.7W) with SMTP id LAA13722; Tue, 10 Aug 2004 11:55:59 +0900 (JST) Message-Id: <200408100255.LAA13722@axe-inc.co.jp> X-Authentication-Warning: axegw.axe-inc.co.jp: localhost [127.0.0.1] didn't use HELO protocol To: martin.mato@wanadoo.fr From: takawata@jp.freebsd.org In-reply-to: Your message of "Tue, 10 Aug 2004 04:43:46 +0200." <41183662.4010802@wanadoo.fr> Date: Tue, 10 Aug 2004 11:55:59 +0900 Sender: takawata@axe-inc.co.jp cc: freebsd-current@freebsd.org Subject: Re: ACPI autoload failed: no such file or directory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 02:56:06 -0000 In message <41183662.4010802@wanadoo.fr>, Martin MATO wrote: >since several days; i ' got this message before the kernel load (not >easy to see that, is not include in the logs) > >ACPI autoload failed: no such file or directory > >after the boot process, i logged in and try this command > >#kldload acpi.ko >kldload: can't load usb.ko: No such file or directory > >#kldload /boot/kernel/acpi.ko >in this case the system try to load the module and, of course, it can't. You cannot load acpi.ko from userland. >- the acpi.ko file is present in /boot/kernel >- i didn't changed anything , except a fresh kernel build >- kldload works with other modules in this directory. > > >anyone could explain this.. strange thing? Hmm, how about trying to escape to boot loader prompt and load acpi module manually ? From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 03:16:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0425C16A4CE for ; Tue, 10 Aug 2004 03:16:38 +0000 (GMT) Received: from hourri.hittite.isp.9tel.net (hourri.hittite.isp.9tel.net [62.62.156.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B23F843D48 for ; Tue, 10 Aug 2004 03:16:37 +0000 (GMT) (envelope-from martin.mato@wanadoo.fr) Received: from [192.168.0.2] (unknown [80.119.126.148]) by hourri.hittite.isp.9tel.net (Postfix) with ESMTP id 9F9C6157579 for ; Tue, 10 Aug 2004 05:26:03 +0200 (CEST) Message-ID: <41183E13.4070107@wanadoo.fr> Date: Tue, 10 Aug 2004 05:16:35 +0200 From: Martin MATO User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: fr, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <200408100255.LAA13722@axe-inc.co.jp> In-Reply-To: <200408100255.LAA13722@axe-inc.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: ACPI autoload failed: no such file or directory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: martin.mato@wanadoo.fr List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 03:16:38 -0000 takawata@jp.freebsd.org a écrit : >In message <41183662.4010802@wanadoo.fr>, Martin MATO wrote: > > >>since several days; i ' got this message before the kernel load (not >>easy to see that, is not include in the logs) >> >>ACPI autoload failed: no such file or directory >> >>after the boot process, i logged in and try this command >> >>#kldload acpi.ko >>kldload: can't load usb.ko: No such file or directory >> >>#kldload /boot/kernel/acpi.ko >>in this case the system try to load the module and, of course, it can't. >> >> > >You cannot load acpi.ko from userland. > > yes, i know, but kldload doesn't found the file if i don't specify the path. It is what I tried to explain. if i specify the path, i got the message in the log: "kernel: The ACPI driver cannot be loaded after boot" instead of: "acpi.ko: no such file or directory" > > >>- the acpi.ko file is present in /boot/kernel >>- i didn't changed anything , except a fresh kernel build >>- kldload works with other modules in this directory. >> >> >>anyone could explain this.. strange thing? >> >> > >Hmm, how about trying to escape to boot loader prompt and >load acpi module manually ? > > > i tried. acpi.ko is loaded only if i specify the path, but at kernel boot, i got the message "ACPI autoload failed...." and i have no acpi inplementation. (the acpi function are not discovered.) From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 03:33:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E64B116A4CE for ; Tue, 10 Aug 2004 03:33:04 +0000 (GMT) Received: from pandora.afflictions.org (asylum.afflictions.org [64.7.134.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 453ED43D46 for ; Tue, 10 Aug 2004 03:33:04 +0000 (GMT) (envelope-from dgerow@afflictions.org) Received: from localhost (localhost [127.0.0.1]) by pandora.afflictions.org (Postfix) with ESMTP id 1861378C35 for ; Mon, 9 Aug 2004 23:37:10 -0400 (EDT) Received: from dementia.afflictions.org (dementia.afflictions.org [172.19.206.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pandora.afflictions.org (Postfix) with ESMTP id 4662478C1C for ; Mon, 9 Aug 2004 23:37:08 -0400 (EDT) Received: by dementia.afflictions.org (Postfix, from userid 1001) id AE4F5170C9; Mon, 9 Aug 2004 23:32:47 -0400 (EDT) Date: Mon, 9 Aug 2004 23:32:47 -0400 From: Damian Gerow To: freebsd-current@FreeBSD.ORG Message-ID: <20040810033247.GD7059@afflictions.org> Mail-Followup-To: freebsd-current@FreeBSD.ORG References: <6.1.2.0.0.20040809134944.058d4098@64.7.153.2> <200408091814.i79IEjjv009798@grimreaper.grondar.org> <20040809185738.GY26004@sirius.firepipe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040809185738.GY26004@sirius.firepipe.net> X-Operating-System: FreeBSD 5.2-CURRENT on a i386 X-GPG-Fingerprint: B3D7 D901 A53A 1A99 BFD6 E6DF 9F3B 742B C288 9CC9 User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at afflictions.org Subject: Re: VIA C3 AES code ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 03:33:05 -0000 Thus spake Will Andrews (will@csociety.org) [09/08/04 15:02]: : On Mon, Aug 09, 2004 at 07:14:45PM +0100, Mark Murray wrote: : > Yup. It means that if you ask OpenSSL for AES encryptionon a C3 Nehemiah, : > you get the full HW speed. : : I must be doing something wrong. I believe that not all Nehemiah's support AES -- only those with Stepping 8 and higher, IIRC. Yes, it's true. Here's Google's HTML version: of the VIA ACE programming guide: If you're not Stepping 8 or higher, you only have the (P)RNG. - Damian From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 03:34:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 680AA16A4CE for ; Tue, 10 Aug 2004 03:34:20 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id D131243D48 for ; Tue, 10 Aug 2004 03:34:19 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by mproxy.gmail.com with SMTP id 75so125786rnl for ; Mon, 09 Aug 2004 20:34:19 -0700 (PDT) Received: by 10.38.24.64 with SMTP id 64mr1183381rnx; Mon, 09 Aug 2004 20:34:19 -0700 (PDT) Message-ID: Date: Tue, 10 Aug 2004 11:34:19 +0800 From: Jiawei Ye To: John-Mark Gurney In-Reply-To: <20040809225255.GI991@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200408092003.28922.max@love2party.net> <20040809222127.GU64690@camelot.theinternet.com.au> <200408100040.23324.max@love2party.net> <20040809225255.GI991@funkthat.com> cc: Max Laier cc: freebsd-current@freebsd.org Subject: Re: kldload pf failed on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 03:34:20 -0000 On Mon, 9 Aug 2004 15:52:55 -0700, John-Mark Gurney > Ok, on the kernel boot, please send me: > sysctl kern.bootfile kern.module_path > ls /boot/ > > Make sure that you're current kernel is built to include modules. We > no longer will load the default kernel's modules for other kernels. So > if you boot kernel.test (or other kernel) that does not have pf.ko, you > can't load pf.ko anymore. > -- > John-Mark Gurney Voice: +1 415 225 5579 root@chihiro:~# kldload pf kldload: can't load pf: No such file or directory root@chihiro:~# kldload /boot/kernel/pf.ko root@chihiro:~# sysctl kern.bootfile kern.module_path kern.bootfile: /boot/kernel/kernel kern.module_path: /boot/modules root@chihiro:~# ls /boot/kernel/ 3dfx.ko* if_ic.ko* ng_sscfu.ko* aac.ko* if_ie.ko* ng_sscop.ko* aac_linux.ko* if_kue.ko* ng_sync_ar.ko* accf_data.ko* if_lge.ko* ng_sync_sr.ko* accf_http.ko* if_lnc.ko* ng_tee.ko* acpi.ko* if_my.ko* ng_tty.ko* acpi_asus.ko* if_nge.ko* ng_ubt.ko* acpi_panasonic.ko* if_oltr.ko* ng_uni.ko* acpi_toshiba.ko* if_patm.ko* ng_vjc.ko* acpi_video.ko* if_pcn.ko* ng_vlan.ko* agp.ko* if_ppp.ko* ngatmbase.ko* aha.ko* if_ray.ko* nmdm.ko* ahb.ko* if_re.ko* nsp.ko* ahc.ko* if_rl.ko* ntfs.ko* ahc_eisa.ko* if_rue.ko* ntfs_iconv.ko* ahc_pci.ko* if_sbni.ko* nullfs.ko* ahd.ko* if_sbsh.ko* nwfs.ko* aic.ko* if_sf.ko* pccard.ko* aio.ko* if_sis.ko* pcf.ko* alpm.ko* if_sk.ko* pcfclock.ko* amd.ko* if_sl.ko* pecoff.ko* amdpm.ko* if_sn.ko* pf.ko* amr.ko* if_sr.ko* plip.ko* aout.ko* if_ste.ko* portalfs.ko* apm.ko* if_stf.ko* ppbus.ko* apm_saver.ko* if_tap.ko* ppi.ko* arcnet.ko* if_ti.ko* pps.ko* asr.ko* if_tl.ko* procfs.ko* ath_hal.ko* if_tun.ko* pseudofs.ko* bktr.ko* if_tx.ko* pst.ko* bktr_mem.ko* if_txp.ko* r128.ko* blank_saver.ko* if_udav.ko* radeon.ko* bridge.ko* if_vlan.ko* rain_saver.ko* cam.ko* if_vr.ko* random.ko* cardbus.ko* if_vx.ko* rc.ko* cbb.ko* if_wb.ko* rc4.ko* cd9660.ko* if_wi.ko* rp.ko* cd9660_iconv.ko* if_xe.ko* s3.ko* ciss.ko* if_xl.ko* safe.ko* coda.ko* iic.ko* sbp.ko* coda5.ko* iicbb.ko* sbp_targ.ko* crypto.ko* iicbus.ko* scd.ko* cryptodev.ko* iicsmb.ko* scsi_low.ko* daemon_saver.ko* iir.ko* sis.ko* dcons.ko* intpm.ko* smapi.ko* dcons_crom.ko* io.ko* smb.ko* digi.ko* ip6fw.ko* smbfs.ko* digi_CX.ko* ip_mroute.ko* smbios.ko* digi_CX_PCI.ko* ipfw.ko* smbus.ko* digi_EPCX.ko* ipl.ko* snake_saver.ko* digi_EPCX_PCI.ko* ips.ko* snd_ad1816.ko* digi_Xe.ko* isp.ko* snd_als4000.ko* digi_Xem.ko* ispfw.ko* snd_cmi.ko* digi_Xr.ko* joy.ko* snd_cs4281.ko* dpt.ko* kernel* snd_csa.ko* dragon_saver.ko* libiconv.ko* snd_driver.ko* dummynet.ko* libmbpool.ko* snd_ds1.ko* elink.ko* libmchain.ko* snd_emu10k1.ko* exca.ko* linker.hints snd_es137x.ko* ext2fs.ko* linprocfs.ko* snd_ess.ko* fade_saver.ko* linux.ko* snd_fm801.ko* fdc.ko* logo_saver.ko* snd_ich.ko* fdescfs.ko* lpbb.ko* snd_maestro.ko* fire_saver.ko* lpt.ko* snd_maestro3.ko* firewire.ko* mac_biba.ko* snd_mss.ko* g_md.ko* mac_bsdextended.ko* snd_neomagic.ko* geom_apple.ko* mac_ifoff.ko* snd_sb16.ko* geom_bde.ko* mac_lomac.ko* snd_sb8.ko* geom_bsd.ko* mac_mls.ko* snd_sbc.ko* geom_ccd.ko* mac_none.ko* snd_solo.ko* geom_concat.ko* mac_partition.ko* snd_t4dwave.ko* geom_fox.ko* mac_portacl.ko* snd_uaudio.ko* geom_gate.ko* mac_seeotheruids.ko* snd_via8233.ko* geom_gpt.ko* mac_stub.ko* snd_via82c686.ko* geom_label.ko* mac_test.ko* snd_vibes.ko* geom_mbr.ko* mcd.ko* snp.ko* geom_mirror.ko* mem.ko* sound.ko* geom_nop.ko* mga.ko* speaker.ko* geom_pc98.ko* miibus.ko* splash_bmp.ko* geom_stripe.ko* mlx.ko* splash_pcx.ko* geom_sunlabel.ko* mly.ko* sppp.ko* geom_vinum.ko* mpt.ko* star_saver.ko* geom_vol_ffs.ko* msdosfs.ko* stg.ko* green_saver.ko* msdosfs_iconv.ko* streams.ko* hfa.ko* ncp.ko* sym.ko* hfa_pci.ko* ncv.ko* sysvmsg.ko* hifn.ko* ndis.ko* sysvsem.ko* ibcs2.ko* netgraph.ko* sysvshm.ko* ibcs2_coff.ko* nfsclient.ko* tdfx.ko* ichwd.ko* nfsserver.ko* trm.ko* ida.ko* ng_UI.ko* twa.ko* idt.ko* ng_async.ko* twe.ko* if_an.ko* ng_atm.ko* uart.ko* if_ar.ko* ng_atmpif.ko* ubsa.ko* if_arl.ko* ng_bluetooth.ko* ubsec.ko* if_ath.ko* ng_bpf.ko* ubser.ko* if_aue.ko* ng_bridge.ko* ubtbcmfw.ko* if_awi.ko* ng_bt3c.ko* ucom.ko* if_axe.ko* ng_btsocket.ko* udbp.ko* if_bfe.ko* ng_cisco.ko* udf.ko* if_bge.ko* ng_echo.ko* udf_iconv.ko* if_cm.ko* ng_eiface.ko* ufm.ko* if_cp.ko* ng_etf.ko* uftdi.ko* if_ct.ko* ng_ether.ko* ugen.ko* if_cue.ko* ng_fec.ko* uhid.ko* if_cx.ko* ng_frame_relay.ko* ukbd.ko* if_dc.ko* ng_gif.ko* ulpt.ko* if_de.ko* ng_gif_demux.ko* umass.ko* if_disc.ko* ng_h4.ko* umct.ko* if_ed.ko* ng_hci.ko* umodem.ko* if_ef.ko* ng_hole.ko* ums.ko* if_el.ko* ng_hub.ko* unionfs.ko* if_em.ko* ng_iface.ko* uplcom.ko* if_en.ko* ng_ip_input.ko* urio.ko* if_ep.ko* ng_ksocket.ko* usb.ko* if_ex.ko* ng_l2cap.ko* uscanner.ko* if_faith.ko* ng_l2tp.ko* utopia.ko* if_fatm.ko* ng_lmi.ko* uvisor.ko* if_fe.ko* ng_mppc.ko* uvscom.ko* if_fwe.ko* ng_one2many.ko* vesa.ko* if_fwip.ko* ng_ppp.ko* viapm.ko* if_fxp.ko* ng_pppoe.ko* vinum.ko* if_gif.ko* ng_pptpgre.ko* vpd.ko* if_gre.ko* ng_rfc1490.ko* vpo.ko* if_gx.ko* ng_socket.ko* warp_saver.ko* if_harp.ko* ng_split.ko* wlan.ko* if_hatm.ko* ng_sppp.ko* root@chihiro:~# Jiawei Ye From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 03:37:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E95A16A4CE for ; Tue, 10 Aug 2004 03:37:22 +0000 (GMT) Received: from sirius.firepipe.net (sirius.firepipe.net [69.13.116.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4034F43D2F for ; Tue, 10 Aug 2004 03:37:22 +0000 (GMT) (envelope-from will@csociety.org) Received: by sirius.firepipe.net (Postfix, from userid 1000) id C658117F72; Mon, 9 Aug 2004 22:37:21 -0500 (EST) Date: Mon, 9 Aug 2004 22:37:21 -0500 From: Will Andrews To: freebsd-current@FreeBSD.ORG Message-ID: <20040810033721.GB26004@sirius.firepipe.net> Mail-Followup-To: freebsd-current@FreeBSD.ORG References: <6.1.2.0.0.20040809134944.058d4098@64.7.153.2> <200408091814.i79IEjjv009798@grimreaper.grondar.org> <20040809185738.GY26004@sirius.firepipe.net> <20040810033247.GD7059@afflictions.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RUvhGz2nhX7DIu1B" Content-Disposition: inline In-Reply-To: <20040810033247.GD7059@afflictions.org> User-Agent: Mutt/1.5.6i Subject: Re: VIA C3 AES code ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 03:37:22 -0000 --RUvhGz2nhX7DIu1B Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 09, 2004 at 11:32:47PM -0400, Damian Gerow wrote: > I believe that not all Nehemiah's support AES -- only those with Stepping= 8 > and higher, IIRC. Yes, I know. CPU: VIA C3 Nehemiah+RNG+ACE (1208.87-MHz 686-class CPU) Origin =3D "CentaurHauls" Id =3D 0x698 Stepping =3D 8 Features=3D0x381b93f Nevertheless, it appears the support Mark mentions doesn't actually exist in -current yet. Regards, --=20 wca --RUvhGz2nhX7DIu1B Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGELxF47idPgWcsURAgLfAJ4i1TVs0b0/3CIy5S0z7+Dpzlt9EACfYFOU 2zPMQYRAHFk6+x12jMLREJ8= =MUNT -----END PGP SIGNATURE----- --RUvhGz2nhX7DIu1B-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 03:38:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9157916A4CF for ; Tue, 10 Aug 2004 03:38:39 +0000 (GMT) Received: from pandora.afflictions.org (asylum.afflictions.org [64.7.134.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id AACB743D5A for ; Tue, 10 Aug 2004 03:38:38 +0000 (GMT) (envelope-from dgerow@afflictions.org) Received: from localhost (localhost [127.0.0.1]) by pandora.afflictions.org (Postfix) with ESMTP id BBF4278C35 for ; Mon, 9 Aug 2004 23:42:44 -0400 (EDT) Received: from dementia.afflictions.org (dementia.afflictions.org [172.19.206.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pandora.afflictions.org (Postfix) with ESMTP id 1490B78C1C for ; Mon, 9 Aug 2004 23:42:43 -0400 (EDT) Received: by dementia.afflictions.org (Postfix, from userid 1001) id 9B474170C9; Mon, 9 Aug 2004 23:38:22 -0400 (EDT) Date: Mon, 9 Aug 2004 23:38:22 -0400 From: Damian Gerow To: freebsd-current@FreeBSD.ORG Message-ID: <20040810033822.GE7059@afflictions.org> Mail-Followup-To: freebsd-current@FreeBSD.ORG References: <6.1.2.0.0.20040809134944.058d4098@64.7.153.2> <200408091814.i79IEjjv009798@grimreaper.grondar.org> <20040809185738.GY26004@sirius.firepipe.net> <20040810033247.GD7059@afflictions.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040810033247.GD7059@afflictions.org> X-Operating-System: FreeBSD 5.2-CURRENT on a i386 X-GPG-Fingerprint: B3D7 D901 A53A 1A99 BFD6 E6DF 9F3B 742B C288 9CC9 User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at afflictions.org Subject: Re: VIA C3 AES code ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 03:38:39 -0000 Thus spake Damian Gerow (dgerow@afflictions.org) [09/08/04 23:37]: : I believe that not all Nehemiah's support AES -- only those with Stepping 8 : and higher, IIRC. Before anyone points out the obvious, I saw that he has ACE (and, AFAIK, all chips 1.2GHz and greater include ACE) -- this is just in case anyone else pipes up that it's not working. Sorry, should have included that before. From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 03:47:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C908816A4CE for ; Tue, 10 Aug 2004 03:47:27 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81CAA43D49 for ; Tue, 10 Aug 2004 03:47:27 +0000 (GMT) (envelope-from jon.drews@gmail.com) Received: by mproxy.gmail.com with SMTP id 79so168378rnl for ; Mon, 09 Aug 2004 20:47:27 -0700 (PDT) Received: by 10.38.12.77 with SMTP id 77mr1132915rnl; Mon, 09 Aug 2004 20:47:26 -0700 (PDT) Message-ID: <8cb27cbf04080920471d98713@mail.gmail.com> Date: Mon, 9 Aug 2004 22:47:26 -0500 From: Jon Drews To: freebsd-current@freebsd.org In-Reply-To: <20040809221244.GB14911@fasolt.home.paeps.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040805071236.GA595@loge.nixsys.be> <20040809090723.GI642@loge.nixsys.be> <20040809221244.GB14911@fasolt.home.paeps.cx> Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 03:47:27 -0000 On Tue, 10 Aug 2004 00:12:44 +0200, Philip Paeps wrote: > Mmm, oh, right. Verbose isn't verbose enough for psm, I'm afraid you'll have > to compile a kernel with options PSM_DEBUG=2. I'll have to remember to stick > the probe-messages under a normal verbose. Oops -- I did a CVSUP and now I get the following error when I do "make buildworld": Make: Don't know how to make snmp_atm.h Stop. It's not in the specified directory. So getting options PSM_DEBUG=2 compiled in may take a little longer than I thought. I will do a cvsup in 8 hours. Kind regards, Jonathan From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 03:55:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E210C16A4CE for ; Tue, 10 Aug 2004 03:55:33 +0000 (GMT) Received: from tethys.ringofsaturn.com (tethys.ringofsaturn.com [66.13.175.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5425943D3F for ; Tue, 10 Aug 2004 03:55:33 +0000 (GMT) (envelope-from rnejdl@ringofsaturn.com) Received: from mail.ringofsaturn.com (localhost [127.0.0.1]) i7A3tSeX087666; Mon, 9 Aug 2004 22:55:28 -0500 (CDT) (envelope-from rnejdl@ringofsaturn.com) Received: from 66.13.175.242 (SquirrelMail authenticated user rnejdl); by mail.ringofsaturn.com with HTTP; Mon, 9 Aug 2004 22:55:28 -0500 (CDT) Message-ID: <61285.66.13.175.242.1092110128.squirrel@[66.13.175.242]> In-Reply-To: References: <44129.12.148.147.242.1092077172.squirrel@[12.148.147.242]> Date: Mon, 9 Aug 2004 22:55:28 -0500 (CDT) From: "Rusty Nejdl" To: conrads@cox.net User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on tethys.ringofsaturn.com X-Virus-Status: Clean cc: freebsd-current@freebsd.org cc: Dan Nelson Subject: Re: Is anything being done re: the pcm timeout issue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rnejdl@ringofsaturn.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 03:55:34 -0000 Conrad J. Sabatier said: > > > No, no vchans in use here. My main audio app is madplay, which I run > from a little "jukebox" script I wrote to play my MP3s. Ok, I've looked a bit at madplay and it looks like sound is very different in 5.3-current. (Yes, I know about the device change in the kernel). I haven't had a chance to test this out yet in 5.3 because I've been focusing on some other issues - mainly GIANT's which are killing performance for me in 5.2. I'm going to load this up on my laptop tomorrow and see if I can cause this to break in any conceivable way for me. I have a dual opteron system I can play with in my lab, but I'm afraid that this one doesn't have sound on it. > > I've been unable to determine what's triggering the breakage myself. > The script runs fine for a while, selecting random MP3 files and > running madplay to play them one by one. Suddenly, madplay will output the > message "output: write failed" (or something like that) and my system log > will show "pcm0:play:0: play interrupt timeout, channel dead". > > After that, any further attempts to play a sound file of any sort result > in only a split-second of sound followed by the same messages as above. The > only cure is a reboot. > > I posted some truss output from madplay a while back, but it's probably > not very useful, since a timeout had already occurred in a previous run, so > the listing only showed what was happening once the device had already > become broken. > > Catching it "in the act", so to speak, is tricky, as it may work fine > for an hour or two before the first breakage occurs. This would require a > HUGE amount of truss or ktrace logging. > > > We had a discussion recently here about certain peculiarities in the > sound code, but never reached any useful conclusions, and none of our sound > experts ever joined in, either. Yeah, I noticed that too. Wasn't sure though, since I just recently joined the list. > > I would hate to see 5.3 released with this problem still unsolved, but > it's beginning to look like that may, in fact, be the case, unfortunately. > I had hoped, too, that by this time we would have seen > the new MIDI code incorporated into the tree as well, but it seems that > sound (other than the abrupt yanking of the previous MIDI code and the > recent renaming of devices/drivers) is being sadly neglected lately. Well, let's get testing and breaking, then. Rusty Nejdl From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 04:35:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 160D216A4CE for ; Tue, 10 Aug 2004 04:35:06 +0000 (GMT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0A1843D58 for ; Tue, 10 Aug 2004 04:35:05 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-68-121-219-69.dsl.snfc21.pacbell.net [68.121.219.69])i7A4Z3HL109568 for ; Tue, 10 Aug 2004 00:35:04 -0400 Message-ID: <41185077.5000106@elischer.org> Date: Mon, 09 Aug 2004 21:35:03 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: FreeBSD current mailing list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Is world broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 04:35:06 -0000 I'm hitting the following.... Stop in /usr/src/lib/libbsnmp. ===> libbsnmp ===> modules ===> modules/snmp_atm make: don't know how to make snmp_atm.c. Stop *** Error code 2 Stop in /usr/src/lib/libbsnmp/modules. anyone know where that comes from? From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 04:40:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 653A916A4CE for ; Tue, 10 Aug 2004 04:40:49 +0000 (GMT) Received: from hellhound.ceribus.net (c-24-21-90-79.client.comcast.net [24.21.90.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id F249143D4C for ; Tue, 10 Aug 2004 04:40:48 +0000 (GMT) (envelope-from grover@ceribus.net) Received: (qmail 96653 invoked by uid 1002); 10 Aug 2004 04:41:03 -0000 Received: from grover@ceribus.net by hellhound.ceribus.net by uid 89 with qmail-scanner-1.22 (clamscan: 0.73. spamassassin: 2.63. Clear:RC:1(192.168.200.200):. Processed in 0.868585 secs); 10 Aug 2004 04:41:03 -0000 Received: from unknown (HELO ?192.168.200.219?) (grover@ceribus.net@192.168.200.200) by 192.168.200.225 with SMTP; 10 Aug 2004 04:41:02 -0000 Message-ID: <411851D1.3080006@ceribus.net> Date: Mon, 09 Aug 2004 21:40:49 -0700 From: Grover Lines User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <41185077.5000106@elischer.org> In-Reply-To: <41185077.5000106@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Is world broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 04:40:49 -0000 Julian Elischer wrote: > > I'm hitting the following.... > Stop in /usr/src/lib/libbsnmp. > > ===> libbsnmp > ===> modules > ===> modules/snmp_atm > make: don't know how to make snmp_atm.c. Stop > *** Error code 2 > > Stop in /usr/src/lib/libbsnmp/modules. > > > anyone know where that comes from? > > > _______________________________________________ > 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" > > Been broken for me last 4 tries in the last day or so. Mines broke at the same spot too. They're probably jamming in as many commits as they can before the 15th. -- Grover Lines From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 04:42:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DBF316A4CE for ; Tue, 10 Aug 2004 04:42:59 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 188AC43D48 for ; Tue, 10 Aug 2004 04:42:59 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 26388 invoked from network); 10 Aug 2004 04:42:58 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail4.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Aug 2004 04:42:58 -0000 Received: from hydrogen.funkthat.com (lmrwvm@localhost.funkthat.com [127.0.0.1])i7A4gvuU068274; Mon, 9 Aug 2004 21:42:58 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i7A4gvSA068273; Mon, 9 Aug 2004 21:42:57 -0700 (PDT) Date: Mon, 9 Aug 2004 21:42:57 -0700 From: John-Mark Gurney To: Jiawei Ye Message-ID: <20040810044257.GJ991@funkthat.com> Mail-Followup-To: Jiawei Ye , freebsd-current@freebsd.org References: <200408092003.28922.max@love2party.net> <20040809222127.GU64690@camelot.theinternet.com.au> <200408100040.23324.max@love2party.net> <20040809225255.GI991@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-current@freebsd.org Subject: Re: kldload pf failed on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 04:42:59 -0000 Jiawei Ye wrote this message on Tue, Aug 10, 2004 at 11:34 +0800: > On Mon, 9 Aug 2004 15:52:55 -0700, John-Mark Gurney > > Ok, on the kernel boot, please send me: > > sysctl kern.bootfile kern.module_path > > ls /boot/ > > > > Make sure that you're current kernel is built to include modules. We > > no longer will load the default kernel's modules for other kernels. So > > if you boot kernel.test (or other kernel) that does not have pf.ko, you > > can't load pf.ko anymore. > > -- > > John-Mark Gurney Voice: +1 415 225 5579 > > root@chihiro:~# kldload pf > kldload: can't load pf: No such file or directory > root@chihiro:~# kldload /boot/kernel/pf.ko > root@chihiro:~# sysctl kern.bootfile kern.module_path > kern.bootfile: /boot/kernel/kernel > kern.module_path: /boot/modules > root@chihiro:~# ls /boot/kernel/ [...] > amdpm.ko* if_sn.ko* pf.ko* [...] Ok, now this is really wierd... On my system that I just upgraded on Sunday, I don't have a problem... I end up with: -bash-2.05b$ sysctl kern.bootfile kern.module_path kern.bootfile: /boot/kernel/kernel kern.module_path: /boot/kernel;/boot/modules and this is with: -bash-2.05b$ ident support.4th defaults/loader.conf support.4th: $FreeBSD: src/sys/boot/forth/support.4th,v 1.15 2002/05/24 02:28:58 gordon Exp $ defaults/loader.conf: $FreeBSD: src/sys/boot/forth/loader.conf,v 1.85 2004/08/06 15:06:06 jmg Exp $ could you also send me your loader.conf and device.hints along with the output of ident as shown above? Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 04:56:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFA6316A4D5 for ; Tue, 10 Aug 2004 04:56:50 +0000 (GMT) Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AEBC43D58 for ; Tue, 10 Aug 2004 04:56:50 +0000 (GMT) (envelope-from mike@inbox.lv) Received: from pool0278.cvx26-bradley.dialup.earthlink.net ([209.179.223.23] helo=ringworm.mojavegreen.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1BuOgm-0003ZG-00 for freebsd-current@freebsd.org; Mon, 09 Aug 2004 21:56:44 -0700 Received: by ringworm.mojavegreen.com (Postfix, from userid 1001) id E90D7B479C; Mon, 9 Aug 2004 21:56:42 -0700 (PDT) From: "Michael C. Shultz" To: freebsd-current@freebsd.org Date: Mon, 9 Aug 2004 21:56:38 -0700 User-Agent: KMail/1.6.2 References: <200408071057.06960.ringworm@inbox.lv> In-Reply-To: <200408071057.06960.ringworm@inbox.lv> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_GWFGBQrGjPJrQNU" Message-Id: <200408092156.39453.ringworm@inbox.lv> X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Re: Need help: buildworld for CURRENT while under STABLE is not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 04:56:50 -0000 --Boundary-00=_GWFGBQrGjPJrQNU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Saturday 07 August 2004 10:57 am, Michael C. Shultz wrote: > I have STABLE on ad0 and a working snapshot of CURRENT on ad1, I am trying > to run: > > make buildworld -DDESTDIR=/ad1 while booted from STABLE and I keep getting > the following error: (Note: cvsup'ed just before running make build world > still didn't help, neither does cleaning before hand...) I'll attach my > make.conf in case that helps... > > > ===> usr.sbin/bsnmpd/gensnmptree > /usr/obj/ad1/usr/src/i386/ad1/usr/src/usr.sbin/bsnmpd/gensnmptree created > for /ad1/usr/src/usr.sbin/bsnmpd/gensnmptree > rm -f .depend > mkdep -f .depend -a > -I/ad1/usr/src/usr.sbin/bsnmpd/gensnmptree/../../../contrib/bsnmp/lib > -I/usr/obj/ad1/usr/src/i386/legacy/usr/include > /ad1/usr/src/usr.sbin/bsnmpd/gensnmptree/../../../contrib/bsnmp/gensnmptree >/gensnmptree.c > /ad1/usr/src/usr.sbin/bsnmpd/gensnmptree/../../../contrib/bsnmp/gensnmptree >/gensnmptree.c:66: stdint.h: No such file or directory > mkdep: compile failed > *** Error code 1 > > Stop in /ad1/usr/src/usr.sbin/bsnmpd/gensnmptree. > *** Error code 1 > > Stop in /ad1/usr/src. > *** Error code 1 > > Stop in /ad1/usr/src. > *** Error code 1 > > Stop in /ad1/usr/src. After commenting from contrib/bsnmp/gensnmptree/gensnmptree.c buildworld worked!!! Now buildkernel is failing for: -------------------------------------------------------------- >>> stage 3.2: building everything -------------------------------------------------------------- cd /usr/obj/ad1/usr/src/sys/RINGWORM; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE=i586 GROFF_BIN_PATH=/usr/obj/ad1/usr/src/i386/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/ad1/usr/src/i386/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/ad1/usr/src/i386/legacy/usr/share/tmac DESTDIR=/usr/obj/ad1/usr/src/i386 _SHLIBDIRPREFIX=/usr/obj/ad1/usr/src/i386 INSTALL="sh /ad1/usr/src/tools/install.sh" PATH=/usr/obj/ad1/usr/src/i386/legacy/usr/sbin:/usr/obj/ad1/usr/src/i386/legacy/usr/bin:/usr/obj/ad1/usr/src/i386/legacy/usr/games:/usr/obj/ad1/usr/src/i386/usr/sbin:/usr/obj/ad1/usr/src/i386/usr/bin:/usr/obj/ad1/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /usr/obj/ad1/usr/src/make.i386/make KERNEL=kernel all -DNO_MODULES_OBJ linking kernel if.o(.text+0x2d60): In function `if_setlladdr': : undefined reference to `arp_ifinit' *** Error code 1 Stop in /usr/obj/ad1/usr/src/sys/RINGWORM. *** Error code 1 Stop in /ad1/usr/src. *** Error code 1 Stop in /ad1/usr/src. Is it possible I have something in my config file set wrong? I'll attach it incase anyone wants to see it, also my make.conf. Thankyou -mike --Boundary-00=_GWFGBQrGjPJrQNU Content-Type: text/plain; charset="iso-8859-1"; name="RINGWORM" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="RINGWORM" # # RINGWORM # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.411 2004/08/03 19:24:53 markm Exp $ machine i386 #cpu I486_CPU cpu I586_CPU #cpu I686_CPU ident RINGWORM # To statically compile in device wiring instead of /boot/device.hints hints "RINGWORM.hints" # Default places to look for devices. #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device #options NFSCLIENT # Network Filesystem Client #options NFSSERVER # Network Filesystem Server #options NFS_ROOT # NFS usable as /, requires NFSCLIENT #options MSDOSFS # MSDOS Filesystem #options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework #options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 #options SCSI_DELAY=15000 # Delay (in ms) before probing SCSI #options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. #options PFIL_HOOKS # pfil(9) framework # Debugging for use in -current #options KDB # Enable kernel debugger support. #options DDB # Support DDB. #options GDB # Support remote GDB. #options INVARIANTS # Enable calls of extra sanity checking #options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS # Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel #device apic # I/O APIC # Bus support. Do not remove isa, even if you have no isa slots device isa #device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device ataraid # ATA RAID drives #device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #device ahd # AHA39320/29320 and onboard AIC79xx devices #device amd # AMD 53C974 (Tekram DC-390(T)) #device isp # Qlogic family #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aha # Adaptec 154x SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # SCSI peripherals #device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers #device da # Direct Access (disks) #device sa # Sequential Access (tape etc) #device cd # CD #device pass # Passthrough device (direct SCSI access) #device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options #device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID #device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers #device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device ida # Compaq Smart RAID #device mlx # Mylex DAC960 family #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard #device psm # PS/2 mouse device vga # VGA video card driver #device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. #device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support #device cbb # cardbus (yenta) bridge #device pcic # ExCA ISA and PCI bridges #device pccard # PC Card (16-bit) bus #device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') #device em # Intel PRO/1000 adapter Gigabit Ethernet Card #device ixgb # Intel PRO/10GbE Ethernet Card #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! #device miibus # MII bus support #device bfe # Broadcom BCM440x 10/100 Ethernet #device bge # Broadcom BCM570xx Gigabit Ethernet #device dc # DEC/Intel 21143 and various workalikes #device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device pcn # AMD Am79C97x PCI 10/100 (precedence over 'lnc') #device re # RealTek 8139C+/8169/8169S/8110S #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device ti # Alteon Networks Tigon I/II gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards ##device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. #device lnc # NE2100, NE32-VL Lance Ethernet cards #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # ISA devices that use the old ISA shims #device le # Wireless NIC cards #device wlan # 802.11 support #device an # Aironet 4500/4800 802.11 wireless NICs. #device awi # BayStack 660 and others #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device #device ether # Ethernet support #device sl # Kernel SLIP #device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse #device urio # Diamond Rio 500 MP3 player #device uscanner # Scanners # USB Ethernet, requires mii #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) --Boundary-00=_GWFGBQrGjPJrQNU-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 05:09:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9FFB16A4CE for ; Tue, 10 Aug 2004 05:09:09 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F6F243D3F for ; Tue, 10 Aug 2004 05:09:09 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 28045 invoked from network); 10 Aug 2004 05:09:09 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Aug 2004 05:09:09 -0000 Received: from hydrogen.funkthat.com (mzebix@localhost.funkthat.com [127.0.0.1])i7A598uU068807; Mon, 9 Aug 2004 22:09:08 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i7A598OM068806; Mon, 9 Aug 2004 22:09:08 -0700 (PDT) Date: Mon, 9 Aug 2004 22:09:07 -0700 From: John-Mark Gurney To: Martin MATO Message-ID: <20040810050907.GL991@funkthat.com> Mail-Followup-To: Martin MATO , freebsd-current@freebsd.org References: <41183662.4010802@wanadoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41183662.4010802@wanadoo.fr> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-current@freebsd.org Subject: Re: ACPI autoload failed: no such file or directory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 05:09:09 -0000 Martin MATO wrote this message on Tue, Aug 10, 2004 at 04:43 +0200: > anyone could explain this.. strange thing? Someone else is seeing this w/ pf... Do you have any lines modifing module_path in your loader.conf? Also, do you have an upto date support.4th? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 05:25:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26C4516A4CF for ; Tue, 10 Aug 2004 05:25:02 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id C093543D45 for ; Tue, 10 Aug 2004 05:25:01 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by mproxy.gmail.com with SMTP id 75so128004rnl for ; Mon, 09 Aug 2004 22:24:52 -0700 (PDT) Received: by 10.38.86.74 with SMTP id j74mr987032rnb; Mon, 09 Aug 2004 22:24:51 -0700 (PDT) Message-ID: Date: Tue, 10 Aug 2004 13:24:51 +0800 From: Jiawei Ye To: John-Mark Gurney In-Reply-To: <20040810044257.GJ991@funkthat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_91_1203969.1092115491969" References: <200408092003.28922.max@love2party.net> <20040809222127.GU64690@camelot.theinternet.com.au> <200408100040.23324.max@love2party.net> <20040809225255.GI991@funkthat.com> <20040810044257.GJ991@funkthat.com> cc: freebsd-current@freebsd.org Subject: Re: kldload pf failed on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 05:25:02 -0000 ------=_Part_91_1203969.1092115491969 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, 9 Aug 2004 21:42:57 -0700, John-Mark Gurney > > could you also send me your loader.conf and device.hints along with > the output of ident as shown above? > > Thanks. > -- > John-Mark Gurney Voice: +1 415 225 5579 No problem here you go. root@chihiro:/boot# ident support.4th defaults/loader.conf support.4th: $FreeBSD: src/sys/boot/forth/support.4th,v 1.15 2002/05/24 02:28:58 gordon Exp $ defaults/loader.conf: $FreeBSD: src/sys/boot/forth/loader.conf,v 1.85 2004/08/06 15:06:06 jmg Exp $ Attached are loader.conf and device.hints Jiawei ------=_Part_91_1203969.1092115491969 Content-Type: text/plain; name="device.hints" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="device.hints" # $FreeBSD: src/sys/i386/conf/GENERIC.hints,v 1.13 2004/04/01 21:48:31 alfr= ed Exp $ hint.fdc.0.at=3D"isa" hint.fdc.0.port=3D"0x3F0" hint.fdc.0.irq=3D"6" hint.fdc.0.drq=3D"2" hint.fd.0.at=3D"fdc0" hint.fd.0.drive=3D"0" hint.fd.1.at=3D"fdc0" hint.fd.1.drive=3D"1" hint.ata.0.at=3D"isa" hint.ata.0.port=3D"0x1F0" hint.ata.0.irq=3D"14" hint.ata.1.at=3D"isa" hint.ata.1.port=3D"0x170" hint.ata.1.irq=3D"15" hint.adv.0.at=3D"isa" hint.adv.0.disabled=3D"1" hint.bt.0.at=3D"isa" hint.bt.0.disabled=3D"1" hint.aha.0.at=3D"isa" hint.aha.0.disabled=3D"1" hint.aic.0.at=3D"isa" hint.aic.0.disabled=3D"1" hint.atkbdc.0.at=3D"isa" hint.atkbdc.0.port=3D"0x060" hint.atkbd.0.at=3D"atkbdc" hint.atkbd.0.irq=3D"1" hint.psm.0.at=3D"atkbdc" hint.psm.0.irq=3D"12" hint.vga.0.at=3D"isa" hint.sc.0.at=3D"isa" hint.sc.0.flags=3D"0x100" hint.vt.0.at=3D"isa" hint.vt.0.disabled=3D"1" hint.apm.0.disabled=3D"1" hint.apm.0.flags=3D"0x20" hint.pcic.0.at=3D"isa" # hint.pcic.0.irq=3D"10"=09# Default to polling hint.pcic.0.port=3D"0x3e0" hint.pcic.0.maddr=3D"0xd0000" hint.pcic.1.at=3D"isa" hint.pcic.1.irq=3D"11" hint.pcic.1.port=3D"0x3e2" hint.pcic.1.maddr=3D"0xd4000" hint.pcic.1.disabled=3D"1" hint.sio.0.at=3D"isa" hint.sio.0.port=3D"0x3F8" hint.sio.0.flags=3D"0x10" hint.sio.0.irq=3D"4" hint.sio.1.at=3D"isa" hint.sio.1.port=3D"0x2F8" hint.sio.1.irq=3D"3" hint.sio.2.at=3D"isa" hint.sio.2.disabled=3D"1" hint.sio.2.port=3D"0x3E8" hint.sio.2.irq=3D"5" hint.sio.3.at=3D"isa" hint.sio.3.disabled=3D"1" hint.sio.3.port=3D"0x2E8" hint.sio.3.irq=3D"9" hint.ppc.0.at=3D"isa" hint.ppc.0.irq=3D"7" hint.ed.0.at=3D"isa" hint.ed.0.disabled=3D"1" hint.ed.0.port=3D"0x280" hint.ed.0.irq=3D"10" hint.ed.0.maddr=3D"0xd8000" hint.cs.0.at=3D"isa" hint.cs.0.disabled=3D"1" hint.cs.0.port=3D"0x300" hint.sn.0.at=3D"isa" hint.sn.0.disabled=3D"1" hint.sn.0.port=3D"0x300" hint.sn.0.irq=3D"10" hint.ie.0.at=3D"isa" hint.ie.0.disabled=3D"1" hint.ie.0.port=3D"0x300" hint.ie.0.irq=3D"10" hint.ie.0.maddr=3D"0xd0000" hint.fe.0.at=3D"isa" hint.fe.0.disabled=3D"1" hint.fe.0.port=3D"0x300" hint.lnc.0.at=3D"isa" hint.lnc.0.disabled=3D"1" hint.lnc.0.port=3D"0x280" hint.lnc.0.irq=3D"10" hint.lnc.0.drq=3D"0" ------=_Part_91_1203969.1092115491969 Content-Type: text/plain; name="loader.conf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="loader.conf" io_load=3D"YES"=09=09=09# /dev/io mem_load=3D"YES"=09=09=09# /dev/mem smbfs_load=3D"YES"=09=09# load smbfs untill they fix mount_smbfs if_fxp_load=3D"YES"=09=09# Intel EtherExpress PRO/100B (82557, 82558) if_rl_load=3D"YES"=09=09# RealTek 8129/8139 usb_load=3D"YES"=09=09=09# USB snd_ich_load=3D"YES"=09=09# ICH AC97 ------=_Part_91_1203969.1092115491969-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 05:39:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E232B16A4CE for ; Tue, 10 Aug 2004 05:39:13 +0000 (GMT) Received: from huva.hittite.isp.9tel.net (huva.hittite.isp.9tel.net [62.62.156.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DE0B43D45 for ; Tue, 10 Aug 2004 05:39:13 +0000 (GMT) (envelope-from martin.mato@wanadoo.fr) Received: from [192.168.0.2] (unknown [84.98.17.24]) by huva.hittite.isp.9tel.net (Postfix) with ESMTP id 0F4E314B5CC for ; Tue, 10 Aug 2004 07:48:44 +0200 (CEST) Message-ID: <41185F7F.8070906@wanadoo.fr> Date: Tue, 10 Aug 2004 07:39:11 +0200 From: Martin MATO User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: fr, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <41183662.4010802@wanadoo.fr> <20040810050907.GL991@funkthat.com> In-Reply-To: <20040810050907.GL991@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: ACPI autoload failed: no such file or directory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: martin.mato@wanadoo.fr List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 05:39:14 -0000 John-Mark Gurney a écrit : >Martin MATO wrote this message on Tue, Aug 10, 2004 at 04:43 +0200: > > >>anyone could explain this.. strange thing? >> >> > >Someone else is seeing this w/ pf... > >Do you have any lines modifing module_path in your loader.conf? Also, >do you have an upto date support.4th? > > > i haven't any lines modifying module_path ( Andrew Milton has mailed me about adding module_path="/boot/kernel /boot/modules" to /boot/loader.conf, should fix it; but has no effects.) and i have an up to date support.4th , compiled at the same time as the kernel files. booting whith the GENERIC kernel has same behaviour, but with other errors messages; not in relation whith acpi; but debug support (!) i'll try compiling one whitout any OPTFLAGS and CFLAGS optimization, to see... (i use -O2 -pipe) but i doubt it is in relation with the kldload behaviour... ps: sorry for my bad english, i'm french... From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 05:39:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CE6F16A4CE for ; Tue, 10 Aug 2004 05:39:38 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B72E43D45 for ; Tue, 10 Aug 2004 05:39:38 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by mproxy.gmail.com with SMTP id 75so128262rnl for ; Mon, 09 Aug 2004 22:39:34 -0700 (PDT) Received: by 10.38.24.64 with SMTP id 64mr1213804rnx; Mon, 09 Aug 2004 22:39:34 -0700 (PDT) Message-ID: Date: Tue, 10 Aug 2004 13:39:34 +0800 From: Jiawei Ye To: John-Mark Gurney In-Reply-To: <20040810050907.GL991@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41183662.4010802@wanadoo.fr> <20040810050907.GL991@funkthat.com> cc: Martin MATO cc: freebsd-current@freebsd.org Subject: Re: ACPI autoload failed: no such file or directory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 05:39:38 -0000 On Mon, 9 Aug 2004 22:09:07 -0700, John-Mark Gurney wrote: > Someone else is seeing this w/ pf... > > Do you have any lines modifing module_path in your loader.conf? Also, > do you have an upto date support.4th? > > -- > John-Mark Gurney Voice: +1 415 225 5579 My /boot/default/loader.conf contains this line: module_path="/boot/modules" # Set the module search path I suppose that's where it's picking up. There is no /boot/kernel entry. Jiawei From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 06:04:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08FC516A4CE for ; Tue, 10 Aug 2004 06:04:07 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id D69EB43D46 for ; Tue, 10 Aug 2004 06:04:06 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 24631 invoked from network); 10 Aug 2004 06:04:06 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Aug 2004 06:04:06 -0000 Received: from hydrogen.funkthat.com (juzmjk@localhost.funkthat.com [127.0.0.1])i7A645uU069643; Mon, 9 Aug 2004 23:04:05 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i7A64550069642; Mon, 9 Aug 2004 23:04:05 -0700 (PDT) Date: Mon, 9 Aug 2004 23:04:05 -0700 From: John-Mark Gurney To: Jiawei Ye Message-ID: <20040810060405.GM991@funkthat.com> Mail-Followup-To: Jiawei Ye , freebsd-current@freebsd.org References: <200408092003.28922.max@love2party.net> <20040809222127.GU64690@camelot.theinternet.com.au> <200408100040.23324.max@love2party.net> <20040809225255.GI991@funkthat.com> <20040810044257.GJ991@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-current@freebsd.org Subject: Re: kldload pf failed on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 06:04:07 -0000 Jiawei Ye wrote this message on Tue, Aug 10, 2004 at 13:24 +0800: > On Mon, 9 Aug 2004 21:42:57 -0700, John-Mark Gurney > > > could you also send me your loader.conf and device.hints along with > > the output of ident as shown above? > > root@chihiro:/boot# ident support.4th defaults/loader.conf > support.4th: > $FreeBSD: src/sys/boot/forth/support.4th,v 1.15 2002/05/24 > 02:28:58 gordon Exp $ > > defaults/loader.conf: > $FreeBSD: src/sys/boot/forth/loader.conf,v 1.85 2004/08/06 > 15:06:06 jmg Exp $ > > Attached are loader.conf and device.hints hmmm... now I'm really puzzled... there is code in support.4th that adds in the current boot directory to the module path... could you break out to the loader prompt, and see what show module_path returns? mine: OK show module_path /boot/kernel;/boot/modules -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 06:31:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C25FD16A4D7 for ; Tue, 10 Aug 2004 06:31:12 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FEB043D60 for ; Tue, 10 Aug 2004 06:31:12 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.11/8.12.11) id i7A6VBaS069437 for freebsd-current@freebsd.org; Tue, 10 Aug 2004 01:31:11 -0500 (CDT) (envelope-from dan) Date: Tue, 10 Aug 2004 01:31:11 -0500 From: Dan Nelson To: freebsd-current@freebsd.org Message-ID: <20040810063111.GB6474@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-OS: FreeBSD 5.2-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i Subject: panic: _mtx_lock_sleep: recursed on non-recursive mutex sbc0 @ ../../../dev/sound/isa/sbc.c:131 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 06:31:12 -0000 For at least the last week's worth of kernels I've been getting the following panic whenever I try and write to /dev/dsp. It may have been broken longer, but I don't usually use the soundcard on this machine. I triggered this one with with a simple "echo hi > /dev/dsp": panic messages: --- panic: _mtx_lock_sleep: recursed on non-recursive mutex sbc0 @ ../../../dev/sound/isa/sbc.c:131 (kgdb) where #0 doadump () at machine/pcpu.h:159 #1 0xc052bfb5 in boot (howto=260) at ../../../kern/kern_shutdown.c:399 #2 0xc052c2af in panic () at ../../../kern/kern_shutdown.c:561 #3 0xc0524347 in _mtx_lock_sleep (m=0xc142c200, td=0xc1572c60, opts=0, file=0xc06a8d73 "../../../dev/sound/isa/sbc.c", line=131) at ../../../kern/kern_mutex.c:482 #4 0xc0523caa in _mtx_lock_flags (m=0xc142c200, opts=0, file=0xc06a8d73 "../../../dev/sound/isa/sbc.c", line=131) at ../../../kern/kern_mutex.c:253 #5 0xc04c87fa in sbc_lock (scp=0x0) at ../../../dev/sound/isa/sbc.c:131 #6 0xc04c774a in sb_lock (sb=0x0) at ../../../dev/sound/isa/sb16.c:123 #7 0xc04c78d6 in sb_cmd2 (sb=0xc1395a00, cmd=0 '\0', val=127) at ../../../dev/sound/isa/sb16.c:212 #8 0xc04c81e7 in sb_setup (sb=0xc1395a00) at ../../../dev/sound/isa/sb16.c:630 #9 0xc04c8388 in sb16chan_trigger (obj=0xc1422860, data=0xc1395a2c, go=0) at ../../../dev/sound/isa/sb16.c:727 #10 0xc04ccea2 in chn_trigger (c=0x1, go=1) at channel_if.h:100 #11 0xc04cbd67 in chn_start (c=0xc13aa500, force=1) at ../../../dev/sound/pcm/channel.c:543 #12 0xc04cbf9e in chn_flush (c=0xc13aa500) at ../../../dev/sound/pcm/channel.c:673 #13 0xc04cdb45 in dsp_close (i_dev=0xc1397500, flags=2, mode=8192, td=0xc1572c60) at ../../../dev/sound/pcm/dsp.c:379 #14 0xc04fa16f in spec_close (ap=0xcc201b70) at ../../../fs/specfs/spec_vnops.c:637 #15 0xc04f9293 in spec_vnoperate (ap=0x0) at ../../../fs/specfs/spec_vnops.c:118 #16 0xc0582942 in vn_close (vp=0xc18c1240, flags=2, file_cred=0xc1865180, td=0xc1572c60) at vnode_if.h:262 #17 0xc0583ad6 in vn_closefile (fp=0xc1558990, td=0xc1572c60) at ../../../kern/vfs_vnops.c:949 #18 0xc0511857 in fdrop_locked (fp=0xc1558990, td=0xc1572c60) at ../../../sys/file.h:289 #19 0xc0510be0 in fdrop (fp=0xc1558990, td=0xc1572c60) at ../../../kern/kern_descrip.c:1910 #20 0xc0510bb3 in closef (fp=0xc1558990, td=0xc1572c60) at ../../../kern/kern_descrip.c:1896 #21 0xc050ec20 in do_dup (td=0xc1572c60, type=DUP_FIXED, old=11, new=1, retval=0xc1572d74) at ../../../kern/kern_descrip.c:700 #22 0xc050dde5 in dup2 (td=0x0, uap=0x0) at ../../../kern/kern_descrip.c:255 #23 0xc06670bf in syscall (frame= {tf_fs = 134676527, tf_es = -1078001617, tf_ds = -1078001617, tf_edi = 1, tf_esi = 672130312, tf_ebp = -1077941624, tf_isp = -870310540, tf_ebx = 67210923 6, tf_edx = 0, tf_ecx = 673317580, tf_eax = 90, tf_trapno = 12, tf_err = 2, tf_e ip = 672806431, tf_cs = 31, tf_eflags = 643, tf_esp = -1077941652, tf_ss = 47}) at ../../../i386/i386/trap.c:1004 #24 0xc0657e5f in Xint0x80_syscall () at {standard input}:137 ---Can't read userspace from dump, or kernel process--- -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 07:06:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E0D516A4CE; Tue, 10 Aug 2004 07:06:06 +0000 (GMT) Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD99443D41; Tue, 10 Aug 2004 07:06:05 +0000 (GMT) (envelope-from mike@urgle.com) Received: from guylian.urgle.com ([80.177.40.54]) by anchor-post-33.mail.demon.net with esmtp (Exim 3.35 #1) id 1BuQhw-000Mb1-0X; Tue, 10 Aug 2004 07:06:04 +0000 Received: from mike by guylian.urgle.com with local (Exim 4.32; FreeBSD) id 1BuQhv-0007JK-Sh; Tue, 10 Aug 2004 07:06:03 +0000 Date: Tue, 10 Aug 2004 08:06:03 +0100 From: Mike Bristow To: Robert Watson Message-ID: <20040810070603.GA27291@urgle.com> References: <1092044482.20927.35.camel@singsing.eng.demon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: panic: mutex vr0 not owned at ...if_vr.c:571 when doing ifconfig X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 07:06:06 -0000 On Mon, Aug 09, 2004 at 06:41:43PM -0400, Robert Watson wrote: > Hmm. I actually committed a slightly different patch as if_vr.c:1.93 to > acquire the lock around vr_setcfg() in vr_miibus_statchg(). Could you > check that that also solves the problem? When I tried that, it booted but paniced as soon as I ran 'ifconfig vr0 media blah': # ifconfig vr0 media 100baseTX panic: _mtx_lock_sleep: recursed on non-recursive mutex vr0 @ +/usr/src/sys/pci/if_vr.c:506 cpuid = 1 KDB: enter: panic [thread 100089] Stopped at kdb_enter+0x30: leave db> trace kdb_enter(... panic(... _mtx_lock_sleep _mtx_lock_flags vr_miibus_statchg miibus_statchg mii_phy_update amphy_service mii_mediachg vr_init_locked vr_init vr_ifmdia_upd ifmedia_ioctl vr_ioctl ifhwioctl ifioctl syscall Xint0x80_syscall -- You dont have to be illiterate to use the Internet, but it help's. From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 07:20:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A9AB16A4CE for ; Tue, 10 Aug 2004 07:20:06 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B6A743D45 for ; Tue, 10 Aug 2004 07:20:05 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i7A7K3X213614; Tue, 10 Aug 2004 09:20:03 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) i7A7K2f85814; Tue, 10 Aug 2004 09:20:02 +0200 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i7A7K1e07297; Tue, 10 Aug 2004 09:20:02 +0200 (MET DST) Date: Tue, 10 Aug 2004 09:20:10 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: Kris Kennaway In-Reply-To: <20040809212544.GA86157@xor.obsecurity.org> Message-ID: <20040810091743.X42422@beagle.kn.op.dlr.de> References: <20040809212544.GA86157@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: world broken (libbsnmp broken, and "+for: not found") X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 07:20:06 -0000 On Mon, 9 Aug 2004, Kris Kennaway wrote: KK>World seems to be broken in two ways (updating from -current from KK>about a month ago): KK> KK>1) KK> KK>> ===> lib/libbsnmp/modules KK>> ===> lib/libbsnmp/modules/snmp_atm KK>> make: don't know how to make snmp_atm.h. Stop KK>> *** Error code 2 Ups. That should work. I'll have a look into this. KK>After reverting these commits, it gets a bit further before dying with KK> KK>2) KK> KK>echo routed: /usr/obj/a/portbuild/i386/src-client/i386/usr/lib/libc.a /usr/obj/a/portbuild/i386/src-client/i386/usr/lib/libmd.a >> .depend KK>+for: not found KK>*** Error code 127 KK> KK>Stop in /a/portbuild/i386/src-client/sbin/routed. KK>*** Error code 1 KK> KK>Stop in /a/obj/a/portbuild/i386/src-client/rescue/rescue. *** Error KK>code 1 I committed a fix to crunchgen yesterday in the evening (GMT). Make in rescue was picking up the wrong make binary. harti From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 07:24:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1317916A4CE for ; Tue, 10 Aug 2004 07:24:48 +0000 (GMT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 9013843D31 for ; Tue, 10 Aug 2004 07:24:44 +0000 (GMT) (envelope-from sebastian.ssmoller@gmx.net) Received: (qmail 32659 invoked by uid 65534); 10 Aug 2004 07:24:43 -0000 Received: from pD9E82618.dip.t-dialin.net (HELO tyrael.linnet) (217.232.38.24) by mail.gmx.net (mp019) with SMTP; 10 Aug 2004 09:24:43 +0200 X-Authenticated: #15005775 Date: Tue, 10 Aug 2004 09:26:48 +0200 From: sebastian ssmoller To: freebsd-current@freebsd.org Message-Id: <20040810092648.64e582c2.sebastian.ssmoller@gmx.net> In-Reply-To: <41182054.7090109@root.org> References: <41131EEC.4050909@root.org> <291946042.22742@mails.tsinghua.edu.cn> <41182054.7090109@root.org> X-Mailer: Sylpheed version 0.9.9-gtk2-20040229 (GTK+ 2.4.1; i386-portbld-freebsd5.2.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: PLEASE TEST: acpi pci irq routing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 07:24:48 -0000 hi, not sure what i should expect (to see). but this patch looks good here. everything works fine. no errors nor warnings. all irqs seem to be ok. thx regards, seb ps: hardware: asus m2400n notebook On Mon, 09 Aug 2004 18:09:40 -0700 Nate Lawson wrote: > Thanks for all the feedback to everyone who responded. I have > finished > reworking our PCI irq routing approach and the result is much simpler > while retaining the existing weighting algorithm from acpi_pci_link.c > (around since Oct. 2002). It removes the hack which causes the first > IRQ to be chosen from possible IRQs if the BIOS hasn't routed an > interrupt. The selection algorithm is to always use the BIOS irq, if > valid, and then select from the weighted priority list if that fails. > I've tested both approaches fully. > > Please test this patch to be sure all PCI devices continue (or begin) > to > function as expected. If something fails for you, please send me the > dmesg from boot -v. > > Thanks, > Nate > -- "Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away." --- Antoine de St. Exupery, Wind, Sand, and Stars, 1939 From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 07:28:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8984F16A4CE; Tue, 10 Aug 2004 07:28:03 +0000 (GMT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id F378A43D1F; Tue, 10 Aug 2004 07:28:02 +0000 (GMT) (envelope-from DougB@freebsd.org) Received: from dougb.net ([24.130.110.32]) by comcast.net (sccrmhc11) with SMTP id <2004081007280101100kbjnme>; Tue, 10 Aug 2004 07:28:02 +0000 Date: Tue, 10 Aug 2004 00:28:00 -0700 (PDT) From: Doug Barton To: Harti Brandt In-Reply-To: <20040810091743.X42422@beagle.kn.op.dlr.de> Message-ID: <20040810002515.Q1614@qbhto.arg> References: <20040809212544.GA86157@xor.obsecurity.org> <20040810091743.X42422@beagle.kn.op.dlr.de> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: "current@freebsd.org" cc: Kris Kennaway Subject: Re: world broken (ps: structure has no member named ki_tid) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 07:28:03 -0000 On Tue, 10 Aug 2004, Harti Brandt wrote: > KK>After reverting these commits, it gets a bit further before dying with > KK> > KK>2) > KK> > KK>echo routed: /usr/obj/a/portbuild/i386/src-client/i386/usr/lib/libc.a /usr/obj/a/portbuild/i386/src-client/i386/usr/lib/libmd.a >> .depend > KK>+for: not found > KK>*** Error code 127 > KK> > KK>Stop in /a/portbuild/i386/src-client/sbin/routed. > KK>*** Error code 1 > KK> > KK>Stop in /a/obj/a/portbuild/i386/src-client/rescue/rescue. *** Error > KK>code 1 > > I committed a fix to crunchgen yesterday in the evening (GMT). Make in > rescue was picking up the wrong make binary. And if you can get past that one, it dies with: cc -O -ggdb -pipe -march=pentium4 -DLAZY_PS -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -c /usr/local/src/bin/ps/keyword.c /usr/local/src/bin/ps/keyword.c:112: error: structure has no member named `ki_tid' Argh. -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 07:51:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0A7216A4CE; Tue, 10 Aug 2004 07:51:20 +0000 (GMT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7090743D4C; Tue, 10 Aug 2004 07:51:20 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-68-121-219-69.dsl.snfc21.pacbell.net [68.121.219.69])i7A7pH3d167396; Tue, 10 Aug 2004 03:51:18 -0400 Message-ID: <41187E75.8040509@elischer.org> Date: Tue, 10 Aug 2004 00:51:17 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: Harti Brandt References: <20040809212544.GA86157@xor.obsecurity.org> <20040810091743.X42422@beagle.kn.op.dlr.de> In-Reply-To: <20040810091743.X42422@beagle.kn.op.dlr.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org cc: Kris Kennaway Subject: Re: world broken (libbsnmp broken, and "+for: not found") X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 07:51:21 -0000 Harti Brandt wrote: > On Mon, 9 Aug 2004, Kris Kennaway wrote: > > KK>World seems to be broken in two ways (updating from -current from > KK>about a month ago): > KK> > KK>1) > KK> > KK>> ===> lib/libbsnmp/modules > KK>> ===> lib/libbsnmp/modules/snmp_atm > KK>> make: don't know how to make snmp_atm.h. Stop > KK>> *** Error code 2 > > Ups. That should work. I'll have a look into this. > > KK>After reverting these commits, it gets a bit further before dying with > KK> > KK>2) > KK> > KK>echo routed: /usr/obj/a/portbuild/i386/src-client/i386/usr/lib/libc.a /usr/obj/a/portbuild/i386/src-client/i386/usr/lib/libmd.a >> .depend > KK>+for: not found > KK>*** Error code 127 > KK> > KK>Stop in /a/portbuild/i386/src-client/sbin/routed. > KK>*** Error code 1 > KK> > KK>Stop in /a/obj/a/portbuild/i386/src-client/rescue/rescue. *** Error > KK>code 1 > > I committed a fix to crunchgen yesterday in the evening (GMT). Make in > rescue was picking up the wrong make binary. > > harti > _______________________________________________ > 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" rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/routed/if.c /usr/src/sbin/routed/input.c /usr/src/sbin/routed/main.c /usr/src/sbin/routed/output.c /usr/src/sbin/routed/parms.c /usr/src/sbin/routed/radix.c /usr/src/sbin/routed/rdisc.c /usr/src/sbin/routed/table.c /usr/src/sbin/routed/trace.c echo routed: /usr/obj/usr/src/i386/usr/lib/libc.a /usr/obj/usr/src/i386/usr/lib/libmd.a >> .depend +for: not found *** Error code 127 Stop in /usr/src/sbin/routed. *** Error code 1 Stop in /usr/obj/usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue. any chance you could fix it? :-) From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 07:54:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F155616A4CE for ; Tue, 10 Aug 2004 07:54:54 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1158D43D55 for ; Tue, 10 Aug 2004 07:54:54 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i7A7seX340608; Tue, 10 Aug 2004 09:54:40 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) i7A7sef481404; Tue, 10 Aug 2004 09:54:40 +0200 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i7A7sde08535; Tue, 10 Aug 2004 09:54:39 +0200 (MET DST) Date: Tue, 10 Aug 2004 09:54:40 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: Julian Elischer In-Reply-To: <41187E75.8040509@elischer.org> Message-ID: <20040810095258.E42422@beagle.kn.op.dlr.de> References: <20040809212544.GA86157@xor.obsecurity.org> <20040810091743.X42422@beagle.kn.op.dlr.de> <41187E75.8040509@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org cc: Kris Kennaway Subject: Re: world broken (libbsnmp broken, and "+for: not found") X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 07:54:55 -0000 On Tue, 10 Aug 2004, Julian Elischer wrote: JE>Harti Brandt wrote: JE>> On Mon, 9 Aug 2004, Kris Kennaway wrote: JE>> JE>> KK>World seems to be broken in two ways (updating from -current from JE>> KK>about a month ago): JE>> KK> JE>> KK>1) JE>> KK> JE>> KK>> ===> lib/libbsnmp/modules JE>> KK>> ===> lib/libbsnmp/modules/snmp_atm JE>> KK>> make: don't know how to make snmp_atm.h. Stop JE>> KK>> *** Error code 2 JE>> JE>> Ups. That should work. I'll have a look into this. JE>> JE>> KK>After reverting these commits, it gets a bit further before dying with JE>> KK> JE>> KK>2) JE>> KK> JE>> KK>echo routed: /usr/obj/a/portbuild/i386/src-client/i386/usr/lib/libc.a JE>> /usr/obj/a/portbuild/i386/src-client/i386/usr/lib/libmd.a >> .depend JE>> KK>+for: not found JE>> KK>*** Error code 127 JE>> KK> JE>> KK>Stop in /a/portbuild/i386/src-client/sbin/routed. JE>> KK>*** Error code 1 JE>> KK> JE>> KK>Stop in /a/obj/a/portbuild/i386/src-client/rescue/rescue. *** Error JE>> KK>code 1 JE>> JE>> I committed a fix to crunchgen yesterday in the evening (GMT). Make in JE>> rescue was picking up the wrong make binary. JE>> JE>> harti JE>> _______________________________________________ JE>> freebsd-current@freebsd.org mailing list JE>> http://lists.freebsd.org/mailman/listinfo/freebsd-current JE>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" JE> JE>rm -f .depend JE>mkdep -f .depend -a -DRESCUE /usr/src/sbin/routed/if.c JE>/usr/src/sbin/routed/input.c /usr/src/sbin/routed/main.c JE>/usr/src/sbin/routed/output.c /usr/src/sbin/routed/parms.c JE>/usr/src/sbin/routed/radix.c /usr/src/sbin/routed/rdisc.c JE>/usr/src/sbin/routed/table.c /usr/src/sbin/routed/trace.c JE>echo routed: /usr/obj/usr/src/i386/usr/lib/libc.a JE>/usr/obj/usr/src/i386/usr/lib/libmd.a >> .depend JE>+for: not found JE>*** Error code 127 JE> JE>Stop in /usr/src/sbin/routed. JE>*** Error code 1 JE> JE>Stop in /usr/obj/usr/src/rescue/rescue. JE>*** Error code 1 JE> JE>Stop in /usr/src/rescue/rescue. JE>*** Error code 1 JE> JE>Stop in /usr/src/rescue. JE> JE>any chance you could fix it? :-) Could you please have a look into /usr/obj/usr/src/rescue/rescue/rescue.mk. If it contains the line MAKE=make near the beginning you have still the crunchgen without the fix I committed, or you tried to build without re-generating rescue.mk. harti From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 08:26:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83AA816A4CE for ; Tue, 10 Aug 2004 08:26:57 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF1DD43D45 for ; Tue, 10 Aug 2004 08:26:56 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i7A8Qa8H013148; Tue, 10 Aug 2004 01:26:40 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200408100826.i7A8Qa8H013148@gw.catspoiler.org> Date: Tue, 10 Aug 2004 01:26:36 -0700 (PDT) From: Don Lewis To: rnejdl@ringofsaturn.com In-Reply-To: <44129.12.148.147.242.1092077172.squirrel@[12.148.147.242]> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org cc: dnelson@allantgroup.com Subject: Re: Is anything being done re: the pcm timeout issue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 08:26:57 -0000 On 9 Aug, Rusty Nejdl wrote: > Conrad J. Sabatier said: >> > >>> Sound works fine for me on my Dell laptop (mss driver). I do get a >>> mutex-related panic on my desktop (sb16 driver), but haven't sent in >>> the stack trace to anyone yet. >> >> My problems are occurring on an amd64 box (Athlon 64) with the nVidia >> nForce3 chipset (snd_ich driver). >> >> Sounds works fine for a while, then suddenly I get a pcm play timeout, >> and game over. Have to reboot to get sound to work again. >> >> Others have reported similar problems, but I've seen no followups >> indicating anything is being done about it. >> > > I've been seeing a sound issue on 5.2.1-release and I wonder if it's > related at all to what you are seeing. I have : > > hw.snd.maxautovchans: 4 > hw.snd.pcm0.vchans: 4 > > And I have seen that these will eventually stop working one by one > until I have none left. lsof and fstat don't show any programs using > them, but nonetheless, programms like xmms and gaim can't use them > anymore. The vchan code is fairly broken. I was hoping to have to some time to work on this (and other problems in the top half of the sound code) before 5.3, but it looks like the clock has just about run out. > Do you have any more details on the pcm play timeout? Are you using > vchans? What program are you using? My suspicion is that there is either a problem in ich_intr() that it causing it to stop receiving interrupts or to stop calling chn_intr(), or there is enough interrupt latency to allow the DMA pointer to wrap and fool chn_dmaupdate() into thinking no data was consumed. It is possible that the ich_intr() problem is specific to amd64. I previously sent out these suggestions on how to debug the problem: ------ Forwarded message ------ From: Don Lewis Subject: Re: Questionable code in sys/dev/sound/pcm/channel.c Date: Tue, 27 Jul 2004 15:15:06 -0700 (PDT) To: mat@cnd.mcgill.ca Cc: freebsd-current@freebsd.org On 27 Jul, Mathew Kanner wrote: > On Jul 26, John-Mark Gurney wrote: >> Conrad J. Sabatier wrote this message on Mon, Jul 26, 2004 at 16:35 -0500: >> > Why the formulaic calculation of timeout, if it's simply going to be >> > unconditionally set to 1 immediately afterwards anyway? What's going on >> > here? >> >> Well, if you look at the annotations, that absolute set of timeout was >> added in rev 1.65 by cg with the comment: >> tweaks to reduce latency/pauses in output >> > > > I think this has been raised on the mailling list before. > IIRC, the logic for this is to check frequently for dead channels but > CG is the authoriy. My suspicion is that this change was made to reduce the consequences of lost wakeups from the interrupt routine. This would have been more of a problem when tsleep() was used in chn_sleep() and shouldn't be needed now that the top and bottom halves of the code use the channel lock and chn_sleep() uses msleep() to atomically release the lock and wait for the wakeup from the interrupt code. That said, setting timeout to 1 shouldn't hurt anything and will just waste a bit of CPU time. >> > Also, at the end of the function: >> > >> > if (count <= 0) { >> > c->flags |= CHN_F_DEAD; >> > printf("%s: play interrupt timeout, channel dead\n", c->name); >> > } >> > >> > return ret; >> > } >> >> that was changed in rev1.52 (by cg also), and previously was just a check >> for count == 0.. >> >> So, I'd recommend a message off to cg and ask why he made this changes... The original version of the code always set timeout to 1 and looped on (count > 0), so count could never go negative. When the code was changed to set count to something larger than 1, count could go negative if (hz % timeout != 0), so the condition for setting CHN_F_DEAD had to be modified accordingly. My suspicion is that there is sometimes enough latency in executing the interrupt routine that the hardware DMA pointer is wrapping and chn_dmaupdate() is calculating delta as zero. This would cause chn_wrfeed() not to consume any data from the software buffer (and skip the wakeup()), which might be enough to cause the chn_write() to time out while waiting for space to become available in the software buffer. It would be interesting to enable the debug code in chn_dmaupdate(), and add (delta == 0) as a condition to trigger the device_printf(). The bigger question is what is the cause of the latency ... ------ Forwarded message ------ From: Don Lewis Subject: Re: Questionable code in sys/dev/sound/pcm/channel.c Date: Tue, 27 Jul 2004 15:21:57 -0700 (PDT) To: conrads@cox.net Cc: freebsd-current@freebsd.org On 27 Jul, Conrad J. Sabatier wrote: > > On 26-Jul-2004 Conrad J. Sabatier wrote: >> >> On 26-Jul-2004 Conrad J. Sabatier wrote: >>> I'm a little perplexed at the following bit of logic in chn_write() >>> (which is where the "interrupt timeout, channel dead" messages are >>> being generated). > > [snip] > >>> Also, at the end of the function: >>> >>> if (count <= 0) { >>> c->flags |= CHN_F_DEAD; >>> printf("%s: play interrupt timeout, channel dead\n", >>> c->name); >>> } >>> >>> return ret; >>> } >>> >>> Could it be that the conditional test is wrong here? Perhaps >>> we should be using (count < 0) instead? >> >> I'm now running a kernel built with this last conditional test >> changed to "if (count < 0)" and sound is still working OK. Have yet >> to see if this eliminates the interrupt timeout messages. > > Well, that was a failure. :-) Didn't see any timeout error messages, > but the device still died eventually, nonetheless. I've since changed > back to the original code. That's an interesting data point. At this point I'd start looking at the driver code for your sound hardware. I suspect that the driver interrupt code is either no longer seeing interrupts, or it is no longer calling chn_intr(). From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 08:27:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 025B316A4CE; Tue, 10 Aug 2004 08:27:20 +0000 (GMT) Received: from ares.wolfpond.org (ns1.wolfpond.org [62.212.96.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id A195E43D3F; Tue, 10 Aug 2004 08:27:17 +0000 (GMT) (envelope-from ftigeot@wolfpond.org) Received: from aoi.wolfpond.org (aoi.wolfpond.org [IPv6:2001:7a8:24db:1:20c:76ff:feb4:27e1]) by ares.wolfpond.org (8.12.10/8.12.10) with ESMTP id i7A8RGNf002675; Tue, 10 Aug 2004 10:27:16 +0200 (CEST) (envelope-from ftigeot@aoi.wolfpond.org) Received: from aoi.wolfpond.org (localhost [127.0.0.1]) by aoi.wolfpond.org (8.12.11/8.12.11) with ESMTP id i7A8RNL5012847; Tue, 10 Aug 2004 10:27:23 +0200 (CEST) (envelope-from ftigeot@aoi.wolfpond.org) Received: (from ftigeot@localhost) by aoi.wolfpond.org (8.12.11/8.12.11/Submit) id i7A8RNcG012846; Tue, 10 Aug 2004 10:27:23 +0200 (CEST) (envelope-from ftigeot) Date: Tue, 10 Aug 2004 10:27:23 +0200 From: Francois Tigeot To: "Bjoern A. Zeeb" Message-ID: <20040810082723.GA8692@aoi.wolfpond.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: FreeBSD arch mailing list cc: FreeBSD current mailing list Subject: Re: NO_YP_LIBC patch - please test/review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 08:27:20 -0000 On Sun, Aug 08, 2004 at 03:21:41PM +0000, Bjoern A. Zeeb wrote: > > I am looking for more tests and reviews of the NO_YP_LIBC patch. > > You can find the latest version to test on > http://sources.zabbadoz.net/freebsd/patchset/10039-no-yp-libc.diff > > You will need to apply the whole patch in order to successfully build > a world with > NO_YP_LIBC=yes > in make.conf and thus be able to also test the changes. > Mostly things like bind, sendmail, amd, etc. that still get build will > need testing. I installed it on an i386 workstation. So far so good. If there are no problems with it in a few days I will try it on an amd64/sendmail server. -- Francois Tigeot From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 08:30:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E813916A4CE for ; Tue, 10 Aug 2004 08:30:56 +0000 (GMT) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 445FA43D2F for ; Tue, 10 Aug 2004 08:30:56 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd08.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1BuS1u-0005W3-02; Tue, 10 Aug 2004 10:30:46 +0200 Received: from Andro-Beta.Leidinger.net (Ek9ntZZLre2feWU2mF6AT2zizYOrmerwXw7Qu1HJQzLdBUHkoVSREx@[84.128.203.72]) by fmrl08.sul.t-online.com with esmtp id 1BuS1n-0QXUf20; Tue, 10 Aug 2004 10:30:39 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) i7A8UgKZ099358; Tue, 10 Aug 2004 10:30:42 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Tue, 10 Aug 2004 10:31:27 +0200 From: Alexander Leidinger To: "Bjoern A. Zeeb" Message-Id: <20040810103127.56fda573@Magellan.Leidinger.net> In-Reply-To: References: <200408080622.i786Mnhe017474@www1.pochta.ru> <20040808132524.GB1033@mehnert.org> <20040808155623.2fa6fb4b@Magellan.Leidinger.net> <20040809112700.GB659@mehnert.org> <20040809150754.13ca108a@Magellan.Leidinger.net> <20040809153341.24963cfd@Magellan.Leidinger.net> <20040809161137.0bab2d07@Magellan.Leidinger.net> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: Ek9ntZZLre2feWU2mF6AT2zizYOrmerwXw7Qu1HJQzLdBUHkoVSREx@t-dialin.net cc: Hannes Mehnert cc: current@freebsd.org Subject: Re: IPSec + 5.2.current Problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 08:30:57 -0000 On Mon, 9 Aug 2004 14:27:49 +0000 (UTC) "Bjoern A. Zeeb" wrote: > On Mon, 9 Aug 2004, Alexander Leidinger wrote: > > > > which on ? use vs. require ? I think this is just not HEAD. > > > > In my case it's -current from Jul 18. > > and use vs. require does make a difference for you ? I don't know, I can't test it, the box is in production now. But it seems to make a difference for Hannes. > > > your problem: do you really need gif(4) ? if yes - what for ? > > > > In my case the problem doesn't matter, since using FAST_IPSEC works for > > me. But I think it should be fixed for 5.3. > > the MSIZE= should really be fixed I think, yes. I was talking about the other problem we see, I have MSIZE in the kernel, and IPSEC didn't worked (at least not with require). > > As you can see in the above mentioned mail, I converted a 4.x system to > > -current. On 4.x I've used gif for a tunnel (as documented in the > > handbook) > > I will have to read this. Nether had to use gif(4) with IPsec on the > 4.[7-*] machines I co-configered. Perhaps the handbook is just > outdated. > > > between the FreeBSD system and a VPN appliance which isn't > > under my control. Is there another way to setup a tunnel in -current? > > only use IPSec w/o gif(4). gif(4) is currently needed for few things > - IPv6 with FAST_IPSEC > - running s.th. like a link bound routing protocol over IPsec (I think) > > That's what I can think of at the moment. > > but take care - whatever your applicance on the other side does and > how it had worked up to now ... Since it works and the system went live, I won't change anything ATM. Bye, Alexander. -- I'm available to get hired (preferred in .lu). http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 08:38:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F18E316A4CE for ; Tue, 10 Aug 2004 08:38:41 +0000 (GMT) Received: from fep22-app.kolumbus.fi (fep22-0.kolumbus.fi [193.229.0.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE9B143D39 for ; Tue, 10 Aug 2004 08:38:40 +0000 (GMT) (envelope-from santtu.lintervo@kolumbus.fi) Received: from a81-197-39-234.elisa-laajakaista.fi ([81.197.39.234]) by fep22-app.kolumbus.fi with ESMTP <20040810083839.POPJ27645.fep22-app.kolumbus.fi@a81-197-39-234.elisa-laajakaista.fi> for ; Tue, 10 Aug 2004 11:38:39 +0300 From: Santtu Lintervo To: freebsd-current@freebsd.org Date: Tue, 10 Aug 2004 11:37:11 +0300 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408101137.11297.santtu.lintervo@kolumbus.fi> Subject: INDEX file format X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: santtu.lintervo@kolumbus.fi List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 08:38:42 -0000 hello, it seems that the INDEX file format has changed recently. where can i get the format of the file? --santtu From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 08:55:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 095E116A4CE; Tue, 10 Aug 2004 08:55:24 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80A1443D49; Tue, 10 Aug 2004 08:55:23 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i7A8tMjQ071326; Tue, 10 Aug 2004 04:55:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7A8tLgA077100; Tue, 10 Aug 2004 04:55:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id ACF137303F; Tue, 10 Aug 2004 04:55:21 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040810085521.ACF137303F@freebsd-current.sentex.ca> Date: Tue, 10 Aug 2004 04:55:21 -0400 (EDT) Subject: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 08:55:24 -0000 TB --- 2004-08-10 08:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-10 08:00:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2004-08-10 08:00:00 - checking out the source tree TB --- 2004-08-10 08:00:00 - cd /home/tinderbox/sandbox/CURRENT/alpha/alpha TB --- 2004-08-10 08:00:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-10 08:05:33 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-10 08:05:33 - cd /home/tinderbox/sandbox/CURRENT/alpha/alpha/src TB --- 2004-08-10 08:05:33 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] mkdep -f .depend -a -I. -DNS -DINET6 -DRESCUE /tinderbox/CURRENT/alpha/alpha/src/sbin/route/route.c echo route: /home/tinderbox/sandbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libc.a >> .depend cc -O2 -pipe -mcpu=ev4 -mtune=ev5 -mieee -I. -Wall -DNS -DINET6 -DRESCUE -c /tinderbox/CURRENT/alpha/alpha/src/sbin/route/route.c (cd /tinderbox/CURRENT/alpha/alpha/src/rescue/rescue/../../sbin/routed && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE if.o input.o main.o output.o parms.o radix.o rdisc.o table.o trace.o) rm -f .depend mkdep -f .depend -a -DRESCUE /tinderbox/CURRENT/alpha/alpha/src/sbin/routed/if.c /tinderbox/CURRENT/alpha/alpha/src/sbin/routed/input.c /tinderbox/CURRENT/alpha/alpha/src/sbin/routed/main.c /tinderbox/CURRENT/alpha/alpha/src/sbin/routed/output.c /tinderbox/CURRENT/alpha/alpha/src/sbin/routed/parms.c /tinderbox/CURRENT/alpha/alpha/src/sbin/routed/radix.c /tinderbox/CURRENT/alpha/alpha/src/sbin/routed/rdisc.c /tinderbox/CURRENT/alpha/alpha/src/sbin/routed/table.c /tinderbox/CURRENT/alpha/alpha/src/sbin/routed/trace.c echo routed: /home/tinderbox/sandbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libc.a /home/tinderbox/sandbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libmd.a >> .depend +for: not found *** Error code 127 Stop in /tinderbox/CURRENT/alpha/alpha/src/sbin/routed. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2004-08-10 08:55:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-10 08:55:21 - ERROR: failed to build world TB --- 2004-08-10 08:55:21 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 09:04:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F42316A4CE; Tue, 10 Aug 2004 09:04:54 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD68343D49; Tue, 10 Aug 2004 09:04:52 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i7A94oX430140; Tue, 10 Aug 2004 11:04:51 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) i7A94of561356; Tue, 10 Aug 2004 11:04:50 +0200 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i7A94ne09415; Tue, 10 Aug 2004 11:04:50 +0200 (MET DST) Date: Tue, 10 Aug 2004 11:04:49 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: FreeBSD Tinderbox In-Reply-To: <20040810085521.ACF137303F@freebsd-current.sentex.ca> Message-ID: <20040810110343.O42422@beagle.kn.op.dlr.de> References: <20040810085521.ACF137303F@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: alpha@freebsd.org cc: current@freebsd.org Subject: Re: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 09:04:54 -0000 Hi, where can I find the complete tinderbox logs? The machine where they are running is telling me that it is under maintenance. harti On Tue, 10 Aug 2004, FreeBSD Tinderbox wrote: FT>TB --- 2004-08-10 08:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca FT>TB --- 2004-08-10 08:00:00 - starting CURRENT tinderbox run for alpha/alpha FT>TB --- 2004-08-10 08:00:00 - checking out the source tree FT>TB --- 2004-08-10 08:00:00 - cd /home/tinderbox/sandbox/CURRENT/alpha/alpha FT>TB --- 2004-08-10 08:00:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src FT>TB --- 2004-08-10 08:05:33 - building world (CFLAGS=-O2 -pipe) FT>TB --- 2004-08-10 08:05:33 - cd /home/tinderbox/sandbox/CURRENT/alpha/alpha/src FT>TB --- 2004-08-10 08:05:33 - /usr/bin/make -B buildworld FT>>>> Rebuilding the temporary build tree FT>>>> stage 1.1: legacy release compatibility shims FT>>>> stage 1.2: bootstrap tools FT>>>> stage 2.1: cleaning up the object tree FT>>>> stage 2.2: rebuilding the object tree FT>>>> stage 2.3: build tools FT>>>> stage 3: cross tools FT>>>> stage 4.1: building includes FT>>>> stage 4.2: building libraries FT>>>> stage 4.3: make dependencies FT>>>> stage 4.4: building everything FT>[...] FT>mkdep -f .depend -a -I. -DNS -DINET6 -DRESCUE /tinderbox/CURRENT/alpha/alpha/src/sbin/route/route.c FT>echo route: /home/tinderbox/sandbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libc.a >> .depend FT>cc -O2 -pipe -mcpu=ev4 -mtune=ev5 -mieee -I. -Wall -DNS -DINET6 -DRESCUE -c /tinderbox/CURRENT/alpha/alpha/src/sbin/route/route.c FT>(cd /tinderbox/CURRENT/alpha/alpha/src/rescue/rescue/../../sbin/routed && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE if.o input.o main.o output.o parms.o radix.o rdisc.o table.o trace.o) FT>rm -f .depend FT>mkdep -f .depend -a -DRESCUE /tinderbox/CURRENT/alpha/alpha/src/sbin/routed/if.c /tinderbox/CURRENT/alpha/alpha/src/sbin/routed/input.c /tinderbox/CURRENT/alpha/alpha/src/sbin/routed/main.c /tinderbox/CURRENT/alpha/alpha/src/sbin/routed/output.c /tinderbox/CURRENT/alpha/alpha/src/sbin/routed/parms.c /tinderbox/CURRENT/alpha/alpha/src/sbin/routed/radix.c /tinderbox/CURRENT/alpha/alpha/src/sbin/routed/rdisc.c /tinderbox/CURRENT/alpha/alpha/src/sbin/routed/table.c /tinderbox/CURRENT/alpha/alpha/src/sbin/routed/trace.c FT>echo routed: /home/tinderbox/sandbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libc.a /home/tinderbox/sandbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libmd.a >> .depend FT>+for: not found FT>*** Error code 127 FT> FT>Stop in /tinderbox/CURRENT/alpha/alpha/src/sbin/routed. FT>*** Error code 1 FT> FT>Stop in /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/rescue/rescue. FT>*** Error code 1 FT> FT>Stop in /tinderbox/CURRENT/alpha/alpha/src/rescue/rescue. FT>*** Error code 1 FT> FT>Stop in /tinderbox/CURRENT/alpha/alpha/src/rescue. FT>*** Error code 1 FT> FT>Stop in /tinderbox/CURRENT/alpha/alpha/src. FT>*** Error code 1 FT> FT>Stop in /tinderbox/CURRENT/alpha/alpha/src. FT>*** Error code 1 FT> FT>Stop in /tinderbox/CURRENT/alpha/alpha/src. FT>TB --- 2004-08-10 08:55:21 - WARNING: /usr/bin/make returned exit code 1 FT>TB --- 2004-08-10 08:55:21 - ERROR: failed to build world FT>TB --- 2004-08-10 08:55:21 - tinderbox aborted FT> FT>_______________________________________________ FT>freebsd-current@freebsd.org mailing list FT>http://lists.freebsd.org/mailman/listinfo/freebsd-current FT>To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" FT> FT> FT> From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 09:14:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA41F16A4CE; Tue, 10 Aug 2004 09:14:01 +0000 (GMT) Received: from eddie.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32B9243D3F; Tue, 10 Aug 2004 09:14:01 +0000 (GMT) (envelope-from simon@eddie.nitro.dk) Received: by eddie.nitro.dk (Postfix, from userid 1000) id 3A40A11819; Tue, 10 Aug 2004 11:13:59 +0200 (CEST) Date: Tue, 10 Aug 2004 11:13:59 +0200 From: "Simon L. Nielsen" To: Harti Brandt Message-ID: <20040810091358.GD42347@eddie.nitro.dk> References: <20040810085521.ACF137303F@freebsd-current.sentex.ca> <20040810110343.O42422@beagle.kn.op.dlr.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zS7rBR6csb6tI2e1" Content-Disposition: inline In-Reply-To: <20040810110343.O42422@beagle.kn.op.dlr.de> User-Agent: Mutt/1.5.6i cc: alpha@freebsd.org cc: FreeBSD Tinderbox cc: current@freebsd.org Subject: Re: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 09:14:02 -0000 --zS7rBR6csb6tI2e1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004.08.10 11:04:49 +0200, Harti Brandt wrote: > where can I find the complete tinderbox logs? The machine where they > are running is telling me that it is under maintenance. At http://freebsd-current.sentex.ca/tinderbox/ . There is also a link to it from http://www.freebsd.org/projects/ (that might be simpler to remember for later). --=20 Simon L. Nielsen FreeBSD Documentation Team --zS7rBR6csb6tI2e1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBGJHWh9pcDSc1mlERAq/TAKCgvVhWlIpzsExCrGehMH867apMGwCgw+oD I6s6PoajlbTFJlA+ZkH6LzY= =ptGC -----END PGP SIGNATURE----- --zS7rBR6csb6tI2e1-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 09:20:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6C1D16A4CF; Tue, 10 Aug 2004 09:20:24 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE14843D2D; Tue, 10 Aug 2004 09:20:21 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i7A9KKX570010; Tue, 10 Aug 2004 11:20:20 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) i7A9KKf561404; Tue, 10 Aug 2004 11:20:20 +0200 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i7A9KJe09679; Tue, 10 Aug 2004 11:20:19 +0200 (MET DST) Date: Tue, 10 Aug 2004 11:20:20 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: "Simon L. Nielsen" In-Reply-To: <20040810091358.GD42347@eddie.nitro.dk> Message-ID: <20040810111959.K42422@beagle.kn.op.dlr.de> References: <20040810085521.ACF137303F@freebsd-current.sentex.ca> <20040810091358.GD42347@eddie.nitro.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: alpha@freebsd.org cc: FreeBSD Tinderbox cc: current@freebsd.org Subject: Re: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 09:20:25 -0000 On Tue, 10 Aug 2004, Simon L. Nielsen wrote: SLN>On 2004.08.10 11:04:49 +0200, Harti Brandt wrote: SLN> SLN>> where can I find the complete tinderbox logs? The machine where they SLN>> are running is telling me that it is under maintenance. SLN> SLN>At http://freebsd-current.sentex.ca/tinderbox/ . There is also a link SLN>to it from http://www.freebsd.org/projects/ (that might be simpler to SLN>remember for later). Thanks. harti From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 09:34:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E51D16A4CE for ; Tue, 10 Aug 2004 09:34:58 +0000 (GMT) Received: from mail.imp.ch (ns1.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A871743D3F for ; Tue, 10 Aug 2004 09:34:56 +0000 (GMT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.9p2/8.12.3) with ESMTP id i7A9YoA2083284 for ; Tue, 10 Aug 2004 11:34:52 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Tue, 10 Aug 2004 11:34:50 +0200 (CEST) From: Martin Blapp To: current@freebsd.org Message-ID: <20040810113341.U31181@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checksum: 0d61b9acab0947b1a713fef02be29d01 X-Virus-Message-Status: No X-Virus-Status: No, scantime="0.0013 seconds" X-Spam-Status: No, hits=-4.64 required=5 scantime="1.5210 seconds" tests=BAYES_00, UPPERCASE_25_50 X-Scanned-By: MIMEDefang 2.44 Subject: Stalled processes consuming 100% CPU in latest current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 09:34:58 -0000 Hi all, With a snap from one week ago I get (truss output) getdtablesize() = 11095 (0x2b57) fcntl(5,F_GETFL,0x0) = 2 (0x2) fstat(5,0x281789c0) = 0 (0x0) fcntl(5,F_SETFD,0x1) = 0 (0x0) sigaction(SIGALRM,0x0,{ SIG_DFL 0x0|ONSTACK|RESTART|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t }) = 0 (0x0) sigprocmask(0x1,0xbfbfea60,0xbfbfea50) = 0 (0x0) sigaction(SIGALRM,{ SIG_DFL 0x0|ONSTACK|RESTART|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t },{ SIG_DFL 0x0|ONSTACK|RESTART|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t }) = 0 (0x0) sigprocmask(0x3,0x8fff840,0x0) = 0 (0x0) sigprocmask(0x1,0xbfbfeae0,0xbfbfead0) = 0 (0x0) sigaction(SIGALRM,{ 0x280e8bd2 0x0|ONSTACK|RESTART|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t },{ SIG_DFL 0x0|ONSTACK|RESTART|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t }) = 0 (0x0) sigprocmask(0x3,0x8fff840,0x0) = 0 (0x0) setitimer(0,{0 0, 300 0},{0 0, 0 0}) = 0 (0x0) And there it hangs forever and does nothing ... Martin Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 09:38:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B943816A4CE; Tue, 10 Aug 2004 09:38:15 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1E6D43D41; Tue, 10 Aug 2004 09:38:14 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7A9c3tW045651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Aug 2004 12:38:04 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7A9c5k9016613; Tue, 10 Aug 2004 12:38:05 +0300 (EEST) (envelope-from ru) Date: Tue, 10 Aug 2004 12:38:04 +0300 From: Ruslan Ermilov To: Harti Brandt Message-ID: <20040810093804.GA16437@ip.net.ua> References: <20040810085521.ACF137303F@freebsd-current.sentex.ca> <20040810091358.GD42347@eddie.nitro.dk> <20040810111959.K42422@beagle.kn.op.dlr.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline In-Reply-To: <20040810111959.K42422@beagle.kn.op.dlr.de> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: alpha@freebsd.org cc: FreeBSD Tinderbox cc: "Simon L. Nielsen" cc: current@freebsd.org Subject: Re: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 09:38:16 -0000 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 10, 2004 at 11:20:20AM +0200, Harti Brandt wrote: > On Tue, 10 Aug 2004, Simon L. Nielsen wrote: >=20 > SLN>On 2004.08.10 11:04:49 +0200, Harti Brandt wrote: > SLN> > SLN>> where can I find the complete tinderbox logs? The machine where they > SLN>> are running is telling me that it is under maintenance. > SLN> > SLN>At http://freebsd-current.sentex.ca/tinderbox/ . There is also a link > SLN>to it from http://www.freebsd.org/projects/ (that might be simpler to > SLN>remember for later). >=20 > Thanks. >=20 I know what's happening here. : TB --- 2004-08-10 08:55:21 - WARNING: /usr/bin/make returned exit code 1 ^^^^^^^^^^^^^ The rescue/ uses crunchgen(1) which used to emit these bogus MAKE assignments into the generated .mk files, so this new ``+@for'' construct in bsd.subdir.mk breaks. Now we need to make sure to update crunchgen(1). This can be fixed with the following change: %%% Index: Makefile.inc1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/Makefile.inc1,v retrieving revision 1.434 diff -u -r1.434 Makefile.inc1 --- Makefile.inc1 9 Aug 2004 11:38:41 -0000 1.434 +++ Makefile.inc1 10 Aug 2004 09:36:53 -0000 @@ -722,7 +722,7 @@ .endif =20 .if !defined(NO_RESCUE) && \ - ${BOOTSTRAPPING} < 501100 + ${BOOTSTRAPPING} < 502128 _crunchgen=3D usr.sbin/crunch/crunchgen .endif =20 %%% Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGJd8qRfpzJluFF4RAlw8AKCBgck064r8qU+0AgypNnZuyTlwfQCfVJ/p MODyKZrkBclChS9B7B7Fl1U= =e2kc -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 09:41:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EACE16A4CE; Tue, 10 Aug 2004 09:41:57 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6D6C43D54; Tue, 10 Aug 2004 09:41:55 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i7A9frX122620; Tue, 10 Aug 2004 11:41:54 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) i7A9fpf453098; Tue, 10 Aug 2004 11:41:51 +0200 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i7A9fpe10015; Tue, 10 Aug 2004 11:41:51 +0200 (MET DST) Date: Tue, 10 Aug 2004 11:41:52 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: Ruslan Ermilov In-Reply-To: <20040810093804.GA16437@ip.net.ua> Message-ID: <20040810113908.D42422@beagle.kn.op.dlr.de> References: <20040810085521.ACF137303F@freebsd-current.sentex.ca> <20040810111959.K42422@beagle.kn.op.dlr.de> <20040810093804.GA16437@ip.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: alpha@freebsd.org cc: FreeBSD Tinderbox cc: "Simon L. Nielsen" cc: current@freebsd.org Subject: Re: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 09:41:57 -0000 On Tue, 10 Aug 2004, Ruslan Ermilov wrote: RE>On Tue, Aug 10, 2004 at 11:20:20AM +0200, Harti Brandt wrote: RE>> On Tue, 10 Aug 2004, Simon L. Nielsen wrote: RE>> RE>> SLN>On 2004.08.10 11:04:49 +0200, Harti Brandt wrote: RE>> SLN> RE>> SLN>> where can I find the complete tinderbox logs? The machine where they RE>> SLN>> are running is telling me that it is under maintenance. RE>> SLN> RE>> SLN>At http://freebsd-current.sentex.ca/tinderbox/ . There is also a link RE>> SLN>to it from http://www.freebsd.org/projects/ (that might be simpler to RE>> SLN>remember for later). RE>> RE>> Thanks. RE>> RE>I know what's happening here. RE> RE>: TB --- 2004-08-10 08:55:21 - WARNING: /usr/bin/make returned exit code 1 RE> ^^^^^^^^^^^^^ RE> RE>The rescue/ uses crunchgen(1) which used to emit these bogus RE>MAKE assignments into the generated .mk files, so this new RE>``+@for'' construct in bsd.subdir.mk breaks. Ok, I was suspecting this. I'll do a buildworld with your patch... harti RE> RE>Now we need to make sure to update crunchgen(1). This can be RE>fixed with the following change: RE> RE>%%% RE>Index: Makefile.inc1 RE>=================================================================== RE>RCS file: /home/ncvs/src/Makefile.inc1,v RE>retrieving revision 1.434 RE>diff -u -r1.434 Makefile.inc1 RE>--- Makefile.inc1 9 Aug 2004 11:38:41 -0000 1.434 RE>+++ Makefile.inc1 10 Aug 2004 09:36:53 -0000 RE>@@ -722,7 +722,7 @@ RE> .endif RE> RE> .if !defined(NO_RESCUE) && \ RE>- ${BOOTSTRAPPING} < 501100 RE>+ ${BOOTSTRAPPING} < 502128 RE> _crunchgen= usr.sbin/crunch/crunchgen RE> .endif RE> RE>%%% RE> RE> RE>Cheers, RE> From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 09:51:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0B1E16A4CE; Tue, 10 Aug 2004 09:51:33 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E01743D41; Tue, 10 Aug 2004 09:51:33 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smtp3.sentex.ca (8.12.11/8.12.11) with ESMTP id i7A9pWZi073073; Tue, 10 Aug 2004 05:51:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7A9pWtf029396; Tue, 10 Aug 2004 05:51:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8F20D7303F; Tue, 10 Aug 2004 05:51:32 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040810095132.8F20D7303F@freebsd-current.sentex.ca> Date: Tue, 10 Aug 2004 05:51:32 -0400 (EDT) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 09:51:34 -0000 TB --- 2004-08-10 08:55:21 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-10 08:55:21 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-08-10 08:55:21 - checking out the source tree TB --- 2004-08-10 08:55:21 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64 TB --- 2004-08-10 08:55:21 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-10 09:01:13 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-10 09:01:13 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src TB --- 2004-08-10 09:01:13 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] mkdep -f .depend -a -I. -DNS -DINET6 -DRESCUE /tinderbox/CURRENT/amd64/amd64/src/sbin/route/route.c echo route: /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libc.a >> .depend cc -O2 -pipe -I. -Wall -DNS -DINET6 -DRESCUE -c /tinderbox/CURRENT/amd64/amd64/src/sbin/route/route.c (cd /tinderbox/CURRENT/amd64/amd64/src/rescue/rescue/../../sbin/routed && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE if.o input.o main.o output.o parms.o radix.o rdisc.o table.o trace.o) rm -f .depend mkdep -f .depend -a -DRESCUE /tinderbox/CURRENT/amd64/amd64/src/sbin/routed/if.c /tinderbox/CURRENT/amd64/amd64/src/sbin/routed/input.c /tinderbox/CURRENT/amd64/amd64/src/sbin/routed/main.c /tinderbox/CURRENT/amd64/amd64/src/sbin/routed/output.c /tinderbox/CURRENT/amd64/amd64/src/sbin/routed/parms.c /tinderbox/CURRENT/amd64/amd64/src/sbin/routed/radix.c /tinderbox/CURRENT/amd64/amd64/src/sbin/routed/rdisc.c /tinderbox/CURRENT/amd64/amd64/src/sbin/routed/table.c /tinderbox/CURRENT/amd64/amd64/src/sbin/routed/trace.c echo routed: /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libc.a /home/tinderbox/sandbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libmd.a >> .depend +for: not found *** Error code 127 Stop in /tinderbox/CURRENT/amd64/amd64/src/sbin/routed. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-08-10 09:51:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-10 09:51:32 - ERROR: failed to build world TB --- 2004-08-10 09:51:32 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 10:10:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D2A516A4CE for ; Tue, 10 Aug 2004 10:10:16 +0000 (GMT) Received: from mail.imp.ch (ns1.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FC8C43D66 for ; Tue, 10 Aug 2004 10:10:15 +0000 (GMT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.9p2/8.12.3) with ESMTP id i7AAA6HD092745 for ; Tue, 10 Aug 2004 12:10:08 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Tue, 10 Aug 2004 12:10:06 +0200 (CEST) From: Martin Blapp To: current@freebsd.org In-Reply-To: <20040810113341.U31181@cvs.imp.ch> Message-ID: <20040810120924.T31181@cvs.imp.ch> References: <20040810113341.U31181@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checksum: ea45ce8cae5c09381f4a84823dd248d8 X-Virus-Status: No, scantime="0.0019 seconds" X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=4 scantime="4.0182 seconds" tests=BAYES_00 X-Scanned-By: MIMEDefang 2.44 Subject: Re: Stalled processes consuming 100% CPU in latest current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 10:10:16 -0000 And shortly later I got this panic: db> where propagate_priority(c34c6840,c4989730,c34c6840,0,de955c74) at propagate_priority+ 0x82 turnstile_wait(c34e41c0,c0938c60,c4217160,6,4) at turnstile_wait+0x325 _mtx_lock_sleep(c0938c60,c34c6840,0,0,0) at _mtx_lock_sleep+0x122 softclock(0,0,0,0,0) at softclock+0x250 ithread_loop(c34e8680,de955d48,0,0,0) at ithread_loop+0x1a4 fork_exit(c062a11f,c34e8680,de955d48) at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xde955d7c, ebp = 0 --- Martin From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 10:11:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E94F16A4CE for ; Tue, 10 Aug 2004 10:11:54 +0000 (GMT) Received: from mail.imp.ch (ns1.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70E0543D70 for ; Tue, 10 Aug 2004 10:11:53 +0000 (GMT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.9p2/8.12.3) with ESMTP id i7AABRHD093021 for ; Tue, 10 Aug 2004 12:11:28 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Tue, 10 Aug 2004 12:11:26 +0200 (CEST) From: Martin Blapp To: current@freebsd.org Message-ID: <20040810121026.K31181@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checksum: bc07b25d42abd826572d9c87e57a418d X-Virus-Status: No, scantime="2.1074 seconds" X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=4 scantime="19.9525 seconds" tests=BAYES_00 X-Scanned-By: MIMEDefang 2.44 Subject: db> panic borken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 10:11:54 -0000 Hi, In older releases this worked just fine. Note that this is an IPS raid and dumping is not possible. But this isn't a reason to just deadlock completly ! db> panic panic: from debugger cpuid = 0; boot() called on cpu#0 Uptime: 2h33m54s Cannot dump. No dump device defined. pfs_vncache_unload(): 197 entries remaining Martin Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 10:46:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3610616A4CE; Tue, 10 Aug 2004 10:46:13 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 925E643D31; Tue, 10 Aug 2004 10:46:12 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i7AAkBvB083444; Tue, 10 Aug 2004 06:46:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7AAkBSb080802; Tue, 10 Aug 2004 06:46:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id BA00D7303F; Tue, 10 Aug 2004 06:46:11 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040810104611.BA00D7303F@freebsd-current.sentex.ca> Date: Tue, 10 Aug 2004 06:46:11 -0400 (EDT) Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 10:46:13 -0000 TB --- 2004-08-10 09:51:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-10 09:51:32 - starting CURRENT tinderbox run for i386/i386 TB --- 2004-08-10 09:51:32 - checking out the source tree TB --- 2004-08-10 09:51:32 - cd /home/tinderbox/sandbox/CURRENT/i386/i386 TB --- 2004-08-10 09:51:32 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-10 09:57:15 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-10 09:57:15 - cd /home/tinderbox/sandbox/CURRENT/i386/i386/src TB --- 2004-08-10 09:57:15 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] mkdep -f .depend -a -I. -DNS -DINET6 -DRESCUE /tinderbox/CURRENT/i386/i386/src/sbin/route/route.c echo route: /home/tinderbox/sandbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/usr/lib/libc.a >> .depend cc -O2 -pipe -I. -Wall -DNS -DINET6 -DRESCUE -c /tinderbox/CURRENT/i386/i386/src/sbin/route/route.c (cd /tinderbox/CURRENT/i386/i386/src/rescue/rescue/../../sbin/routed && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE if.o input.o main.o output.o parms.o radix.o rdisc.o table.o trace.o) rm -f .depend mkdep -f .depend -a -DRESCUE /tinderbox/CURRENT/i386/i386/src/sbin/routed/if.c /tinderbox/CURRENT/i386/i386/src/sbin/routed/input.c /tinderbox/CURRENT/i386/i386/src/sbin/routed/main.c /tinderbox/CURRENT/i386/i386/src/sbin/routed/output.c /tinderbox/CURRENT/i386/i386/src/sbin/routed/parms.c /tinderbox/CURRENT/i386/i386/src/sbin/routed/radix.c /tinderbox/CURRENT/i386/i386/src/sbin/routed/rdisc.c /tinderbox/CURRENT/i386/i386/src/sbin/routed/table.c /tinderbox/CURRENT/i386/i386/src/sbin/routed/trace.c echo routed: /home/tinderbox/sandbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/usr/lib/libc.a /home/tinderbox/sandbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/usr/lib/libmd.a >> .depend +for: not found *** Error code 127 Stop in /tinderbox/CURRENT/i386/i386/src/sbin/routed. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2004-08-10 10:46:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-10 10:46:11 - ERROR: failed to build world TB --- 2004-08-10 10:46:11 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 11:30:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E79B16A4CE for ; Tue, 10 Aug 2004 11:30:10 +0000 (GMT) Received: from lakermmtao12.cox.net (lakermmtao12.cox.net [68.230.240.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDC8343D31 for ; Tue, 10 Aug 2004 11:30:08 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.71.51]) by lakermmtao12.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP <20040810113007.KIMH14787.lakermmtao12.cox.net@dolphin.local.net>; Tue, 10 Aug 2004 07:30:07 -0400 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with ESMTP id i7ABU7ke032353; Tue, 10 Aug 2004 06:30:07 -0500 (CDT) (envelope-from conrads@dolphin.local.net) Received: (from conrads@localhost) by dolphin.local.net (8.13.1/8.13.1/Submit) id i7ABU2ia032352; Tue, 10 Aug 2004 06:30:02 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <61285.66.13.175.242.1092110128.squirrel@[66.13.175.242]> Date: Tue, 10 Aug 2004 06:30:02 -0500 (CDT) Organization: A Rag-Tag Band of Drug-Crazed Hippies From: "Conrad J. Sabatier" To: Rusty Nejdl cc: freebsd-current@freebsd.org cc: Dan Nelson Subject: Re: Is anything being done re: the pcm timeout issue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conrads@cox.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 11:30:10 -0000 On 10-Aug-2004 Rusty Nejdl wrote: > Conrad J. Sabatier said: >> >> No, no vchans in use here. My main audio app is madplay, which I >> run from a little "jukebox" script I wrote to play my MP3s. > > Ok, I've looked a bit at madplay and it looks like sound is very > different in 5.3-current. (Yes, I know about the device change in > the kernel). I haven't had a chance to test this out yet in 5.3 > because I've been focusing on some other issues - mainly GIANT's > which are killing performance for me in 5.2. > > I'm going to load this up on my laptop tomorrow and see if I can > cause this to break in any conceivable way for me. I have a dual > opteron system I can play with in my lab, but I'm afraid that this > one doesn't have sound on it. Cool, thanks. >> I've been unable to determine what's triggering the breakage myself. >> The script runs fine for a while, selecting random MP3 files and >> running madplay to play them one by one. Suddenly, madplay will >> output the message "output: write failed" (or something like that) >> and my system log will show "pcm0:play:0: play interrupt timeout, >> channel dead". >> >> After that, any further attempts to play a sound file of any sort >> result in only a split-second of sound followed by the same messages >> as above. The only cure is a reboot. >> >> I posted some truss output from madplay a while back, but it's >> probably not very useful, since a timeout had already occurred in >> a previous run, so the listing only showed what was happening once >> the device had already become broken. >> >> Catching it "in the act", so to speak, is tricky, as it may work >> fine for an hour or two before the first breakage occurs. This >> would require a HUGE amount of truss or ktrace logging. >> >> We had a discussion recently here about certain peculiarities in the >> sound code, but never reached any useful conclusions, and none of >> our sound experts ever joined in, either. > > Yeah, I noticed that too. Wasn't sure though, since I just recently > joined the list. > >> >> I would hate to see 5.3 released with this problem still unsolved, >> but it's beginning to look like that may, in fact, be the case, >> unfortunately. I had hoped, too, that by this time we would have >> seen the new MIDI code incorporated into the tree as well, but it >> seems that sound (other than the abrupt yanking of the previous >> MIDI code and the recent renaming of devices/drivers) is being sadly >> neglected lately. > > Well, let's get testing and breaking, then. I'm with you! If there's anything I can do, feel free to ask away. Thanks! -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 16:03:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0520C16A4CE; Mon, 9 Aug 2004 16:03:39 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (80-219-164-131.dclient.hispeed.ch [80.219.164.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08CF643D4C; Mon, 9 Aug 2004 16:03:37 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:50db:a483:0:20e:2eff:fe06:2376]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id i79G3PS72423 verified NO); Mon, 9 Aug 2004 18:03:33 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id i79G3Pr72422; Mon, 9 Aug 2004 18:03:25 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Mon, 9 Aug 2004 18:03:25 +0200 (CEST) Message-Id: <200408091603.i79G3Pr72422@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma To: freebsd-current@freebsd.org References: <200408071057.06960.ringworm@inbox.lv> <20040808064912.GA27705@les.ath.cx> <200408081730.i78HUN320899@Mail.NOSPAM.DynDNS.dK> <200408090554.17355.ringworm@inbox.lv> X-Mailman-Approved-At: Tue, 10 Aug 2004 11:37:05 +0000 cc: Harti Brandt cc: "Michael C. Shultz" Subject: Re: Need help: buildworld for CURRENT while under STABLE is not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 16:03:39 -0000 [keep replies to the list and I'll catch up later, thanks] > > (whether my build breaks further down the line, time will tell, > > my machine is slow and old, like me) > I've received much help with this off list. What was suggested and seems to > work is to comment out contrib/gensnmptree/gensnmptree.c but I've That should work too (everything needed seems to be somewhere else in the -stable build environment) > received another email saying that may cause other problems, anyways > my buildworld is still in progress (for 10hrs now). I'm told the author of I may be slower, but I have -DNOCLEAN for situations like this. This failure just in: It seems that `gengenrtl' is built to the expectations of the target -current crossbuild, and then it gets invoked during the -stable build as per the makefile: genrtl.c genrtl.h: gengenrtl ./gengenrtl > genrtl.c ./gengenrtl -h > genrtl.h This appears to result in the crossbuild failure I see: ./gengenrtl > genrtl.c ELF interpreter /libexec/ld-elf.so.1 not found Abort trap *** Error code 134 I'm hoping there's nowhere else in the crossbuild where I've taken timesaving shortcuts where this is built as a cross-tools target. Haven't looked. I'll do some half-hearted poking around to see if I can work around this and see if I complete the build on my rapidly- self-obsoleting source, to see if other beasties rear their heads. > contrib/gensnmptree/gensnmptree.c ? is aware of the problem so I have no > doubt it will be fixed sooner or later. Just thought I'd post my latest discoveries in case they're not already known. thanks barry bouwsma (direct replies to me aren't necessary, as I'll be offline again Real Soon Now) From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 16:23:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E7BE16A4CE for ; Mon, 9 Aug 2004 16:23:04 +0000 (GMT) Received: from web41115.mail.yahoo.com (web41115.mail.yahoo.com [66.218.93.31]) by mx1.FreeBSD.org (Postfix) with SMTP id 1EBF143D4C for ; Mon, 9 Aug 2004 16:23:04 +0000 (GMT) (envelope-from jmkatcher@yahoo.com) Message-ID: <20040809162303.17452.qmail@web41115.mail.yahoo.com> Received: from [24.18.54.216] by web41115.mail.yahoo.com via HTTP; Mon, 09 Aug 2004 09:23:03 PDT Date: Mon, 9 Aug 2004 09:23:03 -0700 (PDT) From: Jeffrey Katcher To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 10 Aug 2004 11:37:05 +0000 Subject: Default module load paths messed up in todays -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 16:23:04 -0000 For example: kldload if_ath fails kldload /boot/kernel/if_ath.ko works, but fails when dependencies (rc4, wlan, ath_hal) won't load. Each has to be explicitly loaded by full name in the right order. Thanks, Jeff Katcher From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 16:35:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0755F16A4CE for ; Mon, 9 Aug 2004 16:35:33 +0000 (GMT) Received: from dragon.relcom.ru (dragon.relcom.ru [194.58.36.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71BCB43D58 for ; Mon, 9 Aug 2004 16:35:32 +0000 (GMT) (envelope-from anatoly@relcom.ru) Received: from [213.128.192.73] (moscow3-a9.sibintek.net [213.128.192.73]) by dragon.relcom.ru with asmtp (encrypted) id 1BuD4I-000Cqc-LS for current@freebsd.org; (v1.249) (envelope-from ); Mon, 09 Aug 2004 20:32:15 +0400 Message-ID: <4117A7CF.5080303@relcom.ru> Date: Mon, 09 Aug 2004 20:35:27 +0400 From: anatoly@relcom.ru User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040807) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 10 Aug 2004 11:37:05 +0000 Subject: strange ipfilter's behavior X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 16:35:33 -0000 hey, after few current cvsup's ipfilter doesnt work properly. Seems none saw this problem. After boot process passed it seems ipfilter rules are not working properly (but they're loaded and you can see them via ipfstat -io). rules themself are applied for tun0 with ppp on it. If I run ipf -Fa -f /etc/ipf.conf manually ipfilter start working as it ought to. (same situation with ipnat) Question is.. i missed something in recent /etc/rc updates or its a bug? uname -a: FreeBSD lifebook 5.2-CURRENT FreeBSD 5.2-CURRENT #0: Mon Aug 9 14:35:50 MSD 2004 root@lifebook:/usr/obj/usr/src/sys/LIFEBOOK i386 /etc/rc.conf: ipfilter_enable="YES" ipfilter_program="/sbin/ipf" ipfilter_rules="/etc/ipf.conf" ipfilter_flags="" ipnat_enable="YES" # Set to YES to enable ipnat functionality ipnat_program="/sbin/ipnat" # where the ipnat program lives ipnat_rules="/etc/ipnat.conf" # rules definition file for ipnat ipnat_flags="" # additional flags for ipnat ipmon_enable="YES" ipmon_program="/sbin/ipmon" # where the ipfilter monitor program lives ipmon_flags="-Ds" # typically "-Ds" or "-D /var/log/ipflog" /etc/ipf.conf: (pretty ugly) count out on tun0 from any to any count in on tun0 from any to any pass out quick on tun0 proto tcp from any to any keep state pass out quick on tun0 proto icmp from any to any keep state pass out quick on tun0 proto udp from any to any keep state block return-icmp in log quick on tun0 proto udp from any to any block return-icmp(proto-unr) in log quick on tun0 proto icmp from any to any block return-rst in log quick on tun0 proto tcp from any to any From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 18:02:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 624D116A4CE for ; Mon, 9 Aug 2004 18:02:24 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (80-219-164-131.dclient.hispeed.ch [80.219.164.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3FF343D48 for ; Mon, 9 Aug 2004 18:02:22 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:50db:a483:0:20e:2eff:fe06:2376]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id i79I2HS81576 verified NO) for ; Mon, 9 Aug 2004 20:02:20 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id i79I2Hp81575; Mon, 9 Aug 2004 20:02:17 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Mon, 9 Aug 2004 20:02:17 +0200 (CEST) Message-Id: <200408091802.i79I2Hp81575@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma To: freebsd-current@freebsd.org References: <200408071057.06960.ringworm@inbox.lv> <20040808064912.GA27705@les.ath.cx> <200408081730.i78HUN320899@Mail.NOSPAM.DynDNS.dK> <200408090554.17355.ringworm@inbox.lv> <200408091603.i79G3Pr72422@Mail.NOSPAM.DynDNS.dK> X-Mailman-Approved-At: Tue, 10 Aug 2004 11:37:05 +0000 Subject: Re: Need help: buildworld for CURRENT while under STABLE is not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 18:02:24 -0000 [keep replies to the list and I'll catch up later, thanks] I wrote: > This failure just in: It seems that `gengenrtl' is built to the > expectations of the target -current crossbuild, and then it gets > invoked during the -stable build as per the makefile: > genrtl.c genrtl.h: gengenrtl > ./gengenrtl > genrtl.c > ./gengenrtl -h > genrtl.h (Apologies sent off-line for mistakenly assuming Harti Brandt was responsible for this part of the code) Hmmm. I see two issues in my build. The various cc_tools are built as part of my cross-build _build-tools step, where they're built static, and the above works. However, I don't see that those build-tools binaries get installed anywhere that show up in the BPATH or XPATH or STRICTTMPPATH used later. Could be pilot error here too. Anyway, rather than ./genFOO, it seems to me that this makefile should be trying to make use of the PATH in the environment, particularly for crossbuilds like mine. Stripping away the ./ from all the invoked paths in this makefile and relying on $PATH to DTRT was my first idea; of course, during the build-tools step, nothing has been installed to be invoked. So I thought maybe add `:.' to BPATH, and then I thought, aiee, maybe not. Instead I changed every `./' in this makefile and replaced it with `PATH=${PATH}:. ' and that seemed to work for the build-tools step. And it might as well work for the everything step, if only these binaries were to appear in the PATH before the `.', hmmm. I'll probably poke at that until I pass out or something. Once again, this is a crossbuild of -current on -stable. > This appears to result in the crossbuild failure I see: > ./gengenrtl > genrtl.c > ELF interpreter /libexec/ld-elf.so.1 not found thanks barry bouwsma From owner-freebsd-current@FreeBSD.ORG Mon Aug 9 20:19:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E76516A4CE; Mon, 9 Aug 2004 20:19:05 +0000 (GMT) Received: from mx1.originative.co.uk (freebsd.gotadsl.co.uk [81.6.249.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7EF343D53; Mon, 9 Aug 2004 20:19:02 +0000 (GMT) (envelope-from paul@originative.co.uk) Received: from [192.168.7.2] (myrddin [192.168.7.2]) by mx1.originative.co.uk (Postfix) with ESMTP id B479215565; Mon, 9 Aug 2004 21:19:09 +0100 (BST) From: Paul Richards To: "Brandon S. Allbery KF8NH" In-Reply-To: <1092000894.56646.3.camel@rushlight.kf8nh.com> References: <16659.6061.369420.562800@roam.psg.com> <1091822755.23206.39.camel@tomcat.kitchenlab.org> <16659.58793.887526.631294@roam.psg.com> <1091824128.23206.52.camel@tomcat.kitchenlab.org> <1091933302.56646.1.camel@rushlight.kf8nh.com> <16662.38633.549566.111706@roam.psg.com> <1092000894.56646.3.camel@rushlight.kf8nh.com> Content-Type: text/plain Message-Id: <1092082749.31886.24.camel@myrddin> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 09 Aug 2004 21:19:09 +0100 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 10 Aug 2004 11:37:05 +0000 cc: Randy Bush cc: "Bruce A. Mah" cc: FreeBSD Current Subject: Re: usb palm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Aug 2004 20:19:05 -0000 On Sun, 2004-08-08 at 22:34, Brandon S. Allbery KF8NH wrote: > On Sun, 2004-08-08 at 17:11, Randy Bush wrote: > > > For what it's worth, my Tungsten T3 syncs fine over USB with -STABLE. > > using /dev/??? > > /dev/ucom0 On a related note. Has anyone had any success connecting to a P800? I spent the w/e working on it and got to the point where I could bring a connection up and ping the phone, but the phone would then try and bring up a GPRS connection and closing that dropped the PPP connection from FreeBSD. From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 04:30:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 593BF16A4CF; Tue, 10 Aug 2004 04:30:28 +0000 (GMT) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 875CB43D31; Tue, 10 Aug 2004 04:30:27 +0000 (GMT) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.32) id 1BuORl-0007C7-Sk; Tue, 10 Aug 2004 11:41:13 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.12.10/8.12.10) with ESMTP id i7A4UY0m063572; Tue, 10 Aug 2004 11:30:34 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.12.10/8.12.10/Submit) id i7A4UYIu063567; Tue, 10 Aug 2004 11:30:34 +0700 (NOVST) (envelope-from danfe) Date: Tue, 10 Aug 2004 11:30:34 +0700 From: Alexey Dokuchaev To: harti@freebsd.org Message-ID: <20040810043034.GA61300@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Tue, 10 Aug 2004 11:37:05 +0000 cc: current@freebsd.org Subject: snmp_atm is broken? (world does not build) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 04:30:28 -0000 Hi there, Today's world does not build, failing in snmp_atm: ===> lib/libbsnmp/modules/snmp_atm make: don't know how to make snmp_atm.h. Stop *** Error code 2 Stop in /usr/src/lib/libbsnmp/modules. *** Error code 1 Stop in /usr/src/lib/libbsnmp. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. >From src/lib/libbsnmp/modules/snmp_atm/Makefile rev. 1.1 I see: SNMP_ATM=${.CURDIR}/../../../../contrib/ngatm/snmp_atm INCS= snmp_${MOD}.h CFLAGS+= -I${SNMP_ATM} but /usr/src/contrib/ngatm/snmp_atm is missing. Can you investigate? If you are not responsible for this, please accept my apologies and ignore this letter. :) Thanks. ./danfe From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 11:41:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD81F16A5B6; Tue, 10 Aug 2004 11:41:13 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2BFA43D1D; Tue, 10 Aug 2004 11:41:12 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i7ABfCi5090899; Tue, 10 Aug 2004 07:41:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7ABfCqF033301; Tue, 10 Aug 2004 07:41:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 498417303F; Tue, 10 Aug 2004 07:41:12 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040810114112.498417303F@freebsd-current.sentex.ca> Date: Tue, 10 Aug 2004 07:41:12 -0400 (EDT) Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 11:41:13 -0000 TB --- 2004-08-10 10:46:12 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-10 10:46:12 - starting CURRENT tinderbox run for i386/pc98 TB --- 2004-08-10 10:46:12 - checking out the source tree TB --- 2004-08-10 10:46:12 - cd /home/tinderbox/sandbox/CURRENT/i386/pc98 TB --- 2004-08-10 10:46:12 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-10 10:51:59 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-10 10:51:59 - cd /home/tinderbox/sandbox/CURRENT/i386/pc98/src TB --- 2004-08-10 10:51:59 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] mkdep -f .depend -a -I. -DNS -DINET6 -DRESCUE /tinderbox/CURRENT/i386/pc98/src/sbin/route/route.c echo route: /home/tinderbox/sandbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/i386/usr/lib/libc.a >> .depend cc -O2 -pipe -I. -Wall -DNS -DINET6 -DRESCUE -c /tinderbox/CURRENT/i386/pc98/src/sbin/route/route.c (cd /tinderbox/CURRENT/i386/pc98/src/rescue/rescue/../../sbin/routed && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE if.o input.o main.o output.o parms.o radix.o rdisc.o table.o trace.o) rm -f .depend mkdep -f .depend -a -DRESCUE /tinderbox/CURRENT/i386/pc98/src/sbin/routed/if.c /tinderbox/CURRENT/i386/pc98/src/sbin/routed/input.c /tinderbox/CURRENT/i386/pc98/src/sbin/routed/main.c /tinderbox/CURRENT/i386/pc98/src/sbin/routed/output.c /tinderbox/CURRENT/i386/pc98/src/sbin/routed/parms.c /tinderbox/CURRENT/i386/pc98/src/sbin/routed/radix.c /tinderbox/CURRENT/i386/pc98/src/sbin/routed/rdisc.c /tinderbox/CURRENT/i386/pc98/src/sbin/routed/table.c /tinderbox/CURRENT/i386/pc98/src/sbin/routed/trace.c echo routed: /home/tinderbox/sandbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/i386/usr/lib/libc.a /home/tinderbox/sandbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/i386/usr/lib/libmd.a >> .depend +for: not found *** Error code 127 Stop in /tinderbox/CURRENT/i386/pc98/src/sbin/routed. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2004-08-10 11:41:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-10 11:41:12 - ERROR: failed to build world TB --- 2004-08-10 11:41:12 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 11:46:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAB0116A4CE for ; Tue, 10 Aug 2004 11:46:03 +0000 (GMT) Received: from www.bee-s.net (smtp.bee-s.net [195.128.150.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3AA143D1F for ; Tue, 10 Aug 2004 11:46:00 +0000 (GMT) (envelope-from brian@bee-s.com) Received: from inet11.beeline-samara.ru (inet11.bee [172.24.40.229]) by www.bee-s.net (8.11.3/8.11.3) with SMTP id i7ABjwm44409 for ; Tue, 10 Aug 2004 16:45:58 +0500 (SAMST) (envelope-from brian@bee-s.com) Date: Tue, 10 Aug 2004 16:45:52 +0500 From: "Andrew A. Leikand" To: current@freebsd.org Message-Id: <20040810164552.78f68ea6.brian@bee-s.com> Organization: BeeLine Samara X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Tue__10_Aug_2004_16:45:52_+0500_082228f8" Subject: 5.2-CURRENT crashes everyday X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 11:46:03 -0000 This is a multi-part message in MIME format. --Multipart_Tue__10_Aug_2004_16:45:52_+0500_082228f8 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello all well i have a real big problem it is the server with 5.2-current. Harware is IBM eServer 345 Dual Xeon with serveRAID 6i, raid controller has no support under STABLE thus i had no choice :( There are apache and sendmail on the server, load averages about 0.01, but it crashes everyday and i have no idea how to force it work. The only messages before it goes down is lock order reversal 1st 0xc6574738 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1311 2nd 0xc0673ae0 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pager.c:1797 3rd 0xc0c43a50 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:925 Stack backtrace: backtrace(0,1,c064cf90,c064e0c0,c06194dc) at backtrace+0x12 witness_checkorder(c0c43a50,9,c05fe7bf,39d) at witness_checkorder+0x53b _mtx_lock_flags(c0c43a50,0,c05fe7bf,39d,c350b288) at _mtx_lock_flags+0x57 obj_alloc(c3502dc0,1000,de086a2b,101,de086a38) at obj_alloc+0x31 slab_zalloc(c3502dc0,1,c3502dc0,c3502dc0,c350b280) at slab_zalloc+0x87 uma_zone_slab(c3502dc0,1,c350b288,0,c05fe7bf,79c) at uma_zone_slab+0xb0 uma_zalloc_internal(c3502dc0,0,1,c350b288,0) at uma_zalloc_internal+0x29 uma_zalloc_arg(c3502dc0,0,1) at uma_zalloc_arg+0x2a2 swp_pager_meta_build(c6574738,5e,0,2,0) at swp_pager_meta_build+0x108 swap_pager_putpages(c6574738,de086bf0,1,0,de086b60) at swap_pager_putpages+0x2a8 default_pager_putpages(c6574738,de086bf0,1,0,de086b60) at default_pager_putpages+0x18 vm_pageout_flush(de086bf0,1,0,c064c6e0,2ff) at vm_pageout_flush+0x112 vm_pageout_clean(c2ca1f88) at vm_pageout_clean+0x2a5 vm_pageout_scan(0,c0673fe0,0,c05fe55f,5a7) at vm_pageout_scan+0x543 vm_pageout(0,de086d48,0,c057f0e4,0) at vm_pageout+0x2cf fork_exit(c057f0e4,0,de086d48) at fork_exit+0x98 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xde086d7c, ebp = 0 --- Kernel config and dmesg are attached. Appreciate any comments or feedback on this. -- BR, Andrew --Multipart_Tue__10_Aug_2004_16:45:52_+0500_082228f8 Content-Type: text/plain; name="TUNED.txt" Content-Disposition: attachment; filename="TUNED.txt" Content-Transfer-Encoding: 7bit machine i386 cpu I686_CPU options CPU_ENABLE_SSE options MPTABLE_FORCE_HTT # Enable HTT CPUs with the MP Table ident TUNED # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options INET # InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options UNIONFS options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_LINUX # Enable Linux ABI emulation options SCSI_DELAY=15000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options QUOTA # Debugging for use in -current # options DDB # Enable the kernel debugger # options INVARIANTS # Enable calls of extra sanity checking # options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS # options WITNESS # Enable checks to detect deadlocks and cycles # options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # To make an SMP kernel, the next two are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC device isa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem device ips # IBM (Adaptec) ServeRAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. #device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port #device ppc #device ppbus # Parallel port bus (required) #device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. device em # Intel PRO/1000 adapter Gigabit Ethernet Card # Pseudo devices - the number indicates how many units to allocate. device random # Entropy device device loop # Network loopback device ether # Ethernet support #device vlan #device sl # Kernel SLIP #device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" # device pf # device pflog # device pfsync # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # options PFIL_HOOKS # pfil(9) framework options IPFILTER options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK #options IPSTEALTH options RANDOM_IP_ID options TCP_DROP_SYNFIN --Multipart_Tue__10_Aug_2004_16:45:52_+0500_082228f8 Content-Type: application/octet-stream; name="dmesg.today" Content-Disposition: attachment; filename="dmesg.today" Content-Transfer-Encoding: base64 Q29weXJpZ2h0IChjKSAxOTkyLTIwMDQgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDUuMi1DVVJSRU5UICMxMDogTW9uIEF1ZyAgOSAxMzowODoy MiBTQU1TVCAyMDA0CiAgICByb290QGphaWxlci5iZWUtcy5jb206L3Vzci9vYmovdXNyL3NyYy9z eXMvVFVORUQKQUNQSSBBUElDIFRhYmxlOiA8SUJNICAgIFNFUk9OWVhQPgpUaW1lY291bnRlciAi aTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApDUFU6IEludGVsKFIpIFhlb24o VE0pIENQVSAyLjgwR0h6ICgyNzkzLjg5LU1IeiA2ODYtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJH ZW51aW5lSW50ZWwiICBJZCA9IDB4ZjI5ICBTdGVwcGluZyA9IDkKICBGZWF0dXJlcz0weGJmZWJm YmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0Us TUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1Ms SFRULFRNLFBCRT4KICBIeXBlcnRocmVhZGluZzogMiBsb2dpY2FsIENQVXMKcmVhbCBtZW1vcnkg ID0gMjE0NzQ2MzE2OCAoMjA0NyBNQikKYXZhaWwgbWVtb3J5ID0gMjEwMDMyNjQwMCAoMjAwMyBN QikKRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogNCBDUFVzCiBj cHUwIChCU1ApOiBBUElDIElEOiAgMAogY3B1MSAoQVApOiBBUElDIElEOiAgMQogY3B1MiAoQVAp OiBBUElDIElEOiAgNgogY3B1MyAoQVApOiBBUElDIElEOiAgNwpNQURUOiBGb3JjaW5nIGFjdGl2 ZS1sb3cgcG9sYXJpdHkgYW5kIGxldmVsIHRyaWdnZXIgZm9yIFNDSQppb2FwaWMyIDxWZXJzaW9u IDEuMT4gaXJxcyAzMi00NyBvbiBtb3RoZXJib2FyZAppb2FwaWMxIDxWZXJzaW9uIDEuMT4gaXJx cyAxNi0zMSBvbiBtb3RoZXJib2FyZAppb2FwaWMwIDxWZXJzaW9uIDEuMT4gaXJxcyAwLTE1IG9u IG1vdGhlcmJvYXJkCm5weDA6IFtGQVNUXQpucHgwOiA8bWF0aCBwcm9jZXNzb3I+IG9uIG1vdGhl cmJvYXJkCm5weDA6IElOVCAxNiBpbnRlcmZhY2UKYWNwaTA6IDxJQk0gU0VST05ZWFA+IG9uIG1v dGhlcmJvYXJkCmFjcGkwOiBbR0lBTlQtTE9DS0VEXQphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhl ZCkKYWNwaV90aW1lcjA6IGNvdWxkbid0IGFsbG9jYXRlIHJlc291cmNlIChwb3J0IDB4NDg4KQpj cHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1Mjog PEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUzOiA8QUNQSSBDUFU+IG9uIGFjcGkwCnBjaWIwOiA8QUNQ SSBIb3N0LVBDSSBicmlkZ2U+IG9uIGFjcGkwCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIw CnBjaTA6IDxkaXNwbGF5LCBWR0E+IGF0IGRldmljZSA2LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkK YXRhcGNpMDogPFNlcnZlcldvcmtzIENTQjUgVURNQTEwMCBjb250cm9sbGVyPiBwb3J0IDB4NzAw LTB4NzBmLDB4Mzc2LDB4MTcwLTB4MTc3LDB4M2Y2LDB4MWYwLTB4MWY3IGF0IGRldmljZSAxNS4x IG9uIHBjaTAKYXRhMDogYXQgMHgxZjAgaXJxIDE0IG9uIGF0YXBjaTAKYXRhMTogc2ltcGxleCBk ZXZpY2UsIERNQSBvbiBwcmltYXJ5IG9ubHkKYXRhMTogYXQgMHgxNzAgaXJxIDE1IG9uIGF0YXBj aTAKcGNpMDogPHNlcmlhbCBidXMsIFVTQj4gYXQgZGV2aWNlIDE1LjIgKG5vIGRyaXZlciBhdHRh Y2hlZCkKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDE1LjMgb24gcGNpMAppc2Ew OiA8SVNBIGJ1cz4gb24gaXNhYjAKcGNpYjE6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gb24gYWNw aTAKcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKcGNpYjI6IDxBQ1BJIEhvc3QtUENJIGJy aWRnZT4gb24gYWNwaTAKcGNpNDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjIKcGNpYjM6IDxBQ1BJ IEhvc3QtUENJIGJyaWRnZT4gb24gYWNwaTAKcGNpNjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMK ZW0wOiA8SW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25uZWN0aW9uLCBWZXJzaW9uIC0gMS43 LjI1PiBwb3J0IDB4MjUwMC0weDI1M2YgbWVtIDB4ZmJmZTAwMDAtMHhmYmZmZmZmZiBpcnEgMjkg YXQgZGV2aWNlIDguMCBvbiBwY2k2CmVtMDogW0dJQU5ULUxPQ0tFRF0KZW0wOiBFdGhlcm5ldCBh ZGRyZXNzOiAwMDowOTo2Yjo4OTo3ODo4OAplbTA6ICBTcGVlZDpOL0EgIER1cGxleDpOL0EKZW0x OiA8SW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25uZWN0aW9uLCBWZXJzaW9uIC0gMS43LjI1 PiBwb3J0IDB4MjU0MC0weDI1N2YgbWVtIDB4ZmJmYzAwMDAtMHhmYmZkZmZmZiBpcnEgMzAgYXQg ZGV2aWNlIDguMSBvbiBwY2k2CmVtMTogW0dJQU5ULUxPQ0tFRF0KZW0xOiBFdGhlcm5ldCBhZGRy ZXNzOiAwMDowOTo2Yjo4OTo3ODo4OQplbTE6ICBTcGVlZDpOL0EgIER1cGxleDpOL0EKcGNpYjQ6 IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gb24gYWNwaTAKcGNpODogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjQKaXBzMDogPEFkYXB0ZWMgU2VydmVSQUlEIEFkYXB0ZXI+IG1lbSAweGY0MDAwMDAwLTB4 ZjdmZmZmZmYsMHhmM2ZmZjAwMC0weGYzZmZmZmZmIGlycSAxOCBhdCBkZXZpY2UgMi4wIG9uIHBj aTgKaXBzMDogW0dJQU5ULUxPQ0tFRF0KYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4 MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+ IGlycSAxIG9uIGF0a2JkYzAKYXRrYmQ6IHVuYWJsZSB0byBzZXQgdGhlIGNvbW1hbmQgYnl0ZS4K a2JkMCBhdCBhdGtiZDAKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQpwc20wOiB1bmFibGUgdG8gc2V0 IHRoZSBjb21tYW5kIGJ5dGUuCmZkYzA6IDxmbG9wcHkgZHJpdmUgY29udHJvbGxlcj4gcG9ydCAw eDNmMC0weDNmNSBpcnEgNiBkcnEgMiBvbiBhY3BpMApmZGMwOiBGSUZPIGVuYWJsZWQsIDggYnl0 ZXMgdGhyZXNob2xkCmZkMDogPDE0NDAtS0IgMy41IiBkcml2ZT4gb24gZmRjMCBkcml2ZSAwCmFj cGlfdGltZXIwOiBjb3VsZG4ndCBhbGxvY2F0ZSByZXNvdXJjZSAocG9ydCAweDQ4OCkKb3JtMDog PElTQSBPcHRpb24gUk9Ncz4gYXQgaW9tZW0gMHhjODAwMC0weGM5N2ZmLDB4YzAwMDAtMHhjN2Zm ZiBvbiBpc2EwCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNj MDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4Kc2lvMDogY29uZmlndXJl ZCBpcnEgNCBub3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDAKc2lvMDogcG9ydCBtYXkgbm90 IGJlIGVuYWJsZWQKc2lvMCBhdCBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24g aXNhMApzaW8wOiB0eXBlIDgyNTAgb3Igbm90IHJlc3BvbmRpbmcKc2lvMTogY29uZmlndXJlZCBp cnEgMyBub3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDAKc2lvMTogcG9ydCBtYXkgbm90IGJl IGVuYWJsZWQKdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21l bSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApUaW1lY291bnRlcnMgdGljayBldmVyeSAxMC4wMDAg bXNlYwpJUCBGaWx0ZXI6IHYzLjQuMzUgaW5pdGlhbGl6ZWQuICBEZWZhdWx0ID0gYmxvY2sgYWxs LCBMb2dnaW5nID0gZW5hYmxlZApBVEFQSV9SRVNFVCB0aW1lID0gMTQwdXMKYWNkMDogQ0RST00g PExHIENELVJPTSBDUk4tODI0NUIvMS4xNj4gYXQgYXRhMC1tYXN0ZXIgVURNQTMzCmlwczA6IHJl c2V0dGluZyBhZGFwdGVyLCB0aGlzIG1heSB0YWtlIHVwIHRvIDUgbWludXRlcwppcHMwOiBhZGFw dGVyIHR5cGU6IFNlcnZlUkFJRCA2aSAoc2VicmluZykKaXBzMDogbG9naWNhbCBkcml2ZXM6IDIK aXBzMDogTG9naWNhbCBEcml2ZSAwOiBSQUlENSBzZWN0b3JzOiAxMzUxNjgwMDAsIHN0YXRlIE9L CmlwczA6IExvZ2ljYWwgRHJpdmUgMTogUkFJRDAgc2VjdG9yczogMTA1MzY5NjAsIHN0YXRlIE9L Cmlwc2QwOiA8TG9naWNhbCBEcml2ZT4gb24gaXBzMAppcHNkMDogTG9naWNhbCBEcml2ZSAgKDY2 MDAwTUIpCmlwc2QxOiA8TG9naWNhbCBEcml2ZT4gb24gaXBzMAppcHNkMTogTG9naWNhbCBEcml2 ZSAgKDUxNDVNQikKU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMzIExhdW5j aGVkIQpTTVA6IEFQIENQVSAjMiBMYXVuY2hlZCEKTW91bnRpbmcgcm9vdCBmcm9tIHVmczovZGV2 L2lwc2QwczFhCmVtMDogTGluayBpcyB1cCAxMDAgTWJwcyBGdWxsIER1cGxleAo= --Multipart_Tue__10_Aug_2004_16:45:52_+0500_082228f8-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 12:13:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A405816A4CE for ; Tue, 10 Aug 2004 12:13:32 +0000 (GMT) Received: from mail.imp.ch (ns1.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23C4F43D48 for ; Tue, 10 Aug 2004 12:13:30 +0000 (GMT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.9p2/8.12.3) with ESMTP id i7ACDCVW024615 for ; Tue, 10 Aug 2004 14:13:14 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Tue, 10 Aug 2004 14:13:12 +0200 (CEST) From: Martin Blapp To: current@freebsd.org Message-ID: <20040810121717.X31181@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checksum: ef56150dae42a70d6fd4d78232b3acde X-Virus-Status: No, scantime="0.0260 seconds" X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=4 scantime="11.6824 seconds" tests=BAYES_00 X-Scanned-By: MIMEDefang 2.44 Subject: Current is in a very desolated state X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 12:13:32 -0000 Hi all, Even with the disabled preemtion CURRENT is in a very desolated state at the moment - and this one week before freeze. While I was able to run a server with 5.2.1 about 1 month without panicing, this is no longer true with recent current. The panics I get are in the timer codepath or sometimes in the vfs layer. It's very easy to kill the machine with high load (rm -rfd /usr/src while running a make world -j 10) kills the server. I also get this panic after 20 - 30 minutes load propagate_priority(c34e3420,0,82b45d4f,16ccf49,ffc00014) at propagate_priority+0x82 turnstile_wait(c3bd0480,c09396a0,c3aea840,c35b0680,4) at turnstile_wait+0x325 _mtx_lock_sleep(c09396a0,c34e3420,0,0,0) at _mtx_lock_sleep+0x122 ithread_loop(c3460980,de97bd48,0,0,0) at ithread_loop+0x19c fork_exit(c062a1af,c3460980,de97bd48) at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 This is an SMP box with two XEON's, running a SMP kernel with SCHEDBSD. Martin Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 12:26:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0ECD16A4CE; Tue, 10 Aug 2004 12:26:28 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B30D743D39; Tue, 10 Aug 2004 12:26:26 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7ACQHSv065673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Aug 2004 15:26:18 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7ACQJBp018479; Tue, 10 Aug 2004 15:26:19 +0300 (EEST) (envelope-from ru) Date: Tue, 10 Aug 2004 15:26:19 +0300 From: Ruslan Ermilov To: Alexey Dokuchaev Message-ID: <20040810122619.GB18408@ip.net.ua> References: <20040810043034.GA61300@regency.nsu.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TRYliJ5NKNqkz5bu" Content-Disposition: inline In-Reply-To: <20040810043034.GA61300@regency.nsu.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: harti@freebsd.org cc: current@freebsd.org Subject: Re: snmp_atm is broken? (world does not build) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 12:26:29 -0000 --TRYliJ5NKNqkz5bu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 10, 2004 at 11:30:34AM +0700, Alexey Dokuchaev wrote: > Hi there, >=20 > Today's world does not build, failing in snmp_atm: >=20 > =3D=3D=3D> lib/libbsnmp/modules/snmp_atm > make: don't know how to make snmp_atm.h. Stop > *** Error code 2 >=20 [...] > >From src/lib/libbsnmp/modules/snmp_atm/Makefile rev. 1.1 I see: >=20 > SNMP_ATM=3D${.CURDIR}/../../../../contrib/ngatm/snmp_atm > INCS=3D snmp_${MOD}.h > CFLAGS+=3D -I${SNMP_ATM} >=20 > but /usr/src/contrib/ngatm/snmp_atm is missing. Can you investigate? > If you are not responsible for this, please accept my apologies and > ignore this letter. :) >=20 How many times must it be said? If you're running/using -CURRENT, please get yourself subscribed and *read* the current@ mailing list. There have been a ton of these reports already, and the issue is being worked on. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --TRYliJ5NKNqkz5bu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGL7rqRfpzJluFF4RArQ9AJ4/QK1kMijiZ56J9fi7LNXnyOcbUgCfXY5v TP7Q3AmuLC/dEmVP2PRhaO0= =c1DJ -----END PGP SIGNATURE----- --TRYliJ5NKNqkz5bu-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 12:29:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A49916A4CE for ; Tue, 10 Aug 2004 12:29:44 +0000 (GMT) Received: from sarajevo.pacific.net.sg (sarajevo.pacific.net.sg [203.120.90.134]) by mx1.FreeBSD.org (Postfix) with SMTP id 0084F43D2F for ; Tue, 10 Aug 2004 12:29:43 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: (qmail 26971 invoked from network); 10 Aug 2004 12:29:41 -0000 Received: from unknown (HELO maxwell2.pacific.net.sg) (203.120.90.192) by sarajevo with SMTP; 10 Aug 2004 12:29:41 -0000 Received: from [192.168.0.107] ([210.24.202.160]) by maxwell2.pacific.net.sg with ESMTP <20040810122940.NECP1183.maxwell2.pacific.net.sg@[192.168.0.107]>; Tue, 10 Aug 2004 20:29:40 +0800 Message-ID: <4118BFB0.7070006@pacific.net.sg> Date: Tue, 10 Aug 2004 20:29:36 +0800 From: Erich Dollansky User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040714) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Andrew A. Leikand" References: <20040810164552.78f68ea6.brian@bee-s.com> In-Reply-To: <20040810164552.78f68ea6.brian@bee-s.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: 5.2-CURRENT crashes everyday X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 12:29:44 -0000 Hi, have you ever tried to disable HyperThreading? Erich Andrew A. Leikand wrote: > options MPTABLE_FORCE_HTT # Enable HTT CPUs with the MP Table > From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 12:35:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71AF716A4CE; Tue, 10 Aug 2004 12:35:57 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEBD743D31; Tue, 10 Aug 2004 12:35:56 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i7ACZupQ097846; Tue, 10 Aug 2004 08:35:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i7ACZtbf064254; Tue, 10 Aug 2004 08:35:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0A90A7303F; Tue, 10 Aug 2004 08:35:55 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040810123555.0A90A7303F@freebsd-current.sentex.ca> Date: Tue, 10 Aug 2004 08:35:55 -0400 (EDT) Subject: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 12:35:57 -0000 TB --- 2004-08-10 11:41:12 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-10 11:41:12 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2004-08-10 11:41:12 - cleaning the sandbox TB --- 2004-08-10 11:42:13 - checking out the source tree TB --- 2004-08-10 11:42:13 - cd /home/tinderbox/sandbox/CURRENT/ia64/ia64 TB --- 2004-08-10 11:42:13 - /usr/bin/cvs -f -R -Q -d/home/ncvs checkout -P -A src TB --- 2004-08-10 11:49:57 - WARNING: /home/tinderbox/sandbox/ia64.diff does not exist TB --- 2004-08-10 11:49:57 - building world (CFLAGS=-O -pipe) TB --- 2004-08-10 11:49:57 - cd /home/tinderbox/sandbox/CURRENT/ia64/ia64/src TB --- 2004-08-10 11:49:57 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] mkdep -f .depend -a -I. -DNS -DINET6 -DRESCUE /tinderbox/CURRENT/ia64/ia64/src/sbin/route/route.c echo route: /home/tinderbox/sandbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/i386/usr/lib/libc.a >> .depend cc -O -pipe -I. -Wall -DNS -DINET6 -DRESCUE -c /tinderbox/CURRENT/ia64/ia64/src/sbin/route/route.c (cd /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue/../../sbin/routed && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE if.o input.o main.o output.o parms.o radix.o rdisc.o table.o trace.o) rm -f .depend mkdep -f .depend -a -DRESCUE /tinderbox/CURRENT/ia64/ia64/src/sbin/routed/if.c /tinderbox/CURRENT/ia64/ia64/src/sbin/routed/input.c /tinderbox/CURRENT/ia64/ia64/src/sbin/routed/main.c /tinderbox/CURRENT/ia64/ia64/src/sbin/routed/output.c /tinderbox/CURRENT/ia64/ia64/src/sbin/routed/parms.c /tinderbox/CURRENT/ia64/ia64/src/sbin/routed/radix.c /tinderbox/CURRENT/ia64/ia64/src/sbin/routed/rdisc.c /tinderbox/CURRENT/ia64/ia64/src/sbin/routed/table.c /tinderbox/CURRENT/ia64/ia64/src/sbin/routed/trace.c echo routed: /home/tinderbox/sandbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/i386/usr/lib/libc.a /home/tinderbox/sandbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/i386/usr/lib/libmd.a >> .depend +for: not found *** Error code 127 Stop in /tinderbox/CURRENT/ia64/ia64/src/sbin/routed. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2004-08-10 12:35:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-10 12:35:55 - ERROR: failed to build world TB --- 2004-08-10 12:35:55 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 12:50:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D8DD16A4CE for ; Tue, 10 Aug 2004 12:50:15 +0000 (GMT) Received: from mail.imp.ch (ns1.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B4D543D5E for ; Tue, 10 Aug 2004 12:50:14 +0000 (GMT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.9p2/8.12.3) with ESMTP id i7ACo7CZ035050 for ; Tue, 10 Aug 2004 14:50:08 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Tue, 10 Aug 2004 14:50:07 +0200 (CEST) From: Martin Blapp To: current@freebsd.org In-Reply-To: <20040810121717.X31181@cvs.imp.ch> Message-ID: <20040810144940.M31181@cvs.imp.ch> References: <20040810121717.X31181@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checksum: 683de6fd8476abed484546412eea897b X-Virus-Message-Status: No X-Virus-Status: No, scantime="0.0062 seconds" X-Spam-Status: No, hits=0.001 required=5 scantime="2.5864 seconds" tests=BAYES_50 X-Scanned-By: MIMEDefang 2.44 Subject: Re: Current is in a very desolated state X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 12:50:15 -0000 Hi, > While I was able to run a server with 5.2.1 about 1 month without panicing, > this is no longer true with recent current. This is the last version which was more or less stable: FreeBSD 5.2-CURRENT #11: Mon May 10 13:57:01 CEST 2004 Martin From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 13:02:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F5F216A4CE for ; Tue, 10 Aug 2004 13:02:27 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7AB643D54 for ; Tue, 10 Aug 2004 13:02:26 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by mproxy.gmail.com with SMTP id 75so134791rnl for ; Tue, 10 Aug 2004 06:02:23 -0700 (PDT) Received: by 10.38.86.74 with SMTP id j74mr1098422rnb; Tue, 10 Aug 2004 06:02:23 -0700 (PDT) Message-ID: Date: Tue, 10 Aug 2004 21:02:22 +0800 From: Jiawei Ye To: John-Mark Gurney In-Reply-To: <20040810060405.GM991@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200408092003.28922.max@love2party.net> <20040809222127.GU64690@camelot.theinternet.com.au> <20040809225255.GI991@funkthat.com> <20040810044257.GJ991@funkthat.com> <20040810060405.GM991@funkthat.com> cc: freebsd-current@freebsd.org Subject: Re: kldload pf failed on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 13:02:27 -0000 On Mon, 9 Aug 2004 23:04:05 -0700, John-Mark Gurney wrote: > hmmm... now I'm really puzzled... there is code in support.4th that > adds in the current boot directory to the module path... could you > break out to the loader prompt, and see what show module_path returns? > > mine: > OK show module_path > /boot/kernel;/boot/modules > > -- > John-Mark Gurney Voice: +1 415 225 5579 module_path is /boot/modules only, no /boot/kernel. Also, acpi.ko isn't loaded either. Jiawei From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 13:03:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8306416A4CE; Tue, 10 Aug 2004 13:03:57 +0000 (GMT) Received: from smtp.lcn.biz (smtp.lcn.biz [195.82.107.155]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBCBC43D41; Tue, 10 Aug 2004 13:03:56 +0000 (GMT) (envelope-from simond@irrelevant.org) Received: from telivo.cust.hastwood.com ([62.244.179.195] helo=[192.168.195.5]) by smtp.lcn.biz with asmtp (Exim 4.30; FreeBSD) id 1BuWIF-000K1G-Dc; Tue, 10 Aug 2004 14:03:55 +0100 From: Simon Dick To: Mike Bristow In-Reply-To: <20040810070603.GA27291@urgle.com> References: <1092044482.20927.35.camel@singsing.eng.demon.net> <20040810070603.GA27291@urgle.com> Content-Type: text/plain Message-Id: <1092143030.54231.0.camel@simon.lcn.biz> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 10 Aug 2004 14:03:51 +0100 Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: Robert Watson Subject: Re: panic: mutex vr0 not owned at ...if_vr.c:571 when doing ifconfig X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 13:03:57 -0000 On Tue, 2004-08-10 at 08:06, Mike Bristow wrote: > On Mon, Aug 09, 2004 at 06:41:43PM -0400, Robert Watson wrote: > > Hmm. I actually committed a slightly different patch as if_vr.c:1.93 to > > acquire the lock around vr_setcfg() in vr_miibus_statchg(). Could you > > check that that also solves the problem? > > When I tried that, it booted but paniced as soon as I ran 'ifconfig > vr0 media blah': > > > # ifconfig vr0 media 100baseTX > panic: _mtx_lock_sleep: recursed on non-recursive mutex vr0 @ > +/usr/src/sys/pci/if_vr.c:506 Same here with 1.93 installed, currently backed out to 1.92 so I can use my network From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 13:23:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD77916A4CE; Tue, 10 Aug 2004 13:23:42 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0632143D2F; Tue, 10 Aug 2004 13:23:39 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smtp3.sentex.ca (8.12.11/8.12.11) with ESMTP id i7ADNaV1092797; Tue, 10 Aug 2004 09:23:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i7ADNcIZ089505; Tue, 10 Aug 2004 09:23:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3D2217303F; Tue, 10 Aug 2004 09:23:38 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040810132338.3D2217303F@freebsd-current.sentex.ca> Date: Tue, 10 Aug 2004 09:23:38 -0400 (EDT) Subject: [current tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 13:23:43 -0000 TB --- 2004-08-10 12:35:56 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-10 12:35:56 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2004-08-10 12:35:56 - cleaning the sandbox TB --- 2004-08-10 12:36:58 - checking out the source tree TB --- 2004-08-10 12:36:58 - cd /home/tinderbox/sandbox/CURRENT/powerpc/powerpc TB --- 2004-08-10 12:36:58 - /usr/bin/cvs -f -R -Q -d/home/ncvs checkout -P -A src TB --- 2004-08-10 12:45:07 - patching the sources TB --- 2004-08-10 12:45:07 - cd /home/tinderbox/sandbox/CURRENT/powerpc/powerpc/src TB --- 2004-08-10 12:45:07 - /usr/bin/patch -f -s -i/home/tinderbox/sandbox/powerpc.diff TB --- 2004-08-10 12:45:07 - building world (CFLAGS=-O -pipe) TB --- 2004-08-10 12:45:07 - cd /home/tinderbox/sandbox/CURRENT/powerpc/powerpc/src TB --- 2004-08-10 12:45:07 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] mkdep -f .depend -a -I. -DNS -DINET6 -DRESCUE /tinderbox/CURRENT/powerpc/powerpc/src/sbin/route/route.c echo route: /home/tinderbox/sandbox/CURRENT/powerpc/powerpc/obj/powerpc/tinderbox/CURRENT/powerpc/powerpc/src/i386/usr/lib/libc.a >> .depend cc -O -pipe -I. -Wall -DNS -DINET6 -DRESCUE -c /tinderbox/CURRENT/powerpc/powerpc/src/sbin/route/route.c (cd /tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue/../../sbin/routed && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE if.o input.o main.o output.o parms.o radix.o rdisc.o table.o trace.o) rm -f .depend mkdep -f .depend -a -DRESCUE /tinderbox/CURRENT/powerpc/powerpc/src/sbin/routed/if.c /tinderbox/CURRENT/powerpc/powerpc/src/sbin/routed/input.c /tinderbox/CURRENT/powerpc/powerpc/src/sbin/routed/main.c /tinderbox/CURRENT/powerpc/powerpc/src/sbin/routed/output.c /tinderbox/CURRENT/powerpc/powerpc/src/sbin/routed/parms.c /tinderbox/CURRENT/powerpc/powerpc/src/sbin/routed/radix.c /tinderbox/CURRENT/powerpc/powerpc/src/sbin/routed/rdisc.c /tinderbox/CURRENT/powerpc/powerpc/src/sbin/routed/table.c /tinderbox/CURRENT/powerpc/powerpc/src/sbin/routed/trace.c echo routed: /home/tinderbox/sandbox/CURRENT/powerpc/powerpc/obj/powerpc/tinderbox/CURRENT/powerpc/powerpc/src/i386/usr/lib/libc.a /home/tinderbox/sandbox/CURRENT/powerpc/powerpc/obj/powerpc/tinderbox/CURRENT/powerpc/powerpc/src/i386/usr/lib/libmd.a >> .depend +for: not found *** Error code 127 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/sbin/routed. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2004-08-10 13:23:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-10 13:23:38 - ERROR: failed to build world TB --- 2004-08-10 13:23:38 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 13:35:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 469D116A4CE for ; Tue, 10 Aug 2004 13:35:59 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B448343D49 for ; Tue, 10 Aug 2004 13:35:58 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.201] ([192.168.0.201]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i7ADZWNI027368; Tue, 10 Aug 2004 07:35:33 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4118CEAE.2050100@samsco.org> Date: Tue, 10 Aug 2004 07:33:34 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Andrew A. Leikand" References: <20040810164552.78f68ea6.brian@bee-s.com> In-Reply-To: <20040810164552.78f68ea6.brian@bee-s.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: current@freebsd.org Subject: Re: 5.2-CURRENT crashes everyday X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 13:35:59 -0000 Hi, I'm pretty sure that this is a known, harmless bug. It might even have been fixed in the last few weeks, but I can't remember for sure. You can avoid the panics by removing INVARIANTS from your kernel config. Scott Andrew A. Leikand wrote: > Hello all > > well i have a real big problem it is the server with 5.2-current. > Harware is IBM eServer 345 Dual Xeon with serveRAID 6i, raid controller > has no support under STABLE thus i had no choice :( > There are apache and sendmail on the server, load averages about 0.01, > but it crashes everyday and i have no idea how to force it work. > The only messages before it goes down is > > lock order reversal > 1st 0xc6574738 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1311 > 2nd 0xc0673ae0 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pager.c:1797 > 3rd 0xc0c43a50 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:925 > Stack backtrace: > backtrace(0,1,c064cf90,c064e0c0,c06194dc) at backtrace+0x12 > witness_checkorder(c0c43a50,9,c05fe7bf,39d) at witness_checkorder+0x53b > _mtx_lock_flags(c0c43a50,0,c05fe7bf,39d,c350b288) at _mtx_lock_flags+0x57 > obj_alloc(c3502dc0,1000,de086a2b,101,de086a38) at obj_alloc+0x31 > slab_zalloc(c3502dc0,1,c3502dc0,c3502dc0,c350b280) at slab_zalloc+0x87 > uma_zone_slab(c3502dc0,1,c350b288,0,c05fe7bf,79c) at uma_zone_slab+0xb0 > uma_zalloc_internal(c3502dc0,0,1,c350b288,0) at uma_zalloc_internal+0x29 > uma_zalloc_arg(c3502dc0,0,1) at uma_zalloc_arg+0x2a2 > swp_pager_meta_build(c6574738,5e,0,2,0) at swp_pager_meta_build+0x108 > swap_pager_putpages(c6574738,de086bf0,1,0,de086b60) at swap_pager_putpages+0x2a8 > default_pager_putpages(c6574738,de086bf0,1,0,de086b60) at default_pager_putpages+0x18 > vm_pageout_flush(de086bf0,1,0,c064c6e0,2ff) at vm_pageout_flush+0x112 > vm_pageout_clean(c2ca1f88) at vm_pageout_clean+0x2a5 > vm_pageout_scan(0,c0673fe0,0,c05fe55f,5a7) at vm_pageout_scan+0x543 > vm_pageout(0,de086d48,0,c057f0e4,0) at vm_pageout+0x2cf > fork_exit(c057f0e4,0,de086d48) at fork_exit+0x98 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xde086d7c, ebp = 0 --- > > Kernel config and dmesg are attached. > > Appreciate any comments or feedback on this. > > -- > BR, Andrew > > > ------------------------------------------------------------------------ > > machine i386 > cpu I686_CPU > options CPU_ENABLE_SSE > options MPTABLE_FORCE_HTT # Enable HTT CPUs with the MP Table > > ident TUNED > > # To statically compile in device wiring instead of /boot/device.hints > #hints "GENERIC.hints" # Default places to look for devices. > > #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols > > options SCHED_ULE # ULE scheduler > options INET # InterNETworking > options FFS # Berkeley Fast Filesystem > options SOFTUPDATES # Enable FFS soft updates support > options UFS_ACL # Support for access control lists > options UFS_DIRHASH # Improve performance on big directories > options MD_ROOT # MD is a potential root device > options MSDOSFS # MSDOS Filesystem > options CD9660 # ISO 9660 Filesystem > options PROCFS # Process filesystem (requires PSEUDOFS) > options PSEUDOFS # Pseudo-filesystem framework > options UNIONFS > options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > options COMPAT_LINUX # Enable Linux ABI emulation > > options SCSI_DELAY=15000 # Delay (in ms) before probing SCSI > options KTRACE # ktrace(1) support > options SYSVSHM # SYSV-style shared memory > options SYSVMSG # SYSV-style message queues > options SYSVSEM # SYSV-style semaphores > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > options QUOTA > > > # Debugging for use in -current > # options DDB # Enable the kernel debugger > # options INVARIANTS # Enable calls of extra sanity checking > # options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS > # options WITNESS # Enable checks to detect deadlocks and cycles > # options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed > > # To make an SMP kernel, the next two are needed > options SMP # Symmetric MultiProcessor Kernel > device apic # I/O APIC > > device isa > device pci > > # Floppy drives > device fdc > > # ATA and ATAPI devices > device ata > device atadisk # ATA disk drives > device atapicd # ATAPI CDROM drives > options ATA_STATIC_ID # Static device numbering > > # SCSI peripherals > device scbus # SCSI bus (required for SCSI) > device ch # SCSI media changers > device da # Direct Access (disks) > device sa # Sequential Access (tape etc) > device cd # CD > device pass # Passthrough device (direct SCSI access) > device ses # SCSI Environmental Services (and SAF-TE) > > # RAID controllers interfaced to the SCSI subsystem > device ips # IBM (Adaptec) ServeRAID > > > # atkbdc0 controls both the keyboard and the PS/2 mouse > device atkbdc # AT keyboard controller > device atkbd # AT keyboard > device psm # PS/2 mouse > > device vga # VGA video card driver > > device splash # Splash screen and screen saver support > > # syscons is the default console driver, resembling an SCO console > device sc > > device agp # support several AGP chipsets > > # Floating point support - do not disable. > device npx > > # Power management support (see NOTES for more options) > #device apm > # Add suspend/resume support for the i8254. > #device pmtimer > > # Serial (COM) ports > device sio # 8250, 16[45]50 based serial ports > > # Parallel port > #device ppc > #device ppbus # Parallel port bus (required) > #device lpt # Printer > #device plip # TCP/IP over parallel > #device ppi # Parallel port interface device > #device vpo # Requires scbus and da > > # If you've got a "dumb" serial or parallel PCI card that is > # supported by the puc(4) glue driver, uncomment the following > # line to enable it (connects to the sio and/or ppc drivers): > #device puc > > # PCI Ethernet NICs. > device em # Intel PRO/1000 adapter Gigabit Ethernet Card > > # Pseudo devices - the number indicates how many units to allocate. > device random # Entropy device > device loop # Network loopback > device ether # Ethernet support > #device vlan > #device sl # Kernel SLIP > #device ppp # Kernel PPP > device tun # Packet tunnel. > device pty # Pseudo-ttys (telnet etc) > device md # Memory "disks" > # device pf > # device pflog > # device pfsync > > > # The `bpf' device enables the Berkeley Packet Filter. > # Be aware of the administrative consequences of enabling this! > device bpf # Berkeley packet filter > > # > options PFIL_HOOKS # pfil(9) framework > options IPFILTER > options IPFILTER_LOG > options IPFILTER_DEFAULT_BLOCK > #options IPSTEALTH > options RANDOM_IP_ID > options TCP_DROP_SYNFIN > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Aug 10 13:44:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9BDC16A4CE for ; Tue, 10 Aug 2004 13:44:39 +0000 (GMT) Received: from ioskeha.hittite.isp.9tel.net (ioskeha.hittite.isp.9tel.net [62.62.156.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F76043D48 for ; Tue, 10 Aug 2004 13:44:39 +0000 (GMT) (envelope-from martin.mato@wanadoo.fr) Received: from [192.168.0.2] (unknown [84.97.210.201]) by ioskeha.hittite.isp.9tel.net (Postfix) with ESMTP id 1C13514B707 for ; Tue, 10 Aug 2004 15:54:16 +0200 (CEST) Message-ID: <4118D144.2030401@wanadoo.fr> Date: Tue, 10 Aug 2004 15:44:36 +0200 From: Martin MATO User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: fr, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <41183662.4010802@wanadoo.fr> <20040810050907.GL991@funkthat.com> <41185F7F.8070906@wanadoo.fr> In-Reply-To: <41185F7F.8070906@wanadoo.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: ACPI autoload failed: no such file or directory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: martin.mato@wanadoo.fr List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 13:44:39 -0000 Martin MATO a écrit : > John-Mark Gurney a écrit : > >> Martin MATO wrote this message on Tue, Aug 10, 2004 at 04:43 +0200: >> >> >>> anyone could explain this.. strange thing? >>> >> >> >> Someone else is seeing this w/ pf... >> >> Do you have any lines modifing module_path in your loader.conf? Also, >> do you have an upto date support.4th? >> >> >> > i haven't any lines modifying module_path ( Andrew Milton has mailed > me about adding module_path="/boot/kernel /boot/modules" to > /boot/loader.conf, should fix it; but has no effects.) > and i have an up to date support.4th , compiled at the same time as > the kernel files. > > booting whith the GENERIC kernel has same behaviour, but with other > errors messages; not in relation whith acpi; but debug support (!) > i'll try compiling one whitout any OPTFLAGS and CFLAGS optimization, > to see... (i use -O2 -pipe) > > but i doubt it is in relation with the kldload behaviour... > > ps: sorry for my bad english, i'm french... > _______________________________________________ > 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" > Well, with a GENERIC kernel first, and a new world compiled without the -O2 flag, i obtaint the same problem. both with acpi autoload AND kldload error.. i'm out of ideas... :P From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 14:07:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2470A16A4CE for ; Tue, 10 Aug 2004 14:07:08 +0000 (GMT) Received: from mediamonks.com (siripandita.mediamonks.net [62.192.127.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DB2A43D58 for ; Tue, 10 Aug 2004 14:07:06 +0000 (GMT) (envelope-from root@mediamonks.net) Received: from manrikigusari [217.19.28.156] by mediamonks.com with ESMTP (SMTPD32-8.12) id A681C900082; Tue, 10 Aug 2004 16:06:57 +0200 From: "Terrence Koeman" To: "'Doug White'" Date: Tue, 10 Aug 2004 16:06:49 +0200 Organization: MediaMonks B.V. MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20040809183302.X80973@carver.gumbysoft.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_008E_01C47EF4.0ACF6320" Thread-Index: AcR+eitAqEpjhD0/Rw+rV3n9bl/PRwAZ8vQg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <200408101606842.SM01804@manrikigusari> X-Info: This e-mail was scanned for spam and viruses by mail.mediamonks.net. X-Info: Please send abuse reports about this e-mail to abuse@mediamonks.net. cc: freebsd-current@freebsd.org Subject: RE: Compiler segmentation fault in 5-08 -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: root@mediamonks.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 14:07:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_008E_01C47EF4.0ACF6320 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-freebsd-current@freebsd.org > [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Doug White > Sent: Tuesday, August 10, 2004 03:34 > To: Terrence Koeman > Cc: freebsd-current@freebsd.org > Subject: Re: Compiler segmentation fault in 5-08 -CURRENT > > On Mon, 9 Aug 2004, Terrence Koeman wrote: > > I recently upgraded world and kernel to the 5 august > > -CURRENT, and now > > nearly anything that requires a compiler fails. > > Can you compile a simple "hello world" program? Sometimes > these types of > faults can be caused by faulty memory, processor, overclocking, or > temperature issues. It doesn't seem hardware related. Before the update I had no problems with segmentation faults, and the system can take heavy load just fine. I tried to compile the following hello world program: #include int main() { printf("Hello World\n"); return 0; } The result is: terrence@dhammapada.mediamonks.net:~$ cc -o helloworld helloworld.c helloworld.c: In function `main': helloworld.c:4: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Is there perhaps a way to copy over the compiler from a working (older) -CURRENT system and build a new world with it to see if it's fixed in cvs? -- Regards, Terrence Koeman MediaMonks B.V. (www.mediamonks.com) Please quote all replies in correspondence. ------=_NextPart_000_008E_01C47EF4.0ACF6320 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKUzCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNmMIICz6ADAgECAhANi0/uqtIYW/R1ap0p4X/7MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4G0MIGxMBEGCWCGSAGG+EIBAQQEAwIB BjA1BgNVHR8ELjAsMCqgKKAmhiRodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLjEuMS5jcmww RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB AgUAA4GBAEJ8Dt+MeUysvwjsTVUvUImgxV5OLl6VMpt5rWURCxxKUsTVqDEhjt4Qm2wIxQfmA7nn yDR4CQnyvAZC+FqMg9GK3qoi9dnjIdLPZYwGM7DNILIzzQq9PuGdwTWpZLCnpSRb6fFo6xPEfDf0 lGQNmsW9MxfvgzOgPuWqPq7Ycx+tMIIEpDCCBA2gAwIBAgIQZx6EJ4oHSmQocGtEpogzPzANBgkq hkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wNDAyMDQw MDAwMDBaFw0wNTAyMDMyMzU5NTlaMIIBFjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0 IEZ1bGwgU2VydmljZTEYMBYGA1UEAxQPVGVycmVuY2UgS29lbWFuMSIwIAYJKoZIhvcNAQkBFhNy b290QG1lZGlhbW9ua3MubmV0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKUqZ0P8RUaCCe aemq1V8OtPimM3jxXZY6yuWtQz74POz82LhrkctttQoqujz5SubFWsQ15KsVnK4Nt+gTmtUELQVa I4uUebypbChhf1fxFerA7Rx8SYL4Ez9Fvco0tn89FRht6C/xoc/Ms/1YkQQcfnu2sqohx53S5Pm0 Ffo/ZQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcC AjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVm ZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDAGCmCG SAGG+EUBBgcEIhYgMWE5NjkyOTM3Y2MyOTFhMzZkZjAxN2Q4NDBjNDRiMTYwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOB gQAmpan0cUGODHHRIbkVFBHbTOumbMmEO3TR6d9z3LVO9cU5YDC/8BI9e5DZ7Kv43p/ldaGVo2ua ZwtvwL6o/iDcP8UDw+WmjSwzp6tck5cVRDEi+q9nCe3JAYBeRgSJlP5JGOirFpLuDTwL4UPdE0em p9ELBC+sXACm2C3u19hlKTGCBD4wggQ6AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3Qg VmFsaWRhdGVkAhBnHoQnigdKZChwa0SmiDM/MAkGBSsOAwIaBQCgggKyMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDgxMDE0MDY0OVowIwYJKoZIhvcNAQkEMRYE FKyCDFwbVcJBU3cX2ogFXa5kKq/gMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIa MAoGCCqGSIb3DQIFMIHyBgkrBgEEAYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNp Z24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5v dCBWYWxpZGF0ZWQCEGcehCeKB0pkKHBrRKaIMz8wgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBnHoQnigdKZChwa0SmiDM/MA0GCSqGSIb3 DQEBAQUABIGAjqRPvRcgxSsuiek0rxpkbcKbwa/QLJ9RYATgmtCm8BK3aFO+AFwDEm46sCKpTwwx 2DcAtffeHlzu/313o7Vk9gUlGu3+D0JUGgye1YNW1LWk7CpF6GJuJg7Yf/C6w/Y6fpBkPK8gfQMs x6cB5kD8uOJETfpOroPcRpwA7H1+IL8AAAAAAAA= ------=_NextPart_000_008E_01C47EF4.0ACF6320-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 14:08:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4083816A4CE; Tue, 10 Aug 2004 14:08:19 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3B5B43D1D; Tue, 10 Aug 2004 14:08:18 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i7AE8It7010205; Tue, 10 Aug 2004 10:08:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7AE8HrE021668; Tue, 10 Aug 2004 10:08:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2D6B07303F; Tue, 10 Aug 2004 10:08:17 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040810140817.2D6B07303F@freebsd-current.sentex.ca> Date: Tue, 10 Aug 2004 10:08:17 -0400 (EDT) Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 14:08:19 -0000 TB --- 2004-08-10 13:23:38 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-10 13:23:38 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-08-10 13:23:38 - cleaning the sandbox TB --- 2004-08-10 13:24:26 - checking out the source tree TB --- 2004-08-10 13:24:26 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64 TB --- 2004-08-10 13:24:26 - /usr/bin/cvs -f -R -Q -d/home/ncvs checkout -P -A src TB --- 2004-08-10 13:31:44 - WARNING: /home/tinderbox/sandbox/sparc64.diff does not exist TB --- 2004-08-10 13:31:44 - building world (CFLAGS=-O -pipe) TB --- 2004-08-10 13:31:44 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src TB --- 2004-08-10 13:31:44 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] mkdep -f .depend -a -I. -DNS -DINET6 -DRESCUE /tinderbox/CURRENT/sparc64/sparc64/src/sbin/route/route.c echo route: /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libc.a >> .depend cc -O -pipe -I. -Wall -DNS -DINET6 -DRESCUE -c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/route/route.c (cd /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue/../../sbin/routed && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE if.o input.o main.o output.o parms.o radix.o rdisc.o table.o trace.o) rm -f .depend mkdep -f .depend -a -DRESCUE /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/if.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/input.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/main.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/output.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/parms.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/radix.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/rdisc.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/table.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/trace.c echo routed: /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libc.a /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libmd.a >> .depend +for: not found *** Error code 127 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-08-10 14:08:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-10 14:08:16 - ERROR: failed to build world TB --- 2004-08-10 14:08:16 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 14:16:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BCE416A4CE; Tue, 10 Aug 2004 14:16:46 +0000 (GMT) Received: from home.irrelevant.org (dsl-217-155-238-245.zen.co.uk [217.155.238.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A20543D2D; Tue, 10 Aug 2004 14:16:45 +0000 (GMT) (envelope-from simond@irrelevant.org) Received: from telivo.cust.hastwood.com ([62.244.179.195] helo=[192.168.195.53]) by home.irrelevant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.30; FreeBSD) id 1BuXQg-000Ii2-Ny; Tue, 10 Aug 2004 15:16:42 +0100 From: Simon Dick To: Mike Bristow In-Reply-To: <1092143030.54231.0.camel@simon.lcn.biz> References: <1092044482.20927.35.camel@singsing.eng.demon.net> <1092143030.54231.0.camel@simon.lcn.biz> Content-Type: text/plain Message-Id: <1092147286.632.0.camel@laptop.irrelevant.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 10 Aug 2004 15:14:46 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.6 (----) X-Spam-Report: Content analysis details: (-4.6 points, 5.0 required) pts rule name description --------------------------------------------------1% [score: 0.0000] 0.3 AWL AWL: Auto-whitelist adjustment cc: freebsd-current@freebsd.org cc: Robert Watson Subject: Re: panic: mutex vr0 not owned at ...if_vr.c:571 when doing ifconfig X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 14:16:46 -0000 On Tue, 2004-08-10 at 14:03, Simon Dick wrote: > On Tue, 2004-08-10 at 08:06, Mike Bristow wrote: > > On Mon, Aug 09, 2004 at 06:41:43PM -0400, Robert Watson wrote: > > > Hmm. I actually committed a slightly different patch as if_vr.c:1.93 to > > > acquire the lock around vr_setcfg() in vr_miibus_statchg(). Could you > > > check that that also solves the problem? > > > > When I tried that, it booted but paniced as soon as I ran 'ifconfig > > vr0 media blah': > > > > > > # ifconfig vr0 media 100baseTX > > panic: _mtx_lock_sleep: recursed on non-recursive mutex vr0 @ > > +/usr/src/sys/pci/if_vr.c:506 > > Same here with 1.93 installed, currently backed out to 1.92 so I can use > my network Just tried the patch in PR 70189 and it works fine for me From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 14:26:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FA1916A4CE for ; Tue, 10 Aug 2004 14:26:54 +0000 (GMT) Received: from encontacto.net (dsl-200-95-35-213.prod-infinitum.com.mx [200.95.35.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66D4C43D5F for ; Tue, 10 Aug 2004 14:26:53 +0000 (GMT) (envelope-from eculp@encontacto.net) Received: from localhost (localhost [127.0.0.1]) (uid 80) by encontacto.net with local; Tue, 10 Aug 2004 09:32:18 -0500 Received: from dsl-200-78-18-127.prod-infinitum.com.mx (dsl-200-78-18-127.prod-infinitum.com.mx [200.78.18.127]) by mail.encontacto.net (Horde) with HTTP for ; Tue, 10 Aug 2004 09:32:18 -0500 Message-ID: <20040810093218.gck4kwcwsckocko8@mail.encontacto.net> Date: Tue, 10 Aug 2004 09:32:18 -0500 From: Edwin Culp To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 200.78.18.127 Subject: Problem with sound in latest current o athlon w/VIA, kde, KsCD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 14:26:54 -0000 I've installed the latest kde3 on 5 Athlon's with via chipset (all en one memory shared thingy) and even though they are cheapies, everything works well except for an issue with KsCD. It shows that it is playing the cd but no sound. I fire up xmms w/cdread and it works out of the box and with sound :). KaudioCreator seems to rip fine and the mp3's and/or waves work fine. The part that I have a hard time with and the reason I'm sending this to current rather than questions is that I have the idea that the problem may lie with the via chipset and may not be a problem in stable or even other versions of current. Any ideas would be appreciated. Thanks, ed P.S. Version info. CPU: AMD Athlon(tm) (1333.40-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x644 Stepping = 4 Features=0x183fbff AMD Features=0xc0440000 # uname -a 5.2-CURRENT FreeBSD 5.2-CURRENT #0: Sun Aug 8 05:54:46 CDT 2004 root@plazamagnolia.com:/usr/obj/usr/src/sys/ENCONTACTO i386 versions of kde kde-3.2.3 kdegames-3.2.3 kdesdk-3.2.3 kdeaccessibility-3.2.3 kdegraphics-3.2.3 kdetoys-3.2.3 kdeadmin-3.2.3 kdelibs-3.2.3_1 kdeutils-3.2.3 kdeartwork-3.2.3 kdemultimedia-3.2.3 kdevelop-3.0.4 kdebase-3.2.3 kdenetwork-3.2.3_1 koffice-1.3.1,1 kdeedu-3.2.3 kdepim-3.2.3 From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 14:29:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5F2116A4CE; Tue, 10 Aug 2004 14:29:01 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C86943D1F; Tue, 10 Aug 2004 14:29:01 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.201] ([192.168.0.201]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i7AESeJ7027523; Tue, 10 Aug 2004 08:28:40 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4118DB22.8060202@samsco.org> Date: Tue, 10 Aug 2004 08:26:42 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Dick References: <1092044482.20927.35.camel@singsing.eng.demon.net> <1092143030.54231.0.camel@simon.lcn.biz> <1092147286.632.0.camel@laptop.irrelevant.org> In-Reply-To: <1092147286.632.0.camel@laptop.irrelevant.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-current@freebsd.org cc: Robert Watson Subject: Re: panic: mutex vr0 not owned at ...if_vr.c:571 when doing ifconfig X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 14:29:01 -0000 Simon Dick wrote: > On Tue, 2004-08-10 at 14:03, Simon Dick wrote: > >>On Tue, 2004-08-10 at 08:06, Mike Bristow wrote: >> >>>On Mon, Aug 09, 2004 at 06:41:43PM -0400, Robert Watson wrote: >>> >>>>Hmm. I actually committed a slightly different patch as if_vr.c:1.93 to >>>>acquire the lock around vr_setcfg() in vr_miibus_statchg(). Could you >>>>check that that also solves the problem? >>> >>>When I tried that, it booted but paniced as soon as I ran 'ifconfig >>>vr0 media blah': >>> >>> >>># ifconfig vr0 media 100baseTX >>>panic: _mtx_lock_sleep: recursed on non-recursive mutex vr0 @ >>>+/usr/src/sys/pci/if_vr.c:506 >> >>Same here with 1.93 installed, currently backed out to 1.92 so I can use >>my network > > > Just tried the patch in PR 70189 and it works fine for me > So backing out rev 1.93 _and_ applying the patch in the PR makes everything work? If so then I'll look into this today. Scott From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 14:34:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7D1816A4CE; Tue, 10 Aug 2004 14:34:54 +0000 (GMT) Received: from home.irrelevant.org (dsl-217-155-238-245.zen.co.uk [217.155.238.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F18943D1D; Tue, 10 Aug 2004 14:34:54 +0000 (GMT) (envelope-from simond@irrelevant.org) Received: from telivo.cust.hastwood.com ([62.244.179.195] helo=[192.168.195.53]) by home.irrelevant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.30; FreeBSD) id 1BuXiC-000IkS-Q9; Tue, 10 Aug 2004 15:34:48 +0100 From: Simon Dick To: Scott Long In-Reply-To: <4118DB22.8060202@samsco.org> References: <1092044482.20927.35.camel@singsing.eng.demon.net> <1092143030.54231.0.camel@simon.lcn.biz> <1092147286.632.0.camel@laptop.irrelevant.org> <4118DB22.8060202@samsco.org> Content-Type: text/plain Message-Id: <1092148372.632.4.camel@laptop.irrelevant.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 10 Aug 2004 15:32:52 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.6 (----) X-Spam-Report: Content analysis details: (-4.6 points, 5.0 required) pts rule name description --------------------------------------------------1% [score: 0.0000] 0.3 AWL AWL: Auto-whitelist adjustment cc: freebsd-current@freebsd.org cc: Robert Watson Subject: Re: panic: mutex vr0 not owned at ...if_vr.c:571 when doing ifconfig X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 14:34:55 -0000 On Tue, 2004-08-10 at 15:26, Scott Long wrote: > Simon Dick wrote: > > On Tue, 2004-08-10 at 14:03, Simon Dick wrote: > > > >>On Tue, 2004-08-10 at 08:06, Mike Bristow wrote: > >> > >>>On Mon, Aug 09, 2004 at 06:41:43PM -0400, Robert Watson wrote: > >>> > >>>>Hmm. I actually committed a slightly different patch as if_vr.c:1.93 to > >>>>acquire the lock around vr_setcfg() in vr_miibus_statchg(). Could you > >>>>check that that also solves the problem? > >>> > >>>When I tried that, it booted but paniced as soon as I ran 'ifconfig > >>>vr0 media blah': > >>> > >>> > >>># ifconfig vr0 media 100baseTX > >>>panic: _mtx_lock_sleep: recursed on non-recursive mutex vr0 @ > >>>+/usr/src/sys/pci/if_vr.c:506 > >> > >>Same here with 1.93 installed, currently backed out to 1.92 so I can use > >>my network > > > > > > Just tried the patch in PR 70189 and it works fine for me > > > > So backing out rev 1.93 _and_ applying the patch in the PR makes > everything work? If so then I'll look into this today. Yes, that's exactly what I found, thanks Mike From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 14:37:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64EE316A4CE for ; Tue, 10 Aug 2004 14:37:30 +0000 (GMT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9982043D39 for ; Tue, 10 Aug 2004 14:37:29 +0000 (GMT) (envelope-from mike@urgle.com) Received: from singsing.eng.demon.net (singsing.eng.demon.net [194.217.90.11]) by internal.mail.demon.net with ESMTP id i7AEe4416888; Tue, 10 Aug 2004 14:40:05 GMT Received: from singsing.eng.demon.net (localhost [127.0.0.1]) i7AEbMtY026006; Tue, 10 Aug 2004 15:37:22 +0100 (BST) (envelope-from mike@urgle.com) Received: (from michaelb@localhost) by singsing.eng.demon.net (8.12.10/8.12.10/Submit) id i7AEbL1Y026005; Tue, 10 Aug 2004 15:37:21 +0100 (BST) (envelope-from mike@urgle.com) X-Authentication-Warning: singsing.eng.demon.net: michaelb set sender to mike@urgle.com using -f From: Mike Bristow To: Simon Dick In-Reply-To: <1092148372.632.4.camel@laptop.irrelevant.org> References: <1092044482.20927.35.camel@singsing.eng.demon.net> <1092143030.54231.0.camel@simon.lcn.biz> <1092147286.632.0.camel@laptop.irrelevant.org> <4118DB22.8060202@samsco.org> <1092148372.632.4.camel@laptop.irrelevant.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: (none) Message-Id: <1092148641.25849.14.camel@singsing.eng.demon.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 10 Aug 2004 15:37:21 +0100 cc: freebsd-current@freebsd.org Subject: Re: panic: mutex vr0 not owned at ...if_vr.c:571 when doing ifconfig X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 14:37:30 -0000 On Tue, 2004-08-10 at 15:32, Simon Dick wrote: > > So backing out rev 1.93 _and_ applying the patch in the PR makes > > everything work? If so then I'll look into this today. Ta. I don't know why my box paniced with 1.92; I suspect it's partially due to the fact that my network is running ipv6 as well as ipv4, but I'm guessing. > Yes, that's exactly what I found, thanks Mike Thanks for looking at my patch :) -- Mike Bristow - http://www.urgle.com/~mike/ - mike@urgle.com What do you give an injured lemon? So he could make a clean getaway From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 15:05:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 618B616A4CE for ; Tue, 10 Aug 2004 15:05:32 +0000 (GMT) Received: from ioskeha.hittite.isp.9tel.net (ioskeha.hittite.isp.9tel.net [62.62.156.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0D9543D41 for ; Tue, 10 Aug 2004 15:05:31 +0000 (GMT) (envelope-from martin.mato@wanadoo.fr) Received: from [192.168.0.2] (unknown [84.97.178.89]) by ioskeha.hittite.isp.9tel.net (Postfix) with ESMTP id 6FA7814B677 for ; Tue, 10 Aug 2004 17:15:09 +0200 (CEST) Message-ID: <4118E438.5050606@wanadoo.fr> Date: Tue, 10 Aug 2004 17:05:28 +0200 From: Martin MATO User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: fr, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <41183662.4010802@wanadoo.fr> <20040810050907.GL991@funkthat.com> <41185F7F.8070906@wanadoo.fr> <4118D144.2030401@wanadoo.fr> In-Reply-To: <4118D144.2030401@wanadoo.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: ACPI autoload failed: no such file or directory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: martin.mato@wanadoo.fr List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 15:05:32 -0000 Martin MATO a écrit : > Martin MATO a écrit : > >> John-Mark Gurney a écrit : >> >>> Martin MATO wrote this message on Tue, Aug 10, 2004 at 04:43 +0200: >>> >>> >>>> anyone could explain this.. strange thing? >>>> >>> >>> >>> >>> Someone else is seeing this w/ pf... >>> >>> Do you have any lines modifing module_path in your loader.conf? Also, >>> do you have an upto date support.4th? >>> >>> >>> >> i haven't any lines modifying module_path ( Andrew Milton has mailed >> me about adding module_path="/boot/kernel /boot/modules" to >> /boot/loader.conf, should fix it; but has no effects.) >> and i have an up to date support.4th , compiled at the same time as >> the kernel files. >> >> booting whith the GENERIC kernel has same behaviour, but with other >> errors messages; not in relation whith acpi; but debug support (!) >> i'll try compiling one whitout any OPTFLAGS and CFLAGS >> optimization, to see... (i use -O2 -pipe) >> >> but i doubt it is in relation with the kldload behaviour... >> >> ps: sorry for my bad english, i'm french... >> _______________________________________________ >> 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" >> > Well, with a GENERIC kernel first, and a new world compiled without > the -O2 flag, i obtaint the same problem. both with acpi autoload AND > kldload error.. > i'm out of ideas... :P > _______________________________________________ > 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" > well, i tried now some kload "modules.ko" NONE worked (no such files or directory) kldload doesn't seems to find them i checked the modules path; and i added - again- module_path="/boot/kernel /boot/modules" in /boot/loader.conf after reboot and the same ACPI autoload error message, kldload doesn't find again none of the modules i tried to load (i tried a lot of them)! the module path in the sysctl variable is effectively set to "/boot/kernel /boot/modules" with a cp /boot/kernel/*.ko /boot/modules kldload find finally the modules files; EXCEPT acpi.ko. i repeat I KNOW that acpi.ko can't be loaded from userland, i 'm only seeing if kldload find the file(s) specified. well i think i have a big problem here... :°( From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 15:20:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFEE316A4E2 for ; Tue, 10 Aug 2004 15:20:41 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCAE543D62 for ; Tue, 10 Aug 2004 15:20:11 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 19289 invoked from network); 10 Aug 2004 15:20:11 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 10 Aug 2004 15:20:10 -0000 Received: from 10.50.40.208 (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i7AFJpeq083739; Tue, 10 Aug 2004 11:20:06 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org, santtu.lintervo@kolumbus.fi Date: Tue, 10 Aug 2004 10:41:41 -0400 User-Agent: KMail/1.6 References: <200408101137.11297.santtu.lintervo@kolumbus.fi> In-Reply-To: <200408101137.11297.santtu.lintervo@kolumbus.fi> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408101041.41263.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx Subject: Re: INDEX file format X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 15:20:42 -0000 On Tuesday 10 August 2004 04:37 am, Santtu Lintervo wrote: > hello, > > it seems that the INDEX file format has changed recently. > where can i get the format of the file? I think that build_depends was split up into 3 separate fields. You can search the ports@ archive for a message about what the new fields are I believe. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 15:20:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3507416A4E7 for ; Tue, 10 Aug 2004 15:20:42 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43C8B43D1D for ; Tue, 10 Aug 2004 15:20:14 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 25712 invoked from network); 10 Aug 2004 15:20:14 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 10 Aug 2004 15:20:13 -0000 Received: from 10.50.40.208 (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i7AFJper083739; Tue, 10 Aug 2004 11:20:10 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Tue, 10 Aug 2004 10:43:15 -0400 User-Agent: KMail/1.6 References: <20040810113341.U31181@cvs.imp.ch> <20040810120924.T31181@cvs.imp.ch> In-Reply-To: <20040810120924.T31181@cvs.imp.ch> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408101043.15040.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Martin Blapp cc: current@FreeBSD.org Subject: Re: Stalled processes consuming 100% CPU in latest current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 15:20:42 -0000 On Tuesday 10 August 2004 06:10 am, Martin Blapp wrote: > And shortly later I got this panic: > > db> where > propagate_priority(c34c6840,c4989730,c34c6840,0,de955c74) at > propagate_priority+ 0x82 > turnstile_wait(c34e41c0,c0938c60,c4217160,6,4) at turnstile_wait+0x325 > _mtx_lock_sleep(c0938c60,c34c6840,0,0,0) at _mtx_lock_sleep+0x122 > softclock(0,0,0,0,0) at softclock+0x250 > ithread_loop(c34e8680,de955d48,0,0,0) at ithread_loop+0x1a4 > fork_exit(c062a11f,c34e8680,de955d48) at fork_exit+0x80 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xde955d7c, ebp = 0 --- > > Martin What was the actual panic? A trap 12? A failed assertion? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 15:20:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FB1B16A50F for ; Tue, 10 Aug 2004 15:20:42 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0DAC43D48 for ; Tue, 10 Aug 2004 15:20:23 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 19603 invoked from network); 10 Aug 2004 15:20:23 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 10 Aug 2004 15:20:22 -0000 Received: from 10.50.40.208 (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i7AFJpes083739; Tue, 10 Aug 2004 11:20:13 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Tue, 10 Aug 2004 10:45:39 -0400 User-Agent: KMail/1.6 References: <20040810164552.78f68ea6.brian@bee-s.com> <4118CEAE.2050100@samsco.org> In-Reply-To: <4118CEAE.2050100@samsco.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408101045.39960.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: "Andrew A. Leikand" cc: current@FreeBSD.org Subject: Re: 5.2-CURRENT crashes everyday X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 15:20:43 -0000 On Tuesday 10 August 2004 09:33 am, Scott Long wrote: > Hi, > > I'm pretty sure that this is a known, harmless bug. It might even have > been fixed in the last few weeks, but I can't remember for sure. You > can avoid the panics by removing INVARIANTS from your kernel config. > > Scott Err, LOR's don't panic. The panic is something else and is busted. The LOR messages can be ignored though. What we need are any other messages that might come up before it crashes. When you say "crash", what do you mean exactly: does it panic or does it just lock up hard? > Andrew A. Leikand wrote: > > Hello all > > > > well i have a real big problem it is the server with 5.2-current. > > Harware is IBM eServer 345 Dual Xeon with serveRAID 6i, raid controller > > has no support under STABLE thus i had no choice :( > > There are apache and sendmail on the server, load averages about 0.01, > > but it crashes everyday and i have no idea how to force it work. > > The only messages before it goes down is > > > > lock order reversal > > 1st 0xc6574738 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1311 > > 2nd 0xc0673ae0 swap_pager swhash (swap_pager swhash) @ > > /usr/src/sys/vm/swap_pager.c:1797 3rd 0xc0c43a50 vm object (vm object) @ > > /usr/src/sys/vm/uma_core.c:925 Stack backtrace: > > backtrace(0,1,c064cf90,c064e0c0,c06194dc) at backtrace+0x12 > > witness_checkorder(c0c43a50,9,c05fe7bf,39d) at witness_checkorder+0x53b > > _mtx_lock_flags(c0c43a50,0,c05fe7bf,39d,c350b288) at _mtx_lock_flags+0x57 > > obj_alloc(c3502dc0,1000,de086a2b,101,de086a38) at obj_alloc+0x31 > > slab_zalloc(c3502dc0,1,c3502dc0,c3502dc0,c350b280) at slab_zalloc+0x87 > > uma_zone_slab(c3502dc0,1,c350b288,0,c05fe7bf,79c) at uma_zone_slab+0xb0 > > uma_zalloc_internal(c3502dc0,0,1,c350b288,0) at uma_zalloc_internal+0x29 > > uma_zalloc_arg(c3502dc0,0,1) at uma_zalloc_arg+0x2a2 > > swp_pager_meta_build(c6574738,5e,0,2,0) at swp_pager_meta_build+0x108 > > swap_pager_putpages(c6574738,de086bf0,1,0,de086b60) at > > swap_pager_putpages+0x2a8 > > default_pager_putpages(c6574738,de086bf0,1,0,de086b60) at > > default_pager_putpages+0x18 vm_pageout_flush(de086bf0,1,0,c064c6e0,2ff) > > at vm_pageout_flush+0x112 vm_pageout_clean(c2ca1f88) at > > vm_pageout_clean+0x2a5 > > vm_pageout_scan(0,c0673fe0,0,c05fe55f,5a7) at vm_pageout_scan+0x543 > > vm_pageout(0,de086d48,0,c057f0e4,0) at vm_pageout+0x2cf > > fork_exit(c057f0e4,0,de086d48) at fork_exit+0x98 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0x1, eip = 0, esp = 0xde086d7c, ebp = 0 --- > > > > Kernel config and dmesg are attached. > > > > Appreciate any comments or feedback on this. > > > > -- > > BR, Andrew > > > > > > ------------------------------------------------------------------------ > > > > machine i386 > > cpu I686_CPU > > options CPU_ENABLE_SSE > > options MPTABLE_FORCE_HTT # Enable HTT CPUs with the MP > > Table > > > > ident TUNED > > > > # To statically compile in device wiring instead of /boot/device.hints > > #hints "GENERIC.hints" # Default places to look for devices. > > > > #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols > > > > options SCHED_ULE # ULE scheduler > > options INET # InterNETworking > > options FFS # Berkeley Fast Filesystem > > options SOFTUPDATES # Enable FFS soft updates support > > options UFS_ACL # Support for access control lists > > options UFS_DIRHASH # Improve performance on big directories > > options MD_ROOT # MD is a potential root device > > options MSDOSFS # MSDOS Filesystem > > options CD9660 # ISO 9660 Filesystem > > options PROCFS # Process filesystem (requires PSEUDOFS) > > options PSEUDOFS # Pseudo-filesystem framework > > options UNIONFS > > options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] > > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > > options COMPAT_LINUX # Enable Linux ABI emulation > > > > options SCSI_DELAY=15000 # Delay (in ms) before probing SCSI > > options KTRACE # ktrace(1) support > > options SYSVSHM # SYSV-style shared memory > > options SYSVMSG # SYSV-style message queues > > options SYSVSEM # SYSV-style semaphores > > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time > > extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev > > options QUOTA > > > > > > # Debugging for use in -current > > # options DDB # Enable the kernel debugger > > # options INVARIANTS # Enable calls of extra sanity checking > > # options INVARIANT_SUPPORT # Extra sanity checks of internal > > structures, required by INVARIANTS # options WITNESS # Enable checks > > to detect deadlocks and cycles # options WITNESS_SKIPSPIN # Don't run > > witness on spinlocks for speed > > > > # To make an SMP kernel, the next two are needed > > options SMP # Symmetric MultiProcessor Kernel > > device apic # I/O APIC > > > > device isa > > device pci > > > > # Floppy drives > > device fdc > > > > # ATA and ATAPI devices > > device ata > > device atadisk # ATA disk drives > > device atapicd # ATAPI CDROM drives > > options ATA_STATIC_ID # Static device numbering > > > > # SCSI peripherals > > device scbus # SCSI bus (required for SCSI) > > device ch # SCSI media changers > > device da # Direct Access (disks) > > device sa # Sequential Access (tape etc) > > device cd # CD > > device pass # Passthrough device (direct SCSI access) > > device ses # SCSI Environmental Services (and SAF-TE) > > > > # RAID controllers interfaced to the SCSI subsystem > > device ips # IBM (Adaptec) ServeRAID > > > > > > # atkbdc0 controls both the keyboard and the PS/2 mouse > > device atkbdc # AT keyboard controller > > device atkbd # AT keyboard > > device psm # PS/2 mouse > > > > device vga # VGA video card driver > > > > device splash # Splash screen and screen saver support > > > > # syscons is the default console driver, resembling an SCO console > > device sc > > > > device agp # support several AGP chipsets > > > > # Floating point support - do not disable. > > device npx > > > > # Power management support (see NOTES for more options) > > #device apm > > # Add suspend/resume support for the i8254. > > #device pmtimer > > > > # Serial (COM) ports > > device sio # 8250, 16[45]50 based serial ports > > > > # Parallel port > > #device ppc > > #device ppbus # Parallel port bus (required) > > #device lpt # Printer > > #device plip # TCP/IP over parallel > > #device ppi # Parallel port interface device > > #device vpo # Requires scbus and da > > > > # If you've got a "dumb" serial or parallel PCI card that is > > # supported by the puc(4) glue driver, uncomment the following > > # line to enable it (connects to the sio and/or ppc drivers): > > #device puc > > > > # PCI Ethernet NICs. > > device em # Intel PRO/1000 adapter Gigabit Ethernet Card > > > > # Pseudo devices - the number indicates how many units to allocate. > > device random # Entropy device > > device loop # Network loopback > > device ether # Ethernet support > > #device vlan > > #device sl # Kernel SLIP > > #device ppp # Kernel PPP > > device tun # Packet tunnel. > > device pty # Pseudo-ttys (telnet etc) > > device md # Memory "disks" > > # device pf > > # device pflog > > # device pfsync > > > > > > # The `bpf' device enables the Berkeley Packet Filter. > > # Be aware of the administrative consequences of enabling this! > > device bpf # Berkeley packet filter > > > > # > > options PFIL_HOOKS # pfil(9) framework > > options IPFILTER > > options IPFILTER_LOG > > options IPFILTER_DEFAULT_BLOCK > > #options IPSTEALTH > > options RANDOM_IP_ID > > options TCP_DROP_SYNFIN > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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" > > _______________________________________________ > 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" -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 15:20:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FC5416A4E5 for ; Tue, 10 Aug 2004 15:20:42 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 444EE43D31 for ; Tue, 10 Aug 2004 15:20:14 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 25712 invoked from network); 10 Aug 2004 15:20:14 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 10 Aug 2004 15:20:13 -0000 Received: from 10.50.40.208 (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i7AFJper083739; Tue, 10 Aug 2004 11:20:10 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Tue, 10 Aug 2004 10:43:15 -0400 User-Agent: KMail/1.6 References: <20040810113341.U31181@cvs.imp.ch> <20040810120924.T31181@cvs.imp.ch> In-Reply-To: <20040810120924.T31181@cvs.imp.ch> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408101043.15040.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Martin Blapp cc: current@FreeBSD.org Subject: Re: Stalled processes consuming 100% CPU in latest current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 15:20:43 -0000 On Tuesday 10 August 2004 06:10 am, Martin Blapp wrote: > And shortly later I got this panic: > > db> where > propagate_priority(c34c6840,c4989730,c34c6840,0,de955c74) at > propagate_priority+ 0x82 > turnstile_wait(c34e41c0,c0938c60,c4217160,6,4) at turnstile_wait+0x325 > _mtx_lock_sleep(c0938c60,c34c6840,0,0,0) at _mtx_lock_sleep+0x122 > softclock(0,0,0,0,0) at softclock+0x250 > ithread_loop(c34e8680,de955d48,0,0,0) at ithread_loop+0x1a4 > fork_exit(c062a11f,c34e8680,de955d48) at fork_exit+0x80 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xde955d7c, ebp = 0 --- > > Martin What was the actual panic? A trap 12? A failed assertion? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 15:20:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 460C416A4ED for ; Tue, 10 Aug 2004 15:20:42 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2BCB43D69 for ; Tue, 10 Aug 2004 15:20:23 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 19603 invoked from network); 10 Aug 2004 15:20:23 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 10 Aug 2004 15:20:22 -0000 Received: from 10.50.40.208 (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i7AFJpes083739; Tue, 10 Aug 2004 11:20:13 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Tue, 10 Aug 2004 10:45:39 -0400 User-Agent: KMail/1.6 References: <20040810164552.78f68ea6.brian@bee-s.com> <4118CEAE.2050100@samsco.org> In-Reply-To: <4118CEAE.2050100@samsco.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408101045.39960.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: "Andrew A. Leikand" cc: current@FreeBSD.org Subject: Re: 5.2-CURRENT crashes everyday X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 15:20:44 -0000 On Tuesday 10 August 2004 09:33 am, Scott Long wrote: > Hi, > > I'm pretty sure that this is a known, harmless bug. It might even have > been fixed in the last few weeks, but I can't remember for sure. You > can avoid the panics by removing INVARIANTS from your kernel config. > > Scott Err, LOR's don't panic. The panic is something else and is busted. The LOR messages can be ignored though. What we need are any other messages that might come up before it crashes. When you say "crash", what do you mean exactly: does it panic or does it just lock up hard? > Andrew A. Leikand wrote: > > Hello all > > > > well i have a real big problem it is the server with 5.2-current. > > Harware is IBM eServer 345 Dual Xeon with serveRAID 6i, raid controller > > has no support under STABLE thus i had no choice :( > > There are apache and sendmail on the server, load averages about 0.01, > > but it crashes everyday and i have no idea how to force it work. > > The only messages before it goes down is > > > > lock order reversal > > 1st 0xc6574738 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1311 > > 2nd 0xc0673ae0 swap_pager swhash (swap_pager swhash) @ > > /usr/src/sys/vm/swap_pager.c:1797 3rd 0xc0c43a50 vm object (vm object) @ > > /usr/src/sys/vm/uma_core.c:925 Stack backtrace: > > backtrace(0,1,c064cf90,c064e0c0,c06194dc) at backtrace+0x12 > > witness_checkorder(c0c43a50,9,c05fe7bf,39d) at witness_checkorder+0x53b > > _mtx_lock_flags(c0c43a50,0,c05fe7bf,39d,c350b288) at _mtx_lock_flags+0x57 > > obj_alloc(c3502dc0,1000,de086a2b,101,de086a38) at obj_alloc+0x31 > > slab_zalloc(c3502dc0,1,c3502dc0,c3502dc0,c350b280) at slab_zalloc+0x87 > > uma_zone_slab(c3502dc0,1,c350b288,0,c05fe7bf,79c) at uma_zone_slab+0xb0 > > uma_zalloc_internal(c3502dc0,0,1,c350b288,0) at uma_zalloc_internal+0x29 > > uma_zalloc_arg(c3502dc0,0,1) at uma_zalloc_arg+0x2a2 > > swp_pager_meta_build(c6574738,5e,0,2,0) at swp_pager_meta_build+0x108 > > swap_pager_putpages(c6574738,de086bf0,1,0,de086b60) at > > swap_pager_putpages+0x2a8 > > default_pager_putpages(c6574738,de086bf0,1,0,de086b60) at > > default_pager_putpages+0x18 vm_pageout_flush(de086bf0,1,0,c064c6e0,2ff) > > at vm_pageout_flush+0x112 vm_pageout_clean(c2ca1f88) at > > vm_pageout_clean+0x2a5 > > vm_pageout_scan(0,c0673fe0,0,c05fe55f,5a7) at vm_pageout_scan+0x543 > > vm_pageout(0,de086d48,0,c057f0e4,0) at vm_pageout+0x2cf > > fork_exit(c057f0e4,0,de086d48) at fork_exit+0x98 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0x1, eip = 0, esp = 0xde086d7c, ebp = 0 --- > > > > Kernel config and dmesg are attached. > > > > Appreciate any comments or feedback on this. > > > > -- > > BR, Andrew > > > > > > ------------------------------------------------------------------------ > > > > machine i386 > > cpu I686_CPU > > options CPU_ENABLE_SSE > > options MPTABLE_FORCE_HTT # Enable HTT CPUs with the MP > > Table > > > > ident TUNED > > > > # To statically compile in device wiring instead of /boot/device.hints > > #hints "GENERIC.hints" # Default places to look for devices. > > > > #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols > > > > options SCHED_ULE # ULE scheduler > > options INET # InterNETworking > > options FFS # Berkeley Fast Filesystem > > options SOFTUPDATES # Enable FFS soft updates support > > options UFS_ACL # Support for access control lists > > options UFS_DIRHASH # Improve performance on big directories > > options MD_ROOT # MD is a potential root device > > options MSDOSFS # MSDOS Filesystem > > options CD9660 # ISO 9660 Filesystem > > options PROCFS # Process filesystem (requires PSEUDOFS) > > options PSEUDOFS # Pseudo-filesystem framework > > options UNIONFS > > options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] > > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > > options COMPAT_LINUX # Enable Linux ABI emulation > > > > options SCSI_DELAY=15000 # Delay (in ms) before probing SCSI > > options KTRACE # ktrace(1) support > > options SYSVSHM # SYSV-style shared memory > > options SYSVMSG # SYSV-style message queues > > options SYSVSEM # SYSV-style semaphores > > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time > > extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev > > options QUOTA > > > > > > # Debugging for use in -current > > # options DDB # Enable the kernel debugger > > # options INVARIANTS # Enable calls of extra sanity checking > > # options INVARIANT_SUPPORT # Extra sanity checks of internal > > structures, required by INVARIANTS # options WITNESS # Enable checks > > to detect deadlocks and cycles # options WITNESS_SKIPSPIN # Don't run > > witness on spinlocks for speed > > > > # To make an SMP kernel, the next two are needed > > options SMP # Symmetric MultiProcessor Kernel > > device apic # I/O APIC > > > > device isa > > device pci > > > > # Floppy drives > > device fdc > > > > # ATA and ATAPI devices > > device ata > > device atadisk # ATA disk drives > > device atapicd # ATAPI CDROM drives > > options ATA_STATIC_ID # Static device numbering > > > > # SCSI peripherals > > device scbus # SCSI bus (required for SCSI) > > device ch # SCSI media changers > > device da # Direct Access (disks) > > device sa # Sequential Access (tape etc) > > device cd # CD > > device pass # Passthrough device (direct SCSI access) > > device ses # SCSI Environmental Services (and SAF-TE) > > > > # RAID controllers interfaced to the SCSI subsystem > > device ips # IBM (Adaptec) ServeRAID > > > > > > # atkbdc0 controls both the keyboard and the PS/2 mouse > > device atkbdc # AT keyboard controller > > device atkbd # AT keyboard > > device psm # PS/2 mouse > > > > device vga # VGA video card driver > > > > device splash # Splash screen and screen saver support > > > > # syscons is the default console driver, resembling an SCO console > > device sc > > > > device agp # support several AGP chipsets > > > > # Floating point support - do not disable. > > device npx > > > > # Power management support (see NOTES for more options) > > #device apm > > # Add suspend/resume support for the i8254. > > #device pmtimer > > > > # Serial (COM) ports > > device sio # 8250, 16[45]50 based serial ports > > > > # Parallel port > > #device ppc > > #device ppbus # Parallel port bus (required) > > #device lpt # Printer > > #device plip # TCP/IP over parallel > > #device ppi # Parallel port interface device > > #device vpo # Requires scbus and da > > > > # If you've got a "dumb" serial or parallel PCI card that is > > # supported by the puc(4) glue driver, uncomment the following > > # line to enable it (connects to the sio and/or ppc drivers): > > #device puc > > > > # PCI Ethernet NICs. > > device em # Intel PRO/1000 adapter Gigabit Ethernet Card > > > > # Pseudo devices - the number indicates how many units to allocate. > > device random # Entropy device > > device loop # Network loopback > > device ether # Ethernet support > > #device vlan > > #device sl # Kernel SLIP > > #device ppp # Kernel PPP > > device tun # Packet tunnel. > > device pty # Pseudo-ttys (telnet etc) > > device md # Memory "disks" > > # device pf > > # device pflog > > # device pfsync > > > > > > # The `bpf' device enables the Berkeley Packet Filter. > > # Be aware of the administrative consequences of enabling this! > > device bpf # Berkeley packet filter > > > > # > > options PFIL_HOOKS # pfil(9) framework > > options IPFILTER > > options IPFILTER_LOG > > options IPFILTER_DEFAULT_BLOCK > > #options IPSTEALTH > > options RANDOM_IP_ID > > options TCP_DROP_SYNFIN > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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" > > _______________________________________________ > 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" -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 15:24:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F378516A4CE for ; Tue, 10 Aug 2004 15:24:14 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63FBC43D1D for ; Tue, 10 Aug 2004 15:24:14 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7AFMcru084800; Tue, 10 Aug 2004 11:22:38 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7AFMbpD084797; Tue, 10 Aug 2004 11:22:37 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 10 Aug 2004 11:22:37 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: <4118CEAE.2050100@samsco.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "Andrew A. Leikand" cc: current@freebsd.org Subject: Re: 5.2-CURRENT crashes everyday X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 15:24:15 -0000 On Tue, 10 Aug 2004, Scott Long wrote: > I'm pretty sure that this is a known, harmless bug. It might even have > been fixed in the last few weeks, but I can't remember for sure. You > can avoid the panics by removing INVARIANTS from your kernel config. Lock reversals don't generate a panic by default, so the hang must happen shortly after the lock order reversal. I.e., there's a real bug here, but it may or may not be related to the WITNESS output. Andrew -- if you use a serial console, are you able to use a serial break to get into the debugger if the debugger is compiled in with serial break support? You can find details on setting up the debugging environment in the handbook. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research > > Scott > > Andrew A. Leikand wrote: > > Hello all > > > > well i have a real big problem it is the server with 5.2-current. > > Harware is IBM eServer 345 Dual Xeon with serveRAID 6i, raid controller > > has no support under STABLE thus i had no choice :( > > There are apache and sendmail on the server, load averages about 0.01, > > but it crashes everyday and i have no idea how to force it work. > > The only messages before it goes down is > > > > lock order reversal > > 1st 0xc6574738 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1311 > > 2nd 0xc0673ae0 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pager.c:1797 > > 3rd 0xc0c43a50 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:925 > > Stack backtrace: > > backtrace(0,1,c064cf90,c064e0c0,c06194dc) at backtrace+0x12 > > witness_checkorder(c0c43a50,9,c05fe7bf,39d) at witness_checkorder+0x53b > > _mtx_lock_flags(c0c43a50,0,c05fe7bf,39d,c350b288) at _mtx_lock_flags+0x57 > > obj_alloc(c3502dc0,1000,de086a2b,101,de086a38) at obj_alloc+0x31 > > slab_zalloc(c3502dc0,1,c3502dc0,c3502dc0,c350b280) at slab_zalloc+0x87 > > uma_zone_slab(c3502dc0,1,c350b288,0,c05fe7bf,79c) at uma_zone_slab+0xb0 > > uma_zalloc_internal(c3502dc0,0,1,c350b288,0) at uma_zalloc_internal+0x29 > > uma_zalloc_arg(c3502dc0,0,1) at uma_zalloc_arg+0x2a2 > > swp_pager_meta_build(c6574738,5e,0,2,0) at swp_pager_meta_build+0x108 > > swap_pager_putpages(c6574738,de086bf0,1,0,de086b60) at swap_pager_putpages+0x2a8 > > default_pager_putpages(c6574738,de086bf0,1,0,de086b60) at default_pager_putpages+0x18 > > vm_pageout_flush(de086bf0,1,0,c064c6e0,2ff) at vm_pageout_flush+0x112 > > vm_pageout_clean(c2ca1f88) at vm_pageout_clean+0x2a5 > > vm_pageout_scan(0,c0673fe0,0,c05fe55f,5a7) at vm_pageout_scan+0x543 > > vm_pageout(0,de086d48,0,c057f0e4,0) at vm_pageout+0x2cf > > fork_exit(c057f0e4,0,de086d48) at fork_exit+0x98 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0x1, eip = 0, esp = 0xde086d7c, ebp = 0 --- > > > > Kernel config and dmesg are attached. > > > > Appreciate any comments or feedback on this. > > > > -- > > BR, Andrew > > > > > > ------------------------------------------------------------------------ > > > > machine i386 > > cpu I686_CPU > > options CPU_ENABLE_SSE > > options MPTABLE_FORCE_HTT # Enable HTT CPUs with the MP Table > > > > ident TUNED > > > > # To statically compile in device wiring instead of /boot/device.hints > > #hints "GENERIC.hints" # Default places to look for devices. > > > > #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols > > > > options SCHED_ULE # ULE scheduler > > options INET # InterNETworking > > options FFS # Berkeley Fast Filesystem > > options SOFTUPDATES # Enable FFS soft updates support > > options UFS_ACL # Support for access control lists > > options UFS_DIRHASH # Improve performance on big directories > > options MD_ROOT # MD is a potential root device > > options MSDOSFS # MSDOS Filesystem > > options CD9660 # ISO 9660 Filesystem > > options PROCFS # Process filesystem (requires PSEUDOFS) > > options PSEUDOFS # Pseudo-filesystem framework > > options UNIONFS > > options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] > > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > > options COMPAT_LINUX # Enable Linux ABI emulation > > > > options SCSI_DELAY=15000 # Delay (in ms) before probing SCSI > > options KTRACE # ktrace(1) support > > options SYSVSHM # SYSV-style shared memory > > options SYSVMSG # SYSV-style message queues > > options SYSVSEM # SYSV-style semaphores > > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions > > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > > options QUOTA > > > > > > # Debugging for use in -current > > # options DDB # Enable the kernel debugger > > # options INVARIANTS # Enable calls of extra sanity checking > > # options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS > > # options WITNESS # Enable checks to detect deadlocks and cycles > > # options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed > > > > # To make an SMP kernel, the next two are needed > > options SMP # Symmetric MultiProcessor Kernel > > device apic # I/O APIC > > > > device isa > > device pci > > > > # Floppy drives > > device fdc > > > > # ATA and ATAPI devices > > device ata > > device atadisk # ATA disk drives > > device atapicd # ATAPI CDROM drives > > options ATA_STATIC_ID # Static device numbering > > > > # SCSI peripherals > > device scbus # SCSI bus (required for SCSI) > > device ch # SCSI media changers > > device da # Direct Access (disks) > > device sa # Sequential Access (tape etc) > > device cd # CD > > device pass # Passthrough device (direct SCSI access) > > device ses # SCSI Environmental Services (and SAF-TE) > > > > # RAID controllers interfaced to the SCSI subsystem > > device ips # IBM (Adaptec) ServeRAID > > > > > > # atkbdc0 controls both the keyboard and the PS/2 mouse > > device atkbdc # AT keyboard controller > > device atkbd # AT keyboard > > device psm # PS/2 mouse > > > > device vga # VGA video card driver > > > > device splash # Splash screen and screen saver support > > > > # syscons is the default console driver, resembling an SCO console > > device sc > > > > device agp # support several AGP chipsets > > > > # Floating point support - do not disable. > > device npx > > > > # Power management support (see NOTES for more options) > > #device apm > > # Add suspend/resume support for the i8254. > > #device pmtimer > > > > # Serial (COM) ports > > device sio # 8250, 16[45]50 based serial ports > > > > # Parallel port > > #device ppc > > #device ppbus # Parallel port bus (required) > > #device lpt # Printer > > #device plip # TCP/IP over parallel > > #device ppi # Parallel port interface device > > #device vpo # Requires scbus and da > > > > # If you've got a "dumb" serial or parallel PCI card that is > > # supported by the puc(4) glue driver, uncomment the following > > # line to enable it (connects to the sio and/or ppc drivers): > > #device puc > > > > # PCI Ethernet NICs. > > device em # Intel PRO/1000 adapter Gigabit Ethernet Card > > > > # Pseudo devices - the number indicates how many units to allocate. > > device random # Entropy device > > device loop # Network loopback > > device ether # Ethernet support > > #device vlan > > #device sl # Kernel SLIP > > #device ppp # Kernel PPP > > device tun # Packet tunnel. > > device pty # Pseudo-ttys (telnet etc) > > device md # Memory "disks" > > # device pf > > # device pflog > > # device pfsync > > > > > > # The `bpf' device enables the Berkeley Packet Filter. > > # Be aware of the administrative consequences of enabling this! > > device bpf # Berkeley packet filter > > > > # > > options PFIL_HOOKS # pfil(9) framework > > options IPFILTER > > options IPFILTER_LOG > > options IPFILTER_DEFAULT_BLOCK > > #options IPSTEALTH > > options RANDOM_IP_ID > > options TCP_DROP_SYNFIN > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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" > > _______________________________________________ > 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 Aug 10 15:38:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D17CE16A4CE for ; Tue, 10 Aug 2004 15:38:11 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5ED1243D54 for ; Tue, 10 Aug 2004 15:38:11 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7AFac8C085126; Tue, 10 Aug 2004 11:36:38 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7AFacRW085123; Tue, 10 Aug 2004 11:36:38 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 10 Aug 2004 11:36:38 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Martin Blapp In-Reply-To: <20040810121717.X31181@cvs.imp.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: Current is in a very desolated state X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 15:38:11 -0000 On Tue, 10 Aug 2004, Martin Blapp wrote: > Even with the disabled preemtion CURRENT is in a very desolated state at > the moment - and this one week before freeze. > > While I was able to run a server with 5.2.1 about 1 month without > panicing, this is no longer true with recent current. > > The panics I get are in the timer codepath or sometimes in the vfs > layer. It's very easy to kill the machine with high load (rm -rfd > /usr/src while running a make world -j 10) kills the server. > > I also get this panic after 20 - 30 minutes load You left out the panic message. In fact, you left out all three panic messages. This will makes it a lot harder to debug the problems you're experiencing. While I'm sure you're already familiar with it, you can find instructions for setting up the debugging environment and making bug reports in the handbook. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research > propagate_priority(c34e3420,0,82b45d4f,16ccf49,ffc00014) at > propagate_priority+0x82 > turnstile_wait(c3bd0480,c09396a0,c3aea840,c35b0680,4) at turnstile_wait+0x325 > _mtx_lock_sleep(c09396a0,c34e3420,0,0,0) at _mtx_lock_sleep+0x122 > ithread_loop(c3460980,de97bd48,0,0,0) at ithread_loop+0x19c > fork_exit(c062a1af,c3460980,de97bd48) at fork_exit+0x80 > fork_trampoline() at fork_trampoline+0x8 > > This is an SMP box with two XEON's, running a SMP kernel with SCHEDBSD. > > Martin > > Martin Blapp, > ------------------------------------------------------------------ > ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH > Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 > PGP: > PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E > ------------------------------------------------------------------ > _______________________________________________ > 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 Aug 10 15:39:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19A9316A4CE for ; Tue, 10 Aug 2004 15:39:46 +0000 (GMT) Received: from mail.imp.ch (ns1.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C5BD43D46 for ; Tue, 10 Aug 2004 15:39:45 +0000 (GMT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.9p2/8.12.3) with ESMTP id i7AFdbbC081377 for ; Tue, 10 Aug 2004 17:39:38 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Tue, 10 Aug 2004 17:39:37 +0200 (CEST) From: Martin Blapp To: current@freebsd.org In-Reply-To: <20040810113341.U31181@cvs.imp.ch> Message-ID: <20040810173827.B31181@cvs.imp.ch> References: <20040810113341.U31181@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checksum: 7368209757ed51574eedab65d0770b3e X-Virus-Status: No, scantime="0.0030 seconds" X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=4 scantime="3.8713 seconds" tests=BAYES_00 X-Scanned-By: MIMEDefang 2.44 Subject: Re: Stalled processes consuming 100% CPU in latest current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 15:39:46 -0000 Hi, > And there it hangs forever and does nothing ... The userland hangs turned our to be a corrupt bayes. The result was many processes eating all existing CPU slots. This lead to high socket and IPC usage and to the panics afterwords. Martin From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 15:49:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8ED5D16A4CE for ; Tue, 10 Aug 2004 15:49:16 +0000 (GMT) Received: from meitner.wh.uni-dortmund.de (meitner.wh.Uni-Dortmund.DE [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D40943D2D for ; Tue, 10 Aug 2004 15:49:16 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id CFC161675E1; Tue, 10 Aug 2004 17:49:14 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i7AFjaZK082206 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 10 Aug 2004 17:45:41 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: freebsd-current@FreeBSD.org Date: Tue, 10 Aug 2004 17:45:29 +0200 User-Agent: KMail/1.6.2 References: <20040810093218.gck4kwcwsckocko8@mail.encontacto.net> In-Reply-To: <20040810093218.gck4kwcwsckocko8@mail.encontacto.net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_e2OGBIRX93/BWpT"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408101745.34348.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new Subject: Re: Problem with sound in latest current o athlon w/VIA, kde, KsCD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 15:49:16 -0000 --Boundary-02=_e2OGBIRX93/BWpT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 10 August 2004 16:32, Edwin Culp wrote: > I've installed the latest kde3 on 5 Athlon's with via chipset > (all en one memory shared thingy) and even though they are > cheapies, everything works well except for an issue with KsCD. > It shows that it is playing the cd but no sound. I fire up xmms > w/cdread and it works out of the box and with sound :). KsCD does not 'rip' CDs to play them, it simply sends play commands to the= =20 drive. To get hear the sound, you need to connect your drive's sound output= =20 with a matching input on your soundcard. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --Boundary-02=_e2OGBIRX93/BWpT Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBBGO2eXhc68WspdLARAr6wAJ9OPQ+5MYQrpd4NRec4EA5rsWCOVwCeNNiZ oWo2iHmdeBC82+4+T5Nk6hQ= =pnrh -----END PGP SIGNATURE----- --Boundary-02=_e2OGBIRX93/BWpT-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 15:57:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D03E616A4CE for ; Tue, 10 Aug 2004 15:57:07 +0000 (GMT) Received: from tethys.ringofsaturn.com (tethys.ringofsaturn.com [66.13.175.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25A2943D54 for ; Tue, 10 Aug 2004 15:57:07 +0000 (GMT) (envelope-from rnejdl@ringofsaturn.com) Received: from mail.ringofsaturn.com (localhost [127.0.0.1]) i7AFv6eX060599 for ; Tue, 10 Aug 2004 10:57:06 -0500 (CDT) (envelope-from rnejdl@ringofsaturn.com) Received: from 12.148.147.242 (SquirrelMail authenticated user rnejdl); by mail.ringofsaturn.com with HTTP; Tue, 10 Aug 2004 10:57:06 -0500 (CDT) Message-ID: <34711.12.148.147.242.1092153426.squirrel@[12.148.147.242]> In-Reply-To: <200408101745.34348.michaelnottebrock@gmx.net> References: <20040810093218.gck4kwcwsckocko8@mail.encontacto.net> <200408101745.34348.michaelnottebrock@gmx.net> Date: Tue, 10 Aug 2004 10:57:06 -0500 (CDT) From: "Rusty Nejdl" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on tethys.ringofsaturn.com X-Virus-Status: Clean Subject: Re: Problem with sound in latest current o athlon w/VIA, kde, KsCD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rnejdl@ringofsaturn.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 15:57:07 -0000 > > KsCD does not 'rip' CDs to play them, it simply sends play commands to > the drive. To get hear the sound, you need to connect your drive's sound > output with a matching input on your soundcard. > Also, run the mixer command from the cli and verify that the cd volume is not 0:0 Mixer cd is currently set to 90:90 Rusty From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 16:45:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55EE516A4CE; Tue, 10 Aug 2004 16:45:09 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3346643D46; Tue, 10 Aug 2004 16:45:08 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 2B0E61FF9A6; Tue, 10 Aug 2004 18:45:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 413AF1FF92F; Tue, 10 Aug 2004 18:45:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 20CDE15665; Tue, 10 Aug 2004 16:41:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 1D80715329; Tue, 10 Aug 2004 16:41:43 +0000 (UTC) Date: Tue, 10 Aug 2004 16:41:43 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Robert Watson In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: "Andrew A. Leikand" cc: FreeBSD current mailing list Subject: Re: 5.2-CURRENT crashes everyday X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 16:45:09 -0000 On Tue, 10 Aug 2004, Robert Watson wrote: > On Tue, 10 Aug 2004, Scott Long wrote: > > > I'm pretty sure that this is a known, harmless bug. It might even have > > been fixed in the last few weeks, but I can't remember for sure. You > > can avoid the panics by removing INVARIANTS from your kernel config. > > Lock reversals don't generate a panic by default, so the hang must happen > shortly after the lock order reversal. I.e., there's a real bug here, but > it may or may not be related to the WITNESS output. > > Andrew -- if you use a serial console, are you able to use a serial break > to get into the debugger if the debugger is compiled in with serial break > support? You can find details on setting up the debugging environment in > the handbook. apart from that I remember someone with exact the same symptoms and the same report (no serial log but only this well known LOR) but I cannot remember what had been the actual problem or if it got solved. Search for this LOR in the archives of the last two months. Might help anyone who is going to look into this to get more input. > > Andrew A. Leikand wrote: > > > > > > well i have a real big problem it is the server with 5.2-current. > > > Harware is IBM eServer 345 Dual Xeon with serveRAID 6i, raid controller > > > has no support under STABLE thus i had no choice :( > > > There are apache and sendmail on the server, load averages about 0.01, > > > but it crashes everyday and i have no idea how to force it work. > > > The only messages before it goes down is > > > > > > lock order reversal > > > 1st 0xc6574738 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1311 > > > 2nd 0xc0673ae0 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pager.c:1797 > > > 3rd 0xc0c43a50 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:925 > > > Stack backtrace: > > > backtrace(0,1,c064cf90,c064e0c0,c06194dc) at backtrace+0x12 > > > witness_checkorder(c0c43a50,9,c05fe7bf,39d) at witness_checkorder+0x53b > > > _mtx_lock_flags(c0c43a50,0,c05fe7bf,39d,c350b288) at _mtx_lock_flags+0x57 > > > obj_alloc(c3502dc0,1000,de086a2b,101,de086a38) at obj_alloc+0x31 > > > slab_zalloc(c3502dc0,1,c3502dc0,c3502dc0,c350b280) at slab_zalloc+0x87 > > > uma_zone_slab(c3502dc0,1,c350b288,0,c05fe7bf,79c) at uma_zone_slab+0xb0 > > > uma_zalloc_internal(c3502dc0,0,1,c350b288,0) at uma_zalloc_internal+0x29 > > > uma_zalloc_arg(c3502dc0,0,1) at uma_zalloc_arg+0x2a2 > > > swp_pager_meta_build(c6574738,5e,0,2,0) at swp_pager_meta_build+0x108 > > > swap_pager_putpages(c6574738,de086bf0,1,0,de086b60) at swap_pager_putpages+0x2a8 > > > default_pager_putpages(c6574738,de086bf0,1,0,de086b60) at default_pager_putpages+0x18 > > > vm_pageout_flush(de086bf0,1,0,c064c6e0,2ff) at vm_pageout_flush+0x112 > > > vm_pageout_clean(c2ca1f88) at vm_pageout_clean+0x2a5 > > > vm_pageout_scan(0,c0673fe0,0,c05fe55f,5a7) at vm_pageout_scan+0x543 > > > vm_pageout(0,de086d48,0,c057f0e4,0) at vm_pageout+0x2cf > > > fork_exit(c057f0e4,0,de086d48) at fork_exit+0x98 > > > fork_trampoline() at fork_trampoline+0x8 > > > --- trap 0x1, eip = 0, esp = 0xde086d7c, ebp = 0 --- > > > > > > Kernel config and dmesg are attached. > > > > > > Appreciate any comments or feedback on this. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 16:56:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 095D816A4CE for ; Tue, 10 Aug 2004 16:56:05 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id B495E43D4C for ; Tue, 10 Aug 2004 16:56:04 +0000 (GMT) (envelope-from jon.drews@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so157824rnl for ; Tue, 10 Aug 2004 09:56:00 -0700 (PDT) Received: by 10.38.78.1 with SMTP id a1mr1544213rnb; Tue, 10 Aug 2004 09:56:00 -0700 (PDT) Message-ID: <8cb27cbf040810095659e1ef69@mail.gmail.com> Date: Tue, 10 Aug 2004 11:56:00 -0500 From: Jon Drews To: freebsd-current@freebsd.org In-Reply-To: <20040809221244.GB14911@fasolt.home.paeps.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040805071236.GA595@loge.nixsys.be> <20040809090723.GI642@loge.nixsys.be> <20040809221244.GB14911@fasolt.home.paeps.cx> Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 16:56:05 -0000 On Tue, 10 Aug 2004 00:12:44 +0200, Philip Paeps wrote: > Mmm, oh, right. Verbose isn't verbose enough for psm, I'm afraid you'll have > to compile a kernel with options PSM_DEBUG=2. I'll have to remember to stick > the probe-messages under a normal verbose. Hi Philip: I got it compiled with the above option. Here is the complete output: http://www.silbsd.org/bugreports/dmesgVerbose.txt This is for 5.2-CURRENT #0: Tue Aug 10 11:11:49 CDT 2004 Here are the relevant info* and cap* lines: Synaptics Touchpad v5.8 Model information: infoRot180: 1 infoPortrait: 0 infoSensor: 29 infoHardware: 36 infoNewAbs: 1 capPen: 0 infoSimplC: 1 infoGeometry: 1 Extended capabilities: capExtended: 1 capPassthrough: 0 capSleep: 1 capFourButtons: 0 capMultiFinger: 1 capPalmDetect: 1 psm0: found Synaptics Touchpad Kind regards, Jonathan From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 17:08:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F086B16A4CE for ; Tue, 10 Aug 2004 17:08:34 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF48343D2F for ; Tue, 10 Aug 2004 17:08:34 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id C3AE772DF2; Tue, 10 Aug 2004 10:08:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id BF37472DB5; Tue, 10 Aug 2004 10:08:34 -0700 (PDT) Date: Tue, 10 Aug 2004 10:08:34 -0700 (PDT) From: Doug White To: Terrence Koeman In-Reply-To: <200408101606842.SM01804@manrikigusari> Message-ID: <20040810100612.Q88160@carver.gumbysoft.com> References: <200408101606842.SM01804@manrikigusari> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: RE: Compiler segmentation fault in 5-08 -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 17:08:35 -0000 On Tue, 10 Aug 2004, Terrence Koeman wrote: > > Can you compile a simple "hello world" program? Sometimes > > these types of > > faults can be caused by faulty memory, processor, overclocking, or > > temperature issues. > > It doesn't seem hardware related. Before the update I had no problems with > segmentation faults, and the system can take heavy load just fine. > > I tried to compile the following hello world program: [...] > helloworld.c:4: internal compiler error: Segmentation fault Ugh. Looks like your gcc binary's busted. > Is there perhaps a way to copy over the compiler from a working (older) > -CURRENT system and build a new world with it to see if it's fixed in cvs? You might try tracking down a recent snapshot and do an 'upgrade'; that should overwrite your defective binary. This problem is unique to you so you may have had a disk error or something that's zeroed out part of the gcc binary or cc1 or something important like that. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 17:13:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 638D016A4D0; Tue, 10 Aug 2004 17:13:04 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4307843D5C; Tue, 10 Aug 2004 17:13:04 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 36E5772DF2; Tue, 10 Aug 2004 10:13:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 348F372DB5; Tue, 10 Aug 2004 10:13:04 -0700 (PDT) Date: Tue, 10 Aug 2004 10:13:04 -0700 (PDT) From: Doug White To: "Conrad J. Sabatier" In-Reply-To: Message-ID: <20040810101020.D88160@carver.gumbysoft.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: cvsup on amd64 just broke today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 17:13:04 -0000 On Mon, 9 Aug 2004, Conrad J. Sabatier wrote: > > Can you run cvsup manually? It appears to be trying to execute a > > binary as a shell script here. > > Tried that, got the same result. > > I hadn't noticed it before, but it does strike me as odd that the > binary package for amd64 would include a file with "i386" in the name, > and which is, in fact, an ELF 32 binary. Did something change today > that would effect the handling of such a file, perhaps? Possible. In the interim you might try installing this native amd64 version of cvsup (its a package so pkg_add it): http://people.freebsd.org/~peter/cvsup-without-gui-16.1h.tbz If that doesn't work for you I can build a package on my amd64 box. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 17:15:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DA9616A4CE for ; Tue, 10 Aug 2004 17:15:27 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F19443D55 for ; Tue, 10 Aug 2004 17:15:27 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 453E272DF2; Tue, 10 Aug 2004 10:15:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 402A472DB5; Tue, 10 Aug 2004 10:15:27 -0700 (PDT) Date: Tue, 10 Aug 2004 10:15:27 -0700 (PDT) From: Doug White To: Mike Jakubik In-Reply-To: <2352.192.168.0.200.1092102436.squirrel@192.168.0.200> Message-ID: <20040810101435.C88160@carver.gumbysoft.com> References: <2352.192.168.0.200.1092102436.squirrel@192.168.0.200> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: buildworld failiure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 17:15:27 -0000 On Mon, 9 Aug 2004, Mike Jakubik wrote: > Cvsuped 3 times, no go. Thanks. This has been temproarily fixed. You can also work around it by compiling with NOATM. > ===> lib/libbsnmp/modules/snmp_atm > make: don't know how to make snmp_atm.h. Stop > *** Error code 2 -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 17:52:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 917AB16A4CE for ; Tue, 10 Aug 2004 17:52:18 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01A5B43D1D for ; Tue, 10 Aug 2004 17:52:18 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.102] (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0)i7AHeTjr030294 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 10 Aug 2004 13:40:30 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: John Birrell Date: Tue, 10 Aug 2004 13:53:14 -0400 User-Agent: KMail/1.6.2 References: <200407271731.12282.mistry.7@osu.edu> <200408041828.26762.mistry.7@osu.edu> <20040804223937.GA99521@freebsd3.cimlogic.com.au> In-Reply-To: <20040804223937.GA99521@freebsd3.cimlogic.com.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_LuQGBy7Z7vDlpxv" Message-Id: <200408101353.22714.mistry.7@osu.edu> X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,J_CHICKENPOX_34, J_CHICKENPOX_42,PATCH_UNIFIED_DIFF,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_KMAIL version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-current@freebsd.org Subject: Re: FreeBSD and wine mmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 17:52:18 -0000 --Boundary-00=_LuQGBy7Z7vDlpxv Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 04 August 2004 06:39 pm, you wrote: > On Wed, Aug 04, 2004 at 06:28:02PM -0400, Anish Mistry wrote: > > Ok, so we need something like vm_map_findspace(), but for process addre= ss > > mapping? ie. pmap_findspace() that will return an address to a large > > enough free chunk? > > That's a good start, just to get something to work with. How this fits in > with the vm code and whether it is ultimately suitable in the long run is > probably up to Alan Cox. For now, just get something that (a) doesn't bre= ak > anything else; and (b) lets Wine behave the way it needs to. > > AFAIK, there are still pthread issues with Wine, but those can't be > addressed until the mmap issue has a work-around. I've got a small patch that gets by the initial problem about not being to= =20 mmap the memory for the libraries, but the addresses that are mmap'ed seem = to=20 seem to overlap with memory that the current pthread implementation want to= =20 mmap for the "red zone" when wine tries to create a thread. It can't mmap= =20 the "red zone" addresses since all those address mapping where gobbled up=20 before the thread launched. I'll try to figure out a way to maybe leave a space for the "red zone" and = see=20 if that works. Someone who actually knows what they are doing should probably take a look. =2D --=20 Anish Mistry =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGQuRxqA5ziudZT0RAv0VAJ0bL3c9McGSCjtXLucNuIwJRWkt7QCdG6Uh jJeycc2sW1sb4fFOsJ+vT/k=3D =3D/uWq =2D----END PGP SIGNATURE----- --Boundary-00=_LuQGBy7Z7vDlpxv Content-Type: text/x-diff; charset="iso-8859-1"; name="vm_mmap.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vm_mmap.patch" --- vm_mmap.c.orig Thu Aug 5 03:04:33 2004 +++ vm_mmap.c Tue Aug 10 13:02:09 2004 @@ -208,6 +208,8 @@ vm_offset_t addr; vm_size_t size, pageoff; vm_prot_t prot, maxprot; + vm_map_t map; + void *handle; int flags, error; off_t pos; @@ -276,9 +278,28 @@ if (addr == 0 || (addr >= round_page((vm_offset_t)vms->vm_taddr) && addr < round_page((vm_offset_t)vms->vm_daddr + - lim_max(td->td_proc, RLIMIT_DATA)))) + lim_max(td->td_proc, RLIMIT_DATA)))) { + /* + * XXX So much dirtyness someone who knows what they are doing + * will want to fix this monstrosity. + */ + map = &td->td_proc->p_vmspace->vm_map; + vm_map_lock(map); addr = round_page((vm_offset_t)vms->vm_daddr + - lim_max(td->td_proc, RLIMIT_DATA)); + lim_max(td->td_proc, RLIMIT_DATA)); + if(vm_map_findspace(map, addr, size, &addr) != 0) { + /* + * since we can't grab the upper process address space bruteforce it. + */ + for(addr = 2048*1024;addr <= round_page((vm_offset_t)vms->vm_taddr) && + vm_map_findspace(map, addr, size, &addr) != 0 + ;addr += PAGE_SIZE,addr = round_page(addr)); + +/* printf("NFND 0x%X : data : 0x%X : FF : 0x%X\n",addr,(vm_offset_t)vms->vm_daddr,(vm_offset_t)map->first_free->start);*/ + } + vm_map_unlock(map); + } + PROC_UNLOCK(td->td_proc); } if (flags & MAP_ANON) { --Boundary-00=_LuQGBy7Z7vDlpxv-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 18:07:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31BC016A4CE; Tue, 10 Aug 2004 18:07:10 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3E7C43D53; Tue, 10 Aug 2004 18:07:09 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-67-115-74-195.dsl.lsan03.pacbell.net [67.115.74.195]) i7AI7Ajx002736; Tue, 10 Aug 2004 14:07:12 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 928A1513CF; Tue, 10 Aug 2004 11:07:05 -0700 (PDT) Date: Tue, 10 Aug 2004 11:07:05 -0700 From: Kris Kennaway To: John Baldwin Message-ID: <20040810180705.GA53156@xor.obsecurity.org> References: <200408101137.11297.santtu.lintervo@kolumbus.fi> <200408101041.41263.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: <200408101041.41263.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@FreeBSD.org cc: santtu.lintervo@kolumbus.fi Subject: Re: INDEX file format X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 18:07:10 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 10, 2004 at 10:41:41AM -0400, John Baldwin wrote: > On Tuesday 10 August 2004 04:37 am, Santtu Lintervo wrote: > > hello, > > > > it seems that the INDEX file format has changed recently. > > where can i get the format of the file? >=20 > I think that build_depends was split up into 3 separate fields. You can= =20 > search the ports@ archive for a message about what the new fields are I= =20 > believe. Or check the code in /usr/ports/Makefile that pretty-prints it. Kris --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBGQ7JWry0BWjoQKURAqNxAKDLQkC2ZYRg+F+eO/fMAkYi03Gs/wCg/vvQ cvXaRP6/9ghFcjQ7WCzsGV8= =a1zF -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 18:30:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2D6216A4CF for ; Tue, 10 Aug 2004 18:30:27 +0000 (GMT) Received: from mediamonks.com (siripandita.mediamonks.net [62.192.127.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id D645243D39 for ; Tue, 10 Aug 2004 18:30:25 +0000 (GMT) (envelope-from root@mediamonks.net) Received: from manrikigusari [217.19.28.156] by mediamonks.com with ESMTP (SMTPD32-8.12) id A43AD03007E; Tue, 10 Aug 2004 20:30:18 +0200 From: "Terrence Koeman" To: Date: Tue, 10 Aug 2004 20:29:29 +0200 Organization: MediaMonks B.V. MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001E_01C47F18.BCC07A50" Thread-Index: AcR/B/kPitTkm1jOTEqaYJaAESbFNQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20040810203073.SM01804@manrikigusari> X-Info: This e-mail was scanned for spam and viruses by mail.mediamonks.net. X-Info: Please send abuse reports about this e-mail to abuse@mediamonks.net. Subject: Lock order reversal in 5.2-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: root@mediamonks.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 18:30:27 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C47F18.BCC07A50 Content-Type: multipart/mixed; boundary="----=_NextPart_001_001F_01C47F18.BCC07A50" ------=_NextPart_001_001F_01C47F18.BCC07A50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, In addition to my compiler not working, I've encountered another problem, the system just hung and dropped to the debugger on the serial port. There's nothing in the logfiles, the output on the serial console was: lock order reversal 1st 0xc0645aa0 sched lock (sched lock) @ /usr/src/sys/vm/vm_zeroidle.c:156 2nd 0xc06748c0 sio (sio) @ /usr/src/sys/dev/sio/sio.c:3039 KDB: stack backtrace: kdb_backtrace(c05fe96f,c06748c0,c0636660,c0636660,c060eede) at kdb_backtrace+0x2e witness_checkorder(c06748c0,9,c060eede,bdf,da7a) at witness_checkorder+0x6a6 _mtx_lock_spin_flags(c06748c0,0,c060eede,bdf,a) at _mtx_lock_spin_flags+0x8d siocnputc(c0636840,6b,5,d4dd7bf0,6b) at siocnputc+0x7a cnputc(6b,da7a,1,c15f39a0,c0611cff) at cnputc+0x6a putchar(6b,d4dd7bf0,c064ab40,0,c0686634) at putchar+0x5c kvprintf(c0611cfe,c04c9930,d4dd7bf0,a,d4dd7c10) at kvprintf+0x8d printf(c0611cfe,c,d4dd7c30,c04b2c9e,c0645aa0) at printf+0x55 trap(18,c0640010,10,c15f39a0,d4dd7cfc) at trap+0xc2 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc04b3ed2, esp = 0xd4dd7c90, ebp = 0xd4dd7ce0 --- mi_switch(1,0,c060d2be,9c,dbba0) at mi_switch+0x102 vm_pagezero(0,d4dd7d48,c05f8b5a,32b,e209f103) at vm_pagezero+0xe9 fork_exit(c059b140,0,d4dd7d48) at fork_exit+0xc7 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd4dd7d7c, ebp = 0 --- KDB: enter: witness_checkorder [thread 100051] Stopped at kdb_enter+0x30: leave db> This LOR is not on http://sources.zabbadoz.net/freebsd/lor.html, so I'm guessing this one locked up my system. I have ruled out broken hardware by swapping raid arrays with an identical working system earier because of my compiler problem (see my earlier mail on that). My dmesg and kernel config file are attached. Please advice. -- Regards, Terrence Koeman MediaMonks B.V. (www.mediamonks.com) Please quote all replies in correspondence. ------=_NextPart_001_001F_01C47F18.BCC07A50 Content-Type: application/octet-stream; name="dmesg.dhammapada" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.dhammapada" Copyright (c) 1992-2004 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 5.2-CURRENT #8: Thu Aug 5 14:04:45 CEST 2004 terrence@dhammapada.mediamonks.net:/usr/obj/usr/src/sys/DHAMMAPADA WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. WARNING: Kernel preemption is disabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 2.60GHz (2600.45-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf29 Stepping =3D 9 = Features=3D0xbfebfbff real memory =3D 528416768 (503 MB) avail memory =3D 511713280 (488 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [GIANT-LOCKED] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem = 0xec100000-0xec17ffff,0xe0000000-0xe7ffffff irq 5 at device 2.0 on pci0 agp0: detected 8060k stolen memory agp0: aperture size is 128M pcib1: at device 30.0 on pci0 pci1: on pcib1 atapci0: port = 0xa000-0xa00f,0x9c00-0x9c03,0x9800-0x9807,0x9400-0x9403,0x9000-0x9007 = mem 0xec040000-0xec04ffff irq 11 at device 0.0 on pci1 ata2: at 0x9000 on atapci0 ata3: at 0x9800 on atapci0 em0: port = 0xa400-0xa43f mem 0xec000000-0xec01ffff irq 10 at device 5.0 on pci1 em0: [GIANT-LOCKED] em0: Ethernet address: 00:30:48:42:96:0e em0: Speed:N/A Duplex:N/A em1: port = 0xa800-0xa83f mem 0xec020000-0xec03ffff irq 12 at device 6.0 on pci1 em1: [GIANT-LOCKED] em1: Ethernet address: 00:30:48:42:96:0f em1: Speed:N/A Duplex:N/A isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port = 0xcc00-0xcc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci1 ata1: at 0x170 irq 15 on atapci1 pci0: at device 31.3 (no driver attached) fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on = acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 orm0: at iomem 0xcc000-0xd57ff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 Timecounter "TSC" frequency 2600450072 Hz quality 800 Timecounters tick every 1.000 msec ipfw2 initialized, divert disabled, rule-based forwarding enabled, = default to accept, logging limited to 20 packets/entry by default ATAPI_RESET time =3D 320us acd0: CDROM at ata0-master UDMA33 ad4: 156334MB [317632/16/63] at ata2-master UDMA133 ad6: 156334MB [317632/16/63] at ata3-master UDMA133 ar0: 156334MB [19929/255/63] status: READY subdisks: disk0 READY on ad4 at ata2-master disk1 READY on ad6 at ata3-master Mounting root from ufs:/dev/ar0s1a em0: Link is up 100 Mbps Full Duplex Expensive timeout(9) function: 0xc05341e0(0) 0.008006324 s em1: Link is up 100 Mbps Full Duplex ------=_NextPart_001_001F_01C47F18.BCC07A50 Content-Type: application/octet-stream; name="DHAMMAPADA" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="DHAMMAPADA" machine i386 cpu I686_CPU ident DHAMMAPADA #To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" #Default places to look for = devices. #makeoptions DEBUG=3D-g #Build kernel with gdb(1) = debug symbols options SW_WATCHDOG options DIAGNOSTIC options SCHED_4BSD #4BSD scheduler #options SCHED_ULE # ULE scheduler options INET #InterNETworking options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_DIRHASH #Improve performance on big = directories options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires = PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP = THIS!] #options COMPAT_FREEBSD4 #Compatible with FreeBSD4 #options SCSI_DELAY=3D15000 #Delay (in ms) before probing = SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time = extensions #options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in = debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in = debug # output. Adds ~215k to driver. #options PFIL_HOOKS # pfil(9) framework #options QUOTA #options COMPAT_LINUX options DDB_UNATTENDED=20 options KDB options DDB # Enable the kernel debugger options WITNESS_KDB options KDB_TRACE options INVARIANTS # Enable calls of extra sanity = checking options INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS options WITNESS # Enable checks to detect = deadlocks and cycles #options WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed #options SMP # Symmetric MultiProcessor Kernel #device apic # I/O APIC options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=3D20 options IPFIREWALL_DEFAULT_TO_ACCEPT options HZ=3D3000 options DUMMYNET options RANDOM_IP_ID options CPU_ENABLE_SSE options CPU_FASTER_5X86_FPU options NO_F00F_HACK options ACCEPT_FILTER_HTTP #options ACCEPT_FILTER_DATA device isa #device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard #device psm # PS/2 mouse device vga # VGA video card driver #device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports #device ppbus #device ppc # parallel port # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit = Ethernet Card #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # Pseudo devices - the number indicates how many units to allocate. device random # Entropy device device loop # Network loopback device ether # Ethernet support device pty # Pseudo-ttys (telnet etc) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filte ------=_NextPart_001_001F_01C47F18.BCC07A50-- ------=_NextPart_000_001E_01C47F18.BCC07A50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKUzCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNmMIICz6ADAgECAhANi0/uqtIYW/R1ap0p4X/7MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4G0MIGxMBEGCWCGSAGG+EIBAQQEAwIB BjA1BgNVHR8ELjAsMCqgKKAmhiRodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLjEuMS5jcmww RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB AgUAA4GBAEJ8Dt+MeUysvwjsTVUvUImgxV5OLl6VMpt5rWURCxxKUsTVqDEhjt4Qm2wIxQfmA7nn yDR4CQnyvAZC+FqMg9GK3qoi9dnjIdLPZYwGM7DNILIzzQq9PuGdwTWpZLCnpSRb6fFo6xPEfDf0 lGQNmsW9MxfvgzOgPuWqPq7Ycx+tMIIEpDCCBA2gAwIBAgIQZx6EJ4oHSmQocGtEpogzPzANBgkq hkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wNDAyMDQw MDAwMDBaFw0wNTAyMDMyMzU5NTlaMIIBFjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0 IEZ1bGwgU2VydmljZTEYMBYGA1UEAxQPVGVycmVuY2UgS29lbWFuMSIwIAYJKoZIhvcNAQkBFhNy b290QG1lZGlhbW9ua3MubmV0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKUqZ0P8RUaCCe aemq1V8OtPimM3jxXZY6yuWtQz74POz82LhrkctttQoqujz5SubFWsQ15KsVnK4Nt+gTmtUELQVa I4uUebypbChhf1fxFerA7Rx8SYL4Ez9Fvco0tn89FRht6C/xoc/Ms/1YkQQcfnu2sqohx53S5Pm0 Ffo/ZQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcC AjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVm ZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDAGCmCG SAGG+EUBBgcEIhYgMWE5NjkyOTM3Y2MyOTFhMzZkZjAxN2Q4NDBjNDRiMTYwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOB gQAmpan0cUGODHHRIbkVFBHbTOumbMmEO3TR6d9z3LVO9cU5YDC/8BI9e5DZ7Kv43p/ldaGVo2ua ZwtvwL6o/iDcP8UDw+WmjSwzp6tck5cVRDEi+q9nCe3JAYBeRgSJlP5JGOirFpLuDTwL4UPdE0em p9ELBC+sXACm2C3u19hlKTGCBD4wggQ6AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3Qg VmFsaWRhdGVkAhBnHoQnigdKZChwa0SmiDM/MAkGBSsOAwIaBQCgggKyMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDgxMDE4MjkyOVowIwYJKoZIhvcNAQkEMRYE FJLw3mAUAkftqneRILtknUw+jKhuMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIa MAoGCCqGSIb3DQIFMIHyBgkrBgEEAYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNp Z24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5v dCBWYWxpZGF0ZWQCEGcehCeKB0pkKHBrRKaIMz8wgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBnHoQnigdKZChwa0SmiDM/MA0GCSqGSIb3 DQEBAQUABIGARMXYUGH0ShLKROXu2revI7qPPFbrcFg5XG5dNYfN7qAwDgF/2kOHPOU0aTZg3OrX hfAq6FgQxbuU0pIOYprN5XdGhMhx05VGaoXpn6v4zIhA0atcwpk6fCcGtDu2eqWZ+zqp9ivsyFpk 6VdadVPPJdHUb0IVbeaWtws/bEZLp9sAAAAAAAA= ------=_NextPart_000_001E_01C47F18.BCC07A50-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 18:35:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21C1816A4CE for ; Tue, 10 Aug 2004 18:35:05 +0000 (GMT) Received: from mediamonks.com (siripandita.mediamonks.net [62.192.127.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3754943D55 for ; Tue, 10 Aug 2004 18:35:04 +0000 (GMT) (envelope-from root@mediamonks.net) Received: from manrikigusari [217.19.28.156] by mediamonks.com with ESMTP (SMTPD32-8.12) id A55732800C6; Tue, 10 Aug 2004 20:35:03 +0200 From: "Terrence Koeman" To: "'Doug White'" Date: Tue, 10 Aug 2004 20:34:13 +0200 Organization: MediaMonks B.V. MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0026_01C47F19.66204F80" Thread-Index: AcR+/PdaMkQrNa/jTXGWjUti8MT/fQAC4JAg In-Reply-To: <20040810100612.Q88160@carver.gumbysoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <200408102035823.SM01804@manrikigusari> X-Info: This e-mail was scanned for spam and viruses by mail.mediamonks.net. X-Info: Please send abuse reports about this e-mail to abuse@mediamonks.net. cc: freebsd-current@freebsd.org Subject: RE: Compiler segmentation fault in 5-08 -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: root@mediamonks.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 18:35:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C47F19.66204F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-freebsd-current@freebsd.org > [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Doug White > Sent: Tuesday, August 10, 2004 19:09 > To: Terrence Koeman > Cc: freebsd-current@freebsd.org > Subject: RE: Compiler segmentation fault in 5-08 -CURRENT > > On Tue, 10 Aug 2004, Terrence Koeman wrote: > > > > Can you compile a simple "hello world" program? Sometimes > > > these types of > > > faults can be caused by faulty memory, processor, overclocking, or > > > temperature issues. > > > > It doesn't seem hardware related. Before the update I had > no problems with > > segmentation faults, and the system can take heavy load just fine. > > > > I tried to compile the following hello world program: > [...] > > helloworld.c:4: internal compiler error: Segmentation fault > > Ugh. Looks like your gcc binary's busted. > > > Is there perhaps a way to copy over the compiler from a > working (older) > > -CURRENT system and build a new world with it to see if > it's fixed in cvs? > > You might try tracking down a recent snapshot and do an > 'upgrade'; that > should overwrite your defective binary. > > This problem is unique to you so you may have had a disk error or > something that's zeroed out part of the gcc binary or cc1 or something > important like that. I have copied over /usr/bin/* from another working system and now I can compile things again. Is there anything that could create new problems when doing this? -- Regards, Terrence Koeman MediaMonks B.V. (www.mediamonks.com) Please quote all replies in correspondence. ------=_NextPart_000_0026_01C47F19.66204F80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKUzCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNmMIICz6ADAgECAhANi0/uqtIYW/R1ap0p4X/7MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4G0MIGxMBEGCWCGSAGG+EIBAQQEAwIB BjA1BgNVHR8ELjAsMCqgKKAmhiRodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLjEuMS5jcmww RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB AgUAA4GBAEJ8Dt+MeUysvwjsTVUvUImgxV5OLl6VMpt5rWURCxxKUsTVqDEhjt4Qm2wIxQfmA7nn yDR4CQnyvAZC+FqMg9GK3qoi9dnjIdLPZYwGM7DNILIzzQq9PuGdwTWpZLCnpSRb6fFo6xPEfDf0 lGQNmsW9MxfvgzOgPuWqPq7Ycx+tMIIEpDCCBA2gAwIBAgIQZx6EJ4oHSmQocGtEpogzPzANBgkq hkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wNDAyMDQw MDAwMDBaFw0wNTAyMDMyMzU5NTlaMIIBFjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0 IEZ1bGwgU2VydmljZTEYMBYGA1UEAxQPVGVycmVuY2UgS29lbWFuMSIwIAYJKoZIhvcNAQkBFhNy b290QG1lZGlhbW9ua3MubmV0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKUqZ0P8RUaCCe aemq1V8OtPimM3jxXZY6yuWtQz74POz82LhrkctttQoqujz5SubFWsQ15KsVnK4Nt+gTmtUELQVa I4uUebypbChhf1fxFerA7Rx8SYL4Ez9Fvco0tn89FRht6C/xoc/Ms/1YkQQcfnu2sqohx53S5Pm0 Ffo/ZQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcC AjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVm ZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDAGCmCG SAGG+EUBBgcEIhYgMWE5NjkyOTM3Y2MyOTFhMzZkZjAxN2Q4NDBjNDRiMTYwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOB gQAmpan0cUGODHHRIbkVFBHbTOumbMmEO3TR6d9z3LVO9cU5YDC/8BI9e5DZ7Kv43p/ldaGVo2ua ZwtvwL6o/iDcP8UDw+WmjSwzp6tck5cVRDEi+q9nCe3JAYBeRgSJlP5JGOirFpLuDTwL4UPdE0em p9ELBC+sXACm2C3u19hlKTGCBD4wggQ6AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3Qg VmFsaWRhdGVkAhBnHoQnigdKZChwa0SmiDM/MAkGBSsOAwIaBQCgggKyMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDgxMDE4MzQxM1owIwYJKoZIhvcNAQkEMRYE FPCqP9EoSwYdmhwbKw7ARcD15JfBMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIa MAoGCCqGSIb3DQIFMIHyBgkrBgEEAYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNp Z24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5v dCBWYWxpZGF0ZWQCEGcehCeKB0pkKHBrRKaIMz8wgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBnHoQnigdKZChwa0SmiDM/MA0GCSqGSIb3 DQEBAQUABIGAEu6v8efTjeyXm59lyf/y5FKnmyMKb6ioxca70D+bs1NL19zRwc2bpE1VTL5U65vP ZBmoKjiVdcGay/HNczQP8qAqXEWKPf3OzAI83P3BgSM1ncqkji6xGCMQbfrDodguc+4vmxxs0bNt /XOLQP9k53q2p665EN2pa3wstvZee1MAAAAAAAA= ------=_NextPart_000_0026_01C47F19.66204F80-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 18:45:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6060E16A4CE for ; Tue, 10 Aug 2004 18:45:13 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id B471A43D39 for ; Tue, 10 Aug 2004 18:45:12 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 130781FFDD8; Tue, 10 Aug 2004 20:45:11 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id F0BAC1FFDD6; Tue, 10 Aug 2004 20:45:08 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 735F415672; Tue, 10 Aug 2004 18:45:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 68BAB15665; Tue, 10 Aug 2004 18:45:04 +0000 (UTC) Date: Tue, 10 Aug 2004 18:45:04 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Terrence Koeman In-Reply-To: <20040810203073.SM01804@manrikigusari> Message-ID: References: <20040810203073.SM01804@manrikigusari> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: freebsd-current@freebsd.org Subject: Re: Lock order reversal in 5.2-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 18:45:13 -0000 On Tue, 10 Aug 2004, Terrence Koeman wrote: > There's nothing in the logfiles, the output on the serial console was: > > lock order reversal > 1st 0xc0645aa0 sched lock (sched lock) @ /usr/src/sys/vm/vm_zeroidle.c:156 > 2nd 0xc06748c0 sio (sio) @ /usr/src/sys/dev/sio/sio.c:3039 ... > This LOR is not on http://sources.zabbadoz.net/freebsd/lor.html, so I'm added with ID 020: http://sources.zabbadoz.net/freebsd/lor.html#020 -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 18:53:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02B2D16A4D7 for ; Tue, 10 Aug 2004 18:53:16 +0000 (GMT) Received: from pd3mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D343543D5F for ; Tue, 10 Aug 2004 18:53:15 +0000 (GMT) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from pd5mr1so.prod.shaw.ca (pd5mr1so-qfe3.prod.shaw.ca [10.0.141.232]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0I2800CBZURZL4@l-daemon> for freebsd-current@freebsd.org; Tue, 10 Aug 2004 12:45:35 -0600 (MDT) Received: from pn2ml4so.prod.shaw.ca ([10.0.121.148]) by pd5mr1so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I280010GURTJYJ0@pd5mr1so.prod.shaw.ca> for freebsd-current@freebsd.org; Tue, 10 Aug 2004 12:45:29 -0600 (MDT) Received: from piii600.wadham.ox.ac.uk (S0106006067227a4a.vc.shawcable.net [24.87.233.42]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0I280020HURSL9@l-daemon> for freebsd-current@freebsd.org; Tue, 10 Aug 2004 12:45:29 -0600 (MDT) Date: Tue, 10 Aug 2004 11:45:09 -0700 From: Colin Percival In-reply-to: <20040810203073.SM01804@manrikigusari> X-Sender: cperciva@popserver.sfu.ca (Unverified) To: root@mediamonks.net Message-id: <6.1.0.6.1.20040810114002.03ef96c8@popserver.sfu.ca> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Content-type: text/plain; charset=us-ascii References: <20040810203073.SM01804@manrikigusari> cc: freebsd-current@freebsd.org Subject: Re: Lock order reversal in 5.2-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 18:53:16 -0000 At 11:29 10/08/2004, Terrence Koeman wrote: >lock order reversal > 1st 0xc0645aa0 sched lock (sched lock) @ /usr/src/sys/vm/vm_zeroidle.c:156 > 2nd 0xc06748c0 sio (sio) @ /usr/src/sys/dev/sio/sio.c:3039 > >This LOR is not on http://sources.zabbadoz.net/freebsd/lor.html, so I'm >guessing this one locked up my system. This is LOR #013 on bzeeb's list. There isn't any solution yet, but there is a simple workaround: unplug the serial console. Colin Percival From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 18:55:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFB0216A4E2 for ; Tue, 10 Aug 2004 18:55:17 +0000 (GMT) Received: from huva.hittite.isp.9tel.net (huva.hittite.isp.9tel.net [62.62.156.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B81B43D45 for ; Tue, 10 Aug 2004 18:55:17 +0000 (GMT) (envelope-from martin.mato@wanadoo.fr) Received: from [192.168.0.2] (unknown [84.98.32.235]) by huva.hittite.isp.9tel.net (Postfix) with ESMTP id 44DFC14B5A8 for ; Tue, 10 Aug 2004 21:04:54 +0200 (CEST) Message-ID: <41191A10.7000104@wanadoo.fr> Date: Tue, 10 Aug 2004 20:55:12 +0200 From: Martin MATO User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: fr, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: [Fwd: Re: ACPI autoload failed: no such file or directory] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: martin.mato@wanadoo.fr List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 18:55:17 -0000 -------- Message original -------- From: - Tue Aug 10 20:48:55 2004 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00800000 Message-ID: <41191895.7040401@wanadoo.fr> Date: Tue, 10 Aug 2004 20:48:53 +0200 From: Martin MATO Reply-To: martin.mato@wanadoo.fr User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: fr, en MIME-Version: 1.0 To: Roland Dittel Subject: Re: ACPI autoload failed: no such file or directory References: <41183662.4010802@wanadoo.fr> <20040810050907.GL991@funkthat.com> <41185F7F.8070906@wanadoo.fr> <4118D144.2030401@wanadoo.fr> <4118E438.5050606@wanadoo.fr> <364F6440-EAF6-11D8-8115-0003937B7386@web.de> In-Reply-To: <364F6440-EAF6-11D8-8115-0003937B7386@web.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Roland Dittel a écrit : > Hi > >> well, i tried now some kload "modules.ko" NONE worked (no such >> files or directory) kldload doesn't seems to find them >> i checked the modules path; and i added - again- >> module_path="/boot/kernel /boot/modules" in /boot/loader.conf > > > I've got the same message since yesterday. You have to set the > module_path to "/boot/kernel;/boot/modules" not "/boot/kernel > /boot/modules" > >> >> after reboot and the same ACPI autoload error message, >> kldload doesn't find again none of the modules i tried to load (i >> tried a lot of them)! >> the module path in the sysctl variable is effectively set to >> "/boot/kernel /boot/modules" >> >> with a >> cp /boot/kernel/*.ko /boot/modules kldload find finally the modules >> files; EXCEPT acpi.ko. i repeat I KNOW that acpi.ko can't be loaded >> from userland, i 'm only seeing if kldload find the file(s) specified. >> >> well i think i have a big problem here... :°( >> >> _______________________________________________ >> 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" > > > Ok, it 's work finally... all this things for a ";" :°( one question (maybe stupid) why do not include the default path in /boot/defaults/loader.conf ? that would avoid surprises one day, in a morning compilation ;) thanks for all , everyone . From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 19:05:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CE2916A4CE; Tue, 10 Aug 2004 19:05:20 +0000 (GMT) Received: from avscan2.sentex.ca (avscan2.sentex.ca [199.212.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35CAC43D2F; Tue, 10 Aug 2004 19:05:20 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7AJ5JjQ076025; Tue, 10 Aug 2004 15:05:19 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan2.sentex.ca ([127.0.0.1]) by localhost (avscan2.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 75442-06; Tue, 10 Aug 2004 15:05:19 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7AJ5JZI076002; Tue, 10 Aug 2004 15:05:19 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i7AJ5BbO074466; Tue, 10 Aug 2004 15:05:12 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.1.2.0.0.20040810150715.093753a0@64.7.153.2> X-Sender: mdtpop@64.7.153.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 10 Aug 2004 15:09:15 -0400 To: Mark Murray From: Mike Tancsa In-Reply-To: <200408091814.i79IEjjv009798@grimreaper.grondar.org> References: <200408091814.i79IEjjv009798@grimreaper.grondar.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan2b cc: freebsd-current@freebsd.org Subject: Re: VIA C3 AES code ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 19:05:20 -0000 At 02:14 PM 09/08/2004, Mark Murray wrote: >Mike Tancsa writes: > > Neato! Is this more than just the HRNG support ? ie will there be support > > for crypto offloading in OpenSSL or more ? How far along are you in it ? > >Yup. It means that if you ask OpenSSL for AES encryptionon a C3 Nehemiah, >you get the full HW speed. It looks like OpenSSL has this recently committed into their tree http://marc.theaimsgroup.com/?l=openssl-cvs&m=109148330200378&w=2 which came from http://www.logix.cz/michal/devel/padlock/ ---Mike From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 19:08:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 704D116A4CE for ; Tue, 10 Aug 2004 19:08:50 +0000 (GMT) Received: from omail9.walla.co.il (omail9.walla.co.il [192.118.71.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6820343D48 for ; Tue, 10 Aug 2004 19:08:49 +0000 (GMT) (envelope-from ianchov@walla.com) Date: Tue, 10 Aug 2004 22:06:56 +0300 Received: from ([213.240.192.49]) by omail9.walla.co.il ([192.118.71.129]) with HTTP; Tue, 10 Aug 2004 22:06:43 +0300 From: =?utf-8?Q?=49=61=6E=74=63=68=6F=20=56=61=73=73=69=6C=65=76?= X-Sender: ianchov@walla.com X-Originating-Email: [ianchov@walla.com] X-Originating-IP: [213.240.192.49] To: Message-Id: <1092164803.282000-39789820-29345@walla.com> Content-Type: multipart/mixed; boundary="------=_EREZ_P_WallaMail_49710_8207_P_0" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: if_vr.c:506 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 19:08:50 -0000 --------=_EREZ_P_WallaMail_49710_8207_P_0 Content-Transfer-Encoding: base64 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" DQo8Qk9EWSBvbmNvbnRleHRtZW51PSJyZXR1cm4gZmFsc2UiIGRpcj1sdHIg c3R5bGU9Ik9WRVJGTE9XLVk6IHNjcm9sbCIgbGVmdE1hcmdpbj0wIHRvcE1h cmdpbj0wIHJpZ2h0TWFyZ2luPTA+PERJViBpZD13cnRlcGxhY2Vob2xkZXIg c3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgbmFtZT0id3J0ZXBsYWNlaG9s ZGVyIj4NCjxESVY+PEJSPjxCUj48QlI+SEkhIHRvIEFsbDxCUj5JYG0gcGxl YXNlIGkgY2FuIHdyaXRlIGluIHRhaCBsaXN0LjxCUj48QlI+PEJSPlNvIHll c3RlcmRheSBpIGN2c3VwLW15IHNvdXJjZSBhbmQgcmVidWlsZGVkLjxCUj48 QlI+PEJSPkZpcnN0IGkgZGlkIEJVSUxEV09STEQuPEJSPnRoZW4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgQlVJTERLRVJORUw8QlI+dGhlbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJTlNUQUxM S0VSTkVMPEJSPnRoZW4mbmJzcDsmbmJzcDsmbmJzcDsgYm9vdC1lZCBpbnRv IHNpbmdsZTxCUj50aGVuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IG1lcmdlbWFzdGVyIC1wPEJSPnRoZW4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5zdGFsbHdvcmxkIC0gdGhlcmUgd2Vy ZSBzb21lIGVycm9ycyBhYm91dCBzb21lIG1hbi5nejxCUj48QlI+YnV0IHRo YXRgcyBub3QgdGhlIHF1ZXN0aW9uPEJSPjxCUj48QlI+QWZ0ZXIgYm9vdGlu ZyBpIGhhZCB0aGUmbmJzcDtmb2xsb3dpbmcgZXJyb3I6PEJSPjxCUj5wYW5p YzpfbXR4X2xvY2suc2xlZXAgcmVjdXJzZWQgb24gbm9uLXJlY3Vyc2l2ZSBt dXRleCB2cjBAL3Vzci9zcmMvc3lzL3BjaS9pZl92cjAuYzo1MDY8QlI+PEJS PmFuZCB0aGUgYm9vdGluZyBwcm9jZXNzIHdlbnQgdG8ga2VybmVsIGRlYnVn Z2VyPEJSPklgbSB3aXRoIFZpYVJoaW5lIE1vZGVsIEV0aGVybmV0Li48QlI+ b25seSBhZnRlciBhZGRpbmcgPEJSPm5ldHdvcmtfaW50ZXJmYWNlcz0iICIg dG8gcmMuY29uZiBtYWRlIHRvIGJvb3QgY29ycmVjdGx5PEJSPjxCUj5wLnMu PEJSPm5vIHNwZWNpYWwgb3B0aW9ucyB3aGlsZSBjb21waWxlIC0gcGVudGl1 bTMmbmJzcDs8QlI+SSZuYnNwOyA8QlI+PEJSPjwvRElWPjwvRElWPjwvQk9E WT48aHI+PGRpdiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjp3aGl0ZTtjb2xv cjpibGFjazsiPldhbGxhISBNYWlsIC0gPGEgaHJlZj0iaHR0cDovL3d3dy53 YWxsYS5jb20iIHN0eWxlPSJjb2xvcjpibHVlIj5nZXQgeW91ciBmcmVlIDFH IG1haWwgdG9kYXk8L2E+PC9kaXY+AA== --------=_EREZ_P_WallaMail_49710_8207_P_0-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 19:38:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBC2816A4CE for ; Tue, 10 Aug 2004 19:38:33 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC35643D2F for ; Tue, 10 Aug 2004 19:38:33 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 26588 invoked from network); 10 Aug 2004 19:38:33 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 10 Aug 2004 19:38:32 -0000 Received: from 10.50.40.208 (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i7AJcOip085369; Tue, 10 Aug 2004 15:38:26 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Tue, 10 Aug 2004 15:35:11 -0400 User-Agent: KMail/1.6 References: <20040810203073.SM01804@manrikigusari> <6.1.0.6.1.20040810114002.03ef96c8@popserver.sfu.ca> In-Reply-To: <6.1.0.6.1.20040810114002.03ef96c8@popserver.sfu.ca> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408101535.11863.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: root@mediamonks.net cc: Colin Percival Subject: Re: Lock order reversal in 5.2-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 19:38:34 -0000 On Tuesday 10 August 2004 02:45 pm, Colin Percival wrote: > At 11:29 10/08/2004, Terrence Koeman wrote: > >lock order reversal > > 1st 0xc0645aa0 sched lock (sched lock) @ > > /usr/src/sys/vm/vm_zeroidle.c:156 2nd 0xc06748c0 sio (sio) @ > > /usr/src/sys/dev/sio/sio.c:3039 > > > >This LOR is not on http://sources.zabbadoz.net/freebsd/lor.html, so I'm > >guessing this one locked up my system. > > This is LOR #013 on bzeeb's list. There isn't any solution yet, but there > is a simple workaround: unplug the serial console. The real problem is that mi_switch panic'd: calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc04b3ed2, esp = 0xd4dd7c90, ebp = 0xd4dd7ce0 --- mi_switch(1,0,c060d2be,9c,dbba0) at mi_switch+0x102 Does the original poster have a debug kernel built? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 19:41:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B488216A4CE; Tue, 10 Aug 2004 19:41:29 +0000 (GMT) Received: from mediamonks.com (siripandita.mediamonks.net [62.192.127.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2034243D55; Tue, 10 Aug 2004 19:41:28 +0000 (GMT) (envelope-from root@mediamonks.net) Received: from manrikigusari [217.19.28.156] by mediamonks.com with ESMTP (SMTPD32-8.12) id A4E23FB00A8; Tue, 10 Aug 2004 21:41:22 +0200 From: "Terrence Koeman" To: "'John Baldwin'" , Date: Tue, 10 Aug 2004 21:40:22 +0200 Organization: MediaMonks B.V. MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcR/EaFEbu5N8FB9TsORK1thGtLSRAAAB+KA Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0047_01C47F22.A36B9990" In-Reply-To: <200408101535.11863.jhb@FreeBSD.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <200408102141323.SM01804@manrikigusari> X-Info: This e-mail was scanned for spam and viruses by mail.mediamonks.net. X-Info: Please send abuse reports about this e-mail to abuse@mediamonks.net. Subject: RE: Lock order reversal in 5.2-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: root@mediamonks.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 19:41:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C47F22.A36B9990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: John Baldwin [mailto:jhb@FreeBSD.org] > Sent: Tuesday, August 10, 2004 21:35 > To: freebsd-current@FreeBSD.org > Cc: Colin Percival; root@mediamonks.net > Subject: Re: Lock order reversal in 5.2-CURRENT > > On Tuesday 10 August 2004 02:45 pm, Colin Percival wrote: > > At 11:29 10/08/2004, Terrence Koeman wrote: > > >lock order reversal > > > 1st 0xc0645aa0 sched lock (sched lock) @ > > > /usr/src/sys/vm/vm_zeroidle.c:156 2nd 0xc06748c0 sio (sio) @ > > > /usr/src/sys/dev/sio/sio.c:3039 > > > > > >This LOR is not on > http://sources.zabbadoz.net/freebsd/lor.html, so I'm > > >guessing this one locked up my system. > > > > This is LOR #013 on bzeeb's list. There isn't any solution > yet, but there > > is a simple workaround: unplug the serial console. > > The real problem is that mi_switch panic'd: > > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc04b3ed2, esp = 0xd4dd7c90, ebp = 0xd4dd7ce0 --- > mi_switch(1,0,c060d2be,9c,dbba0) at mi_switch+0x102 > > Does the original poster have a debug kernel built? > Yes I have, but I have no experience with the debugger. I'll be happy to carry out whatever's needed. -- Regards, Terrence Koeman MediaMonks B.V. (www.mediamonks.com) Please quote all replies in correspondence. ------=_NextPart_000_0047_01C47F22.A36B9990 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKUzCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNmMIICz6ADAgECAhANi0/uqtIYW/R1ap0p4X/7MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4G0MIGxMBEGCWCGSAGG+EIBAQQEAwIB BjA1BgNVHR8ELjAsMCqgKKAmhiRodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLjEuMS5jcmww RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB AgUAA4GBAEJ8Dt+MeUysvwjsTVUvUImgxV5OLl6VMpt5rWURCxxKUsTVqDEhjt4Qm2wIxQfmA7nn yDR4CQnyvAZC+FqMg9GK3qoi9dnjIdLPZYwGM7DNILIzzQq9PuGdwTWpZLCnpSRb6fFo6xPEfDf0 lGQNmsW9MxfvgzOgPuWqPq7Ycx+tMIIEpDCCBA2gAwIBAgIQZx6EJ4oHSmQocGtEpogzPzANBgkq hkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wNDAyMDQw MDAwMDBaFw0wNTAyMDMyMzU5NTlaMIIBFjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0 IEZ1bGwgU2VydmljZTEYMBYGA1UEAxQPVGVycmVuY2UgS29lbWFuMSIwIAYJKoZIhvcNAQkBFhNy b290QG1lZGlhbW9ua3MubmV0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKUqZ0P8RUaCCe aemq1V8OtPimM3jxXZY6yuWtQz74POz82LhrkctttQoqujz5SubFWsQ15KsVnK4Nt+gTmtUELQVa I4uUebypbChhf1fxFerA7Rx8SYL4Ez9Fvco0tn89FRht6C/xoc/Ms/1YkQQcfnu2sqohx53S5Pm0 Ffo/ZQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcC AjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVm ZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDAGCmCG SAGG+EUBBgcEIhYgMWE5NjkyOTM3Y2MyOTFhMzZkZjAxN2Q4NDBjNDRiMTYwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOB gQAmpan0cUGODHHRIbkVFBHbTOumbMmEO3TR6d9z3LVO9cU5YDC/8BI9e5DZ7Kv43p/ldaGVo2ua ZwtvwL6o/iDcP8UDw+WmjSwzp6tck5cVRDEi+q9nCe3JAYBeRgSJlP5JGOirFpLuDTwL4UPdE0em p9ELBC+sXACm2C3u19hlKTGCBD4wggQ6AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3Qg VmFsaWRhdGVkAhBnHoQnigdKZChwa0SmiDM/MAkGBSsOAwIaBQCgggKyMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDgxMDE5NDAyMlowIwYJKoZIhvcNAQkEMRYE FBXJuq1Dmh+HH7DJy+m9Pf/rOX93MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIa MAoGCCqGSIb3DQIFMIHyBgkrBgEEAYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNp Z24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5v dCBWYWxpZGF0ZWQCEGcehCeKB0pkKHBrRKaIMz8wgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBnHoQnigdKZChwa0SmiDM/MA0GCSqGSIb3 DQEBAQUABIGAHvFYe7Seb43IGzCBLrWVKSeXTAbSVJ/Tqzg+iCbCmNud/39Z+CgXtwgFiSY/39Lq a+z3DFJy9ymIT8Ru/hQmfi8w+PkGpvSKc06NWrVGuUIfhU5uwbo7SsjbmROxnYsht4aboxxbMsBy Wk+oq22nYQyurzd5+6uiVein8Ln3oZQAAAAAAAA= ------=_NextPart_000_0047_01C47F22.A36B9990-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 20:15:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC34716A4CE; Tue, 10 Aug 2004 20:15:34 +0000 (GMT) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 160EC43D39; Tue, 10 Aug 2004 20:15:34 +0000 (GMT) (envelope-from langd@informatik.tu-muenchen.de) Date: Tue, 10 Aug 2004 22:15:32 +0200 From: Daniel Lang To: Terrence Koeman Message-ID: <20040810201532.GA53289@atrbg11.informatik.tu-muenchen.de> References: <200408101535.11863.jhb@FreeBSD.org> <200408102141323.SM01804@manrikigusari> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408102141323.SM01804@manrikigusari> X-Geek: GCS/CC d-- s: a- C++$ UBS++++$ P+++$ L- E-(---) W+++(--) N++ o K w--- O? M? V? PS+(++) PE--(+) Y+ PGP+ t++ 5+++ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r+++ y+ User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new/sophie/sophos at mailrelay1.informatik.tu-muenchen.de cc: freebsd-current@FreeBSD.org cc: 'John Baldwin' Subject: Re: Lock order reversal in 5.2-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 20:15:35 -0000 Hi Terrence, Terrence Koeman wrote on Tue, Aug 10, 2004 at 09:40:22PM +0200: [..] > > --- trap 0xc, eip = 0xc04b3ed2, esp = 0xd4dd7c90, ebp = 0xd4dd7ce0 --- > > mi_switch(1,0,c060d2be,9c,dbba0) at mi_switch+0x102 > > > > Does the original poster have a debug kernel built? > > > > Yes I have, but I have no experience with the debugger. I'll be happy to > carry out whatever's needed. [..] The process is documented in the developers handbook: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html In short: - first make sure dumpdevice is set and savecore enabled in /etc/rc.conf - after a panic get a crash-dump, e.g. in ddb enter "call doadump()" - after reboot the dump should be saved to e.g. /var/crash/vmcore.0 - analyse the dump with kernel-gdb: gdb -k /usr/obj/usr/src/sys//kernel.debug /var/crash/vmcore.0 (IIRC), so this is where the debug kernel is required. Please not that stock gdb is currently not able to act as kernel-debugger, you need to install the gdb6 port. - Start with a backtrace (bt) of the kernel, look out for corrupted data. Obvious things are 0x0 pointers, where valid data is expected. If spotted, try to trace the source of corruption. - Post any of your discoveries. Often just the stack-trace with function, arguments and source-lines can give valuable hints to the developers. HTH, Daniel -- IRCnet: Mr-Spock - Agartim billiard bumba m'abdul in papejim twista - rumba rock n rolla. Leik'ab mai. Spirzon Heroin se'osit gaula. - - Marijuana esit gaula. Haschisch. Opis. - Daniel Lang * dl@leo.org * +49 89 2600 8122 * http://www.leo.org/~dl/ From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 20:16:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A442A16A4CE for ; Tue, 10 Aug 2004 20:16:14 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 575DA43D31 for ; Tue, 10 Aug 2004 20:16:14 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 15580 invoked from network); 10 Aug 2004 20:16:14 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 10 Aug 2004 20:16:13 -0000 Received: from 10.50.40.208 (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i7AKG9Xg085610; Tue, 10 Aug 2004 16:16:10 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org, root@mediamonks.net Date: Tue, 10 Aug 2004 15:59:19 -0400 User-Agent: KMail/1.6 References: <200408102141323.SM01804@manrikigusari> In-Reply-To: <200408102141323.SM01804@manrikigusari> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408101559.19800.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx Subject: Re: Lock order reversal in 5.2-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 20:16:14 -0000 On Tuesday 10 August 2004 03:40 pm, Terrence Koeman wrote: > > -----Original Message----- > > From: John Baldwin [mailto:jhb@FreeBSD.org] > > Sent: Tuesday, August 10, 2004 21:35 > > To: freebsd-current@FreeBSD.org > > Cc: Colin Percival; root@mediamonks.net > > Subject: Re: Lock order reversal in 5.2-CURRENT > > > > On Tuesday 10 August 2004 02:45 pm, Colin Percival wrote: > > > At 11:29 10/08/2004, Terrence Koeman wrote: > > > >lock order reversal > > > > 1st 0xc0645aa0 sched lock (sched lock) @ > > > > /usr/src/sys/vm/vm_zeroidle.c:156 2nd 0xc06748c0 sio (sio) @ > > > > /usr/src/sys/dev/sio/sio.c:3039 > > > > > > > >This LOR is not on > > > > http://sources.zabbadoz.net/freebsd/lor.html, so I'm > > > > > >guessing this one locked up my system. > > > > > > This is LOR #013 on bzeeb's list. There isn't any solution > > > > yet, but there > > > > > is a simple workaround: unplug the serial console. > > > > The real problem is that mi_switch panic'd: > > > > calltrap() at calltrap+0x5 > > --- trap 0xc, eip = 0xc04b3ed2, esp = 0xd4dd7c90, ebp = 0xd4dd7ce0 --- > > mi_switch(1,0,c060d2be,9c,dbba0) at mi_switch+0x102 > > > > Does the original poster have a debug kernel built? > > Yes I have, but I have no experience with the debugger. I'll be happy to > carry out whatever's needed. Just pull up gdb on the kernel.debug file in the kernel build directory and do 'l *0xc04b3ed2' (the value is the eip from above) to list the source line associated with the fault. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 20:35:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 629F116A4CE; Tue, 10 Aug 2004 20:35:13 +0000 (GMT) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC27D43D49; Tue, 10 Aug 2004 20:35:12 +0000 (GMT) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) i7AKZBg2048503; Tue, 10 Aug 2004 21:35:11 +0100 (BST) (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost)i7AKZBcV048502; Tue, 10 Aug 2004 21:35:11 +0100 (BST) (envelope-from mark@grondar.org) X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1])i7AKWEBx022659; Tue, 10 Aug 2004 21:32:14 +0100 (BST) (envelope-from mark@grondar.org) Message-Id: <200408102032.i7AKWEBx022659@grimreaper.grondar.org> To: Mike Tancsa From: Mark Murray In-Reply-To: Your message of "Tue, 10 Aug 2004 15:09:15 EDT." <6.1.2.0.0.20040810150715.093753a0@64.7.153.2> Date: Tue, 10 Aug 2004 21:32:14 +0100 Sender: mark@grondar.org cc: freebsd-current@FreeBSD.ORG cc: Mark Murray Subject: Re: VIA C3 AES code ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 20:35:13 -0000 Mike Tancsa writes: > At 02:14 PM 09/08/2004, Mark Murray wrote: > >Mike Tancsa writes: > > > Neato! Is this more than just the HRNG support ? ie will there be support > > > for crypto offloading in OpenSSL or more ? How far along are you in it ? > > > >Yup. It means that if you ask OpenSSL for AES encryptionon a C3 Nehemiah, > >you get the full HW speed. > > It looks like OpenSSL has this recently committed into their tree > > http://marc.theaimsgroup.com/?l=openssl-cvs&m=109148330200378&w=2 > which came from > http://www.logix.cz/michal/devel/padlock/ Yeah. I'm watching OpenSSL with interest. M -- Mark Murray iumop ap!sdn w,I idlaH From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 20:38:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9169516A4CE for ; Tue, 10 Aug 2004 20:38:18 +0000 (GMT) Received: from ddardaar.mine.nu (bwc72.neoplus.adsl.tpnet.pl [83.29.226.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19FAC43D1F for ; Tue, 10 Aug 2004 20:38:16 +0000 (GMT) (envelope-from radek@raadradd.com) Received: by ddardaar.mine.nu (Postfix, from userid 1001) id 893B5A58C; Tue, 10 Aug 2004 22:38:22 +0200 (CEST) Date: Tue, 10 Aug 2004 22:38:22 +0200 From: Radek Kozlowski To: Nate Lawson Message-ID: <20040810203822.GB28585@werd> References: <4113EB2A.7060401@root.org> <20040806221109.GC55186@werd> <411406AA.3030607@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <411406AA.3030607@root.org> User-Agent: Mutt/1.5.6i cc: current@freebsd.org cc: sos@deepcore.dk Subject: Re: Panic on boot with today's CURRENT, ata related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 20:38:18 -0000 On Fri, Aug 06, 2004 at 03:31:06PM -0700, Nate Lawson wrote: > It looks like the DMA object for the channel is not being initialized. > However, that is in another path (this backtrace is just a symptom > triggered by the first DMA access to the drive). Someone who knows more > about the control path for going from PIO -> DMA mode will have to look > into this. I would like to stress that it only happens with ACPI enabled. If I boot with ACPI disabled the transfer mode is set to UDMA100. Shall I provide you with more info? Thanks, -Radek From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 20:40:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 085A816A4CE for ; Tue, 10 Aug 2004 20:40:09 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72A9843D45 for ; Tue, 10 Aug 2004 20:40:08 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id D73971FF91D; Tue, 10 Aug 2004 22:40:06 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id F02921FFDD7; Tue, 10 Aug 2004 22:40:04 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 7F47015665; Tue, 10 Aug 2004 20:36:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 7C93A15329; Tue, 10 Aug 2004 20:36:19 +0000 (UTC) Date: Tue, 10 Aug 2004 20:36:19 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Colin Percival In-Reply-To: <6.1.0.6.1.20040810114002.03ef96c8@popserver.sfu.ca> Message-ID: References: <20040810203073.SM01804@manrikigusari> <6.1.0.6.1.20040810114002.03ef96c8@popserver.sfu.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: freebsd-current@freebsd.org Subject: Re: Lock order reversal in 5.2-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 20:40:09 -0000 On Tue, 10 Aug 2004, Colin Percival wrote: > At 11:29 10/08/2004, Terrence Koeman wrote: > >lock order reversal > > 1st 0xc0645aa0 sched lock (sched lock) @ /usr/src/sys/vm/vm_zeroidle.c:156 > > 2nd 0xc06748c0 sio (sio) @ /usr/src/sys/dev/sio/sio.c:3039 > > > >This LOR is not on http://sources.zabbadoz.net/freebsd/lor.html, so I'm > >guessing this one locked up my system. > > This is LOR #013 on bzeeb's list. There isn't any solution yet, but there is > a simple workaround: unplug the serial console. is it fully the same ? At least it happens in two places then or did functions get moved ? If so then I will merge 020 into 013 ? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 20:43:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C65AD16A4CE for ; Tue, 10 Aug 2004 20:43:45 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AD4143D3F for ; Tue, 10 Aug 2004 20:43:45 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7AKhT8U004203; Tue, 10 Aug 2004 13:43:32 -0700 Message-ID: <41193370.3020302@root.org> Date: Tue, 10 Aug 2004 13:43:28 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Radek Kozlowski References: <4113EB2A.7060401@root.org> <20040806221109.GC55186@werd> <411406AA.3030607@root.org> <20040810203822.GB28585@werd> In-Reply-To: <20040810203822.GB28585@werd> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org cc: sos@deepcore.dk Subject: Re: Panic on boot with today's CURRENT, ata related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 20:43:45 -0000 Radek Kozlowski wrote: > On Fri, Aug 06, 2004 at 03:31:06PM -0700, Nate Lawson wrote: > >>It looks like the DMA object for the channel is not being initialized. >>However, that is in another path (this backtrace is just a symptom >>triggered by the first DMA access to the drive). Someone who knows more >>about the control path for going from PIO -> DMA mode will have to look >>into this. > > I would like to stress that it only happens with ACPI enabled. If I boot > with ACPI disabled the transfer mode is set to UDMA100. Shall I provide > you with more info? I'm done debugging ATA for now. I spent 8 hours tracking down the first bug (not counting the time lost tracking down a non-existent routing table bug triggered by the ATA bug) and 15 minutes on the second one. ACPI does not affect ATA other than setting up IO ports and IRQs. I have no idea what can cause ATA to use PIO over UDMA. -- Nate From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 20:50:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87A3E16A5B7 for ; Tue, 10 Aug 2004 20:50:07 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62ABA43D58 for ; Tue, 10 Aug 2004 20:50:07 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 5777 invoked from network); 10 Aug 2004 20:50:07 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail2.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Aug 2004 20:50:07 -0000 Received: from hydrogen.funkthat.com (yburah@localhost.funkthat.com [127.0.0.1])i7AKo6uU083800; Tue, 10 Aug 2004 13:50:06 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i7AKo67D083799; Tue, 10 Aug 2004 13:50:06 -0700 (PDT) Date: Tue, 10 Aug 2004 13:50:06 -0700 From: John-Mark Gurney To: Martin MATO Message-ID: <20040810205006.GR991@funkthat.com> Mail-Followup-To: Martin MATO , freebsd-current@freebsd.org References: <41191A10.7000104@wanadoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <41191A10.7000104@wanadoo.fr> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-current@freebsd.org Subject: Re: [Fwd: Re: ACPI autoload failed: no such file or directory] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 20:50:08 -0000 Martin MATO wrote this message on Tue, Aug 10, 2004 at 20:55 +0200: > Ok, it 's work finally... all this things for a ";" :°( > one question (maybe stupid) why do not include the default path in > /boot/defaults/loader.conf ? > that would avoid surprises one day, in a morning compilation ;) Well, because another mechanism in the loader process is suppose to do that for you automaticly.. It works over here, and there is no way you should be able to boot kernel.old w/ kernel.old modules if that mechanism fails to add the kernel path to the module path... hence, on the systems it's failing, there is another issue... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 20:54:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA57F16A4CE; Tue, 10 Aug 2004 20:54:37 +0000 (GMT) Received: from ctb-mesg4.saix.net (ctb-mesg4.saix.net [196.25.240.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7E6343D1F; Tue, 10 Aug 2004 20:54:36 +0000 (GMT) (envelope-from marc@bowtie.nl) Received: from [192.168.0.104] (tbnb-97-84.telkomadsl.co.za [165.165.97.84]) by ctb-mesg4.saix.net (Postfix) with ESMTP id EA38BAD6C; Tue, 10 Aug 2004 22:54:33 +0200 (SAST) From: Marc van Kempen To: freebsd-current@freebsd.org Date: Tue, 10 Aug 2004 22:54:32 +0200 User-Agent: KMail/1.6.2 References: <20040805071236.GA595@loge.nixsys.be> In-Reply-To: <20040805071236.GA595@loge.nixsys.be> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408102254.32722.marc@bowtie.nl> Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 20:54:37 -0000 On Thursday 05 August 2004 09:12, Philip Paeps wrote: > Hi gang :-) > > Since the original synaptics support was added to psm, there have been some > reports of malfunctions and missing magic. I've tried to fix all that, but > it's still work in progress. > > If you happen to own a laptop with a synaptics touchpad, please help test: > > > > So far, I've had one report of a panic, possibly related to an extra gadget > chained through the the touchpad. If you're extra masochistic, and your > laptop has one of these extra gadgets, you might like to remove the #if 0 > around line 2537 and the #endif around line 2568 of your sys/isa/psm.c. > > Please report successes and failures :-) > > - Philip Hi Philip, Just found out about your changes because of my stick not working anymore after upgrading my kernel sources today. I've got an IBM Thinkpad R40 with both a touchpad and a stick. With the default settings the whole stick part (including the stick buttons) was not working. The touchpad was working to some extent, but tapping (both single and double) didn't work either. I've changed the hints.psm.0.flags to "0x6400" which recognizes it just as a default ps/2 mouse, and then everything works (as it always did) including single and double tapping. If you need extra info let me know. Regards, Marc. From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 20:56:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E036C16A4CF for ; Tue, 10 Aug 2004 20:56:53 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3743543D39 for ; Tue, 10 Aug 2004 20:56:53 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i7AKukSu058165; Tue, 10 Aug 2004 22:56:51 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <41193683.2090906@DeepCore.dk> Date: Tue, 10 Aug 2004 22:56:35 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <4113EB2A.7060401@root.org> <20040806221109.GC55186@werd> <411406AA.3030607@root.org> <20040810203822.GB28585@werd> <41193370.3020302@root.org> In-Reply-To: <41193370.3020302@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: current@freebsd.org cc: Radek Kozlowski Subject: Re: Panic on boot with today's CURRENT, ata related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 20:56:54 -0000 Nate Lawson wrote: > Radek Kozlowski wrote: >=20 >> On Fri, Aug 06, 2004 at 03:31:06PM -0700, Nate Lawson wrote: >> >>> It looks like the DMA object for the channel is not being=20 >>> initialized. However, that is in another path (this backtrace is just= =20 >>> a symptom triggered by the first DMA access to the drive). Someone=20 >>> who knows more about the control path for going from PIO -> DMA mode = >>> will have to look into this. >> >> >> I would like to stress that it only happens with ACPI enabled. If I bo= ot >> with ACPI disabled the transfer mode is set to UDMA100. Shall I provid= e >> you with more info? >=20 >=20 > I'm done debugging ATA for now. I spent 8 hours tracking down the firs= t=20 > bug (not counting the time lost tracking down a non-existent routing=20 > table bug triggered by the ATA bug) and 15 minutes on the second one. >=20 > ACPI does not affect ATA other than setting up IO ports and IRQs. I=20 > have no idea what can cause ATA to use PIO over UDMA. If the IO ports for DMA are set wrong or just NULL there will be no DMA, = so compare the dmesg from with and without ACPI and check if thats the=20 reason... -S=F8ren From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 21:01:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 210F316A4D7 for ; Tue, 10 Aug 2004 21:01:06 +0000 (GMT) Received: from ddardaar.mine.nu (bwc72.neoplus.adsl.tpnet.pl [83.29.226.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id A624943D45 for ; Tue, 10 Aug 2004 21:01:05 +0000 (GMT) (envelope-from radek@raadradd.com) Received: by ddardaar.mine.nu (Postfix, from userid 1001) id B2661A58C; Tue, 10 Aug 2004 23:01:12 +0200 (CEST) Date: Tue, 10 Aug 2004 23:01:12 +0200 From: Radek Kozlowski To: Nate Lawson Message-ID: <20040810210112.GC28585@werd> References: <4113EB2A.7060401@root.org> <20040806221109.GC55186@werd> <411406AA.3030607@root.org> <20040810203822.GB28585@werd> <41193370.3020302@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <41193370.3020302@root.org> User-Agent: Mutt/1.5.6i cc: current@freebsd.org cc: sos@deepcore.dk Subject: Re: Panic on boot with today's CURRENT, ata related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 21:01:06 -0000 On Tue, Aug 10, 2004 at 01:43:28PM -0700, Nate Lawson wrote: > >I would like to stress that it only happens with ACPI enabled. If I boot > >with ACPI disabled the transfer mode is set to UDMA100. Shall I provide > >you with more info? > > I'm done debugging ATA for now. I spent 8 hours tracking down the first > bug (not counting the time lost tracking down a non-existent routing > table bug triggered by the ATA bug) and 15 minutes on the second one. I'm sorry that i put you through that. I really appreciate it. > ACPI does not affect ATA other than setting up IO ports and IRQs. I > have no idea what can cause ATA to use PIO over UDMA. I guess I'll have to learn to live with that then. Over and out. -Radek From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 21:03:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10B7316A4CE for ; Tue, 10 Aug 2004 21:03:53 +0000 (GMT) Received: from gateway.nixsys.be (gateway.nixsys.be [195.144.77.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F83843D54 for ; Tue, 10 Aug 2004 21:03:52 +0000 (GMT) (envelope-from philip@paeps.cx) Received: from erda.home.paeps.cx (erda.home.paeps.cx [IPv6:2001:838:37f:10::1]) by gateway.nixsys.be (Postfix) with ESMTP id A14B76C for ; Tue, 10 Aug 2004 23:03:50 +0200 (CEST) Received: from fasolt.home.paeps.cx (fasolt.home.paeps.cx [10.0.0.2]) by erda.home.paeps.cx (Postfix) with ESMTP id 334782120 for ; Tue, 10 Aug 2004 23:03:42 +0200 (CEST) Received: from fasolt.home.paeps.cx (philip@localhost [127.0.0.1]) i7AL3nfV019743; Tue, 10 Aug 2004 23:03:49 +0200 (CEST) (envelope-from philip@fasolt.home.paeps.cx) Received: (from philip@localhost) by fasolt.home.paeps.cx (8.12.11/8.12.11/Submit) id i7AL3nwC019742; Tue, 10 Aug 2004 23:03:49 +0200 (CEST) (envelope-from philip) Date: Tue, 10 Aug 2004 23:03:49 +0200 From: Philip Paeps To: Marc van Kempen Message-ID: <20040810210348.GO14911@fasolt.home.paeps.cx> Mail-Followup-To: Marc van Kempen , freebsd-current@freebsd.org References: <20040805071236.GA595@loge.nixsys.be> <200408102254.32722.marc@bowtie.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408102254.32722.marc@bowtie.nl> X-Date-in-Rome: ante diem V Idius Augustas MMDCCLVII ab Urbe Condida X-PGP-Fingerprint: FA74 3C27 91A6 79D5 F6D3 FC53 BF4B D0E6 049D B879 X-Message-Flag: Get a proper mailclient! User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 21:03:53 -0000 On 2004-08-10 22:54:32 (+0200), Marc van Kempen wrote: > On Thursday 05 August 2004 09:12, Philip Paeps wrote: > > If you happen to own a laptop with a synaptics touchpad, please help test: > > > > > > > > Please report successes and failures :-) > > Just found out about your changes because of my stick not working anymore > after upgrading my kernel sources today. Could you please try Arne's patch, which implements support for guest devices? I've not commited it yet, because I'm still trying to figure some things out. > The touchpad was working to some extent, but tapping (both single and > double) didn't work either. That's strange. While you're applying that patch, it would be nice if you could add options PSM_DEBUG=2 to the kernel configuration as well, and let me know the output of the psm probe (info* and cap* lines). > If you need extra info let me know. Knowing your info* and cap* bits would really help. Thanks! - Philip -- Philip Paeps 100% recycled electrons philip@freebsd.org When life hands you a lemon, make lemonade. From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 21:09:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D94016A4CE for ; Tue, 10 Aug 2004 21:09:20 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D36C43D39 for ; Tue, 10 Aug 2004 21:09:20 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 32521 invoked from network); 10 Aug 2004 21:09:20 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail4.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Aug 2004 21:09:19 -0000 Received: from hydrogen.funkthat.com (azwtcf@localhost.funkthat.com [127.0.0.1])i7AL9IuU084241 for ; Tue, 10 Aug 2004 14:09:19 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i7AL9IwD084240 for freebsd-current@freebsd.org; Tue, 10 Aug 2004 14:09:18 -0700 (PDT) Date: Tue, 10 Aug 2004 14:09:18 -0700 From: John-Mark Gurney To: freebsd-current@freebsd.org Message-ID: <20040810210918.GS991@funkthat.com> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: have you installworld'd since Friday? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 21:09:20 -0000 If you have, please send me a private email telling me approximately when you cvsup'd your sources (or just ident /boot/defaults/loader.conf), and if after installworld, you did, or did not have problems loading kernel modules, such as acpi? This is to help me better understand if the kernel module issue is a wide spread issue, or something wrong with a few existing users. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 21:11:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAC8C16A4E2 for ; Tue, 10 Aug 2004 21:11:34 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9E5843D49 for ; Tue, 10 Aug 2004 21:11:34 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7ALBP8U004711; Tue, 10 Aug 2004 14:11:25 -0700 Message-ID: <411939FC.5060001@root.org> Date: Tue, 10 Aug 2004 14:11:24 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Radek Kozlowski References: <4113EB2A.7060401@root.org> <20040806221109.GC55186@werd> <411406AA.3030607@root.org> <20040810203822.GB28585@werd> <41193370.3020302@root.org> <20040810210112.GC28585@werd> In-Reply-To: <20040810210112.GC28585@werd> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org cc: sos@deepcore.dk Subject: Re: Panic on boot with today's CURRENT, ata related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 21:11:35 -0000 Radek Kozlowski wrote: > On Tue, Aug 10, 2004 at 01:43:28PM -0700, Nate Lawson wrote: > >>>I would like to stress that it only happens with ACPI enabled. If I boot >>>with ACPI disabled the transfer mode is set to UDMA100. Shall I provide >>>you with more info? >> >>I'm done debugging ATA for now. I spent 8 hours tracking down the first >>bug (not counting the time lost tracking down a non-existent routing >>table bug triggered by the ATA bug) and 15 minutes on the second one. > > I'm sorry that i put you through that. I really appreciate it. No problem, I think it's good to debug things to improve FreeBSD even if it's not my area of expertise. >>ACPI does not affect ATA other than setting up IO ports and IRQs. I >>have no idea what can cause ATA to use PIO over UDMA. > > I guess I'll have to learn to live with that then. Over and out. Do what Soeren said. I'm definitely willing to look into anything that acpi is screwing up if someone can point to the before/after behavior, I just can't spend more time in the internals of ata. -- Nate From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 21:28:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDC5716A4CF for ; Tue, 10 Aug 2004 21:28:36 +0000 (GMT) Received: from mediamonks.com (siripandita.mediamonks.net [62.192.127.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 235FF43D45 for ; Tue, 10 Aug 2004 21:28:35 +0000 (GMT) (envelope-from root@mediamonks.net) Received: from manrikigusari [217.19.28.156] by mediamonks.com with ESMTP (SMTPD32-8.12) id ADFA1AD00C2; Tue, 10 Aug 2004 23:28:26 +0200 From: "Terrence Koeman" To: "'Doug White'" Date: Tue, 10 Aug 2004 23:27:12 +0200 Organization: MediaMonks B.V. MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcR+/PdaMkQrNa/jTXGWjUti8MT/fQAC4JAgAAYBSeA= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0074_01C47F31.90554950" In-Reply-To: <200408102035823.SM01804@manrikigusari> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <200408102328524.SM01804@manrikigusari> X-Info: This e-mail was scanned for spam and viruses by mail.mediamonks.net. X-Info: Please send abuse reports about this e-mail to abuse@mediamonks.net. cc: freebsd-current@freebsd.org Subject: RE: Compiler segmentation fault in 5-08 -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: root@mediamonks.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 21:28:37 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0074_01C47F31.90554950 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-freebsd-current@freebsd.org > [mailto:owner-freebsd-current@freebsd.org] On Behalf Of > Terrence Koeman > > -----Original Message----- > > From: owner-freebsd-current@freebsd.org > > [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Doug White > > > > On Tue, 10 Aug 2004, Terrence Koeman wrote: > > > > > > Can you compile a simple "hello world" program? Sometimes > > > > these types of > > > > faults can be caused by faulty memory, processor, > overclocking, or > > > > temperature issues. > > > > > > It doesn't seem hardware related. Before the update I had > > no problems with > > > segmentation faults, and the system can take heavy load just fine. > > > > > > I tried to compile the following hello world program: > > [...] > > > helloworld.c:4: internal compiler error: Segmentation fault > > > > Ugh. Looks like your gcc binary's busted. > > > > > Is there perhaps a way to copy over the compiler from a > > working (older) > > > -CURRENT system and build a new world with it to see if > > it's fixed in cvs? > > > > You might try tracking down a recent snapshot and do an > > 'upgrade'; that > > should overwrite your defective binary. > > > > This problem is unique to you so you may have had a disk error or > > something that's zeroed out part of the gcc binary or cc1 > or something > > important like that. > > I have copied over /usr/bin/* from another working system and > now I can > compile things again. > > Is there anything that could create new problems when doing this? > Well, it seems to be fixed now. As I said I copied over the /usr/bin dir from another system and build world with it. It gave a shitload of warnings I've never seen, but it proceeded anyway. Thanks for your help, I didn't think of a corrupted binary. -- Regards, Terrence Koeman MediaMonks B.V. (www.mediamonks.com) Please quote all replies in correspondence. ------=_NextPart_000_0074_01C47F31.90554950 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKUzCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNmMIICz6ADAgECAhANi0/uqtIYW/R1ap0p4X/7MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4G0MIGxMBEGCWCGSAGG+EIBAQQEAwIB BjA1BgNVHR8ELjAsMCqgKKAmhiRodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLjEuMS5jcmww RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB AgUAA4GBAEJ8Dt+MeUysvwjsTVUvUImgxV5OLl6VMpt5rWURCxxKUsTVqDEhjt4Qm2wIxQfmA7nn yDR4CQnyvAZC+FqMg9GK3qoi9dnjIdLPZYwGM7DNILIzzQq9PuGdwTWpZLCnpSRb6fFo6xPEfDf0 lGQNmsW9MxfvgzOgPuWqPq7Ycx+tMIIEpDCCBA2gAwIBAgIQZx6EJ4oHSmQocGtEpogzPzANBgkq hkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wNDAyMDQw MDAwMDBaFw0wNTAyMDMyMzU5NTlaMIIBFjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0 IEZ1bGwgU2VydmljZTEYMBYGA1UEAxQPVGVycmVuY2UgS29lbWFuMSIwIAYJKoZIhvcNAQkBFhNy b290QG1lZGlhbW9ua3MubmV0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKUqZ0P8RUaCCe aemq1V8OtPimM3jxXZY6yuWtQz74POz82LhrkctttQoqujz5SubFWsQ15KsVnK4Nt+gTmtUELQVa I4uUebypbChhf1fxFerA7Rx8SYL4Ez9Fvco0tn89FRht6C/xoc/Ms/1YkQQcfnu2sqohx53S5Pm0 Ffo/ZQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcC AjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVm ZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDAGCmCG SAGG+EUBBgcEIhYgMWE5NjkyOTM3Y2MyOTFhMzZkZjAxN2Q4NDBjNDRiMTYwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOB gQAmpan0cUGODHHRIbkVFBHbTOumbMmEO3TR6d9z3LVO9cU5YDC/8BI9e5DZ7Kv43p/ldaGVo2ua ZwtvwL6o/iDcP8UDw+WmjSwzp6tck5cVRDEi+q9nCe3JAYBeRgSJlP5JGOirFpLuDTwL4UPdE0em p9ELBC+sXACm2C3u19hlKTGCBD4wggQ6AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3Qg VmFsaWRhdGVkAhBnHoQnigdKZChwa0SmiDM/MAkGBSsOAwIaBQCgggKyMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDgxMDIxMjcxMlowIwYJKoZIhvcNAQkEMRYE FPWPfQaong2a9zpclB4JuU3pUPlgMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIa MAoGCCqGSIb3DQIFMIHyBgkrBgEEAYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNp Z24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5v dCBWYWxpZGF0ZWQCEGcehCeKB0pkKHBrRKaIMz8wgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBnHoQnigdKZChwa0SmiDM/MA0GCSqGSIb3 DQEBAQUABIGARY5zdIOvTqPRDjb5cSS0SUI7p0Bn4ttCgTx+VFut8/fVxwteBZj/ezyRFXqje6S/ 6p/FocRpqzNVVbHvUrSAZZ9c7EWO1qRb6wm7tAoynah9OxR+KP522HgTo+WRHMuUEgKWyvH9x9vf 687k2FXaQCYNwtVorUPeYxcVBffny8MAAAAAAAA= ------=_NextPart_000_0074_01C47F31.90554950-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 21:59:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4D8516A4CE for ; Tue, 10 Aug 2004 21:59:02 +0000 (GMT) Received: from ddardaar.mine.nu (bwc72.neoplus.adsl.tpnet.pl [83.29.226.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07F2F43D45 for ; Tue, 10 Aug 2004 21:59:02 +0000 (GMT) (envelope-from radek@raadradd.com) Received: by ddardaar.mine.nu (Postfix, from userid 1001) id 24A56A58C; Tue, 10 Aug 2004 23:59:08 +0200 (CEST) Date: Tue, 10 Aug 2004 23:59:07 +0200 From: Radek Kozlowski To: Nate Lawson Message-ID: <20040810215907.GD28585@werd> References: <4113EB2A.7060401@root.org> <20040806221109.GC55186@werd> <411406AA.3030607@root.org> <20040810203822.GB28585@werd> <41193370.3020302@root.org> <20040810210112.GC28585@werd> <411939FC.5060001@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <411939FC.5060001@root.org> User-Agent: Mutt/1.5.6i cc: current@freebsd.org cc: sos@deepcore.dk Subject: Re: Panic on boot with today's CURRENT, ata related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 21:59:02 -0000 On Tue, Aug 10, 2004 at 02:11:24PM -0700, Nate Lawson wrote: > Do what Soeren said. I'm definitely willing to look into anything that > acpi is screwing up if someone can point to the before/after behavior, I > just can't spend more time in the internals of ata. Here it is: http://spekt.net/~raadradd/freebsd/dmesg-acpi_disabled.boot http://spekt.net/~raadradd/freebsd/dmesg-acpi_enabled.boot http://spekt.net/~raadradd/freebsd/dmesg.diff That's what grepping the diff for ata/ad0 spits out: -atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x8080 [...] -ata0-master: setting UDMA100 on AcerLabs Aladdin chip [...] -ATAPI_RESET time = 160us +ATAPI_RESET time = 180us [...] -ad0: 16 secs/int, 1 depth queue, UDMA100 +ad0: 16 secs/int, 1 depth queue, PIO4 Please tell me if there's more I can do. Thank you. -Radek From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 22:01:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89F7A16A4CE; Tue, 10 Aug 2004 22:01:59 +0000 (GMT) Received: from lakermmtao11.cox.net (lakermmtao11.cox.net [68.230.240.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCF8143D1D; Tue, 10 Aug 2004 22:01:58 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.71.51]) by lakermmtao11.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP <20040810220157.IFON10626.lakermmtao11.cox.net@dolphin.local.net>; Tue, 10 Aug 2004 18:01:57 -0400 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with ESMTP id i7AM1uUq038951; Tue, 10 Aug 2004 17:01:56 -0500 (CDT) (envelope-from conrads@dolphin.local.net) Received: (from conrads@localhost) by dolphin.local.net (8.13.1/8.13.1/Submit) id i7AM1plw038950; Tue, 10 Aug 2004 17:01:51 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20040810101020.D88160@carver.gumbysoft.com> Date: Tue, 10 Aug 2004 17:01:51 -0500 (CDT) Organization: A Rag-Tag Band of Drug-Crazed Hippies From: "Conrad J. Sabatier" To: Doug White cc: freebsd-current@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: cvsup on amd64 just broke today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conrads@cox.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 22:01:59 -0000 On 10-Aug-2004 Doug White wrote: > On Mon, 9 Aug 2004, Conrad J. Sabatier wrote: > >> > Can you run cvsup manually? It appears to be trying to execute a >> > binary as a shell script here. >> >> Tried that, got the same result. >> >> I hadn't noticed it before, but it does strike me as odd that the >> binary package for amd64 would include a file with "i386" in the >> name, and which is, in fact, an ELF 32 binary. Did something >> change today that would effect the handling of such a file, perhaps? > > Possible. In the interim you might try installing this native amd64 > version of cvsup (its a package so pkg_add it): > > http://people.freebsd.org/~peter/cvsup-without-gui-16.1h.tbz > > If that doesn't work for you I can build a package on my amd64 box. Thanks, it works. I'm just wondering, if you're able to build the port under amd64, why isn't it in the ports collection? I'm also wondering if maybe the breakage of the earlier version I had installed may have been related to the recent import of the new "file" command. -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 22:31:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A49716A4CE; Tue, 10 Aug 2004 22:31:54 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54E2B43D45; Tue, 10 Aug 2004 22:31:54 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-10.local ([172.16.0.10] helo=dhcp-11.local) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41 (FreeBSD)) id 1Buf9q-0008vV-Uc; Wed, 11 Aug 2004 00:31:53 +0200 Date: Wed, 11 Aug 2004 00:33:26 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) To: conrads@cox.net From: Oliver Eikemeier In-Reply-To: Message-Id: <4B88D1FC-EB1D-11D8-9C56-00039312D914@fillmore-labs.com> Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: freebsd-current@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: cvsup on amd64 just broke today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 22:31:54 -0000 Conrad J. Sabatier: > I'm just wondering, if you're able to build the port under amd64, why > isn't it in the ports collection? It is. Doesn't `pkg_add -r cvsup-without-gui' work for you? -Oliver From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 22:35:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4077D16A4CE for ; Tue, 10 Aug 2004 22:35:00 +0000 (GMT) Received: from ctb-mesg6.saix.net (ctb-mesg6.saix.net [196.25.240.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82D0943D49 for ; Tue, 10 Aug 2004 22:34:59 +0000 (GMT) (envelope-from marc@bowtie.nl) Received: from [192.168.0.104] (tbnb-97-84.telkomadsl.co.za [165.165.97.84]) by ctb-mesg6.saix.net (Postfix) with ESMTP id 6826D58898 for ; Wed, 11 Aug 2004 00:34:55 +0200 (SAST) From: Marc van Kempen To: freebsd-current@freebsd.org Date: Wed, 11 Aug 2004 00:34:54 +0200 User-Agent: KMail/1.6.2 References: <20040805071236.GA595@loge.nixsys.be> <200408102254.32722.marc@bowtie.nl> <20040810210348.GO14911@fasolt.home.paeps.cx> In-Reply-To: <20040810210348.GO14911@fasolt.home.paeps.cx> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408110034.54841.marc@bowtie.nl> Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 22:35:00 -0000 On Tuesday 10 August 2004 23:03, Philip Paeps wrote: > On 2004-08-10 22:54:32 (+0200), Marc van Kempen wrote: > > On Thursday 05 August 2004 09:12, Philip Paeps wrote: > > > If you happen to own a laptop with a synaptics touchpad, please help > > > test: > > > > > > > > > > > > Please report successes and failures :-) > > > > Just found out about your changes because of my stick not working anymore > > after upgrading my kernel sources today. > > Could you please try Arne's patch, which implements support for guest > devices? I've not commited it yet, because I'm still trying to figure some > things out. > Works much better. I got my stick back. The only thing not working is the double-pat hold action on the touchpad. > > > > The touchpad was working to some extent, but tapping (both single and > > double) didn't work either. > > That's strange. While you're applying that patch, it would be nice if you > could add options PSM_DEBUG=2 to the kernel configuration as well, and let > me know the output of the psm probe (info* and cap* lines). > The single and double tapping worked, but the double-tap-hold didn't. > > If you need extra info let me know. > > Knowing your info* and cap* bits would really help. > Here it goes: ug 10 23:40:25 host10 kernel: atkbdc0: port 0x64,0x 60 irq 1 on acpi0 Aug 10 23:40:25 host10 kernel: atkbd0: irq 1 on atkbdc0 Aug 10 23:40:25 host10 kernel: kbd0 at atkbd0 Aug 10 23:40:25 host10 kernel: atkbd0: [GIANT-LOCKED] Aug 10 23:40:25 host10 kernel: psm0: current command byte:0047 Aug 10 23:40:25 host10 kernel: Synaptics Touchpad v5.9 Aug 10 23:40:25 host10 kernel: Model information: Aug 10 23:40:25 host10 kernel: infoRot180: 0 Aug 10 23:40:25 host10 kernel: infoPortrait: 0 Aug 10 23:40:25 host10 kernel: infoSensor: 44 Aug 10 23:40:25 host10 kernel: infoHardware: 53 Aug 10 23:40:25 host10 kernel: infoNewAbs: 1 Aug 10 23:40:25 host10 kernel: capPen: 0 Aug 10 23:40:25 host10 kernel: infoSimplC: 1 Aug 10 23:40:25 host10 kernel: infoGeometry: 1 Aug 10 23:40:25 host10 kernel: Extended capabilities: Aug 10 23:40:25 host10 kernel: capExtended: 1 Aug 10 23:40:25 host10 kernel: capPassthrough: 1 Aug 10 23:40:25 host10 kernel: capSleep: 1 Aug 10 23:40:25 host10 kernel: capFourButtons: 0 Aug 10 23:40:25 host10 kernel: capMultiFinger: 1 Aug 10 23:40:25 host10 kernel: capPalmDetect: 1 Aug 10 23:40:25 host10 kernel: psm0: found Synaptics Touchpad Aug 10 23:40:25 host10 kernel: psm0: flags 0x6000 irq 12 on atkbdc0 Aug 10 23:40:25 host10 kernel: psm0: [GIANT-LOCKED] Aug 10 23:40:25 host10 kernel: psm0: model Synaptics Touchpad, device ID 0-00, 3 b uttons Aug 10 23:40:25 host10 kernel: psm0: config:00006000, flags:00000000, packet size: 6 Aug 10 23:40:25 host10 kernel: psm0: syncmask:c0, syncbits:80 Cheers, Marc. From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 22:42:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D54516A4CE; Tue, 10 Aug 2004 22:42:31 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D71643D31; Tue, 10 Aug 2004 22:42:31 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-67-115-74-195.dsl.lsan03.pacbell.net [67.115.74.195]) i7AMgWjx032447; Tue, 10 Aug 2004 18:42:32 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8C85A5138A; Tue, 10 Aug 2004 15:42:27 -0700 (PDT) Date: Tue, 10 Aug 2004 15:42:27 -0700 From: Kris Kennaway To: "Conrad J. Sabatier" Message-ID: <20040810224227.GA67391@xor.obsecurity.org> References: <20040810101020.D88160@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: cvsup on amd64 just broke today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 22:42:31 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Aug 10, 2004 at 05:01:51PM -0500, Conrad J. Sabatier wrote: > I'm just wondering, if you're able to build the port under amd64, why > isn't it in the ports collection? It is. Kris --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBGU9TWry0BWjoQKURAmKKAJ0QsUCLMMiRMstW1F4YUcipd2Sq5QCg0DlH BBUN/kQr3DXgDJ2stbWxELM= =i73q -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 22:50:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A14AC16A4DA for ; Tue, 10 Aug 2004 22:50:30 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B715643D7D for ; Tue, 10 Aug 2004 22:50:19 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 599BE7A3D2 for ; Tue, 10 Aug 2004 15:50:19 -0700 (PDT) Message-ID: <4119512A.6070001@elischer.org> Date: Tue, 10 Aug 2004 15:50:18 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: make -DRESTART buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 22:50:35 -0000 Could someone who knows the buildworld target give a comment as to whether it would be possible to do a -DRESTART option? I have done -DNOCLEAN but it still does quite a bit.. it would be nice to have an option that did -DNOCLEAN and -DNO_TOOLS -DNO_MKDEP and -DNO_CHROOTLIBS (if they existed, and went straight to doing the build where it left off (and where you probably fixed the problem.. it's really annoying to have to restart the buildworld after if falls over 95% through and have it start at the beginning again.. From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 23:05:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B07016A4CE; Tue, 10 Aug 2004 23:05:11 +0000 (GMT) Received: from mediamonks.com (siripandita.mediamonks.net [62.192.127.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3876043D45; Tue, 10 Aug 2004 23:05:08 +0000 (GMT) (envelope-from root@mediamonks.net) Received: from manrikigusari [217.19.28.156] by mediamonks.com with ESMTP (SMTPD32-8.12) id A49541D0090; Wed, 11 Aug 2004 01:04:53 +0200 From: "Terrence Koeman" To: "'John Baldwin'" , Date: Wed, 11 Aug 2004 01:03:17 +0200 Organization: MediaMonks B.V. MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-Type: multipart/signed; boundary="----=_NextPart_000_0018_01C47F3E.FBE5D560"; micalg=SHA1; protocol="application/x-pkcs7-signature" In-Reply-To: <200408101559.19800.jhb@FreeBSD.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcR/FuTtYoq92di4TM6OknOtZEtqwwAFx9Eg Message-Id: <200408110104380.SM01804@manrikigusari> X-Info: This e-mail was scanned for spam and viruses by mail.mediamonks.net. X-Info: Please send abuse reports about this e-mail to abuse@mediamonks.net. Subject: RE: Lock order reversal in 5.2-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: root@mediamonks.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2004 23:05:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C47F3E.FBE5D560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: John Baldwin [mailto:jhb@FreeBSD.org] > Sent: Tuesday, August 10, 2004 21:59 > To: freebsd-current@FreeBSD.org; root@mediamonks.net > Subject: Re: Lock order reversal in 5.2-CURRENT > > > The real problem is that mi_switch panic'd: > > > > > > calltrap() at calltrap+0x5 > > > --- trap 0xc, eip = 0xc04b3ed2, esp = 0xd4dd7c90, ebp = > > > 0xd4dd7ce0 --- > > > mi_switch(1,0,c060d2be,9c,dbba0) at mi_switch+0x102 > > > > > > Does the original poster have a debug kernel built? > > > > Yes I have, but I have no experience with the debugger. > I'll be happy to > > carry out whatever's needed. > > Just pull up gdb on the kernel.debug file in the kernel build > directory and do > 'l *0xc04b3ed2' (the value is the eip from above) to list > the source line > associated with the fault. I'm sorry, I deleted /usr/obj/ to see if a clean start would help. I'll rebuild my kernel and world and if it happens again I'll do this. -- Regards, Terrence Koeman MediaMonks B.V. (www.mediamonks.com) Please quote all replies in correspondence. ------=_NextPart_000_0018_01C47F3E.FBE5D560 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKUzCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNmMIICz6ADAgECAhANi0/uqtIYW/R1ap0p4X/7MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4G0MIGxMBEGCWCGSAGG+EIBAQQEAwIB BjA1BgNVHR8ELjAsMCqgKKAmhiRodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLjEuMS5jcmww RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB AgUAA4GBAEJ8Dt+MeUysvwjsTVUvUImgxV5OLl6VMpt5rWURCxxKUsTVqDEhjt4Qm2wIxQfmA7nn yDR4CQnyvAZC+FqMg9GK3qoi9dnjIdLPZYwGM7DNILIzzQq9PuGdwTWpZLCnpSRb6fFo6xPEfDf0 lGQNmsW9MxfvgzOgPuWqPq7Ycx+tMIIEpDCCBA2gAwIBAgIQZx6EJ4oHSmQocGtEpogzPzANBgkq hkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wNDAyMDQw MDAwMDBaFw0wNTAyMDMyMzU5NTlaMIIBFjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0 IEZ1bGwgU2VydmljZTEYMBYGA1UEAxQPVGVycmVuY2UgS29lbWFuMSIwIAYJKoZIhvcNAQkBFhNy b290QG1lZGlhbW9ua3MubmV0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKUqZ0P8RUaCCe aemq1V8OtPimM3jxXZY6yuWtQz74POz82LhrkctttQoqujz5SubFWsQ15KsVnK4Nt+gTmtUELQVa I4uUebypbChhf1fxFerA7Rx8SYL4Ez9Fvco0tn89FRht6C/xoc/Ms/1YkQQcfnu2sqohx53S5Pm0 Ffo/ZQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcC AjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVm ZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDAGCmCG SAGG+EUBBgcEIhYgMWE5NjkyOTM3Y2MyOTFhMzZkZjAxN2Q4NDBjNDRiMTYwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOB gQAmpan0cUGODHHRIbkVFBHbTOumbMmEO3TR6d9z3LVO9cU5YDC/8BI9e5DZ7Kv43p/ldaGVo2ua ZwtvwL6o/iDcP8UDw+WmjSwzp6tck5cVRDEi+q9nCe3JAYBeRgSJlP5JGOirFpLuDTwL4UPdE0em p9ELBC+sXACm2C3u19hlKTGCBD4wggQ6AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3Qg VmFsaWRhdGVkAhBnHoQnigdKZChwa0SmiDM/MAkGBSsOAwIaBQCgggKyMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDgxMDIzMDMxNlowIwYJKoZIhvcNAQkEMRYE FPB6JQnhSpy8RIwwRd+TyJAE1DcBMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIa MAoGCCqGSIb3DQIFMIHyBgkrBgEEAYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNp Z24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5v dCBWYWxpZGF0ZWQCEGcehCeKB0pkKHBrRKaIMz8wgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBnHoQnigdKZChwa0SmiDM/MA0GCSqGSIb3 DQEBAQUABIGAJWYtzMTt+7uHV7yjsKjyZIY5drJ7B/v1uZbrZ9KmelyPYzNr1CXOceGB+eXGbkN+ 98duIB55qIehv0QJpZRNeXVrDaMjRGO25kqQvZ8O0KtVixHZo/Ix7j+M4juCAQ6I57UvNjfhSWt9 rkiVAm9mfmb2IvXMEUhdqnuRd1Js0pYAAAAAAAA= ------=_NextPart_000_0018_01C47F3E.FBE5D560-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 23:10:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B88016A4CE; Tue, 10 Aug 2004 23:10:48 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id D087943D4C; Tue, 10 Aug 2004 23:10:47 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-67-115-74-195.dsl.lsan03.pacbell.net [67.115.74.195]) i7ANAnjx005322; Tue, 10 Aug 2004 19:10:49 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 150AB527DF; Tue, 10 Aug 2004 16:10:45 -0700 (PDT) Date: Tue, 10 Aug 2004 16:10:44 -0700 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20040810231044.GA70020@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i cc: harti@FreeBSD.org cc: ru@FreeBSD.org Subject: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 23:10:48 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm trying to update a current from a few months ago, and it dies almost im= mediately: Script started on Tue Aug 10 23:06:32 2004 pointyhat# make cleanworld rm -rf /a/obj/usr/src/* chflags -R 0 /a/obj/usr/src rm -rf /a/obj/usr/src/* pointyhat# make buildworld -------------------------------------------------------------- >>> Building an up-to-date make(1) -------------------------------------------------------------- /a/obj//usr/src/usr.bin/make created for /usr/src/usr.bin/make rm -f .depend mkdep -f .depend -a -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"520040803= 0\" -D__FBSDID=3D__RCSID -DDEFSHELL=3D1 arch.c buf.c compat.c cond.c dir.c = for.c hash.c job.c main.c make.c parse.c str.c suff.c targ.c util.c var.c v= ar_modify.c /usr/src/usr.bin/make/lst.lib/lstAppend.c /usr/src/usr.bin/make= /lst.lib/lstAtEnd.c /usr/src/usr.bin/make/lst.lib/lstAtFront.c /usr/src/usr= .bin/make/lst.lib/lstClose.c /usr/src/usr.bin/make/lst.lib/lstConcat.c /usr= /src/usr.bin/make/lst.lib/lstDatum.c /usr/src/usr.bin/make/lst.lib/lstDeQue= ue.c /usr/src/usr.bin/make/lst.lib/lstDestroy.c /usr/src/usr.bin/make/lst.l= ib/lstDupl.c /usr/src/usr.bin/make/lst.lib/lstEnQueue.c /usr/src/usr.bin/ma= ke/lst.lib/lstFind.c /usr/src/usr.bin/make/lst.lib/lstFindFrom.c /usr/src/u= sr.bin/make/lst.lib/lstFirst.c /usr/src/usr.bin/make/lst.lib/lstForEach.c /= usr/src/usr.bin/make/lst.lib/lstForEachFrom.c /usr/src/usr.bin/make/lst.lib= /lstInit.c /usr/src/usr.bin/make/lst.lib/lstInsert.c /usr/src/usr.bin/make/= lst.lib/lstIsAtEnd.c /usr/src/usr.bin/make/lst.lib/lstIsEmpty.c /usr/src/us= r.bin/make/lst.lib/lstLast.c /usr/src/usr.bin/make/lst.lib/lstMember.c /usr= /src/usr.bin/make/lst.lib/lstNext.c /usr/src/usr.bin/make/lst.lib/lstOpen.c= /usr/src/usr.bin/make/lst.lib/lstRemove.c /usr/src/usr.bin/make/lst.lib/ls= tReplace.c /usr/src/usr.bin/make/lst.lib/lstSucc.c echo make: /usr/lib/libc.a >> .depend cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c arch.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c buf.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c compat.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c cond.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c dir.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c for.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c hash.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c job.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c main.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c make.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c parse.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c str.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c suff.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c targ.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c util.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c var.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c var_modify.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstAppend.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstAtEnd.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstAtFront.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstClose.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstConcat.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstDatum.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstDeQueue.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstDestroy.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstDupl.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstEnQueue.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstFind.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstFindFrom.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstFirst.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstForEach.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstForEachFr= om.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstInit.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstInsert.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstIsAtEnd.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstIsEmpty.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstLast.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstMember.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstNext.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstOpen.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstRemove.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstReplace.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -c /usr/src/usr.bin/make/lst.lib/lstSucc.c cc -O -pipe -I/usr/src/usr.bin/make -DMAKE_VERSION=3D\"5200408030\" -D__FBS= DID=3D__RCSID -DDEFSHELL=3D1 -static -o make arch.o buf.o compat.o cond.o= dir.o for.o hash.o job.o main.o make.o parse.o str.o suff.o targ.o util.o = var.o var_modify.o lstAppend.o lstAtEnd.o lstAtFront.o lstClose.o lstConcat= .o lstDatum.o lstDeQueue.o lstDestroy.o lstDupl.o lstEnQueue.o lstFind.o ls= tFindFrom.o lstFirst.o lstForEach.o lstForEachFrom.o lstInit.o lstInsert.o = lstIsAtEnd.o lstIsEmpty.o lstLast.o lstMember.o lstNext.o lstOpen.o lstRemo= ve.o lstReplace.o lstSucc.o=20 sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 make /a/obj//usr/= src/make.i386 -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf /a/obj//usr/src/i386 mkdir -p /a/obj//usr/src/i386/legacy/usr/bin mkdir -p /a/obj//usr/src/i386/legacy/usr/games mkdir -p /a/obj//usr/src/i386/legacy/usr/include/c++/3.3 mkdir -p /a/obj//usr/src/i386/legacy/usr/include/sys mkdir -p /a/obj//usr/src/i386/legacy/usr/lib mkdir -p /a/obj//usr/src/i386/legacy/usr/libexec mkdir -p /a/obj//usr/src/i386/legacy/usr/sbin mkdir -p /a/obj//usr/src/i386/legacy/usr/share/dict mkdir -p /a/obj//usr/src/i386/legacy/usr/share/groff_font/devX100 mkdir -p /a/obj//usr/src/i386/legacy/usr/share/groff_font/devX100-12 mkdir -p /a/obj//usr/src/i386/legacy/usr/share/groff_font/devX75 mkdir -p /a/obj//usr/src/i386/legacy/usr/share/groff_font/devX75-12 mkdir -p /a/obj//usr/src/i386/legacy/usr/share/groff_font/devascii mkdir -p /a/obj//usr/src/i386/legacy/usr/share/groff_font/devcp1047 mkdir -p /a/obj//usr/src/i386/legacy/usr/share/groff_font/devdvi mkdir -p /a/obj//usr/src/i386/legacy/usr/share/groff_font/devhtml mkdir -p /a/obj//usr/src/i386/legacy/usr/share/groff_font/devkoi8-r mkdir -p /a/obj//usr/src/i386/legacy/usr/share/groff_font/devlatin1 mkdir -p /a/obj//usr/src/i386/legacy/usr/share/groff_font/devlbp mkdir -p /a/obj//usr/src/i386/legacy/usr/share/groff_font/devlj4 mkdir -p /a/obj//usr/src/i386/legacy/usr/share/groff_font/devps mkdir -p /a/obj//usr/src/i386/legacy/usr/share/groff_font/devutf8 mkdir -p /a/obj//usr/src/i386/legacy/usr/share/tmac/mdoc mkdir -p /a/obj//usr/src/i386/legacy/usr/share/tmac/mm mkdir -p /a/obj//usr/src/i386/lib mkdir -p /a/obj//usr/src/i386/usr/bin mkdir -p /a/obj//usr/src/i386/usr/include mkdir -p /a/obj//usr/src/i386/usr/lib/compat/aout mkdir -p /a/obj//usr/src/i386/usr/libdata/ldscripts mkdir -p /a/obj//usr/src/i386/usr/libexec mkdir -p /a/obj//usr/src/i386/usr/sbin mkdir -p /a/obj//usr/src/i386/usr/share/misc mkdir -p /a/obj//usr/src/i386/usr/share/snmp/defs mkdir -p /a/obj//usr/src/i386/usr/share/snmp/mibs mtree -deU -f /usr/src/etc/mtree/BSD.include.dist -p /a/obj//usr/src/i386/= usr/include >/dev/null ln -sf /usr/src/sys /a/obj//usr/src/i386 -------------------------------------------------------------- >>> stage 1.1: legacy release compatibility shims -------------------------------------------------------------- +cd /usr/src; MAKEOBJDIRPREFIX=3D/a/obj//usr/src/i386 DESTDIR=3D INSTALL= =3D"sh /usr/src/tools/install.sh" PATH=3D/a/obj//usr/src/i386/legacy/usr/s= bin:/a/obj//usr/src/i386/legacy/usr/bin:/a/obj//usr/src/i386/legacy/usr/gam= es:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=3D/a/obj//usr/src/i386 MAKEFLAG= S=3D"-m /usr/src/tools/build/mk -m /usr/src/share/mk" make -f Makefile.inc= 1 BOOTSTRAPPING=3D502112 -DNOHTML -DNOINFO -DNOLINT -DNOMAN -DNOPIC -DNOP= ROFILE -DNOSHARED -DNO_CPU_CFLAGS -DNO_WARNS legacy +cd: not found *** Error code 127 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Before I did the cleanworld, it was getting fractionally further: =3D=3D=3D> tools/build cd /usr/src/tools/build; /a/obj//usr/src/make.i386/make buildincludes; /a/o= bj//usr/src/make.i386/make installincludes sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libegacy.a /a/obj= //legacy/usr/lib install: /a/obj//legacy/usr/lib: No such file or directory *** Error code 71 Stop in /usr/src/tools/build. *** Error code 1 More fallout from the wonderful new make(1) semantics?=20 Kris --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBGVX0Wry0BWjoQKURAuqKAKCZ11kWNLz47lMzjaBvxfJQ02hXuQCffr1e 5BvifNiuIFT9SjaebnX3ZRI= =zNNW -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 23:12:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DB3016A4CE for ; Tue, 10 Aug 2004 23:12:08 +0000 (GMT) Received: from mail.lambertfam.org (www.lambertfam.org [216.223.208.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 172DF43D41 for ; Tue, 10 Aug 2004 23:12:08 +0000 (GMT) (envelope-from lambert@lambertfam.org) Received: from localhost (localhost [127.0.0.1]) by mail.lambertfam.org (Postfix) with ESMTP id 37AC934D67 for ; Tue, 10 Aug 2004 19:12:05 -0400 (EDT) Received: from mail.lambertfam.org ([127.0.0.1]) by localhost (www.lambertfam.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25579-06 for ; Tue, 10 Aug 2004 19:12:03 -0400 (EDT) Received: from laptop.lambertfam.org (ns.tcworks.com [65.66.76.10]) by mail.lambertfam.org (Postfix) with ESMTP id 8CA7234D53 for ; Tue, 10 Aug 2004 19:12:03 -0400 (EDT) Received: by laptop.lambertfam.org (Postfix, from userid 1001) id ED5DCC14D; Tue, 10 Aug 2004 18:12:02 -0500 (CDT) Date: Tue, 10 Aug 2004 18:12:02 -0500 From: Scott Lambert To: freebsd-current@freebsd.org Message-ID: <20040810231202.GD1067@laptop.lambertfam.org> Mail-Followup-To: freebsd-current@freebsd.org References: <20040805071236.GA595@loge.nixsys.be> <200408102254.32722.marc@bowtie.nl> <20040810210348.GO14911@fasolt.home.paeps.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040810210348.GO14911@fasolt.home.paeps.cx> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at lambertfam.org Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 10 Aug 2004 23:12:08 -0000 On Tue, Aug 10, 2004 at 11:03:49PM +0200, Philip Paeps wrote: > > On Thursday 05 August 2004 09:12, Philip Paeps wrote: > > > If you happen to own a laptop with a synaptics touchpad, please help test: > > > > > > > > > > > > Please report successes and failures :-) Sorry for replying to a newer message. I'm running : device psm # PS/2 mouse options PSM_DEBUG=2 14:55:53 Tue Aug 10 $ ident /sys/isa/psm.c /sys/isa/psm.c: $FreeBSD: src/sys/isa/psm.c,v 1.76 2004/08/08 01:26:00 philip Exp $ dmesg: psm0: unable to allocate IRQ psmcpnp0 irq 12 on acpi0 psm0: current command byte:0047 psm0: found IntelliMouse psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000000, packet size:4 psm0: syncmask:08, syncbits:08 I have a Compaq Presario 2195US with Synaptics touchpad. I used the older XFree86 patch to run the touchpad without moused support before you began enhancing psm. I'm hoping that the psm/moused method will get rid of these annoying double clicks that happen about half the time I click the buttons. I have to use the tap method if a double-click would be a bad thing. (I'm pretty sure I'm not accidentally stuttering my clicks.) All the usual things like dmesg and whatnot are here: http://www.lambertfam.org/~lambert/laptop/Presario_2195US/5/ -- Scott Lambert KC5MLE Unix SysAdmin lambert@lambertfam.org From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 23:19:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75B3016A4CF for ; Tue, 10 Aug 2004 23:19:26 +0000 (GMT) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25FFF43D39 for ; Tue, 10 Aug 2004 23:19:26 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-67-115-74-195.dsl.lsan03.pacbell.net [67.115.74.195]) i7ANJMNW017596 for ; Tue, 10 Aug 2004 19:19:22 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 538995138A; Tue, 10 Aug 2004 16:19:24 -0700 (PDT) Date: Tue, 10 Aug 2004 16:19:24 -0700 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20040810231924.GA71215@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: CPUTYPE not used? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 23:19:26 -0000 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline For some reason kernel and world builds are not using my CPUTYPE=pentium3 setting on an up-to-date -current machine. Can anyone else confirm this? Kris --5vNYLRcllDrimb99 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBGVf7Wry0BWjoQKURAo9vAKDFHtaCWHVi+iDYFrp5dvXCBmF0VACePD+e oAN+t+6ejSxNF+cw59PuzJ8= =6vuC -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 00:02:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 684B116A4CE for ; Wed, 11 Aug 2004 00:02:09 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2853D43D2F for ; Wed, 11 Aug 2004 00:02:09 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-67-115-74-195.dsl.lsan03.pacbell.net [67.115.74.195]) i7B025XO027069; Tue, 10 Aug 2004 20:02:05 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C74845183F; Tue, 10 Aug 2004 17:02:01 -0700 (PDT) Date: Tue, 10 Aug 2004 17:02:01 -0700 From: Kris Kennaway To: Martin MATO Message-ID: <20040811000201.GA72726@xor.obsecurity.org> References: <20040810231924.GA71215@xor.obsecurity.org> <411960B5.3020104@wanadoo.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline In-Reply-To: <411960B5.3020104@wanadoo.fr> User-Agent: Mutt/1.4.2.1i cc: current@FreeBSD.org cc: Kris Kennaway Subject: Re: CPUTYPE not used? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 00:02:09 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 11, 2004 at 01:56:37AM +0200, Martin MATO wrote: > Kris Kennaway a ?crit : >=20 > >For some reason kernel and world builds are not using my > >CPUTYPE=3Dpentium3 setting on an up-to-date -current machine. Can > >anyone else confirm this? > > > >Kris > > > >=20 > > > if you referring the value in /etc/make.conf, the correct one is =20 > "p3" not "pentium3", accordingly to the man page and the example file= =20 > located in /usr/share/examples/etc/make.conf Oops, you're right. Thanks! Kris --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBGWH5Wry0BWjoQKURAglRAJwL40mXEtDgEvMyneunjnaMbkr/XgCdEwvD NOtQjlsfOaR5FP7h8Zk1KcU= =k6y6 -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 00:04:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5D7516A4CE for ; Wed, 11 Aug 2004 00:04:59 +0000 (GMT) Received: from smtp07.web.de (smtp07.web.de [217.72.192.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8686743D1D for ; Wed, 11 Aug 2004 00:04:59 +0000 (GMT) (envelope-from eugene3@web.de) Received: from [217.80.83.210] (helo=[192.168.0.3]) by smtp07.web.de with asmtp (WEB.DE 4.101 #44) id 1Bugbx-0005Rq-00 for freebsd-current@freebsd.org; Wed, 11 Aug 2004 02:04:58 +0200 Message-ID: <411962A7.3060207@web.de> Date: Wed, 11 Aug 2004 02:04:55 +0200 From: Eugene User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.7.1) Gecko/20040707 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20040810212217.1A50B16A54C@hub.freebsd.org> In-Reply-To: <20040810212217.1A50B16A54C@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: eugene3@web.de X-Sender: eugene3@web.de Subject: re: if_vr.c:506 (panic in new 1.93 revision) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 00:04:59 -0000 the panic only occurs in this new 1.93 revision. so the last commit broke it. instantly after booting kernel when doing rc-voodo, setting up the interface right after i read something like set hostname=... panic: _mtx_lock_sleep: recursed on non-recursive mutex vr0 @ /usr/src/sys/pci/if_vr.c:506 i didnt set/unset any mpsafenet sysctl... so it has the default value, cant check at the moment, because its a remote host and obvously the nic donst work right now... Eugene From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 00:05:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 696B116A4CE; Wed, 11 Aug 2004 00:05:47 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2725743D2D; Wed, 11 Aug 2004 00:05:47 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-10.local ([172.16.0.10] helo=dhcp-11.local) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41 (FreeBSD)) id 1Bugch-000LwB-Ey; Wed, 11 Aug 2004 02:05:46 +0200 Date: Wed, 11 Aug 2004 02:07:18 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) To: Kris Kennaway From: Oliver Eikemeier In-Reply-To: <20040810231044.GA70020@xor.obsecurity.org> Message-Id: <68F48C06-EB2A-11D8-9C56-00039312D914@fillmore-labs.com> Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: harti@FreeBSD.org cc: ru@FreeBSD.org cc: current@FreeBSD.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 00:05:47 -0000 Kris Kennaway wrote: > I'm trying to update a current from a few months ago, and it dies > almost immediately: > [...] > More fallout from the wonderful new make(1) semantics? It seems that the build process does not always use the bootstrapped make(1): AFAIK this is being worked on. -Oliver From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 00:10:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A60C16A4CE; Wed, 11 Aug 2004 00:10:25 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0934443D45; Wed, 11 Aug 2004 00:10:25 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-67-115-74-195.dsl.lsan03.pacbell.net [67.115.74.195]) i7B0AIjx022945; Tue, 10 Aug 2004 20:10:18 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 96A3153227; Tue, 10 Aug 2004 17:10:14 -0700 (PDT) Date: Tue, 10 Aug 2004 17:10:14 -0700 From: Kris Kennaway To: Oliver Eikemeier Message-ID: <20040811001014.GA75088@xor.obsecurity.org> References: <20040810231044.GA70020@xor.obsecurity.org> <68F48C06-EB2A-11D8-9C56-00039312D914@fillmore-labs.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <68F48C06-EB2A-11D8-9C56-00039312D914@fillmore-labs.com> User-Agent: Mutt/1.4.2.1i cc: harti@FreeBSD.org cc: ru@FreeBSD.org cc: current@FreeBSD.org cc: Kris Kennaway Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 00:10:25 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 11, 2004 at 02:07:18AM +0200, Oliver Eikemeier wrote: > Kris Kennaway wrote: >=20 > >I'm trying to update a current from a few months ago, and it dies=20 > >almost immediately: > >[...] > >More fallout from the wonderful new make(1) semantics? >=20 > It seems that the build process does not always use the bootstrapped=20 > make(1): > current/2004-August/033703.html> >=20 > AFAIK this is being worked on. OK, thanks. Kris --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBGWPmWry0BWjoQKURAuFIAJ9Z1G6jHY/LEFQMEkRdxFWx1jJDAQCgpDS5 8ghs4qrbSphGWH8yM3LaZGI= =814W -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 00:21:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFAAE16A4D1 for ; Wed, 11 Aug 2004 00:21:18 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DE7443D46 for ; Wed, 11 Aug 2004 00:21:16 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id i7B0LAtk076304; Wed, 11 Aug 2004 09:51:10 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Wed, 11 Aug 2004 09:51:10 +0930 User-Agent: KMail/1.6.2 References: <1092164803.282000-39789820-29345@walla.com> In-Reply-To: <1092164803.282000-39789820-29345@walla.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200408110951.10148.doconnor@gsoft.com.au> X-Spam-Score: -4.3 () CARRIAGE_RETURNS,IN_REP_TO,MIME_LONG_LINE_QP,PGP_SIGNATURE,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Iantcho Vassilev Subject: Re: if_vr.c:506 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 00:21:19 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 11 Aug 2004 04:36, Iantcho Vassilev wrote: > leftMargin=3D0 topMargin=3D0 rightMargin=3D0>
style=3D"FONT-FAMILY: Arial" name=3D"wrteplaceholder">



H= I! to > All
I`m please i can write in tah list.


So yesterday i > cvsup-my source and rebuilded.


First i did > BUILDWORLD.
then          > BUILDKERNEL
then         = &n >bsp; INSTALLKERNEL
then    boot-ed into > single
then       mergemaster > -p
then       installworld - there were > some errors about some man.gz

but that`s not the > question


After booting i had the following > error:

panic:_mtx_lock.sleep recursed on non-recursive mutex > vr0@/usr/src/sys/pci/if_vr0.c:506

and the booting process went to > kernel debugger
I`m with ViaRhine Model Ethernet..
only after adding >
network_interfaces=3D" " to rc.conf made to boot > correctly

p.s.
no special options while compile - > pentium3 
I 

style=3D"background-color:white;color:black;">Walla! Mail - href=3D"http://www.walla.com" style=3D"color:blue">get your free 1G mail > today
You know I can barely read this email. It's MIME type is text/plain but it contains HTML goo. Please fix your email client/provider so you send plain text (or at least=20 correctly typed HTML) As to your problem.. Try backing out the latest commit to if_vr.c (ie go ba= ck=20 to 1.192) =2D --=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 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGWZ25ZPcIHs/zowRAhxmAKCQchefhSBJ9PozfnHMngVldaCaPACaA44N srJos40vXRS4mn5XFFHXFaE=3D =3DiRof =2D----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 00:36:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8897316A4CE for ; Wed, 11 Aug 2004 00:36:46 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5F9B43D45 for ; Wed, 11 Aug 2004 00:36:45 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id i7B0aawm076902; Wed, 11 Aug 2004 10:06:40 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Wed, 11 Aug 2004 10:06:36 +0930 User-Agent: KMail/1.6.2 References: <20040810093218.gck4kwcwsckocko8@mail.encontacto.net> <200408101745.34348.michaelnottebrock@gmx.net> In-Reply-To: <200408101745.34348.michaelnottebrock@gmx.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200408111006.36483.doconnor@gsoft.com.au> X-Spam-Score: -4.9 () CARRIAGE_RETURNS,IN_REP_TO,MIME_LONG_LINE_QP,PGP_SIGNATURE,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) Subject: Re: Problem with sound in latest current o athlon w/VIA, kde, KsCD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 00:36:46 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 11 Aug 2004 01:15, Michael Nottebrock wrote: > On Tuesday 10 August 2004 16:32, Edwin Culp wrote: > > I've installed the latest kde3 on 5 Athlon's with via chipset > > (all en one memory shared thingy) and even though they are > > cheapies, everything works well except for an issue with KsCD. > > It shows that it is playing the cd but no sound. I fire up xmms > > w/cdread and it works out of the box and with sound :). > > KsCD does not 'rip' CDs to play them, it simply sends play commands to the > drive. To get hear the sound, you need to connect your drive's sound outp= ut > with a matching input on your soundcard. If you're using KDE already you can use konqueror to play your CD via=20 cdparanoia.. Visit the URL audiocd:/By Track/Track 01.wav?device=3D/dev/acd0 (or play it= with=20 Kaboodle directly) kscd should really use that kioslave IMHO but I guess kscd was around first= :) More goodies like this available by reading the output of this -> kcmshell ioslaveinfo (eg sftp:/ fish:/ :) =2D --=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 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGWoU5ZPcIHs/zowRAmwEAJ9mkGZGYSN+BlCZ6fQ/4lZgTQS2QACfftIW XbaqookwechZbEWWIVEv2OE=3D =3Dco6G =2D----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 00:48:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF99916A4CE; Wed, 11 Aug 2004 00:48:02 +0000 (GMT) Received: from lakermmtao08.cox.net (lakermmtao08.cox.net [68.230.240.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25C1543D3F; Wed, 11 Aug 2004 00:48:02 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.71.51]) by lakermmtao08.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040811004802.MHDE2852.lakermmtao08.cox.net@dolphin.local.net>; Tue, 10 Aug 2004 20:48:02 -0400 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with ESMTP id i7B0m1Kd000882; Tue, 10 Aug 2004 19:48:01 -0500 (CDT) (envelope-from conrads@dolphin.local.net) Received: (from conrads@localhost) by dolphin.local.net (8.13.1/8.13.1/Submit) id i7B0lt0P000881; Tue, 10 Aug 2004 19:47:55 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <4B88D1FC-EB1D-11D8-9C56-00039312D914@fillmore-labs.com> Date: Tue, 10 Aug 2004 19:47:55 -0500 (CDT) Organization: A Rag-Tag Band of Drug-Crazed Hippies From: "Conrad J. Sabatier" To: Oliver Eikemeier cc: freebsd-current@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: cvsup on amd64 just broke today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conrads@cox.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2004 00:48:02 -0000 On 10-Aug-2004 Oliver Eikemeier wrote: > Conrad J. Sabatier: >> I'm just wondering, if you're able to build the port under amd64, >> why >> isn't it in the ports collection? > > It is. Doesn't `pkg_add -r cvsup-without-gui' work for you? > > -Oliver I meant, why isn't it buildable from source in the ports collection? -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 01:00:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 045EB16A4CE for ; Wed, 11 Aug 2004 01:00:27 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCAC943D2D for ; Wed, 11 Aug 2004 01:00:26 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.10) with ESMTP id i7B10POF019500; Tue, 10 Aug 2004 18:00:25 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i7B10PZd019499; Tue, 10 Aug 2004 18:00:25 -0700 Date: Tue, 10 Aug 2004 18:00:25 -0700 From: Brooks Davis To: "Conrad J. Sabatier" Message-ID: <20040811010025.GB5987@Odin.AC.HMC.Edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-current@freebsd.org Subject: Re: sys/conf/NOTES needs pruning/distributing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 01:00:27 -0000 --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 08, 2004 at 12:50:08PM -0500, Conrad J. Sabatier wrote: > If I understand correctly, sys/conf/NOTES should contain only universal > options that are useable on any platform, correct? Yes, this is correct. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --H+4ONPRPur6+Ovig Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBGW+oXY6L6fI4GtQRArbxAJ0f8sIrkUXcNKKOL2mtxva7O2BiZACgxVIp NF5F48VD+d68bTidv1V3YFk= =JJY0 -----END PGP SIGNATURE----- --H+4ONPRPur6+Ovig-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 01:15:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B2FA16A55E for ; Wed, 11 Aug 2004 01:15:05 +0000 (GMT) Received: from maxlor.mine.nu (c-213-160-32-54.customer.ggaweb.ch [213.160.32.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AD8F43D48 for ; Wed, 11 Aug 2004 01:15:04 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from localhost (localhost [127.0.0.1]) by maxlor.mine.nu (Postfix) with ESMTP id 3F98E2BB for ; Wed, 11 Aug 2004 03:15:02 +0200 (CEST) Received: from maxlor.mine.nu ([127.0.0.1]) by localhost (midgard [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36562-01 for ; Wed, 11 Aug 2004 03:15:00 +0200 (CEST) Received: from merlin.intranet (merlin.intranet [10.0.0.16]) by maxlor.mine.nu (Postfix) with SMTP id B9BDE24C for ; Wed, 11 Aug 2004 03:15:00 +0200 (CEST) Date: Wed, 11 Aug 2004 03:14:52 +0200 From: Benjamin Lutz To: current@freebsd.org Message-Id: <20040811031452.36b44663.benlutz@datacomm.ch> X-Mailer: Sylpheed version 0.9.12-gtk2-20040622 (GTK+ 2.4.4; i386-portbld-freebsd5.2.1) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Wed__11_Aug_2004_03_14_52_+0200_x6kA4N815SQJkpwN" X-Virus-Scanned: by amavisd-new at maxlor.mine.nu Subject: panic when trying to burn a DVD in 5.2.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 01:15:28 -0000 --Signature=_Wed__11_Aug_2004_03_14_52_+0200_x6kA4N815SQJkpwN Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi, This may not be the most useful panic report, given how old FreeBSD 5.2.1 is by now, but maybe it helps anyway. I get a reproducable kernel panic (page fault) if I do this: - Start k3b, create a new data DVD - Burn the DVD, with options "Simulate" and "On the fly". - At least here, the burning will fail almost immediately, I suppose that's another unrelated bug somewhere. - The DVD Tray will open, leave it open. - Burn the DVD again, with the same options - PANIC! Below is the gdb backtrace. Sincerely, Benjamin Lutz root@merlin/usr/panic> uname -a FreeBSD merlin 5.2.1-RELEASE-p8 FreeBSD 5.2.1-RELEASE-p8 #16: Wed Aug 11 02:40:41 CEST 2004 maxlor@merlin:/usr/src/sys/i386/compile/MERLIN i386 root@merlin/usr/panic> gdb -k /boot/kernel/kernel.debug vmcore.1 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 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 "i386-unknown-freebsd"... panic: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xbfafe900 fault code = supervisor write, page not present instruction pointer = 0x8:0xc044625f stack pointer = 0x10:0xe3a62c74 frame pointer = 0x10:0xe3a62ca8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 26 (irq15: ata1) trap number = 12 panic: page fault syncing disks, buffers remaining... 4547 4547 4547 4547 4547 4547 4547 4547 4547 4547 4547 4547 4547 4547 4547 4547 4547 4547 4547 4547 giving up on 3102 buffers Uptime: 3m16s Dumping 1023 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008--- warning: cannot find file for module nvidia.ko Error while mapping shared library sections: nvidia.ko: No such file or directory. Reading symbols from /usr/src/sys/i386/compile/MERLIN/modules/usr/src/sys/modules/linux/linux. ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/MERLIN/modules/usr/src/sys/modules/linux/linux. ko.debug Reading symbols from /boot/kernel/snd_pcm.ko...done. Loaded symbols for /boot/kernel/snd_pcm.ko Reading symbols from /boot/kernel/snd_emu10k1.ko...done. Loaded symbols for /boot/kernel/snd_emu10k1.ko Error while reading shared library symbols: nvidia.ko: No such file or directory. Reading symbols from /usr/src/sys/i386/compile/MERLIN/modules/usr/src/sys/modules/acpi/acpi.ko .debug...done. Loaded symbols for /usr/src/sys/i386/compile/MERLIN/modules/usr/src/sys/modules/acpi/acpi.ko .debug Reading symbols from /usr/src/sys/i386/compile/MERLIN/modules/usr/src/sys/modules/linprocfs/li nprocfs.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/MERLIN/modules/usr/src/sys/modules/linprocfs/li nprocfs.ko.debug Reading symbols from /usr/src/sys/i386/compile/MERLIN/modules/usr/src/sys/modules/ipfw/ipfw.ko .debug...done. Loaded symbols for /usr/src/sys/i386/compile/MERLIN/modules/usr/src/sys/modules/ipfw/ipfw.ko .debug #0 doadump () at ../../../kern/kern_shutdown.c:240 240 dumping++; (kgdb) backtrace #0 doadump () at ../../../kern/kern_shutdown.c:240 #1 0xc04ef95a in boot (howto=256) at ../../../kern/kern_shutdown.c:372 #2 0xc04efcd8 in panic () at ../../../kern/kern_shutdown.c:550 #3 0xc06684fe in trap_fatal (frame=0xe3a62c34, eva=0) at ../../../i386/i386/trap.c:821 #4 0xc0668213 in trap_pfault (frame=0xe3a62c34, usermode=0, eva=3215976704) at ../../../i386/i386/trap.c:735 #5 0xc0667ded in trap (frame= {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1078990592, tf_esi = -963552256, tf_ebp = -475648856, tf_isp = -475648928, tf_ebx = 0, tf_edx = 368, tf_ecx = 9, tf_eax = -1078990592, tf_trapno = 12, tf_err = 2, tf_eip = -1069260193, tf_cs = 8, tf_eflags = 66050, tf_esp = -963347904, tf_ss = -1029856640}) at ../../../i386/i386/trap.c:420 #6 0xc0657708 in calltrap () at {standard input}:94 #7 0xc0443fc1 in ata_interrupt (data=0xc6915c00) at ../../../dev/ata/ata-lowlevel.c:456 #8 0xc04dafd8 in ithread_loop (arg=0xc29d0600) at ../../../kern/kern_intr.c:544 #9 0xc04d9d2f in fork_exit (callout=0xc04dae10 , arg=0x0, frame=0x0) at ../../../kern/kern_fork.c:793 (kgdb) --Signature=_Wed__11_Aug_2004_03_14_52_+0200_x6kA4N815SQJkpwN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBGXMUgShs4qbRdeQRAvl8AJwPejJncSAoYV6MkesFRWjAc9ERHgCfcgks sHeRQEuV9Y7PRRrgN93qXKs= =BUEH -----END PGP SIGNATURE----- --Signature=_Wed__11_Aug_2004_03_14_52_+0200_x6kA4N815SQJkpwN-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 01:31:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 640BE16A4CF for ; Wed, 11 Aug 2004 01:31:27 +0000 (GMT) Received: from gateway.nixsys.be (gateway.nixsys.be [195.144.77.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1536C43D2D for ; Wed, 11 Aug 2004 01:31:08 +0000 (GMT) (envelope-from philip@paeps.cx) Received: from erda.home.paeps.cx (erda.home.paeps.cx [IPv6:2001:838:37f:10::1]) by gateway.nixsys.be (Postfix) with ESMTP id E34C371 for ; Wed, 11 Aug 2004 03:31:06 +0200 (CEST) Received: from fasolt.home.paeps.cx (fasolt.home.paeps.cx [10.0.0.2]) by erda.home.paeps.cx (Postfix) with ESMTP id 8E8C620E3 for ; Wed, 11 Aug 2004 03:30:58 +0200 (CEST) Received: from fasolt.home.paeps.cx (philip@localhost [127.0.0.1]) i7B1V6WQ020863 for ; Wed, 11 Aug 2004 03:31:06 +0200 (CEST) (envelope-from philip@fasolt.home.paeps.cx) Received: (from philip@localhost) by fasolt.home.paeps.cx (8.12.11/8.12.11/Submit) id i7B1V6TD020862 for freebsd-current@freebsd.org; Wed, 11 Aug 2004 03:31:06 +0200 (CEST) (envelope-from philip) Date: Wed, 11 Aug 2004 03:31:06 +0200 From: Philip Paeps To: freebsd-current@freebsd.org Message-ID: <20040811013106.GA14911@fasolt.home.paeps.cx> Mail-Followup-To: freebsd-current@freebsd.org References: <20040805071236.GA595@loge.nixsys.be> <200408102254.32722.marc@bowtie.nl> <20040810210348.GO14911@fasolt.home.paeps.cx> <20040810231202.GD1067@laptop.lambertfam.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040810231202.GD1067@laptop.lambertfam.org> X-Date-in-Rome: ante diem V Idius Augustas MMDCCLVII ab Urbe Condida X-PGP-Fingerprint: FA74 3C27 91A6 79D5 F6D3 FC53 BF4B D0E6 049D B879 X-Message-Flag: Get a proper mailclient! User-Agent: Mutt/1.5.6i Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 01:31:28 -0000 On 2004-08-10 18:12:02 (-0500), Scott Lambert wrote: > On Tue, Aug 10, 2004 at 11:03:49PM +0200, Philip Paeps wrote: > > > On Thursday 05 August 2004 09:12, Philip Paeps wrote: > > > > If you happen to own a laptop with a synaptics touchpad, please help test: > > > > > > > > > > > > > > > > Please report successes and failures :-) > > dmesg: > psm0: unable to allocate IRQ > psmcpnp0 irq 12 on acpi0 > psm0: current command byte:0047 > psm0: found IntelliMouse This appears not to be a Synaptics Touchpad, but an intellimouse... > psm0: syncmask:08, syncbits:08 Synaptics have 0c here. I'm not aware of any Synaptics hardware responding differently to probes (though the specs might be a bit dated here and there, I wouldn't expect them to change something like that). > I have a Compaq Presario 2195US with Synaptics touchpad. Are you really sure it's a Synaptics? - Philip [puzzled] -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. Any child who chatters non-stop at home will adamantly refuse to utter a word when requested to demonstrate for an audience. From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 01:33:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15EFF16A4CE for ; Wed, 11 Aug 2004 01:33:43 +0000 (GMT) Received: from gateway.nixsys.be (gateway.nixsys.be [195.144.77.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6CDF43D2F for ; Wed, 11 Aug 2004 01:33:42 +0000 (GMT) (envelope-from philip@paeps.cx) Received: from erda.home.paeps.cx (erda.home.paeps.cx [IPv6:2001:838:37f:10::1]) by gateway.nixsys.be (Postfix) with ESMTP id D571C46 for ; Wed, 11 Aug 2004 03:33:41 +0200 (CEST) Received: from fasolt.home.paeps.cx (fasolt.home.paeps.cx [10.0.0.2]) by erda.home.paeps.cx (Postfix) with ESMTP id 8C0722120 for ; Wed, 11 Aug 2004 03:33:33 +0200 (CEST) Received: from fasolt.home.paeps.cx (philip@localhost [127.0.0.1]) i7B1XfJK020889 for ; Wed, 11 Aug 2004 03:33:41 +0200 (CEST) (envelope-from philip@fasolt.home.paeps.cx) Received: (from philip@localhost) by fasolt.home.paeps.cx (8.12.11/8.12.11/Submit) id i7B1XfT2020888 for freebsd-current@freebsd.org; Wed, 11 Aug 2004 03:33:41 +0200 (CEST) (envelope-from philip) Date: Wed, 11 Aug 2004 03:33:41 +0200 From: Philip Paeps To: freebsd-current@freebsd.org Message-ID: <20040811013341.GB14911@fasolt.home.paeps.cx> Mail-Followup-To: freebsd-current@freebsd.org References: <20040805071236.GA595@loge.nixsys.be> <200408102254.32722.marc@bowtie.nl> <20040810210348.GO14911@fasolt.home.paeps.cx> <200408110034.54841.marc@bowtie.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408110034.54841.marc@bowtie.nl> X-Date-in-Rome: ante diem V Idius Augustas MMDCCLVII ab Urbe Condida X-PGP-Fingerprint: FA74 3C27 91A6 79D5 F6D3 FC53 BF4B D0E6 049D B879 X-Message-Flag: Get a proper mailclient! User-Agent: Mutt/1.5.6i Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 01:33:43 -0000 On 2004-08-11 00:34:54 (+0200), Marc van Kempen wrote: > On Tuesday 10 August 2004 23:03, Philip Paeps wrote: > > On 2004-08-10 22:54:32 (+0200), Marc van Kempen wrote: > > > Just found out about your changes because of my stick not working > > > anymore after upgrading my kernel sources today. > > > > Could you please try Arne's patch, which implements support for guest > > devices? I've not commited it yet, because I'm still trying to figure some > > things out. > > Works much better. I got my stick back. I'll have to commit that then :-) > The only thing not working is the double-pat hold action on the touchpad. That's something I'm still working on (it's a very popular feature which I also sorely miss, but can't seem to get right). I have patches that are just about workable, which I'll post for testing shortly. - Philip -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. If you know, you can't say. From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 02:00:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C02116A4CE; Wed, 11 Aug 2004 02:00:52 +0000 (GMT) Received: from ganymede.hub.org (u46n208.hfx.eastlink.ca [24.222.46.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3591D43D1F; Wed, 11 Aug 2004 02:00:47 +0000 (GMT) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id 382E9350D2; Tue, 10 Aug 2004 23:00:48 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 3738B34E9D; Tue, 10 Aug 2004 23:00:48 -0300 (ADT) Date: Tue, 10 Aug 2004 23:00:48 -0300 (ADT) From: "Marc G. Fournier" To: Ruslan Ermilov In-Reply-To: <20040810122619.GB18408@ip.net.ua> Message-ID: <20040810225929.L62519@ganymede.hub.org> References: <20040810043034.GA61300@regency.nsu.ru> <20040810122619.GB18408@ip.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Alexey Dokuchaev cc: harti@freebsd.org cc: current@freebsd.org Subject: Re: snmp_atm is broken? (world does not build) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 02:00:52 -0000 On Tue, 10 Aug 2004, Ruslan Ermilov wrote: > On Tue, Aug 10, 2004 at 11:30:34AM +0700, Alexey Dokuchaev wrote: >> Hi there, >> >> Today's world does not build, failing in snmp_atm: >> >> ===> lib/libbsnmp/modules/snmp_atm >> make: don't know how to make snmp_atm.h. Stop >> *** Error code 2 >> > [...] > >>> From src/lib/libbsnmp/modules/snmp_atm/Makefile rev. 1.1 I see: >> >> SNMP_ATM=${.CURDIR}/../../../../contrib/ngatm/snmp_atm >> INCS= snmp_${MOD}.h >> CFLAGS+= -I${SNMP_ATM} >> >> but /usr/src/contrib/ngatm/snmp_atm is missing. Can you investigate? >> If you are not responsible for this, please accept my apologies and >> ignore this letter. :) >> > How many times must it be said? If you're running/using -CURRENT, > please get yourself subscribed and *read* the current@ mailing list. > There have been a ton of these reports already, and the issue is > being worked on. In Alexey's defense, his is the first report that I've found watching the lists for this particular problem, since his is the first that (again, I've seen) is quite specific in the subject, instead of just 'buildworld fails' ... :( ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 03:28:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3364A16A4CE for ; Wed, 11 Aug 2004 03:28:48 +0000 (GMT) Received: from omoikane.mb.skyweb.ca (omoikane.mb.skyweb.ca [64.42.246.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AE4243D31 for ; Wed, 11 Aug 2004 03:28:47 +0000 (GMT) (envelope-from mark@skyweb.ca) Received: by omoikane.mb.skyweb.ca (Postfix, from userid 1001) id D6A9461D2D; Tue, 10 Aug 2004 22:28:39 -0500 (CDT) From: Mark Johnston To: current@freebsd.org Date: Tue, 10 Aug 2004 22:28:39 -0500 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200408102228.39276.mjohnston@skyweb.ca> Subject: cvs-src summary for August 2-9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 03:28:48 -0000 Here's the summary, albeit a bit delayed; things are back on track after the holiday. Mark FreeBSD cvs-src summary for 02/08/04 to 09/08/04 ++++++++++++++++++++++++++++++++++++++++++++++++ This is a regular weekly summary of FreeBSD's cutting-edge development. It is intended to help the FreeBSD community keep up with the fast-paced work going on in FreeBSD-CURRENT by distilling the deluge of data from the CVS mailing list into a (hopefully) easy-to-read newsletter. This newsletter is marked up in reStructuredText_, so any odd punctuation that you see is likely intended for the reST parser. .. _reStructuredText: http://docutils.sourceforge.net/rst.html You can get old summaries, and an HTML version of this one, at http://www.xl0.org/FreeBSD/. Please send any comments to Mark Johnston (mark at xl0.org). For Lukasz Dudek and Szymon Roczniak's Polish translations of these summaries, which may lag the English ones slightly, please see http://mocart.pinco.pl/FreeBSD/. .. contents:: ============ New features ============ Support for Thread Local Storage added -------------------------------------- Doug Rabson (dfr) added support for Thread Local Storage (TLS), a GCC feature that allows a variable to be declared as separate for each thread, so if one thread changes it, the changes will not affect other threads. The main user of this is OpenGL. http://www.freebsd.org/cgi/mid.cgi?200408030851.i738p0uZ062955 ipfw gains antispoof option --------------------------- Andre Oppermann (andre) added an option called "antispoof" to ipfw. The antispoof option checks the source address of a packet; if that adress is on a directly connected network, but the packet is coming in on a different interface than that network is connected to, antispoof *does not* match. That means that it should be used as follows:: ipfw add deny ip from any to any not antispoof in http://www.freebsd.org/cgi/mid.cgi?200408091612.i79GCAOB064830 FILE updated to 4.10 -------------------- David O'Brien (obrien) imported Christos Zoulas's FILE version 4.10. FILE is a tool that identifies files and prints information about them. http://www.freebsd.org/cgi/mid.cgi?200408090845.i798jhgY049866 bsnmpd updated to 1.7 --------------------- Hartmut Brandt (harti) updated bsnmpd, a lightweight SNMP server. This update introduces fixups, cleanups, and the ability for gensnmptree to merge multiple trees. http://www.freebsd.org/cgi/mid.cgi?200408061338.i76DcVcM015589 sendmail 8.13.1 MFC'ed ---------------------- Gregory Neil Shapiro (gshapiro) MFC'ed the sendmail 8.13.1 update. http://www.freebsd.org/cgi/mid.cgi?200408090015.i790FiVa033171 =============== Notable changes =============== Packet mode enabled by default in boot0cfg ------------------------------------------ David O'Brien (obrien) enabled packet mode by default in boot0cfg, the program that installs the bootloader code. Packet mode allows the system to boot from partitions above cylinder 1024, but can affect compatibility, especially on SCSI drives. http://www.freebsd.org/cgi/mid.cgi?200408031520.i73FKtea075256 Command-line arguments in make now propagate to all sub-makes ------------------------------------------------------------- Hartmut Brandt (harti) modified make to propagate its command-line arguments to sub-makes as command-line arguments, as required by POSIX. This primarily affects prople using MAKEOBJDIR and MAKEOBJDIRPREFIX as command-line arguments; they should instead be used as environment variables, so they don't propagate to sub-makes. Some discussion followed from this commit, but it was generally of a technical support nature and isn't summarized here. The committed code was derived from NetBSD. http://www.freebsd.org/cgi/mid.cgi?200408031856.i73IuV8c082723 null.ko removed --------------- Mark Murray (markm) removed the null.ko kernel module, which provided /dev/null and /dev/zero in module form. Those devices are now built in to all kernels statically. http://www.freebsd.org/cgi/mid.cgi?200408031924.i73JOsJR083899 CARP placeholder added; recompile of network modules required ------------------------------------------------------------- Max Laier (mlaier) added a placeholder to the network interface structure to permit adding CARP, the Common Address Redundancy Protocol, from OpenBSD, in the future. Any modules that use the ifnet structure will need to be recompiled. http://www.freebsd.org/cgi/mid.cgi?200408070932.i779W4u6054997 TCP in-flight sysctls moved into a subtree ------------------------------------------ Andre Oppermann (andre) moved the sysctls net.inet.tcp.inflight_enable, net.inet.tcp.inflight_debug, net.inet.tcp.inflight_min, net.inet.tcp.inflight_max, and net.inet.tcp.inflight_stab to their own subtree, net.inet.tcp.inflight. The result of this is that the underscores in the old names become dots in the new ones. http://www.freebsd.org/cgi/mid.cgi?200408031354.i73DsBZ6072580 ================= Discussion topics ================= Dealing with duplicate modules ------------------------------ David O'Brien (obrien) removed the recently-added mem.ko module from the kernel Makefile, saying, "Currently one cannot load the mem.ko module without panicing if mem is compiled into the kernel and one cannot build a kernel w/o 'device mem' right now either." John Baldwin (jhb) replied, "You need to file a bug report, not start a commit war. Revert this commit and give Mark [Murray] a chance of trying to fix this." David replied, "I'll back it out, but I'm now asking for a back out of the entire mem as a module commit -- it is only 1/2 baked [ . . . ]." David also followed up to his original post, saying, "Please find a way for all your /dev KO's to detect if they are already active and not panic if loaded(initialized) twice." Roman Kurakin (rik) responded, "Take a look how ctau(4)/cx(4)/cp(4) solve this problem.", giving some sample code. Mark Murray (markm) replied too, saying, "I am investigating. In the meanwhile, please back out this commit [ . . . ]." David responded, "You've been investigating for years. I've reported the problem about random.ko more than once.", also backing out his original commit as Mark asked. Mark answered, "What I'm having problems with is fixing the module system, particularly when it works with some modules and not with others." Brooks Davis (brooks) also replied to David, saying, "IMO this is a module system bug not a bug in any given module." Mark replied, "I'm looking to see if MODULE_VERSION() may fix this." Nate Lawson (njl) responded, "The case where mem is compiled into the kernel and then an attempt is made to load it as a module needs to be detected by looking for an instance of the devclass." John pointed out, "mem is a dev_t aka struct cdev \*, not a device_t. There is no devclass." Brooks added, "Similarly, where I've seen this problem is pseudo network interfaces which are nothing but ifnet entries. This is why I think we need to handle this in the module layer and stop requring hack in every driver." http://www.freebsd.org/cgi/mid.cgi?200408021814.i72IE6QJ030695 Cryptography in releases and legal concerns ------------------------------------------- Nate Lawson (njl) moved the crypto distribution into base, making all releases cryptography-enabled. He noted, "The -DNOCRYPT build option still exists for anyone who really wants to build non-cryptographic binaries [ . . . ]." Paul Richards replied, "From information I've received recently it seems that exporting crypto from the UK now requires an export license." Poul-Henning Kamp (phk) responded, "No it doesn't. Read the Waasenaar accord." Colin Percival also answered Paul, saying, "When I asked [the UK Department of Trade and Industry] about crypto a couple years ago, their response was 'it's open source? In that case, go right ahead'. Of course, the usual caveats about not exporting to embargoed countries and not assisting in the production of WMD still apply, but those restrictions would apply regardless of whether we ship cryptographic binaries." Paul replied, "In this case it wasn't open source, it was a commercial product that had FreeBSD in it, specifically it was "tangible" and that's significant when interpreting the export rules." He also gave a link to the crypto law survey at http://rechten.uvt.nl/koops/cryptolaw/cls2.htm . In a second posting, he clarified that "It's not an issue for FreeBSD to be distributed as open source [but] It doesn't however follow that FreeBSD is always exempt from export controls because it might not be if your exporting it as a product, even if that product is just FreeBSD on a CD." Mark Murray (markm) answered, "This is just plain incorrect. If it is Open Source, it is exportable." Paul asked, "Do you have a reference for that assumption?" Mark replied, "Not offhand, but our company lawyers OKed it.", and suggested http://www.wassenaar.org and http://www.dti.gov.uk as well. Paul responded, "I'm only reporting what I was told by a UK FreeBSD user [ . . . ]. For their product the fact that FreeBSD was bundled into an embedded product meant that it was not considered to be an open source product and therefore possibly needed an export license." Mark clarified, "If the product's web site has a downloadable copy of the cryptographic stuff available for public download, you don't need to license. If the cryptographic code is in some way _NOT_ available to the general public, you need to seek permission." http://www.freebsd.org/cgi/mid.cgi?200408060727.i767R87w004556 =================== Important bug fixes =================== mbuf exhaustion panic fixed --------------------------- Brian Feldman (green) changed the UMA (uniform memory access) code, allowing UMA to return an error if the memory requested could not be allocated. This eliminates the panics when you run out of memory for mbuf clusters. http://www.freebsd.org/cgi/mid.cgi?200408020018.i720Iato093771 =============== Other bug fixes =============== Nate Lawson (njl) made EISA probing less invasive; this fixes hangs on some laptops (Thinkpads, for instance) when booting with ACPI disabled, but breaks the old Adaptec 2842 VLB controller. VLB (Vesa Local Bus) is a bus technology that predates PCI, and that was commonly found on 486es. http://www.freebsd.org/cgi/mid.cgi?200408030041.i730fl2S048673 Joe Marcus Clarke (marcus) fixed a segfault in natd when trying to process a PPTP (used for VPN connections) or Skinny (SCCP, used for Cisco IP phones) packet. http://www.freebsd.org/cgi/mid.cgi?200408041517.i74FH8e9028150 From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 03:29:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CCE916A4CE; Wed, 11 Aug 2004 03:29:41 +0000 (GMT) Received: from tethys.ringofsaturn.com (tethys.ringofsaturn.com [66.13.175.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7200D43D1D; Wed, 11 Aug 2004 03:29:40 +0000 (GMT) (envelope-from rnejdl@ringofsaturn.com) Received: from mail.ringofsaturn.com (localhost [127.0.0.1]) i7B3TYRN004594; Tue, 10 Aug 2004 22:29:34 -0500 (CDT) (envelope-from rnejdl@ringofsaturn.com) Received: from 66.13.175.242 (SquirrelMail authenticated user rnejdl); by mail.ringofsaturn.com with HTTP; Tue, 10 Aug 2004 22:29:34 -0500 (CDT) Message-ID: <49521.66.13.175.242.1092194974.squirrel@[66.13.175.242]> In-Reply-To: <200408100826.i7A8Qa8H013148@gw.catspoiler.org> References: <44129.12.148.147.242.1092077172.squirrel@[12.148.147.242]> <200408100826.i7A8Qa8H013148@gw.catspoiler.org> Date: Tue, 10 Aug 2004 22:29:34 -0500 (CDT) From: "Rusty Nejdl" To: "Don Lewis" User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on tethys.ringofsaturn.com X-Virus-Status: Clean cc: freebsd-current@FreeBSD.org cc: dnelson@allantgroup.com Subject: Re: Is anything being done re: the pcm timeout issue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rnejdl@ringofsaturn.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2004 03:29:41 -0000 >> >> And I have seen that these will eventually stop working one by one >> until I have none left. lsof and fstat don't show any programs using >> them, but nonetheless, programms like xmms and gaim can't use them >> anymore. Well, try as much as I could, I haven't been able to duplicate this tonight. I've got 4 vchans setup and I was running madplay continuously on 4 channels for 4 hours and it worked the whole time. > > The vchan code is fairly broken. I was hoping to have to some time to > work on this (and other problems in the top half of the sound code) before > 5.3, but it looks like the clock has just about run out. I'm not seeing the locked channels yet, but that doesn't mean that they aren't there. > > >> Do you have any more details on the pcm play timeout? Are you using >> vchans? What program are you using? > > My suspicion is that there is either a problem in ich_intr() that it > causing it to stop receiving interrupts or to stop calling chn_intr(), or > there is enough interrupt latency to allow the DMA pointer to wrap and > fool chn_dmaupdate() into thinking no data was consumed. It is possible > that the ich_intr() problem is specific to amd64. > > I previously sent out these suggestions on how to debug the problem: I remembered seeing these, but I'm learning as I go so that is a bit more than I can do at present. > > > ------ Forwarded message ------ > From: Don Lewis > Subject: Re: Questionable code in sys/dev/sound/pcm/channel.c > Date: Tue, 27 Jul 2004 15:15:06 -0700 (PDT) > To: mat@cnd.mcgill.ca > Cc: freebsd-current@freebsd.org > > > On 27 Jul, Mathew Kanner wrote: > >> On Jul 26, John-Mark Gurney wrote: >> >>> Conrad J. Sabatier wrote this message on Mon, Jul 26, 2004 at 16:35 >>> -0500: >>> >>>> Why the formulaic calculation of timeout, if it's simply going to >>>> be unconditionally set to 1 immediately afterwards anyway? What's >>>> going on here? >>> >>> Well, if you look at the annotations, that absolute set of timeout >>> was added in rev 1.65 by cg with the comment: tweaks to reduce >>> latency/pauses in output >>> >> >> >> I think this has been raised on the mailling list before. >> IIRC, the logic for this is to check frequently for dead channels but >> CG is the authoriy. >> > > My suspicion is that this change was made to reduce the consequences of > lost wakeups from the interrupt routine. This would have been more of a > problem when tsleep() was used in chn_sleep() and shouldn't be needed now > that the top and bottom halves of the code use the channel lock and > chn_sleep() uses msleep() to atomically release the lock and wait for the > wakeup from the interrupt code. That said, setting timeout to 1 shouldn't > hurt anything and will just waste a bit of CPU time. > > >>>> Also, at the end of the function: >>>> >>>> >>>> if (count <= 0) { c->flags |= CHN_F_DEAD; printf("%s: play interrupt >>>> timeout, channel dead\n", c->name); } >>>> >>>> >>>> return ret; } >>>> >>> >>> that was changed in rev1.52 (by cg also), and previously was just a >>> check for count == 0.. >>> >>> So, I'd recommend a message off to cg and ask why he made this >>> changes... > > The original version of the code always set timeout to 1 and looped on > (count > 0), so count could never go negative. When the code was > changed to set count to something larger than 1, count could go negative if > (hz % timeout != 0), so the condition for setting CHN_F_DEAD had to > be modified accordingly. > > My suspicion is that there is sometimes enough latency in executing the > interrupt routine that the hardware DMA pointer is wrapping and > chn_dmaupdate() is calculating delta as zero. This would cause > chn_wrfeed() not to consume any data from the software buffer (and skip > the wakeup()), which might be enough to cause the chn_write() to time out > while waiting for space to become available in the software buffer. It > would be interesting to enable the debug code in chn_dmaupdate(), and add > (delta == 0) as a condition to trigger the device_printf(). > > > The bigger question is what is the cause of the latency ... > > > > ------ Forwarded message ------ > From: Don Lewis > Subject: Re: Questionable code in sys/dev/sound/pcm/channel.c > Date: Tue, 27 Jul 2004 15:21:57 -0700 (PDT) > To: conrads@cox.net > Cc: freebsd-current@freebsd.org > > > On 27 Jul, Conrad J. Sabatier wrote: > >> >> On 26-Jul-2004 Conrad J. Sabatier wrote: >> >>> >>> On 26-Jul-2004 Conrad J. Sabatier wrote: >>> >>>> I'm a little perplexed at the following bit of logic in chn_write() >>>> (which is where the "interrupt timeout, channel dead" messages are >>>> being generated). >> >> [snip] >> >> >>>> Also, at the end of the function: >>>> >>>> >>>> if (count <= 0) { c->flags |= CHN_F_DEAD; printf("%s: play interrupt >>>> timeout, channel dead\n", c->name); } >>>> >>>> >>>> return ret; } >>>> >>>> >>>> Could it be that the conditional test is wrong here? Perhaps >>>> we should be using (count < 0) instead? >>> >>> I'm now running a kernel built with this last conditional test >>> changed to "if (count < 0)" and sound is still working OK. Have yet to >>> see if this eliminates the interrupt timeout messages. >> >> Well, that was a failure. :-) Didn't see any timeout error messages, >> but the device still died eventually, nonetheless. I've since changed >> back to the original code. > > That's an interesting data point. At this point I'd start looking at the > driver code for your sound hardware. I suspect that the driver interrupt > code is either no longer seeing interrupts, or it is no longer calling > chn_intr(). > > > From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 03:45:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF7AD16A4CE for ; Wed, 11 Aug 2004 03:45:57 +0000 (GMT) Received: from pd3mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCE5F43D1D for ; Wed, 11 Aug 2004 03:45:57 +0000 (GMT) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from pd4mr7so.prod.shaw.ca (pd4mr7so-qfe3.prod.shaw.ca [10.0.141.84])2003)) with ESMTP id <0I2900045JFWDR@l-daemon> for current@freebsd.org; Tue, 10 Aug 2004 21:38:20 -0600 (MDT) Received: from pn2ml4so.prod.shaw.ca ([10.0.121.148]) by pd4mr7so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I2900BCTJFWIP90@pd4mr7so.prod.shaw.ca> for current@freebsd.org; Tue, 10 Aug 2004 21:38:20 -0600 (MDT) Received: from piii600.wadham.ox.ac.uk (S0106006067227a4a.vc.shawcable.net [24.87.233.42]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0I2900A58JFVKP@l-daemon> for current@freebsd.org; Tue, 10 Aug 2004 21:38:20 -0600 (MDT) Date: Tue, 10 Aug 2004 20:38:10 -0700 From: Colin Percival In-reply-to: <200408102228.39276.mjohnston@skyweb.ca> X-Sender: cperciva@popserver.sfu.ca (Unverified) To: Mark Johnston Message-id: <6.1.0.6.1.20040810203707.03f131a8@popserver.sfu.ca> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Content-type: text/plain; charset=us-ascii References: <200408102228.39276.mjohnston@skyweb.ca> cc: current@freebsd.org Subject: Re: cvs-src summary for August 2-9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 03:45:58 -0000 At 20:28 10/08/2004, Mark Johnston wrote: >Cryptography in releases and legal concerns >------------------------------------------- > >Nate Lawson (njl) moved the crypto distribution into base... Don't blame him; it was me. Colin Percival From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 03:48:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0168E16A4CE for ; Wed, 11 Aug 2004 03:48:53 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71BD443D46 for ; Wed, 11 Aug 2004 03:48:52 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id 4024750B82 for ; Wed, 11 Aug 2004 12:48:51 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id DA47A50BBD for ; Wed, 11 Aug 2004 12:48:49 +0900 (JST) Date: Wed, 11 Aug 2004 12:48:49 +0900 Message-ID: <7mbrhiibby.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: Current User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 Subject: Sleeping in "rip6_output" with the following non-sleepable locks held X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 03:48:53 -0000 This is today's -current on amd64 box: Sleeping in "rip6_output" with the following non-sleepable locks held: exclusive sleep mutex inp (raw6inp) r = 0 (0xffffff002f11f0e8) locked @ netinet6/raw_ip6.c:347 exclusive sleep mutex rip r = 0 (0xffffffff807cbf48) locked @ netinet6/raw_ip6.c:745 KDB: stack backtrace: witness_warn() at witness_warn+0x2eb rip6_output() at rip6_output+0x1d2 rip6_send() at rip6_send+0xc1 sosend() at sosend+0x654 kern_sendit() at kern_sendit+0xf4 sendit() at sendit+0x5f sendmsg() at sendmsg+0x87 syscall() at syscall+0x4c3 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (28, FreeBSD ELF64, sendmsg), rip = 0x20068c380, rsp = 0x7fffffffed78, rbp = 0x1 --- -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 04:16:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 277A916A4CE for ; Wed, 11 Aug 2004 04:16:25 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3D1943D41 for ; Wed, 11 Aug 2004 04:16:24 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7B4Enjq005144; Wed, 11 Aug 2004 00:14:50 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7B4EnUb005141; Wed, 11 Aug 2004 00:14:49 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 11 Aug 2004 00:14:49 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Jun Kuriyama In-Reply-To: <7mbrhiibby.wl@black.imgsrc.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Current Subject: Re: Sleeping in "rip6_output" with the following non-sleepable locks held X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 04:16:25 -0000 On Wed, 11 Aug 2004, Jun Kuriyama wrote: > This is today's -current on amd64 box: Hmm. There was a patch floating around for this based on my suggestion of converting this to an M_DONTWAIT and then handling the error case, but I don't seem to be able to find it in my mailbox. Do you have a copy? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research > > Sleeping in "rip6_output" with the following non-sleepable locks held: > exclusive sleep mutex inp (raw6inp) r = 0 (0xffffff002f11f0e8) locked @ netinet6/raw_ip6.c:347 > exclusive sleep mutex rip r = 0 (0xffffffff807cbf48) locked @ netinet6/raw_ip6.c:745 > KDB: stack backtrace: > witness_warn() at witness_warn+0x2eb > rip6_output() at rip6_output+0x1d2 > rip6_send() at rip6_send+0xc1 > sosend() at sosend+0x654 > kern_sendit() at kern_sendit+0xf4 > sendit() at sendit+0x5f > sendmsg() at sendmsg+0x87 > syscall() at syscall+0x4c3 > Xfast_syscall() at Xfast_syscall+0xa8 > --- syscall (28, FreeBSD ELF64, sendmsg), rip = 0x20068c380, rsp = 0x7fffffffed78, rbp = 0x1 --- > > > -- > Jun Kuriyama // IMG SRC, Inc. > // FreeBSD Project > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 04:29:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81BD216A4CE for ; Wed, 11 Aug 2004 04:29:00 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C3BF43D58 for ; Wed, 11 Aug 2004 04:29:00 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7B4RPaA005494 for ; Wed, 11 Aug 2004 00:27:25 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7B4RPVE005491 for ; Wed, 11 Aug 2004 00:27:25 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 11 Aug 2004 00:27:25 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: USB network device drivers now usable with debug.mpsafenet=1 (was:cvs commit: src/sys/dev/usb if_aue.c if_axe.c if_cue.c if_kue.c if_rue.c if_udav.c (fwd)) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 04:29:00 -0000 FYI, with this change it should be substantially safer to run a Giant-free network stack with USB network devices, despite the USB device framework not being MPSAFE. I have similar patches for a number of non-locked network device drivers, including Firewire networking and older ethernet devices, and will merge those in the next few days. This may result in a performance hit for these devices, which may or may not be made up for by removing the Giant lock from the network stack. However, it gives us some room to keep these devices operational in a Giant-free world to allow more time for the device drivers to be made Giant-free. For those interested in the continuing evolution of the netperf work, a change log can be found at: http://www.watson.org/~robert/freebsd/netperf/ I'll send out an updated version of my notice on using the network stack without the Giant lock in a couple of days once I've wrapped up my current batch of merging. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research ---------- Forwarded message ---------- Date: Wed, 11 Aug 2004 03:38:55 +0000 (UTC) From: Robert Watson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/dev/usb if_aue.c if_axe.c if_cue.c if_kue.c if_rue.c if_udav.c rwatson 2004-08-11 03:38:55 UTC FreeBSD src repository Modified files: sys/dev/usb if_aue.c if_axe.c if_cue.c if_kue.c if_rue.c if_udav.c Log: Mark USB ethernet devices as IFF_NEEDSGIANT, since the USB framework if_start routines cannot currently be entered without Giant. When the kernel is running with debug.mpsafenet != 0, this will defer if_start execution to a task queue thread holding Giant, which may introduce additional latency, but avoid incorrect execution. Suggested by: dfr Revision Changes Path 1.86 +2 -1 src/sys/dev/usb/if_aue.c 1.21 +2 -1 src/sys/dev/usb/if_axe.c 1.52 +2 -1 src/sys/dev/usb/if_cue.c 1.58 +2 -1 src/sys/dev/usb/if_kue.c 1.16 +2 -1 src/sys/dev/usb/if_rue.c 1.8 +2 -1 src/sys/dev/usb/if_udav.c From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 04:32:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 912E516A4CF; Wed, 11 Aug 2004 04:32:09 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4123D43D49; Wed, 11 Aug 2004 04:32:09 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) i7B4Vhr4073428; Tue, 10 Aug 2004 21:31:49 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (h234.neville-neil.com [209.157.133.234] (may be forged)) by mail.meer.net (8.12.10/8.12.2/meer) with ESMTP id i7B4VOuE038291; Tue, 10 Aug 2004 21:31:24 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Tue, 10 Aug 2004 21:31:21 -0700 Message-ID: From: "George V. Neville-Neil" To: Robert Watson In-Reply-To: References: <7mbrhiibby.wl@black.imgsrc.co.jp> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: Jun Kuriyama cc: Current Subject: Re: Sleeping in "rip6_output" with the following non-sleepable locks held X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 04:32:09 -0000 At Wed, 11 Aug 2004 00:14:49 -0400 (EDT), Robert Watson wrote: > > > On Wed, 11 Aug 2004, Jun Kuriyama wrote: > > > This is today's -current on amd64 box: > > Hmm. There was a patch floating around for this based on my suggestion of > converting this to an M_DONTWAIT and then handling the error case, but I > don't seem to be able to find it in my mailbox. Do you have a copy? > I believe this is what you mean: @@ -376,7 +377,12 @@ code = icmp6->icmp6_code; } - M_PREPEND(m, sizeof(*ip6), M_TRYWAIT); + M_PREPEND(m, sizeof(*ip6), M_DONTWAIT); + if (m == NULL) { + error = ENOBUFS; + goto bad; + } + ip6 = mtod(m, struct ip6_hdr *); /* Later, George From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 04:40:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4241716A4CE; Wed, 11 Aug 2004 04:40:33 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3377543D48; Wed, 11 Aug 2004 04:40:33 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) i7B4dvr8073497; Tue, 10 Aug 2004 21:40:04 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (h234.neville-neil.com [209.157.133.234] (may be forged)) by mail.meer.net (8.12.10/8.12.2/meer) with ESMTP id i7B4dCuE039215; Tue, 10 Aug 2004 21:39:12 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Tue, 10 Aug 2004 21:39:09 -0700 Message-ID: From: "George V. Neville-Neil" To: Robert Watson In-Reply-To: References: <7mbrhiibby.wl@black.imgsrc.co.jp> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: Jun Kuriyama cc: Current Subject: Re: Sleeping in "rip6_output" with the following non-sleepable locks held X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 04:40:33 -0000 At Tue, 10 Aug 2004 21:31:21 -0700, George V. Neville-Neil wrote: > > At Wed, 11 Aug 2004 00:14:49 -0400 (EDT), > Robert Watson wrote: > > > > > > On Wed, 11 Aug 2004, Jun Kuriyama wrote: > > > > > This is today's -current on amd64 box: > > > > Hmm. There was a patch floating around for this based on my suggestion of > > converting this to an M_DONTWAIT and then handling the error case, but I > > don't seem to be able to find it in my mailbox. Do you have a copy? > > > > I believe this is what you mean: > > @@ -376,7 +377,12 @@ > code = icmp6->icmp6_code; > } > > - M_PREPEND(m, sizeof(*ip6), M_TRYWAIT); > + M_PREPEND(m, sizeof(*ip6), M_DONTWAIT); > + if (m == NULL) { > + error = ENOBUFS; > + goto bad; > + } > + > ip6 = mtod(m, struct ip6_hdr *); > > /* > Sorry, forgot to put in the the name of the file. It's sys/netinet6/raw_ip6.c Later, George From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 04:57:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41FC816A4CE for ; Wed, 11 Aug 2004 04:57:03 +0000 (GMT) Received: from mail.tecdigital.net (mail.tecdigital.net [69.20.85.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2317E43D45 for ; Wed, 11 Aug 2004 04:57:01 +0000 (GMT) (envelope-from mariodoria@yahoo.com) Received: from madd-wireless.localdomain (host-200-56-121-231.block.alestra.net.mx [200.56.121.231]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.tecdigital.net (Postfix) with ESMTP id DBB294B7B0 for ; Tue, 10 Aug 2004 23:56:59 -0500 (CDT) From: "Mario A. Doria" To: current@freebsd.org Date: Tue, 10 Aug 2004 23:56:57 -0500 User-Agent: KMail/1.6.82 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408102356.57524.mariodoria@yahoo.com> Subject: Re: Vinum status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 04:57:03 -0000 Hi, After reading the recent thread, I've got one question. How do you start up using gvinum instead of vinum? Did you change or add a /etc/rc.d script? What do I do to start using gvinum instead of vinum? Thanks, Mario From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 06:12:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CB0516A4CE; Wed, 11 Aug 2004 06:12:10 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A45943D39; Wed, 11 Aug 2004 06:12:09 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7B6C0SA041835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Aug 2004 09:12:01 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7B6C209080338; Wed, 11 Aug 2004 09:12:02 +0300 (EEST) (envelope-from ru) Date: Wed, 11 Aug 2004 09:12:02 +0300 From: Ruslan Ermilov To: Kris Kennaway Message-ID: <20040811061202.GA80234@ip.net.ua> References: <20040810231044.GA70020@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: <20040810231044.GA70020@xor.obsecurity.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: Hartmut Brandt cc: current@FreeBSD.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 06:12:10 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 10, 2004 at 04:10:44PM -0700, Kris Kennaway wrote: > I'm trying to update a current from a few months ago, and it dies almost = immediately: >=20 > Script started on Tue Aug 10 23:06:32 2004 > pointyhat# make cleanworld > rm -rf /a/obj/usr/src/* > chflags -R 0 /a/obj/usr/src > rm -rf /a/obj/usr/src/* > pointyhat# make buildworld >=20 $ hostname pointyhat.freebsd.org $ grep MAKEOBJDIRPREFIX /etc/make.conf MAKEOBJDIRPREFIX=3D/a/obj/ $ grep -A5 '^# MAKEOBJDIRPREFIX' /usr/share/mk/bsd.obj.mk # MAKEOBJDIRPREFIX Specifies somewhere other than /usr/obj to root the obj= ect # tree. Note: MAKEOBJDIRPREFIX is an *environment* variable # and works properly only if set as an environment variable, # not as a global or command line variable! # # E.g. use `env MAKEOBJDIRPREFIX=3D/somewhere/obj make' Pointy hat to: kris For the record, the -CURRENT buildworld on the June 5.2-CURRENT machine worked for me today's night. All issues with the new make(1) and crunchgen(1) have been solved. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --0F1p//8PRICkK4MW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGbiyqRfpzJluFF4RAii3AJ9M64FZQi9yRkFivhXMvbtKbYSGwQCZAZqN PYwbRnNwHujLRHPoumA6qEk= =Ggk7 -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 06:12:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32B1516A4CE for ; Wed, 11 Aug 2004 06:12:59 +0000 (GMT) Received: from ivc-i.dp.uz.gov.ua (ivc-i.dp.uz.gov.ua [212.1.84.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1703843D55 for ; Wed, 11 Aug 2004 06:12:56 +0000 (GMT) (envelope-from o.palij@dp.uz.gov.ua) Received: from s4dnepr.dp.uz.gov.ua ([10.6.105.15]) by ivc-i.dp.uz.gov.ua (8.12.11/8.12.11) with ESMTP id i7B6CpXl018360 for ; Wed, 11 Aug 2004 09:12:53 +0300 Received: from dp.uz.gov.ua ([10.6.100.74]) by s4dnepr.dp.uz.gov.ua (Lotus Domino Release 5.0.10) with SMTP id 2004081109125102:4313 ; Wed, 11 Aug 2004 09:12:51 +0300 Date: Wed, 11 Aug 2004 09:12:51 +0300 From: Oleg Palij To: current@freebsd.org Message-Id: <20040811091251.584e2033@iscmpd-oleg.dp.uz.gov.ua> Organization: Pridn railway X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2.1) Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on s4dnepr/DNEPR/UKRZAL(Release 5.0.10 |March 22, 2002) at 08/11/2004 09:12:51 AM,2002) at 08/11/2004 09:12:53 AM, Serialize complete at 08/11/2004 09:12:53 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on ivc-i X-Virus-Status: Clean Subject: panic with any version of smbd in 5.2.1-R X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 06:12:59 -0000 Panic happens with samba 2.2.8-2.2.10, 3.0.0-3.0.4. I can't reproduce kernel panic but it happens frequently. # uname -a FreeBSD iscmpd-oleg 5.2.1-RELEASE-p9 FreeBSD 5.2.1-RELEASE-p9 #0: Wed Aug 4 11:59:15 EEST 2004 root@iscmpd-oleg:/usr/obj/usr/src/sys/ISCMPD-OLEG_KERNEL i386 Below is the gdb backtrace. # gdb -k kernel.debug.0 /usr/panic/1/vmcore.9 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 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 "i386-unknown-freebsd"... panic: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc055ba8f stack pointer = 0x10:0xce722c70 frame pointer = 0x10:0xce722ce4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 692 (smbd) trap number = 12 panic: page fault syncing disks, buffers remaining... 2197 2197 2194 2192 2192 2192 2192 2192 2192 2192 2192 2192 2192 2192 2192 2192 2192 2192 2192 2192 2192 2192 2192 giving up on 1267 buffers Uptime: 5m0s Dumping 255 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- Reading symbols from /boot/kernel/nvidia.ko...done. Loaded symbols for /boot/kernel/nvidia.ko Reading symbols from /boot/kernel/linux.ko...done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/acpi.ko...done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/msdosfs_iconv.ko...done. Loaded symbols for /boot/kernel/msdosfs_iconv.ko Reading symbols from /boot/kernel/libiconv.ko...done. Loaded symbols for /boot/kernel/libiconv.ko Reading symbols from /boot/kernel/blank_saver.ko...done. Loaded symbols for /boot/kernel/blank_saver.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc0503d52 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc0504087 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc0619276 in trap_fatal (frame=0xce722c30, eva=0) at /usr/src/sys/i386/i386/trap.c:821 #4 0xc0618f12 in trap_pfault (frame=0xce722c30, usermode=0, eva=8) at /usr/src/sys/i386/i386/trap.c:735 #5 0xc0618afd in trap (frame= {tf_fs = -1019871208, tf_es = -1026293744, tf_ds = -831389680, tf_edi = -831378156, tf_esi = -1026292800, tf_ebp = -831378204, tf_isp = -831378340, tf_ebx = 0, tf_edx = 0, tf_ecx = -1019847372, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1068123505, tf_cs = 8, tf_eflags = 66118, tf_esp = -1019847372, tf_ss = -831378300}) at /usr/src/sys/i386/i386/trap.c:420 #6 0xc060a958 in calltrap () at {standard input}:94 #7 0xc0619590 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = -1078001617, tf_edi = 10000, tf_esi = -1077943648, tf_ebp = -1077943592, tf_isp = -831378060, tf_ebx = 0, tf_edx = 0, tf_ecx = -1077942176, tf_eax = 148, tf_trapno = 12, tf_err = 2, tf_eip = 673523215, tf_cs = 31, tf_eflags = 582, tf_esp = -1077943668, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1010 #8 0xc060a9ad in Xint0x80_syscall () at {standard input}:136 ---Can't read userspace from dump, or kernel process--- (kgdb) I can give more information with a pleasure if you say me what i have to do. Also I have samba logs with log level = 9 during panic, but i can't find anything suspect in it. -- Best regards, Palij Oleg, ISC (Pridn railway) From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 06:35:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7806916A4CE for ; Wed, 11 Aug 2004 06:35:24 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B33CC43D53 for ; Wed, 11 Aug 2004 06:35:23 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7B6Z8s4044300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Aug 2004 09:35:09 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7B6Z9g9080538; Wed, 11 Aug 2004 09:35:09 +0300 (EEST) (envelope-from ru) Date: Wed, 11 Aug 2004 09:35:09 +0300 From: Ruslan Ermilov To: Mark Johnston Message-ID: <20040811063509.GC80234@ip.net.ua> References: <200408102228.39276.mjohnston@skyweb.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Clx92ZfkiYIKRjnr" Content-Disposition: inline In-Reply-To: <200408102228.39276.mjohnston@skyweb.ca> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: current@freebsd.org Subject: Re: cvs-src summary for August 2-9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 06:35:24 -0000 --Clx92ZfkiYIKRjnr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 10, 2004 at 10:28:39PM -0500, Mark Johnston wrote: > Command-line arguments in make now propagate to all sub-makes > ------------------------------------------------------------- > Hartmut Brandt (harti) modified make to propagate its command-line > arguments to sub-makes as command-line arguments, as required by POSIX. > This primarily affects prople using MAKEOBJDIR and MAKEOBJDIRPREFIX > as command-line arguments; they should instead be used as environment > variables, so they don't propagate to sub-makes. >=20 Note that setting MAKEOBJDIR and MAKEOBJDIRPREFIX as command-line variables is only supported on 5.x systems after 2003/09/14, and setting them as global variables (e.g., in /etc/make.conf) would most likely result in a failed build. The canonical way was always to use them as environment variables. > Cryptography in releases and legal concerns > ------------------------------------------- >=20 > Nate Lawson (njl) moved the crypto distribution into base, making all > releases cryptography-enabled. He noted, "The -DNOCRYPT build option > still exists for anyone who really wants to build non-cryptographic > binaries [ . . . ]." >=20 It was Colin Percival who did the change. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Important bug fixes > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > mbuf exhaustion panic fixed > --------------------------- > Brian Feldman (green) changed the UMA (uniform memory access) code, >=20 UMA stands for the Universal Memory Allocator. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --Clx92ZfkiYIKRjnr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGb4dqRfpzJluFF4RAl13AJ9uJE6JNJVcMy/bPCSY5MDMOy9HmgCghFUG Ptk2Sb1unZpGSZyM8s24Im4= =A6mG -----END PGP SIGNATURE----- --Clx92ZfkiYIKRjnr-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 06:48:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 843D616A4CE for ; Wed, 11 Aug 2004 06:48:09 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B09DF43D45 for ; Wed, 11 Aug 2004 06:48:08 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7B6lx8G045784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Aug 2004 09:47:59 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7B6m0pS080654; Wed, 11 Aug 2004 09:48:00 +0300 (EEST) (envelope-from ru) Date: Wed, 11 Aug 2004 09:48:00 +0300 From: Ruslan Ermilov To: Julian Elischer Message-ID: <20040811064800.GF80234@ip.net.ua> References: <4119512A.6070001@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0rSojgWGcpz+ezC3" Content-Disposition: inline In-Reply-To: <4119512A.6070001@elischer.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: current@freebsd.org Subject: Re: make -DRESTART buildworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 06:48:09 -0000 --0rSojgWGcpz+ezC3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 10, 2004 at 03:50:18PM -0700, Julian Elischer wrote: >=20 > Could someone who knows the buildworld target give a comment as to=20 > whether it would > be possible to do a -DRESTART option? >=20 > I have done -DNOCLEAN but it still does quite a bit.. > it would be nice to have an option that did > -DNOCLEAN and -DNO_TOOLS -DNO_MKDEP and -DNO_CHROOTLIBS > (if they existed, and went straight to doing the build where it left off= =20 > (and where you > probably fixed the problem.. >=20 > it's really annoying to have to restart the buildworld after if falls=20 > over 95% through and have it start > at the beginning again.. >=20 ``make -f Makefile.inc1 -V WMAKE_TGTS'' will give you an ordered list of buildworld subtargets, so you can control where exactly you want to restart (no checking is done!). You can call of these targets, even underscored ones, from the main src/Makefile (with plain "make "). I often use ``make everything'', the last stage of buildworld, to restart a failed but almost complete buildworld. This is probably exactly what you're looking for at the moment. You can even limit the scope of the rebuild as follows (to check if you've really fixed your problem, and assuming all previous buildworld substages completed successfully): make everything SUBDIR_OVERRIDE=3D"bin/test usr.bin/vacation" Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --0rSojgWGcpz+ezC3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGcEgqRfpzJluFF4RAspoAJ9RVIfLQhLFCDue4v5FK8oV0XKVXACcDEnE okSjJlRqjDmaKrGLGvWPhkg= =Am8T -----END PGP SIGNATURE----- --0rSojgWGcpz+ezC3-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 06:54:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8123D16A4CE; Wed, 11 Aug 2004 06:54:28 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id E07C543D48; Wed, 11 Aug 2004 06:54:25 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id D5D7250BE9; Wed, 11 Aug 2004 15:54:22 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id 99D2350BE8; Wed, 11 Aug 2004 15:54:21 +0900 (JST) Date: Wed, 11 Aug 2004 15:54:21 +0900 Message-ID: <7m657qi2qq.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: "George V. Neville-Neil" In-Reply-To: References: <7mbrhiibby.wl@black.imgsrc.co.jp> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 cc: Jun Kuriyama cc: Current cc: Robert Watson Subject: Re: Sleeping in "rip6_output" with the following non-sleepable locks held X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 06:54:28 -0000 At Tue, 10 Aug 2004 21:39:09 -0700, George V. Neville-Neil wrote: > > I believe this is what you mean: > > > > @@ -376,7 +377,12 @@ > > code = icmp6->icmp6_code; > > } > > > > - M_PREPEND(m, sizeof(*ip6), M_TRYWAIT); > > + M_PREPEND(m, sizeof(*ip6), M_DONTWAIT); > > + if (m == NULL) { > > + error = ENOBUFS; > > + goto bad; > > + } > > + > > ip6 = mtod(m, struct ip6_hdr *); > > > > /* > > Sorry, forgot to put in the the name of the file. It's > > sys/netinet6/raw_ip6.c Thanks! That message is disappeared with your patch. -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 06:59:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95CD616A4CE; Wed, 11 Aug 2004 06:59:16 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5126343D2D; Wed, 11 Aug 2004 06:59:16 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-67-115-74-195.dsl.lsan03.pacbell.net [67.115.74.195]) i7B6xJjx004680; Wed, 11 Aug 2004 02:59:19 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id D7DA25138A; Tue, 10 Aug 2004 23:59:12 -0700 (PDT) Date: Tue, 10 Aug 2004 23:59:12 -0700 From: Kris Kennaway To: Ruslan Ermilov Message-ID: <20040811065912.GA95263@xor.obsecurity.org> References: <20040810231044.GA70020@xor.obsecurity.org> <20040811061202.GA80234@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: <20040811061202.GA80234@ip.net.ua> User-Agent: Mutt/1.4.2.1i cc: Hartmut Brandt cc: current@FreeBSD.org cc: Kris Kennaway Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 06:59:16 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 11, 2004 at 09:12:02AM +0300, Ruslan Ermilov wrote: > On Tue, Aug 10, 2004 at 04:10:44PM -0700, Kris Kennaway wrote: > > I'm trying to update a current from a few months ago, and it dies almos= t immediately: > >=20 > > Script started on Tue Aug 10 23:06:32 2004 > > pointyhat# make cleanworld > > rm -rf /a/obj/usr/src/* > > chflags -R 0 /a/obj/usr/src > > rm -rf /a/obj/usr/src/* > > pointyhat# make buildworld > >=20 > $ hostname > pointyhat.freebsd.org > $ grep MAKEOBJDIRPREFIX /etc/make.conf > MAKEOBJDIRPREFIX=3D/a/obj/ > $ grep -A5 '^# MAKEOBJDIRPREFIX' /usr/share/mk/bsd.obj.mk > # MAKEOBJDIRPREFIX Specifies somewhere other than /usr/obj to root the o= bject > # tree. Note: MAKEOBJDIRPREFIX is an *environment* variable > # and works properly only if set as an environment variable, > # not as a global or command line variable! > # > # E.g. use `env MAKEOBJDIRPREFIX=3D/somewhere/obj make' >=20 > Pointy hat to: kris Well, happy POLA violation to you too; this worked until now. Please add text to make.conf explaining the new order. Kris --J/dobhs11T7y2rNN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBGcPAWry0BWjoQKURAp3NAKD4EExcvlkhXMSNlAnofhz4lWcBjQCfUui0 K0d9IEquzPx1dtCvKmTreso= =rblk -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 07:16:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C3F316A4CE; Wed, 11 Aug 2004 07:16:38 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0794143D4C; Wed, 11 Aug 2004 07:16:37 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i7B7GPX562420; Wed, 11 Aug 2004 09:16:35 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) i7B7GOf62838; Wed, 11 Aug 2004 09:16:25 +0200 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i7B7GNe21069; Wed, 11 Aug 2004 09:16:24 +0200 (MET DST) Date: Wed, 11 Aug 2004 09:16:24 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: Kris Kennaway In-Reply-To: <20040811065912.GA95263@xor.obsecurity.org> Message-ID: <20040811091420.A86410@beagle.kn.op.dlr.de> References: <20040810231044.GA70020@xor.obsecurity.org> <20040811061202.GA80234@ip.net.ua> <20040811065912.GA95263@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2004 07:16:38 -0000 On Tue, 10 Aug 2004, Kris Kennaway wrote: KK>On Wed, Aug 11, 2004 at 09:12:02AM +0300, Ruslan Ermilov wrote: KK>> On Tue, Aug 10, 2004 at 04:10:44PM -0700, Kris Kennaway wrote: KK>> > I'm trying to update a current from a few months ago, and it dies almost immediately: KK>> > KK>> > Script started on Tue Aug 10 23:06:32 2004 KK>> > pointyhat# make cleanworld KK>> > rm -rf /a/obj/usr/src/* KK>> > chflags -R 0 /a/obj/usr/src KK>> > rm -rf /a/obj/usr/src/* KK>> > pointyhat# make buildworld KK>> > KK>> $ hostname KK>> pointyhat.freebsd.org KK>> $ grep MAKEOBJDIRPREFIX /etc/make.conf KK>> MAKEOBJDIRPREFIX=/a/obj/ KK>> $ grep -A5 '^# MAKEOBJDIRPREFIX' /usr/share/mk/bsd.obj.mk KK>> # MAKEOBJDIRPREFIX Specifies somewhere other than /usr/obj to root the object KK>> # tree. Note: MAKEOBJDIRPREFIX is an *environment* variable KK>> # and works properly only if set as an environment variable, KK>> # not as a global or command line variable! KK>> # KK>> # E.g. use `env MAKEOBJDIRPREFIX=/somewhere/obj make' KK>> KK>> Pointy hat to: kris KK> KK>Well, happy POLA violation to you too; this worked until now. Please KK>add text to make.conf explaining the new order. Done in both make.conf(5) and share/examples/etc/make.conf. harti From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 07:19:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6762116A4CE for ; Wed, 11 Aug 2004 07:19:12 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id B665843D39 for ; Wed, 11 Aug 2004 07:19:11 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [172.18.2.1] (csc-gw1.novi.dk [130.225.63.24]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i7B7J0j1063846; Wed, 11 Aug 2004 09:19:05 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <4119C858.6070000@DeepCore.dk> Date: Wed, 11 Aug 2004 09:18:48 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Radek Kozlowski References: <4113EB2A.7060401@root.org> <20040806221109.GC55186@werd><411406AA.3030607@root.org> <20040810203822.GB28585@werd><41193370.3020302@root.org> <20040810210112.GC28585@werd><411939FC.5060001@root.org> <20040810215907.GD28585@werd> In-Reply-To: <20040810215907.GD28585@werd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: current@freebsd.org cc: Nate Lawson Subject: Re: Panic on boot with today's CURRENT, ata related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 07:19:12 -0000 Radek Kozlowski wrote: > -atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x8080 > [...] > -ata0-master: setting UDMA100 on AcerLabs Aladdin chip > [...] > -ATAPI_RESET time =3D 160us > +ATAPI_RESET time =3D 180us > [...] > -ad0: 16 secs/int, 1 depth queue, UDMA100 > +ad0: 16 secs/int, 1 depth queue, PIO4 >=20 > Please tell me if there's more I can do. Thank you. Hmm, you are not getting the DMA resource, or the PCI config registers=20 are not responding as they should. To get more info you should instrument the code in ata-pci.c around=20 lines 178-190 to see what it is that rejects the DMA resource. Something changes in the resources/PCI config that is sent to the ATA=20 driver so that it either cant get at the I/O ports for DMA or so that=20 the PCI config regs wont allow busmastering to be enabled.. Wether this is in ACPI or the PCI code I cant tell without more info=20 from doing the above instrumenting.. -S=F8ren From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 07:45:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D94316A4CE; Wed, 11 Aug 2004 07:45:37 +0000 (GMT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65BF443D5F; Wed, 11 Aug 2004 07:45:37 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bunnk-000Cu6-Tr; Wed, 11 Aug 2004 07:45:37 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Buh1O-00029Z-R6; Tue, 10 Aug 2004 17:31:14 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16665.26834.233633.979765@roam.psg.com> Date: Tue, 10 Aug 2004 17:31:14 -0700 To: "Brandon S. Allbery KF8NH" References: <16659.6061.369420.562800@roam.psg.com> <1091822755.23206.39.camel@tomcat.kitchenlab.org> <16659.58793.887526.631294@roam.psg.com> <1091824128.23206.52.camel@tomcat.kitchenlab.org> <1091933302.56646.1.camel@rushlight.kf8nh.com> <16662.38633.549566.111706@roam.psg.com> <1092000894.56646.3.camel@rushlight.kf8nh.com> cc: "Bruce A. Mah" cc: FreeBSD Current Subject: Re: usb palm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 07:45:37 -0000 >>> For what it's worth, my Tungsten T3 syncs fine over USB with -STABLE. >> using /dev/??? > /dev/ucom0 that was what i tried originally. error on serial. randy From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 08:00:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 946F916A4CE; Wed, 11 Aug 2004 08:00:46 +0000 (GMT) Received: from smtp3.jp.viruscheck.net (smtp3.jp.viruscheck.net [154.33.69.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58E2B43D4C; Wed, 11 Aug 2004 08:00:46 +0000 (GMT) (envelope-from bland@FreeBSD.org) Received: from scan3.jp.viruscheck.net ([154.33.69.38] helo=mail1.jp.viruscheck.net) by smtp3.jp.viruscheck.net with esmtp (Exim 3.36 #1) id 1Buo2O-0002xD-00; Wed, 11 Aug 2004 17:00:44 +0900 Received: from [220.221.2.219] (helo=noc.orchid) by mail1.jp.viruscheck.net with esmtp (Exim 3.36 #3) id 1Buo2N-0002bK-00; Wed, 11 Aug 2004 17:00:43 +0900 Received: from [89.60.10.11] (horse.orchid [89.60.10.11]) by noc.orchid (8.12.11/8.12.11) with ESMTP id i7B80gJ4084573; Wed, 11 Aug 2004 17:00:43 +0900 (JST) (envelope-from bland@FreeBSD.org) Message-ID: <4119D22A.9030107@FreeBSD.org> Date: Wed, 11 Aug 2004 17:00:42 +0900 From: Alexander Nedotsukov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040714 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Bush References: <16659.6061.369420.562800@roam.psg.com> <1091822755.23206.39.camel@tomcat.kitchenlab.org> <16659.58793.887526.631294@roam.psg.com> <1091824128.23206.52.camel@tomcat.kitchenlab.org> <1091933302.56646.1.camel@rushlight.kf8nh.com> <16662.38633.549566.111706@roam.psg.com> <1092000894.56646.3.camel@rushlight.kf8nh.com> <16665.26834.233633.979765@roam.psg.com> In-Reply-To: <16665.26834.233633.979765@roam.psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: "Bruce A. Mah" cc: FreeBSD Current Subject: Re: usb palm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 08:00:46 -0000 Randy Bush wrote: >>>>For what it's worth, my Tungsten T3 syncs fine over USB with -STABLE. >>>> >>>> >>>using /dev/??? >>> >>> >>/dev/ucom0 >> >> > >that was what i tried originally. error on serial. > > May be you fogot to press HotSync button first? Palm's /dev/ucom0 pretty coward. It popups only if some activity should take palce. All the best, Alexander. From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 08:03:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CACA16A4CE; Wed, 11 Aug 2004 08:03:55 +0000 (GMT) Received: from ran.psg.com (ip192.186.dsl-acs2.seawa0.iinet.com [209.20.186.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF1B143D41; Wed, 11 Aug 2004 08:03:54 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ran.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Buo5P-000INn-QD; Wed, 11 Aug 2004 01:03:51 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16665.53991.105517.637209@ran.psg.com> Date: Wed, 11 Aug 2004 01:03:51 -0700 To: Alexander Nedotsukov References: <16659.6061.369420.562800@roam.psg.com> <1091822755.23206.39.camel@tomcat.kitchenlab.org> <16659.58793.887526.631294@roam.psg.com> <1091824128.23206.52.camel@tomcat.kitchenlab.org> <1091933302.56646.1.camel@rushlight.kf8nh.com> <16662.38633.549566.111706@roam.psg.com> <1092000894.56646.3.camel@rushlight.kf8nh.com> <16665.26834.233633.979765@roam.psg.com> <4119D22A.9030107@FreeBSD.org> cc: "Bruce A. Mah" cc: FreeBSD Current Subject: Re: usb palm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 08:03:55 -0000 >>> /dev/ucom0 >> that was what i tried originally. error on serial. > May be you fogot to press HotSync button first? nope. if you haven't pressed the button, you don't have /dev/ucom0 at all. randy From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 08:07:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24D1716A4CE; Wed, 11 Aug 2004 08:07:03 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D503D43D3F; Wed, 11 Aug 2004 08:07:00 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7B83m3T055780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Aug 2004 11:03:49 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7B83oYg084352; Wed, 11 Aug 2004 11:03:50 +0300 (EEST) (envelope-from ru) Date: Wed, 11 Aug 2004 11:03:50 +0300 From: Ruslan Ermilov To: Kris Kennaway Message-ID: <20040811080350.GK80234@ip.net.ua> References: <20040810231044.GA70020@xor.obsecurity.org> <20040811061202.GA80234@ip.net.ua> <20040811065912.GA95263@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KaGhPsiNaI6/sRd6" Content-Disposition: inline In-Reply-To: <20040811065912.GA95263@xor.obsecurity.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: Hartmut Brandt cc: current@FreeBSD.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 08:07:03 -0000 --KaGhPsiNaI6/sRd6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 10, 2004 at 11:59:12PM -0700, Kris Kennaway wrote: > On Wed, Aug 11, 2004 at 09:12:02AM +0300, Ruslan Ermilov wrote: > > On Tue, Aug 10, 2004 at 04:10:44PM -0700, Kris Kennaway wrote: > > > I'm trying to update a current from a few months ago, and it dies alm= ost immediately: > > >=20 > > > Script started on Tue Aug 10 23:06:32 2004 > > > pointyhat# make cleanworld > > > rm -rf /a/obj/usr/src/* > > > chflags -R 0 /a/obj/usr/src > > > rm -rf /a/obj/usr/src/* > > > pointyhat# make buildworld > > >=20 > > $ hostname > > pointyhat.freebsd.org > > $ grep MAKEOBJDIRPREFIX /etc/make.conf > > MAKEOBJDIRPREFIX=3D/a/obj/ > > $ grep -A5 '^# MAKEOBJDIRPREFIX' /usr/share/mk/bsd.obj.mk > > # MAKEOBJDIRPREFIX Specifies somewhere other than /usr/obj to root the= object > > # tree. Note: MAKEOBJDIRPREFIX is an *environment* varia= ble > > # and works properly only if set as an environment variab= le, > > # not as a global or command line variable! > > # > > # E.g. use `env MAKEOBJDIRPREFIX=3D/somewhere/obj make' > >=20 > > Pointy hat to: kris >=20 > Well, happy POLA violation to you too; this worked until now. Please > add text to make.conf explaining the new order. >=20 Can you prove that it worked? I tried to no avail with the old (August 1 2004, before the changes) make(1) and MAKEOBJDIRPREFIX set in /etc/make.conf, to try to buildworld, and it always fails. Do you have a log of a successful buildworld saved somewhere? It fails for me because MAKEOBJDIRPREFIX from /etc/make.conf (a global variable) overrides the value of the MAKEOBJDIRPREFIX environment variable, as documented in make(1), so what's passed to the "legacy" target in Makefile.inc1 by "buildworld" is happily ignored. Here, MAKEOBJDIRPREFIX is set to /home/ru/obj in /etc/make.conf: : -------------------------------------------------------------- : >>> Rebuilding the temporary build tree : -------------------------------------------------------------- : rm -rf /home/ru/obj/usr/src5/i386 [...] : mkdir -p /home/ru/obj/usr/src5/i386/legacy/usr/bin : mkdir -p /home/ru/obj/usr/src5/i386/legacy/usr/games : mkdir -p /home/ru/obj/usr/src5/i386/legacy/usr/include/c++/3.3 : mkdir -p /home/ru/obj/usr/src5/i386/legacy/usr/include/sys : mkdir -p /home/ru/obj/usr/src5/i386/legacy/usr/lib [...] : -------------------------------------------------------------- : >>> stage 1.1: legacy release compatibility shims : -------------------------------------------------------------- : cd /usr/src5; MAKEOBJDIRPREFIX=3D/home/ru/obj/usr/src5/i386 DESTDIR=3D = INSTALL=3D"sh /usr/src5/tools/install.sh" PATH=3D/home/ru/obj/usr/src5/i38= 6/legacy/usr/sbin:/home/ru/obj/usr/src5/i386/legacy/usr/bin:/home/ru/obj/us= r/src5/i386/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=3D/hom= e/ru/obj/usr/src5/i386 MAKEFLAGS=3D"-m /usr/src5/tools/build/mk -m /usr/s= rc5/share/mk" /tmp/make/make -f Makefile.inc1 BOOTSTRAPPING=3D491100 -DNO= HTML -DNOINFO -DNOLINT -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -DNO_CPU_CFL= AGS -DNO_WARNS legacy >=20 So far so good (though the make's idea of the .OBJDIR would not match the Makefile.inc1's perspective, should the canonical /usr/obj exist, but this is harmless at this stage). Now, buildworld tries to call the "legacy" subtarget with MAKEOBJDIRPREFIX set in *environment* to the value of WORLDTMP=3D${MAKEOBJDIRPREFIX}/usr/src5/i386. The "legacy" target will then attempts to install headers and other staff to DESTDIR=3D${MAKEOBJDIRPREFIX}/legacy: legacy: =2Efor _tool in tools/build ${_+_}@${ECHODIR} "=3D=3D=3D> ${_tool}"; \ cd ${.CURDIR}/${_tool}; \ ${MAKE} DIRPRFX=3D${_tool}/ obj; \ ${MAKE} DIRPRFX=3D${_tool}/ DESTDIR=3D${MAKEOBJDIRPREFIX}/legac= y includes; \ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^ ${MAKE} DIRPRFX=3D${_tool}/ depend; \ ${MAKE} DIRPRFX=3D${_tool}/ all; \ ${MAKE} DIRPRFX=3D${_tool}/ DESTDIR=3D${MAKEOBJDIRPREFIX}/legac= y install ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^ =2Eendfor If it was /home/ru/obj/usr/src5/i386/legacy/*, created above, if would have= worked. But MAKEOBJDIRPREFIX from /etc/make.conf messes things up, so it attempts t= o install to non-existing /home/ru/obj/legacy, and fails: : =3D=3D=3D> tools/build : /home/ru/obj/usr/src5/tools/build created for /usr/src5/tools/build : cd /usr/src5/tools/build; /tmp/make/make buildincludes; /tmp/make/make in= stallincludes : sh /usr/src5/tools/install.sh -C -o root -g wheel -m 444 /usr/src5/tools= /build/../../include/getopt.h regex.h /home/ru/obj/legacy/usr/include = ^^^^^^^^^^^^^^^^^^^ : usage: install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode] : [-o owner] file1 file2 : install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode] : [-o owner] file1 ... fileN directory : install -d [-v] [-g group] [-m mode] [-o owner] directory ... : *** Error code 64 :=20 : Stop in /usr/src5/tools/build. Trying to set MAKEOBJDIRPREFIX in /etc/make.conf and attempting to buildwor= ld RELENG_4 on a 4.x machine similarly fails right away. The reason I'm writing this email is that I'm really interested in reproducing the case where it could have possible worked before. Any help on your side would be highly appreciated. The only case that I know of this could have worked (tested) is if make(1) was instructed to prefer the MAKEOBJDIRPREFIX environment variable over a global one, with ``make -E MAKEOBJDIRPREFIX''. Then setting MAKEOBJDIRPREF= IX in /etc/make.conf works. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --KaGhPsiNaI6/sRd6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGdLmqRfpzJluFF4RAiAiAJ0eo25n/XYVjzDmiYu79KX/D8870wCbBroV i3WWEouCLxyvbv+U+l+mLsM= =zYyB -----END PGP SIGNATURE----- --KaGhPsiNaI6/sRd6-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 08:52:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DA6916A4CE for ; Wed, 11 Aug 2004 08:52:33 +0000 (GMT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 9323743D60 for ; Wed, 11 Aug 2004 08:52:32 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 58691 invoked from network); 11 Aug 2004 08:52:30 -0000 Received: from 0x50a43fc7.hknxx1.adsl-dhcp.tele.dk (HELO peter.osted.lan) (80.164.63.199) by relay.pair.com with SMTP; 11 Aug 2004 08:52:30 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost [127.0.0.1]) by peter.osted.lan (8.12.10/8.12.10) with ESMTP id i7B8qTRL062924 for ; Wed, 11 Aug 2004 10:52:29 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.12.10/8.12.10/Submit) id i7B8qTVk062923 for current@freebsd.org; Wed, 11 Aug 2004 10:52:29 +0200 (CEST) (envelope-from pho) Date: Wed, 11 Aug 2004 10:52:29 +0200 From: Peter Holm To: current@freebsd.org Message-ID: <20040811085229.GA62668@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Fatal trap 12 in kern/kern_switch.c:436 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 08:52:33 -0000 While stress testing with kern.threads.virtual_cpu=256 I got this fault after a kill -9 of a hung test program. GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2004 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 5.2-CURRENT #0: Wed Aug 11 04:23:56 CEST 2004 root@peter.osted.lan:/usr/src/sys/i386/compile/PHO WARNING: WITNESS option enabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 1.80GHz (1799.14-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf13 Stepping = 3 Features=0x3febfbff real memory = 267583488 (255 MB) avail memory = 252190720 (240 MB) : ata1-master: DMA limited to UDMA33, non-ATA66 cable or device acd0: CDROM at ata1-master UDMA33 Mounting root from ufs:/dev/ad0s1a kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x54 fault code = supervisor write, page not present instruction pointer = 0x8:0xc066ab08 stack pointer = 0x10:0xd25c1c50 frame pointer = 0x10:0xd25c1c70 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 539 (pthread_setconcurre) [thread 101883] Stopped at setrunqueue+0x1e8: movl %edi,0x54(%edx) db> where setrunqueue(c1bac2c0,c1a957d0,c08b1292,484,c065038e) at setrunqueue+0x1e8 sched_switch(c1bac2c0,0,c08b06b2,123,d3526cf3) at sched_switch+0xa4 mi_switch(2,0,c08b2b56,f5,10000) at mi_switch+0x29f ast(d25c1d48) at ast+0x3fb doreti_ast() at doreti_ast+0x17 db> call doadump Dumping 255 MB panic: blockable sleep lock (sleep mutex) taskqueue @ kern/subr_taskqueue.c:132 cpuid = 0; Uptime: 34m36s panic: cv_wait: not TDS_RUNNING cpuid = 0; KDB: enter: panic [thread 101883] Stopped at kdb_enter+0x30: leave db> (kgdb) l *0xc066ab08 0xc066ab08 is in setrunqueue (../../../kern/kern_switch.c:436). 431 * put the new kse on whatever is next, 432 * which may or may not be us. 433 */ 434 td2 = TAILQ_NEXT(tda, td_runq); 435 kg->kg_last_assigned = td2; 436 td2->td_kse = ke; 437 ke->ke_thread = td2; 438 } 439 sched_add(ke->ke_thread); 440 } else { (kgdb) -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 08:56:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13A8C16A4CE; Wed, 11 Aug 2004 08:56:32 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8258243D3F; Wed, 11 Aug 2004 08:56:31 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i7B8uQje008960; Wed, 11 Aug 2004 18:56:26 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) i7B8uOic005104; Wed, 11 Aug 2004 18:56:25 +1000 Date: Wed, 11 Aug 2004 18:56:23 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: John Baldwin In-Reply-To: <200408051759.53079.jhb@FreeBSD.org> Message-ID: <20040811170302.T1037@epsplex.bde.org> References: <20040805050422.GA41201@cat.robbins.dropbear.id.au> <200408051759.53079.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: Tim Robbins Subject: Re: Atomic operations on i386/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 08:56:32 -0000 On Thu, 5 Aug 2004, John Baldwin wrote: > On Thursday 05 August 2004 01:04 am, Tim Robbins wrote: > > Is there any particular reason why atomic_load_acq_*() and > > atomic_store_rel_*() are implemented with CMPXCHG and XCHG instead of > > MOV on i386/amd64 UP? It is because a something like a locked instruction must be used for synchronization on old i386's, and "LOCK; MOV" is an invalid instruction. I ran AthlonXP and Celeron UP systems for some time with MOV instead of XCHG in atomic_store_rel_*(), but changed back to XCHG since it didn't make much difference and I'm not sure what is best for my other systems (Celeron SMP and amd64). > Actually, using mov instead of lock xchg for store_rel reduced performance in > some benchmarks Scott ran on an SMP machine, I'm guessing due to the higher > latency of locks becoming available to other CPUs. I'm still waiting for > benchmark results on UP to see if the change should be made under #ifndef SMP > or some such. I don't believe unlocked instructions could be slower, and using unlocked && unfenced instructions is just broken in the SMP case. Perhaps there is enough synchronization provided by the lock in load_acq (which in theory needs less locking than store_rel) for missing synchronization in store_rel to sort of work. > > Also, could we use MFENCE/LFENCE/SFENCE in combination with MOV on > > SMP systems instead of LOCK CMPXCHG / (implied LOCK) XCHG? It isn't clear to me (from amd64 manuals) that *FENCE affects caches other than ones seen by the current CPU. I think they do, and can be used (MFENCE might be needed for both). They should work for the same reasons that "LOCK MOV" is an invalid instruction (MOV is inherently atomic (?)). Apparently we are using fake "LOCK MOV"s just for the side effects of the lock instruction (at least on amd64's, the lock instruction does *FENCE implicitly). > MFENCE and LFENCE only exist on the P4. SFENCE only exists on P3+, so to do > so you'd lose the ability to run on PII's and earlier. Also, if you use more > than SFENCE you lose PIII's. Note that amd64 could probably be changed > though since they might all have fences, in which case that might be > something to benchmark on both UP and SMP to see what kind of difference it > makes. amd64 does have all fences. See the thread "RE: 4.7 vs 5.2.1 SMP/UP bridging performance" in freebsd-current for some benchmarks. Locked instructions seem to be relatively fast on amd64's (same as on old systems in cycles), with fences not much faster (about 15 instead of about 30 cycles IIRC). Fences on P4 make locking only twice as slow as on amd64 instead of 5-10 times slower. Bruce From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 09:07:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F12B16A4CE for ; Wed, 11 Aug 2004 09:07:01 +0000 (GMT) Received: from ivc-i.dp.uz.gov.ua (ivc-i.dp.uz.gov.ua [212.1.84.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35FED43D1F for ; Wed, 11 Aug 2004 09:06:56 +0000 (GMT) (envelope-from o.palij@dp.uz.gov.ua) Received: from s4dnepr.dp.uz.gov.ua ([10.6.105.15]) by ivc-i.dp.uz.gov.ua (8.12.11/8.12.11) with ESMTP id i7B96jl3020489 for ; Wed, 11 Aug 2004 12:06:49 +0300 Received: from dp.uz.gov.ua ([10.6.100.74]) by s4dnepr.dp.uz.gov.ua (Lotus Domino Release 5.0.10) with SMTP id 2004081112064389:4424 ; Wed, 11 Aug 2004 12:06:43 +0300 Date: Wed, 11 Aug 2004 12:06:42 +0300 From: Oleg Palij To: current@freebsd.org Message-Id: <20040811120642.503650b8@iscmpd-oleg.dp.uz.gov.ua> In-Reply-To: <07759232F85A5C7FC2256EED0022A18A.00281F3542256EED@dp.uz.gov.ua> References: <07759232F85A5C7FC2256EED0022A18A.00281F3542256EED@dp.uz.gov.ua> Organization: Pridn railway X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2.1) Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on s4dnepr/DNEPR/UKRZAL(Release 5.0.10 |March 22, 2002) at 08/11/2004 12:06:43 PM,2002) at 08/11/2004 12:06:49 PM, Serialize complete at 08/11/2004 12:06:49 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on ivc-i X-Virus-Status: Clean Subject: Re: panic with any version of smbd in 5.2.1-R X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 09:07:01 -0000 On Wed, 11 Aug 2004 09:18:14 +0200 owner-freebsd-current@freebsd.org wrote: > Panic happens with samba 2.2.8-2.2.10, 3.0.0-3.0.4. > I can't reproduce kernel panic but it happens frequently. > > # uname -a > FreeBSD iscmpd-oleg 5.2.1-RELEASE-p9 FreeBSD 5.2.1-RELEASE-p9 #0: Wed Aug 4 > 11:59:15 EEST 2004 root@iscmpd-oleg:/usr/obj/usr/src/sys/ISCMPD-OLEG_KERNEL > i386 > > Below is the gdb backtrace. > Additional info: (kgdb) call doadump $1 = {void (void)} 0xc05037f0 (kgdb) l *0xc055ba8f 0xc055ba8f is in quotactl (/usr/src/sys/kern/vfs_syscalls.c:206). 201 NDFREE(&nd, NDF_ONLY_PNBUF); 202 error = vn_start_write(nd.ni_vp, &mp, V_WAIT | PCATCH); 203 vrele(nd.ni_vp); 204 if (error) 205 return (error); 206 error = VFS_QUOTACTL(mp, uap->cmd, uap->uid, uap->arg, td); 207 vn_finished_write(mp); 208 return (error); 209 } 210 -- Best regards, Palij Oleg, ISC (Pridn railway) From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 09:13:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7704416A4CE; Wed, 11 Aug 2004 09:13:03 +0000 (GMT) Received: from saeab.se (ture.saeab.se [213.80.3.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34D2243D3F; Wed, 11 Aug 2004 09:13:02 +0000 (GMT) (envelope-from thn@saeab.se) Received: from saeab.se (omar.int.saeab.se [10.0.1.32]) by saeab.se (8.12.11/8.12.11) with ESMTP id i7B9CtC4018582; Wed, 11 Aug 2004 11:12:55 +0200 (CEST) (envelope-from thn@saeab.se) Message-ID: <4119E315.1E03688D@saeab.se> Date: Wed, 11 Aug 2004 11:12:53 +0200 From: Thomas Nystrom Organization: Sv. Aktuell Elektronik AB X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: sv,en MIME-Version: 1.0 To: Ruslan Ermilov References: <20040810231044.GA70020@xor.obsecurity.org> <20040811065912.GA95263@xor.obsecurity.org> <20040811080350.GK80234@ip.net.ua> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-6.0 required=5.0 tests=USER_IN_WHITELIST_TO autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on ture.saeab.se cc: Hartmut Brandt cc: current@freebsd.org cc: Kris Kennaway Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 09:13:03 -0000 Ruslan Ermilov wrote: > > Trying to set MAKEOBJDIRPREFIX in /etc/make.conf and attempting to buildworld > RELENG_4 on a 4.x machine similarly fails right away. > > The reason I'm writing this email is that I'm really interested in > reproducing the case where it could have possible worked before. Any help > on your side would be highly appreciated. > > The only case that I know of this could have worked (tested) is if make(1) > was instructed to prefer the MAKEOBJDIRPREFIX environment variable over a > global one, with ``make -E MAKEOBJDIRPREFIX''. Then setting MAKEOBJDIRPREFIX > in /etc/make.conf works. I have been using 'MAKEOBJDIRPREFIX?= /home/obj' (or similair) in /etc/make.conf for quite a long time now. NOTE: it must be '?='. I have used it on both 4.x and 5.x (latest 5.2.1-R). /thn -- --------------------------------------------------------------- Svensk Aktuell Elektronik AB Thomas Nyström Box 10 Phone: +46 8 35 92 85 S-191 21 Sollentuna Fax: +46 8 35 92 86 Sweden Email: thn@saeab.se --------------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 09:33:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72A1416A4CE; Wed, 11 Aug 2004 09:33:18 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AB0843D1F; Wed, 11 Aug 2004 09:33:17 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7B9WBTK069762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Aug 2004 12:32:12 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7B9WDd6085083; Wed, 11 Aug 2004 12:32:13 +0300 (EEST) (envelope-from ru) Date: Wed, 11 Aug 2004 12:32:13 +0300 From: Ruslan Ermilov To: Thomas Nystrom Message-ID: <20040811093213.GA84908@ip.net.ua> References: <20040810231044.GA70020@xor.obsecurity.org> <20040811061202.GA80234@ip.net.ua> <20040811065912.GA95263@xor.obsecurity.org> <20040811080350.GK80234@ip.net.ua> <4119E315.1E03688D@saeab.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <4119E315.1E03688D@saeab.se> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: Hartmut Brandt cc: current@freebsd.org cc: Kris Kennaway Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 09:33:18 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 11, 2004 at 11:12:53AM +0200, Thomas Nystrom wrote: > Ruslan Ermilov wrote: > >=20 > > Trying to set MAKEOBJDIRPREFIX in /etc/make.conf and attempting to buil= dworld > > RELENG_4 on a 4.x machine similarly fails right away. > >=20 > > The reason I'm writing this email is that I'm really interested in > > reproducing the case where it could have possible worked before. Any h= elp > > on your side would be highly appreciated. > >=20 > > The only case that I know of this could have worked (tested) is if make= (1) > > was instructed to prefer the MAKEOBJDIRPREFIX environment variable over= a > > global one, with ``make -E MAKEOBJDIRPREFIX''. Then setting MAKEOBJDIR= PREFIX > > in /etc/make.conf works. >=20 > I have been using 'MAKEOBJDIRPREFIX?=3D /home/obj' (or similair) in > /etc/make.conf for quite a long time now. NOTE: it must be '?=3D'. I have > used it on both 4.x and 5.x (latest 5.2.1-R). >=20 Yes, setting MAKEOBJDIRPREFIX?=3D in /etc/make.conf will work for "make buildworld", BUT FOR BUILDWORLD ONLY, because Makefile.inc1 will reset MAKEOBJDIRPREFIX in environment (as expected by make(1)) for all buildworld substages, correcting the user's mistake. In other words, it happens to magically work for a buildworld (and other world-related targets). OTOH, a plain "make" somewhere with MAKEOBJDIRPREFIX set both in environment (where make(1) expects to find it) and in /etc/make.conf will break. Compare: Good: # rm -rf /home/ru/obj # pwd /tmp/x # env MAKEOBJDIRPREFIX=3D/home/ru/obj make -f bsd.prog.mk whereobj /tmp/x # env MAKEOBJDIRPREFIX=3D/home/ru/obj make -f bsd.prog.mk obj /home/ru/obj/tmp/x created for /tmp/x # env MAKEOBJDIRPREFIX=3D/home/ru/obj make -f bsd.prog.mk whereobj /home/ru/obj/tmp/x Bad: # rm -rf /home/ru/obj # grep MAKEOBJDIRPREFIX /etc/make.conf=20 MAKEOBJDIRPREFIX?=3D /home/ru/obj # make -f bsd.prog.mk whereobj /tmp/x # make -f bsd.prog.mk obj /home/ru/obj/tmp/x created for /tmp/x # make -f bsd.prog.mk whereobj /tmp/x The "whereobj" target just prints the idea of the make(1)'s object directory (where object files get created, also the current working directory before make(1) starts to produce something). MAKEOBJDIRPREFIX in /etc/make.conf, in any form, is a strict "no no"! Fix it now, or you will get a ton of troubles some day. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGeedqRfpzJluFF4RAhCDAKCLzVuU7GdATgQ7bcKBuHQQnCWhlwCeJqcu hsJbzFrqNBAhKHfXN/3Fz2Y= =XsK3 -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 09:42:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7573C16A4CE; Wed, 11 Aug 2004 09:42:42 +0000 (GMT) Received: from mail017.syd.optusnet.com.au (mail017.syd.optusnet.com.au [211.29.132.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 540CB43D45; Wed, 11 Aug 2004 09:42:41 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) i7B9gdX20142; Wed, 11 Aug 2004 19:42:39 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])i7B9gdxP010624; Wed, 11 Aug 2004 19:42:39 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)i7B9gcLC010623; Wed, 11 Aug 2004 19:42:38 +1000 (EST) (envelope-from pjeremy) Date: Wed, 11 Aug 2004 19:42:38 +1000 From: Peter Jeremy To: Ruslan Ermilov Message-ID: <20040811094238.GB423@cirb503493.alcatel.com.au> References: <20040810231044.GA70020@xor.obsecurity.org> <20040811061202.GA80234@ip.net.ua> <20040811065912.GA95263@xor.obsecurity.org> <20040811080350.GK80234@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040811080350.GK80234@ip.net.ua> User-Agent: Mutt/1.4.2i cc: current@freebsd.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 09:42:42 -0000 On Wed, 2004-Aug-11 11:03:50 +0300, Ruslan Ermilov wrote: >Trying to set MAKEOBJDIRPREFIX in /etc/make.conf and attempting to buildworld >RELENG_4 on a 4.x machine similarly fails right away. I have a script that run on RELENG_4 and does make MAKEOBJDIRPREFIX=/usr/obj/k7 CPUTYPE=k7 buildworld >buildworld.k7 2>&1 & make MAKEOBJDIRPREFIX=/usr/obj/i486 CPUTYPE=i486 buildworld >buildworld.i486 2>&1 & make MAKEOBJDIRPREFIX=/usr/obj/i586 CPUTYPE=i586/mmx buildworld >buildworld.i586 2>&1 & This worked perfectly when I tried it on 1st August - at least the system compiled, installed and has been running since last weekend. I have another -STABLE system that has MAKEOBJDIRPREFIX in /etc/make.conf and runs build{world,kernel} happily every night. I admit I haven't tried using MAKEOBJDIRPREFIX on -CURRENT lately. Overall, I find it annoying that it is no longer possible to embed all the buildworld customisations in /etc/make.conf. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 10:11:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A43D16A4CE for ; Wed, 11 Aug 2004 10:11:21 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9099743D31 for ; Wed, 11 Aug 2004 10:11:20 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7BAAwJa074052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Aug 2004 13:10:59 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7BAB0nu085840 for current@freebsd.org; Wed, 11 Aug 2004 13:11:00 +0300 (EEST) (envelope-from ru) Date: Wed, 11 Aug 2004 13:11:00 +0300 From: Ruslan Ermilov To: current@freebsd.org Message-ID: <20040811101100.GB84908@ip.net.ua> References: <20040810231044.GA70020@xor.obsecurity.org> <20040811061202.GA80234@ip.net.ua> <20040811065912.GA95263@xor.obsecurity.org> <20040811080350.GK80234@ip.net.ua> <200408110916.i7B9GTj43770@Mail.NOSPAM.DynDNS.dK> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SkvwRMAIpAhPCcCJ" Content-Disposition: inline In-Reply-To: <200408110916.i7B9GTj43770@Mail.NOSPAM.DynDNS.dK> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new Subject: DISTDIR (was: Re: World broken in stage 1.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 10:11:21 -0000 --SkvwRMAIpAhPCcCJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 11, 2004 at 11:16:29AM +0200, Barry Bouwsma wrote: [...] > I used to set this in make.conf, but only as > MAKEOBJDIRPREFIX?=3D foo... > ^^ >=20 Please see my other email in this thread that explains in detail why it works, and why it should not be used. > Which brings up something else -- has there been any > resolution of the conflict between `DISTDIR' as used by > ports, and `DISTDIR' as used by the `distribute' targets? > I have the former set in my make.conf, which resulted in > some odd paths, no matter how I specified `DESTDIR=3D' and > `DISTDIR=3D' as both environment and `make' options when in > the top-level src directory, but resolved itself only when > given as an option within the `etc' subdirectory. >=20 > Not that I know how to use `distribute/distribution' at > all, but I saw that as one way to populate DESTDIR/etc. >=20 > (Shoot me if this has been resolved in a way I've failed > to catch during the months spent offline.) >=20 DISTDIR is only used by "make distribute", and the latter is only used by "make release". "make release" doesn't use /etc/make.conf. Where's the conflict? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --SkvwRMAIpAhPCcCJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGfC0qRfpzJluFF4RAn4gAJ0eWMFDJKsrgJ8dX+Yb38yVp2YHYQCfUuuU FVydpaGg7luWvra2YB+v4B8= =q71C -----END PGP SIGNATURE----- --SkvwRMAIpAhPCcCJ-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 10:28:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A381A16A4CE for ; Wed, 11 Aug 2004 10:28:29 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7DFF43D1D for ; Wed, 11 Aug 2004 10:28:28 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7BAS1RH075951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Aug 2004 13:28:02 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7BAS3hb085951; Wed, 11 Aug 2004 13:28:03 +0300 (EEST) (envelope-from ru) Date: Wed, 11 Aug 2004 13:28:03 +0300 From: Ruslan Ermilov To: Peter Jeremy Message-ID: <20040811102803.GD84908@ip.net.ua> References: <20040810231044.GA70020@xor.obsecurity.org> <20040811061202.GA80234@ip.net.ua> <20040811065912.GA95263@xor.obsecurity.org> <20040811080350.GK80234@ip.net.ua> <20040811094238.GB423@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qGV0fN9tzfkG3CxV" Content-Disposition: inline In-Reply-To: <20040811094238.GB423@cirb503493.alcatel.com.au> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: current@FreeBSD.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 10:28:29 -0000 --qGV0fN9tzfkG3CxV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Peter, On Wed, Aug 11, 2004 at 07:42:38PM +1000, Peter Jeremy wrote: > On Wed, 2004-Aug-11 11:03:50 +0300, Ruslan Ermilov wrote: > >Trying to set MAKEOBJDIRPREFIX in /etc/make.conf and attempting to build= world > >RELENG_4 on a 4.x machine similarly fails right away. >=20 > I have a script that run on RELENG_4 and does > make MAKEOBJDIRPREFIX=3D/usr/obj/k7 CPUTYPE=3Dk7 buildworld >buildworld.k= 7 2>&1 & > make MAKEOBJDIRPREFIX=3D/usr/obj/i486 CPUTYPE=3Di486 buildworld >buildwor= ld.i486 2>&1 & > make MAKEOBJDIRPREFIX=3D/usr/obj/i586 CPUTYPE=3Di586/mmx buildworld >buil= dworld.i586 2>&1 & >=20 > This worked perfectly when I tried it on 1st August - at least the > system compiled, installed and has been running since last weekend. I > have another -STABLE system that has MAKEOBJDIRPREFIX in > /etc/make.conf and runs build{world,kernel} happily every night. I > admit I haven't tried using MAKEOBJDIRPREFIX on -CURRENT lately. >=20 > Overall, I find it annoying that it is no longer possible to embed all > the buildworld customisations in /etc/make.conf. >=20 Did you read all my replies in this thread before posting this one? MAKEOBJDIRPREFIX has always been an environment variable, it has never been a command-line or global variable of make(1). What you describe should still work but in 4.x only (pass MAKEOBJDIRPREFIX as a command line variable), but only because Makefile.inc1 will properly reset it in environment. This is not by design, it just *happens to work* because Makefile.inc1 needs to reset MAKEOBJDIRPREFIX to different values depending on the current stage of buildworld. Last year, I changed make(1) in 5.x so it's possible to set MAKEOBJDIR[PREFIX] as a command line variable, and have it really work correctly (correctly =3D=3D make will switch to this directory and set .OBJDIR to point to it). This is still discouraged, and is not supported by a 4.x make(1). Since make(1) was recently change to propagate command line variables as command line variables to sub-makes, passing MAKEOBJDIRPREFIX as a command-line variable to buildworld will no longer work: command-line variables take precedence over environment variables, so what Makefile.inc1 will set in environment will be ignored by buildworld substages. So, the only One True Way to use MAKEOBJDIRPREFIX is as documented in the make(1) manpage, i.e., set it as environment variable. I will commit the enforcement into src/Makefile shortly. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --qGV0fN9tzfkG3CxV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGfSzqRfpzJluFF4RAopcAJ434V12aqvEDkFylvSjQlz7x0z3TwCghS9z v/chqiW/s5WecVNFGIZqzhU= =PKOD -----END PGP SIGNATURE----- --qGV0fN9tzfkG3CxV-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 10:44:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C525A16A4CF; Wed, 11 Aug 2004 10:44:20 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A39743D55; Wed, 11 Aug 2004 10:44:19 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i7BAiAX542632; Wed, 11 Aug 2004 12:44:11 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) i7BAiAf194712; Wed, 11 Aug 2004 12:44:10 +0200 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i7BAi9e23963; Wed, 11 Aug 2004 12:44:09 +0200 (MET DST) Date: Wed, 11 Aug 2004 12:44:09 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: Peter Jeremy In-Reply-To: <20040811094238.GB423@cirb503493.alcatel.com.au> Message-ID: <20040811124107.P86410@beagle.kn.op.dlr.de> References: <20040810231044.GA70020@xor.obsecurity.org> <20040811061202.GA80234@ip.net.ua><20040811080350.GK80234@ip.net.ua> <20040811094238.GB423@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2004 10:44:20 -0000 On Wed, 11 Aug 2004, Peter Jeremy wrote: PJ>On Wed, 2004-Aug-11 11:03:50 +0300, Ruslan Ermilov wrote: PJ>>Trying to set MAKEOBJDIRPREFIX in /etc/make.conf and attempting to buildworld PJ>>RELENG_4 on a 4.x machine similarly fails right away. PJ> PJ>I have a script that run on RELENG_4 and does PJ>make MAKEOBJDIRPREFIX=/usr/obj/k7 CPUTYPE=k7 buildworld >buildworld.k7 2>&1 & PJ>make MAKEOBJDIRPREFIX=/usr/obj/i486 CPUTYPE=i486 buildworld >buildworld.i486 2>&1 & PJ>make MAKEOBJDIRPREFIX=/usr/obj/i586 CPUTYPE=i586/mmx buildworld >buildworld.i586 2>&1 & PJ> PJ>This worked perfectly when I tried it on 1st August - at least the PJ>system compiled, installed and has been running since last weekend. I PJ>have another -STABLE system that has MAKEOBJDIRPREFIX in PJ>/etc/make.conf and runs build{world,kernel} happily every night. I PJ>admit I haven't tried using MAKEOBJDIRPREFIX on -CURRENT lately. PJ> PJ>Overall, I find it annoying that it is no longer possible to embed all PJ>the buildworld customisations in /etc/make.conf. Just to be sure I tried it on ref4 with the following make.conf and a fresh RELENG_4 source tree: MAKEOBJDIRPREFIX=/k/scratch/harti/obj Buildworld fails right from the start, so I wonder how THAT worked for you: Script started on Wed Aug 11 10:39:26 2004 -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf /k/scratch/harti/obj/k/scratch/harti/stable/src/i386 mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/bin mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/lib/compat/aout mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/games mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/libdata/ldscripts mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/libexec/elf mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/sbin mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/share/misc mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/share/dict mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/share/groff_font/devX100 mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/share/groff_font/devX100-12 mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/share/groff_font/devX75 mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/share/groff_font/devX75-12 mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/share/groff_font/devascii mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/share/groff_font/devcp1047 mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/share/groff_font/devdvi mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/share/groff_font/devhtml mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/share/groff_font/devkoi8-r mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/share/groff_font/devlatin1 mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/share/groff_font/devlbp mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/share/groff_font/devlj4 mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/share/groff_font/devps mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/share/groff_font/devutf8 mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/share/tmac/mdoc mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/share/tmac/mm mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/include/arpa mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/include/dev mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/include/fs mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/include/g++/std mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/include/isc mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/include/isofs mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/include/libmilter mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/include/objc mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/include/openssl mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/include/protocols mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/include/readline mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/include/rpc mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/include/rpcsvc mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/include/security mkdir -p /k/scratch/harti/obj/k/scratch/harti/stable/src/i386/usr/include/ufs ln -sf /k/scratch/harti/stable/src/sys /k/scratch/harti/obj/k/scratch/harti/stable/src/i386 -------------------------------------------------------------- >>> stage 1: bootstrap tools -------------------------------------------------------------- cd /k/scratch/harti/stable/src; MAKEOBJDIRPREFIX=/k/scratch/harti/obj/k/scratch/harti/stable/src/i386 DESTDIR= INSTALL="sh /k/scratch/harti/stable/src/tools/install.sh" make -f Makefile.inc1 -DBOOTSTRAPPING -DNOHTML -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -DNO_WERROR bootstrap-tools echo "===> games/fortune/strfile"; cd /k/scratch/harti/stable/src/games/fortune/strfile; make DIRPRFX=games/fortune/strfile/ obj; make DIRPRFX=games/fortune/strfile/ depend; make DIRPRFX=games/fortune/strfile/ all; make DIRPRFX=games/fortune/strfile/ DESTDIR=/k/scratch/harti/obj install ===> games/fortune/strfile sh /k/scratch/harti/stable/src/tools/install.sh -s -o root -g wheel -m 555 strfile /k/scratch/harti/obj/usr/games install: /k/scratch/harti/obj/usr/games: No such file or directory *** Error code 71 Stop in /k/scratch/harti/stable/src/games/fortune/strfile. *** Error code 1 Stop in /k/scratch/harti/stable/src. *** Error code 1 Stop in /k/scratch/harti/stable/src. *** Error code 1 Stop in /k/scratch/harti/stable/src. Script done on Wed Aug 11 10:39:26 2004 From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 10:46:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5115D16A4CE for ; Wed, 11 Aug 2004 10:46:54 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 721C843D3F for ; Wed, 11 Aug 2004 10:46:53 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i7BAkpdF012669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Aug 2004 14:46:52 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i7BAkpQq012668; Wed, 11 Aug 2004 14:46:51 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Wed, 11 Aug 2004 14:46:51 +0400 From: Gleb Smirnoff To: freebsd-current@freebsd.org Message-ID: <20040811104651.GC12501@cell.sick.ru> References: <20040726132842.GA98330@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040726132842.GA98330@cell.sick.ru> User-Agent: Mutt/1.5.6i Subject: Duplicate free of item %p from zone( Was: suspend/resume problems (APM) on Thinkpad T40) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 10:46:54 -0000 On Mon, Jul 26, 2004 at 05:28:42PM +0400, Gleb Smirnoff wrote: T> On Mon, Jul 26, 2004 at 03:06:16PM +0200, Anders Odberg wrote: T> A> I have a Thinkpad T40 (model 2373-94G) running FreeBSD-5-CURRENT. Until the T> A> beginning of June, using APM to suspend/resume worked great on this T> A> machine. On every cvsup I've tried after the beginning of June, suspend T> A> seems to work fine, but when resuming, the machine will simply freeze. T> A> I get my prompt back on the display, but no input is accepted, the machine T> A> is completely dead, and needs to be power-cycled. I have got a backtrace today: (kgdb) bt #0 doadump () at pcpu.h:159 #1 0xc054005a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:391 #2 0xc05403c8 in panic (fmt=0xc06ece45 "Duplicate free of item %p from zone %p(%s)\n") at /usr/src/sys/kern/kern_shutdown.c:553 #3 0xc0654914 in uma_dbg_free (zone=0xc1044c60, slab=0xc1ad8f70, item=0xc1ad84a4) at /usr/src/sys/vm/uma_dbg.c:276 #4 0xc06531b1 in uma_zfree_arg (zone=0xc1044c60, item=0xc1ad84a4, udata=0x0) at /usr/src/sys/vm/uma_core.c:2222 #5 0xc0504872 in g_destroy_bio (bp=0x0) at uma.h:302 #6 0xc0507e53 in g_std_done (bp=0x0) at /usr/src/sys/geom/geom_subr.c:752 #7 0xc05940a0 in biodone (bp=0xc1ad84a4) at /usr/src/sys/kern/vfs_bio.c:3002 #8 0xc048c9d2 in ad_done (request=0xc1723000) at /usr/src/sys/dev/ata/ata-disk.c:322 #9 0xc047bcbc in ata_completed (context=0xc1723000, dummy=0) at /usr/src/sys/dev/ata/ata-queue.c:404 #10 0xc047be0c in ata_timeout (request=0xc1723000) at /usr/src/sys/dev/ata/ata-queue.c:442 #11 0xc054e9e8 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:255 #12 0xc0528722 in ithread_loop (arg=0xc14f4580) at /usr/src/sys/kern/kern_intr.c:546 #13 0xc0527786 in fork_exit (callout=0xc05285b0 , arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:819 #14 0xc0682ebc in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209 Afte resume I can move mouse in X for some time, type smth. And in a few seconds panic. Hardware is Thinkpad T20. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 11:20:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F138A16A4CE for ; Wed, 11 Aug 2004 11:20:30 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B7E143D1F for ; Wed, 11 Aug 2004 11:20:30 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7BBI118081123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Aug 2004 14:18:02 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7BBI3oX088503; Wed, 11 Aug 2004 14:18:03 +0300 (EEST) (envelope-from ru) Date: Wed, 11 Aug 2004 14:18:03 +0300 From: Ruslan Ermilov To: Barry Bouwsma Message-ID: <20040811111803.GJ84908@ip.net.ua> References: <20040810231044.GA70020@xor.obsecurity.org> <20040811061202.GA80234@ip.net.ua> <20040811065912.GA95263@xor.obsecurity.org> <20040811080350.GK80234@ip.net.ua> <200408110916.i7B9GTj43770@Mail.NOSPAM.DynDNS.dK> <20040811101100.GB84908@ip.net.ua> <200408111058.i7BAwn244128@Mail.NOSPAM.DynDNS.dK> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j+MD90OnwjQyWNYt" Content-Disposition: inline In-Reply-To: <200408111058.i7BAwn244128@Mail.NOSPAM.DynDNS.dK> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: current@freebsd.org Subject: Re: DISTDIR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 11:20:31 -0000 --j+MD90OnwjQyWNYt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 11, 2004 at 12:58:50PM +0200, Barry Bouwsma wrote: > > > MAKEOBJDIRPREFIX?=3D foo... > > > ^^ > > Please see my other email in this thread that explains in detail > > why it works, and why it should not be used. >=20 > Understood. Methinks that MAKEOBJDIRPREFIX is getting to > be a bit overloaded, as something that can be set by the > user, as well as something that gets set during the build. >=20 During the build, buildworld respects the user's setting by only *adding* to what the user has specified as MAKEOBJDIRPREFIX, so there's no problem here. > Anyway, I agree that it would be nice if there would be > something that can be set in a make.conf which determines > where the build happens, rather than it be dependent on > an environment variable only. >=20 MAKEOBJDIRPREFIX is not limited to buildworld only, it's a feature of make(1). OTOH, if you want some knob for /etc/make.conf to control what MAKEOBJDIRPREFIX will be set to during buildworld and related targets, this should be possible easily, though I personally don't see much point in yet another variable. > > > Which brings up something else -- has there been any > > > resolution of the conflict between `DISTDIR' as used by > > > ports, and `DISTDIR' as used by the `distribute' targets? >=20 > > DISTDIR is only used by "make distribute", and the latter > > is only used by "make release". "make release" doesn't > > use /etc/make.conf. Where's the conflict? >=20 > Ah, that I had been using `make distribute' or similar in > order to populate DESTDIR/etc after a `make installworld', > which is probably not what I should have been doing. (After > a crossbuild, I wanted to fill DESTDIR with everything, > including etc, as if installing a virgin installation. > There's probably a Right Way to do this that I don't know.) >=20 The correct spelling would be "make distrib-dirs && make distribution" while in /usr/src/etc, but it does not use DISTDIR either. "make distibute" while in /usr/src/etc uses DISTDIR, but it should not be called by the end user, it's called as part of "make release" to install the system into various release distributions. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --j+MD90OnwjQyWNYt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGgBqqRfpzJluFF4RAuXCAKCH1n+6uERq5Q7PKD3sW+8GTn2d0ACglG0k qFdppQiYIZGGVXHd/jY4P1o= =4ghl -----END PGP SIGNATURE----- --j+MD90OnwjQyWNYt-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 11:26:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6C8916A4CE; Wed, 11 Aug 2004 11:26:13 +0000 (GMT) Received: from lakermmtao02.cox.net (lakermmtao02.cox.net [68.230.240.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1650843D1D; Wed, 11 Aug 2004 11:26:13 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.71.51]) by lakermmtao02.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040811112612.WSOK1467.lakermmtao02.cox.net@dolphin.local.net>; Wed, 11 Aug 2004 07:26:12 -0400 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with ESMTP id i7BBQBee005108; Wed, 11 Aug 2004 06:26:11 -0500 (CDT) (envelope-from conrads@dolphin.local.net) Received: (from conrads@localhost) by dolphin.local.net (8.13.1/8.13.1/Submit) id i7BBQ6Od005107; Wed, 11 Aug 2004 06:26:06 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <49521.66.13.175.242.1092194974.squirrel@[66.13.175.242]> Date: Wed, 11 Aug 2004 06:26:06 -0500 (CDT) Organization: A Rag-Tag Band of Drug-Crazed Hippies From: "Conrad J. Sabatier" To: Rusty Nejdl cc: Don Lewis cc: freebsd-current@FreeBSD.org cc: dnelson@allantgroup.com Subject: Re: Is anything being done re: the pcm timeout issue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conrads@cox.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2004 11:26:13 -0000 On 11-Aug-2004 Rusty Nejdl wrote: > >>> >>> And I have seen that these will eventually stop working one by one >>> until I have none left. lsof and fstat don't show any programs >>> using >>> them, but nonetheless, programms like xmms and gaim can't use them >>> anymore. > > Well, try as much as I could, I haven't been able to duplicate this > tonight. I've got 4 vchans setup and I was running madplay > continuously on 4 channels for 4 hours and it worked the whole time. > >> >> The vchan code is fairly broken. I was hoping to have to some time >> to >> work on this (and other problems in the top half of the sound code) >> before >> 5.3, but it looks like the clock has just about run out. > > I'm not seeing the locked channels yet, but that doesn't mean that > they aren't there. I do appreciate your looking into this matter. So far, with my latest kernel, I haven't experienced the problem yet, either. Which doesn't necessarily mean, of course, that I still won't. :-) There's definitely the possibility that it's not really a sound issue at all, but just the drivers' sensitivity to something else going on in the kernel. Unfortunately, my knowledge/understanding of the low-level operations of the kernel is practically nil, so I really can't comment on that in any sort of intelligent or useful fashion. :-) I'll keep my fingers crossed here; maybe the problem will just "go away" (or already has). :-) I'll keep you posted if I still see any problems. Thanks again. -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 11:29:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C5AE16A4CE; Wed, 11 Aug 2004 11:29:41 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BB3E43D3F; Wed, 11 Aug 2004 11:29:40 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7BBRSrn082214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Aug 2004 14:27:29 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7BBRUrd088633; Wed, 11 Aug 2004 14:27:30 +0300 (EEST) (envelope-from ru) Date: Wed, 11 Aug 2004 14:27:30 +0300 From: Ruslan Ermilov To: Hartmut Brandt Message-ID: <20040811112730.GM84908@ip.net.ua> Mail-Followup-To: current@FreeBSD.org References: <20040810231044.GA70020@xor.obsecurity.org> <20040811061202.GA80234@ip.net.ua> <20040811065912.GA95263@xor.obsecurity.org> <20040811080350.GK80234@ip.net.ua> <20040811094238.GB423@cirb503493.alcatel.com.au> <20040811124107.P86410@beagle.kn.op.dlr.de> <20040811110511.GH84908@ip.net.ua> <20040811130804.M86410@beagle.kn.op.dlr.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="um2V5WpqCyd73IVb" Content-Disposition: inline In-Reply-To: <20040811130804.M86410@beagle.kn.op.dlr.de> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: current@FreeBSD.org Subject: MAKEOBJDIRPREFIX X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: 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, 11 Aug 2004 11:29:41 -0000 --um2V5WpqCyd73IVb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sorry, but I just couldn't resist. ;) On Wed, Aug 11, 2004 at 01:14:41PM +0200, Harti Brandt wrote: > MAKEOBJDIRPREFIX is now probably the best documented feature in FreeBSD.= =20 > We need to get a mention into the handbook, onto the website and on=20 > slashdot still. Then we have it everywhere :-) >=20 You forgot an UPDATING entry and a HEADS UP to current@, and bumping the __FreeBSD_version to still allow setting MAKEOBJDIRPREFIX in /etc/make.conf (for buildworld only) for those with older systems, then updating the Porter's Handbook would probably be the last thing. Did I miss anything? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --um2V5WpqCyd73IVb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGgKiqRfpzJluFF4RAjA3AJ96UvSXhVvya0Ob1XoD8Wp+9UeEQACeM6as gj7whqaNUIW5fTjm3RBr7ck= =rEK+ -----END PGP SIGNATURE----- --um2V5WpqCyd73IVb-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 12:07:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D02E816A4CE for ; Wed, 11 Aug 2004 12:07:33 +0000 (GMT) Received: from av5-2-sn1.fre.skanova.net (av5-2-sn1.fre.skanova.net [81.228.11.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C1C843D5A for ; Wed, 11 Aug 2004 12:07:33 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av5-2-sn1.fre.skanova.net (Postfix, from userid 502) id B50DE37EBA; Wed, 11 Aug 2004 14:07:32 +0200 (CEST) Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av5-2-sn1.fre.skanova.net (Postfix) with ESMTP id A502E37E5C; Wed, 11 Aug 2004 14:07:32 +0200 (CEST) Received: from gadget (h130n1fls11o822.telia.com [213.64.66.130]) by smtp3-1-sn1.fre.skanova.net (Postfix) with ESMTP id 77C3937E44; Wed, 11 Aug 2004 14:07:32 +0200 (CEST) From: "Daniel Eriksson" To: =?iso-8859-1?Q?'S=F8ren_Schmidt'?= Date: Wed, 11 Aug 2004 14:07:29 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcR9jGeWA5qoddy5Rd+Gw06RxTqnsQAuTKEQAFU1AyA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 cc: freebsd-current@freebsd.org cc: 'Ville-Pertti Keinonen' Subject: RE: ATA driver races with interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 12:07:33 -0000 I wrote: > I have two 250GB SATA discs, one Western Digital and one Maxtor. > After looking at the logs from today, and grep'ing some old logs, > I noticed that it seems more common for the channel with the WD > disc to lock up. My logs don't go back far enough that I can say > it has always been like that, but it looks that way from the logs > right now [...] It was purely coincidental. Today the channel with the Maxtor disc locked up. I also know I've seen lockups on both channels. Plus I've switched SATA cables at least once. > I have updated my system to sources from 2004.08.09.13.00.00 > without any patches (because I saw some commits to the ATA code > in the last couple of days). The base code now allows me to at > least start the SMART monitor and run some stress tests. I'll > report back when/if it fails. Unfortunately it didn't take too long for it to lock up. After 42 hours of uptime with very light I/O load on the SATA discs (plus the SMART monitor), one of the channels locked up. No interesting messages in the logs, just the normal "removed from configuration" message I've reported before. Any suggestions on how to proceed? /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 12:20:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7F5816A4D3 for ; Wed, 11 Aug 2004 12:20:20 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8CC143D53 for ; Wed, 11 Aug 2004 12:20:19 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [172.18.2.1] (csc-gw1.novi.dk [130.225.63.24]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i7BCKCG0066508; Wed, 11 Aug 2004 14:20:17 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <411A0EF0.4090808@DeepCore.dk> Date: Wed, 11 Aug 2004 14:20:00 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eriksson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: freebsd-current@freebsd.org cc: 'Ville-Pertti Keinonen' Subject: Re: ATA driver races with interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 12:20:20 -0000 Daniel Eriksson wrote: > Unfortunately it didn't take too long for it to lock up. After 42 hours= of > uptime with very light I/O load on the SATA discs (plus the SMART monit= or), > one of the channels locked up. No interesting messages in the logs, jus= t the > normal "removed from configuration" message I've reported before. >=20 > Any suggestions on how to proceed? How about not running the SMART monitor ? The SMART monitor issues ATA commands from userland and could do some=20 major footshooting, so lets get that out of the loop and concentrate on=20 "pure" ATA driver details for now. Let me know how that goes.... -S=F8ren From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 12:24:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DF6C16A4CE for ; Wed, 11 Aug 2004 12:24:14 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73B9D43D2F for ; Wed, 11 Aug 2004 12:24:13 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7BCLVSf091832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Aug 2004 15:21:32 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7BCLXRb089129 for current@FreeBSD.org; Wed, 11 Aug 2004 15:21:33 +0300 (EEST) (envelope-from ru) Date: Wed, 11 Aug 2004 15:21:33 +0300 From: Ruslan Ermilov To: current@FreeBSD.org Message-ID: <20040811122133.GA89007@ip.net.ua> References: <20040810231044.GA70020@xor.obsecurity.org> <20040811061202.GA80234@ip.net.ua> <20040811065912.GA95263@xor.obsecurity.org> <20040811080350.GK80234@ip.net.ua> <200408110916.i7B9GTj43770@Mail.NOSPAM.DynDNS.dK> <20040811101100.GB84908@ip.net.ua> <200408111058.i7BAwn244128@Mail.NOSPAM.DynDNS.dK> <20040811111803.GJ84908@ip.net.ua> <200408111152.i7BBq0l44279@Mail.NOSPAM.DynDNS.dK> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <200408111152.i7BBq0l44279@Mail.NOSPAM.DynDNS.dK> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new Subject: Re: DISTDIR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 12:24:14 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 11, 2004 at 01:52:01PM +0200, Barry Bouwsma wrote: > > The correct spelling would be "make distrib-dirs && make > > distribution" while in /usr/src/etc, but it does not use > > DISTDIR either. "make distibute" while in /usr/src/etc > > uses DISTDIR, but it should not be called by the end user, >=20 > This is what I noticed, not knowing which was right, when I > was testing to see what worked. Anyway, then I did the > `make distribution' with success -- I believe the `distrib-dirs' > step was part of the `installworld'. If not, I'll be doing it > all again next buildworld, just for practice... >=20 I don't use mergemaster(8), so I still use the old good way to update /etc, etc.: dir=3D/var/tmp/`date +%Y%m%d` mkdir -p ${dir} cd /usr/src/etc make distrib-dirs DESTDIR=3D${dir} make distribution DESTDIR=3D${dir} By saving the previous contents of /var/tmp/, and comparing it with the current one, I update my /etc. > Thanks for the clarification, and straightening everything up. >=20 We're here to help you. ;) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGg9MqRfpzJluFF4RAtmhAJ4kViTlL2unzo7Ya02G8Kvz2WlTNQCdHpku +SZwoyaU+mPbAv20hqfrlPU= =OTZY -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 15:26:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09D7C16A4CE for ; Tue, 10 Aug 2004 15:26:49 +0000 (GMT) Received: from bsd.ultra-secure.de (bsd.ultra-secure.de [62.146.20.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9B1343D48 for ; Tue, 10 Aug 2004 15:26:47 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: (qmail 30259 invoked by uid 89); 10 Aug 2004 15:26:46 -0000 Message-ID: <20040810152646.30258.qmail@bsd.ultra-secure.de> From: Rainer Duffner To: freebsd-current@freebsd.org Date: Tue, 10 Aug 2004 17:26:46 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 11 Aug 2004 12:26:24 +0000 Subject: buildworld problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 15:26:49 -0000 Hi, I get this: .... mkdep -f .depend -a -DRRESTORE -DRESCUE /usr/src/sbin/restore/main.c /usr/src/sbin/restore/interactive.c /usr/src/sbin/restore/restore.c /usr/src/sbin/restore/dirs.c /usr/src/sbin/restore/symtab.c /usr/src/sbin/restore/tape.c /usr/src/sbin/restore/utilities.c /usr/src/sbin/restore/../dump/dumprmt.c echo restore: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend cc -O -pipe -DRRESTORE -DRESCUE -c /usr/src/sbin/restore/main.c cc -O -pipe -DRRESTORE -DRESCUE -c /usr/src/sbin/restore/interactive.c cc -O -pipe -DRRESTORE -DRESCUE -c /usr/src/sbin/restore/restore.c cc -O -pipe -DRRESTORE -DRESCUE -c /usr/src/sbin/restore/dirs.c cc -O -pipe -DRRESTORE -DRESCUE -c /usr/src/sbin/restore/symtab.c cc -O -pipe -DRRESTORE -DRESCUE -c /usr/src/sbin/restore/tape.c cc -O -pipe -DRRESTORE -DRESCUE -c /usr/src/sbin/restore/utilities.c cc -O -pipe -DRRESTORE -DRESCUE -c /usr/src/sbin/restore/../dump/dumprmt.c (cd /usr/src/rescue/rescue/../../sbin/rcorder && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE ealloc.o hash.o rcorder.o) ln -sf /usr/src/sbin/rcorder/../../lib/libutil/libutil.h util.h rm -f .depend mkdep -f .depend -a -DORDER -I. -DRESCUE /usr/src/sbin/rcorder/ealloc.c /usr/src/sbin/rcorder/hash.c /usr/src/sbin/rcorder/rcorder.c echo rcorder: /usr/obj/usr/src/i386/usr/lib/libc.a /usr/obj/usr/src/i386/usr/lib/libutil.a >> .depend cc -O -pipe -DORDER -I. -DRESCUE -c /usr/src/sbin/rcorder/ealloc.c cc -O -pipe -DORDER -I. -DRESCUE -c /usr/src/sbin/rcorder/hash.c cc -O -pipe -DORDER -I. -DRESCUE -c /usr/src/sbin/rcorder/rcorder.c (cd /usr/src/rescue/rescue/../../sbin/route && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE route.o) sed -e '/^#/d' -e '/^$/d' /usr/src/sbin/route/keywords > _keywords.tmp LC_ALL=C tr 'a-z' 'A-Z' < _keywords.tmp | paste _keywords.tmp - | awk '{ if (NF > 1) printf "#define\tK_%s\t%d\n\t{\"%s\", K_%s},\n", $2, NR, $1, $2 }' > keywords.h rm -f _keywords.tmp rm -f .depend mkdep -f .depend -a -I. -DNS -DINET6 -DRESCUE /usr/src/sbin/route/route.c echo route: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend cc -O -pipe -I. -Wall -DNS -DINET6 -DRESCUE -c /usr/src/sbin/route/route.c (cd /usr/src/rescue/rescue/../../sbin/routed && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE if.o input.o main.o output.o parms.o radix.o rdisc.o table.o trace.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/routed/if.c /usr/src/sbin/routed/input.c /usr/src/sbin/routed/main.c /usr/src/sbin/routed/output.c /usr/src/sbin/routed/parms.c /usr/src/sbin/routed/radix.c /usr/src/sbin/routed/rdisc.c /usr/src/sbin/routed/table.c /usr/src/sbin/routed/trace.c echo routed: /usr/obj/usr/src/i386/usr/lib/libc.a /usr/obj/usr/src/i386/usr/lib/libmd.a >> .depend +for: not found *** Error code 127 Stop in /usr/src/sbin/routed. *** Error code 1 Stop in /usr/obj/usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Has this been fixed ? Or where would I need to look ? Rainer From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 22:44:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F00D016A4CE; Tue, 10 Aug 2004 22:44:55 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (80-219-164-131.dclient.hispeed.ch [80.219.164.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9A7643D48; Tue, 10 Aug 2004 22:44:53 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:50db:a483:0:20e:2eff:fe06:2376]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id i7AMigh14189 verified NO); Wed, 11 Aug 2004 00:44:47 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id i7AMid614188; Wed, 11 Aug 2004 00:44:40 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Wed, 11 Aug 2004 00:44:40 +0200 (CEST) Message-Id: <200408102244.i7AMid614188@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma References: <200407200045.aa99979@salmon.maths.tcd.ie> <200407271843.aa10377@salmon.maths.tcd.ie> To: freebsd-current@freebsd.org X-Mailman-Approved-At: Wed, 11 Aug 2004 12:26:24 +0000 cc: Ian Dowse cc: freebsd-stable@freebsd.org cc: Julian Elischer Subject: Re: Unloading USB driver while device is attached. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Aug 2004 22:44:56 -0000 [keep replies to the list and I'll catch up later, thanks] [posted to -stable as well, as that's what I'm running so it could be of interest there, for the daring and headstrong] Two weeks ago (shows how far behind I am), Ian Dowse wrote to freebsd-current: > In message <200407200045.aa99979@salmon.maths.tcd.ie>, Ian Dowse writes: > >>: http://people.freebsd.org/~iedowse/usb.diff > FYI, I've updated this patch to the latest -CURRENT, and finished > an initial attempt at support for EHCI interrupt pipes. The interrupt > pipe support is likely to be fairly broken, but it seems to be > enough to allow attachment of USB2 hubs and at least some USB2 > devices through USB2 hubs; I have only tested it with a USB2 umass > device connected through a USB2 hub. USB1 devices will definitely > not work via USB2 hubs, as none of the split transaction support > is there. This looks like great fun. I've taken this and -current dev/usb source from 10.Aug (last changed 08.Aug) and gotten at least part of this combination to work under my RELENG_4 system. I no longer see the need_toggle_updates that froze my disk, from my previous attempt to merge in -current code, and I've got that disk attached now via a USB2 hub. There is a slight performance degradation going through the hub measured by throughput (5,9MB/sec direct, 5,1MB/sec via hub) on my ten-year-old machine, and now that I'm continuing my world build via USB instead of firewire, the machine seems decidedly sluggish. The `system' CPU slice according to `top' hovers between 30 and 70% most of the time, but I haven't watched it with either firewire or bypassing the hub and going direct. This is all probably to be expected anyway. I haven't even gotten to the point of trying to merge in my various hacks that I needed to apply to earlier code, some of which seem to no longer be needed. I'm using usb.ko, umass.ko, and ums.ko, as well as loaded-but- not-in-use ugen.ko out of the modules built from this directory in -current, on my -stable box. Is there any interest out there in my hacks to be used with -stable, pulling the latest code from -current? If so, I'll try to clean them up to make them presentable and to remain compatible with a -current build as well. (If nothing else, this diff created from my hacks would be up-to-date against 08.aug -current source.) I haven't really pounded on things either. But the advantage I see from this (compared with my earlier code) is functioning EHCI umass support, and USB2 hubs with USB2 devices attached, which has to be good for something. And it hasn't died yet. thanks barry bouwsma From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 00:14:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAB5616A4CE for ; Wed, 11 Aug 2004 00:14:53 +0000 (GMT) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B10F43D3F for ; Wed, 11 Aug 2004 00:14:52 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-a001.otenet.gr [212.205.215.1]) i7B0EnW3018206 for ; Wed, 11 Aug 2004 03:14:50 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.1/8.13.1) with ESMTP id i7B0E96G016385 for ; Wed, 11 Aug 2004 03:14:10 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.gr (8.13.1/8.13.1/Submit) id i7B0E9on016384 for freebsd-current@freebsd.org; Wed, 11 Aug 2004 03:14:09 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Wed, 11 Aug 2004 03:14:09 +0300 From: Giorgos Keramidas To: freebsd-current@freebsd.org Message-ID: <20040811001407.GB15795@gothmog.gr> References: <20040810210918.GS991@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040810210918.GS991@funkthat.com> X-Mailman-Approved-At: Wed, 11 Aug 2004 12:26:24 +0000 Subject: Re: have you installworld'd since Friday? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 00:14:53 -0000 On 2004-08-10 14:09, John-Mark Gurney wrote: > If you have, please send me a private email telling me approximately > when you cvsup'd your sources (or just ident /boot/defaults/loader.conf), > and if after installworld, you did, or did not have problems loading > kernel modules, such as acpi? I'm running this version at home: $ uname -a FreeBSD gothmog.gr 5.2-CURRENT FreeBSD 5.2-CURRENT #1: \ Sat Aug 7 15:35:17 EEST 2004 \ toor@gothmog.gr:/usr/obj/usr/src/sys/CELERON i386 Here's the ident output too: $ ident /boot/defaults/loader.conf /boot/defaults/loader.conf: $FreeBSD: src/sys/boot/forth/loader.conf,v 1.85 2004/08/06 15:06:06 jmg Exp $ > This is to help me better understand if the kernel module issue is a > wide spread issue, or something wrong with a few existing users. Modules load fine here too: $ kldstat Id Refs Address Size Name 1 5 0xc0400000 39c390 kernel 2 14 0xc079d000 52e08 acpi.ko 3 1 0xc1893000 2000 star_saver.ko I don't know if this helps at all though :-/ From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 03:55:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C5A616A4CE; Wed, 11 Aug 2004 03:55:34 +0000 (GMT) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CB4C43D4C; Wed, 11 Aug 2004 03:55:33 +0000 (GMT) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.34) id 1BukNi-0003S6-FW; Wed, 11 Aug 2004 11:06:30 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.12.10/8.12.10) with ESMTP id i7B3ti0m044736; Wed, 11 Aug 2004 10:55:44 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.12.10/8.12.10/Submit) id i7B3tiON044734; Wed, 11 Aug 2004 10:55:44 +0700 (NOVST) (envelope-from danfe) Date: Wed, 11 Aug 2004 10:55:44 +0700 From: Alexey Dokuchaev To: "Marc G. Fournier" Message-ID: <20040811035543.GA42117@regency.nsu.ru> References: <20040810043034.GA61300@regency.nsu.ru> <20040810122619.GB18408@ip.net.ua> <20040810225929.L62519@ganymede.hub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040810225929.L62519@ganymede.hub.org> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Wed, 11 Aug 2004 12:26:24 +0000 cc: harti@freebsd.org cc: current@freebsd.org Subject: Re: snmp_atm is broken? (world does not build) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 03:55:34 -0000 On Tue, Aug 10, 2004 at 11:00:48PM -0300, Marc G. Fournier wrote: > On Tue, 10 Aug 2004, Ruslan Ermilov wrote: > > >On Tue, Aug 10, 2004 at 11:30:34AM +0700, Alexey Dokuchaev wrote: > >>Hi there, > >> > >>Today's world does not build, failing in snmp_atm: > >> > >>===> lib/libbsnmp/modules/snmp_atm > >>make: don't know how to make snmp_atm.h. Stop > >>*** Error code 2 > >> > >[...] > > > >>>From src/lib/libbsnmp/modules/snmp_atm/Makefile rev. 1.1 I see: > >> > >>SNMP_ATM=${.CURDIR}/../../../../contrib/ngatm/snmp_atm > >>INCS= snmp_${MOD}.h > >>CFLAGS+= -I${SNMP_ATM} > >> > >>but /usr/src/contrib/ngatm/snmp_atm is missing. Can you investigate? > >>If you are not responsible for this, please accept my apologies and > >>ignore this letter. :) > >> > >How many times must it be said? If you're running/using -CURRENT, > >please get yourself subscribed and *read* the current@ mailing list. > >There have been a ton of these reports already, and the issue is > >being worked on. Yeah, I guess that I'll subscribe. List traffic seems to be killing though. ;-) > > In Alexey's defense, his is the first report that I've found watching the > lists for this particular problem, since his is the first that (again, > I've seen) is quite specific in the subject, instead of just 'buildworld > fails' ... :( Thanks Marc. I appreciated it. ./danfe From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 09:16:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 866F816A4CE; Wed, 11 Aug 2004 09:16:44 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (80-219-164-131.dclient.hispeed.ch [80.219.164.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F01343D55; Wed, 11 Aug 2004 09:16:42 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:50db:a483:0:20e:2eff:fe06:2376]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id i7B9GVh43771 verified NO); Wed, 11 Aug 2004 11:16:39 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id i7B9GTj43770; Wed, 11 Aug 2004 11:16:29 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Wed, 11 Aug 2004 11:16:29 +0200 (CEST) Message-Id: <200408110916.i7B9GTj43770@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma To: Ruslan Ermilov References: <20040810231044.GA70020@xor.obsecurity.org> <20040811061202.GA80234@ip.net.ua> <20040811065912.GA95263@xor.obsecurity.org> <20040811080350.GK80234@ip.net.ua> X-Mailman-Approved-At: Wed, 11 Aug 2004 12:26:24 +0000 cc: current@freebsd.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 09:16:44 -0000 [keep replies to the list and I'll catch up later, thanks] > > Well, happy POLA violation to you too; this worked until now. Please > > add text to make.conf explaining the new order. > Can you prove that it worked? I tried to no avail with the old > (August 1 2004, before the changes) make(1) and MAKEOBJDIRPREFIX > set in /etc/make.conf, to try to buildworld, and it always fails. I used to set this in make.conf, but only as MAKEOBJDIRPREFIX?= foo... ^^ Lately I haven't been building normally (doing exclusively crossbuilds, with commandline scripts where I explicitly set env variables), but I should try migrating things back into the specified make.conf for a test build. > It fails for me because MAKEOBJDIRPREFIX from /etc/make.conf (a > global variable) overrides the value of the MAKEOBJDIRPREFIX It probably had succeeded for me due to using `?=' rather than just the `=' which would result in the failures most people see. > Trying to set MAKEOBJDIRPREFIX in /etc/make.conf and attempting to buildworld > RELENG_4 on a 4.x machine similarly fails right away. I had been doing this in the past, but as noted, not recently. I'll try it again Real Soon Now. > The reason I'm writing this email is that I'm really interested in > reproducing the case where it could have possible worked before. Any help A world build takes days on my machines, but I promise that the next ones I kick off, I'll use the make.conf setting as much as possible. If it's expected to work with `?=', though, then ignore me. I agree that even if it does work with `?=', that too many people will fail to see the difference between that and a plain `=' and use the latter. However, I do like that it (used to?) work from make.conf, for times when I forget to set the environment variable. Which brings up something else -- has there been any resolution of the conflict between `DISTDIR' as used by ports, and `DISTDIR' as used by the `distribute' targets? I have the former set in my make.conf, which resulted in some odd paths, no matter how I specified `DESTDIR=' and `DISTDIR=' as both environment and `make' options when in the top-level src directory, but resolved itself only when given as an option within the `etc' subdirectory. Not that I know how to use `distribute/distribution' at all, but I saw that as one way to populate DESTDIR/etc. (Shoot me if this has been resolved in a way I've failed to catch during the months spent offline.) thanks barry bouwsma From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 10:59:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A723D16A4CE; Wed, 11 Aug 2004 10:59:06 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (80-219-164-131.dclient.hispeed.ch [80.219.164.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D53A43D2D; Wed, 11 Aug 2004 10:59:04 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:50db:a483:0:20e:2eff:fe06:2376]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id i7BAwph44129 verified NO); Wed, 11 Aug 2004 12:59:00 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id i7BAwn244128; Wed, 11 Aug 2004 12:58:50 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Wed, 11 Aug 2004 12:58:50 +0200 (CEST) Message-Id: <200408111058.i7BAwn244128@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma To: Ruslan Ermilov References: <20040810231044.GA70020@xor.obsecurity.org> <20040811061202.GA80234@ip.net.ua> <20040811065912.GA95263@xor.obsecurity.org> <20040811080350.GK80234@ip.net.ua> <200408110916.i7B9GTj43770@Mail.NOSPAM.DynDNS.dK> <20040811101100.GB84908@ip.net.ua> X-Mailman-Approved-At: Wed, 11 Aug 2004 12:26:24 +0000 cc: current@freebsd.org Subject: Re: DISTDIR (was: Re: World broken in stage 1.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 10:59:06 -0000 > > MAKEOBJDIRPREFIX?= foo... > > ^^ > Please see my other email in this thread that explains in detail > why it works, and why it should not be used. Understood. Methinks that MAKEOBJDIRPREFIX is getting to be a bit overloaded, as something that can be set by the user, as well as something that gets set during the build. Perhaps there should be something else that's user-only, defaulting to /usr/obj or whatever, from which the build process generates MAKEOBJDIRPREFIX and the like, but which itself remains intact, that *could* be specified in a make.conf or wherever. Admittedly, I don't know much about the build process, or if this has been tossed about in the past. I see that NetBSD has a number of user-specifiable things, some of which overlap or nullify each other, that one can specify, such as BSDOBJDIR and BSDSRCDIR and MAKEOBJDIR; at least the latter of which seems to be an environment variable too, but I'm not familiar with the NetBSD build, other than knowing that I've needed to mess around with these in order to get things where I've wanted. Perhaps these, or something like them, are applicable to FreeBSD as well. Anyway, I agree that it would be nice if there would be something that can be set in a make.conf which determines where the build happens, rather than it be dependent on an environment variable only. > > Which brings up something else -- has there been any > > resolution of the conflict between `DISTDIR' as used by > > ports, and `DISTDIR' as used by the `distribute' targets? > DISTDIR is only used by "make distribute", and the latter > is only used by "make release". "make release" doesn't > use /etc/make.conf. Where's the conflict? Ah, that I had been using `make distribute' or similar in order to populate DESTDIR/etc after a `make installworld', which is probably not what I should have been doing. (After a crossbuild, I wanted to fill DESTDIR with everything, including etc, as if installing a virgin installation. There's probably a Right Way to do this that I don't know.) thanks barry bouwsma From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 11:52:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBBD016A4CE; Wed, 11 Aug 2004 11:52:21 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (80-219-164-131.dclient.hispeed.ch [80.219.164.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA34543D48; Wed, 11 Aug 2004 11:52:19 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:50db:a483:0:20e:2eff:fe06:2376]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id i7BBq2h44280 verified NO); Wed, 11 Aug 2004 13:52:13 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id i7BBq0l44279; Wed, 11 Aug 2004 13:52:01 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Wed, 11 Aug 2004 13:52:01 +0200 (CEST) Message-Id: <200408111152.i7BBq0l44279@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma To: Ruslan Ermilov References: <20040810231044.GA70020@xor.obsecurity.org> <20040811061202.GA80234@ip.net.ua> <20040811065912.GA95263@xor.obsecurity.org> <20040811080350.GK80234@ip.net.ua> <200408110916.i7B9GTj43770@Mail.NOSPAM.DynDNS.dK> <20040811101100.GB84908@ip.net.ua><20040811111803.GJ84908@ip.net.ua> X-Mailman-Approved-At: Wed, 11 Aug 2004 12:26:24 +0000 cc: current@freebsd.org Subject: Re: DISTDIR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 11:52:21 -0000 > OTOH, if you want some knob for > /etc/make.conf to control what MAKEOBJDIRPREFIX will be set > to during buildworld and related targets, this should be > possible easily, though I personally don't see much point > in yet another variable. I believe this would make you (or whoever comes up with it) immensely popular, judging from the responses over the past hours. The advantage is that things would still ``work'' if one were to forget the commandline -- `make buildworld' would just do what the user wants. Like if I mis-type `make -DNOKERNEL_CLEAN buildkernel' on a slow machine. And then pull my hair when it takes hours to get to the point where I was. How many times have I typed `env MAKROBJDIRPREFIX=foo' in the dark and cursed myself when I realized what's wrong. > > > DISTDIR is only used by "make distribute", and the latter > > Ah, that I had been using `make distribute' or similar in > > order to populate DESTDIR/etc after a `make installworld', > > which is probably not what I should have been doing. (After > The correct spelling would be "make distrib-dirs && make > distribution" while in /usr/src/etc, but it does not use > DISTDIR either. "make distibute" while in /usr/src/etc > uses DISTDIR, but it should not be called by the end user, This is what I noticed, not knowing which was right, when I was testing to see what worked. Anyway, then I did the `make distribution' with success -- I believe the `distrib-dirs' step was part of the `installworld'. If not, I'll be doing it all again next buildworld, just for practice... First I tried the `SUBDIR_OVERRIDE' or whatever you mentioned earlier as part of `build everything' for a failed build in the top-level src directory. Like I say, I didn't know what to do so I was trying out different things in hope of getting something right, particularly as not everything works in the subdirectories as in the top-level directory. Thanks for the clarification, and straightening everything up. barry bouwsma From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 13:05:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E34416A4DA for ; Wed, 11 Aug 2004 13:05:24 +0000 (GMT) Received: from ms-smtp-01.nyroc.rr.com (ms-smtp-01.nyroc.rr.com [24.24.2.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFA1743D46 for ; Wed, 11 Aug 2004 13:05:23 +0000 (GMT) (envelope-from martines@rochester.rr.com) Received: from domain.crafts4life.com (roc-66-66-65-30.rochester.rr.com [66.66.65.30])i7BD5CZw027115; Wed, 11 Aug 2004 09:05:12 -0400 (EDT) Received: from localhost.crafts4life.com (localhost [127.0.0.1]) by domain.crafts4life.com (Postfix) with ESMTP id 2B6F63FD9; Wed, 11 Aug 2004 09:05:12 -0400 (EDT) Received: from domain.crafts4life.com (localhost.crafts4life.com [127.0.0.1]) by localhost.crafts4life.com (AvMailGate-2.0.1.16) id 46344-30C72B11; Wed, 11 Aug 2004 09:05:11 -0400 Received: from sauron-2.crafts4life.com (sauron-2.crafts4life.com [192.168.1.246]) by domain.crafts4life.com (Postfix) with ESMTP id B57AB3FC2; Wed, 11 Aug 2004 09:05:11 -0400 (EDT) From: Eduard Martinescu To: =?ISO-8859-1?Q?S=F8ren?= Schmidt In-Reply-To: <411A0EF0.4090808@DeepCore.dk> References: <411A0EF0.4090808@DeepCore.dk> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1092229511.14611.6.camel@sauron.crafts4life.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 11 Aug 2004 09:05:11 -0400 Content-Transfer-Encoding: quoted-printable X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.16; AVE: 6.27.0.4; VDF: 6.27.0.4; host: domain.crafts4life.com) X-Virus-Scanned: Symantec AntiVirus Scan Engine cc: freebsd-current@freebsd.org cc: 'Ville-Pertti Keinonen' cc: Daniel Eriksson Subject: Re: ATA driver races with interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 13:05:24 -0000 While I would like to say that the code I wrote is 'perfect', I have to agree with S=F8ren on this one. I would prefer to have the SMART monitor taken out of the picture, just to make sure I haven't been shooting you in the foot :) Ed FreeBSD porter for smartmontools package On Wed, 2004-08-11 at 08:20, S=F8ren Schmidt wrote: > Daniel Eriksson wrote: >=20 > > Unfortunately it didn't take too long for it to lock up. After 42 hou= rs of > > uptime with very light I/O load on the SATA discs (plus the SMART mon= itor), > > one of the channels locked up. No interesting messages in the logs, j= ust the > > normal "removed from configuration" message I've reported before. > >=20 > > Any suggestions on how to proceed? >=20 > How about not running the SMART monitor ? >=20 > The SMART monitor issues ATA commands from userland and could do some=20 > major footshooting, so lets get that out of the loop and concentrate on= =20 > "pure" ATA driver details for now. >=20 > Let me know how that goes.... >=20 >=20 > -S=F8ren >=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.o= rg" --=20 Eduard Martinescu From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 13:26:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A88E216A4CE for ; Wed, 11 Aug 2004 13:26:51 +0000 (GMT) Received: from smtp.abv.bg (mail07.abv.bg [194.153.145.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id E891B43D5E for ; Wed, 11 Aug 2004 13:26:50 +0000 (GMT) (envelope-from ianchov@gbg.bg) Received: from webmail.gyuvetch.bg (app1.ni.bg [192.168.151.15]) by smtp.abv.bg (Postfix) with SMTP id 4D9EA265 for ; Wed, 11 Aug 2004 16:26:47 +0300 (EEST) Received: (qmail 18271 invoked from network); 11 Aug 2004 13:26:47 -0000 Received: from app1.ni.bg (192.168.151.15) by 0 with SMTP; 11 Aug 2004 13:26:47 -0000 Message-ID: <1360783859.1092230807637.JavaMail.nobody@app1.ni.bg> Date: Wed, 11 Aug 2004 16:26:47 +0300 (EEST) From: Iantcho Vassilev To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit X-Mailer: AbvMail 1.0 X-Originating-IP: 213.240.192.49 Subject: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 13:26:51 -0000 hi. that`s my new e-mail provider. here is the letter that you couldn`t read -s sorry for that only one questions - about if_vr0 - you said to cvsup BACK - how to to that >>>>>> HI! to I`m please i can write in tah list. So yesterday i cvsupuped-my source and rebuilded. First i did then BUILDKERNEL then INSTALLKERNEL then boot-ed into single then mergemaster then installworld - there were some errors about some man.gz but that`s not the question. After booting i had the following error: panic: mtx lock.sleep recursed on non-recursive mutex vr0@/usr/src/sys/pci/if vr0.c:506 and the booting process went to kernel debugger I`m with ViaRhine Model Ethernet..only after adding network interfaces=" " to rc.conf made to boot correctly p.s.no special options while compile -pentium3 I ----------------------------------------------------------------- http://www.elmaz.com/ - Çŕďîçíŕíńňâŕ! From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 13:28:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A74F16A4CE; Wed, 11 Aug 2004 13:28:10 +0000 (GMT) Received: from mediamonks.com (siripandita.mediamonks.net [62.192.127.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BF5E43D39; Wed, 11 Aug 2004 13:28:08 +0000 (GMT) (envelope-from root@mediamonks.net) Received: from manrikigusari [217.19.28.156] by mediamonks.com with ESMTP (SMTPD32-8.12) id AED934800BC; Wed, 11 Aug 2004 15:27:53 +0200 From: "Terrence Koeman" To: "'John Baldwin'" , Date: Wed, 11 Aug 2004 15:28:10 +0200 Organization: MediaMonks B.V. MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000C_01C47FB7.CF14DC10" Thread-Index: AcR/FuTtYoq92di4TM6OknOtZEtqwwAFx9EgAB3h/bA= In-Reply-To: <200408110104380.SM01804@manrikigusari> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <200408111527566.SM01804@manrikigusari> X-Info: This e-mail was scanned for spam and viruses by mail.mediamonks.net. X-Info: Please send abuse reports about this e-mail to abuse@mediamonks.net. Subject: RE: Lock order reversal in 5.2-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: root@mediamonks.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2004 13:28:10 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C47FB7.CF14DC10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think something else is wrong, as I get different lock order reversals = and some other errors that all lockup the box. Earlier I had a corrupted cc binary after a buildworld. Everything points to a hardware failure somewhere, but I already = switched the hardware before this happened, I swapped RAID arrays in identical machines, and the machine where -CURRENT runs on now was a production = server that ran 4.9/4.10-STABLE for months under heavy load without any = problems whatsoever. The following is what I got today: Second bad /: bad dir ino 16110954 at offset 24: mangled entry panic: ufs_dirbad: bad dir KDB: stack backtrace: kdb_backtrace(c05fb5b8,c0646f80,c060ae08,de301814,100) at = kdb_backtrace+0x2e panic(c060ae08,c1738200,f5d56a,18,c060adc2) at panic+0xb7 ufs_dirbad(c2180118,18,c060adc2,0,de301890) at ufs_dirbad+0x50 ufs_lookup(de301950,de30198c,c0501c99,de301950,de301bf0) at = ufs_lookup+0x457 ufs_vnoperate(de301950,de301bf0,de301c04,c1c61420,c1aa0b00) at ufs_vnoperate+0x18 vfs_cache_lookup(de3019d0,de3019ec,c05072c2,de3019d0,20002) at vfs_cache_lookup+0xe9 ufs_vnoperate(de3019d0,20002,c1aa0b00,de3019d0,c1aa0b00) at ufs_vnoperate+0x18 lookup(de301bdc,0,c0602e3d,a4,c1aa0b00) at lookup+0x332 namei(de301bdc,c064ab40,246,9,c1aa0b00) at namei+0x2ae vn_open_cred(de301bdc,de301cdc,1a4,c1c2e600,3) at vn_open_cred+0x24b vn_open(de301bdc,de301cdc,1a4,3,c04d1ea0) at vn_open+0x33 kern_open(c1aa0b00,bfbfd440,0,1,1b6) at kern_open+0xf2 open(c1aa0b00,de301d14,c,c04d02b2,3) at open+0x30 syscall(2f,2f,2f,8084d7b,4) at syscall+0x2e0 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (5, FreeBSD ELF32, open), eip =3D 0x80662a7, esp =3D = 0xbfbfd3ec, ebp =3D 0xbfbfd418 --- KDB: enter: panic [thread 100096] Stopped at kdb_enter+0x30: leave db>=20 panic: mtx_lock() of spin mutex =A0=A5 @ = /usr/src/sys/vm/vm_object.c:1587 KDB: stack backtrace: kdb_backtrace(c05fb5b8,c0646f80,c05fa793,d4da6bb0,100) at = kdb_backtrace+0x2e panic(c05fa793,c1009ca0,c060c69a,633,c064c098) at panic+0xb7 _mtx_lock_flags(c100939c,0,c060c69a,633,c06729c0) at = _mtx_lock_flags+0x69 vm_object_collapse(c1a0f000,0,c060bde0,900,c058e2fe) at vm_object_collapse+0x5b vm_map_copy_entry(c154a940,c154bb90,c19b9618,c1aa0348,c04d2787) at vm_map_copy_entry+0x9f vmspace_fork(c154a940,1,c060b912,26e,c1542aa0) at vmspace_fork+0x30f vm_forkproc(c157ab00,c1a64000,c178c000,14,753) at vm_forkproc+0xee fork1(c157ab00,14,0,d4da6cdc,c157ab00) at fork1+0xfd9 fork(c157ab00,d4da6d14,c04a8825,c1539e00,0) at fork+0x29 syscall(280b002f,284c002f,bfbf002f,1,2) at syscall+0x2e0 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x283dd42f, esp =3D = 0xbfbfecdc, ebp =3D 0xbfbfed08 --- KDB: enter: panic [thread 100041] Stopped at kdb_enter+0x30: leave db>=20 lock order reversal 1st 0xc0645aa0 sched lock (sched lock) @ /usr/src/sys/kern/subr_sleepqueue.c:623 2nd 0xc06486ec sleepq chain (sleepq chain) @ /usr/src/sys/kern/subr_sleepqueue.c:223 KDB: stack backtrace: kdb_backtrace(c05fe96f,c06486ec,c05fdc8a,c05fdc8a,c05fdc97) at kdb_backtrace+0x2e witness_checkorder(c06486ec,9,c05fdc97,df,67e) at = witness_checkorder+0x6a6 _mtx_lock_spin_flags(c06486ec,0,c05fdc97,df,0) at = _mtx_lock_spin_flags+0x8d sleepq_lookup(c0641d80,c05fe5e3,687,c0645aa0,d3bbc9ec) at = sleepq_lookup+0x57 sleepq_broadcast(c0641d80,0,ffffffff,d3bbca14,c04b4152) at sleepq_broadcast+0x31 wakeup(c0641d80,1,c05fbc09,179,c1a632c0) at wakeup+0x21 setrunnable(c1a632c0,0,c05fdc97,26f,c066ef84) at setrunnable+0xb2 sleepq_resume_thread(c1a632c0,ffffffff,c05fdc97,31e,c2259540) at sleepq_resume_thread+0xa0 sleepq_remove(c1a632c0,c066ef84,c05fef7d,464,c2259540) at sleepq_remove+0x117 doselwakeup(c2259540,58,d3bbcaa8,c04f1771,c2259540) at doselwakeup+0x110 selwakeuppri(c2259540,58,c060126c,18e,c20f18c0) at selwakeuppri+0x18 sowakeup(c22594f0,c2259540,c0606e75,4fd,0) at sowakeup+0x41 tcp_input(c1915500,14,f,0,14) at tcp_input+0x1350 ip_input(c1915500,0,c0605194,1d0,c1791318) at ip_input+0x712 transmit_event(c1791300,0,c0605194,300,c0670300) at transmit_event+0x128 dummynet(0,0,c05fc4ec,fd,0) at dummynet+0x138 softclock(0,0,c05f8d63,263,c1545534) at softclock+0x20e ithread_loop(c1539580,d3bbcd48,c05f8b5a,32b,0) at ithread_loop+0x172 fork_exit(c04944a0,c1539580,d3bbcd48) at fork_exit+0xc7 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip =3D 0, esp =3D 0xd3bbcd7c, ebp =3D 0 --- KDB: enter: witness_checkorder [thread 100024] Stopped at kdb_enter+0x30: leave db>=20 Fatal trap 18: integer divide fault while in kernel mode instruction pointer =3D 0x8:0xc056b238 stack pointer =3D 0x10:0xde08c91c frame pointer =3D 0x10:0xde08c980 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 14276 (httpd) [thread 100058] Stopped at softdep_setup_freeblocks+0x408: divl 0xb8(%ecx),%eax db> Does someone have any ideas? --=20 Regards, Terrence Koeman =20 MediaMonks B.V. (www.mediamonks.com) Please quote all replies in correspondence. =20 ------=_NextPart_000_000C_01C47FB7.CF14DC10 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKUzCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNmMIICz6ADAgECAhANi0/uqtIYW/R1ap0p4X/7MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4G0MIGxMBEGCWCGSAGG+EIBAQQEAwIB BjA1BgNVHR8ELjAsMCqgKKAmhiRodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLjEuMS5jcmww RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB AgUAA4GBAEJ8Dt+MeUysvwjsTVUvUImgxV5OLl6VMpt5rWURCxxKUsTVqDEhjt4Qm2wIxQfmA7nn yDR4CQnyvAZC+FqMg9GK3qoi9dnjIdLPZYwGM7DNILIzzQq9PuGdwTWpZLCnpSRb6fFo6xPEfDf0 lGQNmsW9MxfvgzOgPuWqPq7Ycx+tMIIEpDCCBA2gAwIBAgIQZx6EJ4oHSmQocGtEpogzPzANBgkq hkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wNDAyMDQw MDAwMDBaFw0wNTAyMDMyMzU5NTlaMIIBFjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0 IEZ1bGwgU2VydmljZTEYMBYGA1UEAxQPVGVycmVuY2UgS29lbWFuMSIwIAYJKoZIhvcNAQkBFhNy b290QG1lZGlhbW9ua3MubmV0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKUqZ0P8RUaCCe aemq1V8OtPimM3jxXZY6yuWtQz74POz82LhrkctttQoqujz5SubFWsQ15KsVnK4Nt+gTmtUELQVa I4uUebypbChhf1fxFerA7Rx8SYL4Ez9Fvco0tn89FRht6C/xoc/Ms/1YkQQcfnu2sqohx53S5Pm0 Ffo/ZQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcC AjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVm ZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDAGCmCG SAGG+EUBBgcEIhYgMWE5NjkyOTM3Y2MyOTFhMzZkZjAxN2Q4NDBjNDRiMTYwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOB gQAmpan0cUGODHHRIbkVFBHbTOumbMmEO3TR6d9z3LVO9cU5YDC/8BI9e5DZ7Kv43p/ldaGVo2ua ZwtvwL6o/iDcP8UDw+WmjSwzp6tck5cVRDEi+q9nCe3JAYBeRgSJlP5JGOirFpLuDTwL4UPdE0em p9ELBC+sXACm2C3u19hlKTGCBD4wggQ6AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3Qg VmFsaWRhdGVkAhBnHoQnigdKZChwa0SmiDM/MAkGBSsOAwIaBQCgggKyMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDgxMTEzMjgxMFowIwYJKoZIhvcNAQkEMRYE FBNL2TvJdMsx5+G5zMcIlbYPwSPOMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIa MAoGCCqGSIb3DQIFMIHyBgkrBgEEAYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNp Z24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5v dCBWYWxpZGF0ZWQCEGcehCeKB0pkKHBrRKaIMz8wgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBnHoQnigdKZChwa0SmiDM/MA0GCSqGSIb3 DQEBAQUABIGAI9g8ZC550YJGdQWt+jmIa8/80QhT9J8i7ZxMXtEfIW1sqCQjA16ujcubRG42gyym O+F7bFIA3cPCEXipvQVcV2NKEcNGPQ9+1GvzFZxh96KNUa1MzHoJePN3Nu4TIphNE6a0zcAUxDQ1 9+4ySHvQyyHzkyJYm7VGr6zDkCOCwgoAAAAAAAA= ------=_NextPart_000_000C_01C47FB7.CF14DC10-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 13:46:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6494D16A4CE for ; Wed, 11 Aug 2004 13:46:35 +0000 (GMT) Received: from av1-2-sn3.vrr.skanova.net (av1-2-sn3.vrr.skanova.net [81.228.9.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25A2443D39 for ; Wed, 11 Aug 2004 13:46:35 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av1-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 81D2E37E5F; Wed, 11 Aug 2004 15:46:34 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 71E4A37E4E; Wed, 11 Aug 2004 15:46:34 +0200 (CEST) Received: from gadget (h130n1fls11o822.telia.com [213.64.66.130]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 4CBAC3800A; Wed, 11 Aug 2004 15:46:34 +0200 (CEST) From: "Daniel Eriksson" To: =?iso-8859-1?Q?'S=F8ren_Schmidt'?= Date: Wed, 11 Aug 2004 15:46:32 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcR/neYVjMFapPT/Qa6sEq/VuvWj/gAClCMQ In-Reply-To: <411A0EF0.4090808@DeepCore.dk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 cc: freebsd-current@freebsd.org Subject: RE: ATA driver races with interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 13:46:35 -0000 S=F8ren Schmidt wrote: > How about not running the SMART monitor ? >=20 > The SMART monitor issues ATA commands from userland and could do some=20 > major footshooting, so lets get that out of the loop and=20 > concentrate on=20 > "pure" ATA driver details for now. >=20 > Let me know how that goes.... Sure, I will turn it off and report back. This all started with similar lockups even without the SMART monitor, = and I used the monitor as a reference because it would reliably lock up one of = the channels right away. I have at least one other thing to try that used to trigger bad things - creating a geom_stripe array. However, since it really messed my system = up last time I tried it I'll wait until right after a full backup to run = the test. Thank you for your efforts S=F8ren! /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 14:02:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42C2A16A4CE; Wed, 11 Aug 2004 14:02:19 +0000 (GMT) Received: from omoikane.mb.skyweb.ca (64-42-246-34.mb.skyweb.ca [64.42.246.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B01043D67; Wed, 11 Aug 2004 14:02:19 +0000 (GMT) (envelope-from mark@skyweb.ca) Received: by omoikane.mb.skyweb.ca (Postfix, from userid 1001) id 5985561D52; Wed, 11 Aug 2004 09:02:17 -0500 (CDT) From: Mark Johnston To: Ruslan Ermilov Date: Wed, 11 Aug 2004 09:02:17 -0500 User-Agent: KMail/1.6.1 References: <200408102228.39276.mjohnston@skyweb.ca> <20040811063509.GC80234@ip.net.ua> In-Reply-To: <20040811063509.GC80234@ip.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408110902.17081.mjohnston@skyweb.ca> cc: current@freebsd.org Subject: Re: cvs-src summary for August 2-9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 14:02:19 -0000 Ruslan Ermilov wrote: > On Tue, Aug 10, 2004 at 10:28:39PM -0500, Mark Johnston wrote: > > Cryptography in releases and legal concerns > > ------------------------------------------- > > > > Nate Lawson (njl) moved the crypto distribution into base, making all > > releases cryptography-enabled. He noted, "The -DNOCRYPT build option > > still exists for anyone who really wants to build non-cryptographic > > binaries [ . . . ]." > > It was Colin Percival who did the change. Argh! My apologies to Colin - I still can't figure out how I managed to do that. > > mbuf exhaustion panic fixed > > --------------------------- > > Brian Feldman (green) changed the UMA (uniform memory access) code, > > UMA stands for the Universal Memory Allocator. Ah, thanks. I had only heard of UMA as part of the term "NUMA", and I was extrapolating from that, but actually looking up what NUMA is shows "uniform memory access" to be clearly not something you'd write special code for. For anyone who shared my confusion, "non-uniform memory access" is when some memory is slower than other memory, like in a clustered system. "Uniform memory access", where all access is the same speed, is obviously the normal case. For those who just use the Web page, I'm going to correct these errors in the published summary. I'm not trying to pretend I don't screw up, but I think the technical accuracy of what's on the Web is more important than preserving a record there of everything that was said. If this surprises or upsets you, please feel free to use the -current Web archives to continue to refer to the original version of the summary, including errors. Mark From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 14:05:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92DA616A4CE for ; Wed, 11 Aug 2004 14:05:09 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06A6643D5D for ; Wed, 11 Aug 2004 14:05:09 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 4327C1FF92F for ; Wed, 11 Aug 2004 16:05:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 61D301FF91D; Wed, 11 Aug 2004 16:05:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 875E815384; Wed, 11 Aug 2004 14:03:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 7CB8715329 for ; Wed, 11 Aug 2004 14:03:45 +0000 (UTC) Date: Wed, 11 Aug 2004 14:03:45 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: FreeBSD current mailing list In-Reply-To: <200408111527566.SM01804@manrikigusari> Message-ID: References: <200408111527566.SM01804@manrikigusari> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Subject: RE: Lock order reversal in 5.2-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 14:05:09 -0000 On Wed, 11 Aug 2004, Terrence Koeman wrote: > lock order reversal > 1st 0xc0645aa0 sched lock (sched lock) @ > /usr/src/sys/kern/subr_sleepqueue.c:623 > 2nd 0xc06486ec sleepq chain (sleepq chain) @ > /usr/src/sys/kern/subr_sleepqueue.c:223 > KDB: stack backtrace: > kdb_backtrace(c05fe96f,c06486ec,c05fdc8a,c05fdc8a,c05fdc97) at > kdb_backtrace+0x2e > witness_checkorder(c06486ec,9,c05fdc97,df,67e) at witness_checkorder+0x6a6 > _mtx_lock_spin_flags(c06486ec,0,c05fdc97,df,0) at _mtx_lock_spin_flags+0x8d > sleepq_lookup(c0641d80,c05fe5e3,687,c0645aa0,d3bbc9ec) at sleepq_lookup+0x57 > sleepq_broadcast(c0641d80,0,ffffffff,d3bbca14,c04b4152) at > sleepq_broadcast+0x31 > wakeup(c0641d80,1,c05fbc09,179,c1a632c0) at wakeup+0x21 for the archives: looks quite similar to http://sources.zabbadoz.net/freebsd/lor.html#004 so I added it there. It got patched in the other place. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 14:26:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC12F16A4D0 for ; Wed, 11 Aug 2004 14:26:50 +0000 (GMT) Received: from tethys.ringofsaturn.com (tethys.ringofsaturn.com [66.13.175.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2308043D1D for ; Wed, 11 Aug 2004 14:26:50 +0000 (GMT) (envelope-from rnejdl@ringofsaturn.com) Received: from mail.ringofsaturn.com (localhost [127.0.0.1]) i7BEQnRN078228 for ; Wed, 11 Aug 2004 09:26:49 -0500 (CDT) (envelope-from rnejdl@ringofsaturn.com) Received: from 12.148.147.242 (SquirrelMail authenticated user rnejdl); by mail.ringofsaturn.com with HTTP; Wed, 11 Aug 2004 09:26:49 -0500 (CDT) Message-ID: <18300.12.148.147.242.1092234409.squirrel@[12.148.147.242]> Date: Wed, 11 Aug 2004 09:26:49 -0500 (CDT) From: "Rusty Nejdl" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on tethys.ringofsaturn.com X-Virus-Status: Clean Subject: Signal 11 compiling qt33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rnejdl@ringofsaturn.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2004 14:26:50 -0000 I just received this signal 11 while compiling qt33 on the snapshot from 8/9 rm -f libqui.so.1.0.0 libqui.so libqui.so.1 libqui.so.1.0 c++ -fno-exceptions -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/X11R6/lib -lpthread -shared -Wl,-soname,libqui.so.1 -Wl,-rpath,/usr/ports/x11-toolkits/qt33/work/qt-x11-free-3.3.2/lib -o libqui.so.1.0.0 .obj/release-shared-mt/qwidgetfactory.o .obj/release-shared-mt/domtool.o .obj/release-shared-mt/uib.o .obj/release-shared-mt/database.o .obj/release-shared-mt/moc_database2.o -L/usr/local/lib -L/usr/local/lib -L/usr/ports/x11-toolkits/qt33/work/qt-x11-free-3.3.2/lib -L/usr/X11R6/lib -L/usr/X11R6/lib -lqt-mt -lmng -ljpeg -lpng -lz -lGLU -lGL -lXmu -lXi -lXrender -lXrandr -lXinerama -lXft -lfreetype -lfontconfig -lXext -lX11 -lm -lSM -lICE ln -s libqui.so.1.0.0 libqui.so ln -s libqui.so.1.0.0 libqui.so.1 ln -s libqui.so.1.0.0 libqui.so.1.0 rm -f ../../../lib/libqui.so.1.0.0 rm -f ../../../lib/libqui.so rm -f ../../../lib/libqui.so.1 rm -f ../../../lib/libqui.so.1.0 mv -f libqui.so.1.0.0 libqui.so libqui.so.1 libqui.so.1.0 ../../../lib/ cd designer && make -f Makefile /usr/ports/x11-toolkits/qt33/work/qt-x11-free-3.3.2/bin/uic -L /usr/ports/x11-toolkits/qt33/work/qt-x11-free-3.3.2/plugins listboxeditor.ui -o listboxeditor.h *** Signal 11 Stop in /usr/ports/x11-toolkits/qt33/work/qt-x11-free-3.3.2/tools/designer/designer. *** Error code 1 Stop in /usr/ports/x11-toolkits/qt33/work/qt-x11-free-3.3.2/tools/designer. *** Error code 1 Stop in /usr/ports/x11-toolkits/qt33/work/qt-x11-free-3.3.2/tools. *** Error code 1 Stop in /usr/ports/x11-toolkits/qt33/work/qt-x11-free-3.3.2. *** Error code 1 Stop in /usr/ports/x11-toolkits/qt33. *** Error code 1 Stop in /usr/ports/x11-toolkits/qt33. *** Error code 1 > uname -a FreeBSD pan.ringofsaturn.com 5.2-CURRENT-20040809-JPSNAP FreeBSD 5.2-CURRENT-20040809-JPSNAP #0: Mon Aug 9 02:33:23 UTC 2004 root@ushi.jp.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 > Would updating my world solve this problem at all for me? This is the latest (as of this morning) ports. Thanks! Rusty Nejdl From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 14:43:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3227616A4CE for ; Wed, 11 Aug 2004 14:43:27 +0000 (GMT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9464D43D55 for ; Wed, 11 Aug 2004 14:43:26 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BuuK4-0007Wr-00 for ; Wed, 11 Aug 2004 16:43:25 +0200 Received: from anyanka.rfc1149.net ([81.56.47.149]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Aug 2004 16:43:24 +0200 Received: from sam by anyanka.rfc1149.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Aug 2004 16:43:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Samuel Tardieu Date: 11 Aug 2004 13:32:53 +0200 Organization: Avian Carrier & Friends Lines: 26 Message-ID: <87u0v93o62.fsf@beeblebrox.rfc1149.net> References: <20040804144350.GX991@funkthat.com> <2890.1091634484@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: anyanka.rfc1149.net User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 X-Leafnode-NNTP-Posting-Host: 2001:660:330f:f810:200:39ff:fe25:3aa2 Sender: news Subject: Re: GEOM is too verbose X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 14:43:27 -0000 >>>>> "PHK" == Poul-Henning Kamp writes: PHK> see diskinfo(8) Speaking of diskinfo, I can understand why it cannot measure seek times on too-small a disk, but why cannot it measure transfer rates? On my 256M compact flash (Soekris), I get: anyanka# diskinfo -v -t ad1 ad1 512 # sectorsize 257949696 # mediasize in bytes (246M) 503808 # mediasize in sectors 984 # Cylinders according to firmware. 16 # Heads according to firmware. 32 # Sectors according to firmware. Seek times: Full stroke: diskinfo: read error or disk too small for test.: Input/output error anyanka# Sam -- Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 14:48:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B326816A4CE; Wed, 11 Aug 2004 14:48:05 +0000 (GMT) Received: from mail.imp.ch (ns1.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3575843D2F; Wed, 11 Aug 2004 14:48:04 +0000 (GMT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.9p2/8.12.3) with ESMTP id i7BElm1m071212; Wed, 11 Aug 2004 16:47:49 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Wed, 11 Aug 2004 16:47:48 +0200 (CEST) From: Martin Blapp To: freebsd-current@freebsd.org Message-ID: <20040811164404.X31181@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checksum: 67dd6041f38610457d0addb2c94ef8ab X-Virus-Status: No, scantime="0.0022 seconds" X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=4 scantime="10.5778 seconds" tests=BAYES_00 X-Scanned-By: MIMEDefang 2.44 Subject: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 14:48:05 -0000 Hi all, During load tests with both SCHED4BSD and SCHEDULE I found that the latest SCHEDULE version cannot have a load over 2-3. I stress tested the server really a lot, but about 500 processes did sleep and did not got scheduled and only 2 of 500 were run and got about 50% of CPU time. Is this a known problem ? Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 15:09:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EC3416A4CE for ; Wed, 11 Aug 2004 15:09:23 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C732D43D3F for ; Wed, 11 Aug 2004 15:09:22 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7BF7lBW018632; Wed, 11 Aug 2004 11:07:47 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7BF7kvX018629; Wed, 11 Aug 2004 11:07:46 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 11 Aug 2004 11:07:46 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Martin Blapp In-Reply-To: <20040811164404.X31181@cvs.imp.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 15:09:23 -0000 On Wed, 11 Aug 2004, Martin Blapp wrote: > During load tests with both SCHED4BSD and SCHEDULE I found that the > latest SCHEDULE version cannot have a load over 2-3. I stress tested the > server really a lot, but about 500 processes did sleep and did not got > scheduled and only 2 of 500 were run and got about 50% of CPU time. > > Is this a known problem ? I've found that for throughput oriented workloads, 4BSD substantially outperforms ULE, but I haven't tried it with Jeff's latest set of patches (committed a day or two ago). You don't mention if your box is SMP, btw -- I've noticed some load balancing problems with ULE previously, but haven't checked if they were resolved. Anecdotal opinion seems generally to be that interactivity is observably better with ULE than 4BSD, but that 4BSD appears to do a better job under load. This weekend I'll be rerunning a number of benchmarks across a broad range of variables (scheduler, smp support, htt, various locking models, different netisr models, threading libraries, etc) to evaluate progress over the last month, and I'll see how things look with ULE. FYI, when I started benchmarking MySQL a couple of months ago, I was seeing about 2800 transactions/sec on a benchmark on my dual P4 with (GENERIC - DEBUGGING). Now I'm seeing about 7100-7200 transactions/sec. I've merged pretty much all of the changes necessary to see that transition except moving to 4BSD by default, disabling HTT by default, and enabling Giant-free networking by default. UP has also improved, but only be a relatively small fraction, so I've been shifting attention to UP from SMP. Some of the wins on SMP have been from moving to adaptive mutexes by default (most recently, for Giant on i386); others from improved fine grain locking in VM and networking, and general optimization of synchronization primitives, scheduling, wakeups/locking, etc. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 15:09:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D6B616A4CE; Wed, 11 Aug 2004 15:09:33 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3E7143D1D; Wed, 11 Aug 2004 15:09:32 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i7BF9VBh087885; Wed, 11 Aug 2004 11:09:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i7BF9VLB002767; Wed, 11 Aug 2004 11:09:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9AA077303F; Wed, 11 Aug 2004 11:09:31 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040811150931.9AA077303F@freebsd-current.sentex.ca> Date: Wed, 11 Aug 2004 11:09:31 -0400 (EDT) Subject: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2004 15:09:33 -0000 TB --- 2004-08-11 14:41:53 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-11 14:41:53 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2004-08-11 14:41:53 - cleaning the sandbox TB --- 2004-08-11 14:43:00 - checking out the source tree TB --- 2004-08-11 14:43:00 - cd /home/tinderbox/sandbox/CURRENT/ia64/ia64 TB --- 2004-08-11 14:43:00 - /usr/bin/cvs -f -R -Q -d/home/ncvs checkout -P -A src TB --- 2004-08-11 14:50:49 - WARNING: /home/tinderbox/sandbox/ia64.diff does not exist TB --- 2004-08-11 14:50:49 - building world (CFLAGS=-O -pipe) TB --- 2004-08-11 14:50:49 - cd /home/tinderbox/sandbox/CURRENT/ia64/ia64/src TB --- 2004-08-11 14:50:49 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> 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 [...] ===> lib/libbsnmp/libbsnmp rm -f .depend mkdep -f .depend -a -I/tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib -DHAVE_ERR_H -DHAVE_GETADDRINFO -DHAVE_STRLCPY /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/asn1.c /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.c /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpagent.c /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpclient.c /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/support.c ===> lib/libbsnmp/modules ===> lib/libbsnmp/modules/snmp_atm cat /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/modules/snmp_atm/../../../../contrib/ngatm/snmp_atm/atm_tree.def /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/modules/snmp_atm/atm_freebsd.def | gensnmptree -e begemotAtm > atm_oid.h line 110: junk after closing ')' context: "1 internet *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/modules/snmp_atm. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/modules. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/lib. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2004-08-11 15:09:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-11 15:09:31 - ERROR: failed to build world TB --- 2004-08-11 15:09:31 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 15:12:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34AB516A4CE for ; Wed, 11 Aug 2004 15:12:26 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84C2343D46 for ; Wed, 11 Aug 2004 15:12:23 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 91077 invoked from network); 11 Aug 2004 15:06:20 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Aug 2004 15:06:20 -0000 Message-ID: <411A3755.6030507@freebsd.org> Date: Wed, 11 Aug 2004 17:12:21 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: UMA questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 15:12:26 -0000 I have a couple of questions regarding UMA things which are not explained in the relevant man pages (and UTSL is a little bit tough): 1. UMA zones do not show up in the output of 'vmstat -m'. Is there a way to get information on how much memory each UMA zone is using? Example: "sackhole", "tcptw", ... 2. What does the flag UMA_ZONE_ZINIT do exactly? 3. What does the flag UMA_ZONE_NOFREE prevent exactly? Will it prevent any zone/slab of this type to be free'd ever again? This way the zone can only grow and not shrink after transient peaks? -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 15:22:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88A0516A4CE for ; Wed, 11 Aug 2004 15:22:23 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3DA243D45 for ; Wed, 11 Aug 2004 15:22:22 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 91182 invoked from network); 11 Aug 2004 15:16:19 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Aug 2004 15:16:19 -0000 Message-ID: <411A39AC.30707@freebsd.org> Date: Wed, 11 Aug 2004 17:22:20 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <411A3755.6030507@freebsd.org> In-Reply-To: <411A3755.6030507@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: UMA questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 15:22:23 -0000 Andre Oppermann wrote: > I have a couple of questions regarding UMA things which are not > explained in > the relevant man pages (and UTSL is a little bit tough): > > 1. UMA zones do not show up in the output of 'vmstat -m'. Is there a way > to get information on how much memory each UMA zone is using? > Example: "sackhole", "tcptw", ... > > 2. What does the flag UMA_ZONE_ZINIT do exactly? > > 3. What does the flag UMA_ZONE_NOFREE prevent exactly? Will it prevent any > zone/slab of this type to be free'd ever again? This way the zone can > only grow and not shrink after transient peaks? 4. What does the flag UMA_ZONE_STATIC do exactly? I was under the impression that zones are fixed sized by definition and don't need this to be specified additionally. -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 15:29:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2220016A4D3; Wed, 11 Aug 2004 15:29:51 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1802943D1F; Wed, 11 Aug 2004 15:29:51 +0000 (GMT) (envelope-from bmilekic@FreeBSD.org) Received: from freefall.freebsd.org (bmilekic@localhost [127.0.0.1]) i7BFTofH017922; Wed, 11 Aug 2004 15:29:50 GMT (envelope-from bmilekic@freefall.freebsd.org) Received: (from bmilekic@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i7BFToS2017921; Wed, 11 Aug 2004 15:29:50 GMT (envelope-from bmilekic) Date: Wed, 11 Aug 2004 15:29:50 +0000 From: Bosko Milekic To: Andre Oppermann , freebsd-current@freebsd.org Message-ID: <20040811152950.GA17794@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Re: UMA questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 15:29:51 -0000 >1. UMA zones do not show up in the output of 'vmstat -m'. Is there a way > to get information on how much memory each UMA zone is using? > Example: "sackhole", "tcptw", ... vmstat -z, or sysctl vm.zone. Be careful when interpreting the stats in the Mbuf, Mbuf Cluster, and Packet zones, because they are special. See www.unixdaemons.com/~bmilekic/netbuf_bmilekic.pdf if you want to know why, exactly. >2. What does the flag UMA_ZONE_ZINIT do exactly? It initializes zone-allocated objects to zero. This happens as objects are first allocated (i.e., slabs are allocated) and before placement into the slab cache. Unfortunately, I am not sure this works very well unless you also make sure to zero them as they are returned (dtor), which is a shitty model. >3. What does the flag UMA_ZONE_NOFREE prevent exactly? Will it prevent any > zone/slab of this type to be free'd ever again? This way the zone can > only grow and not shrink after transient peaks? Yes. It prevents freeing/draining of the slab cache. -Bosko From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 15:32:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 727CE16A4CE; Wed, 11 Aug 2004 15:32:13 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5250243D39; Wed, 11 Aug 2004 15:32:13 +0000 (GMT) (envelope-from bmilekic@FreeBSD.org) Received: from freefall.freebsd.org (bmilekic@localhost [127.0.0.1]) i7BFWDgq019334; Wed, 11 Aug 2004 15:32:13 GMT (envelope-from bmilekic@freefall.freebsd.org) Received: (from bmilekic@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i7BFWDxR019333; Wed, 11 Aug 2004 15:32:13 GMT (envelope-from bmilekic) Date: Wed, 11 Aug 2004 15:32:13 +0000 From: Bosko Milekic To: Andre Oppermann , freebsd-current@freebsd.org Message-ID: <20040811153213.GA19249@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Re: UMA questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 15:32:13 -0000 >4. What does the flag UMA_ZONE_STATIC do exactly? I was under the impression > that zones are fixed sized by definition and don't need this to be > specified > additionally. It does nothing. -Bosko From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 15:35:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2AE616A4CE; Wed, 11 Aug 2004 15:35:58 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8458D43D1D; Wed, 11 Aug 2004 15:35:58 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i7BFZu6K091126; Wed, 11 Aug 2004 11:35:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7BFZuGc018873; Wed, 11 Aug 2004 11:35:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 97CA57303F; Wed, 11 Aug 2004 11:35:56 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040811153556.97CA57303F@freebsd-current.sentex.ca> Date: Wed, 11 Aug 2004 11:35:56 -0400 (EDT) Subject: [current tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2004 15:35:59 -0000 TB --- 2004-08-11 15:09:31 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-11 15:09:31 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2004-08-11 15:09:31 - cleaning the sandbox TB --- 2004-08-11 15:10:57 - checking out the source tree TB --- 2004-08-11 15:10:57 - cd /home/tinderbox/sandbox/CURRENT/powerpc/powerpc TB --- 2004-08-11 15:10:57 - /usr/bin/cvs -f -R -Q -d/home/ncvs checkout -P -A src TB --- 2004-08-11 15:18:55 - patching the sources TB --- 2004-08-11 15:18:55 - cd /home/tinderbox/sandbox/CURRENT/powerpc/powerpc/src TB --- 2004-08-11 15:18:55 - /usr/bin/patch -f -s -i/home/tinderbox/sandbox/powerpc.diff TB --- 2004-08-11 15:18:55 - building world (CFLAGS=-O -pipe) TB --- 2004-08-11 15:18:55 - cd /home/tinderbox/sandbox/CURRENT/powerpc/powerpc/src TB --- 2004-08-11 15:18:55 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> 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 [...] ===> lib/libbsnmp/libbsnmp rm -f .depend mkdep -f .depend -a -I/tinderbox/CURRENT/powerpc/powerpc/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib -DHAVE_ERR_H -DHAVE_GETADDRINFO -DHAVE_STRLCPY /tinderbox/CURRENT/powerpc/powerpc/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/asn1.c /tinderbox/CURRENT/powerpc/powerpc/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.c /tinderbox/CURRENT/powerpc/powerpc/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpagent.c /tinderbox/CURRENT/powerpc/powerpc/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpclient.c /tinderbox/CURRENT/powerpc/powerpc/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/support.c ===> lib/libbsnmp/modules ===> lib/libbsnmp/modules/snmp_atm cat /tinderbox/CURRENT/powerpc/powerpc/src/lib/libbsnmp/modules/snmp_atm/../../../../contrib/ngatm/snmp_atm/atm_tree.def /tinderbox/CURRENT/powerpc/powerpc/src/lib/libbsnmp/modules/snmp_atm/atm_freebsd.def | gensnmptree -e begemotAtm > atm_oid.h line 110: junk after closing ')' context: "1 internet *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/lib/libbsnmp/modules/snmp_atm. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/lib/libbsnmp/modules. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/lib/libbsnmp. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/lib. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2004-08-11 15:35:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-11 15:35:56 - ERROR: failed to build world TB --- 2004-08-11 15:35:56 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 15:43:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7511C16A4CE for ; Wed, 11 Aug 2004 15:43:24 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B285B43D53 for ; Wed, 11 Aug 2004 15:43:23 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 91401 invoked from network); 11 Aug 2004 15:37:20 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Aug 2004 15:37:20 -0000 Message-ID: <411A3E9A.6000301@freebsd.org> Date: Wed, 11 Aug 2004 17:43:22 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bosko Milekic References: <20040811152950.GA17794@freefall.freebsd.org> In-Reply-To: <20040811152950.GA17794@freefall.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: UMA questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 15:43:24 -0000 Bosko Milekic wrote: >>1. UMA zones do not show up in the output of 'vmstat -m'. Is there a way >> to get information on how much memory each UMA zone is using? >> Example: "sackhole", "tcptw", ... > > > vmstat -z, or sysctl vm.zone. Be careful when interpreting the stats > in the Mbuf, Mbuf Cluster, and Packet zones, because they are special. > See www.unixdaemons.com/~bmilekic/netbuf_bmilekic.pdf if you want to > know why, exactly. Great, thanks for the pointer. >>2. What does the flag UMA_ZONE_ZINIT do exactly? > > > It initializes zone-allocated objects to zero. This happens as objects > are first allocated (i.e., slabs are allocated) and before placement > into the slab cache. Unfortunately, I am not sure this works very well > unless you also make sure to zero them as they are returned (dtor), > which is a shitty model. Ok, so it is better to use uma_zalloc(zone, M_ZERO)? >>3. What does the flag UMA_ZONE_NOFREE prevent exactly? Will it prevent any >> zone/slab of this type to be free'd ever again? This way the zone can >> only grow and not shrink after transient peaks? > > Yes. It prevents freeing/draining of the slab cache. Usually not what one wants. Most of the time we want to give free slabs back if under memory pressure. >4. What does the flag UMA_ZONE_STATIC do exactly? I was under the impression >> that zones are fixed sized by definition and don't need this to be >> specified additionally. > > It does nothing. Many thanks for your quick answers. Would you mind documenting this in the uma_* manpages? Or someone from doc team? -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 15:45:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A286A16A4CE; Wed, 11 Aug 2004 15:45:26 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BE1743D7D; Wed, 11 Aug 2004 15:45:26 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BuvHn-0002CN-00; Wed, 11 Aug 2004 17:45:07 +0200 Received: from [217.227.155.1] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BuvHn-0000Fa-00; Wed, 11 Aug 2004 17:45:07 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Wed, 11 Aug 2004 17:43:08 +0200 User-Agent: KMail/1.6.2 References: <20040811152950.GA17794@freefall.freebsd.org> In-Reply-To: <20040811152950.GA17794@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_U6jGB/JDDmcN0xq"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408111743.16323.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Andre Oppermann cc: Bosko Milekic Subject: Re: UMA questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 15:45:26 -0000 --Boundary-02=_U6jGB/JDDmcN0xq Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 11 August 2004 17:29, Bosko Milekic wrote: > >2. What does the flag UMA_ZONE_ZINIT do exactly? > > It initializes zone-allocated objects to zero. This happens as objects > are first allocated (i.e., slabs are allocated) and before placement > into the slab cache. Unfortunately, I am not sure this works very well > unless you also make sure to zero them as they are returned (dtor), > which is a shitty model. I guess the motivation behind UMA_ZONE_ZINIT is to prevent an information l= eak=20 from other parts of the system. i.e. I want memory that I can pass to users= =20 or the net w/o having to fear that it holds my password or something. Once the slab is in the cache, i.e. it belongs to me, I don't care anymore. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_U6jGB/JDDmcN0xq Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBGj6UXyyEoT62BG0RAkygAJ95IMg41rKma+WKRve6xKR16wnk3gCcDorJ DHZjGrc7yVsz4ItxU9gzZcU= =Uecs -----END PGP SIGNATURE----- --Boundary-02=_U6jGB/JDDmcN0xq-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 15:59:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1106C16A4CE; Wed, 11 Aug 2004 15:59:56 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAC7643D45; Wed, 11 Aug 2004 15:59:55 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i7BFxqXx094585; Wed, 11 Aug 2004 11:59:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i7BFxpV6030127; Wed, 11 Aug 2004 11:59:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EE0397303F; Wed, 11 Aug 2004 11:59:51 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040811155951.EE0397303F@freebsd-current.sentex.ca> Date: Wed, 11 Aug 2004 11:59:51 -0400 (EDT) Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2004 15:59:56 -0000 TB --- 2004-08-11 15:35:56 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-11 15:35:56 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-08-11 15:35:56 - cleaning the sandbox TB --- 2004-08-11 15:36:55 - checking out the source tree TB --- 2004-08-11 15:36:55 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64 TB --- 2004-08-11 15:36:55 - /usr/bin/cvs -f -R -Q -d/home/ncvs checkout -P -A src TB --- 2004-08-11 15:44:29 - WARNING: /home/tinderbox/sandbox/sparc64.diff does not exist TB --- 2004-08-11 15:44:29 - building world (CFLAGS=-O -pipe) TB --- 2004-08-11 15:44:29 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src TB --- 2004-08-11 15:44:29 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> 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 [...] ===> lib/libbsnmp/libbsnmp rm -f .depend mkdep -f .depend -a -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib -DHAVE_ERR_H -DHAVE_GETADDRINFO -DHAVE_STRLCPY /tinderbox/CURRENT/sparc64/sparc64/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/asn1.c /tinderbox/CURRENT/sparc64/sparc64/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.c /tinderbox/CURRENT/sparc64/sparc64/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpagent.c /tinderbox/CURRENT/sparc64/sparc64/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpclient.c /tinderbox/CURRENT/sparc64/sparc64/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/support.c ===> lib/libbsnmp/modules ===> lib/libbsnmp/modules/snmp_atm cat /tinderbox/CURRENT/sparc64/sparc64/src/lib/libbsnmp/modules/snmp_atm/../../../../contrib/ngatm/snmp_atm/atm_tree.def /tinderbox/CURRENT/sparc64/sparc64/src/lib/libbsnmp/modules/snmp_atm/atm_freebsd.def | gensnmptree -e begemotAtm > atm_oid.h line 110: junk after closing ')' context: "1 internet *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/lib/libbsnmp/modules/snmp_atm. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/lib/libbsnmp/modules. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/lib/libbsnmp. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/lib. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-08-11 15:59:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-11 15:59:51 - ERROR: failed to build world TB --- 2004-08-11 15:59:51 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 16:20:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B2DA16A4CE; Wed, 11 Aug 2004 16:20:28 +0000 (GMT) Received: from mail.imp.ch (ns1.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12FDD43D48; Wed, 11 Aug 2004 16:20:27 +0000 (GMT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.9p2/8.12.3) with ESMTP id i7BGKH1m093593; Wed, 11 Aug 2004 18:20:19 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Wed, 11 Aug 2004 18:20:17 +0200 (CEST) From: Martin Blapp To: Robert Watson In-Reply-To: Message-ID: <20040811181850.W31181@cvs.imp.ch> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checksum: f9db2e54ef334b16bff3d247145225ac X-Virus-Status: No, scantime="0.0019 seconds" X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=4 scantime="4.1272 seconds" tests=BAYES_00 X-Scanned-By: MIMEDefang 2.44 cc: freebsd-current@freebsd.org Subject: Re: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 16:20:28 -0000 Hi, > I've found that for throughput oriented workloads, 4BSD substantially > outperforms ULE, but I haven't tried it with Jeff's latest set of patches > (committed a day or two ago). You don't mention if your box is SMP, btw > -- I've noticed some load balancing problems with ULE previously, but > haven't checked if they were resolved. Anecdotal opinion seems generally > to be that interactivity is observably better with ULE than 4BSD, but that > 4BSD appears to do a better job under load. If the load doesn't grow over 2, I'd say the scheduler is broken. This is SMP btw. > SMP. Some of the wins on SMP have been from moving to adaptive mutexes by > default (most recently, for Giant on i386); others from improved fine > grain locking in VM and networking, and general optimization of > synchronization primitives, scheduling, wakeups/locking, etc. The tests I've done are with your adaptive giant option and Jeff's ULE patches. Martin From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 16:31:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7682516A4D2 for ; Wed, 11 Aug 2004 16:31:15 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47CC043D1D for ; Wed, 11 Aug 2004 16:31:15 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7BGVB8U028629; Wed, 11 Aug 2004 09:31:13 -0700 Message-ID: <411A49A1.4070504@root.org> Date: Wed, 11 Aug 2004 09:30:25 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luo Hong , current@freebsd.org References: <41131EEC.4050909@root.org> <291946042.22742@mails.tsinghua.edu.cn> <292099916.02624@mails.tsinghua.edu.cn> <292119349.27842@mails.tsinghua.edu.cn> <292159260.15722@mails.tsinghua.edu.cn> <292208319.23518@mails.tsinghua.edu.cn> In-Reply-To: <292208319.23518@mails.tsinghua.edu.cn> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: PLEASE TEST: acpi pci irq routing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 16:31:15 -0000 Luo Hong wrote: > Nate Lawson wrote: > >> Thanks for the dmesg. My work completely revamps the IRQ routing and >> no longer is dependent on the status (_STA) as the PR indicates. >> >> I found two problems your testing revealed, fixed them, then made this >> patch. Please revert the old patch, apply this one, and test. Your >> system has a LOT of PRT entries. :) >> >> -Nate > > > Thanks very much. The PS/2 mouse can work well with the new patch. But I > still include the new dmesg from boot -v and the acpi asl, > you can check if all things are good. I don't know why there are too > lots of PRT entries and whether it is good or bad. > I think the patch could be committed now, and really thanks for your > hard work:) You're welcome. Your dmesg shows that the updated algorithm works as expected. I've committed the patch. FYI, your machine has entries for 38 PCI slots (including embedded devices). :) -Nate From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 16:32:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3ECC216A4CE for ; Wed, 11 Aug 2004 16:32:39 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF61C43D39 for ; Wed, 11 Aug 2004 16:32:38 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7BGV2lO021212; Wed, 11 Aug 2004 12:31:03 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7BGV2ns021209; Wed, 11 Aug 2004 12:31:02 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 11 Aug 2004 12:31:02 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Martin Blapp In-Reply-To: <20040811181850.W31181@cvs.imp.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 16:32:39 -0000 On Wed, 11 Aug 2004, Martin Blapp wrote: > > I've found that for throughput oriented workloads, 4BSD substantially > > outperforms ULE, but I haven't tried it with Jeff's latest set of patches > > (committed a day or two ago). You don't mention if your box is SMP, btw > > -- I've noticed some load balancing problems with ULE previously, but > > haven't checked if they were resolved. Anecdotal opinion seems generally > > to be that interactivity is observably better with ULE than 4BSD, but that > > 4BSD appears to do a better job under load. > > If the load doesn't grow over 2, I'd say the scheduler is broken. This > is SMP btw. Well, it's a little more complicated than one might think on face value (not to disagree with your point, though). The load average is a statistic measured by the system, based on the notion of a run queue. Since the run queue is a property of the scheduler, the scheduler is responsible for coming up with a notion of "load average". This raises an interesting question: are we measuring the load average incorrectly on ULE, are we not getting enough work done, or both. Given the performance results seen for throughput on applications like MySQL, which are a direct property of scheduler operation, I'd say it has a scheduling problem that might well result in a statistic like the one you're seeing. However, it could also be that the statistic is being measured or generated improperly. > > SMP. Some of the wins on SMP have been from moving to adaptive mutexes by > > default (most recently, for Giant on i386); others from improved fine > > grain locking in VM and networking, and general optimization of > > synchronization primitives, scheduling, wakeups/locking, etc. > > The tests I've done are with your adaptive giant option and Jeff's ULE > patches. You might well want to try 4BSD. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 16:42:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF41316A4CE; Wed, 11 Aug 2004 16:42:06 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C9BF43D45; Wed, 11 Aug 2004 16:42:06 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7BGg58U028832; Wed, 11 Aug 2004 09:42:06 -0700 Message-ID: <411A4C30.6050300@root.org> Date: Wed, 11 Aug 2004 09:41:20 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: HEADSUP: new pci irq routing committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 16:42:06 -0000 Thanks to all the testers. The new pci irq routing code fixes devices for several users. If anyone has PCI device problems (timeouts, etc.), let me know. Send me the output of dmesg from boot -v and your ASL (acpidump -t -d > machine.asl) Thanks, -Nate From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 16:48:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2CB816A4CE for ; Wed, 11 Aug 2004 16:48:27 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21FC043D39 for ; Wed, 11 Aug 2004 16:48:27 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i7BGmQX338338 for ; Wed, 11 Aug 2004 18:48:26 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) i7BGmQf767320 for ; Wed, 11 Aug 2004 18:48:26 +0200 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i7BGmPe29152 for ; Wed, 11 Aug 2004 18:48:25 +0200 (MET DST) Date: Wed, 11 Aug 2004 18:48:25 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: current@freebsd.org In-Reply-To: <20040811150931.9AA077303F@freebsd-current.sentex.ca> Message-ID: <20040811184748.M86410@beagle.kn.op.dlr.de> References: <20040811150931.9AA077303F@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2004 16:48:28 -0000 Sorry for that breakage. This needs a new gensnmptree. I just committed a fix to Makefile.inc1. harti On Wed, 11 Aug 2004, FreeBSD Tinderbox wrote: FT>TB --- 2004-08-11 14:41:53 - tinderbox 2.3 running on freebsd-current.sentex.ca FT>TB --- 2004-08-11 14:41:53 - starting CURRENT tinderbox run for ia64/ia64 FT>TB --- 2004-08-11 14:41:53 - cleaning the sandbox FT>TB --- 2004-08-11 14:43:00 - checking out the source tree FT>TB --- 2004-08-11 14:43:00 - cd /home/tinderbox/sandbox/CURRENT/ia64/ia64 FT>TB --- 2004-08-11 14:43:00 - /usr/bin/cvs -f -R -Q -d/home/ncvs checkout -P -A src FT>TB --- 2004-08-11 14:50:49 - WARNING: /home/tinderbox/sandbox/ia64.diff does not exist FT>TB --- 2004-08-11 14:50:49 - building world (CFLAGS=-O -pipe) FT>TB --- 2004-08-11 14:50:49 - cd /home/tinderbox/sandbox/CURRENT/ia64/ia64/src FT>TB --- 2004-08-11 14:50:49 - /usr/bin/make -B buildworld FT>>>> Building an up-to-date make(1) FT>>>> Rebuilding the temporary build tree FT>>>> stage 1.1: legacy release compatibility shims FT>>>> stage 1.2: bootstrap tools FT>>>> stage 2.1: cleaning up the object tree FT>>>> stage 2.2: rebuilding the object tree FT>>>> stage 2.3: build tools FT>>>> stage 3: cross tools FT>>>> stage 4.1: building includes FT>>>> stage 4.2: building libraries FT>[...] FT>===> lib/libbsnmp/libbsnmp FT>rm -f .depend FT>mkdep -f .depend -a -I/tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib -DHAVE_ERR_H -DHAVE_GETADDRINFO -DHAVE_STRLCPY /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/asn1.c /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.c /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpagent.c /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpclient.c /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/support.c FT>===> lib/libbsnmp/modules FT>===> lib/libbsnmp/modules/snmp_atm FT>cat /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/modules/snmp_atm/../../../../contrib/ngatm/snmp_atm/atm_tree.def /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/modules/snmp_atm/atm_freebsd.def | gensnmptree -e begemotAtm > atm_oid.h FT>line 110: junk after closing ')' FT>context: "1 internet FT>*** Error code 1 FT> FT>Stop in /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/modules/snmp_atm. FT>*** Error code 1 FT> FT>Stop in /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp/modules. FT>*** Error code 1 FT> FT>Stop in /tinderbox/CURRENT/ia64/ia64/src/lib/libbsnmp. FT>*** Error code 1 FT> FT>Stop in /tinderbox/CURRENT/ia64/ia64/src/lib. FT>*** Error code 1 FT> FT>Stop in /tinderbox/CURRENT/ia64/ia64/src. FT>*** Error code 1 FT> FT>Stop in /tinderbox/CURRENT/ia64/ia64/src. FT>*** Error code 1 FT> FT>Stop in /tinderbox/CURRENT/ia64/ia64/src. FT>*** Error code 1 FT> FT>Stop in /tinderbox/CURRENT/ia64/ia64/src. FT>TB --- 2004-08-11 15:09:31 - WARNING: /usr/bin/make returned exit code 1 FT>TB --- 2004-08-11 15:09:31 - ERROR: failed to build world FT>TB --- 2004-08-11 15:09:31 - tinderbox aborted FT> FT>_______________________________________________ FT>freebsd-current@freebsd.org mailing list FT>http://lists.freebsd.org/mailman/listinfo/freebsd-current FT>To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" FT> FT> FT> From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 16:57:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 716CB16A4CE for ; Wed, 11 Aug 2004 16:57:29 +0000 (GMT) Received: from meitner.wh.uni-dortmund.de (meitner.wh.Uni-Dortmund.DE [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 052C443D31 for ; Wed, 11 Aug 2004 16:57:29 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id 11794167509; Wed, 11 Aug 2004 18:57:28 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i7BGvH46063134 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 11 Aug 2004 18:57:20 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: freebsd-current@FreeBSD.org, rnejdl@ringofsaturn.com Date: Wed, 11 Aug 2004 18:57:12 +0200 User-Agent: KMail/1.6.2 References: <18300.12.148.147.242.1092234409.squirrel@[12.148.147.242]> In-Reply-To: <18300.12.148.147.242.1092234409.squirrel@[12.148.147.242]> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_r/kGBdHNQpnojke"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408111857.16230.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new Subject: Re: Signal 11 compiling qt33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 16:57:29 -0000 --Boundary-02=_r/kGBdHNQpnojke Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 11 August 2004 16:26, Rusty Nejdl wrote: > Would updating my world solve this problem at all for me? This is the > latest (as of this morning) ports. uic segfaulting like this is often a result of mixed up threads libraries... You could use a package from http://rabarber.fruitsalad.org, they have=20 recently been redone for post-gcc-3.4 -CURRENT. http://rabarber.fruitsalad.org/packages/3.2.3-final-5/5-CURRENT/All/qt-3.3.= 2_2.tbz=20 is the direct link. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --Boundary-02=_r/kGBdHNQpnojke Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBGk/rXhc68WspdLARAmAzAJ4ocoOHiYsEmCMbIvIorKdK2qPFUwCcDE6w k7Sg91hYhNw1d+UkBH0HBK0= =FSaj -----END PGP SIGNATURE----- --Boundary-02=_r/kGBdHNQpnojke-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 17:10:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9176516A4CF for ; Wed, 11 Aug 2004 17:10:10 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85C8F43D49 for ; Wed, 11 Aug 2004 17:10:10 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 7112172DF2; Wed, 11 Aug 2004 10:10:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 6F4E472DB5; Wed, 11 Aug 2004 10:10:10 -0700 (PDT) Date: Wed, 11 Aug 2004 10:10:10 -0700 (PDT) From: Doug White To: Terrence Koeman In-Reply-To: <200408102328524.SM01804@manrikigusari> Message-ID: <20040811100751.X99067@carver.gumbysoft.com> References: <200408102328524.SM01804@manrikigusari> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: RE: Compiler segmentation fault in 5-08 -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 17:10:10 -0000 On Tue, 10 Aug 2004, Terrence Koeman wrote: > > I have copied over /usr/bin/* from another working system and > > now I can > > compile things again. > > > > Is there anything that could create new problems when doing this? For some reason I got this part of the reply 4 times. :) Data corruption has many sources.. bad disk, crash at the wrong moment, errant program... > Well, it seems to be fixed now. As I said I copied over the /usr/bin dir > from another system and build world with it. It gave a shitload of warnings > I've never seen, but it proceeded anyway. A build & installworld should clean those up by getting all the piescs replaced with working versions. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 17:14:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F5A116A4CE for ; Wed, 11 Aug 2004 17:14:53 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4699C43D39 for ; Wed, 11 Aug 2004 17:14:53 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from dhcp50.pn.xcllnt.net (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i7BHErF4081216; Wed, 11 Aug 2004 10:14:53 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp50.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp50.pn.xcllnt.net (8.13.1/8.13.1) with ESMTP id i7BHErQ6024885; Wed, 11 Aug 2004 10:14:53 -0700 (PDT) (envelope-from marcel@dhcp50.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp50.pn.xcllnt.net (8.13.1/8.13.1/Submit) id i7BHErtu024884; Wed, 11 Aug 2004 10:14:53 -0700 (PDT) (envelope-from marcel) Date: Wed, 11 Aug 2004 10:14:53 -0700 From: Marcel Moolenaar To: Michael Nottebrock Message-ID: <20040811171453.GA24847@dhcp50.pn.xcllnt.net> References: <18300.12.148.147.242.1092234409.squirrel@[12.148.147.242]> <200408111857.16230.michaelnottebrock@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408111857.16230.michaelnottebrock@gmx.net> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: FreeBSD/ia64, gcc-3.4: editors/koffice-kde3 [was: Re: Signal 11 ...] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 17:14:53 -0000 On Wed, Aug 11, 2004 at 06:57:12PM +0200, Michael Nottebrock wrote: > On Wednesday 11 August 2004 16:26, Rusty Nejdl wrote: > > > Would updating my world solve this problem at all for me? This is the > > latest (as of this morning) ports. > > uic segfaulting like this is often a result of mixed up threads libraries... > > You could use a package from http://rabarber.fruitsalad.org, they have > recently been redone for post-gcc-3.4 -CURRENT. OT: editors/koffice-kde3 fails to build on FreeBSD/ia64, yet the package exists for i386. Should I assume that kde3 builds completely on i386 and that failures on ia64 are new or unknown and thus that I need to report them? Yes, kde3/ia64 built fine pre-gcc-3.4. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 17:17:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D62116A4CE; Wed, 11 Aug 2004 17:17:07 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42E6F43D1F; Wed, 11 Aug 2004 17:17:07 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 344A772DF4; Wed, 11 Aug 2004 10:17:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 3297572DF2; Wed, 11 Aug 2004 10:17:07 -0700 (PDT) Date: Wed, 11 Aug 2004 10:17:07 -0700 (PDT) From: Doug White To: "Conrad J. Sabatier" In-Reply-To: Message-ID: <20040811101206.M99067@carver.gumbysoft.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: freebsd-amd64@freebsd.org cc: Oliver Eikemeier Subject: Re: cvsup on amd64 just broke today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 17:17:07 -0000 On Tue, 10 Aug 2004, Conrad J. Sabatier wrote: > I meant, why isn't it buildable from source in the ports collection? Checking the commit logs, I don't think Peter ever committed the patches to make ezm3 work under amd64 native. The port on amd64 just downloads the same binary you were using .. the i386 version and an extra library. ezm3 builds the runtime libs needed to compile Modula-3 apps. Interestingly, jdp just touched that port. I guess he doesn't have peter's patches, or hasn't adapted them for the distro yet. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 17:21:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CBB316A4CE; Wed, 11 Aug 2004 17:21:32 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30AD943D31; Wed, 11 Aug 2004 17:21:32 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 24CDF72DF2; Wed, 11 Aug 2004 10:21:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 22A7772DB5; Wed, 11 Aug 2004 10:21:32 -0700 (PDT) Date: Wed, 11 Aug 2004 10:21:32 -0700 (PDT) From: Doug White To: Terrence Koeman In-Reply-To: <200408111527566.SM01804@manrikigusari> Message-ID: <20040811101859.P99067@carver.gumbysoft.com> References: <200408111527566.SM01804@manrikigusari> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@FreeBSD.org cc: 'John Baldwin' Subject: RE: Lock order reversal in 5.2-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 17:21:32 -0000 On Wed, 11 Aug 2004, Terrence Koeman wrote: > I think something else is wrong, as I get different lock order reversals and > some other errors that all lockup the box. Earlier I had a corrupted cc > binary after a buildworld. > > Everything points to a hardware failure somewhere, but I already switched > the hardware before this happened, I swapped RAID arrays in identical > machines, and the machine where -CURRENT runs on now was a production server > that ran 4.9/4.10-STABLE for months under heavy load without any problems > whatsoever. > > The following is what I got today: > > Second bad > /: bad dir ino 16110954 at offset 24: mangled entry > panic: ufs_dirbad: bad dir Your RAID is doing a really good job of corrupting your data. :) What RAID controller and volume layout are you using? > Fatal trap 18: integer divide fault while in kernel mode This looks more serious .. you may have a bad CPU, memory, or some other critical component. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 17:31:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F61416A4CE for ; Wed, 11 Aug 2004 17:31:30 +0000 (GMT) Received: from meitner.wh.uni-dortmund.de (meitner.wh.Uni-Dortmund.DE [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC08643D58 for ; Wed, 11 Aug 2004 17:31:29 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id C07571674EF; Wed, 11 Aug 2004 19:31:28 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i7BHVQ46065718 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 11 Aug 2004 19:31:27 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: Marcel Moolenaar Date: Wed, 11 Aug 2004 19:31:21 +0200 User-Agent: KMail/1.6.2 References: <18300.12.148.147.242.1092234409.squirrel@[12.148.147.242]> <200408111857.16230.michaelnottebrock@gmx.net> <20040811171453.GA24847@dhcp50.pn.xcllnt.net> In-Reply-To: <20040811171453.GA24847@dhcp50.pn.xcllnt.net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_tflGBnkbe6v1saN"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408111931.25126.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new cc: freebsd-current@freebsd.org Subject: Re: FreeBSD/ia64, gcc-3.4: editors/koffice-kde3 [was: Re: Signal 11 ...] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 17:31:30 -0000 --Boundary-02=_tflGBnkbe6v1saN Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 11 August 2004 19:14, Marcel Moolenaar wrote: > OT: editors/koffice-kde3 fails to build on FreeBSD/ia64, yet the package > exists for i386. Should I assume that kde3 builds completely on i386 and > that failures on ia64 are new or unknown and thus that I need to report > them? KOffice has only recently been updated to version 1.3.2. 1.3.1 has known=20 issues with gcc-3.4. The update fixed those on i386, so it hopefully should= =20 fix ia64, too. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --Boundary-02=_tflGBnkbe6v1saN Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBGlftXhc68WspdLARAi2TAJsEZIfD8rVSVONNHZuHQeutdenHggCfazDm WSZRLvDayrli4ct6/yEngBk= =cVuP -----END PGP SIGNATURE----- --Boundary-02=_tflGBnkbe6v1saN-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 17:31:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D16816A4D0; Wed, 11 Aug 2004 17:31:55 +0000 (GMT) Received: from av9-1-sn1.fre.skanova.net (av9-1-sn1.fre.skanova.net [81.228.11.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8102343D58; Wed, 11 Aug 2004 17:31:54 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av9-1-sn1.fre.skanova.net (Postfix, from userid 502) id ACEB137E48; Wed, 11 Aug 2004 19:31:53 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av9-1-sn1.fre.skanova.net (Postfix) with ESMTP id 9970537E42; Wed, 11 Aug 2004 19:31:53 +0200 (CEST) Received: from gadget (h130n1fls11o822.telia.com [213.64.66.130]) by smtp3-2-sn1.fre.skanova.net (Postfix) with ESMTP id 7062337E4E; Wed, 11 Aug 2004 19:31:53 +0200 (CEST) From: "Daniel Eriksson" To: "'Nate Lawson'" , Date: Wed, 11 Aug 2004 19:31:51 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcR/tB/xgPTAEpRyT0OfGacp8k8iIQAE04pQ In-Reply-To: <200408111452.i7BEqoNN071668@repoman.freebsd.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: RE: cvs commit: src/sys/dev/acpica acpi_pci_link.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c acpi_pcibvar.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 17:31:55 -0000 Nate Lawson wrote: > Modified files: > sys/dev/acpica acpi_pci_link.c acpi_pcib.c > acpi_pcib_acpi.c acpi_pcib_pci.c > acpi_pcibvar.h > Log: > Re-work ACPI PCI IRQ routing (_PRT, link devices). The old > approach was > incomplete in that the PRT routing was not aware of link > programming. > Fix this by doing all routing through the link devices. This(?) breaks interrupt routing pretty badly on ASUS A7V600-X (VIA KT-600 chipset). A kernel/userland from 2004.08.09.13.00.00 works just fine (sorry, no dmesg available right now), but a kernel/userland from 2004.08.11.15.00.00 breaks routing of interrupts to (at least) two HighPoint RocketRAID 454 cards. Below is part of the dmesg from a boot with ACPI on. Does it matter that "PnP OS installed" is turned off in the BIOS? I will run some more tests later tonight and report the results here. This is just a FYI that something might be broken... /Daniel Eriksson /boot/kernel/acpi.ko text=0x44df8 data=0x1b84+0xd2c syms=[0x4+0x6ca0+0x4+0x8d16] KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2004 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 5.2-CURRENT #1: Wed Aug 11 18:29:23 CEST 2004 daniel@fortify.satra.zapto.org:/usr/obj/usr/src/sys/FORTIFY Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(TM) XP 2500+ (1999.78-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 Features=0x383fbff AMD Features=0xc0400000 real memory = 1342156800 (1279 MB) avail memory = 1305075712 (1244 MB) ACPI APIC Table: ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [GIANT-LOCKED] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xf8000000-0xfbffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) atapci0: port 0xb400-0xb4ff,0xb800-0xb803,0xd000-0xd007,0xd400-0xd403,0xd800-0xd807 irq 11 at device 10.0 on pci0 ata2: at 0xd800 on atapci0 ata3: at 0xd000 on atapci0 atapci1: port 0x9800-0x98ff,0xa000-0xa003,0xa400-0xa407,0xa800-0xa803,0xb000-0xb007 irq 11 at device 10.1 on pci0 ata4: at 0xb000 on atapci1 ata5: at 0xa400 on atapci1 ahc0: port 0x9400-0x94ff mem 0xed800000-0xed800fff irq 3 at device 12.0 on pci0 ahc0: [GIANT-LOCKED] aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs atapci2: port 0x7800-0x78ff,0x8000-0x8003,0x8400-0x8407,0x8800-0x8803,0x9000-0x9007 irq 10 at device 14.0 on pci0 ata6: at 0x9000 on atapci2 ata7: at 0x8400 on atapci2 atapci3: port 0x6000-0x60ff,0x6400-0x6403,0x6800-0x6807,0x7000-0x7003,0x7400-0x7407 irq 10 at device 14.1 on pci0 ata8: at 0x7400 on atapci3 ata9: at 0x6800 on atapci3 atapci4: port 0x4000-0x40ff,0x4400-0x440f,0x4800-0x4803,0x5000-0x5007,0x5400-0x5403,0x5800 -0x5807 irq 5 at device 15.0 on pci0 ata10: at 0x5800 on atapci4 ata11: at 0x5000 on atapci4 atapci5: port 0x3800-0x380f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 14 at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci5 ata1: at 0x170 irq 15 on atapci5 uhci0: port 0x3400-0x341f irq 7 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x3000-0x301f irq 7 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x2800-0x281f irq 5 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x2400-0x241f irq 5 at device 16.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xed000000-0xed0000ff irq 9 at device 16.4 on pci0 ehci0: [GIANT-LOCKED] ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 ehci_pci_attach: companion usb3 usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 vr0: port 0x2000-0x20ff mem 0xec800000-0xec8000ff irq 7 at device 18.0 on pci0 miibus0: on vr0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:0e:a6:1f:29:1e vr0: [GIANT-LOCKED] re0: port 0x1800-0x18ff mem 0xec000000-0xec0000ff irq 12 at device 19.0 on pci0 miibus1: on re0 rgephy0: on miibus1 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto re0: Ethernet address: 00:50:fc:f8:c6:81 re0: [GIANT-LOCKED] fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] orm0: at iomem 0xc0000-0xcafff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1999782373 Hz quality 800 Timecounters tick every 1.000 msec ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to accept, logging unlimited ad0: 114473MB [232581/16/63] at ata0-master UDMA100 ad1: 114473MB [232581/16/63] at ata0-slave UDMA100 ad2: 117800MB [239340/16/63] at ata1-master UDMA100 ad3: 117800MB [239340/16/63] at ata1-slave UDMA100 ata2-slave: FAILURE - ATA_IDENTIFY no interrupt ata2-slave: FAILURE - ATA_IDENTIFY no interrupt ata2-master: FAILURE - ATA_IDENTIFY no interrupt ata2-master: FAILURE - ATA_IDENTIFY no interrupt ata3-slave: FAILURE - ATA_IDENTIFY no interrupt ata3-slave: FAILURE - ATA_IDENTIFY no interrupt ata3-master: FAILURE - ATA_IDENTIFY no interrupt ata3-master: FAILURE - ATA_IDENTIFY no interrupt ata4-slave: FAILURE - ATA_IDENTIFY no interrupt ata4-slave: FAILURE - ATA_IDENTIFY no interrupt ata4-master: FAILURE - ATA_IDENTIFY no interrupt [...] From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 17:41:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C40016A4CE for ; Wed, 11 Aug 2004 17:41:20 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A36A43D3F for ; Wed, 11 Aug 2004 17:41:20 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7BHfJ8U030376; Wed, 11 Aug 2004 10:41:19 -0700 Message-ID: <411A5A12.2070404@root.org> Date: Wed, 11 Aug 2004 10:40:34 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eriksson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/sys/dev/acpica acpi_pci_link.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c acpi_pcibvar.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 17:41:20 -0000 Daniel Eriksson wrote: > Nate Lawson wrote: > > >> Modified files: >> sys/dev/acpica acpi_pci_link.c acpi_pcib.c >> acpi_pcib_acpi.c acpi_pcib_pci.c >> acpi_pcibvar.h >> Log: >> Re-work ACPI PCI IRQ routing (_PRT, link devices). The old >>approach was >> incomplete in that the PRT routing was not aware of link >>programming. >> Fix this by doing all routing through the link devices. > > > This(?) breaks interrupt routing pretty badly on ASUS A7V600-X (VIA KT-600 > chipset). > > A kernel/userland from 2004.08.09.13.00.00 works just fine (sorry, no dmesg > available right now), but a kernel/userland from 2004.08.11.15.00.00 breaks > routing of interrupts to (at least) two HighPoint RocketRAID 454 cards. > > Below is part of the dmesg from a boot with ACPI on. Does it matter that > "PnP OS installed" is turned off in the BIOS? I will run some more tests > later tonight and report the results here. This is just a FYI that something > might be broken... That may affect it. Let me know. > atapci0: port > 0xb400-0xb4ff,0xb800-0xb803,0xd000-0xd007,0xd400-0xd403,0xd800-0xd807 irq 11 > atapci1: port > 0x9800-0x98ff,0xa000-0xa003,0xa400-0xa407,0xa800-0xa803,0xb000-0xb007 irq 11 > ahc0: port 0x9400-0x94ff mem > 0xed800000-0xed800fff irq 3 at device 12.0 on pci0 > atapci2: port > 0x7800-0x78ff,0x8000-0x8003,0x8400-0x8407,0x8800-0x8803,0x9000-0x9007 irq 10 > atapci3: port > 0x6000-0x60ff,0x6400-0x6403,0x6800-0x6807,0x7000-0x7003,0x7400-0x7407 irq 10 > at device 14.1 on pci0 > atapci4: port > 0x4000-0x40ff,0x4400-0x440f,0x4800-0x4803,0x5000-0x5007,0x5400-0x5403,0x5800 > -0x5807 irq 5 at device 15.0 on pci0 > atapci5: port > 0x3800-0x380f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 14 at device 15.1 on > pci0 > ata0: at 0x1f0 irq 14 on atapci5 > ata1: at 0x170 irq 15 on atapci5 I need the dmesg output from boot -v to see the link priority settings. -- Nate From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 17:54:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78F2716A4CE for ; Wed, 11 Aug 2004 17:54:53 +0000 (GMT) Received: from miramanee.icarz.com (miramanee.icarz.com [207.99.22.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9719D43D45 for ; Wed, 11 Aug 2004 17:54:50 +0000 (GMT) (envelope-from kenfreebsd@icarz.com) Received: from deanna.icarz.com (deanna.icarz.com [207.99.22.19]) by miramanee.icarz.com (8.12.10/8.12.10) with ESMTP id i7BHsnUR087082; Wed, 11 Aug 2004 13:54:49 -0400 (EDT) (envelope-from kenfreebsd@icarz.com) Received: from kenxp (netb-138.icarz.com [209.123.219.138]) by deanna.icarz.com (8.12.9p2/8.12.9) with SMTP id i7BHsmIf075574; Wed, 11 Aug 2004 13:54:48 -0400 (EDT) (envelope-from kenfreebsd@icarz.com) Message-ID: <073d01c47fcc$4b2a3610$8adb7bd1@icarz.com> From: "Ken Menzel" To: "Rainer Duffner" , References: <20040810152646.30258.qmail@bsd.ultra-secure.de> Date: Wed, 11 Aug 2004 13:54:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: -100 () USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.39 Subject: Re: buildworld problem [me too, and more info (/sbin/routed)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Ken Menzel List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2004 17:54:53 -0000 cvsup from yesterday and another try today. Attempting to upgrade 5.2.1 RC2 system. I read UPDATING but did not see any hints and ran mergemaster -p. Any ideas? 3 pieces follow 1) make of routed 2) uname from System 3) output from make -B buildword -------------------------------------------------------------------- Also tried to compile /usr/src/sbin/routed manualy with following results: cd /usr/src/rescue/rescue/../../sbin/routed && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE if.o input.o main.o output.o parms.o radix.o rdisc.o table.o trace.o ===> rtquery cc -O -pipe -mcpu=pentiumpro -DRESCUE -c /usr/src/sbin/routed/if.c cc -O -pipe -mcpu=pentiumpro -DRESCUE -c /usr/src/sbin/routed/input.c /usr/src/sbin/routed/input.c: In function `ck_passwd': /usr/src/sbin/routed/input.c:978: error: `RIP_AUTH_MD5_HASH_LEN' undeclared (first use in this function) /usr/src/sbin/routed/input.c:978: error: (Each undeclared identifier is reported only once /usr/src/sbin/routed/input.c:978: error: for each function it appears in.) /usr/src/sbin/routed/input.c:1001: error: `RIP_AUTH_MD5_HASH_XTRA' undeclared (first use in this function) /usr/src/sbin/routed/input.c:1002: error: `RIP_AUTH_MD5_KEY_LEN' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sbin/routed. freebsd3# ---------------------------------------------------------------------- ------ More Info: freebsd3# uname -a FreeBSD freebsd3.icarz.com 5.2.1-RC2 FreeBSD 5.2.1-RC2 #0: Thu Feb 12 16:28:31 GMT 2004 root@wv1u.btc.adaptec.com:/usr/obj/usr/src/sys/GENERIC i386 `rcorder.o' is up to date. (cd /usr/src/rescue/rescue/../../sbin/route && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE route.o) `route.o' is up to date. (cd /usr/src/rescue/rescue/../../sbin/routed && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE if.o input.o main.o output.o parms.o radix.o rdisc.o table.o trace.o) +for: not found *** Error code 127 Stop in /usr/src/sbin/routed. *** Error code 1 etc, etc. ----- Original Message ----- From: "Rainer Duffner" To: Sent: Tuesday, August 10, 2004 11:26 AM Subject: buildworld problem > Hi, > > I get this: > .... > mkdep -f .depend -a -DRRESTORE -DRESCUE /usr/src/sbin/restore/main.c > /usr/src/sbin/restore/interactive.c /usr/src/sbin/restore/restore.c > /usr/src/sbin/restore/dirs.c /usr/src/sbin/restore/symtab.c > /usr/src/sbin/restore/tape.c /usr/src/sbin/restore/utilities.c > /usr/src/sbin/restore/../dump/dumprmt.c > echo restore: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend > cc -O -pipe -DRRESTORE -DRESCUE -c /usr/src/sbin/restore/main.c > cc -O -pipe -DRRESTORE -DRESCUE -c /usr/src/sbin/restore/interactive.c > cc -O -pipe -DRRESTORE -DRESCUE -c /usr/src/sbin/restore/restore.c > cc -O -pipe -DRRESTORE -DRESCUE -c /usr/src/sbin/restore/dirs.c > cc -O -pipe -DRRESTORE -DRESCUE -c /usr/src/sbin/restore/symtab.c > cc -O -pipe -DRRESTORE -DRESCUE -c /usr/src/sbin/restore/tape.c > cc -O -pipe -DRRESTORE -DRESCUE -c /usr/src/sbin/restore/utilities.c > cc -O -pipe -DRRESTORE -DRESCUE -c /usr/src/sbin/restore/../dump/dumprmt.c > (cd /usr/src/rescue/rescue/../../sbin/rcorder && make -DRESCUE > CRUNCH_CFLAGS=-DRESCUE depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE > ealloc.o hash.o rcorder.o) > ln -sf /usr/src/sbin/rcorder/../../lib/libutil/libutil.h util.h > rm -f .depend > mkdep -f .depend -a -DORDER -I. -DRESCUE /usr/src/sbin/rcorder/ealloc.c > /usr/src/sbin/rcorder/hash.c /usr/src/sbin/rcorder/rcorder.c > echo rcorder: /usr/obj/usr/src/i386/usr/lib/libc.a > /usr/obj/usr/src/i386/usr/lib/libutil.a >> .depend > cc -O -pipe -DORDER -I. -DRESCUE -c /usr/src/sbin/rcorder/ealloc.c > cc -O -pipe -DORDER -I. -DRESCUE -c /usr/src/sbin/rcorder/hash.c > cc -O -pipe -DORDER -I. -DRESCUE -c /usr/src/sbin/rcorder/rcorder.c > (cd /usr/src/rescue/rescue/../../sbin/route && make -DRESCUE > CRUNCH_CFLAGS=-DRESCUE depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE > route.o) > sed -e '/^#/d' -e '/^$/d' /usr/src/sbin/route/keywords > _keywords.tmp > LC_ALL=C tr 'a-z' 'A-Z' < _keywords.tmp | paste _keywords.tmp - | awk '{ > if (NF > 1) printf "#define\tK_%s\t%d\n\t{\"%s\", K_%s},\n", $2, NR, $1, > $2 }' > keywords.h > rm -f _keywords.tmp > rm -f .depend > mkdep -f .depend -a -I. -DNS -DINET6 -DRESCUE /usr/src/sbin/route/route.c > echo route: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend > cc -O -pipe -I. -Wall -DNS -DINET6 -DRESCUE -c /usr/src/sbin/route/route.c > (cd /usr/src/rescue/rescue/../../sbin/routed && make -DRESCUE > CRUNCH_CFLAGS=-DRESCUE depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE if.o > input.o main.o output.o parms.o radix.o rdisc.o table.o trace.o) > rm -f .depend > mkdep -f .depend -a -DRESCUE /usr/src/sbin/routed/if.c > /usr/src/sbin/routed/input.c /usr/src/sbin/routed/main.c > /usr/src/sbin/routed/output.c /usr/src/sbin/routed/parms.c > /usr/src/sbin/routed/radix.c /usr/src/sbin/routed/rdisc.c > /usr/src/sbin/routed/table.c /usr/src/sbin/routed/trace.c > echo routed: /usr/obj/usr/src/i386/usr/lib/libc.a > /usr/obj/usr/src/i386/usr/lib/libmd.a >> .depend > +for: not found > *** Error code 127 > > Stop in /usr/src/sbin/routed. > *** Error code 1 > > Stop in /usr/obj/usr/src/rescue/rescue. > *** Error code 1 > > Stop in /usr/src/rescue/rescue. > *** Error code 1 > > Stop in /usr/src/rescue. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > > Has this been fixed ? > Or where would I need to look ? > > > Rainer > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 18:00:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3FC716A4CE for ; Wed, 11 Aug 2004 18:00:24 +0000 (GMT) Received: from moya.lambermont.dyndns.org (e165253.upc-e.chello.nl [213.93.165.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 600D043D45 for ; Wed, 11 Aug 2004 18:00:24 +0000 (GMT) (envelope-from hans@lambermont.dyndns.org) Received: from localhost (localhost [127.0.0.1]) by moya.lambermont.dyndns.org (Postfix) with ESMTP id A6F3D3640A for ; Wed, 11 Aug 2004 20:00:22 +0200 (CEST) Received: from moya.lambermont.dyndns.org ([127.0.0.1])port 10024) with ESMTP id 01557-05 for ; Wed, 11 Aug 2004 20:00:22 +0200 (CEST) Received: by moya.lambermont.dyndns.org (Postfix, from userid 1001) id 65DD336409; Wed, 11 Aug 2004 20:00:22 +0200 (CEST) Date: Wed, 11 Aug 2004 20:00:22 +0200 To: freebsd-current@freebsd.org Message-ID: <20040811180022.GA13882@moya.lambermont.dyndns.org> References: <20040810210918.GS991@funkthat.com> <20040811001407.GB15795@gothmog.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040811001407.GB15795@gothmog.gr> User-Agent: Mutt/1.4.2i From: hans@lambermont.dyndns.org (Hans Lambermont) X-Virus-Scanned: by amavisd-new-20030616.p5 at lambermont.dyndns.org Subject: Re: have you installworld'd since Friday? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 18:00:24 -0000 System built and installed on Saturday. (IBM T30 laptop) uname -a FreeBSD gagh.intra.aramiska.net 5.2-CURRENT FreeBSD 5.2-CURRENT #3: Sat Aug 7 22:28:50 CEST 2004 root@gagh.intra.aramiska.net:/new/usr/obj/new/usr/src/sys/GAGH i386 ident /boot/defaults/loader.conf /boot/defaults/loader.conf: $FreeBSD: src/sys/boot/forth/loader.conf,v 1.85 2004/08/06 15:06:06 jmg Exp $ kldstat Id Refs Address Size Name 1 58 0xc0400000 3b7eb0 kernel 2 14 0xc07b8000 51800 acpi.ko 3 1 0xc184d000 17000 linux.ko 4 1 0xc2a0d000 2000 snd_driver.ko 5 1 0xc2a0f000 4000 snd_als4000.ko 6 1 0xc2a13000 4000 snd_cmi.ko 7 1 0xc2a17000 4000 snd_cs4281.ko 8 2 0xc2a1b000 6000 snd_csa.ko 9 1 0xc2a21000 b000 snd_ds1.ko 10 1 0xc2a2c000 6000 snd_emu10k1.ko 11 1 0xc2a32000 5000 snd_es137x.ko 12 2 0xc2a37000 4000 snd_ess.ko 13 4 0xc2a3b000 4000 snd_sbc.ko 14 1 0xc2a3f000 4000 snd_fm801.ko 15 2 0xc2a5b000 9000 snd_mss.ko 16 1 0xc2a68000 5000 snd_ich.ko 17 1 0xc2a76000 6000 snd_maestro.ko 18 1 0xc2a7c000 7000 snd_maestro3.ko 19 1 0xc2a83000 10000 snd_neomagic.ko 20 1 0xc2a93000 4000 snd_sb8.ko 21 1 0xc2a97000 4000 snd_sb16.ko 22 1 0xc2a9b000 4000 snd_solo.ko 23 1 0xc2a9f000 4000 snd_t4dwave.ko 24 1 0xc2aa3000 4000 snd_via8233.ko 25 1 0xc2aa7000 4000 snd_via82c686.ko 26 1 0xc2aab000 4000 snd_vibes.ko a messy snd list, the pcm was removed and I didn't yet put the right one in my config pcm0: port 0x18c0-0x18ff,0x1c00-0x1cff irq 9 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: in fact I dont' even know which one this is ;-) Hope it helps. -- Hans Lambermont From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 18:10:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E527416A56F; Wed, 11 Aug 2004 18:10:41 +0000 (GMT) Received: from mail.imp.ch (ns1.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8987443D48; Wed, 11 Aug 2004 18:10:40 +0000 (GMT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.9p2/8.12.3) with ESMTP id i7BIAVMk014636; Wed, 11 Aug 2004 20:10:32 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Wed, 11 Aug 2004 20:10:31 +0200 (CEST) From: Martin Blapp To: Robert Watson In-Reply-To: Message-ID: <20040811200323.B31181@cvs.imp.ch> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checksum: 0e73bd6c2d0df148b8970e7680a10d85 X-Virus-Message-Status: No X-Virus-Status: No, scantime="0.0012 seconds" X-Spam-Status: No, hits=0.001 required=5 scantime="4.1723 seconds" tests=BAYES_50 X-Scanned-By: MIMEDefang 2.44 cc: freebsd-current@freebsd.org Subject: Re: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 18:10:45 -0000 Hi, > > You might well want to try 4BSD. > I did that too. The milter stress test I run was sending 200 mails with 5 different sorts of attachements into a mail loop. This means these 200 mails are going 26 times trough the milter. The ULE scheduler did process them first very fast. With more processes, the sendmail transactions lagged a lot and it was only running 1-2 of them at one time. This sucks because there is also a lot of timeout handling (waiting for DNS responses). All in one I must say that the SCHED4BSD processed the mails in half of the time as SCHEDULE did. The mix involved included everything: - Preforked mimedefang workers - Forked Sendmails - Threaded applications like clamd, mimedefang-milter So I'd call it a typical real world situation. Another thing I observed was that SCHED4BSD has zero IDLE time, while SCHEDULE always idled between 20% and 50% ! This with 500 running processes and a load of 2.5 -3.0. Martin From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 18:25:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C47D16A4CE for ; Wed, 11 Aug 2004 18:25:55 +0000 (GMT) Received: from phoenix.gargantuan.com (rrcs-se-24-73-171-238.biz.rr.com [24.73.171.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id D859443D3F for ; Wed, 11 Aug 2004 18:25:54 +0000 (GMT) (envelope-from freebsd-current@gargantuan.com) Received: from localhost (localhost.gargantuan.com [127.0.0.1]) by spamassassin-injector (Postfix) with SMTP id 877FC3F5; Wed, 11 Aug 2004 14:25:53 -0400 (EDT) Received: by phoenix.gargantuan.com (Postfix, from userid 1001) id 93AE72CD; Wed, 11 Aug 2004 14:25:16 -0400 (EDT) Date: Wed, 11 Aug 2004 14:25:16 -0400 From: "Michael W. Oliver" To: Ken Menzel Message-ID: <20040811182516.GA89556@gargantuan.com> Mail-Followup-To: Ken Menzel , Rainer Duffner , freebsd-current@freebsd.org References: <20040810152646.30258.qmail@bsd.ultra-secure.de> <073d01c47fcc$4b2a3610$8adb7bd1@icarz.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: <073d01c47fcc$4b2a3610$8adb7bd1@icarz.com> X-WWW-Site: http://michael.gargantuan.com X-PGP-Public-Key: $X-WWW-Site/gnupg/pubkey.asc X-PGP-Fingerprint: 2694 0179 AE3F BFAE 0916 0BF5 B16B FBAB C5FA A3C9 X-Home-Phone: +1-863-816-8091 X-Mobile-Phone: +1-863-738-2334 X-Home-Address0: 8008 Apache Lane X-Home-Address1: Lakeland, FL X-Home-Address2: 33810-2172 X-Home-Address3: United States of America X-Good-Question-Guide: http://www.catb.org/~esr/faqs/smart-questions.html X-Netiquette-Guidelines: http://www.ietf.org/rfc/rfc1855.txt User-Agent: Mutt/1.5.6i X-Spam-DCC: : X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on phoenix.gargantuan.com X-Spam-Level: X-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,BAYES_00,NO_DNS_FOR_FROM autolearn=no version=2.64 cc: freebsd-current@freebsd.org cc: Rainer Duffner Subject: Re: buildworld problem [me too, and more info (/sbin/routed)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 18:25:55 -0000 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004-08-11T13:54:48-0400, Ken Menzel wrote: > cvsup from yesterday and another try today. Attempting to upgrade > 5.2.1 RC2 system. I read UPDATING but did not see any hints and ran > mergemaster -p. Any ideas? [snip] > +for: not found > *** Error code 127 >=20 > Stop in /usr/src/sbin/routed. > *** Error code 1 I was getting the same thing, so I went into /usr/src/usr.bin/make and did (not that I actually know what I am doing, but this oozed from my memory from some past discussions on current@) ... make make install make clean Now `make` works for me again. HTH --=20 Mike perl -e 'print unpack("u","88V]N=3D&%C=3D\"!I;F9O(&EN(&AE861E Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F8E516A4DB for ; Wed, 11 Aug 2004 19:05:32 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 492F743D68 for ; Wed, 11 Aug 2004 19:05:18 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 12324 invoked from network); 11 Aug 2004 19:05:17 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 11 Aug 2004 19:05:17 -0000 Received: from [10.50.41.91] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i7BJ516V093561; Wed, 11 Aug 2004 15:05:13 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Wed, 11 Aug 2004 14:51:38 -0400 User-Agent: KMail/1.6.2 References: <20040811085229.GA62668@peter.osted.lan> In-Reply-To: <20040811085229.GA62668@peter.osted.lan> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408111451.38656.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: current@FreeBSD.org Subject: Re: Fatal trap 12 in kern/kern_switch.c:436 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 19:05:33 -0000 On Wednesday 11 August 2004 04:52 am, Peter Holm wrote: > While stress testing with kern.threads.virtual_cpu=256 I got this > fault after a kill -9 of a hung test program. Do you have PREEMPTION turned on? This is the same type of bug that people were seeing with PREEMPTION turned on. > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2004 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 5.2-CURRENT #0: Wed Aug 11 04:23:56 CEST 2004 > root@peter.osted.lan:/usr/src/sys/i386/compile/PHO > WARNING: WITNESS option enabled, expect reduced performance. > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Celeron(R) CPU 1.80GHz (1799.14-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf13 Stepping = 3 > > Features=0x3febfbffA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM> real memory > = 267583488 (255 MB) > avail memory = 252190720 (240 MB) > > ata1-master: DMA limited to UDMA33, non-ATA66 cable or device > acd0: CDROM at ata1-master UDMA33 > Mounting root from ufs:/dev/ad0s1a > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x54 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc066ab08 > stack pointer = 0x10:0xd25c1c50 > frame pointer = 0x10:0xd25c1c70 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 539 (pthread_setconcurre) > [thread 101883] > Stopped at setrunqueue+0x1e8: movl %edi,0x54(%edx) > db> where > setrunqueue(c1bac2c0,c1a957d0,c08b1292,484,c065038e) at setrunqueue+0x1e8 > sched_switch(c1bac2c0,0,c08b06b2,123,d3526cf3) at sched_switch+0xa4 > mi_switch(2,0,c08b2b56,f5,10000) at mi_switch+0x29f > ast(d25c1d48) at ast+0x3fb > doreti_ast() at doreti_ast+0x17 > db> call doadump > Dumping 255 MB > panic: blockable sleep lock (sleep mutex) taskqueue @ > kern/subr_taskqueue.c:132 cpuid = 0; > Uptime: 34m36s > panic: cv_wait: not TDS_RUNNING > cpuid = 0; > KDB: enter: panic > [thread 101883] > Stopped at kdb_enter+0x30: leave > db> > > (kgdb) l *0xc066ab08 > 0xc066ab08 is in setrunqueue (../../../kern/kern_switch.c:436). > 431 * put the new kse on whatever is next, > 432 * which may or may not be us. > 433 */ > 434 td2 = TAILQ_NEXT(tda, td_runq); > 435 kg->kg_last_assigned = td2; > 436 td2->td_kse = ke; > 437 ke->ke_thread = td2; > 438 } > 439 sched_add(ke->ke_thread); > 440 } else { > (kgdb) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 19:05:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C13916A4F4 for ; Wed, 11 Aug 2004 19:05:32 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1012C43D66 for ; Wed, 11 Aug 2004 19:05:18 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 12324 invoked from network); 11 Aug 2004 19:05:17 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 11 Aug 2004 19:05:17 -0000 Received: from [10.50.41.91] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i7BJ516V093561; Wed, 11 Aug 2004 15:05:13 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Wed, 11 Aug 2004 14:51:38 -0400 User-Agent: KMail/1.6.2 References: <20040811085229.GA62668@peter.osted.lan> In-Reply-To: <20040811085229.GA62668@peter.osted.lan> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408111451.38656.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: current@FreeBSD.org Subject: Re: Fatal trap 12 in kern/kern_switch.c:436 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 19:05:34 -0000 On Wednesday 11 August 2004 04:52 am, Peter Holm wrote: > While stress testing with kern.threads.virtual_cpu=256 I got this > fault after a kill -9 of a hung test program. Do you have PREEMPTION turned on? This is the same type of bug that people were seeing with PREEMPTION turned on. > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2004 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 5.2-CURRENT #0: Wed Aug 11 04:23:56 CEST 2004 > root@peter.osted.lan:/usr/src/sys/i386/compile/PHO > WARNING: WITNESS option enabled, expect reduced performance. > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Celeron(R) CPU 1.80GHz (1799.14-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf13 Stepping = 3 > > Features=0x3febfbffA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM> real memory > = 267583488 (255 MB) > avail memory = 252190720 (240 MB) > > ata1-master: DMA limited to UDMA33, non-ATA66 cable or device > acd0: CDROM at ata1-master UDMA33 > Mounting root from ufs:/dev/ad0s1a > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x54 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc066ab08 > stack pointer = 0x10:0xd25c1c50 > frame pointer = 0x10:0xd25c1c70 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 539 (pthread_setconcurre) > [thread 101883] > Stopped at setrunqueue+0x1e8: movl %edi,0x54(%edx) > db> where > setrunqueue(c1bac2c0,c1a957d0,c08b1292,484,c065038e) at setrunqueue+0x1e8 > sched_switch(c1bac2c0,0,c08b06b2,123,d3526cf3) at sched_switch+0xa4 > mi_switch(2,0,c08b2b56,f5,10000) at mi_switch+0x29f > ast(d25c1d48) at ast+0x3fb > doreti_ast() at doreti_ast+0x17 > db> call doadump > Dumping 255 MB > panic: blockable sleep lock (sleep mutex) taskqueue @ > kern/subr_taskqueue.c:132 cpuid = 0; > Uptime: 34m36s > panic: cv_wait: not TDS_RUNNING > cpuid = 0; > KDB: enter: panic > [thread 101883] > Stopped at kdb_enter+0x30: leave > db> > > (kgdb) l *0xc066ab08 > 0xc066ab08 is in setrunqueue (../../../kern/kern_switch.c:436). > 431 * put the new kse on whatever is next, > 432 * which may or may not be us. > 433 */ > 434 td2 = TAILQ_NEXT(tda, td_runq); > 435 kg->kg_last_assigned = td2; > 436 td2->td_kse = ke; > 437 ke->ke_thread = td2; > 438 } > 439 sched_add(ke->ke_thread); > 440 } else { > (kgdb) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 19:05:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA95716A4DC for ; Wed, 11 Aug 2004 19:05:32 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 036EF43D2F for ; Wed, 11 Aug 2004 19:05:21 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 32286 invoked from network); 11 Aug 2004 19:05:20 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 11 Aug 2004 19:05:20 -0000 Received: from [10.50.41.91] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i7BJ516W093561; Wed, 11 Aug 2004 15:05:16 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Wed, 11 Aug 2004 15:01:23 -0400 User-Agent: KMail/1.6.2 References: <411A5A12.2070404@root.org> In-Reply-To: <411A5A12.2070404@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408111501.23593.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Daniel Eriksson cc: Nate Lawson Subject: Re: cvs commit: src/sys/dev/acpica acpi_pci_link.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c acpi_pcibvar.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 19:05:34 -0000 On Wednesday 11 August 2004 01:40 pm, Nate Lawson wrote: > Daniel Eriksson wrote: > > Nate Lawson wrote: > >> Modified files: > >> sys/dev/acpica acpi_pci_link.c acpi_pcib.c > >> acpi_pcib_acpi.c acpi_pcib_pci.c > >> acpi_pcibvar.h > >> Log: > >> Re-work ACPI PCI IRQ routing (_PRT, link devices). The old > >>approach was > >> incomplete in that the PRT routing was not aware of link > >>programming. > >> Fix this by doing all routing through the link devices. > > > > This(?) breaks interrupt routing pretty badly on ASUS A7V600-X (VIA > > KT-600 chipset). > > > > A kernel/userland from 2004.08.09.13.00.00 works just fine (sorry, no > > dmesg available right now), but a kernel/userland from > > 2004.08.11.15.00.00 breaks routing of interrupts to (at least) two > > HighPoint RocketRAID 454 cards. > > > > Below is part of the dmesg from a boot with ACPI on. Does it matter that > > "PnP OS installed" is turned off in the BIOS? I will run some more tests > > later tonight and report the results here. This is just a FYI that > > something might be broken... > > That may affect it. Let me know. > > > atapci0: port > > 0xb400-0xb4ff,0xb800-0xb803,0xd000-0xd007,0xd400-0xd403,0xd800-0xd807 irq > > 11 atapci1: port > > 0x9800-0x98ff,0xa000-0xa003,0xa400-0xa407,0xa800-0xa803,0xb000-0xb007 irq > > 11 ahc0: port 0x9400-0x94ff mem > > 0xed800000-0xed800fff irq 3 at device 12.0 on pci0 > > atapci2: port > > 0x7800-0x78ff,0x8000-0x8003,0x8400-0x8407,0x8800-0x8803,0x9000-0x9007 irq > > 10 atapci3: port > > 0x6000-0x60ff,0x6400-0x6403,0x6800-0x6807,0x7000-0x7003,0x7400-0x7407 irq > > 10 at device 14.1 on pci0 > > atapci4: port > > 0x4000-0x40ff,0x4400-0x440f,0x4800-0x4803,0x5000-0x5007,0x5400-0x5403,0x5 > >800 -0x5807 irq 5 at device 15.0 on pci0 > > atapci5: port > > 0x3800-0x380f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 14 at device 15.1 > > on pci0 > > ata0: at 0x1f0 irq 14 on atapci5 > > ata1: at 0x170 irq 15 on atapci5 > > I need the dmesg output from boot -v to see the link priority settings. He's using an I/O APIC. These are probably all entries that don't have a link device but just a hardwired global interrupt number. Did you test that case? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 19:54:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F206216A4CF; Wed, 11 Aug 2004 19:53:59 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id C14AA43D2D; Wed, 11 Aug 2004 19:53:59 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7BJrw8U001122; Wed, 11 Aug 2004 12:53:58 -0700 Message-ID: <411A7928.7050005@root.org> Date: Wed, 11 Aug 2004 12:53:12 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <411A5A12.2070404@root.org> <200408111501.23593.jhb@FreeBSD.org> In-Reply-To: <200408111501.23593.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@FreeBSD.org cc: Daniel Eriksson Subject: Re: cvs commit: src/sys/dev/acpica acpi_pci_link.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c acpi_pcibvar.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 19:54:00 -0000 John Baldwin wrote: > On Wednesday 11 August 2004 01:40 pm, Nate Lawson wrote: > >>Daniel Eriksson wrote: >>>atapci0: port >>>0xb400-0xb4ff,0xb800-0xb803,0xd000-0xd007,0xd400-0xd403,0xd800-0xd807 irq >>>11 atapci1: port >>>0x9800-0x98ff,0xa000-0xa003,0xa400-0xa407,0xa800-0xa803,0xb000-0xb007 irq >>>11 ahc0: port 0x9400-0x94ff mem >>>0xed800000-0xed800fff irq 3 at device 12.0 on pci0 >>>atapci2: port >>>0x7800-0x78ff,0x8000-0x8003,0x8400-0x8407,0x8800-0x8803,0x9000-0x9007 irq >>>10 atapci3: port >>>0x6000-0x60ff,0x6400-0x6403,0x6800-0x6807,0x7000-0x7003,0x7400-0x7407 irq >>>10 at device 14.1 on pci0 >>>atapci4: port >>>0x4000-0x40ff,0x4400-0x440f,0x4800-0x4803,0x5000-0x5007,0x5400-0x5403,0x5 >>>800 -0x5807 irq 5 at device 15.0 on pci0 >>>atapci5: port >>>0x3800-0x380f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 14 at device 15.1 >>>on pci0 >>>ata0: at 0x1f0 irq 14 on atapci5 >>>ata1: at 0x170 irq 15 on atapci5 >> >>I need the dmesg output from boot -v to see the link priority settings. > > He's using an I/O APIC. These are probably all entries that don't have a link > device but just a hardwired global interrupt number. Did you test that case? > I don't have an APIC but acpi_pcib_route_interrupt() still checks Source == NULL and *Source == '\0' and if so, treats SourceIndex as hardwired. Also, acpi_pci_link_config() doesn't add entries to its PRT list if the irq is hardwired. This logic didn't change in the commit. -- Nate From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 20:31:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BCE016A4CE for ; Wed, 11 Aug 2004 20:31:26 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E62F43D1D for ; Wed, 11 Aug 2004 20:31:25 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from dhcp50.pn.xcllnt.net (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i7BKVP3k082173; Wed, 11 Aug 2004 13:31:25 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp50.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp50.pn.xcllnt.net (8.13.1/8.13.1) with ESMTP id i7BKVP8P025536; Wed, 11 Aug 2004 13:31:25 -0700 (PDT) (envelope-from marcel@dhcp50.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp50.pn.xcllnt.net (8.13.1/8.13.1/Submit) id i7BKVPvK025535; Wed, 11 Aug 2004 13:31:25 -0700 (PDT) (envelope-from marcel) Date: Wed, 11 Aug 2004 13:31:25 -0700 From: Marcel Moolenaar To: Michael Nottebrock Message-ID: <20040811203125.GA25498@dhcp50.pn.xcllnt.net> References: <18300.12.148.147.242.1092234409.squirrel@[12.148.147.242]> <200408111857.16230.michaelnottebrock@gmx.net> <20040811171453.GA24847@dhcp50.pn.xcllnt.net> <200408111931.25126.michaelnottebrock@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408111931.25126.michaelnottebrock@gmx.net> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: FreeBSD/ia64, gcc-3.4: editors/koffice-kde3 [was: Re: Signal 11 ...] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 20:31:26 -0000 On Wed, Aug 11, 2004 at 07:31:21PM +0200, Michael Nottebrock wrote: > On Wednesday 11 August 2004 19:14, Marcel Moolenaar wrote: > > > OT: editors/koffice-kde3 fails to build on FreeBSD/ia64, yet the package > > exists for i386. Should I assume that kde3 builds completely on i386 and > > that failures on ia64 are new or unknown and thus that I need to report > > them? > > KOffice has only recently been updated to version 1.3.2. 1.3.1 has known > issues with gcc-3.4. The update fixed those on i386, so it hopefully should > fix ia64, too. Ok, thanks. I'll rebuild from scratch with an up-to-date ports tree. If I run into issues, I'll let the KDE team know. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 21:23:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86CB616A58B; Wed, 11 Aug 2004 21:23:46 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9815F43D1F; Wed, 11 Aug 2004 21:23:45 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i7BLNZfX018166; Wed, 11 Aug 2004 14:23:39 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200408112123.i7BLNZfX018166@gw.catspoiler.org> Date: Wed, 11 Aug 2004 14:23:35 -0700 (PDT) From: Don Lewis To: rwatson@FreeBSD.org In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org cc: mb@imp.ch Subject: Re: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 21:23:46 -0000 On 11 Aug, Robert Watson wrote: > > On Wed, 11 Aug 2004, Martin Blapp wrote: > >> During load tests with both SCHED4BSD and SCHEDULE I found that the >> latest SCHEDULE version cannot have a load over 2-3. I stress tested the >> server really a lot, but about 500 processes did sleep and did not got >> scheduled and only 2 of 500 were run and got about 50% of CPU time. >> >> Is this a known problem ? > > I've found that for throughput oriented workloads, 4BSD substantially > outperforms ULE, but I haven't tried it with Jeff's latest set of patches > (committed a day or two ago). You don't mention if your box is SMP, btw > -- I've noticed some load balancing problems with ULE previously, but > haven't checked if they were resolved. Anecdotal opinion seems generally > to be that interactivity is observably better with ULE than 4BSD, but that > 4BSD appears to do a better job under load. I've noticed in fork()/exec() intensive loads like buildworld and building ports on a UP box that ULE favors a CPU-bound but niced process like setiathome over the software build. Even the longer c++ compile steps seem to get less CPU time, than the niced CPU-bound process, at least according to top. Buildworld times with ULE on my Athlon XP box are about 145 minutes with ULE and 82 minutes with 4BSD when competing with setiathome. Top shows setiathome consistently getting about 55% of the CPU with ULE. Without setiathome running, buildworld takes about 65 minutes. From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 21:31:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0911716A4CF for ; Wed, 11 Aug 2004 21:31:12 +0000 (GMT) Received: from mps4.plala.or.jp (c147240.vh.plala.or.jp [210.150.147.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id 871DD43D3F for ; Wed, 11 Aug 2004 21:31:10 +0000 (GMT) (envelope-from sf@FreeBSD.org) Received: from i169110.ap.plala.or.jp ([218.47.169.110]) by mps4.plala.or.jp with ESMTP id <20040811213109.VZJF8755.mps4.plala.or.jp@i169110.ap.plala.or.jp> for ; Thu, 12 Aug 2004 06:31:09 +0900 Date: Thu, 12 Aug 2004 06:30:56 +0900 Message-ID: <86pt5xe50v.wl%sf@FreeBSD.org> From: FUJISHIMA Satsuki To: current@FreeBSD.org User-Agent: Wanderlust/2.11.30 (Wonderwall) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: top -I does not show most of non-idol process X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 21:31:12 -0000 On -CURRENT of 2004.08.10.22.19.57, /usr/bin/top -I does not show long-living non-idol process such as cc, XFree86, emacs, etc. A binary built from a year old source works fine. I captured tty output from both top binaries run at the same time with ttyrec for you to examine. To play, 1) fetch http://people.freebsd.org/~sf/ttytop.tar.gz 2) tar zxf ttytop.tar.gz 2) portinstall misc/ttyrec 3) ttyplay 20030810.ttyrec (a year old binary), or ttyplay 20040812.ttyrec (latest binary) 4) enjoy. note1: both output has been captured with $ unset TOP; ttyrec -e "top.20030810 -Is1" 20030810.ttyrec or $ unset TOP; ttyrec -e "top -Is1" 20040812.ttyrec on independent terminal. note2: old top built with this way: $ cvs co -D'a year ago' src/contrib/top src/usr.bin/top $ cd src/usr.bin/top; make From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 21:45:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22EF916A4CE for ; Wed, 11 Aug 2004 21:45:48 +0000 (GMT) Received: from tethys.ringofsaturn.com (tethys.ringofsaturn.com [66.13.175.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84ECE43D2D for ; Wed, 11 Aug 2004 21:45:47 +0000 (GMT) (envelope-from rnejdl@ringofsaturn.com) Received: from mail.ringofsaturn.com (localhost [127.0.0.1]) i7BLjkRN041066; Wed, 11 Aug 2004 16:45:46 -0500 (CDT) (envelope-from rnejdl@ringofsaturn.com) Received: from 12.148.147.242 (SquirrelMail authenticated user rnejdl); by mail.ringofsaturn.com with HTTP; Wed, 11 Aug 2004 16:45:46 -0500 (CDT) Message-ID: <41704.12.148.147.242.1092260746.squirrel@[12.148.147.242]> In-Reply-To: <200408111857.16230.michaelnottebrock@gmx.net> References: <18300.12.148.147.242.1092234409.squirrel@[12.148.147.242]> <200408111857.16230.michaelnottebrock@gmx.net> Date: Wed, 11 Aug 2004 16:45:46 -0500 (CDT) From: "Rusty Nejdl" To: "Michael Nottebrock" User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on tethys.ringofsaturn.com X-Virus-Status: Clean cc: freebsd-current@freebsd.org Subject: Re: Signal 11 compiling qt33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rnejdl@ringofsaturn.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2004 21:45:48 -0000 > > uic segfaulting like this is often a result of mixed up threads > libraries... > > You could use a package from http://rabarber.fruitsalad.org, they have > recently been redone for post-gcc-3.4 -CURRENT. > > http://rabarber.fruitsalad.org/packages/3.2.3-final-5/5-CURRENT/All/qt-3. > 3.2_2.tbz > is the direct link. Well, keeping this alive, I installed the qt from the above link and then went back to compiling kde3. kdelibs3 died: /usr/X11R6/bin/moc ./kconfigdialogmanager.h -o kconfigdialogmanager.moc if /bin/sh ../libtool --silent --mode=compile --tag=CXX c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../dcop -I../kio/kssl -I../kdefx -I../dcop -I../libltdl -I../kdefx -I../kdecore -I../kdeui -I../kio -I../kio/kio -I../kio/kfile -I.. -I/usr/X11R6/include -I/usr/local/include -I/usr/local/include -I/usr/local/include/libart-2.0 -DQT_THREAD_SUPPORT -I/usr/local/include -I/usr/local/include -I/usr/X11R6/include -D_GETOPT_H -D_THREAD_SAFE -Wnon-virtual-dtor -Wno-long-long -Wundef -Wall -W -Wpointer-arith -Wwrite-strings -DNDEBUG -DNO_DEBUG -O2 -O -pipe -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -MT kconfigdialogmanager.lo -MD -MP -MF ".deps/kconfigdialogmanager.Tpo" -c -o kconfigdialogmanager.lo kconfigdialogmanager.cpp; \ then mv -f ".deps/kconfigdialogmanager.Tpo" ".deps/kconfigdialogmanager.Plo"; else rm -f ".deps/kconfigdialogmanager.Tpo"; exit 1; fi ../dcop/dcopidl/dcopidl ./ksycoca.h > ksycoca.kidl || ( rm -f ksycoca.kidl ; false ) Segmentation fault (core dumped) gmake[3]: *** [ksycoca.kidl] Error 1 gmake[3]: Leaving directory `/usr/ports/x11/kdelibs3/work/kdelibs-3.2.3/kdecore' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/x11/kdelibs3/work/kdelibs-3.2.3/kdecore' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/x11/kdelibs3/work/kdelibs-3.2.3' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/x11/kdelibs3. *** Error code 1 Stop in /usr/ports/x11/kdebase3. *** Error code 1 Stop in /usr/ports/x11/kdebase3. *** Error code 1 Stop in /usr/ports/x11/kde3. > So, I installed the kdelibs3 from the above link, and started to compile kdebase3: checking for dcopidlng... /usr/local/bin/dcopidlng checking for xmllint... /usr/local/bin/xmllint Segmentation fault (core dumped) configure: error: /usr/local/bin/kde-config --prefix outputed the non existant prefix '' for kdelibs. This means it has been moved since you installed it. This won't work. Please recompile kdelibs for the new prefix. ===> Script "configure" failed unexpectedly. Please report the problem to kde@FreeBSD.org [maintainer] and attach the "/usr/ports/x11/kdebase3/work/kdebase-3.2.3/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/x11/kdebase3. *** Error code 1 Stop in /usr/ports/x11/kde3. And for grins, I ran kde-config: > /usr/local/bin/kde-config Segmentation fault > Last time I saw this was with threading all messed up on 5.2.1. I have no /etc/libmap.conf and a clean system: > uname -a FreeBSD pan.ringofsaturn.com 5.2-CURRENT-20040809-JPSNAP FreeBSD 5.2-CURRENT-20040809-JPSNAP #0: Mon Aug 9 02:33:23 UTC 2004 root@ushi.jp.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 > What is up with threading here??? Rusty Nejdl From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 21:47:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B13816A4CE; Wed, 11 Aug 2004 21:47:10 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 330A743D1F; Wed, 11 Aug 2004 21:47:09 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from dhcp50.pn.xcllnt.net (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i7BLl92C082477; Wed, 11 Aug 2004 14:47:09 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp50.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp50.pn.xcllnt.net (8.13.1/8.13.1) with ESMTP id i7BLl9Hj025761; Wed, 11 Aug 2004 14:47:09 -0700 (PDT) (envelope-from marcel@dhcp50.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp50.pn.xcllnt.net (8.13.1/8.13.1/Submit) id i7BLl9he025760; Wed, 11 Aug 2004 14:47:09 -0700 (PDT) (envelope-from marcel) Date: Wed, 11 Aug 2004 14:47:08 -0700 From: Marcel Moolenaar To: njl@FreeBSD.org Message-ID: <20040811214708.GA25696@dhcp50.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i cc: current@FreeBSD.org Subject: ia64: ACPI PCI IRQ routing breakage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 21:47:10 -0000 Nate, I just tried to boot a kernel with the new ACPI PCI IRQ routing and things look very bad: OK boot -v Entering /boot/kernel/kernel at 0xe000000004058000... PA Pocat0x000003f401 SA: P ak-u vctr:0xf0 G a 0e00000fe000 Prceso rti 92,Bu rti 11,IT rti 92 Skipping memory chunk start 0x4040000000 Skipping memory chunk start 0x407efff000 Skipping memory chunk start 0x407f2e8000 Skipping memory chunk start 0x407f9ff000 Skipping memory chunk start 0x407fdff000 Skipping memory chunk start 0x407fe7f000 ptc.e base=0x0, count1=1, count2=1, stride1=0x0, stride2=0x0 Processor supports 24 Region ID bits Trying VHPT size 0x400000 Putting VHPT at 0x400000 Splitting [0x100000-0x4000000] GDB: debug ports: uart GDB: current port: uart KDB: debugger backends: ddb gdb KDB: current backend: ddb Copyright (c) 1992-2004 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 5.2-CURRENT #11: Wed Aug 11 21:23:19 UTC 2004 marcel@pluto1.freebsd.org:/p/src/sys/ia64/compile/PLUTO1 WARNING: WITNESS option enabled, expect reduced performance. UNWIND: table added: base=e000000004000000, start=e000000004639898, end=e00000000465b828 Preloaded elf kernel "/boot/kernel/kernel" at 0xe0000000047ca000. CPU: McKinley (900.00-Mhz Itanium 2) Origin = "GenuineIntel" Revision = 7 Features = 0x1 real memory = 1067114496 (1017 MB) Physical memory chunk(s): 0x0005c000 - 0x0009ffff, 278528 bytes (34 pages) 0x00100000 - 0x003fffff, 3145728 bytes (384 pages) 0x00800000 - 0x03ffffff, 58720256 bytes (7168 pages) 0x047cc000 - 0x3ead5fff, 976265216 bytes (119173 pages) avail memory = 1030324224 (982 MB) FPSWA Revision = 0x1000c, Entry = 0xe00000407fe62050 Using ACPI2.0 table at 0x3fdf8000 Table 'FACP' at 0xe00000003fdfe3f0 Table 'SPCR' at 0xe00000003fdfe528 Table 'DBGP' at 0xe00000003fdfe578 Table 'APIC' at 0xe00000003fdfe638 Local APIC address=0xfee00000 Local APIC override entry Local APIC address=0xfee00000 Local SAPIC entry ProcessorId=0x0, Id=0x0, Eid=0x0 Local SAPIC entry ProcessorId=0x1, Id=0x1, Eid=0x0 I/O SAPIC entry Id=0x0, InterruptBase=0x10, Address=0xfed20800 I/O SAPIC entry Id=0x1, InterruptBase=0x1b, Address=0xfed22800 I/O SAPIC entry Id=0x2, InterruptBase=0x26, Address=0xfed24800 I/O SAPIC entry Id=0x3, InterruptBase=0x31, Address=0xfed26800 I/O SAPIC entry Id=0x4, InterruptBase=0x3c, Address=0xfed28800 I/O SAPIC entry Id=0x6, InterruptBase=0x47, Address=0xfed2c800 I/O SAPIC entry Id=0x7, InterruptBase=0x52, Address=0xfed2e800 Table 'SPMI' at 0xe00000003fdfe5b0 Table 'CPEP' at 0xe00000003fdfe600 Table 'SSDT' at 0xe00000003fdfc680 Table 'SSDT' at 0xe00000003fdfc740 Table 'SSDT' at 0xe00000003fdfc970 Table 'SSDT' at 0xe00000003fdfcfe0 Table 'SSDT' at 0xe00000003fdfd650 Table 'SSDT' at 0xe00000003fdfdcc0 Table 'SSDT' at 0xe00000003fdfe330 MCA: allocated 32768 bytes for state info. mem: null: random: acpi0: on motherboard acpi0: [GIANT-LOCKED] acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) ACPI timer looks BAD min = 2, max = 7, width = 5 ACPI timer looks BAD min = -6, max = 15, width = 21 ACPI timer looks BAD min = -2, max = 11, width = 13 ACPI timer looks BAD min = -10, max = 19, width = 29 ACPI timer looks BAD min = -26, max = 35, width = 61 ACPI timer looks BAD min = -59, max = 68, width = 127 ACPI timer looks GOOD min = 4, max = 5, width = 1 ACPI timer looks BAD min = -11, max = 20, width = 31 ACPI timer looks GOOD min = 4, max = 5, width = 1 ACPI timer looks BAD min = -42, max = 51, width = 93 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> iomem 0xff5c1004-0xff5c1007 on acpi0 acpi_tz0: on acpi0 cpu0: on acpi0 pcib0: on acpi0 ACPI PCI link initial configuration: pci0: on pcib0 pci0: physical bus=0 map[10]: type 1, range 32, base 80023000, size 12, enabled found-> vendor=0x1033, dev=0x0035, revid=0x41 bus=0, slot=1, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0146, statreg=0x0210, cachelnsz=32 (dwords) lattimer=0x80 (3840 ns), mingnt=0x01 (250 ns), maxlat=0x2a (10500 ns) intpin=a, irq=0 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 80022000, size 12, enabled found-> vendor=0x1033, dev=0x0035, revid=0x41 bus=0, slot=1, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x0210, cachelnsz=32 (dwords) lattimer=0x80 (3840 ns), mingnt=0x01 (250 ns), maxlat=0x2a (10500 ns) intpin=b, irq=0 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 80021000, size 8, enabled found-> vendor=0x1033, dev=0x00e0, revid=0x02 bus=0, slot=1, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x0210, cachelnsz=32 (dwords) lattimer=0x80 (3840 ns), mingnt=0x10 (4000 ns), maxlat=0x22 (8500 ns) intpin=c, irq=0 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 00000d58, size 3, enabled map[14]: type 4, range 32, base 00000d64, size 2, enabled map[18]: type 4, range 32, base 00000d50, size 3, enabled map[1c]: type 4, range 32, base 00000d60, size 2, enabled map[20]: type 4, range 32, base 00000d40, size 4, enabled found-> vendor=0x1095, dev=0x0649, revid=0x02 bus=0, slot=2, func=0 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0145, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x80 (3840 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=14 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 80020000, size 12, enabled map[14]: type 4, range 32, base 00000d00, size 6, enabled map[18]: type 1, range 32, base 80000000, size 17, enabled found-> vendor=0x8086, dev=0x1229, revid=0x0d bus=0, slot=3, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0147, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x80 (3840 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=0 powerspec 2 supports D0 D1 D2 D3 current D0 ohci0: mem 0x80023000-0x80023fff irq 0 at device 1.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x80023000 ohci0: Could not setup irq, 2 device_attach: ohci0 attach returned 6 ohci1: mem 0x80022000-0x80022fff irq 0 at device 1.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x80022000 ohci1: Could not setup irq, 2 device_attach: ohci1 attach returned 6 ehci0: mem 0x80021000-0x800210ff irq 0 at device 1.2 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0x80021000 ehci0: Could not setup irq, 2 device_attach: ehci0 attach returned 6 atapci0: port 0xd40-0xd4f,0xd60-0xd63,0xd50-0xd57,0xd64-0xd67,0xd58-0xd5f irq 14 at device 2.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xd40 atapci0: unable to setup interrupt atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xd58 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xd64 ata2: reset tp1 mask=03 ostat0=00 ostat1=01 ata2-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata2-slave: stat=0x01 err=0x04 lsb=0x14 msb=0xeb ata2: reset tp2 stat0=00 stat1=01 devices=0x4 ata2: at 0xd58 on atapci0 ata2: [MPSAFE] atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xd50 atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0xd60 ata3: reset tp1 mask=00 ostat0=ff ostat1=ff ata3: at 0xd50 on atapci0 ata3: [MPSAFE] fxp0: port 0xd00-0xd3f mem 0x80000000-0x8001ffff,0x80020000-0x80020fff irq 0 at device 3.0 on pci0 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x80020000 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1229 103c 1274 000d fxp0: Dynamic Standby mode is disabled miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:30:6e:39:b6:70 fxp0: could not setup irq panic: fxp_release() called with intr handle still active KDB: enter: panic [thread 0] Stopped at kdb_enter+0x80: [M0] break.m 0x84b5d db> tr kdb_enter(0xe0000000045daa38, 0xe000000004280210, 0x895, 0xe000000004677388) at kdb_enter+0x80 panic(0xe0000000045b33a0, 0x2, 0xe0000000045b3380, 0x343) at panic+0x1c0 fxp_release(0xe000000000900000, 0xe000000000901d20, 0xca1, 0xe0000000048aed60, 0xe000000000900000, 0x0, 0xe0000000009003a0, 0xffffffffffffffff) at fxp_release+0x70 fxp_attach(0xe0000000008fa500, 0xe00000000023bd58, 0xe000000000900074, 0x2, 0x8086, 0x1229, 0x103c, 0xe000000000900000) at fxp_attach+0x17f0 device_attach(0xe0000000008fa500) at device_attach+0x4c0 bus_generic_attach(0xe0000000008fa500, 0xe0000000040de610, 0x38d, 0xe000000004604900) at bus_generic_attach+0x40 acpi_pci_attach(0xe0000000008b0200, 0xe0000000001a5200, 0xe000000004678320, 0xe000000004677478, 0xe0000000042b2840, 0x797, 0xe0000000048aed60) at acpi_pci_attach+0x250 device_attach(0xe0000000008b0200) at device_attach+0x4c0 bus_generic_attach(0xe0000000008b0200, 0xe0000000040e1800, 0x50e, 0xe0000000008b0374) at bus_generic_attach+0x40 acpi_pcib_attach(0xe0000000001a5200, 0xe0000000008f38a0, 0x0, 0xe0000000008a2200, 0xe000000004678320) at acpi_pcib_attach+0x1a0 acpi_pcib_acpi_attach(0xe0000000001a5200, 0xe0000000008f3894, 0xe0000000046774a8, 0xe0000000008f3898, 0xe0000000008f3888, 0xe0000000008f3880, 0xe0000000042b2840, 0x797) at acpi_pcib_acpi_attach+0x370 device_attach(0xe0000000001a5200) at device_attach+0x4c0 bus_generic_attach(0xe0000000001a5200, 0xe0000000040cd880, 0xa9d, 0xe0000000046780a0) at bus_generic_attach+0x40 acpi_attach(0xe0000000008a2200, 0x4, 0xe00000000467c6e0, 0xe0000000046774e8, 0xe0000000046774d8, 0xe0000000008a2148, 0xe0000000045b1a78, 0xe0000000045b9648) at acpi_attach+0xae0 device_attach(0xe0000000008a2200) at device_attach+0x4c0 bus_generic_attach(0xe0000000008a2200) at bus_generic_attach+0x40 nexus_attach(0xe0000000001a2200, 0xe0000000042b2840, 0x797, 0xe0000000042b2810) at nexus_attach+0xd0 device_attach(0xe0000000001a2200) at device_attach+0x4c0 root_bus_configure(0xe0000000001a2200, 0xe0000000045686f0, 0x186) at root_bus_configure+0x50 configure(0xe00000000422a610, 0x48b) at configure+0x60 mi_startup(0xe000000004603dd0, 0xe0000000046d0d38, 0xe0000000046d0d40, 0x1, 0xe0000000046d0d30, 0xe0000000046d0d48, 0xe000000004584400, 0x899) at mi_startup+0x2c0 ia64_init(0xe0000000046d06c8) at ia64_init+0xc80 __start() at __start+0xa0 db> show irq 68 1 0 low-active level ID=0 EID=0 db> If you don't have any suggestions from the top of your head, then please could you back it out so that we can work out what's going on without having ia64 completely bOrked. It not just inconvenient for me. It's a major blocker. In that light I'd hoped to be given more time for testing. Thanks, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 21:49:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 799D316A4CE for ; Wed, 11 Aug 2004 21:49:01 +0000 (GMT) Received: from ran.psg.com (ip192.186.dsl-acs2.seawa0.iinet.com [209.20.186.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AF8743D5F for ; Wed, 11 Aug 2004 21:49:01 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ran.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bv0xw-000HGE-A1 for freebsd-current@freebsd.org; Wed, 11 Aug 2004 14:49:00 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16666.37963.904734.842647@ran.psg.com> Date: Wed, 11 Aug 2004 14:48:59 -0700 To: FreeBSD Current Subject: ipfw X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 21:49:01 -0000 ipfw seems to be starting in some strange state where it has loaded my ruleset but does not really process it. everything ends up in unreachable. if i run `ipfw -q /etc/ipfw.rules`, the same command set that's in /etc/rc.conf, it takes off as expected. randy From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 21:56:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1DAF16A4CF for ; Wed, 11 Aug 2004 21:56:00 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4A2C43D1D for ; Wed, 11 Aug 2004 21:56:00 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7BLsNRU030801; Wed, 11 Aug 2004 17:54:23 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7BLsNO7030798; Wed, 11 Aug 2004 17:54:23 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 11 Aug 2004 17:54:23 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Randy Bush In-Reply-To: <16666.37963.904734.842647@ran.psg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD Current Subject: Re: ipfw X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 21:56:01 -0000 On Wed, 11 Aug 2004, Randy Bush wrote: > ipfw seems to be starting in some strange state where it has loaded my > ruleset but does not really process it. everything ends up in > unreachable. if i run `ipfw -q /etc/ipfw.rules`, the same command set > that's in /etc/rc.conf, it takes off as expected. The recent addition of O_ANTISPOOF renumbered the IPFW rule operations, so if you're using a newer kernel and an older user space, /sbin/ipfw will think the rules mean one thing, but the kernel will think they mean another. The miscreant has been convinced that this is a bad idea (always append!) but since the damage was done we decided not to thrash the operator numbers again. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:03:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7009316A4CE; Wed, 11 Aug 2004 22:03:19 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC66F43D1D; Wed, 11 Aug 2004 22:03:17 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7BM1rEZ096116; Wed, 11 Aug 2004 16:01:53 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 11 Aug 2004 16:02:02 -0600 (MDT) Message-Id: <20040811.160202.83622607.imp@bsdimp.com> To: tinderbox@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20040810123555.0A90A7303F@freebsd-current.sentex.ca> References: <20040810123555.0A90A7303F@freebsd-current.sentex.ca> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: current@FreeBSD.org cc: ia64@FreeBSD.org Subject: Re: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 22:03:19 -0000 In message: <20040810123555.0A90A7303F@freebsd-current.sentex.ca> FreeBSD Tinderbox writes: : TB --- 2004-08-10 11:41:12 - tinderbox 2.3 running on freebsd-current.sentex.ca : TB --- 2004-08-10 11:41:12 - starting CURRENT tinderbox run for ia64/ia64 : TB --- 2004-08-10 11:41:12 - cleaning the sandbox : TB --- 2004-08-10 11:42:13 - checking out the source tree : TB --- 2004-08-10 11:42:13 - cd /home/tinderbox/sandbox/CURRENT/ia64/ia64 : TB --- 2004-08-10 11:42:13 - /usr/bin/cvs -f -R -Q -d/home/ncvs checkout -P -A src : TB --- 2004-08-10 11:49:57 - WARNING: /home/tinderbox/sandbox/ia64.diff does not exist : TB --- 2004-08-10 11:49:57 - building world (CFLAGS=-O -pipe) : TB --- 2004-08-10 11:49:57 - cd /home/tinderbox/sandbox/CURRENT/ia64/ia64/src : TB --- 2004-08-10 11:49:57 - /usr/bin/make -B buildworld : >>> Building an up-to-date make(1) : >>> Rebuilding the temporary build tree : >>> stage 1.1: legacy release compatibility shims : >>> stage 1.2: bootstrap tools : >>> stage 2.1: cleaning up the object tree : >>> stage 2.2: rebuilding the object tree : >>> stage 2.3: build tools : >>> stage 3: cross tools : >>> stage 4.1: building includes : >>> stage 4.2: building libraries : >>> stage 4.3: make dependencies : >>> stage 4.4: building everything : [...] : mkdep -f .depend -a -I. -DNS -DINET6 -DRESCUE /tinderbox/CURRENT/ia64/ia64/src/sbin/route/route.c : echo route: /home/tinderbox/sandbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/i386/usr/lib/libc.a >> .depend : cc -O -pipe -I. -Wall -DNS -DINET6 -DRESCUE -c /tinderbox/CURRENT/ia64/ia64/src/sbin/route/route.c : (cd /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue/../../sbin/routed && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE if.o input.o main.o output.o parms.o radix.o rdisc.o table.o trace.o) : rm -f .depend : mkdep -f .depend -a -DRESCUE /tinderbox/CURRENT/ia64/ia64/src/sbin/routed/if.c /tinderbox/CURRENT/ia64/ia64/src/sbin/routed/input.c /tinderbox/CURRENT/ia64/ia64/src/sbin/routed/main.c /tinderbox/CURRENT/ia64/ia64/src/sbin/routed/output.c /tinderbox/CURRENT/ia64/ia64/src/sbin/routed/parms.c /tinderbox/CURRENT/ia64/ia64/src/sbin/routed/radix.c /tinderbox/CURRENT/ia64/ia64/src/sbin/routed/rdisc.c /tinderbox/CURRENT/ia64/ia64/src/sbin/routed/table.c /tinderbox/CURRENT/ia64/ia64/src/sbin/routed/trace.c : echo routed: /home/tinderbox/sandbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/i386/usr/lib/libc.a /home/tinderbox/sandbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/i386/usr/lib/libmd.a >> .depend : +for: not found this appreas to be caused by changes to Makefile and Makefile.inc1: harti 2004-08-09 11:38:41 UTC FreeBSD src repository Modified files: . Makefile Makefile.inc1 Log: Make make recurse into sub-directories and sub-makes when given two -n flags. If only one -n flag is given the old behaviour is retained (POLA). In order to make this working for installworld change the IMAKEENV in this case so that the tools are found (we have no temporary installation environment in this case). Submitted by: ru (IMAKEENV part) Revision Changes Path 1.306 +7 -7 src/Makefile 1.434 +27 -22 src/Makefile.inc1 It would appear that the ${_+_} stuff isn't ready for prime time, and works on my local system when I back that part of this change out. Warner From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:06:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49BF216A4CE; Wed, 11 Aug 2004 22:06:48 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D91143D49; Wed, 11 Aug 2004 22:06:46 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7BM4AAm096144; Wed, 11 Aug 2004 16:04:10 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 11 Aug 2004 16:04:20 -0600 (MDT) Message-Id: <20040811.160420.34008155.imp@bsdimp.com> To: kris@obsecurity.org From: "M. Warner Losh" In-Reply-To: <20040810231044.GA70020@xor.obsecurity.org> References: <20040810231044.GA70020@xor.obsecurity.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: harti@freebsd.org cc: current@freebsd.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 22:06:48 -0000 In message: <20040810231044.GA70020@xor.obsecurity.org> Kris Kennaway writes: : More fallout from the wonderful new make(1) semantics? I think it is speficially related to the changes to src/Makefile and src/Makefile.inc1. If I s/${_+_}//g on those two files, it appears that I can buildworld again (at least it doesn't die right away). Warner From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:08:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AA7816A4CE; Wed, 11 Aug 2004 22:08:36 +0000 (GMT) Received: from mediamonks.com (siripandita.mediamonks.net [62.192.127.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 563C243D39; Wed, 11 Aug 2004 22:08:34 +0000 (GMT) (envelope-from root@mediamonks.net) Received: from manrikigusari [217.19.28.156] by mediamonks.com with ESMTP (SMTPD32-8.12) id A8D2EE30082; Thu, 12 Aug 2004 00:08:18 +0200 From: "Terrence Koeman" To: "'Doug White'" Date: Thu, 12 Aug 2004 00:09:57 +0200 Organization: MediaMonks B.V. MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0015_01C48000.B27F0280" In-Reply-To: <20040811101859.P99067@carver.gumbysoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcR/yUsykvNGsiAZSr2clrdomaMG9QAJYoUg Message-Id: <20040812000885.SM01804@manrikigusari> X-Info: This e-mail was scanned for spam and viruses by mail.mediamonks.net. X-Info: Please send abuse reports about this e-mail to abuse@mediamonks.net. cc: freebsd-current@FreeBSD.org cc: 'John Baldwin' Subject: RE: Lock order reversal in 5.2-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: root@mediamonks.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2004 22:08:36 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C48000.B27F0280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-freebsd-current@freebsd.org > [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Doug White > Sent: Wednesday, August 11, 2004 19:22 > To: Terrence Koeman > Cc: freebsd-current@FreeBSD.org; 'John Baldwin' > Subject: RE: Lock order reversal in 5.2-CURRENT > > On Wed, 11 Aug 2004, Terrence Koeman wrote: > > > I think something else is wrong, as I get different lock > order reversals and > > some other errors that all lockup the box. Earlier I had a > corrupted cc > > binary after a buildworld. > > > > Everything points to a hardware failure somewhere, but I > already switched > > the hardware before this happened, I swapped RAID arrays in > identical > > machines, and the machine where -CURRENT runs on now was a > production server > > that ran 4.9/4.10-STABLE for months under heavy load > without any problems > > whatsoever. > > > > The following is what I got today: > > > > Second bad > > /: bad dir ino 16110954 at offset 24: mangled entry > > panic: ufs_dirbad: bad dir > > Your RAID is doing a really good job of corrupting your data. :) What > RAID controller and volume layout are you using? It's a Promise FastTrak TX2000 with two mirrored 160Gb Maxtor drives. > > Fatal trap 18: integer divide fault while in kernel mode > > This looks more serious .. you may have a bad CPU, memory, or > some other > critical component. I thought so too, because multiple weird errors usually point to the hardware. But I have three identical systems with the only difference being the contents of the disks. The other two systems are running 4.10-STABLE with heavy load without any problems. I swapped the disks (only the disks) with a working system twice now and it locks up just the same. I think the chance of three systems having the same hardware problem is really small, especially because 4.10-STABLE hasn't had a single problem on those systems in the couple of months they run. Maybe 5.2-CURRENT has a specific problem with the hardware in the systems? But it's not like it is exotic hardware, they are SuperMicro 1U barebones with a Celeron 2600, 512MB of RAM and a FastTrak TX2000. -- Regards, Terrence Koeman MediaMonks B.V. (www.mediamonks.com) Please quote all replies in correspondence. ------=_NextPart_000_0015_01C48000.B27F0280 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKUzCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNmMIICz6ADAgECAhANi0/uqtIYW/R1ap0p4X/7MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4G0MIGxMBEGCWCGSAGG+EIBAQQEAwIB BjA1BgNVHR8ELjAsMCqgKKAmhiRodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLjEuMS5jcmww RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB AgUAA4GBAEJ8Dt+MeUysvwjsTVUvUImgxV5OLl6VMpt5rWURCxxKUsTVqDEhjt4Qm2wIxQfmA7nn yDR4CQnyvAZC+FqMg9GK3qoi9dnjIdLPZYwGM7DNILIzzQq9PuGdwTWpZLCnpSRb6fFo6xPEfDf0 lGQNmsW9MxfvgzOgPuWqPq7Ycx+tMIIEpDCCBA2gAwIBAgIQZx6EJ4oHSmQocGtEpogzPzANBgkq hkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEg SW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wNDAyMDQw MDAwMDBaFw0wNTAyMDMyMzU5NTlaMIIBFjEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0 IEZ1bGwgU2VydmljZTEYMBYGA1UEAxQPVGVycmVuY2UgS29lbWFuMSIwIAYJKoZIhvcNAQkBFhNy b290QG1lZGlhbW9ua3MubmV0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKUqZ0P8RUaCCe aemq1V8OtPimM3jxXZY6yuWtQz74POz82LhrkctttQoqujz5SubFWsQ15KsVnK4Nt+gTmtUELQVa I4uUebypbChhf1fxFerA7Rx8SYL4Ez9Fvco0tn89FRht6C/xoc/Ms/1YkQQcfnu2sqohx53S5Pm0 Ffo/ZQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcB ATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcC AjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVm ZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDAGCmCG SAGG+EUBBgcEIhYgMWE5NjkyOTM3Y2MyOTFhMzZkZjAxN2Q4NDBjNDRiMTYwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOB gQAmpan0cUGODHHRIbkVFBHbTOumbMmEO3TR6d9z3LVO9cU5YDC/8BI9e5DZ7Kv43p/ldaGVo2ua ZwtvwL6o/iDcP8UDw+WmjSwzp6tck5cVRDEi+q9nCe3JAYBeRgSJlP5JGOirFpLuDTwL4UPdE0em p9ELBC+sXACm2C3u19hlKTGCBD4wggQ6AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3Qg VmFsaWRhdGVkAhBnHoQnigdKZChwa0SmiDM/MAkGBSsOAwIaBQCgggKyMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDgxMTIyMDk1NVowIwYJKoZIhvcNAQkEMRYE FH5XtiyeknNI0yk+Hc+UE30rhSvyMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIa MAoGCCqGSIb3DQIFMIHyBgkrBgEEAYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNp Z24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5v dCBWYWxpZGF0ZWQCEGcehCeKB0pkKHBrRKaIMz8wgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBnHoQnigdKZChwa0SmiDM/MA0GCSqGSIb3 DQEBAQUABIGAEYxBcbX47Th9xVdbSCQ88ZxnpbTWC0k+PvtNNkFvmmKZ0RvS5A9ZT/SDYDKtUGek PGS6WDZ1+kjhIryakMir8hYHA2aPLrg8D+nNGjbRGaeDOONHZTlhA9BD+DHNJQGz/Yk35SrCv7g6 4875Zm8HtSWSVAx310WCLyK7axTaLIcAAAAAAAA= ------=_NextPart_000_0015_01C48000.B27F0280-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:13:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEC6E16A4CF; Wed, 11 Aug 2004 22:13:57 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 058B443D2F; Wed, 11 Aug 2004 22:13:57 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7BMDklu054114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2004 01:13:47 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7BMDmio094161; Thu, 12 Aug 2004 01:13:48 +0300 (EEST) (envelope-from ru) Date: Thu, 12 Aug 2004 01:13:48 +0300 From: Ruslan Ermilov To: "M. Warner Losh" Message-ID: <20040811221348.GB93983@ip.net.ua> References: <20040810231044.GA70020@xor.obsecurity.org> <20040811.160420.34008155.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KFztAG8eRSV9hGtP" Content-Disposition: inline In-Reply-To: <20040811.160420.34008155.imp@bsdimp.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: harti@FreeBSD.org cc: current@FreeBSD.org cc: kris@obsecurity.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 22:13:57 -0000 --KFztAG8eRSV9hGtP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 11, 2004 at 04:04:20PM -0600, M. Warner Losh wrote: > In message: <20040810231044.GA70020@xor.obsecurity.org> > Kris Kennaway writes: > : More fallout from the wonderful new make(1) semantics?=20 >=20 > I think it is speficially related to the changes to src/Makefile and > src/Makefile.inc1. If I s/${_+_}//g on those two files, it appears > that I can buildworld again (at least it doesn't die right away). >=20 How exactly does it die for you, please provide some logs. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --KFztAG8eRSV9hGtP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGpocqRfpzJluFF4RAsxnAJ9MwIAqgSbf81mVLWjfEikWA7HeeACfZKdz fe6YnlKCTuVbDiLn5va74Vc= =5jmA -----END PGP SIGNATURE----- --KFztAG8eRSV9hGtP-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:18:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C09B716A4CE; Wed, 11 Aug 2004 22:18:16 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21AF443D39; Wed, 11 Aug 2004 22:18:15 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7BMH2mZ096395; Wed, 11 Aug 2004 16:17:02 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 11 Aug 2004 16:17:12 -0600 (MDT) Message-Id: <20040811.161712.129785493.imp@bsdimp.com> To: ru@freebsd.org From: "M. Warner Losh" In-Reply-To: <20040811221348.GB93983@ip.net.ua> References: <20040810231044.GA70020@xor.obsecurity.org> <20040811.160420.34008155.imp@bsdimp.com> <20040811221348.GB93983@ip.net.ua> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: harti@freebsd.org cc: current@freebsd.org cc: kris@obsecurity.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 22:18:16 -0000 I just sent a copy of one of the interbox builds. Mine failed because it couldn't find +@cd when trying to build an up-to-date make(1). Warner From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:18:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D51F616A4DF; Wed, 11 Aug 2004 22:18:23 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4550E43D3F; Wed, 11 Aug 2004 22:18:23 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7BMGRRL096393; Wed, 11 Aug 2004 16:16:28 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 11 Aug 2004 16:16:37 -0600 (MDT) Message-Id: <20040811.161637.56140504.imp@bsdimp.com> To: ru@freebsd.org From: "M. Warner Losh" In-Reply-To: <20040811221348.GB93983@ip.net.ua> References: <20040810231044.GA70020@xor.obsecurity.org> <20040811.160420.34008155.imp@bsdimp.com> <20040811221348.GB93983@ip.net.ua> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: harti@freebsd.org cc: current@freebsd.org cc: kris@obsecurity.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 22:18:24 -0000 In message: <20040811221348.GB93983@ip.net.ua> Ruslan Ermilov writes: : On Wed, Aug 11, 2004 at 04:04:20PM -0600, M. Warner Losh wrote: : > In message: <20040810231044.GA70020@xor.obsecurity.org> : > Kris Kennaway writes: : > : More fallout from the wonderful new make(1) semantics? : > : > I think it is speficially related to the changes to src/Makefile and : > src/Makefile.inc1. If I s/${_+_}//g on those two files, it appears : > that I can buildworld again (at least it doesn't die right away). : > : How exactly does it die for you, please provide some logs. TB --- 2004-08-10 13:23:38 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-10 13:23:38 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-08-10 13:23:38 - cleaning the sandbox TB --- 2004-08-10 13:24:26 - checking out the source tree TB --- 2004-08-10 13:24:26 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64 TB --- 2004-08-10 13:24:26 - /usr/bin/cvs -f -R -Q -d/home/ncvs checkout -P -A src TB --- 2004-08-10 13:31:44 - WARNING: /home/tinderbox/sandbox/sparc64.diff does not exist TB --- 2004-08-10 13:31:44 - building world (CFLAGS=-O -pipe) TB --- 2004-08-10 13:31:44 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src TB --- 2004-08-10 13:31:44 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] mkdep -f .depend -a -I. -DNS -DINET6 -DRESCUE /tinderbox/CURRENT/sparc64/sparc64/src/sbin/route/route.c echo route: /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libc.a >> .depend cc -O -pipe -I. -Wall -DNS -DINET6 -DRESCUE -c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/route/route.c (cd /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue/../../sbin/routed && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE if.o input.o main.o output.o parms.o radix.o rdisc.o table.o trace.o) rm -f .depend mkdep -f .depend -a -DRESCUE /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/if.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/input.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/main.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/output.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/parms.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/radix.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/rdisc.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/table.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/trace.c echo routed: /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libc.a /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libmd.a >> .depend +for: not found *** Error code 127 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-08-10 14:08:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-10 14:08:16 - ERROR: failed to build world TB --- 2004-08-10 14:08:16 - tinderbox aborted _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:22:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 935AD16A4CE; Wed, 11 Aug 2004 22:22:33 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D39C143D4C; Wed, 11 Aug 2004 22:22:32 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7BMMQwO054695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2004 01:22:27 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7BMMSj9011467; Thu, 12 Aug 2004 01:22:28 +0300 (EEST) (envelope-from ru) Date: Thu, 12 Aug 2004 01:22:28 +0300 From: Ruslan Ermilov To: "M. Warner Losh" Message-ID: <20040811222228.GB96867@ip.net.ua> References: <20040810231044.GA70020@xor.obsecurity.org> <20040811.160420.34008155.imp@bsdimp.com> <20040811221348.GB93983@ip.net.ua> <20040811.161712.129785493.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aM3YZ0Iwxop3KEKx" Content-Disposition: inline In-Reply-To: <20040811.161712.129785493.imp@bsdimp.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: harti@FreeBSD.org cc: current@FreeBSD.org cc: kris@obsecurity.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 22:22:33 -0000 --aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 11, 2004 at 04:17:12PM -0600, M. Warner Losh wrote: > I just sent a copy of one of the interbox builds. Mine failed because > it couldn't find +@cd when trying to build an up-to-date make(1). >=20 Please check that you at least have Makefile.inc1,v 1.435. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --aM3YZ0Iwxop3KEKx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGpwkqRfpzJluFF4RAvt5AJ4tpueSAn6hG4V8Q2tet0vamMFYyACfeiIF ApPahR2RfDghsMEhgNBqo7k= =BR8v -----END PGP SIGNATURE----- --aM3YZ0Iwxop3KEKx-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:23:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A55D16A4CE for ; Wed, 11 Aug 2004 22:23:12 +0000 (GMT) Received: from meitner.wh.uni-dortmund.de (meitner.wh.Uni-Dortmund.DE [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id A741443D3F for ; Wed, 11 Aug 2004 22:23:11 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id AB1431677A6; Thu, 12 Aug 2004 00:23:10 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i7BMN846010632 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 12 Aug 2004 00:23:09 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: rnejdl@ringofsaturn.com Date: Thu, 12 Aug 2004 00:22:59 +0200 User-Agent: KMail/1.6.2 References: <18300.12.148.147.242.1092234409.squirrel@[12.148.147.242]> <200408111857.16230.michaelnottebrock@gmx.net> <41704.12.148.147.242.1092260746.squirrel@[12.148.147.242]> In-Reply-To: <41704.12.148.147.242.1092260746.squirrel@[12.148.147.242]> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_LxpGBvJ4VPa4GN6"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408120023.07624.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new cc: freebsd-current@freebsd.org Subject: Re: Signal 11 compiling qt33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 22:23:12 -0000 --Boundary-02=_LxpGBvJ4VPa4GN6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 11 August 2004 23:45, Rusty Nejdl wrote: > What is up with threading here??? > > Rusty Nejdl I don't have the slightest idea what's biting you there, sorry :-\. Perhaps= =20 something is indeed wrong with the snapshot... Btw, my mails to you seem to be bouncing: : host tethys.ringofsaturn.com[66.13.175.242] said: 550 5.7.1 ... Access denied =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --Boundary-02=_LxpGBvJ4VPa4GN6 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBGpxLXhc68WspdLARAr+pAJ0fQ5C/wkmF5AtjsHC2NRERPKa+ywCggCFz F7fs4njvAMkfBVHwzreYhAo= =+Bzw -----END PGP SIGNATURE----- --Boundary-02=_LxpGBvJ4VPa4GN6-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:23:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E234716A4CE; Wed, 11 Aug 2004 22:23:43 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B7D343D2F; Wed, 11 Aug 2004 22:23:43 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7BMNZrR054759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2004 01:23:36 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7BMNb8Q011823; Thu, 12 Aug 2004 01:23:37 +0300 (EEST) (envelope-from ru) Date: Thu, 12 Aug 2004 01:23:37 +0300 From: Ruslan Ermilov To: "M. Warner Losh" Message-ID: <20040811222337.GC96867@ip.net.ua> References: <20040810231044.GA70020@xor.obsecurity.org> <20040811.160420.34008155.imp@bsdimp.com> <20040811221348.GB93983@ip.net.ua> <20040811.161637.56140504.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Sr1nOIr3CvdE5hEN" Content-Disposition: inline In-Reply-To: <20040811.161637.56140504.imp@bsdimp.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: harti@FreeBSD.org cc: current@FreeBSD.org cc: kris@obsecurity.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 22:23:44 -0000 --Sr1nOIr3CvdE5hEN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 11, 2004 at 04:16:37PM -0600, M. Warner Losh wrote: > In message: <20040811221348.GB93983@ip.net.ua> > Ruslan Ermilov writes: > : On Wed, Aug 11, 2004 at 04:04:20PM -0600, M. Warner Losh wrote: > : > In message: <20040810231044.GA70020@xor.obsecurity.org> > : > Kris Kennaway writes: > : > : More fallout from the wonderful new make(1) semantics?=20 > : >=20 > : > I think it is speficially related to the changes to src/Makefile and > : > src/Makefile.inc1. If I s/${_+_}//g on those two files, it appears > : > that I can buildworld again (at least it doesn't die right away). > : >=20 > : How exactly does it die for you, please provide some logs. >=20 > TB --- 2004-08-10 13:23:38 - tinderbox 2.3 running on freebsd-current.sen= tex.ca > TB --- 2004-08-10 13:23:38 - starting CURRENT tinderbox run for sparc64/s= parc64 > TB --- 2004-08-10 13:23:38 - cleaning the sandbox > TB --- 2004-08-10 13:24:26 - checking out the source tree > TB --- 2004-08-10 13:24:26 - cd /home/tinderbox/sandbox/CURRENT/sparc64/s= parc64 > TB --- 2004-08-10 13:24:26 - /usr/bin/cvs -f -R -Q -d/home/ncvs checkout = -P -A src > TB --- 2004-08-10 13:31:44 - WARNING: /home/tinderbox/sandbox/sparc64.dif= f does not exist > TB --- 2004-08-10 13:31:44 - building world (CFLAGS=3D-O -pipe) > TB --- 2004-08-10 13:31:44 - cd /home/tinderbox/sandbox/CURRENT/sparc64/s= parc64/src > TB --- 2004-08-10 13:31:44 - /usr/bin/make -B buildworld > >>> Building an up-to-date make(1) > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > [...] > mkdep -f .depend -a -I. -DNS -DINET6 -DRESCUE /tinderbox/CURRENT/sparc= 64/sparc64/src/sbin/route/route.c > echo route: /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/obj/sparc64/t= inderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libc.a >> .depend > cc -O -pipe -I. -Wall -DNS -DINET6 -DRESCUE -c /tinderbox/CURRENT/sparc= 64/sparc64/src/sbin/route/route.c > (cd /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue/../../sbin/route= d && make -DRESCUE CRUNCH_CFLAGS=3D-DRESCUE depend && make -DRESCUE CRUNC= H_CFLAGS=3D-DRESCUE if.o input.o main.o output.o parms.o radix.o rdisc.o t= able.o trace.o) > rm -f .depend > mkdep -f .depend -a -DRESCUE /tinderbox/CURRENT/sparc64/sparc64/src/sb= in/routed/if.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/input.c /= tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/main.c /tinderbox/CURRENT= /sparc64/sparc64/src/sbin/routed/output.c /tinderbox/CURRENT/sparc64/sparc6= 4/src/sbin/routed/parms.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/route= d/radix.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed/rdisc.c /tinde= rbox/CURRENT/sparc64/sparc64/src/sbin/routed/table.c /tinderbox/CURRENT/spa= rc64/sparc64/src/sbin/routed/trace.c > echo routed: /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/obj/sparc64/= tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libc.a /home/tinderbox/s= andbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc6= 4/src/i386/usr/lib/libmd.a >> .depend > +for: not found > *** Error code 127 >=20 > Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sbin/routed. > *** Error code 1 >=20 > Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/= sparc64/sparc64/src/rescue/rescue. > *** Error code 1 >=20 > Stop in /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue. > *** Error code 1 >=20 You're looking at a day old report. The issue (the bug in crunchgen(1)) has been dealt with already. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --Sr1nOIr3CvdE5hEN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGpxpqRfpzJluFF4RAsshAJ0b7f5zCYFL8eXBWnv3346nMPJ5mACfX9T1 0LnhfYMqEqycVPl5ptIZd/Q= =xN+J -----END PGP SIGNATURE----- --Sr1nOIr3CvdE5hEN-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:27:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F44D16A4CE; Wed, 11 Aug 2004 22:27:05 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0118343D45; Wed, 11 Aug 2004 22:27:05 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7BMQUMM096565; Wed, 11 Aug 2004 16:26:31 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 11 Aug 2004 16:26:40 -0600 (MDT) Message-Id: <20040811.162640.00482545.imp@bsdimp.com> To: ru@freebsd.org From: "M. Warner Losh" In-Reply-To: <20040811221348.GB93983@ip.net.ua> References: <20040810231044.GA70020@xor.obsecurity.org> <20040811.160420.34008155.imp@bsdimp.com> <20040811221348.GB93983@ip.net.ua> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: harti@freebsd.org cc: current@freebsd.org cc: kris@obsecurity.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 22:27:05 -0000 In message: <20040811221348.GB93983@ip.net.ua> Ruslan Ermilov writes: : On Wed, Aug 11, 2004 at 04:04:20PM -0600, M. Warner Losh wrote: : > In message: <20040810231044.GA70020@xor.obsecurity.org> : > Kris Kennaway writes: : > : More fallout from the wonderful new make(1) semantics? : > : > I think it is speficially related to the changes to src/Makefile and : > src/Makefile.inc1. If I s/${_+_}//g on those two files, it appears : > that I can buildworld again (at least it doesn't die right away). : > : How exactly does it die for you, please provide some logs. The problem is due to the following in share/mk/sys.mk: .if !empty(.MAKEFLAGS:M-n) && ${.MAKEFLAGS:M-n} == "-n" _+_ ?= .else _+_ ?= + .endif This should have a third clause: .if ${MAKE_VERSION} >= 5200408030 && !empty(.MAKEFLAGS:M-n) && ${.MAKEFLAGS:M-n} == "-n" so that _+_ is defined to be nothing for those versions of make that don't yet support this new feature of posix. Warner From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:33:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABB1A16A4CF; Wed, 11 Aug 2004 22:33:01 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E34E43D31; Wed, 11 Aug 2004 22:33:01 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7BMWhTs096643; Wed, 11 Aug 2004 16:32:44 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 11 Aug 2004 16:32:53 -0600 (MDT) Message-Id: <20040811.163253.83978294.imp@bsdimp.com> To: ru@freebsd.org From: "M. Warner Losh" In-Reply-To: <20040811222228.GB96867@ip.net.ua> References: <20040811221348.GB93983@ip.net.ua> <20040811.161712.129785493.imp@bsdimp.com> <20040811222228.GB96867@ip.net.ua> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: harti@freebsd.org cc: current@freebsd.org cc: kris@obsecurity.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 22:33:01 -0000 In message: <20040811222228.GB96867@ip.net.ua> Ruslan Ermilov writes: : On Wed, Aug 11, 2004 at 04:17:12PM -0600, M. Warner Losh wrote: : > I just sent a copy of one of the interbox builds. Mine failed because : > it couldn't find +@cd when trying to build an up-to-date make(1). : > : Please check that you at least have Makefile.inc1,v 1.435. # $FreeBSD: src/Makefile.inc1,v 1.435 2004/08/10 13:18:05 harti Exp $ is what I'm using. Warner From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:35:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C500916A4CE for ; Wed, 11 Aug 2004 22:35:04 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71BCB43D1F for ; Wed, 11 Aug 2004 22:35:04 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7BMZ08U004726; Wed, 11 Aug 2004 15:35:03 -0700 Message-ID: <411A9F14.4000204@root.org> Date: Wed, 11 Aug 2004 15:35:00 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Moolenaar References: <20040811214708.GA25696@dhcp50.pn.xcllnt.net> In-Reply-To: <20040811214708.GA25696@dhcp50.pn.xcllnt.net> Content-Type: multipart/mixed; boundary="------------060108080209020609010400" cc: current@FreeBSD.org Subject: Re: ia64: ACPI PCI IRQ routing breakage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 22:35:04 -0000 This is a multi-part message in MIME format. --------------060108080209020609010400 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Marcel Moolenaar wrote: > Nate, > > I just tried to boot a kernel with the new ACPI PCI IRQ routing and > things look very bad: > > Table 'SSDT' at 0xe00000003fdfc680 > Table 'SSDT' at 0xe00000003fdfc740 > Table 'SSDT' at 0xe00000003fdfc970 > Table 'SSDT' at 0xe00000003fdfcfe0 > Table 'SSDT' at 0xe00000003fdfd650 > Table 'SSDT' at 0xe00000003fdfdcc0 > Table 'SSDT' at 0xe00000003fdfe330 It's very hard to debug things when all your important devices are hidden in SSDTs. I'd appreciate it if someone took me up on adding SSDT support to acpidump. > acpi0: on motherboard > acpi0: [GIANT-LOCKED] > acpi0: Power Button (fixed) > acpi0: Sleep Button (fixed) > > pcib0: on acpi0 > ACPI PCI link initial configuration: > pci0: on pcib0 > pci0: physical bus=0 > map[10]: type 1, range 32, base 80023000, size 12, enabled > found-> vendor=0x1033, dev=0x0035, revid=0x41 > bus=0, slot=1, func=0 > class=0c-03-10, hdrtype=0x00, mfdev=1 > cmdreg=0x0146, statreg=0x0210, cachelnsz=32 (dwords) > lattimer=0x80 (3840 ns), mingnt=0x01 (250 ns), maxlat=0x2a (10500 ns) > intpin=a, irq=0 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type 1, range 32, base 80022000, size 12, enabled [...] > > If you don't have any suggestions from the top of your head, then > please could you back it out so that we can work out what's going > on without having ia64 completely bOrked. It not just inconvenient > for me. It's a major blocker. In that light I'd hoped to be given > more time for testing. It's likely your link devices don't like being called with _DIS. Try the attached patch. -Nate --------------060108080209020609010400 Content-Type: text/plain; name="dbg.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dbg.diff" Index: acpi_pci_link.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_pci_link.c,v retrieving revision 1.20 diff -u -r1.20 acpi_pci_link.c --- acpi_pci_link.c 11 Aug 2004 20:37:24 -0000 1.20 +++ acpi_pci_link.c 11 Aug 2004 22:33:09 -0000 @@ -377,12 +377,13 @@ * run _DIS (i.e., the method doesn't exist), assume the initial * IRQ was routed by the BIOS. */ +#if 0 if (ACPI_SUCCESS(AcpiEvaluateObject(handle, "_DIS", NULL, NULL))) { link->current_irq = 0; link->flags = ACPI_LINK_NONE; } else { +#endif link->flags = ACPI_LINK_ROUTED; - } error = AcpiGetPossibleResources(handle, &buf); if (ACPI_FAILURE(error)) { --------------060108080209020609010400-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:35:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6097516A56C; Wed, 11 Aug 2004 22:35:18 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E39C43D31; Wed, 11 Aug 2004 22:35:17 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7BMZACK055429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2004 01:35:11 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7BMZ7ax027048; Thu, 12 Aug 2004 01:35:07 +0300 (EEST) (envelope-from ru) Date: Thu, 12 Aug 2004 01:35:07 +0300 From: Ruslan Ermilov To: John-Mark Gurney , "Daniel C. Sobral" Message-ID: <20040811223507.GD96867@ip.net.ua> References: <200408061506.i76F66sl018247@repoman.freebsd.org> <20040809124153.GN628@darkness.comp.waw.pl> <20040809173814.GG991@funkthat.com> <20040810103007.GB30151@darkness.comp.waw.pl> <20040810144135.GN991@funkthat.com> <20040810154715.GC19937@ip.net.ua> <20040810173617.GQ991@funkthat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yudcn1FV7Hsu/q59" Content-Disposition: inline In-Reply-To: <20040810173617.GQ991@funkthat.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: current@FreeBSD.org Subject: Re: cvs commit: src/sys/boot/common help.common src/sys/boot/forth loader.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 22:35:18 -0000 --yudcn1FV7Hsu/q59 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 10, 2004 at 10:36:17AM -0700, John-Mark Gurney wrote: > Ruslan Ermilov wrote this message on Tue, Aug 10, 2004 at 18:47 +0300: > > > Have you tried booting another kernel? I can't see how your machine > > > could of booted /boot/kernel.old ever with kernel modules, if your > > > machine is currently having troubles with loading kernel modules. > > > (Since kernel.old would not have been added to module path, since it > > > isn't being now, and the correct modules would never load.) > > >=20 > > Do you get the correct module_path with beastie_disable=3D"YES" set in > > /boot/loader.conf? (Sorry, but I cannot try it right now.) >=20 > Yep, I do: > # sysctl kern.module_path > kern.module_path: /boot/kernel;/boot/modules > # kldload pf > # kldunload pf > # grep beastie /boot/loader.conf > beastie_disable=3D"YES" > # uname -a > FreeBSD carbon.funkthat.com 5.2-CURRENT FreeBSD 5.2-CURRENT #1: Sun Aug = 8 22:07:02 PDT 2004 jmg@carbon.funkthat.com:/a/obj/a/src/sys/GENERIC i= 386 >=20 OK, now we have a real problem here. I have updated my system today, and when I let it boot automatically, it didn't result in module_path set to point to the kernel directory, as many others here have reported. I did some experimenting though. If I enter the loader(8) prompt and type unload boot /boot/kernel/kernel then it'd set module_path correctly. Finally, I've been able to find the root of this problem: this is rather an old and sad story about /boot/loader.rc -- the latter does not get updated automatically by an installworld. I had my /boot/loader.rc matching revision 1.1 of sys/boot/i386/loader/loader.rc. Now (because I knew this magic) after I've manually updated it to: $ ident /boot/loader.rc /boot/loader.rc: $FreeBSD: src/sys/boot/i386/loader/loader.rc,v 1.2 2003/11/21 19:01:02= dcs Exp $ it all works as you intended. I think a lot of people will be bite by this (since installworld doesn't update this file if it exists). I suggest that at least a HEADS UP is sent and the UPDATING entry is made, describing symptoms and a solution. You can reproduce it yourself by downgrading your /boot/loader.rc to rev. 1.1, and trying to reboot. I have beastie_enable=3D"NO" set in my /boot/loader.conf, FWIW. I didn't try without it. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --yudcn1FV7Hsu/q59 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGp8bqRfpzJluFF4RAkRWAJ9lIfC5TaaKeaQmP6umsLZCAehUXgCfWaov cZt1stBdQ6EG6V+j8BRJEZY= =7EEH -----END PGP SIGNATURE----- --yudcn1FV7Hsu/q59-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:43:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B1B316A4CE; Wed, 11 Aug 2004 22:43:27 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CE6143D46; Wed, 11 Aug 2004 22:43:26 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7BMhFps055784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2004 01:43:16 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7BMhHw4041096; Thu, 12 Aug 2004 01:43:17 +0300 (EEST) (envelope-from ru) Date: Thu, 12 Aug 2004 01:43:17 +0300 From: Ruslan Ermilov To: "M. Warner Losh" Message-ID: <20040811224317.GE96867@ip.net.ua> References: <20040810231044.GA70020@xor.obsecurity.org> <20040811.160420.34008155.imp@bsdimp.com> <20040811221348.GB93983@ip.net.ua> <20040811.162640.00482545.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h56sxpGKRmy85csR" Content-Disposition: inline In-Reply-To: <20040811.162640.00482545.imp@bsdimp.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: harti@freebsd.org cc: current@freebsd.org cc: kris@obsecurity.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 22:43:27 -0000 --h56sxpGKRmy85csR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 11, 2004 at 04:26:40PM -0600, M. Warner Losh wrote: > In message: <20040811221348.GB93983@ip.net.ua> > Ruslan Ermilov writes: > : On Wed, Aug 11, 2004 at 04:04:20PM -0600, M. Warner Losh wrote: > : > In message: <20040810231044.GA70020@xor.obsecurity.org> > : > Kris Kennaway writes: > : > : More fallout from the wonderful new make(1) semantics?=20 > : >=20 > : > I think it is speficially related to the changes to src/Makefile and > : > src/Makefile.inc1. If I s/${_+_}//g on those two files, it appears > : > that I can buildworld again (at least it doesn't die right away). > : >=20 > : How exactly does it die for you, please provide some logs. >=20 > The problem is due to the following in share/mk/sys.mk: >=20 > .if !empty(.MAKEFLAGS:M-n) && ${.MAKEFLAGS:M-n} =3D=3D "-n" > _+_ ?=3D > .else > _+_ ?=3D + > .endif >=20 > This should have a third clause: >=20 > .if ${MAKE_VERSION} >=3D 5200408030 && !empty(.MAKEFLAGS:M-n) && ${.MAKEF= LAGS:M-n} =3D=3D "-n" >=20 > so that _+_ is defined to be nothing for those versions of make that > don't yet support this new feature of posix. >=20 Why? It's not supposed that you try an old make(1) binary with the new share/mk/sys.mk. src/Makefile will upgrade make(1) if necessary, then use it (or the old make if it's adequate) with new share/mk stuff to call Makefile.inc1. If you throw away the -m from your "make" command in your build script, it will work. We want to be able to use the new make(1) features in our share/mk files right after when they made available. That was one of the main ideas of the make(1) regression testing feature in src/Makefile. It's like we now handle backward issues in our C sources -- we agreed not to pollute sources with __FreeBSD_version checks, and we keep the necessary bootstrapping glue in a separate place. The same applies here -- one is free to use new make(1) features in src/ makefiles and in share/mk support files. src/Makefile and tools/regression/usr.bin/make guarantee that we'll always use the make(1) binary compatible with the feature set used in our .mk and makefiles. Please update your build scripts... Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --h56sxpGKRmy85csR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBGqEFqRfpzJluFF4RAvkuAJ0R3k4hB0Xu1w1L4M5T7+VMoU7HwwCgiFxu j8Uqv9BNfOSeUkXFensNnb0= =caSi -----END PGP SIGNATURE----- --h56sxpGKRmy85csR-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:44:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A130816A4CE; Wed, 11 Aug 2004 22:44:52 +0000 (GMT) Received: from av4-1-sn3.vrr.skanova.net (av4-1-sn3.vrr.skanova.net [81.228.9.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB85343D39; Wed, 11 Aug 2004 22:44:51 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av4-1-sn3.vrr.skanova.net (Postfix, from userid 502) id D08EF382DB; Thu, 12 Aug 2004 00:44:50 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av4-1-sn3.vrr.skanova.net (Postfix) with ESMTP id BCED9382DB; Thu, 12 Aug 2004 00:44:50 +0200 (CEST) Received: from gadget (h130n1fls11o822.telia.com [213.64.66.130]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 7811238009; Thu, 12 Aug 2004 00:44:50 +0200 (CEST) From: "Daniel Eriksson" To: "'Lukas Ertl'" , Date: Thu, 12 Aug 2004 00:44:48 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0055_01C48005.92478910" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20040802193340.R905@korben.in.tern> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcR/9M6HUBDYBuBuQX+NAM0TYa1IXA== Subject: gvinum and RAID-5, page-fault on lost disc? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 22:44:52 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0055_01C48005.92478910 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit As I reported on the "Vinum status" thread a few days ago, gvinum is not very graceful when a disc disappears/dies in a RAID-5 array during operation. The machine I was testing this on was an SMP machine, but when I recompiled the kernel with ddb/kdb support I removed "option SMP" just to take that out of the equation. The system: ----------- ASUS P2B-DS mobo, 2 x P3/700, 1GB ECC RAM, latest BIOS (1014, beta 003) Some old 9GB ATA disc for the OS on the onboard 440BX UDMA33 chipset 4 x 120GB Maxtor SATA discs on a HighPoint RocketRAID 1540 (HPT374 chipset) The 4 120GB discs were put together in a RAID-5 array using "classic" vinum (so they have overlapping slices and VINUM slicetypes). Kernel/userland dated: 2004.08.10.21.00.00 (no CFLAGS/COPTFLAGS, but I use "CPUTYPE?=p3") gvinum started from /boot/loader.conf (geom_vinum_load="YES") The crash: ---------- Stop all non-essential processes (to protect against unnecessary file corruption, normally I've got Apache+PHP4+MySQL running among other things). Set up one process to write to the RAID-5 array (I have used a simple sftp to another machine, pulling down big files). Pull one of the SATA-cables. *boom* I have a vmcore dump and a kernel.debug, but I can't seem to get gdb53 to do what I want (not very familiar with gdb), so here's the output I took down on paper from within ddb. The first 5 lines are exactly what I would expect to happen (and what "classic" vinum also did), but then something goes wrong and the machine page-faults: ad8: TIMEOUT - READ_DMA retrying (2 retries left) LBA = 196849498 ad8: WARNING - removed from configuration gvinum: lost drive 'vinumdrive2' FOO: sd raid5.p0.s2 is down FOO: plex raid5.p0 is degraded Fatal trap 12: page fault while in kernel mode fault virtual address = 0x64 fault code = supervisor read, page not present instruction pointer = 0x8:0xc08580fe stack pointer = 0x10:0xdcf9dc00 frame pointer = 0x10:0xdcf9dc20 code segment = base 0x0, limit 0xfffff, type 0x1b DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2 (g_event) [thread 100038] Stopped at gv_drive_access+0x1e : movl 0x64(%eax),%ecx db> where gv_drive_access(c2608b00,ffffffff,ffffffff,0,0) at gv_drive_access+0x1e g_access(c260a8c0,ffffffff,ffffffff,0,c260a900) at g_access+0x16b gv_plex_orphan(c260a8c0, .......) g_orphan_register one_event g_run_events g_event_procbody fork_exit fork_trampoline --- trap 0x1, eip = 0, esp = 0xdcf9dd7c, ebp = 0 --- Attached is the kernel config file and the dmesg. Let me know if there is anything you want me to do with gdb to further track this down. I could probably even arrange for a guest account on this machine if someone wants to take a closer look at the vmcore file. /Daniel Eriksson ------=_NextPart_000_0055_01C48005.92478910 Content-Type: application/octet-stream; name="dmesg.boot" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.boot" Copyright (c) 1992-2004 The FreeBSD Project.=0A= Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994=0A= The Regents of the University of California. All rights reserved.=0A= FreeBSD 5.2-CURRENT #0: Wed Aug 11 02:41:58 CEST 2004=0A= daniel@sentinel.lokalen.zapto.org:/usr/obj/usr/src/sys/SENTINEL=0A= Timecounter "i8254" frequency 1193182 Hz quality 0=0A= CPU: Intel Pentium III (701.59-MHz 686-class CPU)=0A= Origin =3D "GenuineIntel" Id =3D 0x681 Stepping =3D 1=0A= = Features=3D0x383fbff=0A= real memory =3D 1073729536 (1023 MB)=0A= avail memory =3D 1041289216 (993 MB)=0A= ACPI APIC Table: =0A= ioapic0 irqs 0-23 on motherboard=0A= npx0: [FAST]=0A= npx0: on motherboard=0A= npx0: INT 16 interface=0A= acpi0: on motherboard=0A= acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20=0A= acpi0: [GIANT-LOCKED]=0A= acpi0: Power Button (fixed)=0A= Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000=0A= acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0=0A= cpu0: on acpi0=0A= acpi_button0: on acpi0=0A= pcib0: port 0xcf8-0xcff on acpi0=0A= pci0: on pcib0=0A= agp0: mem = 0xe4000000-0xe7ffffff at device 0.0 on pci0=0A= pcib1: at device 1.0 on pci0=0A= pci1: on pcib1=0A= pci1: at device 0.0 (no driver attached)=0A= isab0: at device 4.0 on pci0=0A= isa0: on isab0=0A= atapci0: port = 0xb800-0xb80f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 4.1 on pci0=0A= ata0: at 0x1f0 irq 14 on atapci0=0A= ata1: at 0x170 irq 15 on atapci0=0A= uhci0: port 0xb400-0xb41f irq = 19 at device 4.2 on pci0=0A= uhci0: [GIANT-LOCKED]=0A= usb0: on uhci0=0A= usb0: USB revision 1.0=0A= uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1=0A= uhub0: 2 ports with 2 removable, self powered=0A= pci0: at device 4.3 (no driver attached)=0A= ahc0: port 0xb000-0xb0ff mem = 0xe1000000-0xe1000fff irq 19 at device 6.0 on pci0=0A= ahc0: [GIANT-LOCKED]=0A= aic7890/91: Ultra2 Wide Channel A, SCSI Id=3D15, 32/253 SCBs=0A= atapci1: port = 0x9400-0x94ff,0x9800-0x9803,0xa000-0xa007,0xa400-0xa403,0xa800-0xa807 = irq 19 at device 9.0 on pci0=0A= ata2: at 0xa800 on atapci1=0A= ata3: at 0xa000 on atapci1=0A= atapci2: port = 0x7800-0x78ff,0x8000-0x8003,0x8400-0x8407,0x8800-0x8803,0x9000-0x9007 = irq 19 at device 9.1 on pci0=0A= ata4: at 0x9000 on atapci2=0A= ata5: at 0x8400 on atapci2=0A= xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x7400-0x747f mem = 0xe0800000-0xe080007f irq 18 at device 10.0 on pci0=0A= miibus0: on xl0=0A= xlphy0: <3c905C 10/100 internal PHY> on miibus0=0A= xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto=0A= xl0: Ethernet address: 00:01:02:73:f4:f5=0A= xl0: [GIANT-LOCKED]=0A= xl1: <3Com 3c905C-TX Fast Etherlink XL> port 0x7000-0x707f mem = 0xe0000000-0xe000007f irq 17 at device 11.0 on pci0=0A= miibus1: on xl1=0A= xlphy1: <3c905C 10/100 internal PHY> on miibus1=0A= xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto=0A= xl1: Ethernet address: 00:50:da:8d:d2:af=0A= xl1: [GIANT-LOCKED]=0A= fxp0: port 0x6800-0x683f mem = 0xdf000000-0xdf0fffff,0xdf800000-0xdf800fff irq 16 at device 12.0 on pci0=0A= miibus2: on fxp0=0A= inphy0: on miibus2=0A= inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto=0A= fxp0: Ethernet address: 00:03:47:09:6f:51=0A= fxp0: [GIANT-LOCKED]=0A= fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on = acpi0=0A= fdc0: FIFO enabled, 8 bytes threshold=0A= fd0: <1440-KB 3.5" drive> on fdc0 drive 0=0A= sio0 port 0x3f8-0x3ff irq 4 on acpi0=0A= sio0: type 16550A=0A= atkbdc0: port 0x64,0x60 irq 1 on acpi0=0A= atkbd0: irq 1 on atkbdc0=0A= kbd0 at atkbd0=0A= atkbd0: [GIANT-LOCKED]=0A= psm0: irq 12 on atkbdc0=0A= psm0: [GIANT-LOCKED]=0A= psm0: model Generic PS/2 mouse, device ID 0=0A= orm0: at iomem = 0xd4000-0xd57ff,0xd0000-0xd07ff,0xcc000-0xcc7ff,0xc0000-0xc7fff on isa0=0A= pmtimer0 on isa0=0A= sc0: at flags 0x100 on isa0=0A= sc0: VGA <16 virtual consoles, flags=3D0x300>=0A= sio1: configured irq 3 not in bitmap of probed irqs 0=0A= sio1: port may not be enabled=0A= vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0=0A= Timecounter "TSC" frequency 701593764 Hz quality 800=0A= Timecounters tick every 1.000 msec=0A= ipfw2 initialized, divert enabled, rule-based forwarding enabled, = default to accept, logging unlimited=0A= ad0: 8693MB [17662/16/63] at ata0-master = UDMA33=0A= ATAPI_RESET time =3D 50us=0A= acd0: CDROM at ata1-master PIO4=0A= ad4: 117246MB [238216/16/63] at ata2-master = SATA150=0A= ad6: 117246MB [238216/16/63] at ata3-master = SATA150=0A= ad8: 117246MB [238216/16/63] at ata4-master = SATA150=0A= ad10: 117246MB [238216/16/63] at ata5-master = SATA150=0A= Waiting 2 seconds for SCSI devices to settle=0A= FOO: sd raid5.p0.s0 is up=0A= FOO: sd raid5.p0.s1 is up=0A= FOO: sd raid5.p0.s2 is up=0A= FOO: sd raid5.p0.s3 is up=0A= Mounting root from ufs:/dev/ad0s1a=0A= WARNING: / was not properly dismounted=0A= ------=_NextPart_000_0055_01C48005.92478910 Content-Type: application/octet-stream; name="SENTINEL" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="SENTINEL" =0A= machine i386=0A= cpu I686_CPU=0A= ident SENTINEL=0A= =0A= # Options for the firewall and NAT functionality=0A= options IPFIREWALL=0A= options IPDIVERT=0A= options IPFIREWALL_DEFAULT_TO_ACCEPT=0A= options IPFIREWALL_VERBOSE=0A= =0A= =0A= # To statically compile in device wiring instead of /boot/device.hints=0A= #hints "GENERIC.hints" # Default places to look for devices.=0A= =0A= makeoptions DEBUG=3D-g # Build kernel with gdb(1) debug symbols=0A= =0A= #options SCHED_ULE # ULE scheduler=0A= options SCHED_4BSD # 4BSD scheduler=0A= options INET # InterNETworking=0A= #options INET6 # IPv6 communications protocols=0A= options FFS # Berkeley Fast Filesystem=0A= options SOFTUPDATES # Enable FFS soft updates support=0A= options UFS_ACL # Support for access control lists=0A= options UFS_DIRHASH # Improve performance on big directories=0A= options MD_ROOT # MD is a potential root device=0A= options NFSCLIENT # Network Filesystem Client=0A= options NFSSERVER # Network Filesystem Server=0A= options NFS_ROOT # NFS usable as /, requires NFSCLIENT=0A= options MSDOSFS # MSDOS Filesystem=0A= options CD9660 # ISO 9660 Filesystem=0A= options PROCFS # Process filesystem (requires PSEUDOFS)=0A= options PSEUDOFS # Pseudo-filesystem framework=0A= options GEOM_GPT # GUID Partition Tables.=0A= options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!]=0A= options COMPAT_FREEBSD4 # Compatible with FreeBSD4=0A= options SCSI_DELAY=3D2000 # Delay (in ms) before probing SCSI=0A= #options KTRACE # ktrace(1) support=0A= options SYSVSHM # SYSV-style shared memory=0A= options SYSVMSG # SYSV-style message queues=0A= options SYSVSEM # SYSV-style semaphores=0A= options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time = extensions=0A= options KBD_INSTALL_CDEV # install a CDEV entry in /dev=0A= #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug = output. Adds ~128k to driver.=0A= #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug = output. Adds ~215k to driver.=0A= #options PFIL_HOOKS # pfil(9) framework=0A= =0A= =0A= # dakrer=0A= #options DEVICE_POLLING=0A= options DUMMYNET=0A= options HZ=3D1000=0A= options ZERO_COPY_SOCKETS # Turn on zero copy send code=0A= =0A= # The aic7xxx driver will attempt to use memory mapped I/O for all PCI=0A= # controllers that have it configured only if this option is set. = Unfortunately,=0A= # this doesn't work on some motherboards, which prevents it from being = the=0A= # default.=0A= #options AHC_ALLOW_MEMIO=0A= =0A= =0A= # encrypted filesystem=0A= options GEOM_BDE=0A= =0A= # Disk quotas are supported when this option is enabled.=0A= #options QUOTA #enable disk quotas=0A= =0A= =0A= # netgraph(4). Enable the base netgraph code with the NETGRAPH option.=0A= # Individual node types can be enabled with the corresponding option=0A= # listed below; however, this is not strictly necessary as netgraph=0A= # will automatically load the corresponding KLD module if the node type=0A= # is not already compiled into the kernel. Each type below has a=0A= # corresponding man page, e.g., ng_async(8).=0A= options NETGRAPH #netgraph(4) system=0A= #options NETGRAPH_ASYNC=0A= #options NETGRAPH_ATMLLC=0A= #options NETGRAPH_ATM_ATMPIF=0A= #options NETGRAPH_BLUETOOTH # ng_bluetooth(4)=0A= #options NETGRAPH_BLUETOOTH_BT3C # ng_bt3c(4)=0A= #options NETGRAPH_BLUETOOTH_H4 # ng_h4(4)=0A= #options NETGRAPH_BLUETOOTH_HCI # ng_hci(4)=0A= #options NETGRAPH_BLUETOOTH_L2CAP # ng_l2cap(4)=0A= #options NETGRAPH_BLUETOOTH_SOCKET # ng_btsocket(4)=0A= #options NETGRAPH_BLUETOOTH_UBT # ng_ubt(4)=0A= #options NETGRAPH_BLUETOOTH_UBTBCMFW # ubtbcmfw(4)=0A= #options NETGRAPH_BPF=0A= #options NETGRAPH_BRIDGE=0A= #options NETGRAPH_CISCO=0A= #options NETGRAPH_ECHO=0A= #options NETGRAPH_ETHER=0A= #options NETGRAPH_FRAME_RELAY=0A= #options NETGRAPH_GIF=0A= #options NETGRAPH_GIF_DEMUX=0A= #options NETGRAPH_HOLE=0A= #options NETGRAPH_IFACE=0A= #options NETGRAPH_IP_INPUT=0A= #options NETGRAPH_KSOCKET=0A= #options NETGRAPH_L2TP=0A= #options NETGRAPH_LMI=0A= ## MPPC compression requires proprietary files (not included)=0A= ##options NETGRAPH_MPPC_COMPRESSION=0A= #options NETGRAPH_MPPC_ENCRYPTION=0A= #options NETGRAPH_ONE2MANY=0A= #options NETGRAPH_PPP=0A= #options NETGRAPH_PPPOE=0A= #options NETGRAPH_PPTPGRE=0A= #options NETGRAPH_RFC1490=0A= #options NETGRAPH_SOCKET=0A= #options NETGRAPH_SPLIT=0A= #options NETGRAPH_SPPP=0A= #options NETGRAPH_TEE=0A= #options NETGRAPH_TTY=0A= #options NETGRAPH_UI=0A= #options NETGRAPH_VJC=0A= =0A= =0A= # Debugging for use in -current=0A= options KDB # Enable the kernel debugger=0A= options DDB # Enable the kernel debugger=0A= #options INVARIANTS # Enable calls of extra sanity checking=0A= #options INVARIANT_SUPPORT # Extra sanity checks of internal = structures, required by INVARIANTS=0A= #options WITNESS # Enable checks to detect deadlocks and cycles=0A= #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed=0A= =0A= # To make an SMP kernel, the next two are needed=0A= #options SMP # Symmetric MultiProcessor Kernel=0A= device apic # I/O APIC=0A= =0A= # Bus support. Do not remove isa, even if you have no isa slots=0A= device isa=0A= #device eisa=0A= device pci=0A= =0A= # Floppy drives=0A= device fdc=0A= =0A= # ATA and ATAPI devices=0A= device ata=0A= device atadisk # ATA disk drives=0A= device ataraid # ATA RAID drives=0A= device atapicd # ATAPI CDROM drives=0A= device atapifd # ATAPI floppy drives=0A= device atapist # ATAPI tape drives=0A= options ATA_STATIC_ID # Static device numbering=0A= =0A= # SCSI Controllers=0A= #device ahb # EISA AHA1742 family=0A= device ahc # AHA2940 and onboard AIC7xxx devices=0A= device ahd # AHA39320/29320 and onboard AIC79xx devices=0A= #device amd # AMD 53C974 (Tekram DC-390(T))=0A= #device isp # Qlogic family=0A= #device mpt # LSI-Logic MPT-Fusion=0A= ##device ncr # NCR/Symbios Logic=0A= #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr')=0A= #device trm # Tekram DC395U/UW/F DC315U adapters=0A= =0A= #device adv # Advansys SCSI adapters=0A= #device adw # Advansys wide SCSI adapters=0A= #device aha # Adaptec 154x SCSI adapters=0A= #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60.=0A= #device bt # Buslogic/Mylex MultiMaster SCSI adapters=0A= =0A= #device ncv # NCR 53C500=0A= #device nsp # Workbit Ninja SCSI-3=0A= #device stg # TMC 18C30/18C50=0A= =0A= # SCSI peripherals=0A= device scbus # SCSI bus (required for SCSI)=0A= device ch # SCSI media changers=0A= device da # Direct Access (disks)=0A= device sa # Sequential Access (tape etc)=0A= device cd # CD=0A= device pass # Passthrough device (direct SCSI access)=0A= device ses # SCSI Environmental Services (and SAF-TE)=0A= =0A= # RAID controllers interfaced to the SCSI subsystem=0A= #device amr # AMI MegaRAID=0A= #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID=0A= #device ciss # Compaq Smart RAID 5*=0A= #device dpt # DPT Smartcache III, IV - See NOTES for options=0A= #device iir # Intel Integrated RAID=0A= #device ips # IBM (Adaptec) ServeRAID=0A= #device mly # Mylex AcceleRAID/eXtremeRAID=0A= #device twa # 3ware 9000 series PATA/SATA RAID=0A= =0A= # RAID controllers=0A= #device aac # Adaptec FSA RAID=0A= #device aacp # SCSI passthrough for aac (requires CAM)=0A= #device ida # Compaq Smart RAID=0A= #device mlx # Mylex DAC960 family=0A= #device pst # Promise Supertrak SX6000=0A= #device twe # 3ware ATA RAID=0A= =0A= # atkbdc0 controls both the keyboard and the PS/2 mouse=0A= device atkbdc # AT keyboard controller=0A= device atkbd # AT keyboard=0A= device psm # PS/2 mouse=0A= =0A= device vga # VGA video card driver=0A= =0A= device splash # Splash screen and screen saver support=0A= =0A= # syscons is the default console driver, resembling an SCO console=0A= device sc=0A= =0A= # Enable this for the pcvt (VT220 compatible) console driver=0A= #device vt=0A= #options XSERVER # support for X server on a vt console=0A= #options FAT_CURSOR # start with block cursor=0A= =0A= device agp # support several AGP chipsets=0A= =0A= # Floating point support - do not disable.=0A= device npx=0A= =0A= # Power management support (see NOTES for more options)=0A= #device apm=0A= # Add suspend/resume support for the i8254.=0A= device pmtimer=0A= =0A= # PCCARD (PCMCIA) support=0A= # PCMCIA and cardbus bridge support=0A= #device cbb # cardbus (yenta) bridge=0A= ##device pcic # ExCA ISA and PCI bridges=0A= #device pccard # PC Card (16-bit) bus=0A= #device cardbus # CardBus (32-bit) bus=0A= =0A= # Serial (COM) ports=0A= device sio # 8250, 16[45]50 based serial ports=0A= =0A= # Parallel port=0A= #device ppc=0A= #device ppbus # Parallel port bus (required)=0A= #device lpt # Printer=0A= #device plip # TCP/IP over parallel=0A= #device ppi # Parallel port interface device=0A= ##device vpo # Requires scbus and da=0A= =0A= # If you've got a "dumb" serial or parallel PCI card that is=0A= # supported by the puc(4) glue driver, uncomment the following=0A= # line to enable it (connects to the sio and/or ppc drivers):=0A= #device puc=0A= =0A= # PCI Ethernet NICs.=0A= #device de # DEC/Intel DC21x4x (``Tulip'')=0A= device em # Intel PRO/1000 adapter Gigabit Ethernet Card=0A= #device ixgb # Intel PRO/10GbE Ethernet Card=0A= #device txp # 3Com 3cR990 (``Typhoon'')=0A= #device vx # 3Com 3c590, 3c595 (``Vortex'')=0A= =0A= # PCI Ethernet NICs that use the common MII bus controller code.=0A= # NOTE: Be sure to keep the 'device miibus' line in order to use these = NICs!=0A= device miibus # MII bus support=0A= #device bfe # Broadcom BCM440x 10/100 Ethernet=0A= #device bge # Broadcom BCM570xx Gigabit Ethernet=0A= #device dc # DEC/Intel 21143 and various workalikes=0A= device fxp # Intel EtherExpress PRO/100B (82557, 82558)=0A= #device pcn # AMD Am79C97x PCI 10/100 (precedence over 'lnc')=0A= device re # RealTek 8139C+/8169/8169S/8110S=0A= device rl # RealTek 8129/8139=0A= #device sf # Adaptec AIC-6915 (``Starfire'')=0A= #device sis # Silicon Integrated Systems SiS 900/SiS 7016=0A= #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet=0A= #device ste # Sundance ST201 (D-Link DFE-550TX)=0A= #device ti # Alteon Networks Tigon I/II gigabit Ethernet=0A= #device tl # Texas Instruments ThunderLAN=0A= #device tx # SMC EtherPower II (83c170 ``EPIC'')=0A= device vr # VIA Rhine, Rhine II=0A= #device wb # Winbond W89C840F=0A= device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'')=0A= =0A= # ISA Ethernet NICs. pccard NICs included.=0A= #device cs # Crystal Semiconductor CS89x0 NIC=0A= # 'device ed' requires 'device miibus'=0A= #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards=0A= #device ex # Intel EtherExpress Pro/10 and Pro/10+=0A= device ep # Etherlink III based cards=0A= #device fe # Fujitsu MB8696x based cards=0A= #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc.=0A= #device lnc # NE2100, NE32-VL Lance Ethernet cards=0A= #device sn # SMC's 9000 series of Ethernet chips=0A= #device xe # Xircom pccard Ethernet=0A= =0A= # ISA devices that use the old ISA shims=0A= #device le=0A= =0A= # Wireless NIC cards=0A= #device wlan # 802.11 support=0A= #device an # Aironet 4500/4800 802.11 wireless NICs.=0A= #device awi # BayStack 660 and others=0A= #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs.=0A= ##device wl # Older non 802.11 Wavelan wireless NIC.=0A= =0A= # Pseudo devices - the number indicates how many units to allocate.=0A= device loop # Network loopback=0A= device mem # Memory and kernel memory devices=0A= device io # I/O device=0A= #device null # Null and zero devices=0A= device random # Entropy device=0A= device ether # Ethernet support=0A= device sl # Kernel SLIP=0A= device ppp # Kernel PPP=0A= device tun # Packet tunnel.=0A= device pty # Pseudo-ttys (telnet etc)=0A= device md # Memory "disks"=0A= device gif # IPv6 and IPv4 tunneling=0A= device faith # IPv6-to-IPv4 relaying (translation)=0A= =0A= # The `bpf' device enables the Berkeley Packet Filter.=0A= # Be aware of the administrative consequences of enabling this!=0A= device bpf # Berkeley packet filter=0A= =0A= # USB support=0A= device uhci # UHCI PCI->USB interface=0A= device ohci # OHCI PCI->USB interface=0A= device usb # USB Bus (required)=0A= #device udbp # USB Double Bulk Pipe devices=0A= device ugen # Generic=0A= device uhid # "Human Interface Devices"=0A= device ukbd # Keyboard=0A= device ulpt # Printer=0A= device umass # Disks/Mass storage - Requires scbus and da=0A= device ums # Mouse=0A= device urio # Diamond Rio 500 MP3 player=0A= device uscanner # Scanners=0A= # USB Ethernet, requires mii=0A= device aue # ADMtek USB Ethernet=0A= device axe # ASIX Electronics USB Ethernet=0A= device cue # CATC USB Ethernet=0A= device kue # Kawasaki LSI USB Ethernet=0A= device rue # RealTek RTL8150 USB Ethernet=0A= =0A= # FireWire support=0A= #device firewire # FireWire bus code=0A= #device sbp # SCSI over FireWire (Requires scbus and da)=0A= #device fwe # Ethernet over FireWire (non-standard!)=0A= =0A= ------=_NextPart_000_0055_01C48005.92478910-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:45:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7B0716A4CE for ; Wed, 11 Aug 2004 22:45:06 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 821EB43D1D for ; Wed, 11 Aug 2004 22:45:06 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-67-115-74-195.dsl.lsan03.pacbell.net [67.115.74.195]) i7BMj3XO024769 for ; Wed, 11 Aug 2004 18:45:03 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C8E315138A; Wed, 11 Aug 2004 15:45:04 -0700 (PDT) Date: Wed, 11 Aug 2004 15:45:04 -0700 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20040811224504.GA46960@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: gcc 3.4.2/x.org packages uploaded X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 22:45:07 -0000 --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I've uploaded a full package set built with gcc 3.4.2 and x.org, so (after a suitable delay to allow the packages to propagate onto the ftp mirrors) you might like to portupgrade -faPP or similar if you're having difficulties recompiling the ports for the new compiler. Kris --RnlQjJ0d97Da+TV1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBGqFwWry0BWjoQKURAn4rAKC3hU/PnSdbrrxkdFmu5o73GEqngACeL1X8 5U0AGkQgp9ldVxxgmOPlRek= =B/9o -----END PGP SIGNATURE----- --RnlQjJ0d97Da+TV1-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:47:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9587D16A4CE for ; Wed, 11 Aug 2004 22:47:32 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F43143D31 for ; Wed, 11 Aug 2004 22:47:31 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 6A8E17A3D2 for ; Wed, 11 Aug 2004 15:47:31 -0700 (PDT) Message-ID: <411AA203.1020502@elischer.org> Date: Wed, 11 Aug 2004 15:47:31 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: current@freebsd.org Content-Type: multipart/mixed; boundary="------------040706030807060502090005" Subject: [Fwd: RFC.. defining __rangeof() in cdefs.h] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 22:47:32 -0000 This is a multi-part message in MIME format. --------------040706030807060502090005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Interresting.. not a single comment.. :-/ --------------040706030807060502090005 Content-Type: message/rfc822; name="RFC.. defining __rangeof() in cdefs.h" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="RFC.. defining __rangeof() in cdefs.h" Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by idiom.com (8.12.9p2/8.12.9) with ESMTP id i79LeqOZ063959 for ; Mon, 9 Aug 2004 14:40:53 -0700 (PDT) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 372F356A1D for ; Mon, 9 Aug 2004 21:40:45 +0000 (GMT) (envelope-from owner-freebsd-current@freebsd.org) Received: by hub.freebsd.org (Postfix) id 7CF5C16A4E7; Mon, 9 Aug 2004 21:40:43 +0000 (GMT) Delivered-To: julian@freebsd.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 6457C16A4E4; Mon, 9 Aug 2004 21:40:43 +0000 (GMT) Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE71916A4CE for ; Mon, 9 Aug 2004 21:40:38 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75ED643D5A for ; Mon, 9 Aug 2004 21:40:38 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 12E377A3D2 for ; Mon, 9 Aug 2004 14:40:38 -0700 (PDT) Message-ID: <4117EF55.4090409@elischer.org> Date: Mon, 09 Aug 2004 14:40:37 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: RFC.. defining __rangeof() in cdefs.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org X-Accessio-Status: NO, score=0.00,none version=6.0 count=0 X-Accessio-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on idiom.com X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Idiom-Reporting: If this was spam, please forward it to spambox@idiom.com I'm considdereing adding: Index: sys/cdefs.h =================================================================== RCS file: /home/ncvs/src/sys/sys/cdefs.h,v retrieving revision 1.83 diff -u -r1.83 cdefs.h --- sys/cdefs.h 28 Jul 2004 07:03:42 -0000 1.83 +++ sys/cdefs.h 9 Aug 2004 21:36:41 -0000 @@ -241,6 +241,8 @@ * require it. */ #define __offsetof(type, field) ((size_t)(&((type *)0)->field)) +#define __rangeof(type, start, end) \ + (__offsetof(type, end) - __offsetof(type, start)) /* * Compiler-dependent macros to declare that functions take printf-like it is used in several places. most importantly in fork1() and it is defined in several files (*).. we should probably just have one copy... (*) in the form RANGEOF() but if we define it in cdefs.h I'd change that to __rangeof() to match __offsetof() _______________________________________________ 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" --------------040706030807060502090005-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:51:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAA8616A4CE for ; Wed, 11 Aug 2004 22:51:57 +0000 (GMT) Received: from imap.univie.ac.at (mail.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3928443D55 for ; Wed, 11 Aug 2004 22:51:57 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from [192.168.0.4] (adslle.cc.univie.ac.at [131.130.102.11]) by imap.univie.ac.at (8.12.10/8.12.10) with ESMTP id i7BMpkRm118732; Thu, 12 Aug 2004 00:51:48 +0200 Date: Thu, 12 Aug 2004 00:51:46 +0200 (CEST) From: Lukas Ertl To: Daniel Eriksson In-Reply-To: Message-ID: <20040812005056.H631@korben.in.tern> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-DCC-ZID-Univie-Metrics: mail 4249; Body=2 Fuz1=2 Fuz2=2 cc: freebsd-current@FreeBSD.org Subject: Re: gvinum and RAID-5, page-fault on lost disc? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 22:51:57 -0000 On Thu, 12 Aug 2004, Daniel Eriksson wrote: > > As I reported on the "Vinum status" thread a few days ago, gvinum is not > very graceful when a disc disappears/dies in a RAID-5 array during > operation. Yes, that's quite likely. :-) I need to work on the failure tolerance. cheers, le -- Lukas Ertl http://homepage.univie.ac.at/l.ertl/ le@FreeBSD.org http://people.freebsd.org/~le/ From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:54:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94B2916A4CE; Wed, 11 Aug 2004 22:54:03 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CE2943D48; Wed, 11 Aug 2004 22:54:03 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7BMqrVj097156; Wed, 11 Aug 2004 16:52:54 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 11 Aug 2004 16:53:03 -0600 (MDT) Message-Id: <20040811.165303.35850140.imp@bsdimp.com> To: ru@freebsd.org From: "M. Warner Losh" In-Reply-To: <20040811224317.GE96867@ip.net.ua> References: <20040811221348.GB93983@ip.net.ua> <20040811.162640.00482545.imp@bsdimp.com> <20040811224317.GE96867@ip.net.ua> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: harti@freebsd.org cc: current@freebsd.org cc: kris@obsecurity.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 22:54:03 -0000 In message: <20040811224317.GE96867@ip.net.ua> Ruslan Ermilov writes: : On Wed, Aug 11, 2004 at 04:26:40PM -0600, M. Warner Losh wrote: : > In message: <20040811221348.GB93983@ip.net.ua> : > Ruslan Ermilov writes: : > : On Wed, Aug 11, 2004 at 04:04:20PM -0600, M. Warner Losh wrote: : > : > In message: <20040810231044.GA70020@xor.obsecurity.org> : > : > Kris Kennaway writes: : > : > : More fallout from the wonderful new make(1) semantics? : > : > : > : > I think it is speficially related to the changes to src/Makefile and : > : > src/Makefile.inc1. If I s/${_+_}//g on those two files, it appears : > : > that I can buildworld again (at least it doesn't die right away). : > : > : > : How exactly does it die for you, please provide some logs. : > : > The problem is due to the following in share/mk/sys.mk: : > : > .if !empty(.MAKEFLAGS:M-n) && ${.MAKEFLAGS:M-n} == "-n" : > _+_ ?= : > .else : > _+_ ?= + : > .endif : > : > This should have a third clause: : > : > .if ${MAKE_VERSION} >= 5200408030 && !empty(.MAKEFLAGS:M-n) && ${.MAKEFLAGS:M-n} == "-n" : > : > so that _+_ is defined to be nothing for those versions of make that : > don't yet support this new feature of posix. : > : Why? It's not supposed that you try an old make(1) binary with : the new share/mk/sys.mk. src/Makefile will upgrade make(1) if : necessary, then use it (or the old make if it's adequate) with : new share/mk stuff to call Makefile.inc1. If you throw away : the -m from your "make" command in your build script, it will : work. I'm not entirely sure why we have it in our build scripts. My software archiology is such that I can't find out why this was added to them (because the same code has jumped between N tools that have grown up over the years). : We want to be able to use the new make(1) features in our : share/mk files right after when they made available. That was : one of the main ideas of the make(1) regression testing feature : in src/Makefile. OK. : It's like we now handle backward issues in our C sources -- we : agreed not to pollute sources with __FreeBSD_version checks, : and we keep the necessary bootstrapping glue in a separate : place. The same applies here -- one is free to use new make(1) : features in src/ makefiles and in share/mk support files. : src/Makefile and tools/regression/usr.bin/make guarantee that : we'll always use the make(1) binary compatible with the : feature set used in our .mk and makefiles. OK. : Please update your build scripts... These build scripts have been this way since the product that used FreeBSD 3.4.1... This is the first time that there has been a problem with that :-(. I'll try to update and fixed like you suggested, however... Warner From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:55:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FC9A16A4CE for ; Wed, 11 Aug 2004 22:55:28 +0000 (GMT) Received: from tethys.ringofsaturn.com (tethys.ringofsaturn.com [66.13.175.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9CFE43D41 for ; Wed, 11 Aug 2004 22:55:27 +0000 (GMT) (envelope-from rnejdl@ringofsaturn.com) Received: from mail.ringofsaturn.com (localhost [127.0.0.1]) i7BMtQRN047571; Wed, 11 Aug 2004 17:55:27 -0500 (CDT) (envelope-from rnejdl@ringofsaturn.com) Received: from 12.148.147.242 (SquirrelMail authenticated user rnejdl); by mail.ringofsaturn.com with HTTP; Wed, 11 Aug 2004 17:55:27 -0500 (CDT) Message-ID: <43870.12.148.147.242.1092264927.squirrel@[12.148.147.242]> In-Reply-To: <200408120023.07624.michaelnottebrock@gmx.net> References: <18300.12.148.147.242.1092234409.squirrel@[12.148.147.242]> <200408111857.16230.michaelnottebrock@gmx.net> <41704.12.148.147.242.1092260746.squirrel@[12.148.147.242]> <200408120023.07624.michaelnottebrock@gmx.net> Date: Wed, 11 Aug 2004 17:55:27 -0500 (CDT) From: "Rusty Nejdl" To: "Michael Nottebrock" User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on tethys.ringofsaturn.com X-Virus-Status: Clean cc: freebsd-current@freebsd.org Subject: Re: Signal 11 compiling qt33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rnejdl@ringofsaturn.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2004 22:55:28 -0000 Michael Nottebrock said: > On Wednesday 11 August 2004 23:45, Rusty Nejdl wrote: > >> What is up with threading here??? >> >> >> Rusty Nejdl >> > > I don't have the slightest idea what's biting you there, sorry :-\. > Perhaps > something is indeed wrong with the snapshot... I think this has to do with xorg and its choice of threading vs qt33 and its choice of threading as I am running the exact same snapshop on my laptop, but installing using XFree86 and it's working. I'm going to keep playing with this, though. I've pulled world from today and I'm rebuilding as we speak, so hopefully with that and any port updates that were commited today, I can get this working. > > Btw, my mails to you seem to be bouncing: I caught that earlier and fixed that. Sorry about that. Rusty Nejdl > > > > > -- > ,_, | Michael Nottebrock | lofi@freebsd.org > (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org > \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org > > From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:56:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E1CA16A4CE for ; Wed, 11 Aug 2004 22:56:02 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E52C43D39 for ; Wed, 11 Aug 2004 22:56:02 +0000 (GMT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 660165C98E; Wed, 11 Aug 2004 15:56:02 -0700 (PDT) Date: Thu, 12 Aug 2004 00:56:02 +0200 From: Maxime Henrion To: Julian Elischer Message-ID: <20040811225602.GN13608@elvis.mu.org> References: <411AA203.1020502@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <411AA203.1020502@elischer.org> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: [Fwd: RFC.. defining __rangeof() in cdefs.h] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 22:56:02 -0000 Julian Elischer wrote: > Interresting.. not a single comment.. :-/ > > From: Julian Elischer > Date: Mon, 09 Aug 2004 14:40:37 -0700 > To: current@freebsd.org > Subject: RFC.. defining __rangeof() in cdefs.h > > I'm considdereing adding: > Index: sys/cdefs.h > =================================================================== > RCS file: /home/ncvs/src/sys/sys/cdefs.h,v > retrieving revision 1.83 > diff -u -r1.83 cdefs.h > --- sys/cdefs.h 28 Jul 2004 07:03:42 -0000 1.83 > +++ sys/cdefs.h 9 Aug 2004 21:36:41 -0000 > @@ -241,6 +241,8 @@ > * require it. > */ > #define __offsetof(type, field) ((size_t)(&((type *)0)->field)) > +#define __rangeof(type, start, end) \ > + (__offsetof(type, end) - __offsetof(type, start)) > > /* > * Compiler-dependent macros to declare that functions take printf-like > > > it is used in several places. most importantly in fork1() > > and it is defined in several files (*).. we should probably just have > one copy... > > > (*) in the form RANGEOF() but if we define it in cdefs.h I'd change that to > __rangeof() to match __offsetof() The patch looks fine to me, I think it should go in. :-) Cheers, Maxime From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 23:00:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BE2716A4D5; Wed, 11 Aug 2004 23:00:36 +0000 (GMT) Received: from ran.psg.com (ip192.186.dsl-acs2.seawa0.iinet.com [209.20.186.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id C366943D5E; Wed, 11 Aug 2004 23:00:25 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ran.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bv24x-000JPM-1z; Wed, 11 Aug 2004 16:00:19 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16666.42242.552955.635999@ran.psg.com> Date: Wed, 11 Aug 2004 16:00:18 -0700 To: Robert Watson References: <16666.37963.904734.842647@ran.psg.com> cc: FreeBSD Current Subject: Re: ipfw X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 23:00:36 -0000 >> ipfw seems to be starting in some strange state where it has loaded my >> ruleset but does not really process it. everything ends up in >> unreachable. if i run `ipfw -q /etc/ipfw.rules`, the same command set >> that's in /etc/rc.conf, it takes off as expected. > The recent addition of O_ANTISPOOF renumbered the IPFW rule operations, so > if you're using a newer kernel and an older user space bingo! thanks. randy From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 23:04:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 647D816A4CF; Wed, 11 Aug 2004 23:04:52 +0000 (GMT) Received: from av5-1-sn4.m-sp.skanova.net (av5-1-sn4.m-sp.skanova.net [81.228.10.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2375843D54; Wed, 11 Aug 2004 23:04:52 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av5-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 8A16137E81; Thu, 12 Aug 2004 01:04:51 +0200 (CEST) Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av5-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 7CFDA37E49; Thu, 12 Aug 2004 01:04:51 +0200 (CEST) Received: from gadget (h130n1fls11o822.telia.com [213.64.66.130]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 5773937E46; Thu, 12 Aug 2004 01:04:51 +0200 (CEST) From: "Daniel Eriksson" To: "'John Baldwin'" , Date: Thu, 12 Aug 2004 01:04:49 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcR/1z9O/J3eci7dRoG/kFoJv0oHqwAH1ihA In-Reply-To: <200408111501.23593.jhb@FreeBSD.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 cc: 'Nate Lawson' Subject: RE: cvs commit: src/sys/dev/acpica acpi_pci_link.c acpi_pcib.cacpi_pcib_acpi.c acpi_pcib_pci.c acpi_pcibvar.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 23:04:52 -0000 John Baldwin wrote: > He's using an I/O APIC. These are probably all entries that > don't have a link > device but just a hardwired global interrupt number. Did you > test that case? Yes, I have "device apic" in my kernel config file. Is this a bad thing to do for a UP system? I remember googling "device apic" and finding at least some info that seemed to indicate that it was off by default in GENERIC simply because there are a few I/O APICs that are buggy, and that it actually helped on systems with properly working chips. Should I leave it out of my kernel config? (I'm just about to recompile with Nate's extra debug output patch.) /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 23:16:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A09A16A4CE for ; Wed, 11 Aug 2004 23:16:52 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8C0243D41 for ; Wed, 11 Aug 2004 23:16:51 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from dhcp50.pn.xcllnt.net (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i7BNGp73083040; Wed, 11 Aug 2004 16:16:51 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp50.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp50.pn.xcllnt.net (8.13.1/8.13.1) with ESMTP id i7BNGpHI026025; Wed, 11 Aug 2004 16:16:51 -0700 (PDT) (envelope-from marcel@dhcp50.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp50.pn.xcllnt.net (8.13.1/8.13.1/Submit) id i7BNGpbm026024; Wed, 11 Aug 2004 16:16:51 -0700 (PDT) (envelope-from marcel) Date: Wed, 11 Aug 2004 16:16:51 -0700 From: Marcel Moolenaar To: Nate Lawson Message-ID: <20040811231651.GA25883@dhcp50.pn.xcllnt.net> References: <20040811214708.GA25696@dhcp50.pn.xcllnt.net> <411A9F14.4000204@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <411A9F14.4000204@root.org> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: ia64: ACPI PCI IRQ routing breakage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 23:16:52 -0000 On Wed, Aug 11, 2004 at 03:35:00PM -0700, Nate Lawson wrote: > > It's likely your link devices don't like being called with _DIS. Try > the attached patch. *snip* > Index: acpi_pci_link.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/acpica/acpi_pci_link.c,v > retrieving revision 1.20 > diff -u -r1.20 acpi_pci_link.c > --- acpi_pci_link.c 11 Aug 2004 20:37:24 -0000 1.20 > +++ acpi_pci_link.c 11 Aug 2004 22:33:09 -0000 > @@ -377,12 +377,13 @@ > * run _DIS (i.e., the method doesn't exist), assume the initial > * IRQ was routed by the BIOS. > */ > +#if 0 > if (ACPI_SUCCESS(AcpiEvaluateObject(handle, "_DIS", NULL, NULL))) { > link->current_irq = 0; > link->flags = ACPI_LINK_NONE; > } else { > +#endif > link->flags = ACPI_LINK_ROUTED; > - } > > error = AcpiGetPossibleResources(handle, &buf); > if (ACPI_FAILURE(error)) { No change whatsoever. This apparently is not it... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 23:18:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6972816A4CE; Wed, 11 Aug 2004 23:18:54 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0780B43D41; Wed, 11 Aug 2004 23:18:54 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1Bv2Mu-0000KO-00; Thu, 12 Aug 2004 01:18:52 +0200 Received: from [217.227.155.1] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1Bv2Mu-0005ER-00; Thu, 12 Aug 2004 01:18:52 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Thu, 12 Aug 2004 01:16:52 +0200 User-Agent: KMail/1.6.2 References: <16666.37963.904734.842647@ran.psg.com> <16666.42242.552955.635999@ran.psg.com> In-Reply-To: <16666.42242.552955.635999@ran.psg.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_rjqGBPbXNU6szCC"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408120116.59718.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Randy Bush cc: Andre Oppermann cc: Robert Watson Subject: Re: ipfw X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 23:18:54 -0000 --Boundary-02=_rjqGBPbXNU6szCC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 12 August 2004 01:00, Randy Bush wrote: > >> ipfw seems to be starting in some strange state where it has loaded my > >> ruleset but does not really process it. everything ends up in > >> unreachable. if i run `ipfw -q /etc/ipfw.rules`, the same command set > >> that's in /etc/rc.conf, it takes off as expected. > > > > The recent addition of O_ANTISPOOF renumbered the IPFW rule operations, > > so if you're using a newer kernel and an older user space > > bingo! thanks. This should maybe go to UPDATING?! =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_rjqGBPbXNU6szCC Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBGqjrXyyEoT62BG0RAhwhAJwLtgfBsN4fmlBDoVSCWkeuIiGIsACdGgQV 7nSEKcicuzigal+pnP9E9Io= =G7A3 -----END PGP SIGNATURE----- --Boundary-02=_rjqGBPbXNU6szCC-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 23:23:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98AC516A4CF; Wed, 11 Aug 2004 23:23:38 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CC6943D39; Wed, 11 Aug 2004 23:23:38 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7BNNb8U006095; Wed, 11 Aug 2004 16:23:37 -0700 Message-ID: <411AAA78.2020401@root.org> Date: Wed, 11 Aug 2004 16:23:36 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eriksson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/sys/dev/acpica acpi_pci_link.c acpi_pcib.cacpi_pcib_acpi.c acpi_pcib_pci.c acpi_pcibvar.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 23:23:39 -0000 Daniel Eriksson wrote: > John Baldwin wrote: > > >>He's using an I/O APIC. These are probably all entries that >>don't have a link >>device but just a hardwired global interrupt number. Did you >>test that case? > > > Yes, I have "device apic" in my kernel config file. Is this a bad thing to > do for a UP system? > > I remember googling "device apic" and finding at least some info that seemed > to indicate that it was off by default in GENERIC simply because there are a > few I/O APICs that are buggy, and that it actually helped on systems with > properly working chips. No need to disable it although if disabling it fixes your problems, that would be an interesting data point. > Should I leave it out of my kernel config? (I'm just about to recompile with > Nate's extra debug output patch.) Leave it in. The debug output is more important right now. -Nate From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 23:25:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05EAB16A4CE; Wed, 11 Aug 2004 23:25:46 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAC8B43D31; Wed, 11 Aug 2004 23:25:45 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7BNPi8U006166; Wed, 11 Aug 2004 16:25:44 -0700 Message-ID: <411AAAF7.9030506@root.org> Date: Wed, 11 Aug 2004 16:25:43 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: multipart/mixed; boundary="------------050605010800050105090405" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: acpi@freebsd.org Subject: ACPI mpsafe patch for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 23:25:46 -0000 This is a multi-part message in MIME format. --------------050605010800050105090405 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Attached is the latest patch for running ACPI mpsafe. It has been pretty well tested and is ready for wider testing. It's especially good to run it with WITNESS enabled. To test, just use it with your system normally. Thanks, Nate --------------050605010800050105090405-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 23:40:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6A7C16A4CE for ; Wed, 11 Aug 2004 23:40:58 +0000 (GMT) Received: from hotmail.com (bay8-f44.bay8.hotmail.com [64.4.27.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CF5D43D31 for ; Wed, 11 Aug 2004 23:40:58 +0000 (GMT) (envelope-from evantd@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 11 Aug 2004 16:40:58 -0700 Received: from 67.171.32.75 by by8fd.bay8.hotmail.msn.com with HTTP; Wed, 11 Aug 2004 23:40:58 GMT X-Originating-IP: [67.171.32.75] X-Originating-Email: [evantd@hotmail.com] X-Sender: evantd@hotmail.com From: "Evan Dower" To: freebsd-current@freebsd.org Date: Wed, 11 Aug 2004 16:40:58 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Aug 2004 23:40:58.0550 (UTC) FILETIME=[A71E8D60:01C47FFC] Subject: Project Evil: TI ACX111 non-success X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 23:40:58 -0000 I've been trying to get the ndisulator to work for my NetGear WG311v2 so I can take the ethernet cables and switches offthe floor in my hall. The following is the "conversation" I've had with Bill Paul. It is perhaps best to read from the bottom up to get the chronology right. Also, as it turns out the net/acx100 port makes no claim to support the acx111, and I was eventually able to build and load it, though of course it didn't work because it doesn't support the acx111. Any help would be greatly appreciated. -- I managed to get rid of the "can't re-use a leaf" messaged by deleting the duplicate entry in ndis_driver_data.h. For some reason, whenever I try to load if_ndis.ko (ndis.ko is already loaded), I get messages about amdpm. Perhaps ndis returning 6 and failing to load is a result of the same return value from trying to attach amdpm. amdpm0: port 0xe4e0-0xe4ff at device 7.3 on pci0 amdpm0: could not map i/o space device_attach: amdpm0 attach returned 6 ndis0: mem 0xf0800000-0xf081ffff,0xf1000000-0xf1001fff irq 17 at device 6.0 on pci2 ndis0: [GIANT-LOCKED] no match for srand ndis0: NDIS API version: 5.1 ndis0: init handler failed device_attach: ndis0 attach returned 6 Thanks again, Evan Dower El mar, 20-07-2004 a las 10:58, Evan Dower escribió: >I have figured out that the "can't re-use a leaf" message is coming from >trying to register a sysctl, which comes from the .inf file. This seems >to indicate some limitations on the complexity of .inf files that can be >properly parsed and turned into a list of sysctls. Since I'm not exactly >sure what those limitations are, I'm sending you a link to the .inf file >(and the .sys file for good measure)ˇ Other than that, it looks like >srand might just need to be plugged into one of the function tables >(probably the hal table, I guess). Also, if you can tell me what >limitations exist for the .inf file, I will gladly modify it to work and >make it available to other WG311v2 owners. >Thanks again, >Evan Dower >Note: Much of the .inf file (anything not for XP) is commented out in an >attempt to make things work. This was my doing. It didn't ship that way. >Since I don't really understand the Windows registry, I didn't get too >adventurous. > >Files at: http://students.washington.edu/evantd/pub/evil/ > >El lun, 12-07-2004 a las 16:05, Evan Dower escribió: > > I have a Netgear WG311v2. The v2 turns out to be very important as the > > original (v1 you might call it now) was based on an Atheros AR5212 and > > was thus supported by the ath driver. v2 is based on the the TI AXC111 > > (aka TNETW1130), which should be supported by the net/acx100 port, but > > if_acx.ko fails to load due to a missing __panic symbol. Following the > > instructions you posted in an email, I made ndis_driver_data.h and > > built and loaded the if_ndis.ko module (after loading ndis.ko or > > compiling it into the kernel). I used the Windows XP .SYS and .INF > > files, though the Windows 2000 versions gave the same result, the > > Windows 98 files produced a module that panicked on load, and I didn't > > try the Windows ME files. The following is the output from `make > > load`. > > > /sbin/kldload -v /usr/current/src/sys/modules/if_ndis/if_ndis.ko > > ndis0: mem > > 0xec800000-0xec81ffff, > > 0xed000000-0xed001fff irq 17 at device 6.0 on pci2 > > ndis0: [GIANT-LOCKED] > > can't re-use a leaf (dot11DesiredBSSType)! > > no match for srand > > ndis0: NDIS API version: 5.1 > > ndis0: init handler failed > > device_attach: ndis0 attach returned 6 > > Loaded /usr/current/src/sys/modules/if_ndis/if_ndis.ko, id=11 > > > Loading the module does not create /dev/ndis0 or /dev/if_ndis0 (or > > anything of the sort). I am running today's -CURRENT. > > > It seems that it requires srand, and I assume the 'can't re-use a leaf > > (dot11DesiredBSSType)!' is also a show-stopper. I ordered my card from > > newegg.com for about $50. > > > If there is anything else you might be interested in (a verbose boot > > log, copies of the .SYS and .INF files, testing for patches, etc.), > > just let me know. I'd be happy to help (especially since the result is > > a working wireless connection). > > > Thanks very much, -- Evan Dower Undergraduate, Computer Science University of Washington Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 23:44:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C79E616A4CE; Wed, 11 Aug 2004 23:44:57 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80AF743D60; Wed, 11 Aug 2004 23:44:57 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7BNiu8U006621; Wed, 11 Aug 2004 16:44:57 -0700 Message-ID: <411AAF78.5010206@root.org> Date: Wed, 11 Aug 2004 16:44:56 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org References: <411AAAF7.9030506@root.org> In-Reply-To: <411AAAF7.9030506@root.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: ACPI mpsafe patch for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 23:44:57 -0000 Nate Lawson wrote: > Attached is the latest patch for running ACPI mpsafe. It has been > pretty well tested and is ready for wider testing. It's especially good > to run it with WITNESS enabled. To test, just use it with your system > normally. > > Thanks, > Nate I've put the patch up at this url since the list appears to strip attachments: http://root.org/~nate/freebsd/acpi_mpsafe.diff.gz -Nate From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 23:56:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48EFC16A4CE; Wed, 11 Aug 2004 23:56:32 +0000 (GMT) Received: from lakermmtao07.cox.net (lakermmtao07.cox.net [68.230.240.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id A56DE43D2D; Wed, 11 Aug 2004 23:56:31 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.71.51]) by lakermmtao07.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040811235629.YBTL5847.lakermmtao07.cox.net@dolphin.local.net>; Wed, 11 Aug 2004 19:56:29 -0400 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with ESMTP id i7BNuSuV077807; Wed, 11 Aug 2004 18:56:28 -0500 (CDT) (envelope-from conrads@dolphin.local.net) Received: (from conrads@localhost) by dolphin.local.net (8.13.1/8.13.1/Submit) id i7BNuN5f077788; Wed, 11 Aug 2004 18:56:23 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 11 Aug 2004 18:56:23 -0500 (CDT) Organization: A Rag-Tag Band of Drug-Crazed Hippies From: "Conrad J. Sabatier" To: freebsd-current@FreeBSD.org cc: Don Lewis cc: dnelson@allantgroup.com cc: Rusty Nejdl Subject: Re: Is anything being done re: the pcm timeout issue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conrads@cox.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2004 23:56:32 -0000 On 11-Aug-2004 Conrad J. Sabatier wrote: > > I do appreciate your looking into this matter. So far, with my > latest kernel, I haven't experienced the problem yet, either. Which > doesn't necessarily mean, of course, that I still won't. :-) Oh well, it was nice while it lasted. Just did it again. I think tomorrow I'm going to try pulling the es1371 card out of my old machine and see how it works in the amd64 box. Maybe it's just the chipset/driver. I'll report the results later. -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 00:03:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CEFE16A4CE for ; Thu, 12 Aug 2004 00:03:51 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B62D43D45 for ; Thu, 12 Aug 2004 00:03:51 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 7286 invoked from network); 12 Aug 2004 00:03:50 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Aug 2004 00:03:50 -0000 Received: from hydrogen.funkthat.com (pkdapa@localhost.funkthat.com [127.0.0.1])i7C03nuU010747 for ; Wed, 11 Aug 2004 17:03:50 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i7C03nvB010746 for freebsd-current@freebsd.org; Wed, 11 Aug 2004 17:03:49 -0700 (PDT) Date: Wed, 11 Aug 2004 17:03:49 -0700 From: John-Mark Gurney To: freebsd-current@freebsd.org Message-ID: <20040812000349.GX991@funkthat.com> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: problems loading modules? solution inside X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2004 00:03:51 -0000 Thanks to Ruslan Ermilov (ru@) for discovering the fix for the problem of loading modules. The entry from UPDATING: Module loading has been fixed. Some older installations will drop proper module_path initalization and modules will fail to load properly. If you have a line in /boot/loader.rc that says: "initialize drop", do (i386 only): cp /usr/src/sys/boot/i386/loader/loader.rc /boot/loader.rc chown root:wheel /boot/loader.rc chmod 444 /boot/loader.rc -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 00:27:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A0FE16A4CE for ; Thu, 12 Aug 2004 00:27:21 +0000 (GMT) Received: from av7-1-sn1.fre.skanova.net (av7-1-sn1.fre.skanova.net [81.228.11.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 483A643D1D for ; Thu, 12 Aug 2004 00:27:21 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av7-1-sn1.fre.skanova.net (Postfix, from userid 502) id A00D837E82; Thu, 12 Aug 2004 02:27:20 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av7-1-sn1.fre.skanova.net (Postfix) with ESMTP id 530E937E47; Thu, 12 Aug 2004 02:27:20 +0200 (CEST) Received: from gadget (h130n1fls11o822.telia.com [213.64.66.130]) by smtp3-2-sn1.fre.skanova.net (Postfix) with ESMTP id 32D0837E46; Thu, 12 Aug 2004 02:27:20 +0200 (CEST) From: "Daniel Eriksson" To: =?iso-8859-1?Q?'S=F8ren_Schmidt'?= , Date: Thu, 12 Aug 2004 02:27:14 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <411A0EF0.4090808@DeepCore.dk> Thread-Index: AcR/neYVjMFapPT/Qa6sEq/VuvWj/gAY8DSg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: RE: ATA driver races with interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 00:27:21 -0000 S=F8ren Schmidt wrote: > How about not running the SMART monitor ? After upgrading the system to sources dated 2004.08.11.15.00.00 I = rebooted with the SMART monitor turned off. The system worked fine (apart from = having to run without ACPI due to recent commits) until just 30 minutes ago = when I was turning it off to upgrade kernel again (trying to track down the = ACPI breakage and needed boot -v output for Nate). After all the buffers had = been flushed it reported a timeout on one of the SATA discs, removed it from = the configuration and then went on to a panic (sorry, no log available). Afterwards the channel was locked up as always when this happens. It seems the problem is not smartmontools related. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 00:39:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E73E916A4CE; Thu, 12 Aug 2004 00:39:28 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75A9C43D1D; Thu, 12 Aug 2004 00:39:28 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7C0bVaR098149; Wed, 11 Aug 2004 18:37:32 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 11 Aug 2004 18:37:41 -0600 (MDT) Message-Id: <20040811.183741.114534886.imp@bsdimp.com> To: ru@freebsd.org From: "M. Warner Losh" In-Reply-To: <20040811.165303.35850140.imp@bsdimp.com> References: <20040811.162640.00482545.imp@bsdimp.com> <20040811224317.GE96867@ip.net.ua> <20040811.165303.35850140.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: harti@freebsd.org cc: current@freebsd.org cc: kris@obsecurity.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 00:39:29 -0000 In message: <20040811.165303.35850140.imp@bsdimp.com> "M. Warner Losh" writes: : : Please update your build scripts... : : These build scripts have been this way since the product that used : FreeBSD 3.4.1... This is the first time that there has been a problem : with that :-(. I'll try to update and fixed like you suggested, : however... Preliminary indications are that this fixed the problem. Office lore has it that this was added when we were using 4.2 to build correctly on 4.0 machines. Warner From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 00:49:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20A9C16A4CE for ; Thu, 12 Aug 2004 00:49:01 +0000 (GMT) Received: from av2-2-sn3.vrr.skanova.net (av2-2-sn3.vrr.skanova.net [81.228.9.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id A86DE43D48 for ; Thu, 12 Aug 2004 00:48:59 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av2-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 0D7A23820C; Thu, 12 Aug 2004 02:48:59 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av2-2-sn3.vrr.skanova.net (Postfix) with ESMTP id E91AA37FB0; Thu, 12 Aug 2004 02:48:58 +0200 (CEST) Received: from gadget (h130n1fls11o822.telia.com [213.64.66.130]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id CB4F338003; Thu, 12 Aug 2004 02:48:57 +0200 (CEST) From: "Daniel Eriksson" To: "'Nate Lawson'" Date: Thu, 12 Aug 2004 02:48:55 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C48016.E936E020" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <411A5A12.2070404@root.org> Thread-Index: AcR/zIElU3VBkDWgRde9xCb4t/ctGQAN61hw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 cc: freebsd-current@freebsd.org Subject: RE: cvs commit: src/sys/dev/acpica acpi_pci_link.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c acpi_pcibvar.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 00:49:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C48016.E936E020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nate Lawson wrote: > I need the dmesg output from boot -v to see the link priority > settings. Attached is the "boot -v" output from two separate boots with a kernel built from sources dated 2004.08.11.21.00.00 (after your patch with additional debug output). The two logs (with "PnP OS installed" set to Yes or No in BIOS) are pretty similar, so I don't think that setting in the BIOS makes much difference for your code. The next thing to try (I guess) is a kernel without "device apic". However, my users are a bit upset about the downtime (already 3 reboots today) so I might have to wait with that until tomorrow. /Daniel Eriksson ------=_NextPart_000_0000_01C48016.E936E020 Content-Type: text/plain; name="boot_PnP_no.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="boot_PnP_no.txt" KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=3D01 base=3D0000000000000000 len=3D000000000009d000 SMAP type=3D02 base=3D000000000009d000 len=3D0000000000003000 SMAP type=3D02 base=3D00000000000f0000 len=3D0000000000010000 SMAP type=3D01 base=3D0000000000100000 len=3D000000004fefb000 SMAP type=3D03 base=3D000000004fffb000 len=3D0000000000004000 SMAP type=3D04 base=3D000000004ffff000 len=3D0000000000001000 SMAP type=3D02 base=3D00000000fec00000 len=3D0000000000001000 SMAP type=3D02 base=3D00000000fee00000 len=3D0000000000001000 SMAP type=3D02 base=3D00000000ffff0000 len=3D0000000000010000 Copyright (c) 1992-2004 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 5.2-CURRENT #2: Thu Aug 12 01:23:35 CEST 2004 daniel@fortify.satra.zapto.org:/usr/obj/usr/src/sys/FORTIFY Preloaded elf kernel "/boot/kernel/kernel" at 0xc089b000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc089b254. Calibrating clock(s) ... i8254 clock: 1193226 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1999782501 Hz CPU: AMD Athlon(TM) XP 2500+ (1999.78-MHz 686-class CPU) Origin =3D "AuthenticAMD" Id =3D 0x6a0 Stepping =3D 0 = Features=3D0x383fbff AMD Features=3D0xc0400000 Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way = associative L2 internal cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 8-way = associative real memory =3D 1342156800 (1279 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009cfff, 638976 bytes (156 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c26000 - 0x000000004e94afff, 1305628672 bytes (318757 pages) avail memory =3D 1305075712 (1244 MB) Table 'FACP' at 0x4fffb0b2 Table 'BOOT' at 0x4fffb030 Table 'APIC' at 0x4fffb058 MADT: Found table at 0x4fffb058 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled ACPI APIC Table: bios32: Found BIOS32 Service Directory header at 0xc00f2000 bios32: Entry =3D 0xf1940 (c00f1940) Rev =3D 0 Len =3D 1 pcibios: PCI BIOS entry at 0xf0000+0x1970 pnpbios: Found PnP BIOS data at 0xc00f9cb0 pnpbios: Entry =3D f0000:9ce0 Rev =3D 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: intr override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: active-high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00040010 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff mem: Pentium Pro MTRR support enabled null: random: io: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [GIANT-LOCKED] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000060 pci_open(1a): mode1res=3D0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=3D060000] [hdr=3D00] is there = (id=3D31891106) pcibios: BIOS version 2.10 Found $PIR table, 11 entries at 0xc00f1f20 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs slot 1 0 12 A 0x05 3 4 5 7 9 10 11 12 slot 1 0 12 B 0x01 3 4 5 7 9 10 11 12 slot 1 0 12 C 0x02 3 4 5 7 9 10 11 12 slot 1 0 12 D 0x03 3 4 5 7 9 10 11 12 slot 2 0 13 A 0x01 3 4 5 7 9 10 11 12 slot 2 0 13 B 0x02 3 4 5 7 9 10 11 12 slot 2 0 13 C 0x03 3 4 5 7 9 10 11 12 slot 2 0 13 D 0x05 3 4 5 7 9 10 11 12 slot 3 0 14 A 0x02 3 4 5 7 9 10 11 12 slot 3 0 14 B 0x03 3 4 5 7 9 10 11 12 slot 3 0 14 C 0x05 3 4 5 7 9 10 11 12 slot 3 0 14 D 0x01 3 4 5 7 9 10 11 12 slot 4 0 19 A 0x03 3 4 5 7 9 10 11 12 slot 4 0 19 B 0x05 3 4 5 7 9 10 11 12 slot 4 0 19 C 0x01 3 4 5 7 9 10 11 12 slot 4 0 19 D 0x02 3 4 5 7 9 10 11 12 slot 5 0 11 A 0x05 3 4 5 7 9 10 11 12 slot 5 0 11 B 0x01 3 4 5 7 9 10 11 12 slot 5 0 11 C 0x02 3 4 5 7 9 10 11 12 slot 5 0 11 D 0x03 3 4 5 7 9 10 11 12 slot 6 0 10 A 0x01 3 4 5 7 9 10 11 12 slot 6 0 10 B 0x02 3 4 5 7 9 10 11 12 slot 6 0 10 C 0x03 3 4 5 7 9 10 11 12 slot 6 0 10 D 0x05 3 4 5 7 9 10 11 12 slot 7 1 0 A 0x01 3 4 5 7 9 10 11 12 slot 7 1 0 B 0x02 3 4 5 7 9 10 11 12 embedded 0 15 A 0x06 3 4 5 7 9 10 11 12 embedded 0 15 B 0x07 3 4 5 7 9 10 11 12 embedded 0 16 A 0x06 3 4 5 7 9 10 11 12 embedded 0 16 B 0x07 3 4 5 7 9 10 11 12 embedded 0 16 C 0x08 3 4 5 7 9 10 11 12 embedded 0 16 D 0x09 3 4 5 7 9 10 11 12 embedded 0 17 C 0x08 3 4 5 7 9 10 11 12 embedded 0 17 D 0x09 3 4 5 7 9 10 11 12 embedded 0 18 A 0x06 3 4 5 7 9 10 11 12 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 17 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 17 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 15 func 0 acpi0: Power Button (fixed) acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 18 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 2 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 3 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 4 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 5 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 unknown: not probed (disabled) unknown: not probed (disabled) cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: pci0: on pcib0 pci0: physical bus=3D0 map[10]: type 3, range 32, base f8000000, size 26, enabled found-> vendor=3D0x1106, dev=3D0x3189, revid=3D0x80 bus=3D0, slot=3D0, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x2230, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) powerspec 2 supports D0 D3 current D0 found-> vendor=3D0x1106, dev=3D0xb198, revid=3D0x00 bus=3D0, slot=3D1, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x2230, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x08 (2000 ns), maxlat=3D0x00 = (0 ns) map[10]: type 4, range 32, base 0000d800, size 3, enabled map[14]: type 4, range 32, base 0000d400, size 2, enabled map[18]: type 4, range 32, base 0000d000, size 3, enabled map[1c]: type 4, range 32, base 0000b800, size 2, enabled map[20]: type 4, range 32, base 0000b400, size 8, enabled found-> vendor=3D0x1103, dev=3D0x0008, revid=3D0x07 bus=3D0, slot=3D10, func=3D0 class=3D01-04-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0230, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x08 (2000 ns), = maxlat=3D0x08 (2000 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000b000, size 3, enabled map[14]: type 4, range 32, base 0000a800, size 2, enabled map[18]: type 4, range 32, base 0000a400, size 3, enabled map[1c]: type 4, range 32, base 0000a000, size 2, enabled map[20]: type 4, range 32, base 00009800, size 8, enabled found-> vendor=3D0x1103, dev=3D0x0008, revid=3D0x07 bus=3D0, slot=3D10, func=3D1 class=3D01-04-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0230, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x08 (2000 ns), = maxlat=3D0x08 (2000 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00009400, size 8, enabled map[14]: type 1, range 64, base ed800000, size 12, enabled found-> vendor=3D0x9005, dev=3D0x0080, revid=3D0x02 bus=3D0, slot=3D12, func=3D0 class=3D01-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0017, statreg=3D0x02b0, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x28 (10000 ns), = maxlat=3D0x19 (6250 ns) intpin=3Da, irq=3D3 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00009000, size 3, enabled map[14]: type 4, range 32, base 00008800, size 2, enabled map[18]: type 4, range 32, base 00008400, size 3, enabled map[1c]: type 4, range 32, base 00008000, size 2, enabled map[20]: type 4, range 32, base 00007800, size 8, enabled found-> vendor=3D0x1103, dev=3D0x0008, revid=3D0x07 bus=3D0, slot=3D14, func=3D0 class=3D01-04-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0230, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x08 (2000 ns), = maxlat=3D0x08 (2000 ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00007400, size 3, enabled map[14]: type 4, range 32, base 00007000, size 2, enabled map[18]: type 4, range 32, base 00006800, size 3, enabled map[1c]: type 4, range 32, base 00006400, size 2, enabled map[20]: type 4, range 32, base 00006000, size 8, enabled found-> vendor=3D0x1103, dev=3D0x0008, revid=3D0x07 bus=3D0, slot=3D14, func=3D1 class=3D01-04-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0230, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x08 (2000 ns), = maxlat=3D0x08 (2000 ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00005800, size 3, enabled map[14]: type 4, range 32, base 00005400, size 2, enabled map[18]: type 4, range 32, base 00005000, size 3, enabled map[1c]: type 4, range 32, base 00004800, size 2, enabled map[20]: type 4, range 32, base 00004400, size 4, enabled map[24]: type 4, range 32, base 00004000, size 8, enabled found-> vendor=3D0x1106, dev=3D0x3149, revid=3D0x80 bus=3D0, slot=3D15, func=3D0 class=3D01-04-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Db, irq=3D9 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 00003800, size 4, enabled found-> vendor=3D0x1106, dev=3D0x0571, revid=3D0x06 bus=3D0, slot=3D15, func=3D1 class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Da, irq=3D14 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 00003400, size 5, enabled found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0x81 bus=3D0, slot=3D16, func=3D0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0017, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Da, irq=3D5 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 00003000, size 5, enabled found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0x81 bus=3D0, slot=3D16, func=3D1 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0017, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Da, irq=3D5 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 00002800, size 5, enabled found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0x81 bus=3D0, slot=3D16, func=3D2 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0017, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Db, irq=3D9 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 00002400, size 5, enabled found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0x81 bus=3D0, slot=3D16, func=3D3 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0017, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Db, irq=3D9 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base ed000000, size 8, enabled found-> vendor=3D0x1106, dev=3D0x3104, revid=3D0x86 bus=3D0, slot=3D16, func=3D4 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0017, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Dc, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 found-> vendor=3D0x1106, dev=3D0x3227, revid=3D0x00 bus=3D0, slot=3D17, func=3D0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0087, statreg=3D0x0210, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00002000, size 8, enabled map[14]: type 1, range 32, base ec800000, size 8, enabled found-> vendor=3D0x1106, dev=3D0x3065, revid=3D0x78 bus=3D0, slot=3D18, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0097, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x03 (750 ns), maxlat=3D0x08 = (2000 ns) intpin=3Da, irq=3D5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 00001800, size 8, enabled map[14]: type 1, range 32, base ec000000, size 8, enabled found-> vendor=3D0x10ec, dev=3D0x8169, revid=3D0x10 bus=3D0, slot=3D19, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0017, statreg=3D0x02b0, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x20 (8000 ns), maxlat=3D0x40 = (16000 ns) intpin=3Da, irq=3D12 powerspec 2 supports D0 D1 D2 D3 current D0 agp0: mem = 0xf8000000-0xfbffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xf8000000 agp0: allocating GATT for aperture of size 240M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xdfff pcib1: memory decode 0xee000000-0xefdfffff pcib1: prefetched decode 0xeff00000-0xf7ffffff ACPI PCI link initial configuration: pci1: on pcib1 pci1: physical bus=3D1 map[10]: type 1, range 32, base ee000000, size 24, enabled pcib1: device (null) requested decoded memory range = 0xee000000-0xeeffffff map[14]: type 3, range 32, base f0000000, size 27, enabled pcib1: device (null) requested decoded memory range = 0xf0000000-0xf7ffffff found-> vendor=3D0x10de, dev=3D0x0150, revid=3D0xa3 bus=3D1, slot=3D0, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x02b0, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x05 (1250 ns), = maxlat=3D0x01 (250 ns) intpin=3Da, irq=3D11 powerspec 1 supports D0 D3 current D0 pci1: at device 0.0 (no driver attached) atapci0: port = 0xb400-0xb4ff,0xb800-0xb803,0xd000-0xd007,0xd400-0xd403,0xd800-0xd807 = irq 11 at device 10.0 on pci0 atapci0: Reserved 0x100 bytes for rid 0x20 type 4 at 0xb400 atapci0: [MPSAFE] atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xd800 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xd400 ata2: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata2-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata2-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata2: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata2: at 0xd800 on atapci0 ata2: [MPSAFE] atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xd000 atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb800 ata3: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata3-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata3-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata3: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata3: at 0xd000 on atapci0 ata3: [MPSAFE] atapci1: port = 0x9800-0x98ff,0xa000-0xa003,0xa400-0xa407,0xa800-0xa803,0xb000-0xb007 = irq 11 at device 10.1 on pci0 atapci1: Reserved 0x100 bytes for rid 0x20 type 4 at 0x9800 atapci1: [MPSAFE] atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xb000 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xa800 ata4: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata4-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata4-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata4: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata4: at 0xb000 on atapci1 ata4: [MPSAFE] atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xa400 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xa000 ata5: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata5-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata5-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata5: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata5: at 0xa400 on atapci1 ata5: [MPSAFE] ahc0: port 0x9400-0x94ff mem = 0xed800000-0xed800fff irq 3 at device 12.0 on pci0 ahc0: Defaulting to MEMIO on ahc0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xed800000 ahc0: Reading SEEPROM...done. ahc0: BIOS eeprom is present ahc0: Secondary High byte termination Enabled ahc0: Secondary Low byte termination Enabled ahc0: Primary Low Byte termination Enabled ahc0: Primary High Byte termination Enabled ahc0: Downloading Sequencer Program... 423 instructions downloaded ahc0: Features 0x1def6, Bugs 0x40, Flags 0x20485560 ahc0: [GIANT-LOCKED] aic7892: Ultra160 Wide Channel A, SCSI Id=3D7, 32/253 SCBs atapci2: port = 0x7800-0x78ff,0x8000-0x8003,0x8400-0x8407,0x8800-0x8803,0x9000-0x9007 = irq 10 at device 14.0 on pci0 atapci2: Reserved 0x100 bytes for rid 0x20 type 4 at 0x7800 atapci2: [MPSAFE] atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9000 atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0x8800 ata6: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata6-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata6-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata6: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata6: at 0x9000 on atapci2 ata6: [MPSAFE] atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0x8400 atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0x8000 ata7: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata7-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata7-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata7: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata7: at 0x8400 on atapci2 ata7: [MPSAFE] atapci3: port = 0x6000-0x60ff,0x6400-0x6403,0x6800-0x6807,0x7000-0x7003,0x7400-0x7407 = irq 10 at device 14.1 on pci0 atapci3: Reserved 0x100 bytes for rid 0x20 type 4 at 0x6000 atapci3: [MPSAFE] atapci3: Reserved 0x8 bytes for rid 0x10 type 4 at 0x7400 atapci3: Reserved 0x4 bytes for rid 0x14 type 4 at 0x7000 ata8: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D01 ata8-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata8-slave: stat=3D0x01 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata8: reset tp2 stat0=3D50 stat1=3D01 devices=3D0x1 ata8: at 0x7400 on atapci3 ata8: [MPSAFE] atapci3: Reserved 0x8 bytes for rid 0x18 type 4 at 0x6800 atapci3: Reserved 0x4 bytes for rid 0x1c type 4 at 0x6400 ata9: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 ata9-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata9-slave: stat=3D0x00 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata9: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 ata9: at 0x6800 on atapci3 ata9: [MPSAFE] atapci4: port = 0x4000-0x40ff,0x4400-0x440f,0x4800-0x4803,0x5000-0x5007,0x5400-0x5403,0x5= 800-0x5807 irq 9 at device 15.0 on pci0 atapci4: Reserved 0x10 bytes for rid 0x20 type 4 at 0x4400 atapci4: [MPSAFE] atapci4: Reserved 0x8 bytes for rid 0x10 type 4 at 0x5800 atapci4: Reserved 0x4 bytes for rid 0x14 type 4 at 0x5400 ata10: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D7f ata10-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10: reset tp2 stat0=3D50 stat1=3Dff devices=3D0x1 ata10: at 0x5800 on atapci4 ata10: [MPSAFE] atapci4: Reserved 0x8 bytes for rid 0x18 type 4 at 0x5000 atapci4: Reserved 0x4 bytes for rid 0x1c type 4 at 0x4800 ata11: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D7f ata11-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata11-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11: reset tp2 stat0=3D50 stat1=3Dff devices=3D0x1 ata11: at 0x5000 on atapci4 ata11: [MPSAFE] atapci5: port = 0x3800-0x380f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 14 at device 15.1 = on pci0 atapci5: Reserved 0x10 bytes for rid 0x20 type 4 at 0x3800 atapci5: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci5: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata0-master: stat=3D0x90 err=3D0x90 lsb=3D0x90 msb=3D0x90 ata0-master: stat=3D0x90 err=3D0x90 lsb=3D0x90 msb=3D0x90 ata0-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata0: at 0x1f0 irq 14 on atapci5 ata0: [MPSAFE] atapci5: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci5: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata1-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata1-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata1: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata1: at 0x170 irq 15 on atapci5 ata1: [MPSAFE] uhci0: port 0x3400-0x341f irq 5 at device = 16.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3400 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x3000-0x301f irq 5 at device = 16.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3000 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x2800-0x281f irq 9 at device = 16.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2800 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x2400-0x241f irq 9 at device = 16.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2400 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xed000000-0xed0000ff irq 11 = at device 16.4 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xed000000 ehci0: [GIANT-LOCKED] ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 ehci_pci_attach: companion usb3 usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 vr0: port 0x2000-0x20ff mem = 0xec800000-0xec8000ff irq 5 at device 18.0 on pci0 vr0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x2000 miibus0: on vr0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: bpf attached vr0: Ethernet address: 00:0e:a6:1f:29:1e vr0: [GIANT-LOCKED] re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x1800 re0: port 0x1800-0x18ff mem = 0xec000000-0xec0000ff irq 12 at device 19.0 on pci0 miibus1: on re0 rgephy0: on miibus1 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, = 1000baseTX-FDX, auto re0: bpf attached re0: Ethernet address: 00:50:fc:f8:c6:81 re0: [GIANT-LOCKED] fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on = acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 unknown: not probed (disabled) sio0: irq maps: 0xc041 0xc051 0xc041 0xc041 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console unknown: not probed (disabled) unknown: not probed (disabled) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x1d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it sio: sio0 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcafff on isa0 pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x100> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0xc041 0xc041 0xc041 0xc041 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 54 80=20 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 54 80=20 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 54 80=20 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 1999782501 Hz quality 800 Timecounters tick every 1.000 msec DUMMYNET initialized (011031) ipfw2 initialized, divert enabled, rule-based forwarding enabled, = default to accept, logging unlimited lo0: bpf attached ata0-slave: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ata0-master: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ata0-master: setting PIO4 on VIA 8237 chip ata0-master: setting UDMA100 on VIA 8237 chip ata0-slave: setting PIO4 on VIA 8237 chip ata0-slave: setting UDMA100 on VIA 8237 chip ad0: ATA-6 disk at ata0-master ad0: 114473MB (234441648 sectors), 232581 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA100 GEOM: new disk ad0 ar: FreeBSD check1 failed [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:234436482 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 32256 length 120031478784 end 120031511039 ad1: ATA-6 disk at ata0-slave ad1: 114473MB (234441648 sectors), 232581 C, 16 H, 63 S, 512 B ad1: 16 secs/int, 1 depth queue, UDMA100 ar: FreeBSD check1 failed GEOM: Configure ad0s1a, start 0 length 536870912 end 536870911 GEOM: Configure ad0s1b, start 536870912 length 536870912 end 1073741823 GEOM: Configure ad0s1c, start 0 length 120031478784 end 120031478783 GEOM: Configure ad0s1d, start 1073741824 length 536870912 end 1610612735 GEOM: Configure ad0s1e, start 1610612736 length 536870912 end 2147483647 GEOM: Configure ad0s1f, start 2147483648 length 10737418240 end = 12884901887 GEOM: Configure ad0s1g, start 12884901888 length 107146576896 end = 120031478783 GEOM: new disk ad1 ata1-slave: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ata1-master: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ata1-master: setting PIO4 on VIA 8237 chip ata1-master: setting UDMA100 on VIA 8237 chip ata1-slave: setting PIO4 on VIA 8237 chip ata1-slave: setting UDMA100 on VIA 8237 chip ad2: ATA-6 disk at ata1-master ad2: 117800MB (241254720 sectors), 239340 C, 16 H, 63 S, 512 B ad2: 16 secs/int, 1 depth queue, UDMA100 ar: FreeBSD check1 failed ad3: ATA-6 disk at ata1-slave ad3: 117800MB (241254720 sectors), 239340 C, 16 H, 63 S, 512 B ad3: 16 secs/int, 1 depth queue, UDMA100 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:234436482 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad1s1, start 32256 length 120031478784 end 120031511039 ar: FreeBSD check1 failed GEOM: new disk ad2 GEOM: new disk ad3 GEOM: Configure ad1s1b, start 536870912 length 536870912 end 1073741823 GEOM: Configure ad1s1c, start 0 length 120031478784 end 120031478783 GEOM: Configure ad1s1d, start 0 length 536870912 end 536870911 GEOM: Configure ad1s1e, start 1073741824 length 536870912 end 1610612735 GEOM: Configure ad1s1f, start 1610612736 length 536870912 end 2147483647 GEOM: Configure ad1s1g, start 2147483648 length 10737418240 end = 12884901887 GEOM: Configure ad1s1h, start 12884901888 length 107146576896 end = 120031478783 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:241248042 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad2s1, start 32256 length 123518997504 end 123519029759 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:241248042 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad3s1, start 32256 length 123518997504 end 123519029759 GEOM: Configure ad2s1c, start 0 length 123518997504 end 123518997503 GEOM: Configure ad2s1e, start 0 length 123518997504 end 123518997503 GEOM: Configure ad3s1c, start 0 length 123518997504 end 123518997503 GEOM: Configure ad3s1e, start 0 length 123518997504 end 123518997503 ata2-slave: FAILURE - ATA_IDENTIFY no interrupt ata2-slave: FAILURE - ATA_IDENTIFY no interrupt ata2-master: FAILURE - ATA_IDENTIFY no interrupt ata2-master: FAILURE - ATA_IDENTIFY no interrupt ata3-slave: FAILURE - ATA_IDENTIFY no interrupt ata3-slave: FAILURE - ATA_IDENTIFY no interrupt ata3-master: FAILURE - ATA_IDENTIFY no interrupt ata3-master: FAILURE - ATA_IDENTIFY no interrupt ata4-slave: FAILURE - ATA_IDENTIFY no interrupt ata4-slave: FAILURE - ATA_IDENTIFY no interrupt ata4-master: FAILURE - ATA_IDENTIFY no interrupt ata4-master: FAILURE - ATA_IDENTIFY no interrupt ata5-slave: FAILURE - ATA_IDENTIFY no interrupt ata5-slave: FAILURE - ATA_IDENTIFY no interrupt ata5-master: FAILURE - ATA_IDENTIFY no interrupt ata5-master: FAILURE - ATA_IDENTIFY no interrupt ata6-slave: FAILURE - ATA_IDENTIFY no interrupt ata6-slave: FAILURE - ATA_IDENTIFY no interrupt ata6-master: FAILURE - ATA_IDENTIFY no interrupt ata6-master: FAILURE - ATA_IDENTIFY no interrupt ata7-slave: FAILURE - ATA_IDENTIFY no interrupt ata7-slave: FAILURE - ATA_IDENTIFY no interrupt ata7-master: FAILURE - ATA_IDENTIFY no interrupt ata7-master: FAILURE - ATA_IDENTIFY no interrupt ata8-master: FAILURE - ATA_IDENTIFY no interrupt ata8-master: FAILURE - ATA_IDENTIFY no interrupt ata9-master: FAILURE - ATA_IDENTIFY no interrupt ata9-master: FAILURE - ATA_IDENTIFY no interrupt ata10-master: FAILURE - ATA_IDENTIFY no interrupt ata10-master: FAILURE - ATA_IDENTIFY no interrupt Waiting 5 seconds for SCSI devices to settle (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. ------=_NextPart_000_0000_01C48016.E936E020 Content-Type: text/plain; name="boot_PnP_yes.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="boot_PnP_yes.txt" KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=3D01 base=3D0000000000000000 len=3D000000000009d000 SMAP type=3D02 base=3D000000000009d000 len=3D0000000000003000 SMAP type=3D02 base=3D00000000000f0000 len=3D0000000000010000 SMAP type=3D01 base=3D0000000000100000 len=3D000000004fefb000 SMAP type=3D03 base=3D000000004fffb000 len=3D0000000000004000 SMAP type=3D04 base=3D000000004ffff000 len=3D0000000000001000 SMAP type=3D02 base=3D00000000fec00000 len=3D0000000000001000 SMAP type=3D02 base=3D00000000fee00000 len=3D0000000000001000 SMAP type=3D02 base=3D00000000ffff0000 len=3D0000000000010000 Copyright (c) 1992-2004 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 5.2-CURRENT #2: Thu Aug 12 01:23:35 CEST 2004 daniel@fortify.satra.zapto.org:/usr/obj/usr/src/sys/FORTIFY Preloaded elf kernel "/boot/kernel/kernel" at 0xc089b000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc089b254. Calibrating clock(s) ... i8254 clock: 1193214 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1999782321 Hz CPU: AMD Athlon(TM) XP 2500+ (1999.78-MHz 686-class CPU) Origin =3D "AuthenticAMD" Id =3D 0x6a0 Stepping =3D 0 = Features=3D0x383fbff AMD Features=3D0xc0400000 Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way = associative L2 internal cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 8-way = associative real memory =3D 1342156800 (1279 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009cfff, 638976 bytes (156 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c26000 - 0x000000004e94afff, 1305628672 bytes (318757 pages) avail memory =3D 1305075712 (1244 MB) Table 'FACP' at 0x4fffb0b2 Table 'BOOT' at 0x4fffb030 Table 'APIC' at 0x4fffb058 MADT: Found table at 0x4fffb058 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled ACPI APIC Table: bios32: Found BIOS32 Service Directory header at 0xc00f2000 bios32: Entry =3D 0xf1940 (c00f1940) Rev =3D 0 Len =3D 1 pcibios: PCI BIOS entry at 0xf0000+0x1970 pnpbios: Found PnP BIOS data at 0xc00f9cb0 pnpbios: Entry =3D f0000:9ce0 Rev =3D 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: intr override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: active-high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00040010 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff mem: Pentium Pro MTRR support enabled null: random: io: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [GIANT-LOCKED] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000060 pci_open(1a): mode1res=3D0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=3D060000] [hdr=3D00] is there = (id=3D31891106) pcibios: BIOS version 2.10 Found $PIR table, 11 entries at 0xc00f1f20 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs slot 1 0 12 A 0x05 3 4 5 7 9 10 11 12 slot 1 0 12 B 0x01 3 4 5 7 9 10 11 12 slot 1 0 12 C 0x02 3 4 5 7 9 10 11 12 slot 1 0 12 D 0x03 3 4 5 7 9 10 11 12 slot 2 0 13 A 0x01 3 4 5 7 9 10 11 12 slot 2 0 13 B 0x02 3 4 5 7 9 10 11 12 slot 2 0 13 C 0x03 3 4 5 7 9 10 11 12 slot 2 0 13 D 0x05 3 4 5 7 9 10 11 12 slot 3 0 14 A 0x02 3 4 5 7 9 10 11 12 slot 3 0 14 B 0x03 3 4 5 7 9 10 11 12 slot 3 0 14 C 0x05 3 4 5 7 9 10 11 12 slot 3 0 14 D 0x01 3 4 5 7 9 10 11 12 slot 4 0 19 A 0x03 3 4 5 7 9 10 11 12 slot 4 0 19 B 0x05 3 4 5 7 9 10 11 12 slot 4 0 19 C 0x01 3 4 5 7 9 10 11 12 slot 4 0 19 D 0x02 3 4 5 7 9 10 11 12 slot 5 0 11 A 0x05 3 4 5 7 9 10 11 12 slot 5 0 11 B 0x01 3 4 5 7 9 10 11 12 slot 5 0 11 C 0x02 3 4 5 7 9 10 11 12 slot 5 0 11 D 0x03 3 4 5 7 9 10 11 12 slot 6 0 10 A 0x01 3 4 5 7 9 10 11 12 slot 6 0 10 B 0x02 3 4 5 7 9 10 11 12 slot 6 0 10 C 0x03 3 4 5 7 9 10 11 12 slot 6 0 10 D 0x05 3 4 5 7 9 10 11 12 slot 7 1 0 A 0x01 3 4 5 7 9 10 11 12 slot 7 1 0 B 0x02 3 4 5 7 9 10 11 12 embedded 0 15 A 0x06 3 4 5 7 9 10 11 12 embedded 0 15 B 0x07 3 4 5 7 9 10 11 12 embedded 0 16 A 0x06 3 4 5 7 9 10 11 12 embedded 0 16 B 0x07 3 4 5 7 9 10 11 12 embedded 0 16 C 0x08 3 4 5 7 9 10 11 12 embedded 0 16 D 0x09 3 4 5 7 9 10 11 12 embedded 0 17 C 0x08 3 4 5 7 9 10 11 12 embedded 0 17 D 0x09 3 4 5 7 9 10 11 12 embedded 0 18 A 0x06 3 4 5 7 9 10 11 12 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 17 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 17 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 15 func 0 acpi0: Power Button (fixed) acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 18 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 2 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 3 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 4 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 5 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 unknown: not probed (disabled) unknown: not probed (disabled) cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: pci0: on pcib0 pci0: physical bus=3D0 map[10]: type 3, range 32, base f8000000, size 26, enabled found-> vendor=3D0x1106, dev=3D0x3189, revid=3D0x80 bus=3D0, slot=3D0, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x2230, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) powerspec 2 supports D0 D3 current D0 found-> vendor=3D0x1106, dev=3D0xb198, revid=3D0x00 bus=3D0, slot=3D1, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x2230, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x08 (2000 ns), maxlat=3D0x00 = (0 ns) map[10]: type 4, range 32, base 0000d800, size 3, enabled map[14]: type 4, range 32, base 0000d400, size 2, enabled map[18]: type 4, range 32, base 0000d000, size 3, enabled map[1c]: type 4, range 32, base 0000b800, size 2, enabled map[20]: type 4, range 32, base 0000b400, size 8, enabled found-> vendor=3D0x1103, dev=3D0x0008, revid=3D0x07 bus=3D0, slot=3D10, func=3D0 class=3D01-04-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0230, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x08 (2000 ns), = maxlat=3D0x08 (2000 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000b000, size 3, enabled map[14]: type 4, range 32, base 0000a800, size 2, enabled map[18]: type 4, range 32, base 0000a400, size 3, enabled map[1c]: type 4, range 32, base 0000a000, size 2, enabled map[20]: type 4, range 32, base 00009800, size 8, enabled found-> vendor=3D0x1103, dev=3D0x0008, revid=3D0x07 bus=3D0, slot=3D10, func=3D1 class=3D01-04-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0230, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x08 (2000 ns), = maxlat=3D0x08 (2000 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00009400, size 8, enabled map[14]: type 1, range 64, base ed800000, size 12, enabled found-> vendor=3D0x9005, dev=3D0x0080, revid=3D0x02 bus=3D0, slot=3D12, func=3D0 class=3D01-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0017, statreg=3D0x02b0, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x28 (10000 ns), = maxlat=3D0x19 (6250 ns) intpin=3Da, irq=3D3 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00009000, size 3, enabled map[14]: type 4, range 32, base 00008800, size 2, enabled map[18]: type 4, range 32, base 00008400, size 3, enabled map[1c]: type 4, range 32, base 00008000, size 2, enabled map[20]: type 4, range 32, base 00007800, size 8, enabled found-> vendor=3D0x1103, dev=3D0x0008, revid=3D0x07 bus=3D0, slot=3D14, func=3D0 class=3D01-04-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0230, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x08 (2000 ns), = maxlat=3D0x08 (2000 ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00007400, size 3, enabled map[14]: type 4, range 32, base 00007000, size 2, enabled map[18]: type 4, range 32, base 00006800, size 3, enabled map[1c]: type 4, range 32, base 00006400, size 2, enabled map[20]: type 4, range 32, base 00006000, size 8, enabled found-> vendor=3D0x1103, dev=3D0x0008, revid=3D0x07 bus=3D0, slot=3D14, func=3D1 class=3D01-04-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0230, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x08 (2000 ns), = maxlat=3D0x08 (2000 ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00005800, size 3, enabled map[14]: type 4, range 32, base 00005400, size 2, enabled map[18]: type 4, range 32, base 00005000, size 3, enabled map[1c]: type 4, range 32, base 00004800, size 2, enabled map[20]: type 4, range 32, base 00004400, size 4, enabled map[24]: type 4, range 32, base 00004000, size 8, enabled found-> vendor=3D0x1106, dev=3D0x3149, revid=3D0x80 bus=3D0, slot=3D15, func=3D0 class=3D01-04-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Db, irq=3D9 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 00003800, size 4, enabled found-> vendor=3D0x1106, dev=3D0x0571, revid=3D0x06 bus=3D0, slot=3D15, func=3D1 class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Da, irq=3D14 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 00003400, size 5, enabled found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0x81 bus=3D0, slot=3D16, func=3D0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0017, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Da, irq=3D5 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 00003000, size 5, enabled found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0x81 bus=3D0, slot=3D16, func=3D1 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0017, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Da, irq=3D5 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 00002800, size 5, enabled found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0x81 bus=3D0, slot=3D16, func=3D2 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0017, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Db, irq=3D9 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 00002400, size 5, enabled found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0x81 bus=3D0, slot=3D16, func=3D3 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0017, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Db, irq=3D9 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base ed000000, size 8, enabled found-> vendor=3D0x1106, dev=3D0x3104, revid=3D0x86 bus=3D0, slot=3D16, func=3D4 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0017, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Dc, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 found-> vendor=3D0x1106, dev=3D0x3227, revid=3D0x00 bus=3D0, slot=3D17, func=3D0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0087, statreg=3D0x0210, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00002000, size 8, enabled map[14]: type 1, range 32, base ec800000, size 8, enabled found-> vendor=3D0x1106, dev=3D0x3065, revid=3D0x78 bus=3D0, slot=3D18, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0097, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x03 (750 ns), maxlat=3D0x08 = (2000 ns) intpin=3Da, irq=3D5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 00001800, size 8, port disabled map[14]: type 1, range 32, base ec000000, size 8, memory = disabled found-> vendor=3D0x10ec, dev=3D0x8169, revid=3D0x10 bus=3D0, slot=3D19, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0014, statreg=3D0x02b0, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x20 (8000 ns), maxlat=3D0x40 = (16000 ns) intpin=3Da, irq=3D255 powerspec 2 supports D0 D1 D2 D3 current D0 agp0: mem = 0xf8000000-0xfbffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xf8000000 agp0: allocating GATT for aperture of size 240M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xdfff pcib1: memory decode 0xee000000-0xefdfffff pcib1: prefetched decode 0xeff00000-0xf7ffffff ACPI PCI link initial configuration: pci1: on pcib1 pci1: physical bus=3D1 map[10]: type 1, range 32, base ee000000, size 24, enabled pcib1: device (null) requested decoded memory range = 0xee000000-0xeeffffff map[14]: type 3, range 32, base f0000000, size 27, enabled pcib1: device (null) requested decoded memory range = 0xf0000000-0xf7ffffff found-> vendor=3D0x10de, dev=3D0x0150, revid=3D0xa3 bus=3D1, slot=3D0, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x02b0, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x05 (1250 ns), = maxlat=3D0x01 (250 ns) intpin=3Da, irq=3D11 powerspec 1 supports D0 D3 current D0 pci1: at device 0.0 (no driver attached) atapci0: port = 0xb400-0xb4ff,0xb800-0xb803,0xd000-0xd007,0xd400-0xd403,0xd800-0xd807 = irq 11 at device 10.0 on pci0 atapci0: Reserved 0x100 bytes for rid 0x20 type 4 at 0xb400 atapci0: [MPSAFE] atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xd800 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xd400 ata2: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata2-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata2-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata2: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata2: at 0xd800 on atapci0 ata2: [MPSAFE] atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xd000 atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb800 ata3: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata3-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata3-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata3: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata3: at 0xd000 on atapci0 ata3: [MPSAFE] atapci1: port = 0x9800-0x98ff,0xa000-0xa003,0xa400-0xa407,0xa800-0xa803,0xb000-0xb007 = irq 11 at device 10.1 on pci0 atapci1: Reserved 0x100 bytes for rid 0x20 type 4 at 0x9800 atapci1: [MPSAFE] atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xb000 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xa800 ata4: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata4-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata4-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata4: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata4: at 0xb000 on atapci1 ata4: [MPSAFE] atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xa400 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xa000 ata5: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata5-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata5-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata5: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata5: at 0xa400 on atapci1 ata5: [MPSAFE] ahc0: port 0x9400-0x94ff mem = 0xed800000-0xed800fff irq 3 at device 12.0 on pci0 ahc0: Defaulting to MEMIO on ahc0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xed800000 ahc0: Reading SEEPROM...done. ahc0: BIOS eeprom is present ahc0: Secondary High byte termination Enabled ahc0: Secondary Low byte termination Enabled ahc0: Primary Low Byte termination Enabled ahc0: Primary High Byte termination Enabled ahc0: Downloading Sequencer Program... 423 instructions downloaded ahc0: Features 0x1def6, Bugs 0x40, Flags 0x20485560 ahc0: [GIANT-LOCKED] aic7892: Ultra160 Wide Channel A, SCSI Id=3D7, 32/253 SCBs atapci2: port = 0x7800-0x78ff,0x8000-0x8003,0x8400-0x8407,0x8800-0x8803,0x9000-0x9007 = irq 10 at device 14.0 on pci0 atapci2: Reserved 0x100 bytes for rid 0x20 type 4 at 0x7800 atapci2: [MPSAFE] atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9000 atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0x8800 ata6: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata6-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata6-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata6: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata6: at 0x9000 on atapci2 ata6: [MPSAFE] atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0x8400 atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0x8000 ata7: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata7-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata7-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata7: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata7: at 0x8400 on atapci2 ata7: [MPSAFE] atapci3: port = 0x6000-0x60ff,0x6400-0x6403,0x6800-0x6807,0x7000-0x7003,0x7400-0x7407 = irq 10 at device 14.1 on pci0 atapci3: Reserved 0x100 bytes for rid 0x20 type 4 at 0x6000 atapci3: [MPSAFE] atapci3: Reserved 0x8 bytes for rid 0x10 type 4 at 0x7400 atapci3: Reserved 0x4 bytes for rid 0x14 type 4 at 0x7000 ata8: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D01 ata8-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata8-slave: stat=3D0x01 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata8: reset tp2 stat0=3D50 stat1=3D01 devices=3D0x1 ata8: at 0x7400 on atapci3 ata8: [MPSAFE] atapci3: Reserved 0x8 bytes for rid 0x18 type 4 at 0x6800 atapci3: Reserved 0x4 bytes for rid 0x1c type 4 at 0x6400 ata9: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 ata9-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata9-slave: stat=3D0x00 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata9: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 ata9: at 0x6800 on atapci3 ata9: [MPSAFE] atapci4: port = 0x4000-0x40ff,0x4400-0x440f,0x4800-0x4803,0x5000-0x5007,0x5400-0x5403,0x5= 800-0x5807 irq 9 at device 15.0 on pci0 atapci4: Reserved 0x10 bytes for rid 0x20 type 4 at 0x4400 atapci4: [MPSAFE] atapci4: Reserved 0x8 bytes for rid 0x10 type 4 at 0x5800 atapci4: Reserved 0x4 bytes for rid 0x14 type 4 at 0x5400 ata10: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D7f ata10-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10: reset tp2 stat0=3D50 stat1=3Dff devices=3D0x1 ata10: at 0x5800 on atapci4 ata10: [MPSAFE] atapci4: Reserved 0x8 bytes for rid 0x18 type 4 at 0x5000 atapci4: Reserved 0x4 bytes for rid 0x1c type 4 at 0x4800 ata11: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D7f ata11-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata11-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11: reset tp2 stat0=3D50 stat1=3Dff devices=3D0x1 ata11: at 0x5000 on atapci4 ata11: [MPSAFE] atapci5: port = 0x3800-0x380f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 14 at device 15.1 = on pci0 atapci5: Reserved 0x10 bytes for rid 0x20 type 4 at 0x3800 atapci5: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci5: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata0-master: stat=3D0x90 err=3D0x90 lsb=3D0x90 msb=3D0x90 ata0-master: stat=3D0x90 err=3D0x90 lsb=3D0x90 msb=3D0x90 ata0-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata0: at 0x1f0 irq 14 on atapci5 ata0: [MPSAFE] atapci5: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci5: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata1-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata1-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata1: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata1: at 0x170 irq 15 on atapci5 ata1: [MPSAFE] uhci0: port 0x3400-0x341f irq 5 at device = 16.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3400 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x3000-0x301f irq 5 at device = 16.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3000 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x2800-0x281f irq 9 at device = 16.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2800 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x2400-0x241f irq 9 at device = 16.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2400 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xed000000-0xed0000ff irq 11 = at device 16.4 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xed000000 ehci0: [GIANT-LOCKED] ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 ehci_pci_attach: companion usb3 usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 vr0: port 0x2000-0x20ff mem = 0xec800000-0xec8000ff irq 5 at device 18.0 on pci0 vr0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x2000 miibus0: on vr0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: bpf attached vr0: Ethernet address: 00:0e:a6:1f:29:1e vr0: [GIANT-LOCKED] re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x1800 re0: port 0x1800-0x18ff mem = 0xec000000-0xec0000ff at device 19.0 on pci0 re0: couldn't map interrupt device_attach: re0 attach returned 6 fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on = acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 unknown: not probed (disabled) sio0: irq maps: 0xc041 0xc051 0xc041 0xc041 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console unknown: not probed (disabled) unknown: not probed (disabled) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x1d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it sio: sio0 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcafff on isa0 pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x100> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0xc041 0xc041 0xc041 0xc041 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 54 80=20 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 54 80=20 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 54 80=20 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 1999782321 Hz quality 800 Timecounters tick every 1.000 msec DUMMYNET initialized (011031) ipfw2 initialized, divert enabled, rule-based forwarding enabled, = default to accept, logging unlimited lo0: bpf attached ata0-slave: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ata0-master: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ata0-master: setting PIO4 on VIA 8237 chip ata0-master: setting UDMA100 on VIA 8237 chip ata0-slave: setting PIO4 on VIA 8237 chip ata0-slave: setting UDMA100 on VIA 8237 chip ad0: ATA-6 disk at ata0-master ad0: 114473MB (234441648 sectors), 232581 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA100 GEOM: new disk ad0 ar: FreeBSD check1 failed [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:234436482 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 32256 length 120031478784 end 120031511039 ad1: ATA-6 disk at ata0-slave ad1: 114473MB (234441648 sectors), 232581 C, 16 H, 63 S, 512 B ad1: 16 secs/int, 1 depth queue, UDMA100 ar: FreeBSD check1 failed GEOM: Configure ad0s1a, start 0 length 536870912 end 536870911 GEOM: Configure ad0s1b, start 536870912 length 536870912 end 1073741823 GEOM: Configure ad0s1c, start 0 length 120031478784 end 120031478783 GEOM: Configure ad0s1d, start 1073741824 length 536870912 end 1610612735 GEOM: Configure ad0s1e, start 1610612736 length 536870912 end 2147483647 GEOM: Configure ad0s1f, start 2147483648 length 10737418240 end = 12884901887 GEOM: Configure ad0s1g, start 12884901888 length 107146576896 end = 120031478783 GEOM: new disk ad1 ata1-slave: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ata1-master: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ata1-master: setting PIO4 on VIA 8237 chip ata1-master: setting UDMA100 on VIA 8237 chip ata1-slave: setting PIO4 on VIA 8237 chip ata1-slave: setting UDMA100 on VIA 8237 chip ad2: ATA-6 disk at ata1-master ad2: 117800MB (241254720 sectors), 239340 C, 16 H, 63 S, 512 B ad2: 16 secs/int, 1 depth queue, UDMA100 ar: FreeBSD check1 failed ad3: ATA-6 disk at ata1-slave ad3: 117800MB (241254720 sectors), 239340 C, 16 H, 63 S, 512 B ad3: 16 secs/int, 1 depth queue, UDMA100 ar: FreeBSD check1 failed [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:234436482 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad1s1, start 32256 length 120031478784 end 120031511039 GEOM: new disk ad2 GEOM: new disk ad3 GEOM: Configure ad1s1b, start 536870912 length 536870912 end 1073741823 GEOM: Configure ad1s1c, start 0 length 120031478784 end 120031478783 GEOM: Configure ad1s1d, start 0 length 536870912 end 536870911 GEOM: Configure ad1s1e, start 1073741824 length 536870912 end 1610612735 GEOM: Configure ad1s1f, start 1610612736 length 536870912 end 2147483647 GEOM: Configure ad1s1g, start 2147483648 length 10737418240 end = 12884901887 GEOM: Configure ad1s1h, start 12884901888 length 107146576896 end = 120031478783 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:241248042 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad2s1, start 32256 length 123518997504 end 123519029759 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:241248042 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad3s1, start 32256 length 123518997504 end 123519029759 GEOM: Configure ad2s1c, start 0 length 123518997504 end 123518997503 GEOM: Configure ad2s1e, start 0 length 123518997504 end 123518997503 GEOM: Configure ad3s1c, start 0 length 123518997504 end 123518997503 GEOM: Configure ad3s1e, start 0 length 123518997504 end 123518997503 ata2-slave: FAILURE - ATA_IDENTIFY no interrupt ata2-slave: FAILURE - ATA_IDENTIFY no interrupt ata2-master: FAILURE - ATA_IDENTIFY no interrupt ata2-master: FAILURE - ATA_IDENTIFY no interrupt ata3-slave: FAILURE - ATA_IDENTIFY no interrupt ata3-slave: FAILURE - ATA_IDENTIFY no interrupt ata3-master: FAILURE - ATA_IDENTIFY no interrupt ata3-master: FAILURE - ATA_IDENTIFY no interrupt ata4-slave: FAILURE - ATA_IDENTIFY no interrupt ata4-slave: FAILURE - ATA_IDENTIFY no interrupt ata4-master: FAILURE - ATA_IDENTIFY no interrupt ata4-master: FAILURE - ATA_IDENTIFY no interrupt ata5-slave: FAILURE - ATA_IDENTIFY no interrupt ata5-slave: FAILURE - ATA_IDENTIFY no interrupt ata5-master: FAILURE - ATA_IDENTIFY no interrupt ata5-master: FAILURE - ATA_IDENTIFY no interrupt ata6-slave: FAILURE - ATA_IDENTIFY no interrupt ata6-slave: FAILURE - ATA_IDENTIFY no interrupt ata6-master: FAILURE - ATA_IDENTIFY no interrupt ata6-master: FAILURE - ATA_IDENTIFY no interrupt ata7-slave: FAILURE - ATA_IDENTIFY no interrupt ata7-slave: FAILURE - ATA_IDENTIFY no interrupt ata7-master: FAILURE - ATA_IDENTIFY no interrupt ata7-master: FAILURE - ATA_IDENTIFY no interrupt ata8-master: FAILURE - ATA_IDENTIFY no interrupt ata8-master: FAILURE - ATA_IDENTIFY no interrupt ata9-master: FAILURE - ATA_IDENTIFY no interrupt ata9-master: FAILURE - ATA_IDENTIFY no interrupt ata10-master: FAILURE - ATA_IDENTIFY no interrupt ata10-master: FAILURE - ATA_IDENTIFY no interrupt Waiting 5 seconds for SCSI devices to settle (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. ------=_NextPart_000_0000_01C48016.E936E020-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 01:11:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EC1B16A4CE; Thu, 12 Aug 2004 01:11:11 +0000 (GMT) Received: from meitner.wh.uni-dortmund.de (meitner.wh.Uni-Dortmund.DE [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id A22BF43D31; Thu, 12 Aug 2004 01:11:10 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id 637331674EA; Thu, 12 Aug 2004 03:11:09 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i7C1B746057719 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 12 Aug 2004 03:11:08 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: freebsd-current@FreeBSD.org, conrads@cox.net Date: Thu, 12 Aug 2004 03:11:05 +0200 User-Agent: KMail/1.6.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_qOsGBGHJPayxoh+"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408120311.06287.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new cc: Don Lewis cc: dnelson@allantgroup.com cc: Rusty Nejdl Subject: Re: Is anything being done re: the pcm timeout issue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 01:11:11 -0000 --Boundary-02=_qOsGBGHJPayxoh+ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 12 August 2004 01:56, Conrad J. Sabatier wrote: > On 11-Aug-2004 Conrad J. Sabatier wrote: > > I do appreciate your looking into this matter. So far, with my > > latest kernel, I haven't experienced the problem yet, either. Which > > doesn't necessarily mean, of course, that I still won't. :-) > > Oh well, it was nice while it lasted. Just did it again. > > I think tomorrow I'm going to try pulling the es1371 card out of my old > machine and see how it works in the amd64 box. Maybe it's just the > chipset/driver. I'd not rule it out, considering what I had to do to get my onboard snd_ich= =20 (different variant though probably, it's onboard a P4 mobo) "working" under= =20 Linux... (with binary volume control (mute - max), no mixers besides master= =20 and defaulting to mute) it seems the matrix of possible chipset variants wi= th=20 this particular ac97-thing is simply too big for a unified driver approach.= =20 =46WIW, my snd_ich works fine on -CURRENT, but i386 of course. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --Boundary-02=_qOsGBGHJPayxoh+ Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBGsOqXhc68WspdLARAoYxAJ9xYj1gtwm8w9y/6NeiiVJp7eMh/wCgk5w2 LRx5zUC6CbbWzAicYx9bWh0= =e3lt -----END PGP SIGNATURE----- --Boundary-02=_qOsGBGHJPayxoh+-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 01:41:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2730016A4CE; Thu, 12 Aug 2004 01:41:31 +0000 (GMT) Received: from lakermmtao06.cox.net (lakermmtao06.cox.net [68.230.240.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9468043D53; Thu, 12 Aug 2004 01:41:30 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.71.51]) by lakermmtao06.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040812014128.EFUA8791.lakermmtao06.cox.net@dolphin.local.net>; Wed, 11 Aug 2004 21:41:28 -0400 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with ESMTP id i7C1fTuc019706; Wed, 11 Aug 2004 20:41:29 -0500 (CDT) (envelope-from conrads@dolphin.local.net) Received: (from conrads@localhost) by dolphin.local.net (8.13.1/8.13.1/Submit) id i7C1fOD4019705; Wed, 11 Aug 2004 20:41:24 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 11 Aug 2004 20:41:24 -0500 (CDT) Organization: A Rag-Tag Band of Drug-Crazed Hippies From: "Conrad J. Sabatier" To: "Conrad J. Sabatier" cc: freebsd-current@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: cvsup on amd64 just broke today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conrads@cox.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2004 01:41:31 -0000 On 10-Aug-2004 Conrad J. Sabatier wrote: > > I hadn't noticed it before, but it does strike me as odd that the > binary package for amd64 would include a file with "i386" in the > name, and which is, in fact, an ELF 32 binary. Did something change > today that would effect the handling of such a file, perhaps? Just realized today while doing another system update that I had somehow deleted "options IA32" from my kernel config. Probably why cvsup suddenly stopped working. :-) My bad. -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 01:50:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80E2016A4D5; Thu, 12 Aug 2004 01:50:22 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5ADCC43D45; Thu, 12 Aug 2004 01:50:20 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 0A9E67A3D2; Wed, 11 Aug 2004 18:50:20 -0700 (PDT) Message-ID: <411ACCDB.9060904@elischer.org> Date: Wed, 11 Aug 2004 18:50:19 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: current@freebsd.org References: <20040808222837.2E72A16A4D3@hub.freebsd.org> <41173194.6020309@elischer.org> <20040811101431.GA11809@rogue.acs-et.com> <411AA2B0.9020900@elischer.org> In-Reply-To: <411AA2B0.9020900@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Daniel Eischen Subject: Re: Code for review.. threads vs. the scheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 01:50:22 -0000 Here is a version of the diff that is pretty much functionaly equivalent to the current system (and almost identical to patches (c) and (d) (*) but it takes it astep further in that teh struct kse has been removed from proc.h and made a private structure within each scheduler. Nothing outside of the 3 files kern/sched_4bsd, kern/sched_ule.c and kern/kern_switch.c (which is now included into the schedulers rather than linked with them) even knows what a struct kse looks like. (*) these patches were not widly distributed. The patch is available at: http://www.freebsd.org/~julian/e.diff At this point each scheduler can be alterred almost completely independently of the other as long as the fields in the kse that are referenced in the common code in kern_switch.c are not renamed or removed. -where to from here.... The next logical step is to move the fields within the thread, and ksegrp structures that reference kses into the scheduler specific extensions to these structures so that not even those references are externally visible. This would make the queues and lists that are used to hang KSEs off also private information for the scheduler, allowing schedulers to have their own private queueing architectures without having to expose them to anything external.. The NEXT step after that is to move all the fields in the KSE structure into the thread's scheduler-private structure (td_sched) and rename it a "kse" to stop the need for massive mechanical renaming. Since every thread has one of these, all the KSE allocation code just vanishes as do the restraints that they hold on code due to locking requirements etc. sched_ule and sched_4bsd don't change much at all. "concurrency control " is switched to use a simple pair of counters. (available slots and total slots (concurrency) per ksegrp. Except for that change, even kern_switch.c remains mostly the same and the KSE structure as we know it has dissappeared entirely (though its name is passed to the td_sched structure for diff-reduction purposes.. when this is done we have a scheduler interface that COMPLETELY hides within it how and where threads are queued, or in fact if they are queued at all.. (A Monte-Carlo scheduler may use a completely different scheme based on probablilistic scheduling..) It should also be a lot more reliable and I suspect that the morphing of the KSE structure into something that is always a part of the thread MIGHT also fix the Preemption hang we've been seeing. Sched-ule and sched-4bsd can then be experimented on a lot more freely without worrying about unintended changes to teh other. Especially if one of the schedulers takes a complete copy of kern_switch.c instead of including it.. Indeed a new scheduler can be added with a single file, and no other edits, allowing people to experiment with their own schedulers much more easily. Julian Elischer wrote: > Here's an "up to date" version.. (version d) > has been seen running thr and kse threaded programs. > > > Mike Makonnen wrote: > >> On Mon, Aug 09, 2004 at 01:11:00AM -0700, Julian Elischer wrote: >> >> >>> regular thread_exit() will do teh job. >>> *** THIS IS NOT FULLLY TESTED*** >>> mtm.. can you see if this still works? I don't have the rignt setup >>> to test it now.. >>> >> >> >> Sure, I can get to it tonight, but it would be a lot easier if >> you could send a patch against the current tree :) >> >> Cheers. >> >> > > From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 16:32:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15A9716A4CE for ; Wed, 11 Aug 2004 16:32:45 +0000 (GMT) Received: from smart.eusc.inter.net (smart.eusc.inter.net [213.73.101.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0E2E43D3F for ; Wed, 11 Aug 2004 16:32:44 +0000 (GMT) (envelope-from msch@snafu.de) Received: from dial-76-181.de.inter.net ([213.73.76.181] helo=current.best-eng.de) by smart.eusc.inter.net with esmtp (Exim 3.36 #4) id 1Buw1r-000630-00; Wed, 11 Aug 2004 18:32:43 +0200 Received: from current.best-eng.de (localhost.best-eng.de [127.0.0.1]) by current.best-eng.de (8.13.1/8.13.1) with ESMTP id i7BGWhgG001045; Wed, 11 Aug 2004 18:32:43 +0200 (CEST) (envelope-from matthias@current.best-eng.de) Received: from localhost (localhost [[UNIX: localhost]]) by current.best-eng.de (8.13.1/8.13.1/Submit) id i7BGWgvN001044; Wed, 11 Aug 2004 18:32:42 +0200 (CEST) (envelope-from matthias) From: Matthias Schuendehuette Organization: Micro$oft-free Zone To: "Mario A. Doria" Date: Wed, 11 Aug 2004 18:32:42 +0200 User-Agent: KMail/1.6.2 References: <200408102356.57524.mariodoria@yahoo.com> In-Reply-To: <200408102356.57524.mariodoria@yahoo.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408111832.42573.msch@snafu.de> X-Mailman-Approved-At: Thu, 12 Aug 2004 01:54:22 +0000 cc: current@freebsd.org Subject: Re: Vinum status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: msch@snafu.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2004 16:32:45 -0000 Hi Mario, On Wednesday 11 August 2004 06:56, Mario A. Doria wrote: > After reading the recent thread, I've got one question. How do you > start up using gvinum instead of vinum? Did you change or add a > /etc/rc.d script? What do I do to start using gvinum instead of > vinum? Either you copy /etc/rc.d/vinum to /etc/rc.d/gvinum and make the necessary changes (mostly :s/vinum/gvinum/g) to this file and to /etc/rc.conf as well - or you load it at boot-time via /boot/loader.conf: "geom_vinum_load="YES" # Set this to YES to load the geom_vinum module" ...works for me in the meantime. -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) PGP-Key at and ID: 0xDDFB0A5F From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 16:45:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C9BF16A4CE for ; Wed, 11 Aug 2004 16:45:09 +0000 (GMT) Received: from web41104.mail.yahoo.com (web41104.mail.yahoo.com [66.218.93.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 3334B43D41 for ; Wed, 11 Aug 2004 16:45:09 +0000 (GMT) (envelope-from jmkatcher@yahoo.com) Message-ID: <20040811164508.74419.qmail@web41104.mail.yahoo.com> Received: from [24.18.54.216] by web41104.mail.yahoo.com via HTTP; Wed, 11 Aug 2004 09:45:08 PDT Date: Wed, 11 Aug 2004 09:45:08 -0700 (PDT) From: Jeffrey Katcher To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 12 Aug 2004 01:54:22 +0000 Subject: Can someone please commit a sane module path in loader.conf? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 16:45:09 -0000 I know I can override it in my local loader.conf, but the change to /boot/modules only was _really_ annoying and unexpected. FYI, it should be /boot/kernel for most people. Thanks, Jeff Katcher From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 17:00:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C4AE16A4D0 for ; Wed, 11 Aug 2004 17:00:03 +0000 (GMT) Received: from anchor-post-35.mail.demon.net (anchor-post-35.mail.demon.net [194.217.242.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C26C443D46 for ; Wed, 11 Aug 2004 17:00:02 +0000 (GMT) (envelope-from tnelson@onresolve.com) Received: from alcyon-home.demon.co.uk ([193.237.184.95] helo=lime) by anchor-post-35.mail.demon.net with esmtp (Exim 3.35 #1) id 1BuwSG-000Jr4-0Z; Wed, 11 Aug 2004 17:00:01 +0000 From: "Trent Nelson" To: , Date: Wed, 11 Aug 2004 17:59:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <18300.12.148.147.242.1092234409.squirrel@[12.148.147.242]> Thread-Index: AcR/r6ZXSzk14IziSWawX4erDmN9cAAFDH4Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-Id: X-Mailman-Approved-At: Thu, 12 Aug 2004 01:54:22 +0000 Subject: RE: Signal 11 compiling qt33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 17:00:03 -0000 > I just received this signal 11 while compiling qt33 on the snapshot from > 8/9 > Would updating my world solve this problem at all for me? This is the > latest (as of this morning) ports. Before everyone jumps in and suggests you have memory problems; I run into this problem every time I compile Qt sources on FreeBSD and I know a lot of other people have too. However, it never fails at the same spot, and I think you'll find if you just type 'make' again, it'll happily continue on from where it died. I typically have to run 'make' about 10-15 times before Qt will completely build. Compiling Qt in general is probably more strenuous on the system than doing a 'make world' due to the nature of their classes and such. I've never seen any problems with my hardware apart from this. I guess there always is the possibility I do have dodgy memory and this is the only thing that is stressing the system enough to make things break. Trent. From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 20:02:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41DF616A4CE for ; Wed, 11 Aug 2004 20:02:52 +0000 (GMT) Received: from smtp.abv.bg (mail07.abv.bg [194.153.145.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 507DA43D39 for ; Wed, 11 Aug 2004 20:02:44 +0000 (GMT) (envelope-from ianchov@gbg.bg) Received: from webmail.gyuvetch.bg (app1.ni.bg [192.168.151.15]) by smtp.abv.bg (Postfix) with SMTP id 2BA0A42C for ; Wed, 11 Aug 2004 23:02:40 +0300 (EEST) Received: (qmail 16962 invoked from network); 11 Aug 2004 20:02:40 -0000 Received: from app1.ni.bg (192.168.151.15) by 0 with SMTP; 11 Aug 2004 20:02:40 -0000 Message-ID: <951675343.1092254560739.JavaMail.nobody@app1.ni.bg> Date: Wed, 11 Aug 2004 23:02:40 +0300 (EEST) From: Iantcho Vassilev To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_15308_624519631.1092254560681" X-Mailer: AbvMail 1.0 X-Originating-IP: 213.240.192.49 X-Mailman-Approved-At: Thu, 12 Aug 2004 01:54:22 +0000 Subject: stage 3: Error in libopcodes.a X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 20:02:52 -0000 ------=_Part_15308_624519631.1092254560681 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit HI! This a part of a error while compiling --- I recompile because yesterday there was a bug in the direver for VIA RHINE:vr0 in if_vr.c:506 i download the lastest if_vr.c(today at 18:00 Sofia) and compiled again only the vr0 driver: but i`coudn`t make it work with the new driver(there weren`t errors but "make load" maded some errors and the kernel used the older code - can you tell me how to make the kernel use a new driver. ---->All log(script) is in the attachement atof-ieee.o bignum-copy.o cond.o dwarf2dbg.o ecoff.o expr.o flonum-copy.o flonum-konst.o flonum-mult.o frags.o hash.o input-file.o input-scrub.o listing.o literal.o macro.o messages.o obj-elf.o output-file.o read.o sb.o stabs.o subsegs.o symbols.o write.o depend.o ehopt.o dw2gencfi.o tc-i386.o ../libbfd/libbfd.a ../libiberty/libiberty.a ../libopcodes/libopcodes.a /usr/obj/usr/src/i386/legacy/usr/lib/libegacy.a -legacy as.o: In function `parse_args': as.o(.text+0x3b8): undefined reference to `getopt_long_only' *** Error code 1 ----------------------------------------------------------------- http://www.elmaz.com/ - Çŕďîçíŕíńňâŕ! ------=_Part_15308_624519631.1092254560681 Content-Type: application/octet-stream; name=newbuild Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=newbuild U2NyaXB0IHN0YXJ0ZWQgb24gV2VkIEF1ZyAxMSAyMTo0Mzo0NSAyMDA0CmlhbmNob3Y6L3Vzci9z cmMjIHRpbWUIIAgIIAgIIAgIIAhleGl0CAgICHVtb3VudCAvbW50LwgICAgICAgICAgICBtbOFBl eGl0CAgICGNwIC9tbnQva2Vybi5wcmUubWsudHh0IC9yb290L2tlcm4ucHJlLm1rDWlhbmNob3Y6 L3Vzci9zcmMjIGNwIC9tbnQvaWZfdnIuYyAvcm9vdC9pZl92ci5jLm1haWJlY2hlMS45Mg0KaWFu Y2hvdjovdXNyL3NyYyMgZXhpdAgICAh1bW91bnQgL21udC8ICAgICAgICAgICAgbWzhQZXhpdAgI CAhjcCAvbW50L2tlcm4ucHJlLm1rLnR4dCAvcm9vdC9rZXJuLnByZS5taw1pYW5jaG92Oi91c3Iv c3JjIyBjcCAvbW50L2lmX3ZyLmMgL3Jvb3QvaWZfdnIuYy5tYWliZWNoZTEuOTINaWFuY2hvdjov dXNyL3NyYyMgG1sxMlBtb3VudF9tc2Rvc2ZzIC9kZXYvYWQwczEgL21udC8NaWFuY2hvdjovdXNy L3NyYyMgG1sxUGN2c3VwIC9yb290L3N0YW5kYXJkLXN1cGZpbGUgDWlhbmNob3Y6L3Vzci9zcmMj IBtbM1BwaW5nIGN2c3VwMi5mci5mcmVlYnNkLm9yZw1pYW5jaG92Oi91c3Ivc3JjIyBlZSAvcm9v dC9zdGFuZGFyZC1zdXBmaWxlIA1pYW5jaG92Oi91c3Ivc3JjIyAbWzNAY3ZzdXAgL3Jvb3Qvc3Rh bmRhcmQtc3VwZmlsZSANCmlhbmNob3Y6L3Vzci9zcmMjIHRpbWUgbWFrZSAtRE5PX1JFU0NVRSBi dWlsZHdvbHJkCCAICCAICCAIcmxkDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gUmVidWlsZGluZyB0aGUgdGVtcG9y YXJ5IGJ1aWxkIHRyZWUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpybSAtcmYgL3Vzci9vYmovdXNyL3NyYy9pMzg2DQpta2Rp ciAtcCAvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9iaW4NCm1rZGlyIC1wIC91c3Iv b2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2dhbWVzDQpta2RpciAtcCAvdXNyL29iai91c3Iv c3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlL2MrKy8zLjMNCm1rZGlyIC1wIC91c3Ivb2JqL3Vz ci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUvc3lzDQpta2RpciAtcCAvdXNyL29iai91c3Iv c3JjL2kzODYvbGVnYWN5L3Vzci9saWINCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9s ZWdhY3kvdXNyL2xpYmV4ZWMNCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kv dXNyL3NiaW4NCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL3NoYXJl L2RpY3QNCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL3NoYXJlL2dy b2ZmX2ZvbnQvZGV2WDEwMA0KbWtkaXIgLXAgL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91 c3Ivc2hhcmUvZ3JvZmZfZm9udC9kZXZYMTAwLTEyDQpta2RpciAtcCAvdXNyL29iai91c3Ivc3Jj L2kzODYvbGVnYWN5L3Vzci9zaGFyZS9ncm9mZl9mb250L2Rldlg3NQ0KbWtkaXIgLXAgL3Vzci9v YmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3Ivc2hhcmUvZ3JvZmZfZm9udC9kZXZYNzUtMTINCm1r ZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL3NoYXJlL2dyb2ZmX2ZvbnQv ZGV2YXNjaWkNCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL3NoYXJl L2dyb2ZmX2ZvbnQvZGV2Y3AxMDQ3DQpta2RpciAtcCAvdXNyL29iai91c3Ivc3JjL2kzODYvbGVn YWN5L3Vzci9zaGFyZS9ncm9mZl9mb250L2RldmR2aQ0KbWtkaXIgLXAgL3Vzci9vYmovdXNyL3Ny Yy9pMzg2L2xlZ2FjeS91c3Ivc2hhcmUvZ3JvZmZfZm9udC9kZXZodG1sDQpta2RpciAtcCAvdXNy L29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9zaGFyZS9ncm9mZl9mb250L2RldmtvaTgtcg0K bWtkaXIgLXAgL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3Ivc2hhcmUvZ3JvZmZfZm9u dC9kZXZsYXRpbjENCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL3No YXJlL2dyb2ZmX2ZvbnQvZGV2bGJwDQpta2RpciAtcCAvdXNyL29iai91c3Ivc3JjL2kzODYvbGVn YWN5L3Vzci9zaGFyZS9ncm9mZl9mb250L2RldmxqNA0KbWtkaXIgLXAgL3Vzci9vYmovdXNyL3Ny Yy9pMzg2L2xlZ2FjeS91c3Ivc2hhcmUvZ3JvZmZfZm9udC9kZXZwcw0KbWtkaXIgLXAgL3Vzci9v YmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3Ivc2hhcmUvZ3JvZmZfZm9udC9kZXZ1dGY4DQpta2Rp ciAtcCAvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9zaGFyZS90bWFjL21kb2MNCm1r ZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL3NoYXJlL3RtYWMvbW0NCm1r ZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9saWINCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9z cmMvaTM4Ni91c3IvYmluDQpta2RpciAtcCAvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL2luY2x1 ZGUNCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3IvbGliL2NvbXBhdC9hb3V0DQpt a2RpciAtcCAvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL2xpYmRhdGEvbGRzY3JpcHRzDQpta2Rp ciAtcCAvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL2xpYmV4ZWMNCm1rZGlyIC1wIC91c3Ivb2Jq L3Vzci9zcmMvaTM4Ni91c3Ivc2Jpbg0KbWtkaXIgLXAgL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vz ci9zaGFyZS9taXNjDQpta2RpciAtcCAvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NoYXJlL3Nu bXAvZGVmcw0KbWtkaXIgLXAgL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zaGFyZS9zbm1wL21p YnMNCm10cmVlIC1kZVUgLWYgL3Vzci9zcmMvZXRjL210cmVlL0JTRC5pbmNsdWRlLmRpc3QgIC1w IC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3IvaW5jbHVkZSA+L2Rldi9udWxsDQpsbiAtc2YgL3Vz ci9zcmMvc3lzIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ng0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IHN0YWdlIDEuMTog bGVnYWN5IHJlbGVhc2UgY29tcGF0aWJpbGl0eSBzaGltcw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmNkIC91c3Ivc3JjOyBN QUtFT0JKRElSUFJFRklYPS91c3Ivb2JqL3Vzci9zcmMvaTM4NiAgREVTVERJUj0gIElOU1RBTEw9 InNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2giICBQQVRIPS91c3Ivb2JqL3Vzci9zcmMvaTM4 Ni9sZWdhY3kvdXNyL3NiaW46L3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvYmluOi91 c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2dhbWVzOi9zYmluOi9iaW46L3Vzci9zYmlu Oi91c3IvYmluICBXT1JMRFRNUD0vdXNyL29iai91c3Ivc3JjL2kzODYgIE1BS0VGTEFHUz0iLW0g L3Vzci9zcmMvdG9vbHMvYnVpbGQvbWsgIC1EIE5PX1JFU0NVRSAtbSAvdXNyL3NyYy9zaGFyZS9t ayAiIC91c3Ivb2JqL3Vzci9zcmMvbWFrZS5pMzg2L21ha2UgLWYgTWFrZWZpbGUuaW5jMSAgQk9P VFNUUkFQUElORz01MDIxMjggIC1ETk9IVE1MIC1ETk9JTkZPIC1ETk9MSU5UIC1ETk9NQU4gLURO T1BJQyAtRE5PUFJPRklMRSAgLUROT1NIQVJFRCAtRE5PX0NQVV9DRkxBR1MgLUROT19XQVJOUyBs ZWdhY3kNCj09PT4gdG9vbHMvYnVpbGQNCi91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL3Rv b2xzL2J1aWxkIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Rvb2xzL2J1aWxkDQpjZCAvdXNyL3NyYy90 b29scy9idWlsZDsgL3Vzci9vYmovdXNyL3NyYy9tYWtlLmkzODYvbWFrZSBidWlsZGluY2x1ZGVz OyAvdXNyL29iai91c3Ivc3JjL21ha2UuaTM4Ni9tYWtlIGluc3RhbGxpbmNsdWRlcw0Kcm0gLWYg LmRlcGVuZA0KbWtkZXAgLWYgLmRlcGVuZCAtYSAgICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9s ZWdhY3kvdXNyL2luY2x1ZGUgL3Vzci9zcmMvdG9vbHMvYnVpbGQvZHVtbXkuYw0KY2MgLU8gLXBp cGUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3Ny Yy90b29scy9idWlsZC9kdW1teS5jDQpidWlsZGluZyBzdGF0aWMgZWdhY3kgbGlicmFyeQ0KcmFu bGliIGxpYmVnYWN5LmENCnNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2ggLUMgLW8gcm9vdCAt ZyB3aGVlbCAtbSA0NDQgICBsaWJlZ2FjeS5hIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kv dXNyL2xpYg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPj4+IHN0YWdlIDEuMjogYm9vdHN0cmFwIHRvb2xzDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Y2QgL3Vzci9zcmM7IE1BS0VPQkpESVJQUkVGSVg9L3Vzci9vYmovdXNyL3NyYy9pMzg2ICBERVNU RElSPSAgSU5TVEFMTD0ic2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCIgIFBBVEg9L3Vzci9v YmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3Ivc2JpbjovdXNyL29iai91c3Ivc3JjL2kzODYvbGVn YWN5L3Vzci9iaW46L3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvZ2FtZXM6L3NiaW46 L2JpbjovdXNyL3NiaW46L3Vzci9iaW4gIFdPUkxEVE1QPS91c3Ivb2JqL3Vzci9zcmMvaTM4NiAg TUFLRUZMQUdTPSItbSAvdXNyL3NyYy90b29scy9idWlsZC9tayAgLUQgTk9fUkVTQ1VFIC1tIC91 c3Ivc3JjL3NoYXJlL21rICIgL3Vzci9vYmovdXNyL3NyYy9tYWtlLmkzODYvbWFrZSAtZiBNYWtl ZmlsZS5pbmMxICBCT09UU1RSQVBQSU5HPTUwMjEyOCAgLUROT0hUTUwgLUROT0lORk8gLUROT0xJ TlQgLUROT01BTiAtRE5PUElDIC1ETk9QUk9GSUxFICAtRE5PU0hBUkVEIC1ETk9fQ1BVX0NGTEFH UyAtRE5PX1dBUk5TIGJvb3RzdHJhcC10b29scw0KPT09PiBnbnUvdXNyLmJpbi9ncGVyZg0KL3Vz ci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYgY3JlYXRlZCBmb3Ig L3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYNCj09PT4gZ251L3Vzci5iaW4vZ3BlcmYvZG9jDQov dXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi9kb2MgY3JlYXRl ZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYvZG9jDQpybSAtZiAuZGVwZW5kDQpta2Rl cCAtZiAuZGVwZW5kIC1hICAgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5j bHVkZSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmLy4uLy4uLy4uL2NvbnRyaWIvZ3BlcmYv bGliIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYgIC91c3Ivc3JjL2dudS91c3IuYmluL2dw ZXJmLy4uLy4uLy4uL2NvbnRyaWIvZ3BlcmYvc3JjL2Jvb2wtYXJyYXkuY2MgL3Vzci9zcmMvZ251 L3Vzci5iaW4vZ3BlcmYvLi4vLi4vLi4vY29udHJpYi9ncGVyZi9zcmMvZ2VuLXBlcmYuY2MgL3Vz ci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYvLi4vLi4vLi4vY29udHJpYi9ncGVyZi9zcmMvaGFzaC10 YWJsZS5jYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8uLi8uLi9jb250cmliL2dwZXJm L3NyYy9pdGVyYXRvci5jYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8uLi8uLi9jb250 cmliL2dwZXJmL3NyYy9rZXktbGlzdC5jYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8u Li8uLi9jb250cmliL2dwZXJmL3NyYy9saXN0LW5vZGUuY2MgL3Vzci9zcmMvZ251L3Vzci5iaW4v Z3BlcmYvLi4vLi4vLi4vY29udHJpYi9ncGVyZi9zcmMvbWFpbi5jYyAvdXNyL3NyYy9nbnUvdXNy LmJpbi9ncGVyZi8uLi8uLi8uLi9jb250cmliL2dwZXJmL3NyYy9uZXcuY2MgL3Vzci9zcmMvZ251 L3Vzci5iaW4vZ3BlcmYvLi4vLi4vLi4vY29udHJpYi9ncGVyZi9zcmMvb3B0aW9ucy5jYyAvdXNy L3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8uLi8uLi9jb250cmliL2dwZXJmL3NyYy9yZWFkLWxp bmUuY2MgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYvLi4vLi4vLi4vY29udHJpYi9ncGVyZi9z cmMvdHJhY2UuY2MgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYvLi4vLi4vLi4vY29udHJpYi9n cGVyZi9zcmMvdmVjdG9ycy5jYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8uLi8uLi9j b250cmliL2dwZXJmL3NyYy92ZXJzaW9uLmNjIC91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmLy4u Ly4uLy4uL2NvbnRyaWIvZ3BlcmYvbGliL2hhc2guY2MgICANCmVjaG8gZ3BlcmY6IC91c3IvbGli L2xpYmMuYSAvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9saWIvbGliZWdhY3kuYSA+ PiAuZGVwZW5kDQplY2hvIGdwZXJmOiAvdXNyL2xpYi9saWJzdGRjKysuYSA+PiAuZGVwZW5kDQo9 PT0+IGdudS91c3IuYmluL2dwZXJmL2RvYw0KYysrIC1PIC1waXBlIC1JL3Vzci9vYmovdXNyL3Ny Yy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmLy4u Ly4uLy4uL2NvbnRyaWIvZ3BlcmYvbGliIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYgLWMg L3Vzci9zcmMvY29udHJpYi9ncGVyZi9zcmMvYm9vbC1hcnJheS5jYw0KYysrIC1PIC1waXBlIC1J L3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2dwZXJmLy4uLy4uLy4uL2NvbnRyaWIvZ3BlcmYvbGliIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vZ3BlcmYgLWMgL3Vzci9zcmMvY29udHJpYi9ncGVyZi9zcmMvZ2VuLXBlcmYuY2MNCmMr KyAtTyAtcGlwZSAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8uLi8uLi9jb250cmliL2dwZXJmL2xpYiAtSS91 c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmIC1jIC91c3Ivc3JjL2NvbnRyaWIvZ3BlcmYvc3JjL2hh c2gtdGFibGUuY2MNCmMrKyAtTyAtcGlwZSAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kv dXNyL2luY2x1ZGUgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8uLi8uLi9jb250cmli L2dwZXJmL2xpYiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmIC1jIC91c3Ivc3JjL2NvbnRy aWIvZ3BlcmYvc3JjL2l0ZXJhdG9yLmNjDQpjKysgLU8gLXBpcGUgLUkvdXNyL29iai91c3Ivc3Jj L2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYvLi4v Li4vLi4vY29udHJpYi9ncGVyZi9saWIgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZiAtYyAv dXNyL3NyYy9jb250cmliL2dwZXJmL3NyYy9rZXktbGlzdC5jYw0KYysrIC1PIC1waXBlIC1JL3Vz ci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2dwZXJmLy4uLy4uLy4uL2NvbnRyaWIvZ3BlcmYvbGliIC1JL3Vzci9zcmMvZ251L3Vzci5i aW4vZ3BlcmYgLWMgL3Vzci9zcmMvY29udHJpYi9ncGVyZi9zcmMvbGlzdC1ub2RlLmNjDQpjKysg LU8gLXBpcGUgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1JL3Vz ci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYvLi4vLi4vLi4vY29udHJpYi9ncGVyZi9saWIgLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9ncGVyZiAtYyAvdXNyL3NyYy9jb250cmliL2dwZXJmL3NyYy9tYWlu LmNjDQpjKysgLU8gLXBpcGUgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNs dWRlIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYvLi4vLi4vLi4vY29udHJpYi9ncGVyZi9s aWIgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZiAtYyAvdXNyL3NyYy9jb250cmliL2dwZXJm L3NyYy9uZXcuY2MNCmMrKyAtTyAtcGlwZSAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kv dXNyL2luY2x1ZGUgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8uLi8uLi9jb250cmli L2dwZXJmL2xpYiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmIC1jIC91c3Ivc3JjL2NvbnRy aWIvZ3BlcmYvc3JjL29wdGlvbnMuY2MNCmMrKyAtTyAtcGlwZSAtSS91c3Ivb2JqL3Vzci9zcmMv aTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8u Li8uLi9jb250cmliL2dwZXJmL2xpYiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmIC1jIC91 c3Ivc3JjL2NvbnRyaWIvZ3BlcmYvc3JjL3JlYWQtbGluZS5jYw0KYysrIC1PIC1waXBlIC1JL3Vz ci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2dwZXJmLy4uLy4uLy4uL2NvbnRyaWIvZ3BlcmYvbGliIC1JL3Vzci9zcmMvZ251L3Vzci5i aW4vZ3BlcmYgLWMgL3Vzci9zcmMvY29udHJpYi9ncGVyZi9zcmMvdHJhY2UuY2MNCmMrKyAtTyAt cGlwZSAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8uLi8uLi9jb250cmliL2dwZXJmL2xpYiAtSS91c3Ivc3Jj L2dudS91c3IuYmluL2dwZXJmIC1jIC91c3Ivc3JjL2NvbnRyaWIvZ3BlcmYvc3JjL3ZlY3RvcnMu Y2MNCmMrKyAtTyAtcGlwZSAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1 ZGUgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8uLi8uLi9jb250cmliL2dwZXJmL2xp YiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmIC1jIC91c3Ivc3JjL2NvbnRyaWIvZ3BlcmYv c3JjL3ZlcnNpb24uY2MNCmMrKyAtTyAtcGlwZSAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdh Y3kvdXNyL2luY2x1ZGUgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8uLi8uLi9jb250 cmliL2dwZXJmL2xpYiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmIC1jIC91c3Ivc3JjL2Nv bnRyaWIvZ3BlcmYvbGliL2hhc2guY2MNCmMrKyAtTyAtcGlwZSAtSS91c3Ivb2JqL3Vzci9zcmMv aTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8u Li8uLi9jb250cmliL2dwZXJmL2xpYiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmICAtc3Rh dGljIC1ML3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvbGliIC1vIGdwZXJmIGJvb2wt YXJyYXkubyBnZW4tcGVyZi5vIGhhc2gtdGFibGUubyBpdGVyYXRvci5vIGtleS1saXN0Lm8gbGlz dC1ub2RlLm8gbWFpbi5vIG5ldy5vIG9wdGlvbnMubyByZWFkLWxpbmUubyB0cmFjZS5vIHZlY3Rv cnMubyB2ZXJzaW9uLm8gaGFzaC5vIC1sZWdhY3kNCj09PT4gZ251L3Vzci5iaW4vZ3BlcmYvZG9j DQpzaCAvdXNyL3NyYy90b29scy9pbnN0YWxsLnNoIC1zIC1vIHJvb3QgLWcgd2hlZWwgLW0gNTU1 ICAgZ3BlcmYgL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvYmluDQo9PT0+IGdudS91 c3IuYmluL2dwZXJmL2RvYw0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi90bWFjDQovdXNyL29iai91 c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi90bWFjIGNyZWF0ZWQgZm9yIC91 c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3RtYWMNCnNlZCAtZiAvdXNyL3NyYy9nbnUvdXNyLmJp bi9ncm9mZi90bWFjLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ3JvZmYvdG1hYy9zdHJpcC5zZWQgL3Vz ci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvdG1hYy8uLi8uLi8uLi8uLi9jb250cmliL2dyb2ZmL3Rt YWMvZG9jLWNvbW1vbiA+IGRvYy1jb21tb24tcw0Kc2VkIC1mIC91c3Ivc3JjL2dudS91c3IuYmlu L2dyb2ZmL3RtYWMvLi4vLi4vLi4vLi4vY29udHJpYi9ncm9mZi90bWFjL3N0cmlwLnNlZCAvdXNy L3NyYy9nbnUvdXNyLmJpbi9ncm9mZi90bWFjLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ3JvZmYvdG1h Yy9kb2MtZGl0cm9mZiA+IGRvYy1kaXRyb2ZmLXMNCnNlZCAtZiAvdXNyL3NyYy9nbnUvdXNyLmJp bi9ncm9mZi90bWFjLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ3JvZmYvdG1hYy9zdHJpcC5zZWQgL3Vz ci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvdG1hYy8uLi8uLi8uLi8uLi9jb250cmliL2dyb2ZmL3Rt YWMvZG9jLW5yb2ZmID4gZG9jLW5yb2ZmLXMNCnNlZCAtZiAvdXNyL3NyYy9nbnUvdXNyLmJpbi9n cm9mZi90bWFjLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ3JvZmYvdG1hYy9zdHJpcC5zZWQgL3Vzci9z cmMvZ251L3Vzci5iaW4vZ3JvZmYvdG1hYy8uLi8uLi8uLi8uLi9jb250cmliL2dyb2ZmL3RtYWMv ZG9jLXN5bXMgPiBkb2Mtc3ltcy1zDQpzZWQgLWYgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYv dG1hYy8uLi8uLi8uLi8uLi9jb250cmliL2dyb2ZmL3RtYWMvc3RyaXAuc2VkIC91c3Ivc3JjL2du dS91c3IuYmluL2dyb2ZmL3RtYWMvZnIuSVNPODg1OS0xID4gZnIuSVNPODg1OS0xLXMNCnNlZCAt ZiAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi90bWFjLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ3Jv ZmYvdG1hYy9zdHJpcC5zZWQgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvdG1hYy9ydS5LT0k4 LVIgPiBydS5LT0k4LVItcw0Kc2VkIC1mIC91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3RtYWMv Li4vLi4vLi4vLi4vY29udHJpYi9ncm9mZi90bWFjL3N0cmlwLnNlZCAvdXNyL3NyYy9nbnUvdXNy LmJpbi9ncm9mZi90bWFjLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ3JvZmYvdG1hYy9lLnRtYWMgPiBl LnRtYWMtcw0Kc2VkIC1mIC91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3RtYWMvLi4vLi4vLi4v Li4vY29udHJpYi9ncm9mZi90bWFjL3N0cmlwLnNlZCAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9m Zi90bWFjLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ3JvZmYvdG1hYy9kb2MudG1hYyA+IGRvYy50bWFj LXMNCnNlZCAtZiAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi90bWFjLy4uLy4uLy4uLy4uL2Nv bnRyaWIvZ3JvZmYvdG1hYy9zdHJpcC5zZWQgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvdG1h Yy9tZG9jLmxvY2FsID4gbWRvYy5sb2NhbC1zDQpzZWQgLWUgInM7QFRNQUNfQU5fUFJFRklYQDs7 ZyIgIC1lICJzO0BUTUFDX1NfUFJFRklYQDs7ZyIgIC1lICJzO0BQTk1UT1BTX05PU0VUUEFHRUA7 cG5tdG9wcztnIiAgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvdG1hYy8uLi8uLi8uLi8uLi9j b250cmliL2dyb2ZmL3RtYWMvYW4udG1hYyA+IGFuLnRtYWMtcw0Kc2VkIC1lICJzO0BUTUFDX0FO X1BSRUZJWEA7O2ciICAtZSAicztAVE1BQ19TX1BSRUZJWEA7O2ciICAtZSAicztAUE5NVE9QU19O T1NFVFBBR0VAO3BubXRvcHM7ZyIgIC91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3RtYWMvLi4v Li4vLi4vLi4vY29udHJpYi9ncm9mZi90bWFjL21hbi50bWFjID4gbWFuLnRtYWMtcw0Kc2VkIC1l ICJzO0BUTUFDX0FOX1BSRUZJWEA7O2ciICAtZSAicztAVE1BQ19TX1BSRUZJWEA7O2ciICAtZSAi cztAUE5NVE9QU19OT1NFVFBBR0VAO3BubXRvcHM7ZyIgIC91c3Ivc3JjL2dudS91c3IuYmluL2dy b2ZmL3RtYWMvLi4vLi4vLi4vLi4vY29udHJpYi9ncm9mZi90bWFjL3MudG1hYyA+IHMudG1hYy1z DQpzZWQgLWUgInM7QFRNQUNfQU5fUFJFRklYQDs7ZyIgIC1lICJzO0BUTUFDX1NfUFJFRklYQDs7 ZyIgIC1lICJzO0BQTk1UT1BTX05PU0VUUEFHRUA7cG5tdG9wcztnIiAgL3Vzci9zcmMvZ251L3Vz ci5iaW4vZ3JvZmYvdG1hYy8uLi8uLi8uLi8uLi9jb250cmliL2dyb2ZmL3RtYWMvbXMudG1hYyA+ IG1zLnRtYWMtcw0Kc2VkIC1lICJzO0BUTUFDX0FOX1BSRUZJWEA7O2ciICAtZSAicztAVE1BQ19T X1BSRUZJWEA7O2ciICAtZSAicztAUE5NVE9QU19OT1NFVFBBR0VAO3BubXRvcHM7ZyIgIC91c3Iv c3JjL2dudS91c3IuYmluL2dyb2ZmL3RtYWMvLi4vLi4vLi4vLi4vY29udHJpYi9ncm9mZi90bWFj L3d3dy50bWFjID4gd3d3LnRtYWMtcw0KY2QgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvdG1h Yy8uLi8uLi8uLi8uLi9jb250cmliL2dyb2ZmL3RtYWM7ICBzaCAvdXNyL3NyYy90b29scy9pbnN0 YWxsLnNoIC1vIHJvb3QgLWcgd2hlZWwgLW0gNDQ0ICBtYW5kb2MudG1hYyBhbmRvYy50bWFjIGFu LW9sZC50bWFjICBtZS50bWFjICBtZG9jLnRtYWMgIHBpYy50bWFjICBhNC50bWFjICBwYXBlcnNp emUudG1hYyAgZWMudG1hYyAgc2FmZXIudG1hYyAgdHJhY2UudG1hYyAgcHMudG1hYyBwc29sZC50 bWFjIHBzcGljLnRtYWMgcHNhdGsudG1hYyAgZHZpLnRtYWMgIHR0eS50bWFjIHR0eS1jaGFyLnRt YWMgIGxhdGluMS50bWFjIGxhdGluMi50bWFjIGxhdGluOS50bWFjIGNwMTA0Ny50bWFjICBYLnRt YWMgWHBzLnRtYWMgIGxqNC50bWFjICBsYnAudG1hYyAgaHRtbC50bWFjIGh0bWwtZW5kLnRtYWMg IGV1cm9wcy50bWFjICBjb21wb3NpdGUudG1hYyAgZXFucmMgIHRyb2ZmcmMgdHJvZmZyYy1lbmQg IGh5cGhlbi51cyBoeXBoZW5leC51cyAvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9z aGFyZS90bWFjDQpjZCAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi90bWFjOyAgc2ggL3Vzci9z cmMvdG9vbHMvaW5zdGFsbC5zaCAtbyByb290IC1nIHdoZWVsIC1tIDQ0NCAga29pOC1yLnRtYWMg aHlwaGVuLnJ1IC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL3NoYXJlL3RtYWMNCmNk IC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3RtYWMNCnNo IC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2ggLW8gcm9vdCAtZyB3aGVlbCAtbSA0NDQgIGUudG1h Yy1zIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL3NoYXJlL3RtYWMvZS50bWFjDQpz aCAvdXNyL3NyYy90b29scy9pbnN0YWxsLnNoIC1vIHJvb3QgLWcgd2hlZWwgLW0gNDQ0ICBkb2Mu dG1hYy1zIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL3NoYXJlL3RtYWMvZG9jLnRt YWMNCnNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2ggLW8gcm9vdCAtZyB3aGVlbCAtbSA0NDQg IG1kb2MubG9jYWwtcyAvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9zaGFyZS90bWFj L21kb2MubG9jYWwNCnNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2ggLW8gcm9vdCAtZyB3aGVl bCAtbSA0NDQgIGFuLnRtYWMtcyAvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9zaGFy ZS90bWFjL2FuLnRtYWMNCnNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2ggLW8gcm9vdCAtZyB3 aGVlbCAtbSA0NDQgIG1hbi50bWFjLXMgL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3Iv c2hhcmUvdG1hYy9tYW4udG1hYw0Kc2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCAtbyByb290 IC1nIHdoZWVsIC1tIDQ0NCAgcy50bWFjLXMgL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91 c3Ivc2hhcmUvdG1hYy9zLnRtYWMNCnNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2ggLW8gcm9v dCAtZyB3aGVlbCAtbSA0NDQgIG1zLnRtYWMtcyAvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5 L3Vzci9zaGFyZS90bWFjL21zLnRtYWMNCnNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2ggLW8g cm9vdCAtZyB3aGVlbCAtbSA0NDQgIHd3dy50bWFjLXMgL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xl Z2FjeS91c3Ivc2hhcmUvdG1hYy93d3cudG1hYw0Kc2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5z aCAtbyByb290IC1nIHdoZWVsIC1tIDQ0NCAgZG9jLWNvbW1vbi1zIC91c3Ivb2JqL3Vzci9zcmMv aTM4Ni9sZWdhY3kvdXNyL3NoYXJlL3RtYWMvbWRvYy9kb2MtY29tbW9uDQpzaCAvdXNyL3NyYy90 b29scy9pbnN0YWxsLnNoIC1vIHJvb3QgLWcgd2hlZWwgLW0gNDQ0ICBkb2MtZGl0cm9mZi1zIC91 c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL3NoYXJlL3RtYWMvbWRvYy9kb2MtZGl0cm9m Zg0Kc2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCAtbyByb290IC1nIHdoZWVsIC1tIDQ0NCAg ZG9jLW5yb2ZmLXMgL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3Ivc2hhcmUvdG1hYy9t ZG9jL2RvYy1ucm9mZg0Kc2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCAtbyByb290IC1nIHdo ZWVsIC1tIDQ0NCAgZG9jLXN5bXMtcyAvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9z aGFyZS90bWFjL21kb2MvZG9jLXN5bXMNCnNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2ggLW8g cm9vdCAtZyB3aGVlbCAtbSA0NDQgIGZyLklTTzg4NTktMS1zIC91c3Ivb2JqL3Vzci9zcmMvaTM4 Ni9sZWdhY3kvdXNyL3NoYXJlL3RtYWMvbWRvYy9mci5JU084ODU5LTENCnNoIC91c3Ivc3JjL3Rv b2xzL2luc3RhbGwuc2ggLW8gcm9vdCAtZyB3aGVlbCAtbSA0NDQgIHJ1LktPSTgtUi1zIC91c3Iv b2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL3NoYXJlL3RtYWMvbWRvYy9ydS5LT0k4LVINCnNo IC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2ggLW8gcm9vdCAtZyB3aGVlbCAtbSA0NDQgIC91c3Iv c3JjL2dudS91c3IuYmluL2dyb2ZmL3RtYWMvLi4vLi4vLi4vLi4vY29udHJpYi9ncm9mZi90bWFj L21hbi5sb2NhbCAvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9zaGFyZS90bWFjDQo9 PT0+IGdudS91c3IuYmluL3RleGluZm8NCj09PT4gZ251L3Vzci5iaW4vdGV4aW5mby9saWJ0eGkN Ci91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vbGlidHhp IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vbGlidHhpDQo9PT0+IGdu dS91c3IuYmluL3RleGluZm8vbWFrZWluZm8NCi91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3Jj L2dudS91c3IuYmluL3RleGluZm8vbWFrZWluZm8gY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vz ci5iaW4vdGV4aW5mby9tYWtlaW5mbw0KPT09PiBnbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8NCi91 c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5mbyBjcmVh dGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8NCj09PT4gZ251L3Vzci5i aW4vdGV4aW5mby9pbmZva2V5DQovdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNy LmJpbi90ZXhpbmZvL2luZm9rZXkgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4 aW5mby9pbmZva2V5DQo9PT0+IGdudS91c3IuYmluL3RleGluZm8vaW5zdGFsbC1pbmZvDQovdXNy L29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luc3RhbGwtaW5m byBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luc3RhbGwtaW5mbw0K PT09PiBnbnUvdXNyLmJpbi90ZXhpbmZvL3RleGluZGV4DQovdXNyL29iai91c3Ivc3JjL2kzODYv dXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL3RleGluZGV4IGNyZWF0ZWQgZm9yIC91c3Ivc3Jj L2dudS91c3IuYmluL3RleGluZm8vdGV4aW5kZXgNCj09PT4gZ251L3Vzci5iaW4vdGV4aW5mby9k b2MNCi91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vZG9j IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vZG9jDQo9PT0+IGdudS91 c3IuYmluL3RleGluZm8vbGlidHhpDQpybSAtZiAuZGVwZW5kDQpta2RlcCAtZiAuZGVwZW5kIC1h ICAgIC1ESEFWRV9DT05GSUdfSCAtRExPQ0FMRURJUj1cIi91c3Ivc2hhcmUvbG9jYWxlXCIgLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2xpYnR4aS8uLi8uLi8uLi8uLi9jb250cmliL3Rl eGluZm8gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2xpYnR4aS8uLi8uLi8uLi8uLi9j b250cmliL3RleGluZm8vbGliIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5j bHVkZSAvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2xpYnR4aS8uLi8uLi8uLi8uLi9jb250 cmliL3RleGluZm8vbGliL3N1YnN0cmluZy5jIC91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8v bGlidHhpLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9saWIveGV4aXQuYyAvdXNyL3NyYy9n bnUvdXNyLmJpbi90ZXhpbmZvL2xpYnR4aS8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8vbGli L3htYWxsb2MuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2xpYnR4aS8uLi8uLi8uLi8u Li9jb250cmliL3RleGluZm8vbGliL3hzdHJkdXAuYw0KPT09PiBnbnUvdXNyLmJpbi90ZXhpbmZv L21ha2VpbmZvDQpybSAtZiAuZGVwZW5kDQpta2RlcCAtZiAuZGVwZW5kIC1hICAgIC1ESEFWRV9D T05GSUdfSCAtRExPQ0FMRURJUj1cIi91c3Ivc2hhcmUvbG9jYWxlXCIgLUkvdXNyL3NyYy9nbnUv dXNyLmJpbi90ZXhpbmZvL21ha2VpbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mbyAtSS91 c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vbWFrZWluZm8vLi4vLi4vLi4vLi4vY29udHJpYi90 ZXhpbmZvL2xpYiAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgL3Vz ci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9tYWtlaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3Rl eGluZm8vbWFrZWluZm8vY21kcy5jIC91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vbWFrZWlu Zm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL21ha2VpbmZvL2RlZnVuLmMgL3Vzci9zcmMv Z251L3Vzci5iaW4vdGV4aW5mby9tYWtlaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8v bWFrZWluZm8vZmlsZXMuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL21ha2VpbmZvLy4u Ly4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9tYWtlaW5mby9mb290bm90ZS5jIC91c3Ivc3JjL2du dS91c3IuYmluL3RleGluZm8vbWFrZWluZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL21h a2VpbmZvL2h0bWwuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL21ha2VpbmZvLy4uLy4u Ly4uLy4uL2NvbnRyaWIvdGV4aW5mby9tYWtlaW5mby9pbmRleC5jIC91c3Ivc3JjL2dudS91c3Iu YmluL3RleGluZm8vbWFrZWluZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL21ha2VpbmZv L2luc2VydGlvbi5jIC91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vbWFrZWluZm8vLi4vLi4v Li4vLi4vY29udHJpYi90ZXhpbmZvL21ha2VpbmZvL2xhbmcuYyAvdXNyL3NyYy9nbnUvdXNyLmJp bi90ZXhpbmZvL21ha2VpbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9tYWtlaW5mby9t YWNyby5jIC91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vbWFrZWluZm8vLi4vLi4vLi4vLi4v Y29udHJpYi90ZXhpbmZvL21ha2VpbmZvL21ha2VpbmZvLmMgL3Vzci9zcmMvZ251L3Vzci5iaW4v dGV4aW5mby9tYWtlaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8vbWFrZWluZm8vbXVs dGkuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL21ha2VpbmZvLy4uLy4uLy4uLy4uL2Nv bnRyaWIvdGV4aW5mby9tYWtlaW5mby9ub2RlLmMgL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5m by9tYWtlaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8vbWFrZWluZm8vc2VjdGlvbmlu Zy5jIC91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vbWFrZWluZm8vLi4vLi4vLi4vLi4vY29u dHJpYi90ZXhpbmZvL21ha2VpbmZvL3RvYy5jIC91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8v bWFrZWluZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL21ha2VpbmZvL3htbC5jDQplY2hv IG1ha2VpbmZvOiAvdXNyL2xpYi9saWJjLmEgL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMv Z251L3Vzci5iaW4vdGV4aW5mby9tYWtlaW5mby8uLi9saWJ0eGkvbGlidHhpLmEgL3Vzci9vYmov dXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvbGliL2xpYmVnYWN5LmEgPj4gLmRlcGVuZA0KPT09PiBn bnUvdXNyLmJpbi90ZXhpbmZvL2luZm8NCnJtIC1mIC5kZXBlbmQNCm1rZGVwIC1mIC5kZXBlbmQg LWEgICAgLURJTkZPRElSPVwiL3Vzci9zaGFyZS9pbmZvOi91c3IvbG9jYWwvaW5mbzovdXNyL1gx MVI2L2luZm86LlwiIC1ESEFWRV9DT05GSUdfSCAtRExPQ0FMRURJUj1cIi91c3Ivc2hhcmUvbG9j YWxlXCIgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29u dHJpYi90ZXhpbmZvIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9pbmZvLy4uLy4uLy4u Ly4uL2NvbnRyaWIvdGV4aW5mby9saWIgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vz ci9pbmNsdWRlIC91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5mby8uLi8uLi8uLi8uLi9j b250cmliL3RleGluZm8vaW5mby9kaXIuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2lu Zm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2luZm8vZGlzcGxheS5jIC91c3Ivc3JjL2du dS91c3IuYmluL3RleGluZm8vaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8vaW5mby9k b2MuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29udHJp Yi90ZXhpbmZvL2luZm8vZHJpYmJsZS5jIC91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5m by8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8vaW5mby9lY2hvLWFyZWEuYyAvdXNyL3NyYy9n bnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2luZm8v ZmlsZXN5cy5jIC91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5mby8uLi8uLi8uLi8uLi9j b250cmliL3RleGluZm8vaW5mby9mb290bm90ZXMuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhp bmZvL2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2luZm8vZ2MuYyAvdXNyL3NyYy9n bnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2luZm8v aW5kaWNlcy5jIC91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5mby8uLi8uLi8uLi8uLi9j b250cmliL3RleGluZm8vaW5mby9pbmZvLXV0aWxzLmMgL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4 aW5mby9pbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9pbmZvL2luZm8uYyAvdXNyL3Ny Yy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2lu Zm8vaW5mb2RvYy5jIC91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5mby8uLi8uLi8uLi8u Li9jb250cmliL3RleGluZm8vaW5mby9pbmZvbWFwLmMgL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4 aW5mby9pbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9pbmZvL20teC5jIC91c3Ivc3Jj L2dudS91c3IuYmluL3RleGluZm8vaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8vaW5m by9tYW4uYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29u dHJpYi90ZXhpbmZvL2luZm8vbm9kZW1lbnUuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZv L2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2luZm8vbm9kZXMuYyAvdXNyL3NyYy9n bnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2luZm8v c2VhcmNoLmMgL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9pbmZvLy4uLy4uLy4uLy4uL2Nv bnRyaWIvdGV4aW5mby9pbmZvL3Nlc3Npb24uYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZv L2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2luZm8vc2lnbmFscy5jIC91c3Ivc3Jj L2dudS91c3IuYmluL3RleGluZm8vaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8vaW5m by90ZXJtaW5hbC5jIC91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5mby8uLi8uLi8uLi8u Li9jb250cmliL3RleGluZm8vaW5mby90aWxkZS5jIC91c3Ivc3JjL2dudS91c3IuYmluL3RleGlu Zm8vaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8vaW5mby92YXJpYWJsZXMuYyAvdXNy L3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZv L2luZm8vd2luZG93LmMNCmVjaG8gaW5mbzogL3Vzci9saWIvbGliYy5hIC91c3IvbGliL2xpYnRl cm1jYXAuYSAvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZv L2luZm8vLi4vbGlidHhpL2xpYnR4aS5hIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNy L2xpYi9saWJlZ2FjeS5hID4+IC5kZXBlbmQNCj09PT4gZ251L3Vzci5iaW4vdGV4aW5mby9pbmZv a2V5DQpybSAtZiAuZGVwZW5kDQpta2RlcCAtZiAuZGVwZW5kIC1hICAgIC1ESEFWRV9DT05GSUdf SCAtRExPQ0FMRURJUj1cIi91c3Ivc2hhcmUvbG9jYWxlXCIgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi90ZXhpbmZvL2luZm9rZXkvLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvIC1JL3Vzci9zcmMv Z251L3Vzci5iaW4vdGV4aW5mby9pbmZva2V5Ly4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9s aWIgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC91c3Ivc3JjL2du dS91c3IuYmluL3RleGluZm8vaW5mb2tleS8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8vaW5m by9pbmZva2V5LmMgL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9pbmZva2V5Ly4uLy4uLy4u Ly4uL2NvbnRyaWIvdGV4aW5mby9pbmZvL2tleS5jDQplY2hvIGluZm9rZXk6IC91c3IvbGliL2xp YmMuYSAvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2lu Zm9rZXkvLi4vbGlidHhpL2xpYnR4aS5hIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNy L2xpYi9saWJlZ2FjeS5hID4+IC5kZXBlbmQNCj09PT4gZ251L3Vzci5iaW4vdGV4aW5mby9pbnN0 YWxsLWluZm8NCnJtIC1mIC5kZXBlbmQNCm1rZGVwIC1mIC5kZXBlbmQgLWEgICAgLURIQVZFX0NP TkZJR19IIC1ETE9DQUxFRElSPVwiL3Vzci9zaGFyZS9sb2NhbGVcIiAtSS91c3Ivc3JjL2dudS91 c3IuYmluL3RleGluZm8vaW5zdGFsbC1pbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mbyAt SS91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5zdGFsbC1pbmZvLy4uLy4uLy4uLy4uL2Nv bnRyaWIvdGV4aW5mby9saWIgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNs dWRlIC91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5zdGFsbC1pbmZvLy4uLy4uLy4uLy4u L2NvbnRyaWIvdGV4aW5mby91dGlsL2luc3RhbGwtaW5mby5jDQplY2hvIGluc3RhbGwtaW5mbzog L3Vzci9saWIvbGliYy5hIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmlu L3RleGluZm8vaW5zdGFsbC1pbmZvLy4uL2xpYnR4aS9saWJ0eGkuYSAvdXNyL29iai91c3Ivc3Jj L2kzODYvbGVnYWN5L3Vzci9saWIvbGliZWdhY3kuYSA+PiAuZGVwZW5kDQo9PT0+IGdudS91c3Iu YmluL3RleGluZm8vdGV4aW5kZXgNCnJtIC1mIC5kZXBlbmQNCm1rZGVwIC1mIC5kZXBlbmQgLWEg ICAgLURIQVZFX0NPTkZJR19IIC1ETE9DQUxFRElSPVwiL3Vzci9zaGFyZS9sb2NhbGVcIiAtSS91 c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vdGV4aW5kZXgvLi4vLi4vLi4vLi4vY29udHJpYi90 ZXhpbmZvIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby90ZXhpbmRleC8uLi8uLi8uLi8u Li9jb250cmliL3RleGluZm8vbGliIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3Iv aW5jbHVkZSAvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL3RleGluZGV4Ly4uLy4uLy4uLy4u L2NvbnRyaWIvdGV4aW5mby91dGlsL3RleGluZGV4LmMNCmVjaG8gdGV4aW5kZXg6IC91c3IvbGli L2xpYmMuYSAvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZv L3RleGluZGV4Ly4uL2xpYnR4aS9saWJ0eGkuYSAvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5 L3Vzci9saWIvbGliZWdhY3kuYSA+PiAuZGVwZW5kDQo9PT0+IGdudS91c3IuYmluL3RleGluZm8v ZG9jDQo9PT0+IGdudS91c3IuYmluL3RleGluZm8vbGlidHhpDQpjYyAtTyAtcGlwZSAtREhBVkVf Q09ORklHX0ggLURMT0NBTEVESVI9XCIvdXNyL3NoYXJlL2xvY2FsZVwiICAtSS91c3Ivc3JjL2du dS91c3IuYmluL3RleGluZm8vbGlidHhpLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mbyAtSS91 c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vbGlidHhpLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4 aW5mby9saWIgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAv dXNyL3NyYy9jb250cmliL3RleGluZm8vbGliL3N1YnN0cmluZy5jDQpjYyAtTyAtcGlwZSAtREhB VkVfQ09ORklHX0ggLURMT0NBTEVESVI9XCIvdXNyL3NoYXJlL2xvY2FsZVwiICAtSS91c3Ivc3Jj L2dudS91c3IuYmluL3RleGluZm8vbGlidHhpLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mbyAt SS91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vbGlidHhpLy4uLy4uLy4uLy4uL2NvbnRyaWIv dGV4aW5mby9saWIgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAt YyAvdXNyL3NyYy9jb250cmliL3RleGluZm8vbGliL3hleGl0LmMNCmNjIC1PIC1waXBlIC1ESEFW RV9DT05GSUdfSCAtRExPQ0FMRURJUj1cIi91c3Ivc2hhcmUvbG9jYWxlXCIgIC1JL3Vzci9zcmMv Z251L3Vzci5iaW4vdGV4aW5mby9saWJ0eGkvLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9saWJ0eGkvLi4vLi4vLi4vLi4vY29udHJpYi90 ZXhpbmZvL2xpYiAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1j IC91c3Ivc3JjL2NvbnRyaWIvdGV4aW5mby9saWIveG1hbGxvYy5jDQpjYyAtTyAtcGlwZSAtREhB VkVfQ09ORklHX0ggLURMT0NBTEVESVI9XCIvdXNyL3NoYXJlL2xvY2FsZVwiICAtSS91c3Ivc3Jj L2dudS91c3IuYmluL3RleGluZm8vbGlidHhpLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mbyAt SS91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vbGlidHhpLy4uLy4uLy4uLy4uL2NvbnRyaWIv dGV4aW5mby9saWIgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAt YyAvdXNyL3NyYy9jb250cmliL3RleGluZm8vbGliL3hzdHJkdXAuYw0KYnVpbGRpbmcgc3RhdGlj IHR4aSBsaWJyYXJ5DQpyYW5saWIgbGlidHhpLmENCj09PT4gZ251L3Vzci5iaW4vdGV4aW5mby9t YWtlaW5mbw0KY2MgLU8gLXBpcGUgLURIQVZFX0NPTkZJR19IIC1ETE9DQUxFRElSPVwiL3Vzci9z aGFyZS9sb2NhbGVcIiAgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL21ha2VpbmZvLy4u Ly4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mbyAtSS91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8v bWFrZWluZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2xpYiAgLUkvdXNyL29iai91c3Iv c3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvdGV4aW5mby9t YWtlaW5mby9jbWRzLmMNCmNjIC1PIC1waXBlIC1ESEFWRV9DT05GSUdfSCAtRExPQ0FMRURJUj1c Ii91c3Ivc2hhcmUvbG9jYWxlXCIgIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9tYWtl aW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90 ZXhpbmZvL21ha2VpbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9saWIgIC1JL3Vzci9v YmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL3Rl eGluZm8vbWFrZWluZm8vZGVmdW4uYw0KY2MgLU8gLXBpcGUgLURIQVZFX0NPTkZJR19IIC1ETE9D QUxFRElSPVwiL3Vzci9zaGFyZS9sb2NhbGVcIiAgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhp bmZvL21ha2VpbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mbyAtSS91c3Ivc3JjL2dudS91 c3IuYmluL3RleGluZm8vbWFrZWluZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2xpYiAg LUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2Nv bnRyaWIvdGV4aW5mby9tYWtlaW5mby9maWxlcy5jDQpjYyAtTyAtcGlwZSAtREhBVkVfQ09ORklH X0ggLURMT0NBTEVESVI9XCIvdXNyL3NoYXJlL2xvY2FsZVwiICAtSS91c3Ivc3JjL2dudS91c3Iu YmluL3RleGluZm8vbWFrZWluZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvIC1JL3Vzci9z cmMvZ251L3Vzci5iaW4vdGV4aW5mby9tYWtlaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGlu Zm8vbGliICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vz ci9zcmMvY29udHJpYi90ZXhpbmZvL21ha2VpbmZvL2Zvb3Rub3RlLmMNCmNjIC1PIC1waXBlIC1E SEFWRV9DT05GSUdfSCAtRExPQ0FMRURJUj1cIi91c3Ivc2hhcmUvbG9jYWxlXCIgIC1JL3Vzci9z cmMvZ251L3Vzci5iaW4vdGV4aW5mby9tYWtlaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGlu Zm8gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL21ha2VpbmZvLy4uLy4uLy4uLy4uL2Nv bnRyaWIvdGV4aW5mby9saWIgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5j bHVkZSAtYyAvdXNyL3NyYy9jb250cmliL3RleGluZm8vbWFrZWluZm8vaHRtbC5jDQpjYyAtTyAt cGlwZSAtREhBVkVfQ09ORklHX0ggLURMT0NBTEVESVI9XCIvdXNyL3NoYXJlL2xvY2FsZVwiICAt SS91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vbWFrZWluZm8vLi4vLi4vLi4vLi4vY29udHJp Yi90ZXhpbmZvIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9tYWtlaW5mby8uLi8uLi8u Li8uLi9jb250cmliL3RleGluZm8vbGliICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kv dXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi90ZXhpbmZvL21ha2VpbmZvL2luZGV4LmMN CmNjIC1PIC1waXBlIC1ESEFWRV9DT05GSUdfSCAtRExPQ0FMRURJUj1cIi91c3Ivc2hhcmUvbG9j YWxlXCIgIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9tYWtlaW5mby8uLi8uLi8uLi8u Li9jb250cmliL3RleGluZm8gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL21ha2VpbmZv Ly4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9saWIgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2 L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL3RleGluZm8vbWFrZWluZm8v aW5zZXJ0aW9uLmMNCmNjIC1PIC1waXBlIC1ESEFWRV9DT05GSUdfSCAtRExPQ0FMRURJUj1cIi91 c3Ivc2hhcmUvbG9jYWxlXCIgIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9tYWtlaW5m by8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhp bmZvL21ha2VpbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9saWIgIC1JL3Vzci9vYmov dXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL3RleGlu Zm8vbWFrZWluZm8vbGFuZy5jDQpjYyAtTyAtcGlwZSAtREhBVkVfQ09ORklHX0ggLURMT0NBTEVE SVI9XCIvdXNyL3NoYXJlL2xvY2FsZVwiICAtSS91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8v bWFrZWluZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvIC1JL3Vzci9zcmMvZ251L3Vzci5i aW4vdGV4aW5mby9tYWtlaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8vbGliICAtSS91 c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJp Yi90ZXhpbmZvL21ha2VpbmZvL21hY3JvLmMNCmNjIC1PIC1waXBlIC1ESEFWRV9DT05GSUdfSCAt RExPQ0FMRURJUj1cIi91c3Ivc2hhcmUvbG9jYWxlXCIgIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v dGV4aW5mby9tYWtlaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8gLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi90ZXhpbmZvL21ha2VpbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9s aWIgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3Ny Yy9jb250cmliL3RleGluZm8vbWFrZWluZm8vbWFrZWluZm8uYw0KY2MgLU8gLXBpcGUgLURIQVZF X0NPTkZJR19IIC1ETE9DQUxFRElSPVwiL3Vzci9zaGFyZS9sb2NhbGVcIiAgLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi90ZXhpbmZvL21ha2VpbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mbyAt SS91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vbWFrZWluZm8vLi4vLi4vLi4vLi4vY29udHJp Yi90ZXhpbmZvL2xpYiAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRl IC1jIC91c3Ivc3JjL2NvbnRyaWIvdGV4aW5mby9tYWtlaW5mby9tdWx0aS5jDQpjYyAtTyAtcGlw ZSAtREhBVkVfQ09ORklHX0ggLURMT0NBTEVESVI9XCIvdXNyL3NoYXJlL2xvY2FsZVwiICAtSS91 c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vbWFrZWluZm8vLi4vLi4vLi4vLi4vY29udHJpYi90 ZXhpbmZvIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9tYWtlaW5mby8uLi8uLi8uLi8u Li9jb250cmliL3RleGluZm8vbGliICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNy L2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi90ZXhpbmZvL21ha2VpbmZvL25vZGUuYw0KY2Mg LU8gLXBpcGUgLURIQVZFX0NPTkZJR19IIC1ETE9DQUxFRElSPVwiL3Vzci9zaGFyZS9sb2NhbGVc IiAgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL21ha2VpbmZvLy4uLy4uLy4uLy4uL2Nv bnRyaWIvdGV4aW5mbyAtSS91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vbWFrZWluZm8vLi4v Li4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2xpYiAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVn YWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvdGV4aW5mby9tYWtlaW5mby9zZWN0 aW9uaW5nLmMNCmNjIC1PIC1waXBlIC1ESEFWRV9DT05GSUdfSCAtRExPQ0FMRURJUj1cIi91c3Iv c2hhcmUvbG9jYWxlXCIgIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9tYWtlaW5mby8u Li8uLi8uLi8uLi9jb250cmliL3RleGluZm8gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZv L21ha2VpbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9saWIgIC1JL3Vzci9vYmovdXNy L3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL3RleGluZm8v bWFrZWluZm8vdG9jLmMNCmNjIC1PIC1waXBlIC1ESEFWRV9DT05GSUdfSCAtRExPQ0FMRURJUj1c Ii91c3Ivc2hhcmUvbG9jYWxlXCIgIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9tYWtl aW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90 ZXhpbmZvL21ha2VpbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9saWIgIC1JL3Vzci9v YmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL3Rl eGluZm8vbWFrZWluZm8veG1sLmMNCmNjIC1PIC1waXBlIC1ESEFWRV9DT05GSUdfSCAtRExPQ0FM RURJUj1cIi91c3Ivc2hhcmUvbG9jYWxlXCIgIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5m by9tYWtlaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8gLUkvdXNyL3NyYy9nbnUvdXNy LmJpbi90ZXhpbmZvL21ha2VpbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9saWIgIC1J L3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAgLXN0YXRpYyAtTC91c3Iv b2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2xpYiAtbyBtYWtlaW5mbyBjbWRzLm8gZGVmdW4u byBmaWxlcy5vIGZvb3Rub3RlLm8gaHRtbC5vIGluZGV4Lm8gaW5zZXJ0aW9uLm8gbGFuZy5vIG1h Y3JvLm8gbWFrZWluZm8ubyBtdWx0aS5vIG5vZGUubyBzZWN0aW9uaW5nLm8gdG9jLm8geG1sLm8g L3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9tYWtlaW5m by8uLi9saWJ0eGkvbGlidHhpLmEgLWxlZ2FjeQ0KPT09PiBnbnUvdXNyLmJpbi90ZXhpbmZvL2lu Zm8NCmNjIC1PIC1waXBlIC1ESU5GT0RJUj1cIi91c3Ivc2hhcmUvaW5mbzovdXNyL2xvY2FsL2lu Zm86L3Vzci9YMTFSNi9pbmZvOi5cIiAtREhBVkVfQ09ORklHX0ggLURMT0NBTEVESVI9XCIvdXNy L3NoYXJlL2xvY2FsZVwiICAtSS91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5mby8uLi8u Li8uLi8uLi9jb250cmliL3RleGluZm8gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2lu Zm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2xpYiAgLUkvdXNyL29iai91c3Ivc3JjL2kz ODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvdGV4aW5mby9pbmZvL2Rp ci5jDQpjYyAtTyAtcGlwZSAtRElORk9ESVI9XCIvdXNyL3NoYXJlL2luZm86L3Vzci9sb2NhbC9p bmZvOi91c3IvWDExUjYvaW5mbzouXCIgLURIQVZFX0NPTkZJR19IIC1ETE9DQUxFRElSPVwiL3Vz ci9zaGFyZS9sb2NhbGVcIiAgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4v Li4vLi4vLi4vY29udHJpYi90ZXhpbmZvIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9p bmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9saWIgIC1JL3Vzci9vYmovdXNyL3NyYy9p Mzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL3RleGluZm8vaW5mby9k aXNwbGF5LmMNCmNjIC1PIC1waXBlIC1ESU5GT0RJUj1cIi91c3Ivc2hhcmUvaW5mbzovdXNyL2xv Y2FsL2luZm86L3Vzci9YMTFSNi9pbmZvOi5cIiAtREhBVkVfQ09ORklHX0ggLURMT0NBTEVESVI9 XCIvdXNyL3NoYXJlL2xvY2FsZVwiICAtSS91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5m by8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhp bmZvL2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2xpYiAgLUkvdXNyL29iai91c3Iv c3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvdGV4aW5mby9p bmZvL2RvYy5jDQpjYyAtTyAtcGlwZSAtRElORk9ESVI9XCIvdXNyL3NoYXJlL2luZm86L3Vzci9s b2NhbC9pbmZvOi91c3IvWDExUjYvaW5mbzouXCIgLURIQVZFX0NPTkZJR19IIC1ETE9DQUxFRElS PVwiL3Vzci9zaGFyZS9sb2NhbGVcIiAgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2lu Zm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4 aW5mby9pbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9saWIgIC1JL3Vzci9vYmovdXNy L3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL3RleGluZm8v aW5mby9kcmliYmxlLmMNCmNjIC1PIC1waXBlIC1ESU5GT0RJUj1cIi91c3Ivc2hhcmUvaW5mbzov dXNyL2xvY2FsL2luZm86L3Vzci9YMTFSNi9pbmZvOi5cIiAtREhBVkVfQ09ORklHX0ggLURMT0NB TEVESVI9XCIvdXNyL3NoYXJlL2xvY2FsZVwiICAtSS91c3Ivc3JjL2dudS91c3IuYmluL3RleGlu Zm8vaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8gLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2xpYiAgLUkvdXNyL29i ai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvdGV4 aW5mby9pbmZvL2VjaG8tYXJlYS5jDQpjYyAtTyAtcGlwZSAtRElORk9ESVI9XCIvdXNyL3NoYXJl L2luZm86L3Vzci9sb2NhbC9pbmZvOi91c3IvWDExUjYvaW5mbzouXCIgLURIQVZFX0NPTkZJR19I IC1ETE9DQUxFRElSPVwiL3Vzci9zaGFyZS9sb2NhbGVcIiAgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvIC1JL3Vzci9zcmMvZ251 L3Vzci5iaW4vdGV4aW5mby9pbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9saWIgIC1J L3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250 cmliL3RleGluZm8vaW5mby9maWxlc3lzLmMNCmNjIC1PIC1waXBlIC1ESU5GT0RJUj1cIi91c3Iv c2hhcmUvaW5mbzovdXNyL2xvY2FsL2luZm86L3Vzci9YMTFSNi9pbmZvOi5cIiAtREhBVkVfQ09O RklHX0ggLURMT0NBTEVESVI9XCIvdXNyL3NoYXJlL2xvY2FsZVwiICAtSS91c3Ivc3JjL2dudS91 c3IuYmluL3RleGluZm8vaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8gLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2xp YiAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3Jj L2NvbnRyaWIvdGV4aW5mby9pbmZvL2Zvb3Rub3Rlcy5jDQpjYyAtTyAtcGlwZSAtRElORk9ESVI9 XCIvdXNyL3NoYXJlL2luZm86L3Vzci9sb2NhbC9pbmZvOi91c3IvWDExUjYvaW5mbzouXCIgLURI QVZFX0NPTkZJR19IIC1ETE9DQUxFRElSPVwiL3Vzci9zaGFyZS9sb2NhbGVcIiAgLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9pbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4 aW5mby9saWIgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAv dXNyL3NyYy9jb250cmliL3RleGluZm8vaW5mby9nYy5jDQpjYyAtTyAtcGlwZSAtRElORk9ESVI9 XCIvdXNyL3NoYXJlL2luZm86L3Vzci9sb2NhbC9pbmZvOi91c3IvWDExUjYvaW5mbzouXCIgLURI QVZFX0NPTkZJR19IIC1ETE9DQUxFRElSPVwiL3Vzci9zaGFyZS9sb2NhbGVcIiAgLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9pbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4 aW5mby9saWIgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAv dXNyL3NyYy9jb250cmliL3RleGluZm8vaW5mby9pbmRpY2VzLmMNCmNjIC1PIC1waXBlIC1ESU5G T0RJUj1cIi91c3Ivc2hhcmUvaW5mbzovdXNyL2xvY2FsL2luZm86L3Vzci9YMTFSNi9pbmZvOi5c IiAtREhBVkVfQ09ORklHX0ggLURMT0NBTEVESVI9XCIvdXNyL3NoYXJlL2xvY2FsZVwiICAtSS91 c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGlu Zm8gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29udHJp Yi90ZXhpbmZvL2xpYiAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRl IC1jIC91c3Ivc3JjL2NvbnRyaWIvdGV4aW5mby9pbmZvL2luZm8tdXRpbHMuYw0KY2MgLU8gLXBp cGUgLURJTkZPRElSPVwiL3Vzci9zaGFyZS9pbmZvOi91c3IvbG9jYWwvaW5mbzovdXNyL1gxMVI2 L2luZm86LlwiIC1ESEFWRV9DT05GSUdfSCAtRExPQ0FMRURJUj1cIi91c3Ivc2hhcmUvbG9jYWxl XCIgIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9pbmZvLy4uLy4uLy4uLy4uL2NvbnRy aWIvdGV4aW5mbyAtSS91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5mby8uLi8uLi8uLi8u Li9jb250cmliL3RleGluZm8vbGliICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNy L2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi90ZXhpbmZvL2luZm8vaW5mby5jDQpjYyAtTyAt cGlwZSAtRElORk9ESVI9XCIvdXNyL3NoYXJlL2luZm86L3Vzci9sb2NhbC9pbmZvOi91c3IvWDEx UjYvaW5mbzouXCIgLURIQVZFX0NPTkZJR19IIC1ETE9DQUxFRElSPVwiL3Vzci9zaGFyZS9sb2Nh bGVcIiAgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29u dHJpYi90ZXhpbmZvIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9pbmZvLy4uLy4uLy4u Ly4uL2NvbnRyaWIvdGV4aW5mby9saWIgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91 c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL3RleGluZm8vaW5mby9pbmZvZG9jLmMNCmNj IC1PIC1waXBlIC1ESU5GT0RJUj1cIi91c3Ivc2hhcmUvaW5mbzovdXNyL2xvY2FsL2luZm86L3Vz ci9YMTFSNi9pbmZvOi5cIiAtREhBVkVfQ09ORklHX0ggLURMT0NBTEVESVI9XCIvdXNyL3NoYXJl L2xvY2FsZVwiICAtSS91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5mby8uLi8uLi8uLi8u Li9jb250cmliL3RleGluZm8gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4v Li4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2xpYiAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVn YWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvdGV4aW5mby9pbmZvL2luZm9tYXAu Yw0KY2MgLU8gLXBpcGUgLURJTkZPRElSPVwiL3Vzci9zaGFyZS9pbmZvOi91c3IvbG9jYWwvaW5m bzovdXNyL1gxMVI2L2luZm86LlwiIC1ESEFWRV9DT05GSUdfSCAtRExPQ0FMRURJUj1cIi91c3Iv c2hhcmUvbG9jYWxlXCIgIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9pbmZvLy4uLy4u Ly4uLy4uL2NvbnRyaWIvdGV4aW5mbyAtSS91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5m by8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8vbGliICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4 Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi90ZXhpbmZvL2luZm8vbS14 LmMNCmNjIC1PIC1waXBlIC1ESU5GT0RJUj1cIi91c3Ivc2hhcmUvaW5mbzovdXNyL2xvY2FsL2lu Zm86L3Vzci9YMTFSNi9pbmZvOi5cIiAtREhBVkVfQ09ORklHX0ggLURMT0NBTEVESVI9XCIvdXNy L3NoYXJlL2xvY2FsZVwiICAtSS91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5mby8uLi8u Li8uLi8uLi9jb250cmliL3RleGluZm8gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2lu Zm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2xpYiAgLUkvdXNyL29iai91c3Ivc3JjL2kz ODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvdGV4aW5mby9pbmZvL21h bi5jDQpjYyAtTyAtcGlwZSAtRElORk9ESVI9XCIvdXNyL3NoYXJlL2luZm86L3Vzci9sb2NhbC9p bmZvOi91c3IvWDExUjYvaW5mbzouXCIgLURIQVZFX0NPTkZJR19IIC1ETE9DQUxFRElSPVwiL3Vz ci9zaGFyZS9sb2NhbGVcIiAgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4v Li4vLi4vLi4vY29udHJpYi90ZXhpbmZvIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9p bmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9saWIgIC1JL3Vzci9vYmovdXNyL3NyYy9p Mzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL3RleGluZm8vaW5mby9u b2RlbWVudS5jDQpjYyAtTyAtcGlwZSAtRElORk9ESVI9XCIvdXNyL3NoYXJlL2luZm86L3Vzci9s b2NhbC9pbmZvOi91c3IvWDExUjYvaW5mbzouXCIgLURIQVZFX0NPTkZJR19IIC1ETE9DQUxFRElS PVwiL3Vzci9zaGFyZS9sb2NhbGVcIiAgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2lu Zm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4 aW5mby9pbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9saWIgIC1JL3Vzci9vYmovdXNy L3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL3RleGluZm8v aW5mby9ub2Rlcy5jDQpjYyAtTyAtcGlwZSAtRElORk9ESVI9XCIvdXNyL3NoYXJlL2luZm86L3Vz ci9sb2NhbC9pbmZvOi91c3IvWDExUjYvaW5mbzouXCIgLURIQVZFX0NPTkZJR19IIC1ETE9DQUxF RElSPVwiL3Vzci9zaGFyZS9sb2NhbGVcIiAgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZv L2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v dGV4aW5mby9pbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9saWIgIC1JL3Vzci9vYmov dXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL3RleGlu Zm8vaW5mby9zZWFyY2guYw0KY2MgLU8gLXBpcGUgLURJTkZPRElSPVwiL3Vzci9zaGFyZS9pbmZv Oi91c3IvbG9jYWwvaW5mbzovdXNyL1gxMVI2L2luZm86LlwiIC1ESEFWRV9DT05GSUdfSCAtRExP Q0FMRURJUj1cIi91c3Ivc2hhcmUvbG9jYWxlXCIgIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4 aW5mby9pbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mbyAtSS91c3Ivc3JjL2dudS91c3Iu YmluL3RleGluZm8vaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8vbGliICAtSS91c3Iv b2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi90 ZXhpbmZvL2luZm8vc2Vzc2lvbi5jDQpjYyAtTyAtcGlwZSAtRElORk9ESVI9XCIvdXNyL3NoYXJl L2luZm86L3Vzci9sb2NhbC9pbmZvOi91c3IvWDExUjYvaW5mbzouXCIgLURIQVZFX0NPTkZJR19I IC1ETE9DQUxFRElSPVwiL3Vzci9zaGFyZS9sb2NhbGVcIiAgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvIC1JL3Vzci9zcmMvZ251 L3Vzci5iaW4vdGV4aW5mby9pbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9saWIgIC1J L3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250 cmliL3RleGluZm8vaW5mby9zaWduYWxzLmMNCmNjIC1PIC1waXBlIC1ESU5GT0RJUj1cIi91c3Iv c2hhcmUvaW5mbzovdXNyL2xvY2FsL2luZm86L3Vzci9YMTFSNi9pbmZvOi5cIiAtREhBVkVfQ09O RklHX0ggLURMT0NBTEVESVI9XCIvdXNyL3NoYXJlL2xvY2FsZVwiICAtSS91c3Ivc3JjL2dudS91 c3IuYmluL3RleGluZm8vaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8gLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2xp YiAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3Jj L2NvbnRyaWIvdGV4aW5mby9pbmZvL3Rlcm1pbmFsLmMNCmNjIC1PIC1waXBlIC1ESU5GT0RJUj1c Ii91c3Ivc2hhcmUvaW5mbzovdXNyL2xvY2FsL2luZm86L3Vzci9YMTFSNi9pbmZvOi5cIiAtREhB VkVfQ09ORklHX0ggLURMT0NBTEVESVI9XCIvdXNyL3NoYXJlL2xvY2FsZVwiICAtSS91c3Ivc3Jj L2dudS91c3IuYmluL3RleGluZm8vaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8gLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhp bmZvL2xpYiAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91 c3Ivc3JjL2NvbnRyaWIvdGV4aW5mby9pbmZvL3RpbGRlLmMNCmNjIC1PIC1waXBlIC1ESU5GT0RJ Uj1cIi91c3Ivc2hhcmUvaW5mbzovdXNyL2xvY2FsL2luZm86L3Vzci9YMTFSNi9pbmZvOi5cIiAt REhBVkVfQ09ORklHX0ggLURMT0NBTEVESVI9XCIvdXNyL3NoYXJlL2xvY2FsZVwiICAtSS91c3Iv c3JjL2dudS91c3IuYmluL3RleGluZm8vaW5mby8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8g LUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90 ZXhpbmZvL2xpYiAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1j IC91c3Ivc3JjL2NvbnRyaWIvdGV4aW5mby9pbmZvL3ZhcmlhYmxlcy5jDQpjYyAtTyAtcGlwZSAt RElORk9ESVI9XCIvdXNyL3NoYXJlL2luZm86L3Vzci9sb2NhbC9pbmZvOi91c3IvWDExUjYvaW5m bzouXCIgLURIQVZFX0NPTkZJR19IIC1ETE9DQUxFRElSPVwiL3Vzci9zaGFyZS9sb2NhbGVcIiAg LUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8vLi4vLi4vLi4vLi4vY29udHJpYi90 ZXhpbmZvIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9pbmZvLy4uLy4uLy4uLy4uL2Nv bnRyaWIvdGV4aW5mby9saWIgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5j bHVkZSAtYyAvdXNyL3NyYy9jb250cmliL3RleGluZm8vaW5mby93aW5kb3cuYw0KY2MgLU8gLXBp cGUgLURJTkZPRElSPVwiL3Vzci9zaGFyZS9pbmZvOi91c3IvbG9jYWwvaW5mbzovdXNyL1gxMVI2 L2luZm86LlwiIC1ESEFWRV9DT05GSUdfSCAtRExPQ0FMRURJUj1cIi91c3Ivc2hhcmUvbG9jYWxl XCIgIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9pbmZvLy4uLy4uLy4uLy4uL2NvbnRy aWIvdGV4aW5mbyAtSS91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5mby8uLi8uLi8uLi8u Li9jb250cmliL3RleGluZm8vbGliICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNy L2luY2x1ZGUgIC1zdGF0aWMgLUwvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9saWIg LW8gaW5mbyBkaXIubyBkaXNwbGF5Lm8gZG9jLm8gZHJpYmJsZS5vIGVjaG8tYXJlYS5vIGZpbGVz eXMubyBmb290bm90ZXMubyBnYy5vIGluZGljZXMubyBpbmZvLXV0aWxzLm8gaW5mby5vIGluZm9k b2MubyBpbmZvbWFwLm8gbS14Lm8gbWFuLm8gbm9kZW1lbnUubyBub2Rlcy5vIHNlYXJjaC5vIHNl c3Npb24ubyBzaWduYWxzLm8gdGVybWluYWwubyB0aWxkZS5vIHZhcmlhYmxlcy5vIHdpbmRvdy5v IC1sdGVybWNhcCAvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhp bmZvL2luZm8vLi4vbGlidHhpL2xpYnR4aS5hIC1sZWdhY3kNCj09PT4gZ251L3Vzci5iaW4vdGV4 aW5mby9pbmZva2V5DQpjYyAtTyAtcGlwZSAtREhBVkVfQ09ORklHX0ggLURMT0NBTEVESVI9XCIv dXNyL3NoYXJlL2xvY2FsZVwiICAtSS91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5mb2tl eS8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhp bmZvL2luZm9rZXkvLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2xpYiAgLUkvdXNyL29iai91 c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvdGV4aW5m by9pbmZvL2luZm9rZXkuYw0KY2MgLU8gLXBpcGUgLURIQVZFX0NPTkZJR19IIC1ETE9DQUxFRElS PVwiL3Vzci9zaGFyZS9sb2NhbGVcIiAgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2lu Zm9rZXkvLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v dGV4aW5mby9pbmZva2V5Ly4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9saWIgIC1JL3Vzci9v YmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL3Rl eGluZm8vaW5mby9rZXkuYw0KY2MgLU8gLXBpcGUgLURIQVZFX0NPTkZJR19IIC1ETE9DQUxFRElS PVwiL3Vzci9zaGFyZS9sb2NhbGVcIiAgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2lu Zm9rZXkvLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v dGV4aW5mby9pbmZva2V5Ly4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mby9saWIgIC1JL3Vzci9v YmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAgLXN0YXRpYyAtTC91c3Ivb2JqL3Vz ci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2xpYiAtbyBpbmZva2V5IGluZm9rZXkubyBrZXkubyAvdXNy L29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm9rZXkvLi4v bGlidHhpL2xpYnR4aS5hIC1sZWdhY3kNCj09PT4gZ251L3Vzci5iaW4vdGV4aW5mby9pbnN0YWxs LWluZm8NCmNjIC1PIC1waXBlIC1ESEFWRV9DT05GSUdfSCAtRExPQ0FMRURJUj1cIi91c3Ivc2hh cmUvbG9jYWxlXCIgIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9pbnN0YWxsLWluZm8v Li4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5m by9pbnN0YWxsLWluZm8vLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZvL2xpYiAgLUkvdXNyL29i ai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvdGV4 aW5mby91dGlsL2luc3RhbGwtaW5mby5jDQpjYyAtTyAtcGlwZSAtREhBVkVfQ09ORklHX0ggLURM T0NBTEVESVI9XCIvdXNyL3NoYXJlL2xvY2FsZVwiICAtSS91c3Ivc3JjL2dudS91c3IuYmluL3Rl eGluZm8vaW5zdGFsbC1pbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mbyAtSS91c3Ivc3Jj L2dudS91c3IuYmluL3RleGluZm8vaW5zdGFsbC1pbmZvLy4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4 aW5mby9saWIgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAgLXN0 YXRpYyAtTC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2xpYiAtbyBpbnN0YWxsLWlu Zm8gaW5zdGFsbC1pbmZvLm8gL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5i aW4vdGV4aW5mby9pbnN0YWxsLWluZm8vLi4vbGlidHhpL2xpYnR4aS5hIC1sZWdhY3kNCj09PT4g Z251L3Vzci5iaW4vdGV4aW5mby90ZXhpbmRleA0KY2MgLU8gLXBpcGUgLURIQVZFX0NPTkZJR19I IC1ETE9DQUxFRElSPVwiL3Vzci9zaGFyZS9sb2NhbGVcIiAgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi90ZXhpbmZvL3RleGluZGV4Ly4uLy4uLy4uLy4uL2NvbnRyaWIvdGV4aW5mbyAtSS91c3Ivc3Jj L2dudS91c3IuYmluL3RleGluZm8vdGV4aW5kZXgvLi4vLi4vLi4vLi4vY29udHJpYi90ZXhpbmZv L2xpYiAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Iv c3JjL2NvbnRyaWIvdGV4aW5mby91dGlsL3RleGluZGV4LmMNCmNjIC1PIC1waXBlIC1ESEFWRV9D T05GSUdfSCAtRExPQ0FMRURJUj1cIi91c3Ivc2hhcmUvbG9jYWxlXCIgIC1JL3Vzci9zcmMvZ251 L3Vzci5iaW4vdGV4aW5mby90ZXhpbmRleC8uLi8uLi8uLi8uLi9jb250cmliL3RleGluZm8gLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL3RleGluZGV4Ly4uLy4uLy4uLy4uL2NvbnRyaWIv dGV4aW5mby9saWIgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAg LXN0YXRpYyAtTC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2xpYiAtbyB0ZXhpbmRl eCB0ZXhpbmRleC5vIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL3Rl eGluZm8vdGV4aW5kZXgvLi4vbGlidHhpL2xpYnR4aS5hIC1sZWdhY3kNCj09PT4gZ251L3Vzci5i aW4vdGV4aW5mby9kb2MNCj09PT4gZ251L3Vzci5iaW4vdGV4aW5mby9saWJ0eGkNCj09PT4gZ251 L3Vzci5iaW4vdGV4aW5mby9tYWtlaW5mbw0Kc2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCAt cyAtbyByb290IC1nIHdoZWVsIC1tIDU1NSAgIG1ha2VpbmZvIC91c3Ivb2JqL3Vzci9zcmMvaTM4 Ni9sZWdhY3kvdXNyL2Jpbg0KPT09PiBnbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8NCnNoIC91c3Iv c3JjL3Rvb2xzL2luc3RhbGwuc2ggLXMgLW8gcm9vdCAtZyB3aGVlbCAtbSA1NTUgICBpbmZvIC91 c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2Jpbg0KPT09PiBnbnUvdXNyLmJpbi90ZXhp bmZvL2luZm9rZXkNCnNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2ggLXMgLW8gcm9vdCAtZyB3 aGVlbCAtbSA1NTUgICBpbmZva2V5IC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2Jp bg0KPT09PiBnbnUvdXNyLmJpbi90ZXhpbmZvL2luc3RhbGwtaW5mbw0Kc2ggL3Vzci9zcmMvdG9v bHMvaW5zdGFsbC5zaCAtcyAtbyByb290IC1nIHdoZWVsIC1tIDU1NSAgIGluc3RhbGwtaW5mbyAv dXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9iaW4NCj09PT4gZ251L3Vzci5iaW4vdGV4 aW5mby90ZXhpbmRleA0Kc2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCAtcyAtbyByb290IC1n IHdoZWVsIC1tIDU1NSAgIHRleGluZGV4IC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNy L2Jpbg0KPT09PiBnbnUvdXNyLmJpbi90ZXhpbmZvL2RvYw0KPT09PiB1c3IuYmluL2NvbGxkZWYN Ci91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL3Vzci5iaW4vY29sbGRlZiBjcmVhdGVkIGZv ciAvdXNyL3NyYy91c3IuYmluL2NvbGxkZWYNCnlhY2MgLWQgL3Vzci9zcmMvdXNyLmJpbi9jb2xs ZGVmL3BhcnNlLnkNCmNwIHkudGFiLmMgcGFyc2UuYw0KbGV4IC10IC04IC1pIC91c3Ivc3JjL3Vz ci5iaW4vY29sbGRlZi9zY2FuLmwgPiBzY2FuLmMNCnJtIC1mIC5kZXBlbmQNCm1rZGVwIC1mIC5k ZXBlbmQgLWEgICAgLUkuIC1JL3Vzci9zcmMvdXNyLmJpbi9jb2xsZGVmIC1JL3Vzci9zcmMvdXNy LmJpbi9jb2xsZGVmLy4uLy4uL2xpYi9saWJjL2xvY2FsZSAtRENPTExBVEVfREVCVUcgLURZWV9O T19VTlBVVCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgcGFyc2Uu YyBzY2FuLmMNCmVjaG8gY29sbGRlZjogL3Vzci9saWIvbGliYy5hIC91c3IvbGliL2xpYmwuYSAv dXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9saWIvbGliZWdhY3kuYSA+PiAuZGVwZW5k DQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNyL3NyYy91c3IuYmluL2NvbGxkZWYgLUkvdXNyL3NyYy91 c3IuYmluL2NvbGxkZWYvLi4vLi4vbGliL2xpYmMvbG9jYWxlIC1EQ09MTEFURV9ERUJVRyAtRFlZ X05PX1VOUFVUICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMg cGFyc2UuYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvdXNyLmJpbi9jb2xsZGVmIC1JL3Vz ci9zcmMvdXNyLmJpbi9jb2xsZGVmLy4uLy4uL2xpYi9saWJjL2xvY2FsZSAtRENPTExBVEVfREVC VUcgLURZWV9OT19VTlBVVCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNs dWRlIC1jIHNjYW4uYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvdXNyLmJpbi9jb2xsZGVm IC1JL3Vzci9zcmMvdXNyLmJpbi9jb2xsZGVmLy4uLy4uL2xpYi9saWJjL2xvY2FsZSAtRENPTExB VEVfREVCVUcgLURZWV9OT19VTlBVVCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vz ci9pbmNsdWRlICAtc3RhdGljIC1ML3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvbGli IC1vIGNvbGxkZWYgcGFyc2UubyBzY2FuLm8gLWxsIC1sZWdhY3kNCnNoIC91c3Ivc3JjL3Rvb2xz L2luc3RhbGwuc2ggLXMgLW8gcm9vdCAtZyB3aGVlbCAtbSA1NTUgICBjb2xsZGVmIC91c3Ivb2Jq L3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2Jpbg0KPT09PiB1c3IuYmluL21ha2V3aGF0aXMNCi91 c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL3Vzci5iaW4vbWFrZXdoYXRpcyBjcmVhdGVkIGZv ciAvdXNyL3NyYy91c3IuYmluL21ha2V3aGF0aXMNCnJtIC1mIC5kZXBlbmQNCm1rZGVwIC1mIC5k ZXBlbmQgLWEgICAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC91 c3Ivc3JjL3Vzci5iaW4vbWFrZXdoYXRpcy9tYWtld2hhdGlzLmMNCmVjaG8gbWFrZXdoYXRpczog L3Vzci9saWIvbGliYy5hIC91c3IvbGliL2xpYnouYSAvdXNyL29iai91c3Ivc3JjL2kzODYvbGVn YWN5L3Vzci9saWIvbGliZWdhY3kuYSA+PiAuZGVwZW5kDQpjYyAtTyAtcGlwZSAgLUkvdXNyL29i ai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL3Vzci5iaW4vbWFr ZXdoYXRpcy9tYWtld2hhdGlzLmMNCmNjIC1PIC1waXBlICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4 Ni9sZWdhY3kvdXNyL2luY2x1ZGUgIC1zdGF0aWMgLUwvdXNyL29iai91c3Ivc3JjL2kzODYvbGVn YWN5L3Vzci9saWIgLW8gbWFrZXdoYXRpcyBtYWtld2hhdGlzLm8gLWx6IC1sZWdhY3kNCnNoIC91 c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2ggLXMgLW8gcm9vdCAtZyB3aGVlbCAtbSA1NTUgICBtYWtl d2hhdGlzIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2Jpbg0Kc2ggL3Vzci9zcmMv dG9vbHMvaW5zdGFsbC5zaCAtbyByb290ICAtZyB3aGVlbCAtbSA1NTUgIC91c3Ivc3JjL3Vzci5i aW4vbWFrZXdoYXRpcy9tYWtld2hhdGlzLmxvY2FsLnNoICAvdXNyL29iai91c3Ivc3JjL2kzODYv bGVnYWN5L3Vzci9saWJleGVjL21ha2V3aGF0aXMubG9jYWwNCi91c3Ivb2JqL3Vzci9zcmMvaTM4 Ni9sZWdhY3kvdXNyL2xpYmV4ZWMvY2F0bWFuLmxvY2FsIC0+IC91c3Ivb2JqL3Vzci9zcmMvaTM4 Ni9sZWdhY3kvdXNyL2xpYmV4ZWMvbWFrZXdoYXRpcy5sb2NhbA0KPT09PiB1c3IuYmluL3JwY2dl bg0KL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvdXNyLmJpbi9ycGNnZW4gY3JlYXRlZCBm b3IgL3Vzci9zcmMvdXNyLmJpbi9ycGNnZW4NCnJtIC1mIC5kZXBlbmQNCm1rZGVwIC1mIC5kZXBl bmQgLWEgICAgLURpbmxpbmU9cnBjZ2VuX2lubGluZSAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9s ZWdhY3kvdXNyL2luY2x1ZGUgL3Vzci9zcmMvdXNyLmJpbi9ycGNnZW4vcnBjX21haW4uYyAvdXNy L3NyYy91c3IuYmluL3JwY2dlbi9ycGNfY2xudG91dC5jIC91c3Ivc3JjL3Vzci5iaW4vcnBjZ2Vu L3JwY19jb3V0LmMgL3Vzci9zcmMvdXNyLmJpbi9ycGNnZW4vcnBjX2hvdXQuYyAvdXNyL3NyYy91 c3IuYmluL3JwY2dlbi9ycGNfcGFyc2UuYyAvdXNyL3NyYy91c3IuYmluL3JwY2dlbi9ycGNfc2Ft cGxlLmMgL3Vzci9zcmMvdXNyLmJpbi9ycGNnZW4vcnBjX3NjYW4uYyAvdXNyL3NyYy91c3IuYmlu L3JwY2dlbi9ycGNfc3Zjb3V0LmMgL3Vzci9zcmMvdXNyLmJpbi9ycGNnZW4vcnBjX3RibG91dC5j IC91c3Ivc3JjL3Vzci5iaW4vcnBjZ2VuL3JwY191dGlsLmMNCmVjaG8gcnBjZ2VuOiAvdXNyL2xp Yi9saWJjLmEgL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvbGliL2xpYmVnYWN5LmEg Pj4gLmRlcGVuZA0KY2MgLU8gLXBpcGUgLURpbmxpbmU9cnBjZ2VuX2lubGluZSAgLUkvdXNyL29i ai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL3Vzci5iaW4vcnBj Z2VuL3JwY19tYWluLmMNCmNjIC1PIC1waXBlIC1EaW5saW5lPXJwY2dlbl9pbmxpbmUgIC1JL3Vz ci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy91c3IuYmlu L3JwY2dlbi9ycGNfY2xudG91dC5jDQpjYyAtTyAtcGlwZSAtRGlubGluZT1ycGNnZW5faW5saW5l ICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMv dXNyLmJpbi9ycGNnZW4vcnBjX2NvdXQuYw0KY2MgLU8gLXBpcGUgLURpbmxpbmU9cnBjZ2VuX2lu bGluZSAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Iv c3JjL3Vzci5iaW4vcnBjZ2VuL3JwY19ob3V0LmMNCmNjIC1PIC1waXBlIC1EaW5saW5lPXJwY2dl bl9pbmxpbmUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAv dXNyL3NyYy91c3IuYmluL3JwY2dlbi9ycGNfcGFyc2UuYw0KY2MgLU8gLXBpcGUgLURpbmxpbmU9 cnBjZ2VuX2lubGluZSAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRl IC1jIC91c3Ivc3JjL3Vzci5iaW4vcnBjZ2VuL3JwY19zYW1wbGUuYw0KY2MgLU8gLXBpcGUgLURp bmxpbmU9cnBjZ2VuX2lubGluZSAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9p bmNsdWRlIC1jIC91c3Ivc3JjL3Vzci5iaW4vcnBjZ2VuL3JwY19zY2FuLmMNCmNjIC1PIC1waXBl IC1EaW5saW5lPXJwY2dlbl9pbmxpbmUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91 c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy91c3IuYmluL3JwY2dlbi9ycGNfc3Zjb3V0LmMNCmNjIC1P IC1waXBlIC1EaW5saW5lPXJwY2dlbl9pbmxpbmUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xl Z2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy91c3IuYmluL3JwY2dlbi9ycGNfdGJsb3V0LmMN CmNjIC1PIC1waXBlIC1EaW5saW5lPXJwY2dlbl9pbmxpbmUgIC1JL3Vzci9vYmovdXNyL3NyYy9p Mzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy91c3IuYmluL3JwY2dlbi9ycGNfdXRp bC5jDQpjYyAtTyAtcGlwZSAtRGlubGluZT1ycGNnZW5faW5saW5lICAtSS91c3Ivb2JqL3Vzci9z cmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgIC1zdGF0aWMgLUwvdXNyL29iai91c3Ivc3JjL2kz ODYvbGVnYWN5L3Vzci9saWIgLW8gcnBjZ2VuIHJwY19tYWluLm8gcnBjX2NsbnRvdXQubyBycGNf Y291dC5vIHJwY19ob3V0Lm8gcnBjX3BhcnNlLm8gcnBjX3NhbXBsZS5vIHJwY19zY2FuLm8gcnBj X3N2Y291dC5vIHJwY190YmxvdXQubyBycGNfdXRpbC5vIC1sZWdhY3kNCnNoIC91c3Ivc3JjL3Rv b2xzL2luc3RhbGwuc2ggLXMgLW8gcm9vdCAtZyB3aGVlbCAtbSA1NTUgICBycGNnZW4gL3Vzci9v YmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvYmluDQo9PT0+IHVzci5iaW4veGluc3RhbGwNCi91 c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL3Vzci5iaW4veGluc3RhbGwgY3JlYXRlZCBmb3Ig L3Vzci9zcmMvdXNyLmJpbi94aW5zdGFsbA0Kcm0gLWYgLmRlcGVuZA0KbWtkZXAgLWYgLmRlcGVu ZCAtYSAgICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgL3Vzci9z cmMvdXNyLmJpbi94aW5zdGFsbC94aW5zdGFsbC5jDQplY2hvIHhpbnN0YWxsOiAvdXNyL2xpYi9s aWJjLmEgL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvbGliL2xpYmVnYWN5LmEgPj4g LmRlcGVuZA0KY2MgLU8gLXBpcGUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3Iv aW5jbHVkZSAtYyAvdXNyL3NyYy91c3IuYmluL3hpbnN0YWxsL3hpbnN0YWxsLmMNCmNjIC1PIC1w aXBlICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgIC1zdGF0aWMg LUwvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9saWIgLW8geGluc3RhbGwgeGluc3Rh bGwubyAtbGVnYWN5DQpzaCAvdXNyL3NyYy90b29scy9pbnN0YWxsLnNoIC1zIC1vIHJvb3QgLWcg d2hlZWwgLW0gNTU1ICAgeGluc3RhbGwgL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3Iv YmluL2luc3RhbGwNCj09PT4gdXNyLnNiaW4vY29uZmlnDQovdXNyL29iai91c3Ivc3JjL2kzODYv dXNyL3NyYy91c3Iuc2Jpbi9jb25maWcgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vY29u ZmlnDQp5YWNjIC1kIC91c3Ivc3JjL3Vzci5zYmluL2NvbmZpZy9jb25maWcueQ0KY3AgeS50YWIu YyBjb25maWcuYw0KbGV4IC10ICAvdXNyL3NyYy91c3Iuc2Jpbi9jb25maWcvbGFuZy5sID4gbGFu Zy5jDQpybSAtZiAuZGVwZW5kDQpta2RlcCAtZiAuZGVwZW5kIC1hICAgIC1JLiAtSS91c3Ivc3Jj L3Vzci5zYmluL2NvbmZpZyAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1 ZGUgY29uZmlnLmMgL3Vzci9zcmMvdXNyLnNiaW4vY29uZmlnL21haW4uYyBsYW5nLmMgL3Vzci9z cmMvdXNyLnNiaW4vY29uZmlnL21rbWFrZWZpbGUuYyAvdXNyL3NyYy91c3Iuc2Jpbi9jb25maWcv bWtoZWFkZXJzLmMgL3Vzci9zcmMvdXNyLnNiaW4vY29uZmlnL21rb3B0aW9ucy5jDQplY2hvIGNv bmZpZzogL3Vzci9saWIvbGliYy5hIC91c3IvbGliL2xpYmwuYSAvdXNyL29iai91c3Ivc3JjL2kz ODYvbGVnYWN5L3Vzci9saWIvbGliZWdhY3kuYSA+PiAuZGVwZW5kDQpjYyAtTyAtcGlwZSAtSS4g LUkvdXNyL3NyYy91c3Iuc2Jpbi9jb25maWcgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2Fj eS91c3IvaW5jbHVkZSAtYyBjb25maWcuYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvdXNy LnNiaW4vY29uZmlnICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUg LWMgL3Vzci9zcmMvdXNyLnNiaW4vY29uZmlnL21haW4uYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vz ci9zcmMvdXNyLnNiaW4vY29uZmlnICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNy L2luY2x1ZGUgLWMgbGFuZy5jDQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNyL3NyYy91c3Iuc2Jpbi9j b25maWcgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNy L3NyYy91c3Iuc2Jpbi9jb25maWcvbWttYWtlZmlsZS5jDQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNy L3NyYy91c3Iuc2Jpbi9jb25maWcgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3Iv aW5jbHVkZSAtYyAvdXNyL3NyYy91c3Iuc2Jpbi9jb25maWcvbWtoZWFkZXJzLmMNCmNjIC1PIC1w aXBlIC1JLiAtSS91c3Ivc3JjL3Vzci5zYmluL2NvbmZpZyAgLUkvdXNyL29iai91c3Ivc3JjL2kz ODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL3Vzci5zYmluL2NvbmZpZy9ta29wdGlv bnMuYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvdXNyLnNiaW4vY29uZmlnICAtSS91c3Iv b2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgIC1zdGF0aWMgLUwvdXNyL29iai91 c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9saWIgLW8gY29uZmlnIGNvbmZpZy5vIG1haW4ubyBsYW5n Lm8gbWttYWtlZmlsZS5vIG1raGVhZGVycy5vIG1rb3B0aW9ucy5vIC1sbCAtbGVnYWN5DQpzaCAv dXNyL3NyYy90b29scy9pbnN0YWxsLnNoIC1zIC1vIHJvb3QgLWcgd2hlZWwgLW0gNTU1ICAgY29u ZmlnIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL3NiaW4NCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiBz dGFnZSAyLjE6IGNsZWFuaW5nIHVwIHRoZSBvYmplY3QgdHJlZQ0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmNkIC91c3Ivc3Jj OyBNQUtFT0JKRElSUFJFRklYPS91c3Ivb2JqICBNQUNISU5FX0FSQ0g9aTM4NiAgTUFDSElORT1p Mzg2ICBDUFVUWVBFPXAzICBHUk9GRl9CSU5fUEFUSD0vdXNyL29iai91c3Ivc3JjL2kzODYvbGVn YWN5L3Vzci9iaW4gIEdST0ZGX0ZPTlRfUEFUSD0vdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5 L3Vzci9zaGFyZS9ncm9mZl9mb250ICBHUk9GRl9UTUFDX1BBVEg9L3Vzci9vYmovdXNyL3NyYy9p Mzg2L2xlZ2FjeS91c3Ivc2hhcmUvdG1hYyAgREVTVERJUj0vdXNyL29iai91c3Ivc3JjL2kzODYg IF9TSExJQkRJUlBSRUZJWD0vdXNyL29iai91c3Ivc3JjL2kzODYgIElOU1RBTEw9InNoIC91c3Iv c3JjL3Rvb2xzL2luc3RhbGwuc2giICBQQVRIPS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kv dXNyL3NiaW46L3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvYmluOi91c3Ivb2JqL3Vz ci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2dhbWVzOi91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc2Jp bjovdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL2JpbjovdXNyL29iai91c3Ivc3JjL2kzODYvdXNy L2dhbWVzOi9zYmluOi9iaW46L3Vzci9zYmluOi91c3IvYmluIC91c3Ivb2JqL3Vzci9zcmMvbWFr ZS5pMzg2L21ha2UgLWYgTWFrZWZpbGUuaW5jMSBwYXItY2xlYW5kaXINCj09PT4gc2hhcmUvaW5m bw0KPT09PiBpbmNsdWRlDQo9PT0+IGluY2x1ZGUvYXJwYQ0KPT09PiBpbmNsdWRlL3Byb3RvY29s cw0KPT09PiBpbmNsdWRlL3JwY3N2Yw0Kcm0gLWYga2V5X3Byb3QuaCBrbG1fcHJvdC5oIG1vdW50 LmggbmZzX3Byb3QuaCBubG1fcHJvdC5oIHJleC5oIHJudXNlcnMuaCAgcnF1b3RhLmggcnN0YXQu aCByd2FsbC5oIHNtX2ludGVyLmggc3ByYXkuaCB5cHBhc3N3ZC5oIHlwLmggIHlweGZyZC5oIHlw dXBkYXRlX3Byb3QuaCBuaXMuaCBuaXNfY2FjaGUuaCBuaXNfY2FsbGJhY2suaCAgYm9vdHBhcmFt X3Byb3QuaCBjcnlwdC5oDQo9PT0+IGluY2x1ZGUvcnBjDQpybSAtZiBycGNiX3Byb3QuaA0KPT09 PiBsaWINCj09PT4gbGliL2NzdS9pMzg2LWVsZg0KPT09PiBsaWIvbGliY29tX2Vycg0KPT09PiBs aWIvbGliY29tX2Vyci9kb2MNCnJtIC1mIGNvbV9lcnIuaW5mbyBjb21fZXJyLmluZm8uZ3oNCj09 PT4gbGliL2xpYmNyeXB0DQo9PT0+IGxpYi9saWJrdm0NCj09PT4gbGliL21zdW4NCj09PT4gbGli L2xpYm1kDQo9PT0+IGxpYi9saWJuY3Vyc2VzDQo9PT0+IGxpYi9saWJuZXRncmFwaA0KPT09PiBs aWIvbGlicmFkaXVzDQo9PT0+IGxpYi9saWJycGNzdmMNCj09PT4gbGliL2xpYnNidWYNCj09PT4g bGliL2xpYnRhY3BsdXMNCj09PT4gbGliL2xpYnV0aWwNCj09PT4gbGliL2xpYnlwY2xudA0KPT09 PiBsaWIvY29tcGF0DQo9PT0+IGxpYi9jb21wYXQvY29tcGF0M3guaTM4Ng0Kcm0gLWYgbGliYWxp YXMuc28uMyBsaWJjLnNvLjMgbGliY19yLnNvLjMgbGliY19yLnNvLjQgbGliY3Vyc2VzLnNvLjIg IGxpYmRpYWxvZy5zby4zIGxpYmVkaXQuc28uMiBsaWJmMmMuc28uMiBsaWJmZXRjaC5zby4xIGxp YmZ0cGlvLnNvLjQgIGxpYmcrKy5zby40IGxpYmhpc3Rvcnkuc28uMyBsaWJteXRpbmZvLnNvLjIg bGlibmN1cnNlcy5zby4zICBsaWJwZXJsLnNvLjMgbGlicmVhZGxpbmUuc28uMyBsaWJzcy5zby4y IGxpYnN0ZGMrKy5zby4yICBsaWJ0ZXJtY2FwLnNvLjIgbGlidXRpbC5zby4yIGxpYnZnbC5zby4x IGxpYndyYXAuc28uMiBsaWJ4cGc0LnNvLjINCj09PT4gbGliL2NvbXBhdC9jb21wYXQ0eC5pMzg2 DQo9PT0+IGxpYi9saWJhbGlhcw0KPT09PiBsaWIvbGliYXJjaGl2ZQ0KPT09PiBsaWIvbGliYXRt DQo9PT0+IGxpYi9saWJiaW5kDQo9PT0+IGxpYi9saWJibHVldG9vdGgNCj09PT4gbGliL2xpYmJz bm1wDQo9PT0+IGxpYi9saWJic25tcC9saWJic25tcA0KPT09PiBsaWIvbGliYnNubXAvbW9kdWxl cw0KPT09PiBsaWIvbGliYnNubXAvbW9kdWxlcy9zbm1wX2F0bQ0Kcm0gLWYgYXRtX29pZC5oIGF0 bV90cmVlLmMgYXRtX3RyZWUuaCBzbm1wX2F0bS4zLmd6IHNubXBfYXRtLjMuY2F0Lmd6DQpybSAt ZiBzbm1wX2F0bS5TbyBhdG1fc3lzLlNvIGF0bV90cmVlLlNvIHNubXBfYXRtLnNvIGF0bV9zeXMu c28gYXRtX3RyZWUuc28gc25tcF9hdG0uU28udG1wIGF0bV9zeXMuU28udG1wIGF0bV90cmVlLlNv LnRtcA0Kcm0gLWYgc25tcF9hdG0uc28NCnJtIC1mIHNubXBfYXRtLnNvLjINCnJtIC1mIC5kZXBl bmQgR1BBVEggR1JUQUdTIEdTWU1TIEdUQUdTDQo9PT0+IGxpYi9saWJic25tcC9tb2R1bGVzL3Nu bXBfbWliSUkNCnJtIC1mIG1pYklJX29pZC5oIG1pYklJX3RyZWUuYyBtaWJJSV90cmVlLmggc25t cF9taWJJSS4zLmd6IHNubXBfbWliSUkuMy5jYXQuZ3oNCnJtIC1mIG1pYklJLlNvIG1pYklJX2lm bWliLlNvIG1pYklJX2lwLlNvIG1pYklJX2ludGVyZmFjZXMuU28gbWliSUlfaXBhZGRyLlNvIG1p YklJX2lmc3RhY2suU28gbWliSUlfcmN2YWRkci5TbyBtaWJJSV9uZXR0b21lZGlhLlNvIG1pYklJ X3RjcC5TbyBtaWJJSV91ZHAuU28gbWliSUlfcm91dGUuU28gbWliSUlfdHJlZS5TbyBtaWJJSS5z byBtaWJJSV9pZm1pYi5zbyBtaWJJSV9pcC5zbyBtaWJJSV9pbnRlcmZhY2VzLnNvIG1pYklJX2lw YWRkci5zbyBtaWJJSV9pZnN0YWNrLnNvIG1pYklJX3JjdmFkZHIuc28gbWliSUlfbmV0dG9tZWRp YS5zbyBtaWJJSV90Y3Auc28gbWliSUlfdWRwLnNvIG1pYklJX3JvdXRlLnNvIG1pYklJX3RyZWUu c28gbWliSUkuU28udG1wIG1pYklJX2lmbWliLlNvLnRtcCBtaWJJSV9pcC5Tby50bXAgbWliSUlf aW50ZXJmYWNlcy5Tby50bXAgbWliSUlfaXBhZGRyLlNvLnRtcCBtaWJJSV9pZnN0YWNrLlNvLnRt cCBtaWJJSV9yY3ZhZGRyLlNvLnRtcCBtaWJJSV9uZXR0b21lZGlhLlNvLnRtcCBtaWJJSV90Y3Au U28udG1wIG1pYklJX3VkcC5Tby50bXAgbWliSUlfcm91dGUuU28udG1wIG1pYklJX3RyZWUuU28u dG1wDQpybSAtZiBzbm1wX21pYklJLnNvDQpybSAtZiBzbm1wX21pYklJLnNvLjINCnJtIC1mIC5k ZXBlbmQgR1BBVEggR1JUQUdTIEdTWU1TIEdUQUdTDQo9PT0+IGxpYi9saWJic25tcC9tb2R1bGVz L3NubXBfbmV0Z3JhcGgNCnJtIC1mIG5ldGdyYXBoX29pZC5oIG5ldGdyYXBoX3RyZWUuYyBuZXRn cmFwaF90cmVlLmggc25tcF9uZXRncmFwaC4zLmd6IHNubXBfbmV0Z3JhcGguMy5jYXQuZ3oNCnJt IC1mIHNubXBfbmV0Z3JhcGguU28gbmV0Z3JhcGhfdHJlZS5TbyBzbm1wX25ldGdyYXBoLnNvIG5l dGdyYXBoX3RyZWUuc28gc25tcF9uZXRncmFwaC5Tby50bXAgbmV0Z3JhcGhfdHJlZS5Tby50bXAN CnJtIC1mIHNubXBfbmV0Z3JhcGguc28NCnJtIC1mIHNubXBfbmV0Z3JhcGguc28uMg0Kcm0gLWYg LmRlcGVuZCBHUEFUSCBHUlRBR1MgR1NZTVMgR1RBR1MNCj09PT4gbGliL2xpYmJ6Mg0KPT09PiBs aWIvbGliYw0KPT09PiBsaWIvbGliY19yDQo9PT0+IGxpYi9saWJjYWxlbmRhcg0KPT09PiBsaWIv bGliY2FtDQo9PT0+IGxpYi9saWJjb21wYXQNCj09PT4gbGliL2xpYmRldmluZm8NCj09PT4gbGli L2xpYmRldnN0YXQNCj09PT4gbGliL2xpYmRpc2sNCj09PT4gbGliL2xpYmVkaXQNCj09PT4gbGli L2xpYmV4cGF0DQo9PT0+IGxpYi9saWJmZXRjaA0KPT09PiBsaWIvbGliZm9ybQ0KPT09PiBsaWIv bGliZnRwaW8NCj09PT4gbGliL2xpYmdlb20NCj09PT4gbGliL2xpYmlwc2VjDQo9PT0+IGxpYi9s aWJpcHgNCj09PT4gbGliL2xpYmlzYw0KPT09PiBsaWIvbGlia2ljb252DQo9PT0+IGxpYi9saWJt YWdpYw0KPT09PiBsaWIvbGlibWVudQ0KPT09PiBsaWIvbGlibXANCj09PT4gbGliL2xpYm5jcA0K PT09PiBsaWIvbGlibmdhdG0NCj09PT4gbGliL2xpYm9waWUNCj09PT4gbGliL2xpYnBhbQ0KPT09 PiBsaWIvbGlicGFtL21vZHVsZXMNCj09PT4gbGliL2xpYnBhbS9tb2R1bGVzL3BhbV9jaHJvb3QN Cj09PT4gbGliL2xpYnBhbS9tb2R1bGVzL3BhbV9kZW55DQo9PT0+IGxpYi9saWJwYW0vbW9kdWxl cy9wYW1fZWNobw0KPT09PiBsaWIvbGlicGFtL21vZHVsZXMvcGFtX2V4ZWMNCj09PT4gbGliL2xp YnBhbS9tb2R1bGVzL3BhbV9mdHB1c2Vycw0KPT09PiBsaWIvbGlicGFtL21vZHVsZXMvcGFtX2dy b3VwDQo9PT0+IGxpYi9saWJwYW0vbW9kdWxlcy9wYW1fZ3Vlc3QNCj09PT4gbGliL2xpYnBhbS9t b2R1bGVzL3BhbV9sYXN0bG9nDQo9PT0+IGxpYi9saWJwYW0vbW9kdWxlcy9wYW1fbG9naW5fYWNj ZXNzDQo9PT0+IGxpYi9saWJwYW0vbW9kdWxlcy9wYW1fbm9sb2dpbg0KPT09PiBsaWIvbGlicGFt L21vZHVsZXMvcGFtX29waWUNCj09PT4gbGliL2xpYnBhbS9tb2R1bGVzL3BhbV9vcGllYWNjZXNz DQo9PT0+IGxpYi9saWJwYW0vbW9kdWxlcy9wYW1fcGFzc3dkcWMNCj09PT4gbGliL2xpYnBhbS9t b2R1bGVzL3BhbV9wZXJtaXQNCj09PT4gbGliL2xpYnBhbS9tb2R1bGVzL3BhbV9yYWRpdXMNCj09 PT4gbGliL2xpYnBhbS9tb2R1bGVzL3BhbV9yaG9zdHMNCj09PT4gbGliL2xpYnBhbS9tb2R1bGVz L3BhbV9yb290b2sNCj09PT4gbGliL2xpYnBhbS9tb2R1bGVzL3BhbV9zZWN1cmV0dHkNCj09PT4g bGliL2xpYnBhbS9tb2R1bGVzL3BhbV9zZWxmDQo9PT0+IGxpYi9saWJwYW0vbW9kdWxlcy9wYW1f c3NoDQo9PT0+IGxpYi9saWJwYW0vbW9kdWxlcy9wYW1fdGFjcGx1cw0KPT09PiBsaWIvbGlicGFt L21vZHVsZXMvcGFtX3VuaXgNCj09PT4gbGliL2xpYnBhbS9saWJwYW0NCj09PT4gbGliL2xpYnBh bmVsDQo9PT0+IGxpYi9saWJwY2FwDQo9PT0+IGxpYi9saWJwdGhyZWFkDQo9PT0+IGxpYi9saWJz ZHANCj09PT4gbGliL2xpYnNtYg0KPT09PiBsaWIvbGlic3RhbmQNCj09PT4gbGliL2xpYnRlbG5l dA0KPT09PiBsaWIvbGlidGhyDQo9PT0+IGxpYi9saWJ0aHJlYWRfZGINCj09PT4gbGliL2xpYnVm cw0KPT09PiBsaWIvbGlidWdpZGZ3DQo9PT0+IGxpYi9saWJ1c2JoaWQNCj09PT4gbGliL2xpYnZn bA0KPT09PiBsaWIvbGlid3JhcA0KPT09PiBsaWIvbGlieHBnNA0KPT09PiBsaWIvbGlieQ0KPT09 PiBsaWIvbGlieg0KPT09PiBsaWJleGVjDQo9PT0+IGxpYmV4ZWMvYXRydW4NCj09PT4gbGliZXhl Yy9ib290cGQNCj09PT4gbGliZXhlYy9ib290cGQvYm9vdHBndw0Kcm0gLWYgYm9vdHBndyBib290 cGd3Lm8gZ2V0aWYubyBod2FkZHIubyByZXBvcnQubyBydG1zZy5vDQpybSAtZiAuZGVwZW5kIEdQ QVRIIEdSVEFHUyBHU1lNUyBHVEFHUw0KPT09PiBsaWJleGVjL2Jvb3RwZC90b29scw0KPT09PiBs aWJleGVjL2Jvb3RwZC90b29scy9ib290cGVmDQpybSAtZiBib290cGVmIGJvb3RwZWYubyBkb3Zl bmQubyByZWFkZmlsZS5vIGhhc2gubyBkdW1wdGFiLm8gbG9va3VwLm8gaHdhZGRyLm8gcmVwb3J0 Lm8gdHpvbmUubyBydG1zZy5vIGJvb3RwZWYuOC5neiBib290cGVmLjguY2F0Lmd6DQpybSAtZiAu ZGVwZW5kIEdQQVRIIEdSVEFHUyBHU1lNUyBHVEFHUw0KPT09PiBsaWJleGVjL2Jvb3RwZC90b29s cy9ib290cHRlc3QNCnJtIC1mIGJvb3RwdGVzdCBib290cHRlc3QubyBnZXRldGhlci5vIGdldGlm Lm8gcHJpbnQtYm9vdHAubyByZXBvcnQubyBib290cHRlc3QuOC5neiBib290cHRlc3QuOC5jYXQu Z3oNCnJtIC1mIC5kZXBlbmQgR1BBVEggR1JUQUdTIEdTWU1TIEdUQUdTDQo9PT0+IGxpYmV4ZWMv Y29tc2F0DQo9PT0+IGxpYmV4ZWMvZmluZ2VyZA0KPT09PiBsaWJleGVjL2Z0cGQNCj09PT4gbGli ZXhlYy9mdHAtcHJveHkNCj09PT4gbGliZXhlYy9nZXROQU1FDQo9PT0+IGxpYmV4ZWMvZ2V0dHkN Cj09PT4gbGliZXhlYy9tYWtla2V5DQo9PT0+IGxpYmV4ZWMvbWtuZXRpZA0KPT09PiBsaWJleGVj L25hbWVkLXhmZXINCj09PT4gbGliZXhlYy9wcHBvZWQNCj09PT4gbGliZXhlYy9wdF9jaG93bg0K PT09PiBsaWJleGVjL3Jib290ZA0KPT09PiBsaWJleGVjL3Jldm5ldGdyb3VwDQo9PT0+IGxpYmV4 ZWMvcmV4ZWNkDQo9PT0+IGxpYmV4ZWMvcmxvZ2luZA0KPT09PiBsaWJleGVjL3JwYy5ycXVvdGFk DQo9PT0+IGxpYmV4ZWMvcnBjLnJzdGF0ZA0KPT09PiBsaWJleGVjL3JwYy5ydXNlcnNkDQo9PT0+ IGxpYmV4ZWMvcnBjLnJ3YWxsZA0KPT09PiBsaWJleGVjL3JwYy5zcHJheWQNCj09PT4gbGliZXhl Yy9yc2hkDQo9PT0+IGxpYmV4ZWMvcnRsZC1lbGYNCj09PT4gbGliZXhlYy9zYXZlLWVudHJvcHkN Cj09PT4gbGliZXhlYy90YWxrZA0KPT09PiBsaWJleGVjL3RjcGQNCj09PT4gbGliZXhlYy90ZWxu ZXRkDQo9PT0+IGxpYmV4ZWMvdGZ0cGQNCj09PT4gbGliZXhlYy95cHhmcg0KPT09PiBiaW4NCj09 PT4gYmluL2NhdA0KPT09PiBiaW4vY2hmbGFncw0KPT09PiBiaW4vY2hpbw0KPT09PiBiaW4vY2ht b2QNCj09PT4gYmluL2NwDQo9PT0+IGJpbi9jc2gNCj09PT4gYmluL2RhdGUNCj09PT4gYmluL2Rk DQo9PT0+IGJpbi9kZg0KPT09PiBiaW4vZG9tYWlubmFtZQ0KPT09PiBiaW4vZWNobw0KPT09PiBi aW4vZWQNCj09PT4gYmluL2V4cHINCj09PT4gYmluL2dldGZhY2wNCj09PT4gYmluL2hvc3RuYW1l DQo9PT0+IGJpbi9rZW52DQo9PT0+IGJpbi9raWxsDQo9PT0+IGJpbi9sbg0KPT09PiBiaW4vbHMN Cj09PT4gYmluL21rZGlyDQo9PT0+IGJpbi9tdg0KPT09PiBiaW4vcGF4DQo9PT0+IGJpbi9wcw0K PT09PiBiaW4vcHdkDQo9PT0+IGJpbi9yY3ANCj09PT4gYmluL3JlYWxwYXRoDQo9PT0+IGJpbi9y bQ0KPT09PiBiaW4vcm1kaXINCj09PT4gYmluL3NldGZhY2wNCj09PT4gYmluL3NoDQo9PT0+IGJp bi9zbGVlcA0KPT09PiBiaW4vc3R0eQ0KPT09PiBiaW4vc3luYw0KPT09PiBiaW4vdGVzdA0KPT09 PiBnbnUNCj09PT4gZ251L2xpYg0KPT09PiBnbnUvbGliL2NzdQ0KPT09PiBnbnUvbGliL2xpYmdj Yw0KPT09PiBnbnUvbGliL2xpYmRpYWxvZw0KPT09PiBnbnUvbGliL2xpYnJlZ2V4DQo9PT0+IGdu dS9saWIvbGlicmVnZXgvZG9jDQpybSAtZiByZWdleC50ZXhpIHJlZ2V4LmluZm8gcmVnZXguaW5m by5neg0KPT09PiBnbnUvbGliL2xpYnJlYWRsaW5lDQo9PT0+IGdudS9saWIvbGlicmVhZGxpbmUv aGlzdG9yeQ0KPT09PiBnbnUvbGliL2xpYnJlYWRsaW5lL2hpc3RvcnkvZG9jDQpybSAtZiBoaXN0 b3J5LmluZm8gaGlzdG9yeS5pbmZvLmd6IGhpc3RvcnkudGV4aQ0KPT09PiBnbnUvbGliL2xpYnJl YWRsaW5lL3JlYWRsaW5lDQo9PT0+IGdudS9saWIvbGlicmVhZGxpbmUvcmVhZGxpbmUvZG9jDQpy bSAtZiByZWFkbGluZS50ZXhpbmZvIHJlYWRsaW5lLmluZm8gcmx1c2VybWFuLmluZm8gcmVhZGxp bmUuaW5mby5neiBybHVzZXJtYW4uaW5mby5neg0KPT09PiBnbnUvbGliL2xpYnN0ZGMrKw0KPT09 PiBnbnUvbGliL2xpYnN1cGMrKw0KPT09PiBnbnUvbGliL2xpYm9iamMNCj09PT4gZ251L2xpYi9s aWJnMmMNCj09PT4gZ251L3Vzci5iaW4NCj09PT4gZ251L3Vzci5iaW4vYmMNCj09PT4gZ251L3Vz ci5iaW4vYmludXRpbHMNCj09PT4gZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5DQo9PT0+ IGdudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZA0KPT09PiBnbnUvdXNyLmJpbi9iaW51dGlscy9s aWJvcGNvZGVzDQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzDQo9PT0+IGdu dS91c3IuYmluL2JpbnV0aWxzL2FkZHIybGluZQ0KPT09PiBnbnUvdXNyLmJpbi9iaW51dGlscy9h cg0KPT09PiBnbnUvdXNyLmJpbi9iaW51dGlscy9hcw0KPT09PiBnbnUvdXNyLmJpbi9iaW51dGls cy9sZA0KPT09PiBnbnUvdXNyLmJpbi9iaW51dGlscy9ubQ0KPT09PiBnbnUvdXNyLmJpbi9iaW51 dGlscy9vYmpjb3B5DQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxzL29iamR1bXANCj09PT4gZ251 L3Vzci5iaW4vYmludXRpbHMvcmFubGliDQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxzL3JlYWRl bGYNCj09PT4gZ251L3Vzci5iaW4vYmludXRpbHMvc2l6ZQ0KPT09PiBnbnUvdXNyLmJpbi9iaW51 dGlscy9zdHJpbmdzDQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxzL3N0cmlwDQo9PT0+IGdudS91 c3IuYmluL2JpbnV0aWxzL2RvYw0KPT09PiBnbnUvdXNyLmJpbi9jYw0KPT09PiBnbnUvdXNyLmJp bi9jYy9jY190b29scw0KPT09PiBnbnUvdXNyLmJpbi9jYy9jY19pbnQNCj09PT4gZ251L3Vzci5i aW4vY2MvY2MNCj09PT4gZ251L3Vzci5iaW4vY2MvY2MxDQo9PT0+IGdudS91c3IuYmluL2NjL2lu Y2x1ZGUNCj09PT4gZ251L3Vzci5iaW4vY2MvcHJvdG9pemUNCj09PT4gZ251L3Vzci5iaW4vY2Mv ZG9jDQo9PT0+IGdudS91c3IuYmluL2NjL2NwcA0KPT09PiBnbnUvdXNyLmJpbi9jYy9jYzFwbHVz DQo9PT0+IGdudS91c3IuYmluL2NjL2MrKw0KPT09PiBnbnUvdXNyLmJpbi9jYy9jYzFvYmoNCj09 PT4gZ251L3Vzci5iaW4vY2MvZjc3DQo9PT0+IGdudS91c3IuYmluL2NjL2Y3NzENCj09PT4gZ251 L3Vzci5iaW4vY2MvZjc3ZG9jDQo9PT0+IGdudS91c3IuYmluL2NjL2djb3YNCj09PT4gZ251L3Vz ci5iaW4vY3Bpbw0KPT09PiBnbnUvdXNyLmJpbi9jcGlvL2RvYw0Kcm0gLWYgY3Bpby5pbmZvIGNw aW8uaW5mby5neg0KPT09PiBnbnUvdXNyLmJpbi9jdnMNCj09PT4gZ251L3Vzci5iaW4vY3ZzL2xp Yg0KPT09PiBnbnUvdXNyLmJpbi9jdnMvbGliZGlmZg0KPT09PiBnbnUvdXNyLmJpbi9jdnMvY3Zz DQo9PT0+IGdudS91c3IuYmluL2N2cy9jb250cmliDQo9PT0+IGdudS91c3IuYmluL2N2cy9jdnNi dWcNCj09PT4gZ251L3Vzci5iaW4vY3ZzL2RvYw0KPT09PiBnbnUvdXNyLmJpbi9kYw0KPT09PiBn bnUvdXNyLmJpbi9kYy9kb2MNCnJtIC1mIGRjLmluZm8gZGMuaW5mby5neg0KPT09PiBnbnUvdXNy LmJpbi9kaWFsb2cNCj09PT4gZ251L3Vzci5iaW4vZGlhbG9nL1RFU1RTDQo9PT0+IGdudS91c3Iu YmluL2RpZmYNCj09PT4gZ251L3Vzci5iaW4vZGlmZi9kb2MNCnJtIC1mIGRpZmYuaW5mbyBkaWZm LmluZm8uZ3oNCj09PT4gZ251L3Vzci5iaW4vZGlmZjMNCj09PT4gZ251L3Vzci5iaW4vZ2RiDQo9 PT0+IGdudS91c3IuYmluL2dkYi9kb2MNCj09PT4gZ251L3Vzci5iaW4vZ2RiL2xpYmdkYg0KPT09 PiBnbnUvdXNyLmJpbi9nZGIvZ2RiDQo9PT0+IGdudS91c3IuYmluL2dkYi9nZGJ0dWkNCj09PT4g Z251L3Vzci5iaW4vZ2RiL2tnZGINCj09PT4gZ251L3Vzci5iaW4vZ3BlcmYNCj09PT4gZ251L3Vz ci5iaW4vZ3BlcmYvZG9jDQpybSAtZiBncGVyZi5pbmZvIGdwZXJmLmluZm8uZ3oNCj09PT4gZ251 L3Vzci5iaW4vZ3JlcA0KPT09PiBnbnUvdXNyLmJpbi9ncmVwL2RvYw0Kcm0gLWYgZ3JlcC5pbmZv IGdyZXAuaW5mby5neg0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZg0KPT09PiBnbnUvdXNyLmJpbi9n cm9mZi9jb250cmliDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL2NvbnRyaWIvbW0NCj09PT4gZ251 L3Vzci5iaW4vZ3JvZmYvZG9jDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL2ZvbnQNCj09PT4gZ251 L3Vzci5iaW4vZ3JvZmYvZm9udC9kZXZYMTAwDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL2ZvbnQv ZGV2WDEwMC0xMg0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9mb250L2Rldlg3NQ0KPT09PiBnbnUv dXNyLmJpbi9ncm9mZi9mb250L2Rldlg3NS0xMg0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9mb250 L2RldmFzY2lpDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL2ZvbnQvZGV2Y3AxMDQ3DQo9PT0+IGdu dS91c3IuYmluL2dyb2ZmL2ZvbnQvZGV2ZHZpDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL2ZvbnQv ZGV2aHRtbA0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9mb250L2RldmtvaTgtcg0KPT09PiBnbnUv dXNyLmJpbi9ncm9mZi9mb250L2RldmxhdGluMQ0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9mb250 L2RldmxicA0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9mb250L2RldmxqNA0KPT09PiBnbnUvdXNy LmJpbi9ncm9mZi9mb250L2RldnBzDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL2ZvbnQvZGV2dXRm OA0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9tYW4NCj09PT4gZ251L3Vzci5iaW4vZ3JvZmYvc3Jj DQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9saWJzDQo9PT0+IGdudS91c3IuYmluL2dyb2Zm L3NyYy9saWJzL2xpYmdyb2ZmDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9saWJzL2xpYmRy aXZlcg0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9zcmMvbGlicy9saWJiaWINCj09PT4gZ251L3Vz ci5iaW4vZ3JvZmYvc3JjL2RldmljZXMNCj09PT4gZ251L3Vzci5iaW4vZ3JvZmYvc3JjL2Rldmlj ZXMvZ3JvZHZpDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9kZXZpY2VzL2dyb2h0bWwNCj09 PT4gZ251L3Vzci5iaW4vZ3JvZmYvc3JjL2RldmljZXMvZ3JvbGJwDQo9PT0+IGdudS91c3IuYmlu L2dyb2ZmL3NyYy9kZXZpY2VzL2dyb2xqNA0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9zcmMvZGV2 aWNlcy9ncm9wcw0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9zcmMvZGV2aWNlcy9ncm90dHkNCj09 PT4gZ251L3Vzci5iaW4vZ3JvZmYvc3JjL3ByZXByb2MNCj09PT4gZ251L3Vzci5iaW4vZ3JvZmYv c3JjL3ByZXByb2MvZXFuDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9wcmVwcm9jL2dybg0K PT09PiBnbnUvdXNyLmJpbi9ncm9mZi9zcmMvcHJlcHJvYy9odG1sDQo9PT0+IGdudS91c3IuYmlu L2dyb2ZmL3NyYy9wcmVwcm9jL3BpYw0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9zcmMvcHJlcHJv Yy9yZWZlcg0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9zcmMvcHJlcHJvYy9zb2VsaW0NCj09PT4g Z251L3Vzci5iaW4vZ3JvZmYvc3JjL3ByZXByb2MvdGJsDQo9PT0+IGdudS91c3IuYmluL2dyb2Zm L3NyYy9yb2ZmDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9yb2ZmL2dyb2ZmDQo9PT0+IGdu dS91c3IuYmluL2dyb2ZmL3NyYy9yb2ZmL2dyb2cNCj09PT4gZ251L3Vzci5iaW4vZ3JvZmYvc3Jj L3JvZmYvbnJvZmYNCj09PT4gZ251L3Vzci5iaW4vZ3JvZmYvc3JjL3JvZmYvcHNyb2ZmDQo9PT0+ IGdudS91c3IuYmluL2dyb2ZmL3NyYy9yb2ZmL3Ryb2ZmDQo9PT0+IGdudS91c3IuYmluL2dyb2Zm L3NyYy91dGlscw0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9zcmMvdXRpbHMvYWRkZnRpbmZvDQo9 PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy91dGlscy9hZm10b2RpdA0KPT09PiBnbnUvdXNyLmJp bi9ncm9mZi9zcmMvdXRpbHMvaHBmdG9kaXQNCj09PT4gZ251L3Vzci5iaW4vZ3JvZmYvc3JjL3V0 aWxzL2luZHhiaWINCj09PT4gZ251L3Vzci5iaW4vZ3JvZmYvc3JjL3V0aWxzL2xrYmliDQo9PT0+ IGdudS91c3IuYmluL2dyb2ZmL3NyYy91dGlscy9sb29rYmliDQo9PT0+IGdudS91c3IuYmluL2dy b2ZmL3NyYy91dGlscy9wZmJ0b3BzDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy91dGlscy90 Zm10b2RpdA0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi90bWFjDQo9PT0+IGdudS91c3IuYmluL2d6 aXANCj09PT4gZ251L3Vzci5iaW4vbWFuDQo9PT0+IGdudS91c3IuYmluL21hbi9saWINCj09PT4g Z251L3Vzci5iaW4vbWFuL21hbg0KPT09PiBnbnUvdXNyLmJpbi9tYW4vbWFucGF0aA0KPT09PiBn bnUvdXNyLmJpbi9tYW4vYXByb3Bvcw0KPT09PiBnbnUvdXNyLmJpbi9wYXRjaA0KPT09PiBnbnUv dXNyLmJpbi9yY3MNCj09PT4gZ251L3Vzci5iaW4vcmNzL2xpYg0KPT09PiBnbnUvdXNyLmJpbi9y Y3MvY2kNCj09PT4gZ251L3Vzci5iaW4vcmNzL2NvDQo9PT0+IGdudS91c3IuYmluL3Jjcy9pZGVu dA0KPT09PiBnbnUvdXNyLmJpbi9yY3MvbWVyZ2UNCj09PT4gZ251L3Vzci5iaW4vcmNzL3Jjcw0K PT09PiBnbnUvdXNyLmJpbi9yY3MvcmNzY2xlYW4NCj09PT4gZ251L3Vzci5iaW4vcmNzL3Jjc2Rp ZmYNCj09PT4gZ251L3Vzci5iaW4vcmNzL3Jjc21lcmdlDQo9PT0+IGdudS91c3IuYmluL3Jjcy9y bG9nDQo9PT0+IGdudS91c3IuYmluL3Jjcy9yY3NmcmVlemUNCj09PT4gZ251L3Vzci5iaW4vc2Rp ZmYNCj09PT4gZ251L3Vzci5iaW4vc2VuZC1wcg0KPT09PiBnbnUvdXNyLmJpbi9zZW5kLXByL2Rv Yw0Kcm0gLWYgc2VuZC1wci5pbmZvIHNlbmQtcHIuaW5mby5neg0KPT09PiBnbnUvdXNyLmJpbi9z b3J0DQo9PT0+IGdudS91c3IuYmluL3Rhcg0KPT09PiBnbnUvdXNyLmJpbi90YXIvZG9jDQpybSAt ZiB0YXIuaW5mbyB0YXIuaW5mby5neg0KPT09PiBnbnUvdXNyLmJpbi90ZXhpbmZvDQo9PT0+IGdu dS91c3IuYmluL3RleGluZm8vbGlidHhpDQo9PT0+IGdudS91c3IuYmluL3RleGluZm8vbWFrZWlu Zm8NCj09PT4gZ251L3Vzci5iaW4vdGV4aW5mby9pbmZvDQo9PT0+IGdudS91c3IuYmluL3RleGlu Zm8vaW5mb2tleQ0KPT09PiBnbnUvdXNyLmJpbi90ZXhpbmZvL2luc3RhbGwtaW5mbw0KPT09PiBn bnUvdXNyLmJpbi90ZXhpbmZvL3RleGluZGV4DQo9PT0+IGdudS91c3IuYmluL3RleGluZm8vZG9j DQo9PT0+IHNiaW4NCj09PT4gc2Jpbi9hZGprZXJudHoNCj09PT4gc2Jpbi9hdGFjb250cm9sDQo9 PT0+IHNiaW4vYXRtDQo9PT0+IHNiaW4vYXRtL2F0bQ0KPT09PiBzYmluL2F0bS9hdG1jb25maWcN Cj09PT4gc2Jpbi9hdG0vZm9yZV9kbmxkDQo9PT0+IHNiaW4vYXRtL2lsbWlkDQo9PT0+IHNiaW4v YmFkc2VjdA0KPT09PiBzYmluL2JzZGxhYmVsDQo9PT0+IHNiaW4vY2FtY29udHJvbA0KPT09PiBz YmluL2NjZGNvbmZpZw0KPT09PiBzYmluL2NscmkNCj09PT4gc2Jpbi9jb21jb250cm9sDQo9PT0+ IHNiaW4vY29uc2NvbnRyb2wNCj09PT4gc2Jpbi9kZXZkDQo9PT0+IHNiaW4vZGV2ZnMNCj09PT4g c2Jpbi9kaGNsaWVudA0KPT09PiBzYmluL2RoY2xpZW50L2NvbW1vbg0KPT09PiBzYmluL2RoY2xp ZW50L2RzdA0KPT09PiBzYmluL2RoY2xpZW50L21pbmlyZXMNCj09PT4gc2Jpbi9kaGNsaWVudC9v bWFwaXANCj09PT4gc2Jpbi9kaGNsaWVudC9kaGNwY3RsDQo9PT0+IHNiaW4vZGhjbGllbnQvY2xp ZW50DQo9PT0+IHNiaW4vZGhjbGllbnQvb21zaGVsbA0KPT09PiBzYmluL2RtZXNnDQo9PT0+IHNi aW4vZHVtcA0KPT09PiBzYmluL2R1bXBmcw0KPT09PiBzYmluL2R1bXBvbg0KPT09PiBzYmluL2Zk aXNrDQo9PT0+IHNiaW4vZmZzaW5mbw0KPT09PiBzYmluL2ZzY2sNCj09PT4gc2Jpbi9mc2NrX2Zm cw0KPT09PiBzYmluL2ZzY2tfbXNkb3Nmcw0KPT09PiBzYmluL2ZzZGINCj09PT4gc2Jpbi9mc2ly YW5kDQo9PT0+IHNiaW4vZ2JkZQ0KPT09PiBzYmluL2dlb20NCj09PT4gc2Jpbi9nZW9tL2NvcmUN Cj09PT4gc2Jpbi9nZW9tL2NsYXNzDQo9PT0+IHNiaW4vZ2VvbS9jbGFzcy9jb25jYXQNCj09PT4g c2Jpbi9nZW9tL2NsYXNzL2xhYmVsDQo9PT0+IHNiaW4vZ2VvbS9jbGFzcy9taXJyb3INCj09PT4g c2Jpbi9nZW9tL2NsYXNzL25vcA0KPT09PiBzYmluL2dlb20vY2xhc3Mvc3RyaXBlDQo9PT0+IHNi aW4vZ2dhdGUNCj09PT4gc2Jpbi9nZ2F0ZS9nZ2F0ZWwNCj09PT4gc2Jpbi9nZ2F0ZS9nZ2F0ZWMN Cj09PT4gc2Jpbi9nZ2F0ZS9nZ2F0ZWQNCj09PT4gc2Jpbi9ncHQNCj09PT4gc2Jpbi9ncm93ZnMN Cj09PT4gc2Jpbi9ndmludW0NCj09PT4gc2Jpbi9pZmNvbmZpZw0KPT09PiBzYmluL2luaXQNCj09 PT4gc2Jpbi9pcDZmdw0KPT09PiBzYmluL2lwZg0KPT09PiBzYmluL2lwZnMNCj09PT4gc2Jpbi9p cGZzdGF0DQo9PT0+IHNiaW4vaXBmdw0KPT09PiBzYmluL2lwbW9uDQo9PT0+IHNiaW4vaXBuYXQN Cj09PT4gc2Jpbi9rbGRjb25maWcNCj09PT4gc2Jpbi9rbGRsb2FkDQo9PT0+IHNiaW4va2xkc3Rh dA0KPT09PiBzYmluL2tsZHVubG9hZA0KPT09PiBzYmluL2xkY29uZmlnDQo9PT0+IHNiaW4vbWQ1 DQo9PT0+IHNiaW4vbWRjb25maWcNCj09PT4gc2Jpbi9tZG1mcw0KPT09PiBzYmluL21rbm9kDQo9 PT0+IHNiaW4vbWtzbmFwX2Zmcw0KPT09PiBzYmluL21vdW50DQo9PT0+IHNiaW4vbW91bnRfY2Q5 NjYwDQo9PT0+IHNiaW4vbW91bnRfZXh0MmZzDQo9PT0+IHNiaW4vbW91bnRfbXNkb3Nmcw0KPT09 PiBzYmluL21vdW50X25mcw0KPT09PiBzYmluL21vdW50X25mczQNCj09PT4gc2Jpbi9tb3VudF9u dGZzDQo9PT0+IHNiaW4vbW91bnRfbnVsbGZzDQo9PT0+IHNiaW4vbW91bnRfc3RkDQo9PT0+IHNi aW4vbW91bnRfdWRmDQo9PT0+IHNiaW4vbW91bnRfdW1hcGZzDQo9PT0+IHNiaW4vbW91bnRfdW5p b25mcw0KPT09PiBzYmluL25hdGQNCj09PT4gc2Jpbi9uZXdmcw0KPT09PiBzYmluL25ld2ZzX21z ZG9zDQo9PT0+IHNiaW4vbmZzaW9kDQo9PT0+IHNiaW4vbm9zLXR1bg0KPT09PiBzYmluL3BmY3Rs DQo9PT0+IHNiaW4vcGZsb2dkDQo9PT0+IHNiaW4vcGluZw0KPT09PiBzYmluL3Bpbmc2DQo9PT0+ IHNiaW4vcXVvdGFjaGVjaw0KPT09PiBzYmluL3Jjb3JkZXINCj09PT4gc2Jpbi9yZWJvb3QNCj09 PT4gc2Jpbi9yZXN0b3JlDQo9PT0+IHNiaW4vcm91dGUNCj09PT4gc2Jpbi9yb3V0ZWQNCj09PT4g c2Jpbi9yb3V0ZWQvcnRxdWVyeQ0Kcm0gLWYgcnRxdWVyeSBydHF1ZXJ5Lm8gcnRxdWVyeS44Lmd6 IHJ0cXVlcnkuOC5jYXQuZ3oNCnJtIC1mIC5kZXBlbmQgR1BBVEggR1JUQUdTIEdTWU1TIEdUQUdT DQo9PT0+IHNiaW4vcnRzb2wNCj09PT4gc2Jpbi9zYXZlY29yZQ0KPT09PiBzYmluL3Njb25maWcN Cj09PT4gc2Jpbi9zaHV0ZG93bg0KPT09PiBzYmluL3NsYXR0YWNoDQo9PT0+IHNiaW4vc3BwcGNv bnRyb2wNCj09PT4gc2Jpbi9zdGFydHNsaXANCj09PT4gc2Jpbi9zdW5sYWJlbA0KPT09PiBzYmlu L3N3YXBvbg0KPT09PiBzYmluL3N5c2N0bA0KPT09PiBzYmluL3R1bmVmcw0KPT09PiBzYmluL3Vt b3VudA0KPT09PiBzYmluL3ZpbnVtDQo9PT0+IHNlY3VyZQ0KPT09PiBzZWN1cmUvbGliDQo9PT0+ IHNlY3VyZS9saWIvbGliY3J5cHRvDQo9PT0+IHNlY3VyZS9saWIvbGlic3NsDQo9PT0+IHNlY3Vy ZS9saWIvbGlic3NoDQo9PT0+IHNlY3VyZS9saWJleGVjDQo9PT0+IHNlY3VyZS9saWJleGVjL3Nm dHAtc2VydmVyDQo9PT0+IHNlY3VyZS9saWJleGVjL3NzaC1rZXlzaWduDQo9PT0+IHNlY3VyZS91 c3IuYmluDQo9PT0+IHNlY3VyZS91c3IuYmluL2JkZXMNCj09PT4gc2VjdXJlL3Vzci5iaW4vb3Bl bnNzbA0KPT09PiBzZWN1cmUvdXNyLmJpbi9zY3ANCj09PT4gc2VjdXJlL3Vzci5iaW4vc2Z0cA0K PT09PiBzZWN1cmUvdXNyLmJpbi9zc2gNCj09PT4gc2VjdXJlL3Vzci5iaW4vc3NoLWFkZA0KPT09 PiBzZWN1cmUvdXNyLmJpbi9zc2gtYWdlbnQNCj09PT4gc2VjdXJlL3Vzci5iaW4vc3NoLWtleWdl bg0KPT09PiBzZWN1cmUvdXNyLmJpbi9zc2gta2V5c2Nhbg0KPT09PiBzZWN1cmUvdXNyLnNiaW4N Cj09PT4gc2VjdXJlL3Vzci5zYmluL3NzaGQNCj09PT4gc3lzDQo9PT0+IHN5cy9ib290DQo9PT0+ IHN5cy9ib290L2ZpY2wNCj09PT4gc3lzL2Jvb3QvaTM4Ng0KPT09PiBzeXMvYm9vdC9pMzg2L21i cg0KPT09PiBzeXMvYm9vdC9pMzg2L2Jvb3QwDQo9PT0+IHN5cy9ib290L2kzODYvYm9vdDBzaW8N Cj09PT4gc3lzL2Jvb3QvaTM4Ni9idHgNCj09PT4gc3lzL2Jvb3QvaTM4Ni9idHgvYnR4DQo9PT0+ IHN5cy9ib290L2kzODYvYnR4L2J0eGxkcg0KPT09PiBzeXMvYm9vdC9pMzg2L2J0eC9saWINCj09 PT4gc3lzL2Jvb3QvaTM4Ni9ib290Mg0KPT09PiBzeXMvYm9vdC9pMzg2L2NkYm9vdA0KPT09PiBz eXMvYm9vdC9pMzg2L2tnemxkcg0KPT09PiBzeXMvYm9vdC9pMzg2L2xpYmkzODYNCj09PT4gc3lz L2Jvb3QvaTM4Ni9sb2FkZXINCj09PT4gc3lzL2Jvb3QvaTM4Ni9weGVsZHINCj09PT4gdXNyLmJp bg0KPT09PiB1c3IuYmluL2FsaWFzDQo9PT0+IHVzci5iaW4vYXBwbHkNCj09PT4gdXNyLmJpbi9h c2ENCj09PT4gdXNyLmJpbi9hdA0KPT09PiB1c3IuYmluL2F0bQ0KPT09PiB1c3IuYmluL2F0bS9z c2NvcA0KPT09PiB1c3IuYmluL2F3aw0KPT09PiB1c3IuYmluL2Jhbm5lcg0KPT09PiB1c3IuYmlu L2Jhc2VuYW1lDQo9PT0+IHVzci5iaW4vYmlmZg0KPT09PiB1c3IuYmluL2JsdWV0b290aA0KPT09 PiB1c3IuYmluL2JsdWV0b290aC9idGhvc3QNCj09PT4gdXNyLmJpbi9ibHVldG9vdGgvYnRzb2Nr c3RhdA0KPT09PiB1c3IuYmluL2JsdWV0b290aC9yZmNvbW1fc3BwZA0KPT09PiB1c3IuYmluL2Jy YW5kZWxmDQo9PT0+IHVzci5iaW4vYnppcDINCj09PT4gdXNyLmJpbi9iemlwMi9kb2MNCnJtIC1m IGJ6aXAyLnRleGkgYnppcDIudGV4aS5vcmlnIGJ6aXAyLmluZm8gYnppcDIuaW5mby5neg0KPT09 PiB1c3IuYmluL2J6aXAycmVjb3Zlcg0KPT09PiB1c3IuYmluL2M4OQ0KPT09PiB1c3IuYmluL2M5 OQ0KPT09PiB1c3IuYmluL2NhbGVuZGFyDQo9PT0+IHVzci5iaW4vY2FwX21rZGINCj09PT4gdXNy LmJpbi9jYXRtYW4NCj09PT4gdXNyLmJpbi9jaGF0DQo9PT0+IHVzci5iaW4vY2hlY2tucg0KPT09 PiB1c3IuYmluL2Noa2V5DQo9PT0+IHVzci5iaW4vY2hwYXNzDQo9PT0+IHVzci5iaW4vY2tzdW0N Cj09PT4gdXNyLmJpbi9jbXANCj09PT4gdXNyLmJpbi9jb2wNCj09PT4gdXNyLmJpbi9jb2xjcnQN Cj09PT4gdXNyLmJpbi9jb2xsZGVmDQo9PT0+IHVzci5iaW4vY29scm0NCj09PT4gdXNyLmJpbi9j b2x1bW4NCj09PT4gdXNyLmJpbi9jb21tDQo9PT0+IHVzci5iaW4vY29tcGlsZV9ldA0KPT09PiB1 c3IuYmluL2NvbXByZXNzDQo9PT0+IHVzci5iaW4vY3NwbGl0DQo9PT0+IHVzci5iaW4vY3RhZ3MN Cj09PT4gdXNyLmJpbi9jdXQNCj09PT4gdXNyLmJpbi9kaWcNCj09PT4gdXNyLmJpbi9kaXJuYW1l DQo9PT0+IHVzci5iaW4vZG5za2V5Z2VuDQo9PT0+IHVzci5iaW4vZG5zcXVlcnkNCj09PT4gdXNy LmJpbi9kdQ0KPT09PiB1c3IuYmluL2VlDQo9PT0+IHVzci5iaW4vZWxmMmFvdXQNCj09PT4gdXNy LmJpbi9lbGZkdW1wDQo9PT0+IHVzci5iaW4vZW5pZ21hDQo9PT0+IHVzci5iaW4vZW52DQo9PT0+ IHVzci5iaW4vZXhwYW5kDQo9PT0+IHVzci5iaW4vZmFsc2UNCj09PT4gdXNyLmJpbi9mZXRjaA0K PT09PiB1c3IuYmluL2ZpbGUNCj09PT4gdXNyLmJpbi9maWxlMmMNCj09PT4gdXNyLmJpbi9maW5k DQo9PT0+IHVzci5iaW4vZmluZ2VyDQo9PT0+IHVzci5iaW4vZm10DQo9PT0+IHVzci5iaW4vZm9s ZA0KPT09PiB1c3IuYmluL2Zyb20NCj09PT4gdXNyLmJpbi9mc3RhdA0KPT09PiB1c3IuYmluL2Zz eW5jDQo9PT0+IHVzci5iaW4vZnRwDQo9PT0+IHVzci5iaW4vZ2NvcmUNCj09PT4gdXNyLmJpbi9n ZW5jYXQNCj09PT4gdXNyLmJpbi9nZXRjb25mDQo9PT0+IHVzci5iaW4vZ2V0b3B0DQo9PT0+IHVz ci5iaW4vZ3Byb2YNCj09PT4gdXNyLmJpbi9oZWFkDQo9PT0+IHVzci5iaW4vaGVzaW5mbw0KPT09 PiB1c3IuYmluL2hleGR1bXANCj09PT4gdXNyLmJpbi9ob3N0DQo9PT0+IHVzci5iaW4vaWQNCj09 PT4gdXNyLmJpbi9pbmRlbnQNCj09PT4gdXNyLmJpbi9pcGNybQ0KPT09PiB1c3IuYmluL2lwY3MN Cj09PT4gdXNyLmJpbi9qb2luDQo9PT0+IHVzci5iaW4vam90DQo9PT0+IHVzci5iaW4va2R1bXAN Cj09PT4gdXNyLmJpbi9rZXlsb2dpbg0KPT09PiB1c3IuYmluL2tleWxvZ291dA0KPT09PiB1c3Iu YmluL2tpbGxhbGwNCj09PT4gdXNyLmJpbi9rdHJhY2UNCj09PT4gdXNyLmJpbi9rdHJkdW1wDQo9 PT0+IHVzci5iaW4vbGFtDQo9PT0+IHVzci5iaW4vbGFzdA0KPT09PiB1c3IuYmluL2xhc3Rjb21t DQo9PT0+IHVzci5iaW4vbGRkDQo9PT0+IHVzci5iaW4vbGVhdmUNCj09PT4gdXNyLmJpbi9sZXNz DQo9PT0+IHVzci5iaW4vbGVzc2VjaG8NCj09PT4gdXNyLmJpbi9sZXNza2V5DQo9PT0+IHVzci5i aW4vbGV4DQo9PT0+IHVzci5iaW4vbGV4L2xpYg0Kcm0gLWYgYS5vdXQgbGlibWFpbi5vIGxpYnl5 d3JhcC5vIGxpYm1haW4uby50bXAgbGlieXl3cmFwLm8udG1wIA0Kcm0gLWYgbGlibG4uYQ0Kcm0g LWYgLmRlcGVuZCBHUEFUSCBHUlRBR1MgR1NZTVMgR1RBR1MNCj09PT4gdXNyLmJpbi9saW1pdHMN Cj09PT4gdXNyLmJpbi9sb2NhbGUNCj09PT4gdXNyLmJpbi9sb2NhdGUNCj09PT4gdXNyLmJpbi9s b2NhdGUvYmlncmFtDQo9PT0+IHVzci5iaW4vbG9jYXRlL2NvZGUNCj09PT4gdXNyLmJpbi9sb2Nh dGUvbG9jYXRlDQo9PT0+IHVzci5iaW4vbG9jaw0KPT09PiB1c3IuYmluL2xvY2tmDQo9PT0+IHVz ci5iaW4vbG9nZ2VyDQo9PT0+IHVzci5iaW4vbG9naW4NCj09PT4gdXNyLmJpbi9sb2dpbnMNCj09 PT4gdXNyLmJpbi9sb2duYW1lDQo9PT0+IHVzci5iaW4vbG9vaw0KPT09PiB1c3IuYmluL2xvcmRl cg0KPT09PiB1c3IuYmluL2xzdmZzDQo9PT0+IHVzci5iaW4vbTQNCj09PT4gdXNyLmJpbi9tYWls DQo9PT0+IHVzci5iaW4vbWFrZQ0KPT09PiB1c3IuYmluL21ha2V3aGF0aXMNCj09PT4gdXNyLmJp bi9tZXNnDQo9PT0+IHVzci5iaW4vbWluaWd6aXANCj09PT4gdXNyLmJpbi9ta2RlcA0KPT09PiB1 c3IuYmluL21rZmlmbw0KPT09PiB1c3IuYmluL21rbG9jYWxlDQo9PT0+IHVzci5iaW4vbWtzdHIN Cj09PT4gdXNyLmJpbi9ta3RlbXANCj09PT4gdXNyLmJpbi9tc2dzDQo9PT0+IHVzci5iaW4vbXQN Cj09PT4gdXNyLmJpbi9uY2FsDQo9PT0+IHVzci5iaW4vbmNwbGlzdA0KPT09PiB1c3IuYmluL25j cGxvZ2luDQo9PT0+IHVzci5iaW4vbmV0c3RhdA0KPT09PiB1c3IuYmluL25ld2dycA0KPT09PiB1 c3IuYmluL25ld2tleQ0KPT09PiB1c3IuYmluL25mc3N0YXQNCj09PT4gdXNyLmJpbi9uaWNlDQo9 PT0+IHVzci5iaW4vbmwNCj09PT4gdXNyLmJpbi9ub2h1cA0KPT09PiB1c3IuYmluL29iamZvcm1h dA0KPT09PiB1c3IuYmluL29waWVpbmZvDQo9PT0+IHVzci5iaW4vb3BpZWtleQ0KPT09PiB1c3Iu YmluL29waWVwYXNzd2QNCj09PT4gdXNyLmJpbi9wYWdlc2l6ZQ0KPT09PiB1c3IuYmluL3Bhc3N3 ZA0KPT09PiB1c3IuYmluL3Bhc3RlDQo9PT0+IHVzci5iaW4vcGF0aGNoaw0KPT09PiB1c3IuYmlu L3BraWxsDQo9PT0+IHVzci5iaW4vcHINCj09PT4gdXNyLmJpbi9wcmludGVudg0KPT09PiB1c3Iu YmluL3ByaW50Zg0KPT09PiB1c3IuYmluL3F1b3RhDQo9PT0+IHVzci5iaW4vcmVuaWNlDQo9PT0+ IHVzci5iaW4vcmV2DQo9PT0+IHVzci5iaW4vcmxvZ2luDQo9PT0+IHVzci5iaW4vcnBjZ2VuDQo9 PT0+IHVzci5iaW4vcnBjaW5mbw0KPT09PiB1c3IuYmluL3JzDQo9PT0+IHVzci5iaW4vcnNoDQo9 PT0+IHVzci5iaW4vcnVwDQo9PT0+IHVzci5iaW4vcnVwdGltZQ0KPT09PiB1c3IuYmluL3J1c2Vy cw0KPT09PiB1c3IuYmluL3J3YWxsDQo9PT0+IHVzci5iaW4vcndobw0KPT09PiB1c3IuYmluL3Nj cmlwdA0KPT09PiB1c3IuYmluL3NlZA0KPT09PiB1c3IuYmluL3NoYXINCj09PT4gdXNyLmJpbi9z aG93bW91bnQNCj09PT4gdXNyLmJpbi9zbWJ1dGlsDQo9PT0+IHVzci5iaW4vc29ja3N0YXQNCj09 PT4gdXNyLmJpbi9zcGxpdA0KPT09PiB1c3IuYmluL3N0YXQNCj09PT4gdXNyLmJpbi9zdQ0KPT09 PiB1c3IuYmluL3N5c3RhdA0KPT09PiB1c3IuYmluL3RhYnMNCj09PT4gdXNyLmJpbi90YWlsDQo9 PT0+IHVzci5iaW4vdGFsaw0KPT09PiB1c3IuYmluL3Rhcg0KPT09PiB1c3IuYmluL3Rjb3B5DQo9 PT0+IHVzci5iaW4vdGVlDQo9PT0+IHVzci5iaW4vdGVsbmV0DQo9PT0+IHVzci5iaW4vdGZ0cA0K PT09PiB1c3IuYmluL3RpbWUNCj09PT4gdXNyLmJpbi90aXANCj09PT4gdXNyLmJpbi90aXAvdGlw DQo9PT0+IHVzci5iaW4vdG9wDQo9PT0+IHVzci5iaW4vdG91Y2gNCj09PT4gdXNyLmJpbi90cHV0 DQo9PT0+IHVzci5iaW4vdHINCj09PT4gdXNyLmJpbi90cnVlDQo9PT0+IHVzci5iaW4vdHJ1bmNh dGUNCj09PT4gdXNyLmJpbi90cnVzcw0KPT09PiB1c3IuYmluL3RzZXQNCj09PT4gdXNyLmJpbi90 c29ydA0KPT09PiB1c3IuYmluL3R0eQ0KPT09PiB1c3IuYmluL3VsDQo9PT0+IHVzci5iaW4vdW5h bWUNCj09PT4gdXNyLmJpbi91bmV4cGFuZA0KPT09PiB1c3IuYmluL3VuaWZkZWYNCj09PT4gdXNy LmJpbi91bmlxDQo9PT0+IHVzci5iaW4vdW5pdHMNCj09PT4gdXNyLmJpbi91bnZpcw0KPT09PiB1 c3IuYmluL3VzYmhpZGFjdGlvbg0KPT09PiB1c3IuYmluL3VzYmhpZGN0bA0KPT09PiB1c3IuYmlu L3VzZXJzDQo9PT0+IHVzci5iaW4vdXVkZWNvZGUNCj09PT4gdXNyLmJpbi91dWVuY29kZQ0KPT09 PiB1c3IuYmluL3V1aWRnZW4NCj09PT4gdXNyLmJpbi92Z3JpbmQNCj09PT4gdXNyLmJpbi92aQ0K PT09PiB1c3IuYmluL3Zpcw0KPT09PiB1c3IuYmluL3Ztc3RhdA0KPT09PiB1c3IuYmluL3cNCj09 PT4gdXNyLmJpbi93YWxsDQo9PT0+IHVzci5iaW4vd2MNCj09PT4gdXNyLmJpbi93aGF0DQo9PT0+ IHVzci5iaW4vd2hlcmVpcw0KPT09PiB1c3IuYmluL3doaWNoDQo9PT0+IHVzci5iaW4vd2hvDQo9 PT0+IHVzci5iaW4vd2hvaXMNCj09PT4gdXNyLmJpbi93aW5kb3cNCj09PT4gdXNyLmJpbi93cml0 ZQ0KPT09PiB1c3IuYmluL3hhcmdzDQo9PT0+IHVzci5iaW4veGluc3RhbGwNCj09PT4gdXNyLmJp bi94bGludA0KPT09PiB1c3IuYmluL3hsaW50L2xpbnQxDQo9PT0+IHVzci5iaW4veGxpbnQvbGlu dDINCj09PT4gdXNyLmJpbi94bGludC94bGludA0KPT09PiB1c3IuYmluL3hsaW50L2xsaWINCj09 PT4gdXNyLmJpbi94c3RyDQo9PT0+IHVzci5iaW4veWFjYw0KPT09PiB1c3IuYmluL3llcw0KPT09 PiB1c3IuYmluL3lwY2F0DQo9PT0+IHVzci5iaW4veXBtYXRjaA0KPT09PiB1c3IuYmluL3lwd2hp Y2gNCj09PT4gdXNyLnNiaW4NCj09PT4gdXNyLnNiaW4vYWMNCj09PT4gdXNyLnNiaW4vYWNjdG9u DQo9PT0+IHVzci5zYmluL2FjcGkNCj09PT4gdXNyLnNiaW4vYWNwaS9hY3BpY29uZg0KPT09PiB1 c3Iuc2Jpbi9hY3BpL2FjcGlkYg0KPT09PiB1c3Iuc2Jpbi9hY3BpL2FjcGlkdW1wDQo9PT0+IHVz ci5zYmluL2FjcGkvaWFzbA0KPT09PiB1c3Iuc2Jpbi9hZGR1c2VyDQo9PT0+IHVzci5zYmluL2Ft ZA0KPT09PiB1c3Iuc2Jpbi9hbWQvaW5jbHVkZQ0KPT09PiB1c3Iuc2Jpbi9hbWQvbGliYW11DQo9 PT0+IHVzci5zYmluL2FtZC9hbWQNCj09PT4gdXNyLnNiaW4vYW1kL2FtcQ0KPT09PiB1c3Iuc2Jp bi9hbWQvZG9jDQo9PT0+IHVzci5zYmluL2FtZC9maXhtb3VudA0KPT09PiB1c3Iuc2Jpbi9hbWQv ZnNpbmZvDQo9PT0+IHVzci5zYmluL2FtZC9obGZzZA0KPT09PiB1c3Iuc2Jpbi9hbWQvbWstYW1k LW1hcA0KPT09PiB1c3Iuc2Jpbi9hbWQvcGF3ZA0KPT09PiB1c3Iuc2Jpbi9hbWQvc2NyaXB0cw0K PT09PiB1c3Iuc2Jpbi9hbWQvd2lyZS10ZXN0DQo9PT0+IHVzci5zYmluL2FuY29udHJvbA0KPT09 PiB1c3Iuc2Jpbi9hcG0NCj09PT4gdXNyLnNiaW4vYXBtZA0KPT09PiB1c3Iuc2Jpbi9hcmxjb250 cm9sDQo9PT0+IHVzci5zYmluL2FycA0KPT09PiB1c3Iuc2Jpbi9hc2YNCj09PT4gdXNyLnNiaW4v YXRtDQo9PT0+IHVzci5zYmluL2F0bS9hdG1hcnBkDQo9PT0+IHVzci5zYmluL2F0bS9zY3NwZA0K PT09PiB1c3Iuc2Jpbi9hdXRocGYNCj09PT4gdXNyLnNiaW4vYmx1ZXRvb3RoDQo9PT0+IHVzci5z YmluL2JsdWV0b290aC9iY21mdw0KPT09PiB1c3Iuc2Jpbi9ibHVldG9vdGgvYnQzY2Z3DQo9PT0+ IHVzci5zYmluL2JsdWV0b290aC9oY2NvbnRyb2wNCj09PT4gdXNyLnNiaW4vYmx1ZXRvb3RoL2hj c2VjZA0KPT09PiB1c3Iuc2Jpbi9ibHVldG9vdGgvaGNzZXJpYWxkDQo9PT0+IHVzci5zYmluL2Js dWV0b290aC9sMmNvbnRyb2wNCj09PT4gdXNyLnNiaW4vYmx1ZXRvb3RoL2wycGluZw0KPT09PiB1 c3Iuc2Jpbi9ibHVldG9vdGgvcmZjb21tX3BwcGQNCj09PT4gdXNyLnNiaW4vYmx1ZXRvb3RoL3Nk cGNvbnRyb2wNCj09PT4gdXNyLnNiaW4vYmx1ZXRvb3RoL3NkcGQNCj09PT4gdXNyLnNiaW4vYm9v dDBjZmcNCj09PT4gdXNyLnNiaW4vYm9vdHBhcmFtZA0KPT09PiB1c3Iuc2Jpbi9ib290cGFyYW1k L2Jvb3RwYXJhbWQNCj09PT4gdXNyLnNiaW4vYm9vdHBhcmFtZC9jYWxsYm9vdGQNCj09PT4gdXNy LnNiaW4vYnNubXBkDQo9PT0+IHVzci5zYmluL2Jzbm1wZC9nZW5zbm1wdHJlZQ0KPT09PiB1c3Iu c2Jpbi9ic25tcGQvYnNubXBkDQo9PT0+IHVzci5zYmluL2J0eGxkDQo9PT0+IHVzci5zYmluL2J1 cm5jZA0KPT09PiB1c3Iuc2Jpbi9jZGNvbnRyb2wNCj09PT4gdXNyLnNiaW4vY2hrZ3JwDQo9PT0+ IHVzci5zYmluL2Nob3duDQo9PT0+IHVzci5zYmluL2Nocm9vdA0KPT09PiB1c3Iuc2Jpbi9ja2Rp c3QNCj09PT4gdXNyLnNiaW4vY29uZmlnDQo9PT0+IHVzci5zYmluL2Nyb24NCj09PT4gdXNyLnNi aW4vY3Jvbi9saWINCj09PT4gdXNyLnNiaW4vY3Jvbi9jcm9uDQo9PT0+IHVzci5zYmluL2Nyb24v Y3JvbnRhYg0KPT09PiB1c3Iuc2Jpbi9jcnVuY2gNCj09PT4gdXNyLnNiaW4vY3J1bmNoL2NydW5j aGdlbg0KPT09PiB1c3Iuc2Jpbi9jcnVuY2gvY3J1bmNoaWRlDQo9PT0+IHVzci5zYmluL2N0bQ0K PT09PiB1c3Iuc2Jpbi9jdG0vY3RtDQo9PT0+IHVzci5zYmluL2N0bS9jdG1fcm1haWwNCj09PT4g dXNyLnNiaW4vY3RtL2N0bV9zbWFpbA0KPT09PiB1c3Iuc2Jpbi9jdG0vY3RtX2RlcXVldWUNCj09 PT4gdXNyLnNiaW4vZGFlbW9uDQo9PT0+IHVzci5zYmluL2Rjb25zY2hhdA0KPT09PiB1c3Iuc2Jp bi9kZXZpbmZvDQo9PT0+IHVzci5zYmluL2RpZ2ljdGwNCj09PT4gdXNyLnNiaW4vZGlza2luZm8N Cj09PT4gdXNyLnNiaW4vZWRxdW90YQ0KPT09PiB1c3Iuc2Jpbi9leHRhdHRyDQo9PT0+IHVzci5z YmluL2V4dGF0dHJjdGwNCj09PT4gdXNyLnNiaW4vZmFpdGhkDQo9PT0+IHVzci5zYmluL2ZkY29u dHJvbA0KPT09PiB1c3Iuc2Jpbi9mZGZvcm1hdA0KPT09PiB1c3Iuc2Jpbi9mZHJlYWQNCj09PT4g dXNyLnNiaW4vZmR3cml0ZQ0KPT09PiB1c3Iuc2Jpbi9md2NvbnRyb2wNCj09PT4gdXNyLnNiaW4v Z2V0Zm1hYw0KPT09PiB1c3Iuc2Jpbi9nZXRwbWFjDQo9PT0+IHVzci5zYmluL2dzdGF0DQo9PT0+ IHVzci5zYmluL2lmbWNzdGF0DQo9PT0+IHVzci5zYmluL2luZXRkDQo9PT0+IHVzci5zYmluL2lv c3RhdA0KPT09PiB1c3Iuc2Jpbi9pcDZhZGRyY3RsDQo9PT0+IHVzci5zYmluL2lwZnRlc3QNCj09 PT4gdXNyLnNiaW4vaXByZXNlbmQNCj09PT4gdXNyLnNiaW4vaXBzZW5kDQo9PT0+IHVzci5zYmlu L2lwdGVzdA0KPT09PiB1c3Iuc2Jpbi9JUFhyb3V0ZWQNCj09PT4gdXNyLnNiaW4vamFpbA0KPT09 PiB1c3Iuc2Jpbi9qZXhlYw0KPT09PiB1c3Iuc2Jpbi9qbHMNCj09PT4gdXNyLnNiaW4va2JkY29u dHJvbA0KPT09PiB1c3Iuc2Jpbi9rYmRtYXANCj09PT4gdXNyLnNiaW4va2V5c2Vydg0KPT09PiB1 c3Iuc2Jpbi9rZ21vbg0KPT09PiB1c3Iuc2Jpbi9rZ3ppcA0KPT09PiB1c3Iuc2Jpbi9rbGR4cmVm DQo9PT0+IHVzci5zYmluL2xhc3Rsb2dpbg0KPT09PiB1c3Iuc2Jpbi9scHRjb250cm9sDQo9PT0+ IHVzci5zYmluL21haWx3cmFwcGVyDQo9PT0+IHVzci5zYmluL21hbmN0bA0KPT09PiB1c3Iuc2Jp bi9tZW1jb250cm9sDQo9PT0+IHVzci5zYmluL21lcmdlbWFzdGVyDQo9PT0+IHVzci5zYmluL21p eGVyDQo9PT0+IHVzci5zYmluL21sZDZxdWVyeQ0KPT09PiB1c3Iuc2Jpbi9tbHhjb250cm9sDQo9 PT0+IHVzci5zYmluL21vdW50ZA0KPT09PiB1c3Iuc2Jpbi9tb3VudF9ud2ZzDQo9PT0+IHVzci5z YmluL21vdW50X3BvcnRhbGZzDQo9PT0+IHVzci5zYmluL21vdW50X3NtYmZzDQo9PT0+IHVzci5z YmluL21vdXNlZA0KPT09PiB1c3Iuc2Jpbi9tcHRhYmxlDQo9PT0+IHVzci5zYmluL21yb3V0ZWQN Cj09PT4gdXNyLnNiaW4vbXJvdXRlZC9jb21tb24NCj09PT4gdXNyLnNiaW4vbXJvdXRlZC9tcm91 dGVkDQo9PT0+IHVzci5zYmluL21yb3V0ZWQvbXJpbmZvDQo9PT0+IHVzci5zYmluL21yb3V0ZWQv bWFwLW1ib25lDQo9PT0+IHVzci5zYmluL21yb3V0ZWQvbXRyYWNlDQo9PT0+IHVzci5zYmluL21y b3V0ZWQvdGVzdHJzcnINCj09PT4gdXNyLnNiaW4vbXRlc3QNCj09PT4gdXNyLnNiaW4vbXRyZWUN Cj09PT4gdXNyLnNiaW4vbmFtZWQNCj09PT4gdXNyLnNiaW4vbmFtZWQucmVsb2FkDQo9PT0+IHVz ci5zYmluL25hbWVkLnJlc3RhcnQNCj09PT4gdXNyLnNiaW4vbmRjDQo9PT0+IHVzci5zYmluL25k aXNjdnQNCj09PT4gdXNyLnNiaW4vbmRwDQo9PT0+IHVzci5zYmluL25ld3N5c2xvZw0KPT09PiB1 c3Iuc2Jpbi9uZnNkDQo9PT0+IHVzci5zYmluL25nY3RsDQo9PT0+IHVzci5zYmluL25naG9vaw0K PT09PiB1c3Iuc2Jpbi9ub2xvZ2luDQo9PT0+IHVzci5zYmluL25zbG9va3VwDQo9PT0+IHVzci5z YmluL25zdXBkYXRlDQo9PT0+IHVzci5zYmluL250cA0KPT09PiB1c3Iuc2Jpbi9udHAvbGlibnRw DQo9PT0+IHVzci5zYmluL250cC9saWJwYXJzZQ0KPT09PiB1c3Iuc2Jpbi9udHAvbnRwZA0KPT09 PiB1c3Iuc2Jpbi9udHAvbnRwZGMNCj09PT4gdXNyLnNiaW4vbnRwL250cHENCj09PT4gdXNyLnNi aW4vbnRwL250cGRhdGUNCj09PT4gdXNyLnNiaW4vbnRwL250cHRyYWNlDQo9PT0+IHVzci5zYmlu L250cC9udHB0aW1lDQo9PT0+IHVzci5zYmluL250cC9udHAta2V5Z2VuDQo9PT0+IHVzci5zYmlu L250cC9zbnRwDQo9PT0+IHVzci5zYmluL250cC9kb2MNCj09PT4gdXNyLnNiaW4vcGNjYXJkDQo9 PT0+IHVzci5zYmluL3BjY2FyZC9wY2NhcmRjDQo9PT0+IHVzci5zYmluL3BjY2FyZC9wY2NhcmRk DQo9PT0+IHVzci5zYmluL3BjaWNvbmYNCj09PT4gdXNyLnNiaW4vcGN2dA0KPT09PiB1c3Iuc2Jp bi9wY3Z0L2tleWNhcA0KPT09PiB1c3Iuc2Jpbi9wY3Z0L2N1cnNvcg0KPT09PiB1c3Iuc2Jpbi9w Y3Z0L2ZvbnRlZGl0DQo9PT0+IHVzci5zYmluL3BjdnQvZm9udHMNCj09PT4gdXNyLnNiaW4vcGN2 dC9rY29uDQo9PT0+IHVzci5zYmluL3BjdnQvbG9hZGZvbnQNCj09PT4gdXNyLnNiaW4vcGN2dC9z Y29uDQo9PT0+IHVzci5zYmluL3BjdnQvdXNlcmtleXMNCj09PT4gdXNyLnNiaW4vcGN2dC92dHRl c3QNCj09PT4gdXNyLnNiaW4vcGN2dC9pc3BjdnQNCj09PT4gdXNyLnNiaW4vcGN2dC92Z2Fpbw0K PT09PiB1c3Iuc2Jpbi9wY3Z0L2tiZGlvDQo9PT0+IHVzci5zYmluL3BjdnQvZGVtbw0KPT09PiB1 c3Iuc2Jpbi9wY3Z0L01pc2MNCj09PT4gdXNyLnNiaW4vcGN2dC9NaXNjL0RvYw0KPT09PiB1c3Iu c2Jpbi9wY3Z0L01pc2MvRXRjDQo9PT0+IHVzci5zYmluL3BjdnQvTWlzYy9Eb2MNCj09PT4gdXNy LnNiaW4vcGN2dC9NaXNjL0V0Yw0KPT09PiB1c3Iuc2Jpbi9wY3Z0L01pc2MvRG9jDQo9PT0+IHVz ci5zYmluL3BjdnQvTWlzYy9FdGMNCj09PT4gdXNyLnNiaW4vcGVyaW9kaWMNCj09PT4gdXNyLnNi aW4vcGtnX2luc3RhbGwNCj09PT4gdXNyLnNiaW4vcGtnX2luc3RhbGwvbGliDQo9PT0+IHVzci5z YmluL3BrZ19pbnN0YWxsL2FkZA0KPT09PiB1c3Iuc2Jpbi9wa2dfaW5zdGFsbC9jcmVhdGUNCj09 PT4gdXNyLnNiaW4vcGtnX2luc3RhbGwvZGVsZXRlDQo9PT0+IHVzci5zYmluL3BrZ19pbnN0YWxs L2luZm8NCj09PT4gdXNyLnNiaW4vcGtnX2luc3RhbGwvc2lnbg0KPT09PiB1c3Iuc2Jpbi9wa2df aW5zdGFsbC92ZXJzaW9uDQo9PT0+IHVzci5zYmluL3BucGluZm8NCj09PT4gdXNyLnNiaW4vcHBw DQo9PT0+IHVzci5zYmluL3BwcGN0bA0KPT09PiB1c3Iuc2Jpbi9wcHBkDQo9PT0+IHVzci5zYmlu L3BwcHN0YXRzDQo9PT0+IHVzci5zYmluL3Byb2NjdGwNCj09PT4gdXNyLnNiaW4vcHN0YXQNCj09 PT4gdXNyLnNiaW4vcHcNCj09PT4gdXNyLnNiaW4vcHdkX21rZGINCj09PT4gdXNyLnNiaW4vcXVv dA0KPT09PiB1c3Iuc2Jpbi9xdW90YW9uDQo9PT0+IHVzci5zYmluL3JhcnBkDQo9PT0+IHVzci5z YmluL3JheWNvbnRyb2wNCj09PT4gdXNyLnNiaW4vcmVwcXVvdGENCj09PT4gdXNyLnNiaW4vcmlw NnF1ZXJ5DQo9PT0+IHVzci5zYmluL3JtdA0KPT09PiB1c3Iuc2Jpbi9yb3V0ZTZkDQo9PT0+IHVz ci5zYmluL3JwY2JpbmQNCj09PT4gdXNyLnNiaW4vcnBjLmxvY2tkDQo9PT0+IHVzci5zYmluL3Jw Yy5zdGF0ZA0KPT09PiB1c3Iuc2Jpbi9ycGMudW1udGFsbA0KPT09PiB1c3Iuc2Jpbi9ycGMueXBw YXNzd2RkDQo9PT0+IHVzci5zYmluL3JwYy55cHVwZGF0ZWQNCj09PT4gdXNyLnNiaW4vcnBjLnlw eGZyZA0KPT09PiB1c3Iuc2Jpbi9ycmVudW1kDQo9PT0+IHVzci5zYmluL3J0YWR2ZA0KPT09PiB1 c3Iuc2Jpbi9ydHByaW8NCj09PT4gdXNyLnNiaW4vcnRzb2xkDQo9PT0+IHVzci5zYmluL3J3aG9k DQo9PT0+IHVzci5zYmluL3NhDQo9PT0+IHVzci5zYmluL3NldGZtYWMNCj09PT4gdXNyLnNiaW4v c2V0a2V5DQo9PT0+IHVzci5zYmluL3NldHBtYWMNCj09PT4gdXNyLnNiaW4vc2ljb250cm9sDQo9 PT0+IHVzci5zYmluL3NsaXBsb2dpbg0KPT09PiB1c3Iuc2Jpbi9zbHN0YXQNCj09PT4gdXNyLnNi aW4vc21ibXNnDQo9PT0+IHVzci5zYmluL3Nwa3J0ZXN0DQo9PT0+IHVzci5zYmluL3NwcmF5DQo9 PT0+IHVzci5zYmluL3N5c2luc3RhbGwNCj09PT4gdXNyLnNiaW4vc3lzbG9nZA0KPT09PiB1c3Iu c2Jpbi90Y3BkY2hrDQo9PT0+IHVzci5zYmluL3RjcGRtYXRjaA0KPT09PiB1c3Iuc2Jpbi90Y3Bk dW1wDQo9PT0+IHVzci5zYmluL3RjcGR1bXAvdGNwZHVtcA0KPT09PiB1c3Iuc2Jpbi90Y3BkdW1w L3RjcHNsaWNlDQo9PT0+IHVzci5zYmluL3RpbWVkDQo9PT0+IHVzci5zYmluL3RpbWVkL3RpbWVk DQo9PT0+IHVzci5zYmluL3RpbWVkL3RpbWVkYw0KPT09PiB1c3Iuc2Jpbi90cmFjZXJvdXRlDQo9 PT0+IHVzci5zYmluL3RyYWNlcm91dGU2DQo9PT0+IHVzci5zYmluL3RycHQNCj09PT4gdXNyLnNi aW4vdHpzZXR1cA0KPT09PiB1c3Iuc2Jpbi91Z2lkZncNCj09PT4gdXNyLnNiaW4vdXNiZA0KPT09 PiB1c3Iuc2Jpbi91c2JkZXZzDQo9PT0+IHVzci5zYmluL3ZpZGNvbnRyb2wNCj09PT4gdXNyLnNi aW4vdmlwdw0KPT09PiB1c3Iuc2Jpbi92bmNvbmZpZw0KPT09PiB1c3Iuc2Jpbi93YXRjaA0KPT09 PiB1c3Iuc2Jpbi93YXRjaGRvZ2QNCj09PT4gdXNyLnNiaW4vd2ljb250cm9sDQo9PT0+IHVzci5z YmluL3dsY29uZmlnDQo9PT0+IHVzci5zYmluL3lwYmluZA0KPT09PiB1c3Iuc2Jpbi95cF9ta2Ri DQo9PT0+IHVzci5zYmluL3lwcG9sbA0KPT09PiB1c3Iuc2Jpbi95cHB1c2gNCj09PT4gdXNyLnNi aW4veXBzZXJ2DQo9PT0+IHVzci5zYmluL3lwc2V0DQo9PT0+IHVzci5zYmluL3ppYw0KPT09PiB1 c3Iuc2Jpbi96aWMvemljDQo9PT0+IHVzci5zYmluL3ppYy96ZHVtcA0KPT09PiB1c3Iuc2Jpbi96 enoNCj09PT4gZXRjDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gc3RhZ2UgMi4yOiByZWJ1aWxkaW5nIHRoZSBvYmpl Y3QgdHJlZQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCmNkIC91c3Ivc3JjOyBNQUtFT0JKRElSUFJFRklYPS91c3Ivb2JqICBN QUNISU5FX0FSQ0g9aTM4NiAgTUFDSElORT1pMzg2ICBDUFVUWVBFPXAzICBHUk9GRl9CSU5fUEFU SD0vdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9iaW4gIEdST0ZGX0ZPTlRfUEFUSD0v dXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9zaGFyZS9ncm9mZl9mb250ICBHUk9GRl9U TUFDX1BBVEg9L3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3Ivc2hhcmUvdG1hYyAgREVT VERJUj0vdXNyL29iai91c3Ivc3JjL2kzODYgIF9TSExJQkRJUlBSRUZJWD0vdXNyL29iai91c3Iv c3JjL2kzODYgIElOU1RBTEw9InNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2giICBQQVRIPS91 c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL3NiaW46L3Vzci9vYmovdXNyL3NyYy9pMzg2 L2xlZ2FjeS91c3IvYmluOi91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2dhbWVzOi91 c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc2JpbjovdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL2Jp bjovdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL2dhbWVzOi9zYmluOi9iaW46L3Vzci9zYmluOi91 c3IvYmluIC91c3Ivb2JqL3Vzci9zcmMvbWFrZS5pMzg2L21ha2UgLWYgTWFrZWZpbGUuaW5jMSBw YXItb2JqDQo9PT0+IHNoYXJlL2luZm8NCj09PT4gaW5jbHVkZQ0KL3Vzci9vYmovdXNyL3NyYy9p bmNsdWRlIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2luY2x1ZGUNCj09PT4gaW5jbHVkZS9hcnBhDQo9 PT0+IGluY2x1ZGUvcHJvdG9jb2xzDQo9PT0+IGluY2x1ZGUvcnBjc3ZjDQovdXNyL29iai91c3Iv c3JjL2luY2x1ZGUvcnBjc3ZjIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2luY2x1ZGUvcnBjc3ZjDQo9 PT0+IGluY2x1ZGUvcnBjDQovdXNyL29iai91c3Ivc3JjL2luY2x1ZGUvcnBjIGNyZWF0ZWQgZm9y IC91c3Ivc3JjL2luY2x1ZGUvcnBjDQo9PT0+IGxpYg0KPT09PiBsaWIvY3N1L2kzODYtZWxmDQov dXNyL29iai91c3Ivc3JjL2xpYi9jc3UvaTM4Ni1lbGYgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGli L2NzdS9pMzg2LWVsZg0KPT09PiBsaWIvbGliY29tX2Vycg0KL3Vzci9vYmovdXNyL3NyYy9saWIv bGliY29tX2VyciBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGliY29tX2Vycg0KPT09PiBsaWIv bGliY29tX2Vyci9kb2MNCi91c3Ivb2JqL3Vzci9zcmMvbGliL2xpYmNvbV9lcnIvZG9jIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL2xpYi9saWJjb21fZXJyL2RvYw0KPT09PiBsaWIvbGliY3J5cHQNCi91 c3Ivb2JqL3Vzci9zcmMvbGliL2xpYmNyeXB0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xpYi9saWJj cnlwdA0KPT09PiBsaWIvbGlia3ZtDQovdXNyL29iai91c3Ivc3JjL2xpYi9saWJrdm0gY3JlYXRl ZCBmb3IgL3Vzci9zcmMvbGliL2xpYmt2bQ0KPT09PiBsaWIvbXN1bg0KL3Vzci9vYmovdXNyL3Ny Yy9saWIvbXN1biBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbXN1bg0KPT09PiBsaWIvbGlibWQN Ci91c3Ivb2JqL3Vzci9zcmMvbGliL2xpYm1kIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xpYi9saWJt ZA0KPT09PiBsaWIvbGlibmN1cnNlcw0KL3Vzci9vYmovdXNyL3NyYy9saWIvbGlibmN1cnNlcyBj cmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGlibmN1cnNlcw0KPT09PiBsaWIvbGlibmV0Z3JhcGgN Ci91c3Ivb2JqL3Vzci9zcmMvbGliL2xpYm5ldGdyYXBoIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xp Yi9saWJuZXRncmFwaA0KPT09PiBsaWIvbGlicmFkaXVzDQovdXNyL29iai91c3Ivc3JjL2xpYi9s aWJyYWRpdXMgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliL2xpYnJhZGl1cw0KPT09PiBsaWIvbGli cnBjc3ZjDQovdXNyL29iai91c3Ivc3JjL2xpYi9saWJycGNzdmMgY3JlYXRlZCBmb3IgL3Vzci9z cmMvbGliL2xpYnJwY3N2Yw0KPT09PiBsaWIvbGlic2J1Zg0KL3Vzci9vYmovdXNyL3NyYy9saWIv bGlic2J1ZiBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGlic2J1Zg0KPT09PiBsaWIvbGlidGFj cGx1cw0KL3Vzci9vYmovdXNyL3NyYy9saWIvbGlidGFjcGx1cyBjcmVhdGVkIGZvciAvdXNyL3Ny Yy9saWIvbGlidGFjcGx1cw0KPT09PiBsaWIvbGlidXRpbA0KL3Vzci9vYmovdXNyL3NyYy9saWIv bGlidXRpbCBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGlidXRpbA0KPT09PiBsaWIvbGlieXBj bG50DQovdXNyL29iai91c3Ivc3JjL2xpYi9saWJ5cGNsbnQgY3JlYXRlZCBmb3IgL3Vzci9zcmMv bGliL2xpYnlwY2xudA0KPT09PiBsaWIvY29tcGF0DQo9PT0+IGxpYi9jb21wYXQvY29tcGF0M3gu aTM4Ng0KL3Vzci9vYmovdXNyL3NyYy9saWIvY29tcGF0L2NvbXBhdDN4LmkzODYgY3JlYXRlZCBm b3IgL3Vzci9zcmMvbGliL2NvbXBhdC9jb21wYXQzeC5pMzg2DQo9PT0+IGxpYi9jb21wYXQvY29t cGF0NHguaTM4Ng0KL3Vzci9vYmovdXNyL3NyYy9saWIvY29tcGF0L2NvbXBhdDR4LmkzODYgY3Jl YXRlZCBmb3IgL3Vzci9zcmMvbGliL2NvbXBhdC9jb21wYXQ0eC5pMzg2DQo9PT0+IGxpYi9saWJh bGlhcw0KL3Vzci9vYmovdXNyL3NyYy9saWIvbGliYWxpYXMgY3JlYXRlZCBmb3IgL3Vzci9zcmMv bGliL2xpYmFsaWFzDQo9PT0+IGxpYi9saWJhcmNoaXZlDQovdXNyL29iai91c3Ivc3JjL2xpYi9s aWJhcmNoaXZlIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xpYi9saWJhcmNoaXZlDQo9PT0+IGxpYi9s aWJhdG0NCi91c3Ivb2JqL3Vzci9zcmMvbGliL2xpYmF0bSBjcmVhdGVkIGZvciAvdXNyL3NyYy9s aWIvbGliYXRtDQo9PT0+IGxpYi9saWJiaW5kDQovdXNyL29iai91c3Ivc3JjL2xpYi9saWJiaW5k IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xpYi9saWJiaW5kDQo9PT0+IGxpYi9saWJibHVldG9vdGgN Ci91c3Ivb2JqL3Vzci9zcmMvbGliL2xpYmJsdWV0b290aCBjcmVhdGVkIGZvciAvdXNyL3NyYy9s aWIvbGliYmx1ZXRvb3RoDQo9PT0+IGxpYi9saWJic25tcA0KPT09PiBsaWIvbGliYnNubXAvbGli YnNubXANCi91c3Ivb2JqL3Vzci9zcmMvbGliL2xpYmJzbm1wL2xpYmJzbm1wIGNyZWF0ZWQgZm9y IC91c3Ivc3JjL2xpYi9saWJic25tcC9saWJic25tcA0KPT09PiBsaWIvbGliYnNubXAvbW9kdWxl cw0KL3Vzci9vYmovdXNyL3NyYy9saWIvbGliYnNubXAvbW9kdWxlcyBjcmVhdGVkIGZvciAvdXNy L3NyYy9saWIvbGliYnNubXAvbW9kdWxlcw0KPT09PiBsaWIvbGliYnNubXAvbW9kdWxlcy9zbm1w X2F0bQ0KL3Vzci9vYmovdXNyL3NyYy9saWIvbGliYnNubXAvbW9kdWxlcy9zbm1wX2F0bSBjcmVh dGVkIGZvciAvdXNyL3NyYy9saWIvbGliYnNubXAvbW9kdWxlcy9zbm1wX2F0bQ0KPT09PiBsaWIv bGliYnNubXAvbW9kdWxlcy9zbm1wX21pYklJDQovdXNyL29iai91c3Ivc3JjL2xpYi9saWJic25t cC9tb2R1bGVzL3NubXBfbWliSUkgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliL2xpYmJzbm1wL21v ZHVsZXMvc25tcF9taWJJSQ0KPT09PiBsaWIvbGliYnNubXAvbW9kdWxlcy9zbm1wX25ldGdyYXBo DQovdXNyL29iai91c3Ivc3JjL2xpYi9saWJic25tcC9tb2R1bGVzL3NubXBfbmV0Z3JhcGggY3Jl YXRlZCBmb3IgL3Vzci9zcmMvbGliL2xpYmJzbm1wL21vZHVsZXMvc25tcF9uZXRncmFwaA0KPT09 PiBsaWIvbGliYnoyDQovdXNyL29iai91c3Ivc3JjL2xpYi9saWJiejIgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvbGliL2xpYmJ6Mg0KPT09PiBsaWIvbGliYw0KL3Vzci9vYmovdXNyL3NyYy9saWIvbGli YyBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGliYw0KPT09PiBsaWIvbGliY19yDQovdXNyL29i ai91c3Ivc3JjL2xpYi9saWJjX3IgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliL2xpYmNfcg0KPT09 PiBsaWIvbGliY2FsZW5kYXINCi91c3Ivb2JqL3Vzci9zcmMvbGliL2xpYmNhbGVuZGFyIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL2xpYi9saWJjYWxlbmRhcg0KPT09PiBsaWIvbGliY2FtDQovdXNyL29i ai91c3Ivc3JjL2xpYi9saWJjYW0gY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliL2xpYmNhbQ0KPT09 PiBsaWIvbGliY29tcGF0DQovdXNyL29iai91c3Ivc3JjL2xpYi9saWJjb21wYXQgY3JlYXRlZCBm b3IgL3Vzci9zcmMvbGliL2xpYmNvbXBhdA0KPT09PiBsaWIvbGliZGV2aW5mbw0KL3Vzci9vYmov dXNyL3NyYy9saWIvbGliZGV2aW5mbyBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGliZGV2aW5m bw0KPT09PiBsaWIvbGliZGV2c3RhdA0KL3Vzci9vYmovdXNyL3NyYy9saWIvbGliZGV2c3RhdCBj cmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGliZGV2c3RhdA0KPT09PiBsaWIvbGliZGlzaw0KL3Vz ci9vYmovdXNyL3NyYy9saWIvbGliZGlzayBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGliZGlz aw0KPT09PiBsaWIvbGliZWRpdA0KL3Vzci9vYmovdXNyL3NyYy9saWIvbGliZWRpdCBjcmVhdGVk IGZvciAvdXNyL3NyYy9saWIvbGliZWRpdA0KPT09PiBsaWIvbGliZXhwYXQNCi91c3Ivb2JqL3Vz ci9zcmMvbGliL2xpYmV4cGF0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xpYi9saWJleHBhdA0KPT09 PiBsaWIvbGliZmV0Y2gNCi91c3Ivb2JqL3Vzci9zcmMvbGliL2xpYmZldGNoIGNyZWF0ZWQgZm9y IC91c3Ivc3JjL2xpYi9saWJmZXRjaA0KPT09PiBsaWIvbGliZm9ybQ0KL3Vzci9vYmovdXNyL3Ny Yy9saWIvbGliZm9ybSBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGliZm9ybQ0KPT09PiBsaWIv bGliZnRwaW8NCi91c3Ivb2JqL3Vzci9zcmMvbGliL2xpYmZ0cGlvIGNyZWF0ZWQgZm9yIC91c3Iv c3JjL2xpYi9saWJmdHBpbw0KPT09PiBsaWIvbGliZ2VvbQ0KL3Vzci9vYmovdXNyL3NyYy9saWIv bGliZ2VvbSBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGliZ2VvbQ0KPT09PiBsaWIvbGliaXBz ZWMNCi91c3Ivb2JqL3Vzci9zcmMvbGliL2xpYmlwc2VjIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xp Yi9saWJpcHNlYw0KPT09PiBsaWIvbGliaXB4DQovdXNyL29iai91c3Ivc3JjL2xpYi9saWJpcHgg Y3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliL2xpYmlweA0KPT09PiBsaWIvbGliaXNjDQovdXNyL29i ai91c3Ivc3JjL2xpYi9saWJpc2MgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliL2xpYmlzYw0KPT09 PiBsaWIvbGlia2ljb252DQovdXNyL29iai91c3Ivc3JjL2xpYi9saWJraWNvbnYgY3JlYXRlZCBm b3IgL3Vzci9zcmMvbGliL2xpYmtpY29udg0KPT09PiBsaWIvbGlibWFnaWMNCi91c3Ivb2JqL3Vz ci9zcmMvbGliL2xpYm1hZ2ljIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xpYi9saWJtYWdpYw0KPT09 PiBsaWIvbGlibWVudQ0KL3Vzci9vYmovdXNyL3NyYy9saWIvbGlibWVudSBjcmVhdGVkIGZvciAv dXNyL3NyYy9saWIvbGlibWVudQ0KPT09PiBsaWIvbGlibXANCi91c3Ivb2JqL3Vzci9zcmMvbGli L2xpYm1wIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xpYi9saWJtcA0KPT09PiBsaWIvbGlibmNwDQov dXNyL29iai91c3Ivc3JjL2xpYi9saWJuY3AgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliL2xpYm5j cA0KPT09PiBsaWIvbGlibmdhdG0NCi91c3Ivb2JqL3Vzci9zcmMvbGliL2xpYm5nYXRtIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL2xpYi9saWJuZ2F0bQ0KPT09PiBsaWIvbGlib3BpZQ0KL3Vzci9vYmov dXNyL3NyYy9saWIvbGlib3BpZSBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGlib3BpZQ0KPT09 PiBsaWIvbGlicGFtDQo9PT0+IGxpYi9saWJwYW0vbW9kdWxlcw0KPT09PiBsaWIvbGlicGFtL21v ZHVsZXMvcGFtX2Nocm9vdA0KL3Vzci9vYmovdXNyL3NyYy9saWIvbGlicGFtL21vZHVsZXMvcGFt X2Nocm9vdCBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGlicGFtL21vZHVsZXMvcGFtX2Nocm9v dA0KPT09PiBsaWIvbGlicGFtL21vZHVsZXMvcGFtX2RlbnkNCi91c3Ivb2JqL3Vzci9zcmMvbGli L2xpYnBhbS9tb2R1bGVzL3BhbV9kZW55IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xpYi9saWJwYW0v bW9kdWxlcy9wYW1fZGVueQ0KPT09PiBsaWIvbGlicGFtL21vZHVsZXMvcGFtX2VjaG8NCi91c3Iv b2JqL3Vzci9zcmMvbGliL2xpYnBhbS9tb2R1bGVzL3BhbV9lY2hvIGNyZWF0ZWQgZm9yIC91c3Iv c3JjL2xpYi9saWJwYW0vbW9kdWxlcy9wYW1fZWNobw0KPT09PiBsaWIvbGlicGFtL21vZHVsZXMv cGFtX2V4ZWMNCi91c3Ivb2JqL3Vzci9zcmMvbGliL2xpYnBhbS9tb2R1bGVzL3BhbV9leGVjIGNy ZWF0ZWQgZm9yIC91c3Ivc3JjL2xpYi9saWJwYW0vbW9kdWxlcy9wYW1fZXhlYw0KPT09PiBsaWIv bGlicGFtL21vZHVsZXMvcGFtX2Z0cHVzZXJzDQovdXNyL29iai91c3Ivc3JjL2xpYi9saWJwYW0v bW9kdWxlcy9wYW1fZnRwdXNlcnMgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliL2xpYnBhbS9tb2R1 bGVzL3BhbV9mdHB1c2Vycw0KPT09PiBsaWIvbGlicGFtL21vZHVsZXMvcGFtX2dyb3VwDQovdXNy L29iai91c3Ivc3JjL2xpYi9saWJwYW0vbW9kdWxlcy9wYW1fZ3JvdXAgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvbGliL2xpYnBhbS9tb2R1bGVzL3BhbV9ncm91cA0KPT09PiBsaWIvbGlicGFtL21vZHVs ZXMvcGFtX2d1ZXN0DQovdXNyL29iai91c3Ivc3JjL2xpYi9saWJwYW0vbW9kdWxlcy9wYW1fZ3Vl c3QgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliL2xpYnBhbS9tb2R1bGVzL3BhbV9ndWVzdA0KPT09 PiBsaWIvbGlicGFtL21vZHVsZXMvcGFtX2xhc3Rsb2cNCi91c3Ivb2JqL3Vzci9zcmMvbGliL2xp YnBhbS9tb2R1bGVzL3BhbV9sYXN0bG9nIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xpYi9saWJwYW0v bW9kdWxlcy9wYW1fbGFzdGxvZw0KPT09PiBsaWIvbGlicGFtL21vZHVsZXMvcGFtX2xvZ2luX2Fj Y2Vzcw0KL3Vzci9vYmovdXNyL3NyYy9saWIvbGlicGFtL21vZHVsZXMvcGFtX2xvZ2luX2FjY2Vz cyBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGlicGFtL21vZHVsZXMvcGFtX2xvZ2luX2FjY2Vz cw0KPT09PiBsaWIvbGlicGFtL21vZHVsZXMvcGFtX25vbG9naW4NCi91c3Ivb2JqL3Vzci9zcmMv bGliL2xpYnBhbS9tb2R1bGVzL3BhbV9ub2xvZ2luIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xpYi9s aWJwYW0vbW9kdWxlcy9wYW1fbm9sb2dpbg0KPT09PiBsaWIvbGlicGFtL21vZHVsZXMvcGFtX29w aWUNCi91c3Ivb2JqL3Vzci9zcmMvbGliL2xpYnBhbS9tb2R1bGVzL3BhbV9vcGllIGNyZWF0ZWQg Zm9yIC91c3Ivc3JjL2xpYi9saWJwYW0vbW9kdWxlcy9wYW1fb3BpZQ0KPT09PiBsaWIvbGlicGFt L21vZHVsZXMvcGFtX29waWVhY2Nlc3MNCi91c3Ivb2JqL3Vzci9zcmMvbGliL2xpYnBhbS9tb2R1 bGVzL3BhbV9vcGllYWNjZXNzIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xpYi9saWJwYW0vbW9kdWxl cy9wYW1fb3BpZWFjY2Vzcw0KPT09PiBsaWIvbGlicGFtL21vZHVsZXMvcGFtX3Bhc3N3ZHFjDQov dXNyL29iai91c3Ivc3JjL2xpYi9saWJwYW0vbW9kdWxlcy9wYW1fcGFzc3dkcWMgY3JlYXRlZCBm b3IgL3Vzci9zcmMvbGliL2xpYnBhbS9tb2R1bGVzL3BhbV9wYXNzd2RxYw0KPT09PiBsaWIvbGli cGFtL21vZHVsZXMvcGFtX3Blcm1pdA0KL3Vzci9vYmovdXNyL3NyYy9saWIvbGlicGFtL21vZHVs ZXMvcGFtX3Blcm1pdCBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGlicGFtL21vZHVsZXMvcGFt X3Blcm1pdA0KPT09PiBsaWIvbGlicGFtL21vZHVsZXMvcGFtX3JhZGl1cw0KL3Vzci9vYmovdXNy L3NyYy9saWIvbGlicGFtL21vZHVsZXMvcGFtX3JhZGl1cyBjcmVhdGVkIGZvciAvdXNyL3NyYy9s aWIvbGlicGFtL21vZHVsZXMvcGFtX3JhZGl1cw0KPT09PiBsaWIvbGlicGFtL21vZHVsZXMvcGFt X3Job3N0cw0KL3Vzci9vYmovdXNyL3NyYy9saWIvbGlicGFtL21vZHVsZXMvcGFtX3Job3N0cyBj cmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGlicGFtL21vZHVsZXMvcGFtX3Job3N0cw0KPT09PiBs aWIvbGlicGFtL21vZHVsZXMvcGFtX3Jvb3Rvaw0KL3Vzci9vYmovdXNyL3NyYy9saWIvbGlicGFt L21vZHVsZXMvcGFtX3Jvb3RvayBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGlicGFtL21vZHVs ZXMvcGFtX3Jvb3Rvaw0KPT09PiBsaWIvbGlicGFtL21vZHVsZXMvcGFtX3NlY3VyZXR0eQ0KL3Vz ci9vYmovdXNyL3NyYy9saWIvbGlicGFtL21vZHVsZXMvcGFtX3NlY3VyZXR0eSBjcmVhdGVkIGZv ciAvdXNyL3NyYy9saWIvbGlicGFtL21vZHVsZXMvcGFtX3NlY3VyZXR0eQ0KPT09PiBsaWIvbGli cGFtL21vZHVsZXMvcGFtX3NlbGYNCi91c3Ivb2JqL3Vzci9zcmMvbGliL2xpYnBhbS9tb2R1bGVz L3BhbV9zZWxmIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xpYi9saWJwYW0vbW9kdWxlcy9wYW1fc2Vs Zg0KPT09PiBsaWIvbGlicGFtL21vZHVsZXMvcGFtX3NzaA0KL3Vzci9vYmovdXNyL3NyYy9saWIv bGlicGFtL21vZHVsZXMvcGFtX3NzaCBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGlicGFtL21v ZHVsZXMvcGFtX3NzaA0KPT09PiBsaWIvbGlicGFtL21vZHVsZXMvcGFtX3RhY3BsdXMNCi91c3Iv b2JqL3Vzci9zcmMvbGliL2xpYnBhbS9tb2R1bGVzL3BhbV90YWNwbHVzIGNyZWF0ZWQgZm9yIC91 c3Ivc3JjL2xpYi9saWJwYW0vbW9kdWxlcy9wYW1fdGFjcGx1cw0KPT09PiBsaWIvbGlicGFtL21v ZHVsZXMvcGFtX3VuaXgNCi91c3Ivb2JqL3Vzci9zcmMvbGliL2xpYnBhbS9tb2R1bGVzL3BhbV91 bml4IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xpYi9saWJwYW0vbW9kdWxlcy9wYW1fdW5peA0KPT09 PiBsaWIvbGlicGFtL2xpYnBhbQ0KL3Vzci9vYmovdXNyL3NyYy9saWIvbGlicGFtL2xpYnBhbSBj cmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGlicGFtL2xpYnBhbQ0KPT09PiBsaWIvbGlicGFuZWwN Ci91c3Ivb2JqL3Vzci9zcmMvbGliL2xpYnBhbmVsIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xpYi9s aWJwYW5lbA0KPT09PiBsaWIvbGlicGNhcA0KL3Vzci9vYmovdXNyL3NyYy9saWIvbGlicGNhcCBj cmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGlicGNhcA0KPT09PiBsaWIvbGlicHRocmVhZA0KL3Vz ci9vYmovdXNyL3NyYy9saWIvbGlicHRocmVhZCBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGli cHRocmVhZA0KPT09PiBsaWIvbGlic2RwDQovdXNyL29iai91c3Ivc3JjL2xpYi9saWJzZHAgY3Jl YXRlZCBmb3IgL3Vzci9zcmMvbGliL2xpYnNkcA0KPT09PiBsaWIvbGlic21iDQovdXNyL29iai91 c3Ivc3JjL2xpYi9saWJzbWIgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliL2xpYnNtYg0KPT09PiBs aWIvbGlic3RhbmQNCi91c3Ivb2JqL3Vzci9zcmMvbGliL2xpYnN0YW5kIGNyZWF0ZWQgZm9yIC91 c3Ivc3JjL2xpYi9saWJzdGFuZA0KPT09PiBsaWIvbGlidGVsbmV0DQovdXNyL29iai91c3Ivc3Jj L2xpYi9saWJ0ZWxuZXQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliL2xpYnRlbG5ldA0KPT09PiBs aWIvbGlidGhyDQovdXNyL29iai91c3Ivc3JjL2xpYi9saWJ0aHIgY3JlYXRlZCBmb3IgL3Vzci9z cmMvbGliL2xpYnRocg0KPT09PiBsaWIvbGlidGhyZWFkX2RiDQovdXNyL29iai91c3Ivc3JjL2xp Yi9saWJ0aHJlYWRfZGIgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliL2xpYnRocmVhZF9kYg0KPT09 PiBsaWIvbGlidWZzDQovdXNyL29iai91c3Ivc3JjL2xpYi9saWJ1ZnMgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvbGliL2xpYnVmcw0KPT09PiBsaWIvbGlidWdpZGZ3DQovdXNyL29iai91c3Ivc3JjL2xp Yi9saWJ1Z2lkZncgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliL2xpYnVnaWRmdw0KPT09PiBsaWIv bGlidXNiaGlkDQovdXNyL29iai91c3Ivc3JjL2xpYi9saWJ1c2JoaWQgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvbGliL2xpYnVzYmhpZA0KPT09PiBsaWIvbGlidmdsDQovdXNyL29iai91c3Ivc3JjL2xp Yi9saWJ2Z2wgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliL2xpYnZnbA0KPT09PiBsaWIvbGlid3Jh cA0KL3Vzci9vYmovdXNyL3NyYy9saWIvbGlid3JhcCBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWIv bGlid3JhcA0KPT09PiBsaWIvbGlieHBnNA0KL3Vzci9vYmovdXNyL3NyYy9saWIvbGlieHBnNCBj cmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGlieHBnNA0KPT09PiBsaWIvbGlieQ0KL3Vzci9vYmov dXNyL3NyYy9saWIvbGlieSBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWIvbGlieQ0KPT09PiBsaWIv bGlieg0KL3Vzci9vYmovdXNyL3NyYy9saWIvbGlieiBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWIv bGlieg0KPT09PiBsaWJleGVjDQo9PT0+IGxpYmV4ZWMvYXRydW4NCi91c3Ivb2JqL3Vzci9zcmMv bGliZXhlYy9hdHJ1biBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWJleGVjL2F0cnVuDQo9PT0+IGxp YmV4ZWMvYm9vdHBkDQovdXNyL29iai91c3Ivc3JjL2xpYmV4ZWMvYm9vdHBkIGNyZWF0ZWQgZm9y IC91c3Ivc3JjL2xpYmV4ZWMvYm9vdHBkDQo9PT0+IGxpYmV4ZWMvYm9vdHBkL2Jvb3RwZ3cNCi91 c3Ivb2JqL3Vzci9zcmMvbGliZXhlYy9ib290cGQvYm9vdHBndyBjcmVhdGVkIGZvciAvdXNyL3Ny Yy9saWJleGVjL2Jvb3RwZC9ib290cGd3DQo9PT0+IGxpYmV4ZWMvYm9vdHBkL3Rvb2xzDQo9PT0+ IGxpYmV4ZWMvYm9vdHBkL3Rvb2xzL2Jvb3RwZWYNCi91c3Ivb2JqL3Vzci9zcmMvbGliZXhlYy9i b290cGQvdG9vbHMvYm9vdHBlZiBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWJleGVjL2Jvb3RwZC90 b29scy9ib290cGVmDQo9PT0+IGxpYmV4ZWMvYm9vdHBkL3Rvb2xzL2Jvb3RwdGVzdA0KL3Vzci9v YmovdXNyL3NyYy9saWJleGVjL2Jvb3RwZC90b29scy9ib290cHRlc3QgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvbGliZXhlYy9ib290cGQvdG9vbHMvYm9vdHB0ZXN0DQo9PT0+IGxpYmV4ZWMvY29tc2F0 DQovdXNyL29iai91c3Ivc3JjL2xpYmV4ZWMvY29tc2F0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xp YmV4ZWMvY29tc2F0DQo9PT0+IGxpYmV4ZWMvZmluZ2VyZA0KL3Vzci9vYmovdXNyL3NyYy9saWJl eGVjL2ZpbmdlcmQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliZXhlYy9maW5nZXJkDQo9PT0+IGxp YmV4ZWMvZnRwZA0KL3Vzci9vYmovdXNyL3NyYy9saWJleGVjL2Z0cGQgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvbGliZXhlYy9mdHBkDQo9PT0+IGxpYmV4ZWMvZnRwLXByb3h5DQovdXNyL29iai91c3Iv c3JjL2xpYmV4ZWMvZnRwLXByb3h5IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xpYmV4ZWMvZnRwLXBy b3h5DQo9PT0+IGxpYmV4ZWMvZ2V0TkFNRQ0KL3Vzci9vYmovdXNyL3NyYy9saWJleGVjL2dldE5B TUUgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliZXhlYy9nZXROQU1FDQo9PT0+IGxpYmV4ZWMvZ2V0 dHkNCi91c3Ivb2JqL3Vzci9zcmMvbGliZXhlYy9nZXR0eSBjcmVhdGVkIGZvciAvdXNyL3NyYy9s aWJleGVjL2dldHR5DQo9PT0+IGxpYmV4ZWMvbWFrZWtleQ0KL3Vzci9vYmovdXNyL3NyYy9saWJl eGVjL21ha2VrZXkgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliZXhlYy9tYWtla2V5DQo9PT0+IGxp YmV4ZWMvbWtuZXRpZA0KL3Vzci9vYmovdXNyL3NyYy9saWJleGVjL21rbmV0aWQgY3JlYXRlZCBm b3IgL3Vzci9zcmMvbGliZXhlYy9ta25ldGlkDQo9PT0+IGxpYmV4ZWMvbmFtZWQteGZlcg0KL3Vz ci9vYmovdXNyL3NyYy9saWJleGVjL25hbWVkLXhmZXIgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGli ZXhlYy9uYW1lZC14ZmVyDQo9PT0+IGxpYmV4ZWMvcHBwb2VkDQovdXNyL29iai91c3Ivc3JjL2xp YmV4ZWMvcHBwb2VkIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xpYmV4ZWMvcHBwb2VkDQo9PT0+IGxp YmV4ZWMvcHRfY2hvd24NCi91c3Ivb2JqL3Vzci9zcmMvbGliZXhlYy9wdF9jaG93biBjcmVhdGVk IGZvciAvdXNyL3NyYy9saWJleGVjL3B0X2Nob3duDQo9PT0+IGxpYmV4ZWMvcmJvb3RkDQovdXNy L29iai91c3Ivc3JjL2xpYmV4ZWMvcmJvb3RkIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2xpYmV4ZWMv cmJvb3RkDQo9PT0+IGxpYmV4ZWMvcmV2bmV0Z3JvdXANCi91c3Ivb2JqL3Vzci9zcmMvbGliZXhl Yy9yZXZuZXRncm91cCBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWJleGVjL3Jldm5ldGdyb3VwDQo9 PT0+IGxpYmV4ZWMvcmV4ZWNkDQovdXNyL29iai91c3Ivc3JjL2xpYmV4ZWMvcmV4ZWNkIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL2xpYmV4ZWMvcmV4ZWNkDQo9PT0+IGxpYmV4ZWMvcmxvZ2luZA0KL3Vz ci9vYmovdXNyL3NyYy9saWJleGVjL3Jsb2dpbmQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliZXhl Yy9ybG9naW5kDQo9PT0+IGxpYmV4ZWMvcnBjLnJxdW90YWQNCi91c3Ivb2JqL3Vzci9zcmMvbGli ZXhlYy9ycGMucnF1b3RhZCBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWJleGVjL3JwYy5ycXVvdGFk DQo9PT0+IGxpYmV4ZWMvcnBjLnJzdGF0ZA0KL3Vzci9vYmovdXNyL3NyYy9saWJleGVjL3JwYy5y c3RhdGQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliZXhlYy9ycGMucnN0YXRkDQo9PT0+IGxpYmV4 ZWMvcnBjLnJ1c2Vyc2QNCi91c3Ivb2JqL3Vzci9zcmMvbGliZXhlYy9ycGMucnVzZXJzZCBjcmVh dGVkIGZvciAvdXNyL3NyYy9saWJleGVjL3JwYy5ydXNlcnNkDQo9PT0+IGxpYmV4ZWMvcnBjLnJ3 YWxsZA0KL3Vzci9vYmovdXNyL3NyYy9saWJleGVjL3JwYy5yd2FsbGQgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvbGliZXhlYy9ycGMucndhbGxkDQo9PT0+IGxpYmV4ZWMvcnBjLnNwcmF5ZA0KL3Vzci9v YmovdXNyL3NyYy9saWJleGVjL3JwYy5zcHJheWQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliZXhl Yy9ycGMuc3ByYXlkDQo9PT0+IGxpYmV4ZWMvcnNoZA0KL3Vzci9vYmovdXNyL3NyYy9saWJleGVj L3JzaGQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliZXhlYy9yc2hkDQo9PT0+IGxpYmV4ZWMvcnRs ZC1lbGYNCi91c3Ivb2JqL3Vzci9zcmMvbGliZXhlYy9ydGxkLWVsZiBjcmVhdGVkIGZvciAvdXNy L3NyYy9saWJleGVjL3J0bGQtZWxmDQo9PT0+IGxpYmV4ZWMvc2F2ZS1lbnRyb3B5DQo9PT0+IGxp YmV4ZWMvdGFsa2QNCi91c3Ivb2JqL3Vzci9zcmMvbGliZXhlYy90YWxrZCBjcmVhdGVkIGZvciAv dXNyL3NyYy9saWJleGVjL3RhbGtkDQo9PT0+IGxpYmV4ZWMvdGNwZA0KL3Vzci9vYmovdXNyL3Ny Yy9saWJleGVjL3RjcGQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvbGliZXhlYy90Y3BkDQo9PT0+IGxp YmV4ZWMvdGVsbmV0ZA0KL3Vzci9vYmovdXNyL3NyYy9saWJleGVjL3RlbG5ldGQgY3JlYXRlZCBm b3IgL3Vzci9zcmMvbGliZXhlYy90ZWxuZXRkDQo9PT0+IGxpYmV4ZWMvdGZ0cGQNCi91c3Ivb2Jq L3Vzci9zcmMvbGliZXhlYy90ZnRwZCBjcmVhdGVkIGZvciAvdXNyL3NyYy9saWJleGVjL3RmdHBk DQo9PT0+IGxpYmV4ZWMveXB4ZnINCi91c3Ivb2JqL3Vzci9zcmMvbGliZXhlYy95cHhmciBjcmVh dGVkIGZvciAvdXNyL3NyYy9saWJleGVjL3lweGZyDQo9PT0+IGJpbg0KPT09PiBiaW4vY2F0DQov dXNyL29iai91c3Ivc3JjL2Jpbi9jYXQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvYmluL2NhdA0KPT09 PiBiaW4vY2hmbGFncw0KL3Vzci9vYmovdXNyL3NyYy9iaW4vY2hmbGFncyBjcmVhdGVkIGZvciAv dXNyL3NyYy9iaW4vY2hmbGFncw0KPT09PiBiaW4vY2hpbw0KL3Vzci9vYmovdXNyL3NyYy9iaW4v Y2hpbyBjcmVhdGVkIGZvciAvdXNyL3NyYy9iaW4vY2hpbw0KPT09PiBiaW4vY2htb2QNCi91c3Iv b2JqL3Vzci9zcmMvYmluL2NobW9kIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2Jpbi9jaG1vZA0KPT09 PiBiaW4vY3ANCi91c3Ivb2JqL3Vzci9zcmMvYmluL2NwIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2Jp bi9jcA0KPT09PiBiaW4vY3NoDQovdXNyL29iai91c3Ivc3JjL2Jpbi9jc2ggY3JlYXRlZCBmb3Ig L3Vzci9zcmMvYmluL2NzaA0KPT09PiBiaW4vZGF0ZQ0KL3Vzci9vYmovdXNyL3NyYy9iaW4vZGF0 ZSBjcmVhdGVkIGZvciAvdXNyL3NyYy9iaW4vZGF0ZQ0KPT09PiBiaW4vZGQNCi91c3Ivb2JqL3Vz ci9zcmMvYmluL2RkIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2Jpbi9kZA0KPT09PiBiaW4vZGYNCi91 c3Ivb2JqL3Vzci9zcmMvYmluL2RmIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2Jpbi9kZg0KPT09PiBi aW4vZG9tYWlubmFtZQ0KL3Vzci9vYmovdXNyL3NyYy9iaW4vZG9tYWlubmFtZSBjcmVhdGVkIGZv ciAvdXNyL3NyYy9iaW4vZG9tYWlubmFtZQ0KPT09PiBiaW4vZWNobw0KL3Vzci9vYmovdXNyL3Ny Yy9iaW4vZWNobyBjcmVhdGVkIGZvciAvdXNyL3NyYy9iaW4vZWNobw0KPT09PiBiaW4vZWQNCi91 c3Ivb2JqL3Vzci9zcmMvYmluL2VkIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2Jpbi9lZA0KPT09PiBi aW4vZXhwcg0KL3Vzci9vYmovdXNyL3NyYy9iaW4vZXhwciBjcmVhdGVkIGZvciAvdXNyL3NyYy9i aW4vZXhwcg0KPT09PiBiaW4vZ2V0ZmFjbA0KL3Vzci9vYmovdXNyL3NyYy9iaW4vZ2V0ZmFjbCBj cmVhdGVkIGZvciAvdXNyL3NyYy9iaW4vZ2V0ZmFjbA0KPT09PiBiaW4vaG9zdG5hbWUNCi91c3Iv b2JqL3Vzci9zcmMvYmluL2hvc3RuYW1lIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2Jpbi9ob3N0bmFt ZQ0KPT09PiBiaW4va2Vudg0KL3Vzci9vYmovdXNyL3NyYy9iaW4va2VudiBjcmVhdGVkIGZvciAv dXNyL3NyYy9iaW4va2Vudg0KPT09PiBiaW4va2lsbA0KL3Vzci9vYmovdXNyL3NyYy9iaW4va2ls bCBjcmVhdGVkIGZvciAvdXNyL3NyYy9iaW4va2lsbA0KPT09PiBiaW4vbG4NCi91c3Ivb2JqL3Vz ci9zcmMvYmluL2xuIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2Jpbi9sbg0KPT09PiBiaW4vbHMNCi91 c3Ivb2JqL3Vzci9zcmMvYmluL2xzIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2Jpbi9scw0KPT09PiBi aW4vbWtkaXINCi91c3Ivb2JqL3Vzci9zcmMvYmluL21rZGlyIGNyZWF0ZWQgZm9yIC91c3Ivc3Jj L2Jpbi9ta2Rpcg0KPT09PiBiaW4vbXYNCi91c3Ivb2JqL3Vzci9zcmMvYmluL212IGNyZWF0ZWQg Zm9yIC91c3Ivc3JjL2Jpbi9tdg0KPT09PiBiaW4vcGF4DQovdXNyL29iai91c3Ivc3JjL2Jpbi9w YXggY3JlYXRlZCBmb3IgL3Vzci9zcmMvYmluL3BheA0KPT09PiBiaW4vcHMNCi91c3Ivb2JqL3Vz ci9zcmMvYmluL3BzIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2Jpbi9wcw0KPT09PiBiaW4vcHdkDQov dXNyL29iai91c3Ivc3JjL2Jpbi9wd2QgY3JlYXRlZCBmb3IgL3Vzci9zcmMvYmluL3B3ZA0KPT09 PiBiaW4vcmNwDQovdXNyL29iai91c3Ivc3JjL2Jpbi9yY3AgY3JlYXRlZCBmb3IgL3Vzci9zcmMv YmluL3JjcA0KPT09PiBiaW4vcmVhbHBhdGgNCi91c3Ivb2JqL3Vzci9zcmMvYmluL3JlYWxwYXRo IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2Jpbi9yZWFscGF0aA0KPT09PiBiaW4vcm0NCi91c3Ivb2Jq L3Vzci9zcmMvYmluL3JtIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2Jpbi9ybQ0KPT09PiBiaW4vcm1k aXINCi91c3Ivb2JqL3Vzci9zcmMvYmluL3JtZGlyIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2Jpbi9y bWRpcg0KPT09PiBiaW4vc2V0ZmFjbA0KL3Vzci9vYmovdXNyL3NyYy9iaW4vc2V0ZmFjbCBjcmVh dGVkIGZvciAvdXNyL3NyYy9iaW4vc2V0ZmFjbA0KPT09PiBiaW4vc2gNCi91c3Ivb2JqL3Vzci9z cmMvYmluL3NoIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2Jpbi9zaA0KPT09PiBiaW4vc2xlZXANCi91 c3Ivb2JqL3Vzci9zcmMvYmluL3NsZWVwIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2Jpbi9zbGVlcA0K PT09PiBiaW4vc3R0eQ0KL3Vzci9vYmovdXNyL3NyYy9iaW4vc3R0eSBjcmVhdGVkIGZvciAvdXNy L3NyYy9iaW4vc3R0eQ0KPT09PiBiaW4vc3luYw0KL3Vzci9vYmovdXNyL3NyYy9iaW4vc3luYyBj cmVhdGVkIGZvciAvdXNyL3NyYy9iaW4vc3luYw0KPT09PiBiaW4vdGVzdA0KL3Vzci9vYmovdXNy L3NyYy9iaW4vdGVzdCBjcmVhdGVkIGZvciAvdXNyL3NyYy9iaW4vdGVzdA0KPT09PiBnbnUNCj09 PT4gZ251L2xpYg0KPT09PiBnbnUvbGliL2NzdQ0KL3Vzci9vYmovdXNyL3NyYy9nbnUvbGliL2Nz dSBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvbGliL2NzdQ0KPT09PiBnbnUvbGliL2xpYmdjYw0K L3Vzci9vYmovdXNyL3NyYy9nbnUvbGliL2xpYmdjYyBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUv bGliL2xpYmdjYw0KPT09PiBnbnUvbGliL2xpYmRpYWxvZw0KL3Vzci9vYmovdXNyL3NyYy9nbnUv bGliL2xpYmRpYWxvZyBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvbGliL2xpYmRpYWxvZw0KPT09 PiBnbnUvbGliL2xpYnJlZ2V4DQovdXNyL29iai91c3Ivc3JjL2dudS9saWIvbGlicmVnZXggY3Jl YXRlZCBmb3IgL3Vzci9zcmMvZ251L2xpYi9saWJyZWdleA0KPT09PiBnbnUvbGliL2xpYnJlZ2V4 L2RvYw0KL3Vzci9vYmovdXNyL3NyYy9nbnUvbGliL2xpYnJlZ2V4L2RvYyBjcmVhdGVkIGZvciAv dXNyL3NyYy9nbnUvbGliL2xpYnJlZ2V4L2RvYw0KPT09PiBnbnUvbGliL2xpYnJlYWRsaW5lDQo9 PT0+IGdudS9saWIvbGlicmVhZGxpbmUvaGlzdG9yeQ0KL3Vzci9vYmovdXNyL3NyYy9nbnUvbGli L2xpYnJlYWRsaW5lL2hpc3RvcnkgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L2xpYi9saWJyZWFk bGluZS9oaXN0b3J5DQo9PT0+IGdudS9saWIvbGlicmVhZGxpbmUvaGlzdG9yeS9kb2MNCi91c3Iv b2JqL3Vzci9zcmMvZ251L2xpYi9saWJyZWFkbGluZS9oaXN0b3J5L2RvYyBjcmVhdGVkIGZvciAv dXNyL3NyYy9nbnUvbGliL2xpYnJlYWRsaW5lL2hpc3RvcnkvZG9jDQo9PT0+IGdudS9saWIvbGli cmVhZGxpbmUvcmVhZGxpbmUNCi91c3Ivb2JqL3Vzci9zcmMvZ251L2xpYi9saWJyZWFkbGluZS9y ZWFkbGluZSBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvbGliL2xpYnJlYWRsaW5lL3JlYWRsaW5l DQo9PT0+IGdudS9saWIvbGlicmVhZGxpbmUvcmVhZGxpbmUvZG9jDQovdXNyL29iai91c3Ivc3Jj L2dudS9saWIvbGlicmVhZGxpbmUvcmVhZGxpbmUvZG9jIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2du dS9saWIvbGlicmVhZGxpbmUvcmVhZGxpbmUvZG9jDQo9PT0+IGdudS9saWIvbGlic3RkYysrDQov dXNyL29iai91c3Ivc3JjL2dudS9saWIvbGlic3RkYysrIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2du dS9saWIvbGlic3RkYysrDQo9PT0+IGdudS9saWIvbGlic3VwYysrDQovdXNyL29iai91c3Ivc3Jj L2dudS9saWIvbGlic3VwYysrIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS9saWIvbGlic3VwYysr DQo9PT0+IGdudS9saWIvbGlib2JqYw0KL3Vzci9vYmovdXNyL3NyYy9nbnUvbGliL2xpYm9iamMg Y3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L2xpYi9saWJvYmpjDQo9PT0+IGdudS9saWIvbGliZzJj DQovdXNyL29iai91c3Ivc3JjL2dudS9saWIvbGliZzJjIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2du dS9saWIvbGliZzJjDQo9PT0+IGdudS91c3IuYmluDQo9PT0+IGdudS91c3IuYmluL2JjDQovdXNy L29iai91c3Ivc3JjL2dudS91c3IuYmluL2JjIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3Iu YmluL2JjDQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxzDQo9PT0+IGdudS91c3IuYmluL2JpbnV0 aWxzL2xpYmliZXJ0eQ0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJp YmVydHkgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5 DQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZA0KL3Vzci9vYmovdXNyL3NyYy9nbnUv dXNyLmJpbi9iaW51dGlscy9saWJiZmQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvbGliYmZkDQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxzL2xpYm9wY29kZXMNCi91 c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGlib3Bjb2RlcyBjcmVhdGVkIGZv ciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJvcGNvZGVzDQo9PT0+IGdudS91c3Iu YmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2Jp bnV0aWxzL2xpYmJpbnV0aWxzIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0 aWxzL2xpYmJpbnV0aWxzDQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxzL2FkZHIybGluZQ0KL3Vz ci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hZGRyMmxpbmUgY3JlYXRlZCBmb3Ig L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYWRkcjJsaW5lDQo9PT0+IGdudS91c3IuYmlu L2JpbnV0aWxzL2FyDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FyIGNy ZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FyDQo9PT0+IGdudS91c3Iu YmluL2JpbnV0aWxzL2FzDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2Fz IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzDQo9PT0+IGdudS91 c3IuYmluL2JpbnV0aWxzL2xkDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2xkIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xkDQo9PT0+IGdu dS91c3IuYmluL2JpbnV0aWxzL25tDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0 aWxzL25tIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL25tDQo9PT0+ IGdudS91c3IuYmluL2JpbnV0aWxzL29iamNvcHkNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5i aW4vYmludXRpbHMvb2JqY29weSBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51 dGlscy9vYmpjb3B5DQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxzL29iamR1bXANCi91c3Ivb2Jq L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvb2JqZHVtcCBjcmVhdGVkIGZvciAvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9vYmpkdW1wDQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxz L3JhbmxpYg0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9yYW5saWIgY3Jl YXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvcmFubGliDQo9PT0+IGdudS91 c3IuYmluL2JpbnV0aWxzL3JlYWRlbGYNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvcmVhZGVsZiBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9y ZWFkZWxmDQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxzL3NpemUNCi91c3Ivb2JqL3Vzci9zcmMv Z251L3Vzci5iaW4vYmludXRpbHMvc2l6ZSBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJp bi9iaW51dGlscy9zaXplDQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxzL3N0cmluZ3MNCi91c3Iv b2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvc3RyaW5ncyBjcmVhdGVkIGZvciAvdXNy L3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9zdHJpbmdzDQo9PT0+IGdudS91c3IuYmluL2JpbnV0 aWxzL3N0cmlwDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL3N0cmlwIGNy ZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL3N0cmlwDQo9PT0+IGdudS91 c3IuYmluL2JpbnV0aWxzL2RvYw0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9kb2MgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvZG9jDQo9PT0+ IGdudS91c3IuYmluL2NjDQo9PT0+IGdudS91c3IuYmluL2NjL2NjX3Rvb2xzDQovdXNyL29iai91 c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91 c3IuYmluL2NjL2NjX3Rvb2xzDQo9PT0+IGdudS91c3IuYmluL2NjL2NjX2ludA0KL3Vzci9vYmov dXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY19pbnQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vz ci5iaW4vY2MvY2NfaW50DQo9PT0+IGdudS91c3IuYmluL2NjL2NjDQovdXNyL29iai91c3Ivc3Jj L2dudS91c3IuYmluL2NjL2NjIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2NjL2Nj DQo9PT0+IGdudS91c3IuYmluL2NjL2NjMQ0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9j Yy9jYzEgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2MxDQo9PT0+IGdudS91 c3IuYmluL2NjL2luY2x1ZGUNCj09PT4gZ251L3Vzci5iaW4vY2MvcHJvdG9pemUNCi91c3Ivb2Jq L3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvcHJvdG9pemUgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251 L3Vzci5iaW4vY2MvcHJvdG9pemUNCj09PT4gZ251L3Vzci5iaW4vY2MvZG9jDQovdXNyL29iai91 c3Ivc3JjL2dudS91c3IuYmluL2NjL2RvYyBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJp bi9jYy9kb2MNCj09PT4gZ251L3Vzci5iaW4vY2MvY3BwDQovdXNyL29iai91c3Ivc3JjL2dudS91 c3IuYmluL2NjL2NwcCBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jcHANCj09 PT4gZ251L3Vzci5iaW4vY2MvY2MxcGx1cw0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9j Yy9jYzFwbHVzIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjMXBsdXMNCj09 PT4gZ251L3Vzci5iaW4vY2MvYysrDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2NjL2Mr KyBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jKysNCj09PT4gZ251L3Vzci5i aW4vY2MvY2Mxb2JqDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjMW9iaiBjcmVh dGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jYzFvYmoNCj09PT4gZ251L3Vzci5iaW4v Y2MvZjc3DQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2NjL2Y3NyBjcmVhdGVkIGZvciAv dXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9mNzcNCj09PT4gZ251L3Vzci5iaW4vY2MvZjc3MQ0KL3Vz ci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9mNzcxIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2du dS91c3IuYmluL2NjL2Y3NzENCj09PT4gZ251L3Vzci5iaW4vY2MvZjc3ZG9jDQovdXNyL29iai91 c3Ivc3JjL2dudS91c3IuYmluL2NjL2Y3N2RvYyBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNy LmJpbi9jYy9mNzdkb2MNCj09PT4gZ251L3Vzci5iaW4vY2MvZ2Nvdg0KL3Vzci9vYmovdXNyL3Ny Yy9nbnUvdXNyLmJpbi9jYy9nY292IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2Nj L2djb3YNCj09PT4gZ251L3Vzci5iaW4vY3Bpbw0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJp bi9jcGlvIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2NwaW8NCj09PT4gZ251L3Vz ci5iaW4vY3Bpby9kb2MNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY3Bpby9kb2MgY3Jl YXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vY3Bpby9kb2MNCj09PT4gZ251L3Vzci5iaW4v Y3ZzDQo9PT0+IGdudS91c3IuYmluL2N2cy9saWINCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5i aW4vY3ZzL2xpYiBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jdnMvbGliDQo9PT0+ IGdudS91c3IuYmluL2N2cy9saWJkaWZmDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2N2 cy9saWJkaWZmIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2N2cy9saWJkaWZmDQo9 PT0+IGdudS91c3IuYmluL2N2cy9jdnMNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY3Zz L2N2cyBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jdnMvY3ZzDQo9PT0+IGdudS91 c3IuYmluL2N2cy9jb250cmliDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2N2cy9jb250 cmliIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2N2cy9jb250cmliDQo9PT0+IGdu dS91c3IuYmluL2N2cy9jdnNidWcNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY3ZzL2N2 c2J1ZyBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jdnMvY3ZzYnVnDQo9PT0+IGdu dS91c3IuYmluL2N2cy9kb2MNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY3ZzL2RvYyBj cmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jdnMvZG9jDQo9PT0+IGdudS91c3IuYmlu L2RjDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2RjIGNyZWF0ZWQgZm9yIC91c3Ivc3Jj L2dudS91c3IuYmluL2RjDQo9PT0+IGdudS91c3IuYmluL2RjL2RvYw0KL3Vzci9vYmovdXNyL3Ny Yy9nbnUvdXNyLmJpbi9kYy9kb2MgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vZGMv ZG9jDQo9PT0+IGdudS91c3IuYmluL2RpYWxvZw0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJp bi9kaWFsb2cgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vZGlhbG9nDQo9PT0+IGdu dS91c3IuYmluL2RpYWxvZy9URVNUUw0KPT09PiBnbnUvdXNyLmJpbi9kaWZmDQovdXNyL29iai91 c3Ivc3JjL2dudS91c3IuYmluL2RpZmYgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4v ZGlmZg0KPT09PiBnbnUvdXNyLmJpbi9kaWZmL2RvYw0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNy LmJpbi9kaWZmL2RvYyBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9kaWZmL2RvYw0K PT09PiBnbnUvdXNyLmJpbi9kaWZmMw0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9kaWZm MyBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9kaWZmMw0KPT09PiBnbnUvdXNyLmJp bi9nZGINCj09PT4gZ251L3Vzci5iaW4vZ2RiL2RvYw0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNy LmJpbi9nZGIvZG9jIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2dkYi9kb2MNCj09 PT4gZ251L3Vzci5iaW4vZ2RiL2xpYmdkYg0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9n ZGIvbGliZ2RiIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2dkYi9saWJnZGINCj09 PT4gZ251L3Vzci5iaW4vZ2RiL2dkYg0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9nZGIv Z2RiIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2dkYi9nZGINCj09PT4gZ251L3Vz ci5iaW4vZ2RiL2dkYnR1aQ0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9nZGIvZ2RidHVp IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2dkYi9nZGJ0dWkNCj09PT4gZ251L3Vz ci5iaW4vZ2RiL2tnZGINCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vZ2RiL2tnZGIgY3Jl YXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ2RiL2tnZGINCj09PT4gZ251L3Vzci5iaW4v Z3BlcmYNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYNCj09PT4gZ251L3Vzci5iaW4vZ3BlcmYvZG9jDQovdXNy L29iai91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmL2RvYyBjcmVhdGVkIGZvciAvdXNyL3NyYy9n bnUvdXNyLmJpbi9ncGVyZi9kb2MNCj09PT4gZ251L3Vzci5iaW4vZ3JlcA0KL3Vzci9vYmovdXNy L3NyYy9nbnUvdXNyLmJpbi9ncmVwIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2dy ZXANCj09PT4gZ251L3Vzci5iaW4vZ3JlcC9kb2MNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5i aW4vZ3JlcC9kb2MgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JlcC9kb2MNCj09 PT4gZ251L3Vzci5iaW4vZ3JvZmYNCj09PT4gZ251L3Vzci5iaW4vZ3JvZmYvY29udHJpYg0KPT09 PiBnbnUvdXNyLmJpbi9ncm9mZi9jb250cmliL21tDQovdXNyL29iai91c3Ivc3JjL2dudS91c3Iu YmluL2dyb2ZmL2NvbnRyaWIvbW0gY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3Jv ZmYvY29udHJpYi9tbQ0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9kb2MNCi91c3Ivb2JqL3Vzci9z cmMvZ251L3Vzci5iaW4vZ3JvZmYvZG9jIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmlu L2dyb2ZmL2RvYw0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9mb250DQo9PT0+IGdudS91c3IuYmlu L2dyb2ZmL2ZvbnQvZGV2WDEwMA0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9mb250L2RldlgxMDAt MTINCj09PT4gZ251L3Vzci5iaW4vZ3JvZmYvZm9udC9kZXZYNzUNCj09PT4gZ251L3Vzci5iaW4v Z3JvZmYvZm9udC9kZXZYNzUtMTINCj09PT4gZ251L3Vzci5iaW4vZ3JvZmYvZm9udC9kZXZhc2Np aQ0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi9mb250L2RldmFzY2lpIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL2ZvbnQvZGV2YXNjaWkNCj09PT4gZ251 L3Vzci5iaW4vZ3JvZmYvZm9udC9kZXZjcDEwNDcNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5i aW4vZ3JvZmYvZm9udC9kZXZjcDEwNDcgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4v Z3JvZmYvZm9udC9kZXZjcDEwNDcNCj09PT4gZ251L3Vzci5iaW4vZ3JvZmYvZm9udC9kZXZkdmkN Ci91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvZm9udC9kZXZkdmkgY3JlYXRlZCBm b3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvZm9udC9kZXZkdmkNCj09PT4gZ251L3Vzci5i aW4vZ3JvZmYvZm9udC9kZXZodG1sDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2dyb2Zm L2ZvbnQvZGV2aHRtbCBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi9mb250 L2Rldmh0bWwNCj09PT4gZ251L3Vzci5iaW4vZ3JvZmYvZm9udC9kZXZrb2k4LXINCi91c3Ivb2Jq L3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvZm9udC9kZXZrb2k4LXIgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvZm9udC9kZXZrb2k4LXINCj09PT4gZ251L3Vzci5iaW4v Z3JvZmYvZm9udC9kZXZsYXRpbjENCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYv Zm9udC9kZXZsYXRpbjEgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvZm9u dC9kZXZsYXRpbjENCj09PT4gZ251L3Vzci5iaW4vZ3JvZmYvZm9udC9kZXZsYnANCi91c3Ivb2Jq L3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvZm9udC9kZXZsYnAgY3JlYXRlZCBmb3IgL3Vzci9z cmMvZ251L3Vzci5iaW4vZ3JvZmYvZm9udC9kZXZsYnANCj09PT4gZ251L3Vzci5iaW4vZ3JvZmYv Zm9udC9kZXZsajQNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvZm9udC9kZXZs ajQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvZm9udC9kZXZsajQNCj09 PT4gZ251L3Vzci5iaW4vZ3JvZmYvZm9udC9kZXZwcw0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNy LmJpbi9ncm9mZi9mb250L2RldnBzIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2dy b2ZmL2ZvbnQvZGV2cHMNCj09PT4gZ251L3Vzci5iaW4vZ3JvZmYvZm9udC9kZXZ1dGY4DQovdXNy L29iai91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL2ZvbnQvZGV2dXRmOCBjcmVhdGVkIGZvciAv dXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi9mb250L2RldnV0ZjgNCj09PT4gZ251L3Vzci5iaW4v Z3JvZmYvbWFuDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL21hbiBjcmVhdGVk IGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi9tYW4NCj09PT4gZ251L3Vzci5iaW4vZ3Jv ZmYvc3JjDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9saWJzDQo9PT0+IGdudS91c3IuYmlu L2dyb2ZmL3NyYy9saWJzL2xpYmdyb2ZmDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2dy b2ZmL3NyYy9saWJzL2xpYmdyb2ZmIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2dy b2ZmL3NyYy9saWJzL2xpYmdyb2ZmDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9saWJzL2xp YmRyaXZlcg0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi9zcmMvbGlicy9saWJk cml2ZXIgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvc3JjL2xpYnMvbGli ZHJpdmVyDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9saWJzL2xpYmJpYg0KL3Vzci9vYmov dXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi9zcmMvbGlicy9saWJiaWIgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvc3JjL2xpYnMvbGliYmliDQo9PT0+IGdudS91c3IuYmlu L2dyb2ZmL3NyYy9kZXZpY2VzDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9kZXZpY2VzL2dy b2R2aQ0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi9zcmMvZGV2aWNlcy9ncm9k dmkgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvc3JjL2RldmljZXMvZ3Jv ZHZpDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9kZXZpY2VzL2dyb2h0bWwNCi91c3Ivb2Jq L3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvc3JjL2RldmljZXMvZ3JvaHRtbCBjcmVhdGVkIGZv ciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi9zcmMvZGV2aWNlcy9ncm9odG1sDQo9PT0+IGdu dS91c3IuYmluL2dyb2ZmL3NyYy9kZXZpY2VzL2dyb2xicA0KL3Vzci9vYmovdXNyL3NyYy9nbnUv dXNyLmJpbi9ncm9mZi9zcmMvZGV2aWNlcy9ncm9sYnAgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251 L3Vzci5iaW4vZ3JvZmYvc3JjL2RldmljZXMvZ3JvbGJwDQo9PT0+IGdudS91c3IuYmluL2dyb2Zm L3NyYy9kZXZpY2VzL2dyb2xqNA0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi9z cmMvZGV2aWNlcy9ncm9sajQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYv c3JjL2RldmljZXMvZ3JvbGo0DQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9kZXZpY2VzL2dy b3BzDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3NyYy9kZXZpY2VzL2dyb3Bz IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3NyYy9kZXZpY2VzL2dyb3Bz DQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9kZXZpY2VzL2dyb3R0eQ0KL3Vzci9vYmovdXNy L3NyYy9nbnUvdXNyLmJpbi9ncm9mZi9zcmMvZGV2aWNlcy9ncm90dHkgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvc3JjL2RldmljZXMvZ3JvdHR5DQo9PT0+IGdudS91c3Iu YmluL2dyb2ZmL3NyYy9wcmVwcm9jDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9wcmVwcm9j L2Vxbg0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi9zcmMvcHJlcHJvYy9lcW4g Y3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvc3JjL3ByZXByb2MvZXFuDQo9 PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9wcmVwcm9jL2dybg0KL3Vzci9vYmovdXNyL3NyYy9n bnUvdXNyLmJpbi9ncm9mZi9zcmMvcHJlcHJvYy9ncm4gY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251 L3Vzci5iaW4vZ3JvZmYvc3JjL3ByZXByb2MvZ3JuDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3Ny Yy9wcmVwcm9jL2h0bWwNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvc3JjL3By ZXByb2MvaHRtbCBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi9zcmMvcHJl cHJvYy9odG1sDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9wcmVwcm9jL3BpYw0KL3Vzci9v YmovdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi9zcmMvcHJlcHJvYy9waWMgY3JlYXRlZCBmb3Ig L3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvc3JjL3ByZXByb2MvcGljDQo9PT0+IGdudS91c3Iu YmluL2dyb2ZmL3NyYy9wcmVwcm9jL3JlZmVyDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmlu L2dyb2ZmL3NyYy9wcmVwcm9jL3JlZmVyIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmlu L2dyb2ZmL3NyYy9wcmVwcm9jL3JlZmVyDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9wcmVw cm9jL3NvZWxpbQ0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi9zcmMvcHJlcHJv Yy9zb2VsaW0gY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvc3JjL3ByZXBy b2Mvc29lbGltDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9wcmVwcm9jL3RibA0KL3Vzci9v YmovdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi9zcmMvcHJlcHJvYy90YmwgY3JlYXRlZCBmb3Ig L3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvc3JjL3ByZXByb2MvdGJsDQo9PT0+IGdudS91c3Iu YmluL2dyb2ZmL3NyYy9yb2ZmDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9yb2ZmL2dyb2Zm DQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3NyYy9yb2ZmL2dyb2ZmIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3NyYy9yb2ZmL2dyb2ZmDQo9PT0+IGdu dS91c3IuYmluL2dyb2ZmL3NyYy9yb2ZmL2dyb2cNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5i aW4vZ3JvZmYvc3JjL3JvZmYvZ3JvZyBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9n cm9mZi9zcmMvcm9mZi9ncm9nDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9yb2ZmL25yb2Zm DQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3NyYy9yb2ZmL25yb2ZmIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3NyYy9yb2ZmL25yb2ZmDQo9PT0+IGdu dS91c3IuYmluL2dyb2ZmL3NyYy9yb2ZmL3Bzcm9mZg0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNy LmJpbi9ncm9mZi9zcmMvcm9mZi9wc3JvZmYgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5i aW4vZ3JvZmYvc3JjL3JvZmYvcHNyb2ZmDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy9yb2Zm L3Ryb2ZmDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3NyYy9yb2ZmL3Ryb2Zm IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3NyYy9yb2ZmL3Ryb2ZmDQo9 PT0+IGdudS91c3IuYmluL2dyb2ZmL3NyYy91dGlscw0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9z cmMvdXRpbHMvYWRkZnRpbmZvDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3Ny Yy91dGlscy9hZGRmdGluZm8gY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYv c3JjL3V0aWxzL2FkZGZ0aW5mbw0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9zcmMvdXRpbHMvYWZt dG9kaXQNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvc3JjL3V0aWxzL2FmbXRv ZGl0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3NyYy91dGlscy9hZm10 b2RpdA0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9zcmMvdXRpbHMvaHBmdG9kaXQNCi91c3Ivb2Jq L3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvc3JjL3V0aWxzL2hwZnRvZGl0IGNyZWF0ZWQgZm9y IC91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3NyYy91dGlscy9ocGZ0b2RpdA0KPT09PiBnbnUv dXNyLmJpbi9ncm9mZi9zcmMvdXRpbHMvaW5keGJpYg0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNy LmJpbi9ncm9mZi9zcmMvdXRpbHMvaW5keGJpYiBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNy LmJpbi9ncm9mZi9zcmMvdXRpbHMvaW5keGJpYg0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9zcmMv dXRpbHMvbGtiaWINCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvc3JjL3V0aWxz L2xrYmliIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3NyYy91dGlscy9s a2JpYg0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9zcmMvdXRpbHMvbG9va2JpYg0KL3Vzci9vYmov dXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi9zcmMvdXRpbHMvbG9va2JpYiBjcmVhdGVkIGZvciAv dXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi9zcmMvdXRpbHMvbG9va2JpYg0KPT09PiBnbnUvdXNy LmJpbi9ncm9mZi9zcmMvdXRpbHMvcGZidG9wcw0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJp bi9ncm9mZi9zcmMvdXRpbHMvcGZidG9wcyBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJp bi9ncm9mZi9zcmMvdXRpbHMvcGZidG9wcw0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi9zcmMvdXRp bHMvdGZtdG9kaXQNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvc3JjL3V0aWxz L3RmbXRvZGl0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3NyYy91dGls cy90Zm10b2RpdA0KPT09PiBnbnUvdXNyLmJpbi9ncm9mZi90bWFjDQovdXNyL29iai91c3Ivc3Jj L2dudS91c3IuYmluL2dyb2ZmL3RtYWMgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4v Z3JvZmYvdG1hYw0KPT09PiBnbnUvdXNyLmJpbi9nemlwDQovdXNyL29iai91c3Ivc3JjL2dudS91 c3IuYmluL2d6aXAgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3ppcA0KPT09PiBn bnUvdXNyLmJpbi9tYW4NCj09PT4gZ251L3Vzci5iaW4vbWFuL2xpYg0KL3Vzci9vYmovdXNyL3Ny Yy9nbnUvdXNyLmJpbi9tYW4vbGliIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL21h bi9saWINCj09PT4gZ251L3Vzci5iaW4vbWFuL21hbg0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNy LmJpbi9tYW4vbWFuIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL21hbi9tYW4NCj09 PT4gZ251L3Vzci5iaW4vbWFuL21hbnBhdGgNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4v bWFuL21hbnBhdGggY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vbWFuL21hbnBhdGgN Cj09PT4gZ251L3Vzci5iaW4vbWFuL2Fwcm9wb3MNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5i aW4vbWFuL2Fwcm9wb3MgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vbWFuL2Fwcm9w b3MNCj09PT4gZ251L3Vzci5iaW4vcGF0Y2gNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4v cGF0Y2ggY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vcGF0Y2gNCj09PT4gZ251L3Vz ci5iaW4vcmNzDQo9PT0+IGdudS91c3IuYmluL3Jjcy9saWINCi91c3Ivb2JqL3Vzci9zcmMvZ251 L3Vzci5iaW4vcmNzL2xpYiBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9yY3MvbGli DQo9PT0+IGdudS91c3IuYmluL3Jjcy9jaQ0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9y Y3MvY2kgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vcmNzL2NpDQo9PT0+IGdudS91 c3IuYmluL3Jjcy9jbw0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9yY3MvY28gY3JlYXRl ZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vcmNzL2NvDQo9PT0+IGdudS91c3IuYmluL3Jjcy9p ZGVudA0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9yY3MvaWRlbnQgY3JlYXRlZCBmb3Ig L3Vzci9zcmMvZ251L3Vzci5iaW4vcmNzL2lkZW50DQo9PT0+IGdudS91c3IuYmluL3Jjcy9tZXJn ZQ0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9yY3MvbWVyZ2UgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvZ251L3Vzci5iaW4vcmNzL21lcmdlDQo9PT0+IGdudS91c3IuYmluL3Jjcy9yY3MNCi91 c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vcmNzL3JjcyBjcmVhdGVkIGZvciAvdXNyL3NyYy9n bnUvdXNyLmJpbi9yY3MvcmNzDQo9PT0+IGdudS91c3IuYmluL3Jjcy9yY3NjbGVhbg0KL3Vzci9v YmovdXNyL3NyYy9nbnUvdXNyLmJpbi9yY3MvcmNzY2xlYW4gY3JlYXRlZCBmb3IgL3Vzci9zcmMv Z251L3Vzci5iaW4vcmNzL3Jjc2NsZWFuDQo9PT0+IGdudS91c3IuYmluL3Jjcy9yY3NkaWZmDQov dXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL3Jjcy9yY3NkaWZmIGNyZWF0ZWQgZm9yIC91c3Iv c3JjL2dudS91c3IuYmluL3Jjcy9yY3NkaWZmDQo9PT0+IGdudS91c3IuYmluL3Jjcy9yY3NtZXJn ZQ0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9yY3MvcmNzbWVyZ2UgY3JlYXRlZCBmb3Ig L3Vzci9zcmMvZ251L3Vzci5iaW4vcmNzL3Jjc21lcmdlDQo9PT0+IGdudS91c3IuYmluL3Jjcy9y bG9nDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL3Jjcy9ybG9nIGNyZWF0ZWQgZm9yIC91 c3Ivc3JjL2dudS91c3IuYmluL3Jjcy9ybG9nDQo9PT0+IGdudS91c3IuYmluL3Jjcy9yY3NmcmVl emUNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vcmNzL3Jjc2ZyZWV6ZSBjcmVhdGVkIGZv ciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9yY3MvcmNzZnJlZXplDQo9PT0+IGdudS91c3IuYmluL3Nk aWZmDQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL3NkaWZmIGNyZWF0ZWQgZm9yIC91c3Iv c3JjL2dudS91c3IuYmluL3NkaWZmDQo9PT0+IGdudS91c3IuYmluL3NlbmQtcHINCi91c3Ivb2Jq L3Vzci9zcmMvZ251L3Vzci5iaW4vc2VuZC1wciBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNy LmJpbi9zZW5kLXByDQo9PT0+IGdudS91c3IuYmluL3NlbmQtcHIvZG9jDQovdXNyL29iai91c3Iv c3JjL2dudS91c3IuYmluL3NlbmQtcHIvZG9jIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3Iu YmluL3NlbmQtcHIvZG9jDQo9PT0+IGdudS91c3IuYmluL3NvcnQNCi91c3Ivb2JqL3Vzci9zcmMv Z251L3Vzci5iaW4vc29ydCBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9zb3J0DQo9 PT0+IGdudS91c3IuYmluL3Rhcg0KL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi90YXIgY3Jl YXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vdGFyDQo9PT0+IGdudS91c3IuYmluL3Rhci9k b2MNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vdGFyL2RvYyBjcmVhdGVkIGZvciAvdXNy L3NyYy9nbnUvdXNyLmJpbi90YXIvZG9jDQo9PT0+IGdudS91c3IuYmluL3RleGluZm8NCj09PT4g Z251L3Vzci5iaW4vdGV4aW5mby9saWJ0eGkNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4v dGV4aW5mby9saWJ0eGkgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9s aWJ0eGkNCj09PT4gZ251L3Vzci5iaW4vdGV4aW5mby9tYWtlaW5mbw0KL3Vzci9vYmovdXNyL3Ny Yy9nbnUvdXNyLmJpbi90ZXhpbmZvL21ha2VpbmZvIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91 c3IuYmluL3RleGluZm8vbWFrZWluZm8NCj09PT4gZ251L3Vzci5iaW4vdGV4aW5mby9pbmZvDQov dXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5mbyBjcmVhdGVkIGZvciAvdXNy L3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm8NCj09PT4gZ251L3Vzci5iaW4vdGV4aW5mby9p bmZva2V5DQovdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vaW5mb2tleSBjcmVh dGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL2luZm9rZXkNCj09PT4gZ251L3Vz ci5iaW4vdGV4aW5mby9pbnN0YWxsLWluZm8NCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4v dGV4aW5mby9pbnN0YWxsLWluZm8gY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4 aW5mby9pbnN0YWxsLWluZm8NCj09PT4gZ251L3Vzci5iaW4vdGV4aW5mby90ZXhpbmRleA0KL3Vz ci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi90ZXhpbmZvL3RleGluZGV4IGNyZWF0ZWQgZm9yIC91 c3Ivc3JjL2dudS91c3IuYmluL3RleGluZm8vdGV4aW5kZXgNCj09PT4gZ251L3Vzci5iaW4vdGV4 aW5mby9kb2MNCi91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9kb2MgY3JlYXRl ZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vdGV4aW5mby9kb2MNCj09PT4gc2Jpbg0KPT09PiBz YmluL2Fkamtlcm50eg0KL3Vzci9vYmovdXNyL3NyYy9zYmluL2Fkamtlcm50eiBjcmVhdGVkIGZv ciAvdXNyL3NyYy9zYmluL2Fkamtlcm50eg0KPT09PiBzYmluL2F0YWNvbnRyb2wNCi91c3Ivb2Jq L3Vzci9zcmMvc2Jpbi9hdGFjb250cm9sIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vYXRhY29u dHJvbA0KPT09PiBzYmluL2F0bQ0KPT09PiBzYmluL2F0bS9hdG0NCi91c3Ivb2JqL3Vzci9zcmMv c2Jpbi9hdG0vYXRtIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vYXRtL2F0bQ0KPT09PiBzYmlu L2F0bS9hdG1jb25maWcNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9hdG0vYXRtY29uZmlnIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL3NiaW4vYXRtL2F0bWNvbmZpZw0KPT09PiBzYmluL2F0bS9mb3JlX2Ru bGQNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9hdG0vZm9yZV9kbmxkIGNyZWF0ZWQgZm9yIC91c3Iv c3JjL3NiaW4vYXRtL2ZvcmVfZG5sZA0KPT09PiBzYmluL2F0bS9pbG1pZA0KL3Vzci9vYmovdXNy L3NyYy9zYmluL2F0bS9pbG1pZCBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL2F0bS9pbG1pZA0K PT09PiBzYmluL2JhZHNlY3QNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9iYWRzZWN0IGNyZWF0ZWQg Zm9yIC91c3Ivc3JjL3NiaW4vYmFkc2VjdA0KPT09PiBzYmluL2JzZGxhYmVsDQovdXNyL29iai91 c3Ivc3JjL3NiaW4vYnNkbGFiZWwgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9ic2RsYWJlbA0K PT09PiBzYmluL2NhbWNvbnRyb2wNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9jYW1jb250cm9sIGNy ZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vY2FtY29udHJvbA0KPT09PiBzYmluL2NjZGNvbmZpZw0K L3Vzci9vYmovdXNyL3NyYy9zYmluL2NjZGNvbmZpZyBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmlu L2NjZGNvbmZpZw0KPT09PiBzYmluL2NscmkNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9jbHJpIGNy ZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vY2xyaQ0KPT09PiBzYmluL2NvbWNvbnRyb2wNCi91c3Iv b2JqL3Vzci9zcmMvc2Jpbi9jb21jb250cm9sIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vY29t Y29udHJvbA0KPT09PiBzYmluL2NvbnNjb250cm9sDQovdXNyL29iai91c3Ivc3JjL3NiaW4vY29u c2NvbnRyb2wgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9jb25zY29udHJvbA0KPT09PiBzYmlu L2RldmQNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9kZXZkIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Ni aW4vZGV2ZA0KPT09PiBzYmluL2RldmZzDQovdXNyL29iai91c3Ivc3JjL3NiaW4vZGV2ZnMgY3Jl YXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9kZXZmcw0KPT09PiBzYmluL2RoY2xpZW50DQo9PT0+IHNi aW4vZGhjbGllbnQvY29tbW9uDQovdXNyL29iai91c3Ivc3JjL3NiaW4vZGhjbGllbnQvY29tbW9u IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vZGhjbGllbnQvY29tbW9uDQo9PT0+IHNiaW4vZGhj bGllbnQvZHN0DQovdXNyL29iai91c3Ivc3JjL3NiaW4vZGhjbGllbnQvZHN0IGNyZWF0ZWQgZm9y IC91c3Ivc3JjL3NiaW4vZGhjbGllbnQvZHN0DQo9PT0+IHNiaW4vZGhjbGllbnQvbWluaXJlcw0K L3Vzci9vYmovdXNyL3NyYy9zYmluL2RoY2xpZW50L21pbmlyZXMgY3JlYXRlZCBmb3IgL3Vzci9z cmMvc2Jpbi9kaGNsaWVudC9taW5pcmVzDQo9PT0+IHNiaW4vZGhjbGllbnQvb21hcGlwDQovdXNy L29iai91c3Ivc3JjL3NiaW4vZGhjbGllbnQvb21hcGlwIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Ni aW4vZGhjbGllbnQvb21hcGlwDQo9PT0+IHNiaW4vZGhjbGllbnQvZGhjcGN0bA0KL3Vzci9vYmov dXNyL3NyYy9zYmluL2RoY2xpZW50L2RoY3BjdGwgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9k aGNsaWVudC9kaGNwY3RsDQo9PT0+IHNiaW4vZGhjbGllbnQvY2xpZW50DQovdXNyL29iai91c3Iv c3JjL3NiaW4vZGhjbGllbnQvY2xpZW50IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vZGhjbGll bnQvY2xpZW50DQo9PT0+IHNiaW4vZGhjbGllbnQvb21zaGVsbA0KL3Vzci9vYmovdXNyL3NyYy9z YmluL2RoY2xpZW50L29tc2hlbGwgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9kaGNsaWVudC9v bXNoZWxsDQo9PT0+IHNiaW4vZG1lc2cNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9kbWVzZyBjcmVh dGVkIGZvciAvdXNyL3NyYy9zYmluL2RtZXNnDQo9PT0+IHNiaW4vZHVtcA0KL3Vzci9vYmovdXNy L3NyYy9zYmluL2R1bXAgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9kdW1wDQo9PT0+IHNiaW4v ZHVtcGZzDQovdXNyL29iai91c3Ivc3JjL3NiaW4vZHVtcGZzIGNyZWF0ZWQgZm9yIC91c3Ivc3Jj L3NiaW4vZHVtcGZzDQo9PT0+IHNiaW4vZHVtcG9uDQovdXNyL29iai91c3Ivc3JjL3NiaW4vZHVt cG9uIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vZHVtcG9uDQo9PT0+IHNiaW4vZmRpc2sNCi91 c3Ivb2JqL3Vzci9zcmMvc2Jpbi9mZGlzayBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL2ZkaXNr DQo9PT0+IHNiaW4vZmZzaW5mbw0KL3Vzci9vYmovdXNyL3NyYy9zYmluL2Zmc2luZm8gY3JlYXRl ZCBmb3IgL3Vzci9zcmMvc2Jpbi9mZnNpbmZvDQo9PT0+IHNiaW4vZnNjaw0KL3Vzci9vYmovdXNy L3NyYy9zYmluL2ZzY2sgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9mc2NrDQo9PT0+IHNiaW4v ZnNja19mZnMNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9mc2NrX2ZmcyBjcmVhdGVkIGZvciAvdXNy L3NyYy9zYmluL2ZzY2tfZmZzDQo9PT0+IHNiaW4vZnNja19tc2Rvc2ZzDQovdXNyL29iai91c3Iv c3JjL3NiaW4vZnNja19tc2Rvc2ZzIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vZnNja19tc2Rv c2ZzDQo9PT0+IHNiaW4vZnNkYg0KL3Vzci9vYmovdXNyL3NyYy9zYmluL2ZzZGIgY3JlYXRlZCBm b3IgL3Vzci9zcmMvc2Jpbi9mc2RiDQo9PT0+IHNiaW4vZnNpcmFuZA0KL3Vzci9vYmovdXNyL3Ny Yy9zYmluL2ZzaXJhbmQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9mc2lyYW5kDQo9PT0+IHNi aW4vZ2JkZQ0KL3Vzci9vYmovdXNyL3NyYy9zYmluL2diZGUgY3JlYXRlZCBmb3IgL3Vzci9zcmMv c2Jpbi9nYmRlDQo9PT0+IHNiaW4vZ2VvbQ0KPT09PiBzYmluL2dlb20vY29yZQ0KL3Vzci9vYmov dXNyL3NyYy9zYmluL2dlb20vY29yZSBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL2dlb20vY29y ZQ0KPT09PiBzYmluL2dlb20vY2xhc3MNCj09PT4gc2Jpbi9nZW9tL2NsYXNzL2NvbmNhdA0KL3Vz ci9vYmovdXNyL3NyYy9zYmluL2dlb20vY2xhc3MvY29uY2F0IGNyZWF0ZWQgZm9yIC91c3Ivc3Jj L3NiaW4vZ2VvbS9jbGFzcy9jb25jYXQNCj09PT4gc2Jpbi9nZW9tL2NsYXNzL2xhYmVsDQovdXNy L29iai91c3Ivc3JjL3NiaW4vZ2VvbS9jbGFzcy9sYWJlbCBjcmVhdGVkIGZvciAvdXNyL3NyYy9z YmluL2dlb20vY2xhc3MvbGFiZWwNCj09PT4gc2Jpbi9nZW9tL2NsYXNzL21pcnJvcg0KL3Vzci9v YmovdXNyL3NyYy9zYmluL2dlb20vY2xhc3MvbWlycm9yIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Ni aW4vZ2VvbS9jbGFzcy9taXJyb3INCj09PT4gc2Jpbi9nZW9tL2NsYXNzL25vcA0KL3Vzci9vYmov dXNyL3NyYy9zYmluL2dlb20vY2xhc3Mvbm9wIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vZ2Vv bS9jbGFzcy9ub3ANCj09PT4gc2Jpbi9nZW9tL2NsYXNzL3N0cmlwZQ0KL3Vzci9vYmovdXNyL3Ny Yy9zYmluL2dlb20vY2xhc3Mvc3RyaXBlIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vZ2VvbS9j bGFzcy9zdHJpcGUNCj09PT4gc2Jpbi9nZ2F0ZQ0KPT09PiBzYmluL2dnYXRlL2dnYXRlbA0KL3Vz ci9vYmovdXNyL3NyYy9zYmluL2dnYXRlL2dnYXRlbCBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmlu L2dnYXRlL2dnYXRlbA0KPT09PiBzYmluL2dnYXRlL2dnYXRlYw0KL3Vzci9vYmovdXNyL3NyYy9z YmluL2dnYXRlL2dnYXRlYyBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL2dnYXRlL2dnYXRlYw0K PT09PiBzYmluL2dnYXRlL2dnYXRlZA0KL3Vzci9vYmovdXNyL3NyYy9zYmluL2dnYXRlL2dnYXRl ZCBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL2dnYXRlL2dnYXRlZA0KPT09PiBzYmluL2dwdA0K L3Vzci9vYmovdXNyL3NyYy9zYmluL2dwdCBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL2dwdA0K PT09PiBzYmluL2dyb3dmcw0KL3Vzci9vYmovdXNyL3NyYy9zYmluL2dyb3dmcyBjcmVhdGVkIGZv ciAvdXNyL3NyYy9zYmluL2dyb3dmcw0KPT09PiBzYmluL2d2aW51bQ0KL3Vzci9vYmovdXNyL3Ny Yy9zYmluL2d2aW51bSBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL2d2aW51bQ0KPT09PiBzYmlu L2lmY29uZmlnDQovdXNyL29iai91c3Ivc3JjL3NiaW4vaWZjb25maWcgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvc2Jpbi9pZmNvbmZpZw0KPT09PiBzYmluL2luaXQNCi91c3Ivb2JqL3Vzci9zcmMvc2Jp bi9pbml0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vaW5pdA0KPT09PiBzYmluL2lwNmZ3DQov dXNyL29iai91c3Ivc3JjL3NiaW4vaXA2ZncgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9pcDZm dw0KPT09PiBzYmluL2lwZg0KL3Vzci9vYmovdXNyL3NyYy9zYmluL2lwZiBjcmVhdGVkIGZvciAv dXNyL3NyYy9zYmluL2lwZg0KPT09PiBzYmluL2lwZnMNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9p cGZzIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vaXBmcw0KPT09PiBzYmluL2lwZnN0YXQNCi91 c3Ivb2JqL3Vzci9zcmMvc2Jpbi9pcGZzdGF0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vaXBm c3RhdA0KPT09PiBzYmluL2lwZncNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9pcGZ3IGNyZWF0ZWQg Zm9yIC91c3Ivc3JjL3NiaW4vaXBmdw0KPT09PiBzYmluL2lwbW9uDQovdXNyL29iai91c3Ivc3Jj L3NiaW4vaXBtb24gY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9pcG1vbg0KPT09PiBzYmluL2lw bmF0DQovdXNyL29iai91c3Ivc3JjL3NiaW4vaXBuYXQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jp bi9pcG5hdA0KPT09PiBzYmluL2tsZGNvbmZpZw0KL3Vzci9vYmovdXNyL3NyYy9zYmluL2tsZGNv bmZpZyBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL2tsZGNvbmZpZw0KPT09PiBzYmluL2tsZGxv YWQNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9rbGRsb2FkIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Ni aW4va2xkbG9hZA0KPT09PiBzYmluL2tsZHN0YXQNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9rbGRz dGF0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4va2xkc3RhdA0KPT09PiBzYmluL2tsZHVubG9h ZA0KL3Vzci9vYmovdXNyL3NyYy9zYmluL2tsZHVubG9hZCBjcmVhdGVkIGZvciAvdXNyL3NyYy9z YmluL2tsZHVubG9hZA0KPT09PiBzYmluL2xkY29uZmlnDQovdXNyL29iai91c3Ivc3JjL3NiaW4v bGRjb25maWcgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9sZGNvbmZpZw0KPT09PiBzYmluL21k NQ0KL3Vzci9vYmovdXNyL3NyYy9zYmluL21kNSBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL21k NQ0KPT09PiBzYmluL21kY29uZmlnDQovdXNyL29iai91c3Ivc3JjL3NiaW4vbWRjb25maWcgY3Jl YXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9tZGNvbmZpZw0KPT09PiBzYmluL21kbWZzDQovdXNyL29i ai91c3Ivc3JjL3NiaW4vbWRtZnMgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9tZG1mcw0KPT09 PiBzYmluL21rbm9kDQovdXNyL29iai91c3Ivc3JjL3NiaW4vbWtub2QgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvc2Jpbi9ta25vZA0KPT09PiBzYmluL21rc25hcF9mZnMNCi91c3Ivb2JqL3Vzci9zcmMv c2Jpbi9ta3NuYXBfZmZzIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vbWtzbmFwX2Zmcw0KPT09 PiBzYmluL21vdW50DQovdXNyL29iai91c3Ivc3JjL3NiaW4vbW91bnQgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvc2Jpbi9tb3VudA0KPT09PiBzYmluL21vdW50X2NkOTY2MA0KL3Vzci9vYmovdXNyL3Ny Yy9zYmluL21vdW50X2NkOTY2MCBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL21vdW50X2NkOTY2 MA0KPT09PiBzYmluL21vdW50X2V4dDJmcw0KL3Vzci9vYmovdXNyL3NyYy9zYmluL21vdW50X2V4 dDJmcyBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL21vdW50X2V4dDJmcw0KPT09PiBzYmluL21v dW50X21zZG9zZnMNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9tb3VudF9tc2Rvc2ZzIGNyZWF0ZWQg Zm9yIC91c3Ivc3JjL3NiaW4vbW91bnRfbXNkb3Nmcw0KPT09PiBzYmluL21vdW50X25mcw0KL3Vz ci9vYmovdXNyL3NyYy9zYmluL21vdW50X25mcyBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL21v dW50X25mcw0KPT09PiBzYmluL21vdW50X25mczQNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9tb3Vu dF9uZnM0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vbW91bnRfbmZzNA0KPT09PiBzYmluL21v dW50X250ZnMNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9tb3VudF9udGZzIGNyZWF0ZWQgZm9yIC91 c3Ivc3JjL3NiaW4vbW91bnRfbnRmcw0KPT09PiBzYmluL21vdW50X251bGxmcw0KL3Vzci9vYmov dXNyL3NyYy9zYmluL21vdW50X251bGxmcyBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL21vdW50 X251bGxmcw0KPT09PiBzYmluL21vdW50X3N0ZA0KL3Vzci9vYmovdXNyL3NyYy9zYmluL21vdW50 X3N0ZCBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL21vdW50X3N0ZA0KPT09PiBzYmluL21vdW50 X3VkZg0KL3Vzci9vYmovdXNyL3NyYy9zYmluL21vdW50X3VkZiBjcmVhdGVkIGZvciAvdXNyL3Ny Yy9zYmluL21vdW50X3VkZg0KPT09PiBzYmluL21vdW50X3VtYXBmcw0KL3Vzci9vYmovdXNyL3Ny Yy9zYmluL21vdW50X3VtYXBmcyBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL21vdW50X3VtYXBm cw0KPT09PiBzYmluL21vdW50X3VuaW9uZnMNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9tb3VudF91 bmlvbmZzIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vbW91bnRfdW5pb25mcw0KPT09PiBzYmlu L25hdGQNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9uYXRkIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Ni aW4vbmF0ZA0KPT09PiBzYmluL25ld2ZzDQovdXNyL29iai91c3Ivc3JjL3NiaW4vbmV3ZnMgY3Jl YXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9uZXdmcw0KPT09PiBzYmluL25ld2ZzX21zZG9zDQovdXNy L29iai91c3Ivc3JjL3NiaW4vbmV3ZnNfbXNkb3MgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9u ZXdmc19tc2Rvcw0KPT09PiBzYmluL25mc2lvZA0KL3Vzci9vYmovdXNyL3NyYy9zYmluL25mc2lv ZCBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL25mc2lvZA0KPT09PiBzYmluL25vcy10dW4NCi91 c3Ivb2JqL3Vzci9zcmMvc2Jpbi9ub3MtdHVuIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vbm9z LXR1bg0KPT09PiBzYmluL3BmY3RsDQovdXNyL29iai91c3Ivc3JjL3NiaW4vcGZjdGwgY3JlYXRl ZCBmb3IgL3Vzci9zcmMvc2Jpbi9wZmN0bA0KPT09PiBzYmluL3BmbG9nZA0KL3Vzci9vYmovdXNy L3NyYy9zYmluL3BmbG9nZCBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL3BmbG9nZA0KPT09PiBz YmluL3BpbmcNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9waW5nIGNyZWF0ZWQgZm9yIC91c3Ivc3Jj L3NiaW4vcGluZw0KPT09PiBzYmluL3Bpbmc2DQovdXNyL29iai91c3Ivc3JjL3NiaW4vcGluZzYg Y3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9waW5nNg0KPT09PiBzYmluL3F1b3RhY2hlY2sNCi91 c3Ivb2JqL3Vzci9zcmMvc2Jpbi9xdW90YWNoZWNrIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4v cXVvdGFjaGVjaw0KPT09PiBzYmluL3Jjb3JkZXINCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9yY29y ZGVyIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vcmNvcmRlcg0KPT09PiBzYmluL3JlYm9vdA0K L3Vzci9vYmovdXNyL3NyYy9zYmluL3JlYm9vdCBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL3Jl Ym9vdA0KPT09PiBzYmluL3Jlc3RvcmUNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9yZXN0b3JlIGNy ZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vcmVzdG9yZQ0KPT09PiBzYmluL3JvdXRlDQovdXNyL29i ai91c3Ivc3JjL3NiaW4vcm91dGUgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9yb3V0ZQ0KPT09 PiBzYmluL3JvdXRlZA0KL3Vzci9vYmovdXNyL3NyYy9zYmluL3JvdXRlZCBjcmVhdGVkIGZvciAv dXNyL3NyYy9zYmluL3JvdXRlZA0KPT09PiBzYmluL3JvdXRlZC9ydHF1ZXJ5DQovdXNyL29iai91 c3Ivc3JjL3NiaW4vcm91dGVkL3J0cXVlcnkgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9yb3V0 ZWQvcnRxdWVyeQ0KPT09PiBzYmluL3J0c29sDQovdXNyL29iai91c3Ivc3JjL3NiaW4vcnRzb2wg Y3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9ydHNvbA0KPT09PiBzYmluL3NhdmVjb3JlDQovdXNy L29iai91c3Ivc3JjL3NiaW4vc2F2ZWNvcmUgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9zYXZl Y29yZQ0KPT09PiBzYmluL3Njb25maWcNCi91c3Ivb2JqL3Vzci9zcmMvc2Jpbi9zY29uZmlnIGNy ZWF0ZWQgZm9yIC91c3Ivc3JjL3NiaW4vc2NvbmZpZw0KPT09PiBzYmluL3NodXRkb3duDQovdXNy L29iai91c3Ivc3JjL3NiaW4vc2h1dGRvd24gY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9zaHV0 ZG93bg0KPT09PiBzYmluL3NsYXR0YWNoDQovdXNyL29iai91c3Ivc3JjL3NiaW4vc2xhdHRhY2gg Y3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Jpbi9zbGF0dGFjaA0KPT09PiBzYmluL3NwcHBjb250cm9s DQovdXNyL29iai91c3Ivc3JjL3NiaW4vc3BwcGNvbnRyb2wgY3JlYXRlZCBmb3IgL3Vzci9zcmMv c2Jpbi9zcHBwY29udHJvbA0KPT09PiBzYmluL3N0YXJ0c2xpcA0KL3Vzci9vYmovdXNyL3NyYy9z YmluL3N0YXJ0c2xpcCBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL3N0YXJ0c2xpcA0KPT09PiBz YmluL3N1bmxhYmVsDQovdXNyL29iai91c3Ivc3JjL3NiaW4vc3VubGFiZWwgY3JlYXRlZCBmb3Ig L3Vzci9zcmMvc2Jpbi9zdW5sYWJlbA0KPT09PiBzYmluL3N3YXBvbg0KL3Vzci9vYmovdXNyL3Ny Yy9zYmluL3N3YXBvbiBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL3N3YXBvbg0KPT09PiBzYmlu L3N5c2N0bA0KL3Vzci9vYmovdXNyL3NyYy9zYmluL3N5c2N0bCBjcmVhdGVkIGZvciAvdXNyL3Ny Yy9zYmluL3N5c2N0bA0KPT09PiBzYmluL3R1bmVmcw0KL3Vzci9vYmovdXNyL3NyYy9zYmluL3R1 bmVmcyBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL3R1bmVmcw0KPT09PiBzYmluL3Vtb3VudA0K L3Vzci9vYmovdXNyL3NyYy9zYmluL3Vtb3VudCBjcmVhdGVkIGZvciAvdXNyL3NyYy9zYmluL3Vt b3VudA0KPT09PiBzYmluL3ZpbnVtDQovdXNyL29iai91c3Ivc3JjL3NiaW4vdmludW0gY3JlYXRl ZCBmb3IgL3Vzci9zcmMvc2Jpbi92aW51bQ0KPT09PiBzZWN1cmUNCj09PT4gc2VjdXJlL2xpYg0K PT09PiBzZWN1cmUvbGliL2xpYmNyeXB0bw0KL3Vzci9vYmovdXNyL3NyYy9zZWN1cmUvbGliL2xp YmNyeXB0byBjcmVhdGVkIGZvciAvdXNyL3NyYy9zZWN1cmUvbGliL2xpYmNyeXB0bw0KPT09PiBz ZWN1cmUvbGliL2xpYnNzbA0KL3Vzci9vYmovdXNyL3NyYy9zZWN1cmUvbGliL2xpYnNzbCBjcmVh dGVkIGZvciAvdXNyL3NyYy9zZWN1cmUvbGliL2xpYnNzbA0KPT09PiBzZWN1cmUvbGliL2xpYnNz aA0KL3Vzci9vYmovdXNyL3NyYy9zZWN1cmUvbGliL2xpYnNzaCBjcmVhdGVkIGZvciAvdXNyL3Ny Yy9zZWN1cmUvbGliL2xpYnNzaA0KPT09PiBzZWN1cmUvbGliZXhlYw0KPT09PiBzZWN1cmUvbGli ZXhlYy9zZnRwLXNlcnZlcg0KL3Vzci9vYmovdXNyL3NyYy9zZWN1cmUvbGliZXhlYy9zZnRwLXNl cnZlciBjcmVhdGVkIGZvciAvdXNyL3NyYy9zZWN1cmUvbGliZXhlYy9zZnRwLXNlcnZlcg0KPT09 PiBzZWN1cmUvbGliZXhlYy9zc2gta2V5c2lnbg0KL3Vzci9vYmovdXNyL3NyYy9zZWN1cmUvbGli ZXhlYy9zc2gta2V5c2lnbiBjcmVhdGVkIGZvciAvdXNyL3NyYy9zZWN1cmUvbGliZXhlYy9zc2gt a2V5c2lnbg0KPT09PiBzZWN1cmUvdXNyLmJpbg0KPT09PiBzZWN1cmUvdXNyLmJpbi9iZGVzDQov dXNyL29iai91c3Ivc3JjL3NlY3VyZS91c3IuYmluL2JkZXMgY3JlYXRlZCBmb3IgL3Vzci9zcmMv c2VjdXJlL3Vzci5iaW4vYmRlcw0KPT09PiBzZWN1cmUvdXNyLmJpbi9vcGVuc3NsDQovdXNyL29i ai91c3Ivc3JjL3NlY3VyZS91c3IuYmluL29wZW5zc2wgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2Vj dXJlL3Vzci5iaW4vb3BlbnNzbA0KPT09PiBzZWN1cmUvdXNyLmJpbi9zY3ANCi91c3Ivb2JqL3Vz ci9zcmMvc2VjdXJlL3Vzci5iaW4vc2NwIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NlY3VyZS91c3Iu YmluL3NjcA0KPT09PiBzZWN1cmUvdXNyLmJpbi9zZnRwDQovdXNyL29iai91c3Ivc3JjL3NlY3Vy ZS91c3IuYmluL3NmdHAgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2VjdXJlL3Vzci5iaW4vc2Z0cA0K PT09PiBzZWN1cmUvdXNyLmJpbi9zc2gNCi91c3Ivb2JqL3Vzci9zcmMvc2VjdXJlL3Vzci5iaW4v c3NoIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NlY3VyZS91c3IuYmluL3NzaA0KPT09PiBzZWN1cmUv dXNyLmJpbi9zc2gtYWRkDQovdXNyL29iai91c3Ivc3JjL3NlY3VyZS91c3IuYmluL3NzaC1hZGQg Y3JlYXRlZCBmb3IgL3Vzci9zcmMvc2VjdXJlL3Vzci5iaW4vc3NoLWFkZA0KPT09PiBzZWN1cmUv dXNyLmJpbi9zc2gtYWdlbnQNCi91c3Ivb2JqL3Vzci9zcmMvc2VjdXJlL3Vzci5iaW4vc3NoLWFn ZW50IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3NlY3VyZS91c3IuYmluL3NzaC1hZ2VudA0KPT09PiBz ZWN1cmUvdXNyLmJpbi9zc2gta2V5Z2VuDQovdXNyL29iai91c3Ivc3JjL3NlY3VyZS91c3IuYmlu L3NzaC1rZXlnZW4gY3JlYXRlZCBmb3IgL3Vzci9zcmMvc2VjdXJlL3Vzci5iaW4vc3NoLWtleWdl bg0KPT09PiBzZWN1cmUvdXNyLmJpbi9zc2gta2V5c2Nhbg0KL3Vzci9vYmovdXNyL3NyYy9zZWN1 cmUvdXNyLmJpbi9zc2gta2V5c2NhbiBjcmVhdGVkIGZvciAvdXNyL3NyYy9zZWN1cmUvdXNyLmJp bi9zc2gta2V5c2Nhbg0KPT09PiBzZWN1cmUvdXNyLnNiaW4NCj09PT4gc2VjdXJlL3Vzci5zYmlu L3NzaGQNCi91c3Ivb2JqL3Vzci9zcmMvc2VjdXJlL3Vzci5zYmluL3NzaGQgY3JlYXRlZCBmb3Ig L3Vzci9zcmMvc2VjdXJlL3Vzci5zYmluL3NzaGQNCj09PT4gc3lzDQo9PT0+IHN5cy9ib290DQo9 PT0+IHN5cy9ib290L2ZpY2wNCi91c3Ivb2JqL3Vzci9zcmMvc3lzL2Jvb3QvZmljbCBjcmVhdGVk IGZvciAvdXNyL3NyYy9zeXMvYm9vdC9maWNsDQo9PT0+IHN5cy9ib290L2kzODYNCj09PT4gc3lz L2Jvb3QvaTM4Ni9tYnINCi91c3Ivb2JqL3Vzci9zcmMvc3lzL2Jvb3QvaTM4Ni9tYnIgY3JlYXRl ZCBmb3IgL3Vzci9zcmMvc3lzL2Jvb3QvaTM4Ni9tYnINCj09PT4gc3lzL2Jvb3QvaTM4Ni9ib290 MA0KL3Vzci9vYmovdXNyL3NyYy9zeXMvYm9vdC9pMzg2L2Jvb3QwIGNyZWF0ZWQgZm9yIC91c3Iv c3JjL3N5cy9ib290L2kzODYvYm9vdDANCj09PT4gc3lzL2Jvb3QvaTM4Ni9ib290MHNpbw0KL3Vz ci9vYmovdXNyL3NyYy9zeXMvYm9vdC9pMzg2L2Jvb3Qwc2lvIGNyZWF0ZWQgZm9yIC91c3Ivc3Jj L3N5cy9ib290L2kzODYvYm9vdDBzaW8NCj09PT4gc3lzL2Jvb3QvaTM4Ni9idHgNCj09PT4gc3lz L2Jvb3QvaTM4Ni9idHgvYnR4DQovdXNyL29iai91c3Ivc3JjL3N5cy9ib290L2kzODYvYnR4L2J0 eCBjcmVhdGVkIGZvciAvdXNyL3NyYy9zeXMvYm9vdC9pMzg2L2J0eC9idHgNCj09PT4gc3lzL2Jv b3QvaTM4Ni9idHgvYnR4bGRyDQovdXNyL29iai91c3Ivc3JjL3N5cy9ib290L2kzODYvYnR4L2J0 eGxkciBjcmVhdGVkIGZvciAvdXNyL3NyYy9zeXMvYm9vdC9pMzg2L2J0eC9idHhsZHINCj09PT4g c3lzL2Jvb3QvaTM4Ni9idHgvbGliDQovdXNyL29iai91c3Ivc3JjL3N5cy9ib290L2kzODYvYnR4 L2xpYiBjcmVhdGVkIGZvciAvdXNyL3NyYy9zeXMvYm9vdC9pMzg2L2J0eC9saWINCj09PT4gc3lz L2Jvb3QvaTM4Ni9ib290Mg0KL3Vzci9vYmovdXNyL3NyYy9zeXMvYm9vdC9pMzg2L2Jvb3QyIGNy ZWF0ZWQgZm9yIC91c3Ivc3JjL3N5cy9ib290L2kzODYvYm9vdDINCj09PT4gc3lzL2Jvb3QvaTM4 Ni9jZGJvb3QNCi91c3Ivb2JqL3Vzci9zcmMvc3lzL2Jvb3QvaTM4Ni9jZGJvb3QgY3JlYXRlZCBm b3IgL3Vzci9zcmMvc3lzL2Jvb3QvaTM4Ni9jZGJvb3QNCj09PT4gc3lzL2Jvb3QvaTM4Ni9rZ3ps ZHINCi91c3Ivb2JqL3Vzci9zcmMvc3lzL2Jvb3QvaTM4Ni9rZ3psZHIgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvc3lzL2Jvb3QvaTM4Ni9rZ3psZHINCj09PT4gc3lzL2Jvb3QvaTM4Ni9saWJpMzg2DQov dXNyL29iai91c3Ivc3JjL3N5cy9ib290L2kzODYvbGliaTM4NiBjcmVhdGVkIGZvciAvdXNyL3Ny Yy9zeXMvYm9vdC9pMzg2L2xpYmkzODYNCj09PT4gc3lzL2Jvb3QvaTM4Ni9sb2FkZXINCi91c3Iv b2JqL3Vzci9zcmMvc3lzL2Jvb3QvaTM4Ni9sb2FkZXIgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc3lz L2Jvb3QvaTM4Ni9sb2FkZXINCj09PT4gc3lzL2Jvb3QvaTM4Ni9weGVsZHINCi91c3Ivb2JqL3Vz ci9zcmMvc3lzL2Jvb3QvaTM4Ni9weGVsZHIgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc3lzL2Jvb3Qv aTM4Ni9weGVsZHINCj09PT4gdXNyLmJpbg0KPT09PiB1c3IuYmluL2FsaWFzDQo9PT0+IHVzci5i aW4vYXBwbHkNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9hcHBseSBjcmVhdGVkIGZvciAvdXNy L3NyYy91c3IuYmluL2FwcGx5DQo9PT0+IHVzci5iaW4vYXNhDQovdXNyL29iai91c3Ivc3JjL3Vz ci5iaW4vYXNhIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vYXNhDQo9PT0+IHVzci5iaW4v YXQNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9hdCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iu YmluL2F0DQo9PT0+IHVzci5iaW4vYXRtDQo9PT0+IHVzci5iaW4vYXRtL3NzY29wDQovdXNyL29i ai91c3Ivc3JjL3Vzci5iaW4vYXRtL3NzY29wIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4v YXRtL3NzY29wDQo9PT0+IHVzci5iaW4vYXdrDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vYXdr IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vYXdrDQo9PT0+IHVzci5iaW4vYmFubmVyDQov dXNyL29iai91c3Ivc3JjL3Vzci5iaW4vYmFubmVyIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5i aW4vYmFubmVyDQo9PT0+IHVzci5iaW4vYmFzZW5hbWUNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJp bi9iYXNlbmFtZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2Jhc2VuYW1lDQo9PT0+IHVz ci5iaW4vYmlmZg0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2JpZmYgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvdXNyLmJpbi9iaWZmDQo9PT0+IHVzci5iaW4vYmx1ZXRvb3RoDQo9PT0+IHVzci5iaW4v Ymx1ZXRvb3RoL2J0aG9zdA0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2JsdWV0b290aC9idGhv c3QgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9ibHVldG9vdGgvYnRob3N0DQo9PT0+IHVz ci5iaW4vYmx1ZXRvb3RoL2J0c29ja3N0YXQNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9ibHVl dG9vdGgvYnRzb2Nrc3RhdCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2JsdWV0b290aC9i dHNvY2tzdGF0DQo9PT0+IHVzci5iaW4vYmx1ZXRvb3RoL3JmY29tbV9zcHBkDQovdXNyL29iai91 c3Ivc3JjL3Vzci5iaW4vYmx1ZXRvb3RoL3JmY29tbV9zcHBkIGNyZWF0ZWQgZm9yIC91c3Ivc3Jj L3Vzci5iaW4vYmx1ZXRvb3RoL3JmY29tbV9zcHBkDQo9PT0+IHVzci5iaW4vYnJhbmRlbGYNCi91 c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9icmFuZGVsZiBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iu YmluL2JyYW5kZWxmDQo9PT0+IHVzci5iaW4vYnppcDINCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJp bi9iemlwMiBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2J6aXAyDQo9PT0+IHVzci5iaW4v YnppcDIvZG9jDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vYnppcDIvZG9jIGNyZWF0ZWQgZm9y IC91c3Ivc3JjL3Vzci5iaW4vYnppcDIvZG9jDQo9PT0+IHVzci5iaW4vYnppcDJyZWNvdmVyDQov dXNyL29iai91c3Ivc3JjL3Vzci5iaW4vYnppcDJyZWNvdmVyIGNyZWF0ZWQgZm9yIC91c3Ivc3Jj L3Vzci5iaW4vYnppcDJyZWNvdmVyDQo9PT0+IHVzci5iaW4vYzg5DQovdXNyL29iai91c3Ivc3Jj L3Vzci5iaW4vYzg5IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vYzg5DQo9PT0+IHVzci5i aW4vYzk5DQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vYzk5IGNyZWF0ZWQgZm9yIC91c3Ivc3Jj L3Vzci5iaW4vYzk5DQo9PT0+IHVzci5iaW4vY2FsZW5kYXINCi91c3Ivb2JqL3Vzci9zcmMvdXNy LmJpbi9jYWxlbmRhciBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2NhbGVuZGFyDQo9PT0+ IHVzci5iaW4vY2FwX21rZGINCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9jYXBfbWtkYiBjcmVh dGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2NhcF9ta2RiDQo9PT0+IHVzci5iaW4vY2F0bWFuDQov dXNyL29iai91c3Ivc3JjL3Vzci5iaW4vY2F0bWFuIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5i aW4vY2F0bWFuDQo9PT0+IHVzci5iaW4vY2hhdA0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2No YXQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9jaGF0DQo9PT0+IHVzci5iaW4vY2hlY2tu cg0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2NoZWNrbnIgY3JlYXRlZCBmb3IgL3Vzci9zcmMv dXNyLmJpbi9jaGVja25yDQo9PT0+IHVzci5iaW4vY2hrZXkNCi91c3Ivb2JqL3Vzci9zcmMvdXNy LmJpbi9jaGtleSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2Noa2V5DQo9PT0+IHVzci5i aW4vY2hwYXNzDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vY2hwYXNzIGNyZWF0ZWQgZm9yIC91 c3Ivc3JjL3Vzci5iaW4vY2hwYXNzDQo9PT0+IHVzci5iaW4vY2tzdW0NCi91c3Ivb2JqL3Vzci9z cmMvdXNyLmJpbi9ja3N1bSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2Nrc3VtDQo9PT0+ IHVzci5iaW4vY21wDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vY21wIGNyZWF0ZWQgZm9yIC91 c3Ivc3JjL3Vzci5iaW4vY21wDQo9PT0+IHVzci5iaW4vY29sDQovdXNyL29iai91c3Ivc3JjL3Vz ci5iaW4vY29sIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vY29sDQo9PT0+IHVzci5iaW4v Y29sY3J0DQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vY29sY3J0IGNyZWF0ZWQgZm9yIC91c3Iv c3JjL3Vzci5iaW4vY29sY3J0DQo9PT0+IHVzci5iaW4vY29sbGRlZg0KL3Vzci9vYmovdXNyL3Ny Yy91c3IuYmluL2NvbGxkZWYgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9jb2xsZGVmDQo9 PT0+IHVzci5iaW4vY29scm0NCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9jb2xybSBjcmVhdGVk IGZvciAvdXNyL3NyYy91c3IuYmluL2NvbHJtDQo9PT0+IHVzci5iaW4vY29sdW1uDQovdXNyL29i ai91c3Ivc3JjL3Vzci5iaW4vY29sdW1uIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vY29s dW1uDQo9PT0+IHVzci5iaW4vY29tbQ0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2NvbW0gY3Jl YXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9jb21tDQo9PT0+IHVzci5iaW4vY29tcGlsZV9ldA0K L3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2NvbXBpbGVfZXQgY3JlYXRlZCBmb3IgL3Vzci9zcmMv dXNyLmJpbi9jb21waWxlX2V0DQo9PT0+IHVzci5iaW4vY29tcHJlc3MNCi91c3Ivb2JqL3Vzci9z cmMvdXNyLmJpbi9jb21wcmVzcyBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2NvbXByZXNz DQo9PT0+IHVzci5iaW4vY3NwbGl0DQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vY3NwbGl0IGNy ZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vY3NwbGl0DQo9PT0+IHVzci5iaW4vY3RhZ3MNCi91 c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9jdGFncyBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmlu L2N0YWdzDQo9PT0+IHVzci5iaW4vY3V0DQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vY3V0IGNy ZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vY3V0DQo9PT0+IHVzci5iaW4vZGlnDQovdXNyL29i ai91c3Ivc3JjL3Vzci5iaW4vZGlnIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vZGlnDQo9 PT0+IHVzci5iaW4vZGlybmFtZQ0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2Rpcm5hbWUgY3Jl YXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9kaXJuYW1lDQo9PT0+IHVzci5iaW4vZG5za2V5Z2Vu DQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vZG5za2V5Z2VuIGNyZWF0ZWQgZm9yIC91c3Ivc3Jj L3Vzci5iaW4vZG5za2V5Z2VuDQo9PT0+IHVzci5iaW4vZG5zcXVlcnkNCi91c3Ivb2JqL3Vzci9z cmMvdXNyLmJpbi9kbnNxdWVyeSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2Ruc3F1ZXJ5 DQo9PT0+IHVzci5iaW4vZHUNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9kdSBjcmVhdGVkIGZv ciAvdXNyL3NyYy91c3IuYmluL2R1DQo9PT0+IHVzci5iaW4vZWUNCi91c3Ivb2JqL3Vzci9zcmMv dXNyLmJpbi9lZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2VlDQo9PT0+IHVzci5iaW4v ZWxmMmFvdXQNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9lbGYyYW91dCBjcmVhdGVkIGZvciAv dXNyL3NyYy91c3IuYmluL2VsZjJhb3V0DQo9PT0+IHVzci5iaW4vZWxmZHVtcA0KL3Vzci9vYmov dXNyL3NyYy91c3IuYmluL2VsZmR1bXAgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9lbGZk dW1wDQo9PT0+IHVzci5iaW4vZW5pZ21hDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vZW5pZ21h IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vZW5pZ21hDQo9PT0+IHVzci5iaW4vZW52DQov dXNyL29iai91c3Ivc3JjL3Vzci5iaW4vZW52IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4v ZW52DQo9PT0+IHVzci5iaW4vZXhwYW5kDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vZXhwYW5k IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vZXhwYW5kDQo9PT0+IHVzci5iaW4vZmFsc2UN Ci91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9mYWxzZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iu YmluL2ZhbHNlDQo9PT0+IHVzci5iaW4vZmV0Y2gNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9m ZXRjaCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2ZldGNoDQo9PT0+IHVzci5iaW4vZmls ZQ0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2ZpbGUgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNy LmJpbi9maWxlDQo9PT0+IHVzci5iaW4vZmlsZTJjDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4v ZmlsZTJjIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vZmlsZTJjDQo9PT0+IHVzci5iaW4v ZmluZA0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2ZpbmQgY3JlYXRlZCBmb3IgL3Vzci9zcmMv dXNyLmJpbi9maW5kDQo9PT0+IHVzci5iaW4vZmluZ2VyDQovdXNyL29iai91c3Ivc3JjL3Vzci5i aW4vZmluZ2VyIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vZmluZ2VyDQo9PT0+IHVzci5i aW4vZm10DQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vZm10IGNyZWF0ZWQgZm9yIC91c3Ivc3Jj L3Vzci5iaW4vZm10DQo9PT0+IHVzci5iaW4vZm9sZA0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmlu L2ZvbGQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9mb2xkDQo9PT0+IHVzci5iaW4vZnJv bQ0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2Zyb20gY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNy LmJpbi9mcm9tDQo9PT0+IHVzci5iaW4vZnN0YXQNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9m c3RhdCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2ZzdGF0DQo9PT0+IHVzci5iaW4vZnN5 bmMNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9mc3luYyBjcmVhdGVkIGZvciAvdXNyL3NyYy91 c3IuYmluL2ZzeW5jDQo9PT0+IHVzci5iaW4vZnRwDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4v ZnRwIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vZnRwDQo9PT0+IHVzci5iaW4vZ2NvcmUN Ci91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9nY29yZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iu YmluL2djb3JlDQo9PT0+IHVzci5iaW4vZ2VuY2F0DQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4v Z2VuY2F0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vZ2VuY2F0DQo9PT0+IHVzci5iaW4v Z2V0Y29uZg0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2dldGNvbmYgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvdXNyLmJpbi9nZXRjb25mDQo9PT0+IHVzci5iaW4vZ2V0b3B0DQovdXNyL29iai91c3Iv c3JjL3Vzci5iaW4vZ2V0b3B0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vZ2V0b3B0DQo9 PT0+IHVzci5iaW4vZ3Byb2YNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9ncHJvZiBjcmVhdGVk IGZvciAvdXNyL3NyYy91c3IuYmluL2dwcm9mDQo9PT0+IHVzci5iaW4vaGVhZA0KL3Vzci9vYmov dXNyL3NyYy91c3IuYmluL2hlYWQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9oZWFkDQo9 PT0+IHVzci5iaW4vaGVzaW5mbw0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2hlc2luZm8gY3Jl YXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9oZXNpbmZvDQo9PT0+IHVzci5iaW4vaGV4ZHVtcA0K L3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2hleGR1bXAgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNy LmJpbi9oZXhkdW1wDQo9PT0+IHVzci5iaW4vaG9zdA0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmlu L2hvc3QgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9ob3N0DQo9PT0+IHVzci5iaW4vaWQN Ci91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9pZCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmlu L2lkDQo9PT0+IHVzci5iaW4vaW5kZW50DQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vaW5kZW50 IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vaW5kZW50DQo9PT0+IHVzci5iaW4vaXBjcm0N Ci91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9pcGNybSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iu YmluL2lwY3JtDQo9PT0+IHVzci5iaW4vaXBjcw0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2lw Y3MgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9pcGNzDQo9PT0+IHVzci5iaW4vam9pbg0K L3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2pvaW4gY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJp bi9qb2luDQo9PT0+IHVzci5iaW4vam90DQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vam90IGNy ZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vam90DQo9PT0+IHVzci5iaW4va2R1bXANCi91c3Iv b2JqL3Vzci9zcmMvdXNyLmJpbi9rZHVtcCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2tk dW1wDQo9PT0+IHVzci5iaW4va2V5bG9naW4NCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9rZXls b2dpbiBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2tleWxvZ2luDQo9PT0+IHVzci5iaW4v a2V5bG9nb3V0DQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4va2V5bG9nb3V0IGNyZWF0ZWQgZm9y IC91c3Ivc3JjL3Vzci5iaW4va2V5bG9nb3V0DQo9PT0+IHVzci5iaW4va2lsbGFsbA0KL3Vzci9v YmovdXNyL3NyYy91c3IuYmluL2tpbGxhbGwgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9r aWxsYWxsDQo9PT0+IHVzci5iaW4va3RyYWNlDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4va3Ry YWNlIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4va3RyYWNlDQo9PT0+IHVzci5iaW4va3Ry ZHVtcA0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2t0cmR1bXAgY3JlYXRlZCBmb3IgL3Vzci9z cmMvdXNyLmJpbi9rdHJkdW1wDQo9PT0+IHVzci5iaW4vbGFtDQovdXNyL29iai91c3Ivc3JjL3Vz ci5iaW4vbGFtIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vbGFtDQo9PT0+IHVzci5iaW4v bGFzdA0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2xhc3QgY3JlYXRlZCBmb3IgL3Vzci9zcmMv dXNyLmJpbi9sYXN0DQo9PT0+IHVzci5iaW4vbGFzdGNvbW0NCi91c3Ivb2JqL3Vzci9zcmMvdXNy LmJpbi9sYXN0Y29tbSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2xhc3Rjb21tDQo9PT0+ IHVzci5iaW4vbGRkDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vbGRkIGNyZWF0ZWQgZm9yIC91 c3Ivc3JjL3Vzci5iaW4vbGRkDQo9PT0+IHVzci5iaW4vbGVhdmUNCi91c3Ivb2JqL3Vzci9zcmMv dXNyLmJpbi9sZWF2ZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2xlYXZlDQo9PT0+IHVz ci5iaW4vbGVzcw0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2xlc3MgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvdXNyLmJpbi9sZXNzDQo9PT0+IHVzci5iaW4vbGVzc2VjaG8NCi91c3Ivb2JqL3Vzci9z cmMvdXNyLmJpbi9sZXNzZWNobyBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2xlc3NlY2hv DQo9PT0+IHVzci5iaW4vbGVzc2tleQ0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2xlc3NrZXkg Y3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9sZXNza2V5DQo9PT0+IHVzci5iaW4vbGV4DQov dXNyL29iai91c3Ivc3JjL3Vzci5iaW4vbGV4IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4v bGV4DQo9PT0+IHVzci5iaW4vbGV4L2xpYg0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2xleC9s aWIgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9sZXgvbGliDQo9PT0+IHVzci5iaW4vbGlt aXRzDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vbGltaXRzIGNyZWF0ZWQgZm9yIC91c3Ivc3Jj L3Vzci5iaW4vbGltaXRzDQo9PT0+IHVzci5iaW4vbG9jYWxlDQovdXNyL29iai91c3Ivc3JjL3Vz ci5iaW4vbG9jYWxlIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vbG9jYWxlDQo9PT0+IHVz ci5iaW4vbG9jYXRlDQo9PT0+IHVzci5iaW4vbG9jYXRlL2JpZ3JhbQ0KL3Vzci9vYmovdXNyL3Ny Yy91c3IuYmluL2xvY2F0ZS9iaWdyYW0gY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9sb2Nh dGUvYmlncmFtDQo9PT0+IHVzci5iaW4vbG9jYXRlL2NvZGUNCi91c3Ivb2JqL3Vzci9zcmMvdXNy LmJpbi9sb2NhdGUvY29kZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2xvY2F0ZS9jb2Rl DQo9PT0+IHVzci5iaW4vbG9jYXRlL2xvY2F0ZQ0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2xv Y2F0ZS9sb2NhdGUgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9sb2NhdGUvbG9jYXRlDQo9 PT0+IHVzci5iaW4vbG9jaw0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2xvY2sgY3JlYXRlZCBm b3IgL3Vzci9zcmMvdXNyLmJpbi9sb2NrDQo9PT0+IHVzci5iaW4vbG9ja2YNCi91c3Ivb2JqL3Vz ci9zcmMvdXNyLmJpbi9sb2NrZiBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2xvY2tmDQo9 PT0+IHVzci5iaW4vbG9nZ2VyDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vbG9nZ2VyIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vbG9nZ2VyDQo9PT0+IHVzci5iaW4vbG9naW4NCi91c3Iv b2JqL3Vzci9zcmMvdXNyLmJpbi9sb2dpbiBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2xv Z2luDQo9PT0+IHVzci5iaW4vbG9naW5zDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vbG9naW5z IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vbG9naW5zDQo9PT0+IHVzci5iaW4vbG9nbmFt ZQ0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL2xvZ25hbWUgY3JlYXRlZCBmb3IgL3Vzci9zcmMv dXNyLmJpbi9sb2duYW1lDQo9PT0+IHVzci5iaW4vbG9vaw0KL3Vzci9vYmovdXNyL3NyYy91c3Iu YmluL2xvb2sgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9sb29rDQo9PT0+IHVzci5iaW4v bG9yZGVyDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vbG9yZGVyIGNyZWF0ZWQgZm9yIC91c3Iv c3JjL3Vzci5iaW4vbG9yZGVyDQo9PT0+IHVzci5iaW4vbHN2ZnMNCi91c3Ivb2JqL3Vzci9zcmMv dXNyLmJpbi9sc3ZmcyBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2xzdmZzDQo9PT0+IHVz ci5iaW4vbTQNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9tNCBjcmVhdGVkIGZvciAvdXNyL3Ny Yy91c3IuYmluL200DQo9PT0+IHVzci5iaW4vbWFpbA0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmlu L21haWwgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9tYWlsDQo9PT0+IHVzci5iaW4vbWFr ZQ0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL21ha2UgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNy LmJpbi9tYWtlDQo9PT0+IHVzci5iaW4vbWFrZXdoYXRpcw0KL3Vzci9vYmovdXNyL3NyYy91c3Iu YmluL21ha2V3aGF0aXMgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9tYWtld2hhdGlzDQo9 PT0+IHVzci5iaW4vbWVzZw0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL21lc2cgY3JlYXRlZCBm b3IgL3Vzci9zcmMvdXNyLmJpbi9tZXNnDQo9PT0+IHVzci5iaW4vbWluaWd6aXANCi91c3Ivb2Jq L3Vzci9zcmMvdXNyLmJpbi9taW5pZ3ppcCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL21p bmlnemlwDQo9PT0+IHVzci5iaW4vbWtkZXANCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9ta2Rl cCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL21rZGVwDQo9PT0+IHVzci5iaW4vbWtmaWZv DQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vbWtmaWZvIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vz ci5iaW4vbWtmaWZvDQo9PT0+IHVzci5iaW4vbWtsb2NhbGUNCi91c3Ivb2JqL3Vzci9zcmMvdXNy LmJpbi9ta2xvY2FsZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL21rbG9jYWxlDQo9PT0+ IHVzci5iaW4vbWtzdHINCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9ta3N0ciBjcmVhdGVkIGZv ciAvdXNyL3NyYy91c3IuYmluL21rc3RyDQo9PT0+IHVzci5iaW4vbWt0ZW1wDQovdXNyL29iai91 c3Ivc3JjL3Vzci5iaW4vbWt0ZW1wIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vbWt0ZW1w DQo9PT0+IHVzci5iaW4vbXNncw0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL21zZ3MgY3JlYXRl ZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9tc2dzDQo9PT0+IHVzci5iaW4vbXQNCi91c3Ivb2JqL3Vz ci9zcmMvdXNyLmJpbi9tdCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL210DQo9PT0+IHVz ci5iaW4vbmNhbA0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL25jYWwgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvdXNyLmJpbi9uY2FsDQo9PT0+IHVzci5iaW4vbmNwbGlzdA0KL3Vzci9vYmovdXNyL3Ny Yy91c3IuYmluL25jcGxpc3QgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9uY3BsaXN0DQo9 PT0+IHVzci5iaW4vbmNwbG9naW4NCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9uY3Bsb2dpbiBj cmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL25jcGxvZ2luDQo9PT0+IHVzci5iaW4vbmV0c3Rh dA0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL25ldHN0YXQgY3JlYXRlZCBmb3IgL3Vzci9zcmMv dXNyLmJpbi9uZXRzdGF0DQo9PT0+IHVzci5iaW4vbmV3Z3JwDQovdXNyL29iai91c3Ivc3JjL3Vz ci5iaW4vbmV3Z3JwIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vbmV3Z3JwDQo9PT0+IHVz ci5iaW4vbmV3a2V5DQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vbmV3a2V5IGNyZWF0ZWQgZm9y IC91c3Ivc3JjL3Vzci5iaW4vbmV3a2V5DQo9PT0+IHVzci5iaW4vbmZzc3RhdA0KL3Vzci9vYmov dXNyL3NyYy91c3IuYmluL25mc3N0YXQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9uZnNz dGF0DQo9PT0+IHVzci5iaW4vbmljZQ0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL25pY2UgY3Jl YXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9uaWNlDQo9PT0+IHVzci5iaW4vbmwNCi91c3Ivb2Jq L3Vzci9zcmMvdXNyLmJpbi9ubCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL25sDQo9PT0+ IHVzci5iaW4vbm9odXANCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9ub2h1cCBjcmVhdGVkIGZv ciAvdXNyL3NyYy91c3IuYmluL25vaHVwDQo9PT0+IHVzci5iaW4vb2JqZm9ybWF0DQovdXNyL29i ai91c3Ivc3JjL3Vzci5iaW4vb2JqZm9ybWF0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4v b2JqZm9ybWF0DQo9PT0+IHVzci5iaW4vb3BpZWluZm8NCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJp bi9vcGllaW5mbyBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL29waWVpbmZvDQo9PT0+IHVz ci5iaW4vb3BpZWtleQ0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL29waWVrZXkgY3JlYXRlZCBm b3IgL3Vzci9zcmMvdXNyLmJpbi9vcGlla2V5DQo9PT0+IHVzci5iaW4vb3BpZXBhc3N3ZA0KL3Vz ci9vYmovdXNyL3NyYy91c3IuYmluL29waWVwYXNzd2QgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNy LmJpbi9vcGllcGFzc3dkDQo9PT0+IHVzci5iaW4vcGFnZXNpemUNCi91c3Ivb2JqL3Vzci9zcmMv dXNyLmJpbi9wYWdlc2l6ZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3BhZ2VzaXplDQo9 PT0+IHVzci5iaW4vcGFzc3dkDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vcGFzc3dkIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vcGFzc3dkDQo9PT0+IHVzci5iaW4vcGFzdGUNCi91c3Iv b2JqL3Vzci9zcmMvdXNyLmJpbi9wYXN0ZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3Bh c3RlDQo9PT0+IHVzci5iaW4vcGF0aGNoaw0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL3BhdGhj aGsgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9wYXRoY2hrDQo9PT0+IHVzci5iaW4vcGtp bGwNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9wa2lsbCBjcmVhdGVkIGZvciAvdXNyL3NyYy91 c3IuYmluL3BraWxsDQo9PT0+IHVzci5iaW4vcHINCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9w ciBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3ByDQo9PT0+IHVzci5iaW4vcHJpbnRlbnYN Ci91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9wcmludGVudiBjcmVhdGVkIGZvciAvdXNyL3NyYy91 c3IuYmluL3ByaW50ZW52DQo9PT0+IHVzci5iaW4vcHJpbnRmDQovdXNyL29iai91c3Ivc3JjL3Vz ci5iaW4vcHJpbnRmIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vcHJpbnRmDQo9PT0+IHVz ci5iaW4vcXVvdGENCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9xdW90YSBjcmVhdGVkIGZvciAv dXNyL3NyYy91c3IuYmluL3F1b3RhDQo9PT0+IHVzci5iaW4vcmVuaWNlDQovdXNyL29iai91c3Iv c3JjL3Vzci5iaW4vcmVuaWNlIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vcmVuaWNlDQo9 PT0+IHVzci5iaW4vcmV2DQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vcmV2IGNyZWF0ZWQgZm9y IC91c3Ivc3JjL3Vzci5iaW4vcmV2DQo9PT0+IHVzci5iaW4vcmxvZ2luDQovdXNyL29iai91c3Iv c3JjL3Vzci5iaW4vcmxvZ2luIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vcmxvZ2luDQo9 PT0+IHVzci5iaW4vcnBjZ2VuDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vcnBjZ2VuIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vcnBjZ2VuDQo9PT0+IHVzci5iaW4vcnBjaW5mbw0KL3Vz ci9vYmovdXNyL3NyYy91c3IuYmluL3JwY2luZm8gY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJp bi9ycGNpbmZvDQo9PT0+IHVzci5iaW4vcnMNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9ycyBj cmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3JzDQo9PT0+IHVzci5iaW4vcnNoDQovdXNyL29i ai91c3Ivc3JjL3Vzci5iaW4vcnNoIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vcnNoDQo9 PT0+IHVzci5iaW4vcnVwDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vcnVwIGNyZWF0ZWQgZm9y IC91c3Ivc3JjL3Vzci5iaW4vcnVwDQo9PT0+IHVzci5iaW4vcnVwdGltZQ0KL3Vzci9vYmovdXNy L3NyYy91c3IuYmluL3J1cHRpbWUgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9ydXB0aW1l DQo9PT0+IHVzci5iaW4vcnVzZXJzDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vcnVzZXJzIGNy ZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vcnVzZXJzDQo9PT0+IHVzci5iaW4vcndhbGwNCi91 c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9yd2FsbCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmlu L3J3YWxsDQo9PT0+IHVzci5iaW4vcndobw0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL3J3aG8g Y3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9yd2hvDQo9PT0+IHVzci5iaW4vc2NyaXB0DQov dXNyL29iai91c3Ivc3JjL3Vzci5iaW4vc2NyaXB0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5i aW4vc2NyaXB0DQo9PT0+IHVzci5iaW4vc2VkDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vc2Vk IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vc2VkDQo9PT0+IHVzci5iaW4vc2hhcg0KL3Vz ci9vYmovdXNyL3NyYy91c3IuYmluL3NoYXIgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi9z aGFyDQo9PT0+IHVzci5iaW4vc2hvd21vdW50DQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vc2hv d21vdW50IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vc2hvd21vdW50DQo9PT0+IHVzci5i aW4vc21idXRpbA0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL3NtYnV0aWwgY3JlYXRlZCBmb3Ig L3Vzci9zcmMvdXNyLmJpbi9zbWJ1dGlsDQo9PT0+IHVzci5iaW4vc29ja3N0YXQNCi91c3Ivb2Jq L3Vzci9zcmMvdXNyLmJpbi9zb2Nrc3RhdCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3Nv Y2tzdGF0DQo9PT0+IHVzci5iaW4vc3BsaXQNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9zcGxp dCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3NwbGl0DQo9PT0+IHVzci5iaW4vc3RhdA0K L3Vzci9vYmovdXNyL3NyYy91c3IuYmluL3N0YXQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJp bi9zdGF0DQo9PT0+IHVzci5iaW4vc3UNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi9zdSBjcmVh dGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3N1DQo9PT0+IHVzci5iaW4vc3lzdGF0DQovdXNyL29i ai91c3Ivc3JjL3Vzci5iaW4vc3lzdGF0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vc3lz dGF0DQo9PT0+IHVzci5iaW4vdGFicw0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL3RhYnMgY3Jl YXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi90YWJzDQo9PT0+IHVzci5iaW4vdGFpbA0KL3Vzci9v YmovdXNyL3NyYy91c3IuYmluL3RhaWwgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi90YWls DQo9PT0+IHVzci5iaW4vdGFsaw0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL3RhbGsgY3JlYXRl ZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi90YWxrDQo9PT0+IHVzci5iaW4vdGFyDQovdXNyL29iai91 c3Ivc3JjL3Vzci5iaW4vdGFyIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vdGFyDQo9PT0+ IHVzci5iaW4vdGNvcHkNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi90Y29weSBjcmVhdGVkIGZv ciAvdXNyL3NyYy91c3IuYmluL3Rjb3B5DQo9PT0+IHVzci5iaW4vdGVlDQovdXNyL29iai91c3Iv c3JjL3Vzci5iaW4vdGVlIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vdGVlDQo9PT0+IHVz ci5iaW4vdGVsbmV0DQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vdGVsbmV0IGNyZWF0ZWQgZm9y IC91c3Ivc3JjL3Vzci5iaW4vdGVsbmV0DQo9PT0+IHVzci5iaW4vdGZ0cA0KL3Vzci9vYmovdXNy L3NyYy91c3IuYmluL3RmdHAgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi90ZnRwDQo9PT0+ IHVzci5iaW4vdGltZQ0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL3RpbWUgY3JlYXRlZCBmb3Ig L3Vzci9zcmMvdXNyLmJpbi90aW1lDQo9PT0+IHVzci5iaW4vdGlwDQo9PT0+IHVzci5iaW4vdGlw L3RpcA0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL3RpcC90aXAgY3JlYXRlZCBmb3IgL3Vzci9z cmMvdXNyLmJpbi90aXAvdGlwDQo9PT0+IHVzci5iaW4vdG9wDQovdXNyL29iai91c3Ivc3JjL3Vz ci5iaW4vdG9wIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vdG9wDQo9PT0+IHVzci5iaW4v dG91Y2gNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi90b3VjaCBjcmVhdGVkIGZvciAvdXNyL3Ny Yy91c3IuYmluL3RvdWNoDQo9PT0+IHVzci5iaW4vdHB1dA0KL3Vzci9vYmovdXNyL3NyYy91c3Iu YmluL3RwdXQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi90cHV0DQo9PT0+IHVzci5iaW4v dHINCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi90ciBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iu YmluL3RyDQo9PT0+IHVzci5iaW4vdHJ1ZQ0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL3RydWUg Y3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi90cnVlDQo9PT0+IHVzci5iaW4vdHJ1bmNhdGUN Ci91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi90cnVuY2F0ZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91 c3IuYmluL3RydW5jYXRlDQo9PT0+IHVzci5iaW4vdHJ1c3MNCi91c3Ivb2JqL3Vzci9zcmMvdXNy LmJpbi90cnVzcyBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3RydXNzDQo9PT0+IHVzci5i aW4vdHNldA0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL3RzZXQgY3JlYXRlZCBmb3IgL3Vzci9z cmMvdXNyLmJpbi90c2V0DQo9PT0+IHVzci5iaW4vdHNvcnQNCi91c3Ivb2JqL3Vzci9zcmMvdXNy LmJpbi90c29ydCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3Rzb3J0DQo9PT0+IHVzci5i aW4vdHR5DQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vdHR5IGNyZWF0ZWQgZm9yIC91c3Ivc3Jj L3Vzci5iaW4vdHR5DQo9PT0+IHVzci5iaW4vdWwNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi91 bCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3VsDQo9PT0+IHVzci5iaW4vdW5hbWUNCi91 c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi91bmFtZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmlu L3VuYW1lDQo9PT0+IHVzci5iaW4vdW5leHBhbmQNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi91 bmV4cGFuZCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3VuZXhwYW5kDQo9PT0+IHVzci5i aW4vdW5pZmRlZg0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL3VuaWZkZWYgY3JlYXRlZCBmb3Ig L3Vzci9zcmMvdXNyLmJpbi91bmlmZGVmDQo9PT0+IHVzci5iaW4vdW5pcQ0KL3Vzci9vYmovdXNy L3NyYy91c3IuYmluL3VuaXEgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi91bmlxDQo9PT0+ IHVzci5iaW4vdW5pdHMNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi91bml0cyBjcmVhdGVkIGZv ciAvdXNyL3NyYy91c3IuYmluL3VuaXRzDQo9PT0+IHVzci5iaW4vdW52aXMNCi91c3Ivb2JqL3Vz ci9zcmMvdXNyLmJpbi91bnZpcyBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3VudmlzDQo9 PT0+IHVzci5iaW4vdXNiaGlkYWN0aW9uDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vdXNiaGlk YWN0aW9uIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vdXNiaGlkYWN0aW9uDQo9PT0+IHVz ci5iaW4vdXNiaGlkY3RsDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vdXNiaGlkY3RsIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vdXNiaGlkY3RsDQo9PT0+IHVzci5iaW4vdXNlcnMNCi91 c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi91c2VycyBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmlu L3VzZXJzDQo9PT0+IHVzci5iaW4vdXVkZWNvZGUNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi91 dWRlY29kZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3V1ZGVjb2RlDQo9PT0+IHVzci5i aW4vdXVlbmNvZGUNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi91dWVuY29kZSBjcmVhdGVkIGZv ciAvdXNyL3NyYy91c3IuYmluL3V1ZW5jb2RlDQo9PT0+IHVzci5iaW4vdXVpZGdlbg0KL3Vzci9v YmovdXNyL3NyYy91c3IuYmluL3V1aWRnZW4gY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi91 dWlkZ2VuDQo9PT0+IHVzci5iaW4vdmdyaW5kDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vdmdy aW5kIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vdmdyaW5kDQo9PT0+IHVzci5iaW4vdmkN Ci91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi92aSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmlu L3ZpDQo9PT0+IHVzci5iaW4vdmlzDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vdmlzIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vdmlzDQo9PT0+IHVzci5iaW4vdm1zdGF0DQovdXNyL29i ai91c3Ivc3JjL3Vzci5iaW4vdm1zdGF0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vdm1z dGF0DQo9PT0+IHVzci5iaW4vdw0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL3cgY3JlYXRlZCBm b3IgL3Vzci9zcmMvdXNyLmJpbi93DQo9PT0+IHVzci5iaW4vd2FsbA0KL3Vzci9vYmovdXNyL3Ny Yy91c3IuYmluL3dhbGwgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi93YWxsDQo9PT0+IHVz ci5iaW4vd2MNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi93YyBjcmVhdGVkIGZvciAvdXNyL3Ny Yy91c3IuYmluL3djDQo9PT0+IHVzci5iaW4vd2hhdA0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmlu L3doYXQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLmJpbi93aGF0DQo9PT0+IHVzci5iaW4vd2hl cmVpcw0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL3doZXJlaXMgY3JlYXRlZCBmb3IgL3Vzci9z cmMvdXNyLmJpbi93aGVyZWlzDQo9PT0+IHVzci5iaW4vd2hpY2gNCi91c3Ivb2JqL3Vzci9zcmMv dXNyLmJpbi93aGljaCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3doaWNoDQo9PT0+IHVz ci5iaW4vd2hvDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vd2hvIGNyZWF0ZWQgZm9yIC91c3Iv c3JjL3Vzci5iaW4vd2hvDQo9PT0+IHVzci5iaW4vd2hvaXMNCi91c3Ivb2JqL3Vzci9zcmMvdXNy LmJpbi93aG9pcyBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3dob2lzDQo9PT0+IHVzci5i aW4vd2luZG93DQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4vd2luZG93IGNyZWF0ZWQgZm9yIC91 c3Ivc3JjL3Vzci5iaW4vd2luZG93DQo9PT0+IHVzci5iaW4vd3JpdGUNCi91c3Ivb2JqL3Vzci9z cmMvdXNyLmJpbi93cml0ZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3dyaXRlDQo9PT0+ IHVzci5iaW4veGFyZ3MNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi94YXJncyBjcmVhdGVkIGZv ciAvdXNyL3NyYy91c3IuYmluL3hhcmdzDQo9PT0+IHVzci5iaW4veGluc3RhbGwNCi91c3Ivb2Jq L3Vzci9zcmMvdXNyLmJpbi94aW5zdGFsbCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3hp bnN0YWxsDQo9PT0+IHVzci5iaW4veGxpbnQNCj09PT4gdXNyLmJpbi94bGludC9saW50MQ0KL3Vz ci9vYmovdXNyL3NyYy91c3IuYmluL3hsaW50L2xpbnQxIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vz ci5iaW4veGxpbnQvbGludDENCj09PT4gdXNyLmJpbi94bGludC9saW50Mg0KL3Vzci9vYmovdXNy L3NyYy91c3IuYmluL3hsaW50L2xpbnQyIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4veGxp bnQvbGludDINCj09PT4gdXNyLmJpbi94bGludC94bGludA0KL3Vzci9vYmovdXNyL3NyYy91c3Iu YmluL3hsaW50L3hsaW50IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4veGxpbnQveGxpbnQN Cj09PT4gdXNyLmJpbi94bGludC9sbGliDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4veGxpbnQv bGxpYiBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3hsaW50L2xsaWINCj09PT4gdXNyLmJp bi94c3RyDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4veHN0ciBjcmVhdGVkIGZvciAvdXNyL3Ny Yy91c3IuYmluL3hzdHINCj09PT4gdXNyLmJpbi95YWNjDQovdXNyL29iai91c3Ivc3JjL3Vzci5i aW4veWFjYyBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3lhY2MNCj09PT4gdXNyLmJpbi95 ZXMNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLmJpbi95ZXMgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNy LmJpbi95ZXMNCj09PT4gdXNyLmJpbi95cGNhdA0KL3Vzci9vYmovdXNyL3NyYy91c3IuYmluL3lw Y2F0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4veXBjYXQNCj09PT4gdXNyLmJpbi95cG1h dGNoDQovdXNyL29iai91c3Ivc3JjL3Vzci5iaW4veXBtYXRjaCBjcmVhdGVkIGZvciAvdXNyL3Ny Yy91c3IuYmluL3lwbWF0Y2gNCj09PT4gdXNyLmJpbi95cHdoaWNoDQovdXNyL29iai91c3Ivc3Jj L3Vzci5iaW4veXB3aGljaCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3lwd2hpY2gNCj09 PT4gdXNyLnNiaW4NCj09PT4gdXNyLnNiaW4vYWMNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4v YWMgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vYWMNCj09PT4gdXNyLnNiaW4vYWNjdG9u DQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL2FjY3RvbiBjcmVhdGVkIGZvciAvdXNyL3NyYy91 c3Iuc2Jpbi9hY2N0b24NCj09PT4gdXNyLnNiaW4vYWNwaQ0KPT09PiB1c3Iuc2Jpbi9hY3BpL2Fj cGljb25mDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL2FjcGkvYWNwaWNvbmYgY3JlYXRlZCBm b3IgL3Vzci9zcmMvdXNyLnNiaW4vYWNwaS9hY3BpY29uZg0KPT09PiB1c3Iuc2Jpbi9hY3BpL2Fj cGlkYg0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9hY3BpL2FjcGlkYiBjcmVhdGVkIGZvciAv dXNyL3NyYy91c3Iuc2Jpbi9hY3BpL2FjcGlkYg0KPT09PiB1c3Iuc2Jpbi9hY3BpL2FjcGlkdW1w DQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL2FjcGkvYWNwaWR1bXAgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvdXNyLnNiaW4vYWNwaS9hY3BpZHVtcA0KPT09PiB1c3Iuc2Jpbi9hY3BpL2lhc2wNCi91 c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vYWNwaS9pYXNsIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vz ci5zYmluL2FjcGkvaWFzbA0KPT09PiB1c3Iuc2Jpbi9hZGR1c2VyDQovdXNyL29iai91c3Ivc3Jj L3Vzci5zYmluL2FkZHVzZXIgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vYWRkdXNlcg0K PT09PiB1c3Iuc2Jpbi9hbWQNCj09PT4gdXNyLnNiaW4vYW1kL2luY2x1ZGUNCi91c3Ivb2JqL3Vz ci9zcmMvdXNyLnNiaW4vYW1kL2luY2x1ZGUgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4v YW1kL2luY2x1ZGUNCj09PT4gdXNyLnNiaW4vYW1kL2xpYmFtdQ0KL3Vzci9vYmovdXNyL3NyYy91 c3Iuc2Jpbi9hbWQvbGliYW11IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2FtZC9saWJh bXUNCj09PT4gdXNyLnNiaW4vYW1kL2FtZA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9hbWQv YW1kIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2FtZC9hbWQNCj09PT4gdXNyLnNiaW4v YW1kL2FtcQ0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9hbWQvYW1xIGNyZWF0ZWQgZm9yIC91 c3Ivc3JjL3Vzci5zYmluL2FtZC9hbXENCj09PT4gdXNyLnNiaW4vYW1kL2RvYw0KL3Vzci9vYmov dXNyL3NyYy91c3Iuc2Jpbi9hbWQvZG9jIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2Ft ZC9kb2MNCj09PT4gdXNyLnNiaW4vYW1kL2ZpeG1vdW50DQovdXNyL29iai91c3Ivc3JjL3Vzci5z YmluL2FtZC9maXhtb3VudCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9hbWQvZml4bW91 bnQNCj09PT4gdXNyLnNiaW4vYW1kL2ZzaW5mbw0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9h bWQvZnNpbmZvIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2FtZC9mc2luZm8NCj09PT4g dXNyLnNiaW4vYW1kL2hsZnNkDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL2FtZC9obGZzZCBj cmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9hbWQvaGxmc2QNCj09PT4gdXNyLnNiaW4vYW1k L21rLWFtZC1tYXANCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vYW1kL21rLWFtZC1tYXAgY3Jl YXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vYW1kL21rLWFtZC1tYXANCj09PT4gdXNyLnNiaW4v YW1kL3Bhd2QNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vYW1kL3Bhd2QgY3JlYXRlZCBmb3Ig L3Vzci9zcmMvdXNyLnNiaW4vYW1kL3Bhd2QNCj09PT4gdXNyLnNiaW4vYW1kL3NjcmlwdHMNCi91 c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vYW1kL3NjcmlwdHMgY3JlYXRlZCBmb3IgL3Vzci9zcmMv dXNyLnNiaW4vYW1kL3NjcmlwdHMNCj09PT4gdXNyLnNiaW4vYW1kL3dpcmUtdGVzdA0KL3Vzci9v YmovdXNyL3NyYy91c3Iuc2Jpbi9hbWQvd2lyZS10ZXN0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vz ci5zYmluL2FtZC93aXJlLXRlc3QNCj09PT4gdXNyLnNiaW4vYW5jb250cm9sDQovdXNyL29iai91 c3Ivc3JjL3Vzci5zYmluL2FuY29udHJvbCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9h bmNvbnRyb2wNCj09PT4gdXNyLnNiaW4vYXBtDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL2Fw bSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9hcG0NCj09PT4gdXNyLnNiaW4vYXBtZA0K L3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9hcG1kIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5z YmluL2FwbWQNCj09PT4gdXNyLnNiaW4vYXJsY29udHJvbA0KL3Vzci9vYmovdXNyL3NyYy91c3Iu c2Jpbi9hcmxjb250cm9sIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2FybGNvbnRyb2wN Cj09PT4gdXNyLnNiaW4vYXJwDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL2FycCBjcmVhdGVk IGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9hcnANCj09PT4gdXNyLnNiaW4vYXNmDQovdXNyL29iai91 c3Ivc3JjL3Vzci5zYmluL2FzZiBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9hc2YNCj09 PT4gdXNyLnNiaW4vYXRtDQo9PT0+IHVzci5zYmluL2F0bS9hdG1hcnBkDQovdXNyL29iai91c3Iv c3JjL3Vzci5zYmluL2F0bS9hdG1hcnBkIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2F0 bS9hdG1hcnBkDQo9PT0+IHVzci5zYmluL2F0bS9zY3NwZA0KL3Vzci9vYmovdXNyL3NyYy91c3Iu c2Jpbi9hdG0vc2NzcGQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vYXRtL3Njc3BkDQo9 PT0+IHVzci5zYmluL2F1dGhwZg0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9hdXRocGYgY3Jl YXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vYXV0aHBmDQo9PT0+IHVzci5zYmluL2JsdWV0b290 aA0KPT09PiB1c3Iuc2Jpbi9ibHVldG9vdGgvYmNtZncNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNi aW4vYmx1ZXRvb3RoL2JjbWZ3IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2JsdWV0b290 aC9iY21mdw0KPT09PiB1c3Iuc2Jpbi9ibHVldG9vdGgvYnQzY2Z3DQovdXNyL29iai91c3Ivc3Jj L3Vzci5zYmluL2JsdWV0b290aC9idDNjZncgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4v Ymx1ZXRvb3RoL2J0M2Nmdw0KPT09PiB1c3Iuc2Jpbi9ibHVldG9vdGgvaGNjb250cm9sDQovdXNy L29iai91c3Ivc3JjL3Vzci5zYmluL2JsdWV0b290aC9oY2NvbnRyb2wgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvdXNyLnNiaW4vYmx1ZXRvb3RoL2hjY29udHJvbA0KPT09PiB1c3Iuc2Jpbi9ibHVldG9v dGgvaGNzZWNkDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL2JsdWV0b290aC9oY3NlY2QgY3Jl YXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vYmx1ZXRvb3RoL2hjc2VjZA0KPT09PiB1c3Iuc2Jp bi9ibHVldG9vdGgvaGNzZXJpYWxkDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL2JsdWV0b290 aC9oY3NlcmlhbGQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vYmx1ZXRvb3RoL2hjc2Vy aWFsZA0KPT09PiB1c3Iuc2Jpbi9ibHVldG9vdGgvbDJjb250cm9sDQovdXNyL29iai91c3Ivc3Jj L3Vzci5zYmluL2JsdWV0b290aC9sMmNvbnRyb2wgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNi aW4vYmx1ZXRvb3RoL2wyY29udHJvbA0KPT09PiB1c3Iuc2Jpbi9ibHVldG9vdGgvbDJwaW5nDQov dXNyL29iai91c3Ivc3JjL3Vzci5zYmluL2JsdWV0b290aC9sMnBpbmcgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvdXNyLnNiaW4vYmx1ZXRvb3RoL2wycGluZw0KPT09PiB1c3Iuc2Jpbi9ibHVldG9vdGgv cmZjb21tX3BwcGQNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vYmx1ZXRvb3RoL3JmY29tbV9w cHBkIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2JsdWV0b290aC9yZmNvbW1fcHBwZA0K PT09PiB1c3Iuc2Jpbi9ibHVldG9vdGgvc2RwY29udHJvbA0KL3Vzci9vYmovdXNyL3NyYy91c3Iu c2Jpbi9ibHVldG9vdGgvc2RwY29udHJvbCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9i bHVldG9vdGgvc2RwY29udHJvbA0KPT09PiB1c3Iuc2Jpbi9ibHVldG9vdGgvc2RwZA0KL3Vzci9v YmovdXNyL3NyYy91c3Iuc2Jpbi9ibHVldG9vdGgvc2RwZCBjcmVhdGVkIGZvciAvdXNyL3NyYy91 c3Iuc2Jpbi9ibHVldG9vdGgvc2RwZA0KPT09PiB1c3Iuc2Jpbi9ib290MGNmZw0KL3Vzci9vYmov dXNyL3NyYy91c3Iuc2Jpbi9ib290MGNmZyBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9i b290MGNmZw0KPT09PiB1c3Iuc2Jpbi9ib290cGFyYW1kDQo9PT0+IHVzci5zYmluL2Jvb3RwYXJh bWQvYm9vdHBhcmFtZA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9ib290cGFyYW1kL2Jvb3Rw YXJhbWQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vYm9vdHBhcmFtZC9ib290cGFyYW1k DQo9PT0+IHVzci5zYmluL2Jvb3RwYXJhbWQvY2FsbGJvb3RkDQovdXNyL29iai91c3Ivc3JjL3Vz ci5zYmluL2Jvb3RwYXJhbWQvY2FsbGJvb3RkIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmlu L2Jvb3RwYXJhbWQvY2FsbGJvb3RkDQo9PT0+IHVzci5zYmluL2Jzbm1wZA0KPT09PiB1c3Iuc2Jp bi9ic25tcGQvZ2Vuc25tcHRyZWUNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vYnNubXBkL2dl bnNubXB0cmVlIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2Jzbm1wZC9nZW5zbm1wdHJl ZQ0KPT09PiB1c3Iuc2Jpbi9ic25tcGQvYnNubXBkDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmlu L2Jzbm1wZC9ic25tcGQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vYnNubXBkL2Jzbm1w ZA0KPT09PiB1c3Iuc2Jpbi9idHhsZA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9idHhsZCBj cmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9idHhsZA0KPT09PiB1c3Iuc2Jpbi9idXJuY2QN Ci91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vYnVybmNkIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vz ci5zYmluL2J1cm5jZA0KPT09PiB1c3Iuc2Jpbi9jZGNvbnRyb2wNCi91c3Ivb2JqL3Vzci9zcmMv dXNyLnNiaW4vY2Rjb250cm9sIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2NkY29udHJv bA0KPT09PiB1c3Iuc2Jpbi9jaGtncnANCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vY2hrZ3Jw IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2Noa2dycA0KPT09PiB1c3Iuc2Jpbi9jaG93 bg0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9jaG93biBjcmVhdGVkIGZvciAvdXNyL3NyYy91 c3Iuc2Jpbi9jaG93bg0KPT09PiB1c3Iuc2Jpbi9jaHJvb3QNCi91c3Ivb2JqL3Vzci9zcmMvdXNy LnNiaW4vY2hyb290IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2Nocm9vdA0KPT09PiB1 c3Iuc2Jpbi9ja2Rpc3QNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vY2tkaXN0IGNyZWF0ZWQg Zm9yIC91c3Ivc3JjL3Vzci5zYmluL2NrZGlzdA0KPT09PiB1c3Iuc2Jpbi9jb25maWcNCi91c3Iv b2JqL3Vzci9zcmMvdXNyLnNiaW4vY29uZmlnIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmlu L2NvbmZpZw0KPT09PiB1c3Iuc2Jpbi9jcm9uDQo9PT0+IHVzci5zYmluL2Nyb24vbGliDQovdXNy L29iai91c3Ivc3JjL3Vzci5zYmluL2Nyb24vbGliIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5z YmluL2Nyb24vbGliDQo9PT0+IHVzci5zYmluL2Nyb24vY3Jvbg0KL3Vzci9vYmovdXNyL3NyYy91 c3Iuc2Jpbi9jcm9uL2Nyb24gY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vY3Jvbi9jcm9u DQo9PT0+IHVzci5zYmluL2Nyb24vY3JvbnRhYg0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9j cm9uL2Nyb250YWIgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vY3Jvbi9jcm9udGFiDQo9 PT0+IHVzci5zYmluL2NydW5jaA0KPT09PiB1c3Iuc2Jpbi9jcnVuY2gvY3J1bmNoZ2VuDQovdXNy L29iai91c3Ivc3JjL3Vzci5zYmluL2NydW5jaC9jcnVuY2hnZW4gY3JlYXRlZCBmb3IgL3Vzci9z cmMvdXNyLnNiaW4vY3J1bmNoL2NydW5jaGdlbg0KPT09PiB1c3Iuc2Jpbi9jcnVuY2gvY3J1bmNo aWRlDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL2NydW5jaC9jcnVuY2hpZGUgY3JlYXRlZCBm b3IgL3Vzci9zcmMvdXNyLnNiaW4vY3J1bmNoL2NydW5jaGlkZQ0KPT09PiB1c3Iuc2Jpbi9jdG0N Cj09PT4gdXNyLnNiaW4vY3RtL2N0bQ0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9jdG0vY3Rt IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2N0bS9jdG0NCj09PT4gdXNyLnNiaW4vY3Rt L2N0bV9ybWFpbA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9jdG0vY3RtX3JtYWlsIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2N0bS9jdG1fcm1haWwNCj09PT4gdXNyLnNiaW4vY3Rt L2N0bV9zbWFpbA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9jdG0vY3RtX3NtYWlsIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2N0bS9jdG1fc21haWwNCj09PT4gdXNyLnNiaW4vY3Rt L2N0bV9kZXF1ZXVlDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL2N0bS9jdG1fZGVxdWV1ZSBj cmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9jdG0vY3RtX2RlcXVldWUNCj09PT4gdXNyLnNi aW4vZGFlbW9uDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL2RhZW1vbiBjcmVhdGVkIGZvciAv dXNyL3NyYy91c3Iuc2Jpbi9kYWVtb24NCj09PT4gdXNyLnNiaW4vZGNvbnNjaGF0DQovdXNyL29i ai91c3Ivc3JjL3Vzci5zYmluL2Rjb25zY2hhdCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jp bi9kY29uc2NoYXQNCj09PT4gdXNyLnNiaW4vZGV2aW5mbw0KL3Vzci9vYmovdXNyL3NyYy91c3Iu c2Jpbi9kZXZpbmZvIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2RldmluZm8NCj09PT4g dXNyLnNiaW4vZGlnaWN0bA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9kaWdpY3RsIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2RpZ2ljdGwNCj09PT4gdXNyLnNiaW4vZGlza2luZm8N Ci91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vZGlza2luZm8gY3JlYXRlZCBmb3IgL3Vzci9zcmMv dXNyLnNiaW4vZGlza2luZm8NCj09PT4gdXNyLnNiaW4vZWRxdW90YQ0KL3Vzci9vYmovdXNyL3Ny Yy91c3Iuc2Jpbi9lZHF1b3RhIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2VkcXVvdGEN Cj09PT4gdXNyLnNiaW4vZXh0YXR0cg0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9leHRhdHRy IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2V4dGF0dHINCj09PT4gdXNyLnNiaW4vZXh0 YXR0cmN0bA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9leHRhdHRyY3RsIGNyZWF0ZWQgZm9y IC91c3Ivc3JjL3Vzci5zYmluL2V4dGF0dHJjdGwNCj09PT4gdXNyLnNiaW4vZmFpdGhkDQovdXNy L29iai91c3Ivc3JjL3Vzci5zYmluL2ZhaXRoZCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jp bi9mYWl0aGQNCj09PT4gdXNyLnNiaW4vZmRjb250cm9sDQovdXNyL29iai91c3Ivc3JjL3Vzci5z YmluL2ZkY29udHJvbCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9mZGNvbnRyb2wNCj09 PT4gdXNyLnNiaW4vZmRmb3JtYXQNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vZmRmb3JtYXQg Y3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vZmRmb3JtYXQNCj09PT4gdXNyLnNiaW4vZmRy ZWFkDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL2ZkcmVhZCBjcmVhdGVkIGZvciAvdXNyL3Ny Yy91c3Iuc2Jpbi9mZHJlYWQNCj09PT4gdXNyLnNiaW4vZmR3cml0ZQ0KL3Vzci9vYmovdXNyL3Ny Yy91c3Iuc2Jpbi9mZHdyaXRlIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2Zkd3JpdGUN Cj09PT4gdXNyLnNiaW4vZndjb250cm9sDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL2Z3Y29u dHJvbCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9md2NvbnRyb2wNCj09PT4gdXNyLnNi aW4vZ2V0Zm1hYw0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9nZXRmbWFjIGNyZWF0ZWQgZm9y IC91c3Ivc3JjL3Vzci5zYmluL2dldGZtYWMNCj09PT4gdXNyLnNiaW4vZ2V0cG1hYw0KL3Vzci9v YmovdXNyL3NyYy91c3Iuc2Jpbi9nZXRwbWFjIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmlu L2dldHBtYWMNCj09PT4gdXNyLnNiaW4vZ3N0YXQNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4v Z3N0YXQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vZ3N0YXQNCj09PT4gdXNyLnNiaW4v aWZtY3N0YXQNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vaWZtY3N0YXQgY3JlYXRlZCBmb3Ig L3Vzci9zcmMvdXNyLnNiaW4vaWZtY3N0YXQNCj09PT4gdXNyLnNiaW4vaW5ldGQNCi91c3Ivb2Jq L3Vzci9zcmMvdXNyLnNiaW4vaW5ldGQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vaW5l dGQNCj09PT4gdXNyLnNiaW4vaW9zdGF0DQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL2lvc3Rh dCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9pb3N0YXQNCj09PT4gdXNyLnNiaW4vaXA2 YWRkcmN0bA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9pcDZhZGRyY3RsIGNyZWF0ZWQgZm9y IC91c3Ivc3JjL3Vzci5zYmluL2lwNmFkZHJjdGwNCj09PT4gdXNyLnNiaW4vaXBmdGVzdA0KL3Vz ci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9pcGZ0ZXN0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5z YmluL2lwZnRlc3QNCj09PT4gdXNyLnNiaW4vaXByZXNlbmQNCi91c3Ivb2JqL3Vzci9zcmMvdXNy LnNiaW4vaXByZXNlbmQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vaXByZXNlbmQNCj09 PT4gdXNyLnNiaW4vaXBzZW5kDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL2lwc2VuZCBjcmVh dGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9pcHNlbmQNCj09PT4gdXNyLnNiaW4vaXB0ZXN0DQov dXNyL29iai91c3Ivc3JjL3Vzci5zYmluL2lwdGVzdCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iu c2Jpbi9pcHRlc3QNCj09PT4gdXNyLnNiaW4vSVBYcm91dGVkDQovdXNyL29iai91c3Ivc3JjL3Vz ci5zYmluL0lQWHJvdXRlZCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9JUFhyb3V0ZWQN Cj09PT4gdXNyLnNiaW4vamFpbA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9qYWlsIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2phaWwNCj09PT4gdXNyLnNiaW4vamV4ZWMNCi91c3Iv b2JqL3Vzci9zcmMvdXNyLnNiaW4vamV4ZWMgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4v amV4ZWMNCj09PT4gdXNyLnNiaW4vamxzDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL2pscyBj cmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9qbHMNCj09PT4gdXNyLnNiaW4va2JkY29udHJv bA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9rYmRjb250cm9sIGNyZWF0ZWQgZm9yIC91c3Iv c3JjL3Vzci5zYmluL2tiZGNvbnRyb2wNCj09PT4gdXNyLnNiaW4va2JkbWFwDQovdXNyL29iai91 c3Ivc3JjL3Vzci5zYmluL2tiZG1hcCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9rYmRt YXANCj09PT4gdXNyLnNiaW4va2V5c2Vydg0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9rZXlz ZXJ2IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2tleXNlcnYNCj09PT4gdXNyLnNiaW4v a2dtb24NCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4va2dtb24gY3JlYXRlZCBmb3IgL3Vzci9z cmMvdXNyLnNiaW4va2dtb24NCj09PT4gdXNyLnNiaW4va2d6aXANCi91c3Ivb2JqL3Vzci9zcmMv dXNyLnNiaW4va2d6aXAgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4va2d6aXANCj09PT4g dXNyLnNiaW4va2xkeHJlZg0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9rbGR4cmVmIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL2tsZHhyZWYNCj09PT4gdXNyLnNiaW4vbGFzdGxvZ2lu DQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL2xhc3Rsb2dpbiBjcmVhdGVkIGZvciAvdXNyL3Ny Yy91c3Iuc2Jpbi9sYXN0bG9naW4NCj09PT4gdXNyLnNiaW4vbHB0Y29udHJvbA0KL3Vzci9vYmov dXNyL3NyYy91c3Iuc2Jpbi9scHRjb250cm9sIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmlu L2xwdGNvbnRyb2wNCj09PT4gdXNyLnNiaW4vbWFpbHdyYXBwZXINCi91c3Ivb2JqL3Vzci9zcmMv dXNyLnNiaW4vbWFpbHdyYXBwZXIgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vbWFpbHdy YXBwZXINCj09PT4gdXNyLnNiaW4vbWFuY3RsDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL21h bmN0bCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9tYW5jdGwNCj09PT4gdXNyLnNiaW4v bWVtY29udHJvbA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9tZW1jb250cm9sIGNyZWF0ZWQg Zm9yIC91c3Ivc3JjL3Vzci5zYmluL21lbWNvbnRyb2wNCj09PT4gdXNyLnNiaW4vbWVyZ2VtYXN0 ZXINCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vbWVyZ2VtYXN0ZXIgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvdXNyLnNiaW4vbWVyZ2VtYXN0ZXINCj09PT4gdXNyLnNiaW4vbWl4ZXINCi91c3Ivb2Jq L3Vzci9zcmMvdXNyLnNiaW4vbWl4ZXIgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vbWl4 ZXINCj09PT4gdXNyLnNiaW4vbWxkNnF1ZXJ5DQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL21s ZDZxdWVyeSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9tbGQ2cXVlcnkNCj09PT4gdXNy LnNiaW4vbWx4Y29udHJvbA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9tbHhjb250cm9sIGNy ZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL21seGNvbnRyb2wNCj09PT4gdXNyLnNiaW4vbW91 bnRkDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL21vdW50ZCBjcmVhdGVkIGZvciAvdXNyL3Ny Yy91c3Iuc2Jpbi9tb3VudGQNCj09PT4gdXNyLnNiaW4vbW91bnRfbndmcw0KL3Vzci9vYmovdXNy L3NyYy91c3Iuc2Jpbi9tb3VudF9ud2ZzIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL21v dW50X253ZnMNCj09PT4gdXNyLnNiaW4vbW91bnRfcG9ydGFsZnMNCi91c3Ivb2JqL3Vzci9zcmMv dXNyLnNiaW4vbW91bnRfcG9ydGFsZnMgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vbW91 bnRfcG9ydGFsZnMNCj09PT4gdXNyLnNiaW4vbW91bnRfc21iZnMNCi91c3Ivb2JqL3Vzci9zcmMv dXNyLnNiaW4vbW91bnRfc21iZnMgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vbW91bnRf c21iZnMNCj09PT4gdXNyLnNiaW4vbW91c2VkDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL21v dXNlZCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9tb3VzZWQNCj09PT4gdXNyLnNiaW4v bXB0YWJsZQ0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9tcHRhYmxlIGNyZWF0ZWQgZm9yIC91 c3Ivc3JjL3Vzci5zYmluL21wdGFibGUNCj09PT4gdXNyLnNiaW4vbXJvdXRlZA0KPT09PiB1c3Iu c2Jpbi9tcm91dGVkL2NvbW1vbg0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9tcm91dGVkL2Nv bW1vbiBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9tcm91dGVkL2NvbW1vbg0KPT09PiB1 c3Iuc2Jpbi9tcm91dGVkL21yb3V0ZWQNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vbXJvdXRl ZC9tcm91dGVkIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL21yb3V0ZWQvbXJvdXRlZA0K PT09PiB1c3Iuc2Jpbi9tcm91dGVkL21yaW5mbw0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9t cm91dGVkL21yaW5mbyBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9tcm91dGVkL21yaW5m bw0KPT09PiB1c3Iuc2Jpbi9tcm91dGVkL21hcC1tYm9uZQ0KL3Vzci9vYmovdXNyL3NyYy91c3Iu c2Jpbi9tcm91dGVkL21hcC1tYm9uZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9tcm91 dGVkL21hcC1tYm9uZQ0KPT09PiB1c3Iuc2Jpbi9tcm91dGVkL210cmFjZQ0KL3Vzci9vYmovdXNy L3NyYy91c3Iuc2Jpbi9tcm91dGVkL210cmFjZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jp bi9tcm91dGVkL210cmFjZQ0KPT09PiB1c3Iuc2Jpbi9tcm91dGVkL3Rlc3Ryc3JyDQovdXNyL29i ai91c3Ivc3JjL3Vzci5zYmluL21yb3V0ZWQvdGVzdHJzcnIgY3JlYXRlZCBmb3IgL3Vzci9zcmMv dXNyLnNiaW4vbXJvdXRlZC90ZXN0cnNycg0KPT09PiB1c3Iuc2Jpbi9tdGVzdA0KL3Vzci9vYmov dXNyL3NyYy91c3Iuc2Jpbi9tdGVzdCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9tdGVz dA0KPT09PiB1c3Iuc2Jpbi9tdHJlZQ0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9tdHJlZSBj cmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9tdHJlZQ0KPT09PiB1c3Iuc2Jpbi9uYW1lZA0K L3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9uYW1lZCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iu c2Jpbi9uYW1lZA0KPT09PiB1c3Iuc2Jpbi9uYW1lZC5yZWxvYWQNCi91c3Ivb2JqL3Vzci9zcmMv dXNyLnNiaW4vbmFtZWQucmVsb2FkIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL25hbWVk LnJlbG9hZA0KPT09PiB1c3Iuc2Jpbi9uYW1lZC5yZXN0YXJ0DQovdXNyL29iai91c3Ivc3JjL3Vz ci5zYmluL25hbWVkLnJlc3RhcnQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vbmFtZWQu cmVzdGFydA0KPT09PiB1c3Iuc2Jpbi9uZGMNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vbmRj IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL25kYw0KPT09PiB1c3Iuc2Jpbi9uZGlzY3Z0 DQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL25kaXNjdnQgY3JlYXRlZCBmb3IgL3Vzci9zcmMv dXNyLnNiaW4vbmRpc2N2dA0KPT09PiB1c3Iuc2Jpbi9uZHANCi91c3Ivb2JqL3Vzci9zcmMvdXNy LnNiaW4vbmRwIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL25kcA0KPT09PiB1c3Iuc2Jp bi9uZXdzeXNsb2cNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vbmV3c3lzbG9nIGNyZWF0ZWQg Zm9yIC91c3Ivc3JjL3Vzci5zYmluL25ld3N5c2xvZw0KPT09PiB1c3Iuc2Jpbi9uZnNkDQovdXNy L29iai91c3Ivc3JjL3Vzci5zYmluL25mc2QgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4v bmZzZA0KPT09PiB1c3Iuc2Jpbi9uZ2N0bA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9uZ2N0 bCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9uZ2N0bA0KPT09PiB1c3Iuc2Jpbi9uZ2hv b2sNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vbmdob29rIGNyZWF0ZWQgZm9yIC91c3Ivc3Jj L3Vzci5zYmluL25naG9vaw0KPT09PiB1c3Iuc2Jpbi9ub2xvZ2luDQovdXNyL29iai91c3Ivc3Jj L3Vzci5zYmluL25vbG9naW4gY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vbm9sb2dpbg0K PT09PiB1c3Iuc2Jpbi9uc2xvb2t1cA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9uc2xvb2t1 cCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9uc2xvb2t1cA0KPT09PiB1c3Iuc2Jpbi9u c3VwZGF0ZQ0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9uc3VwZGF0ZSBjcmVhdGVkIGZvciAv dXNyL3NyYy91c3Iuc2Jpbi9uc3VwZGF0ZQ0KPT09PiB1c3Iuc2Jpbi9udHANCj09PT4gdXNyLnNi aW4vbnRwL2xpYm50cA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9udHAvbGlibnRwIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL250cC9saWJudHANCj09PT4gdXNyLnNiaW4vbnRwL2xp YnBhcnNlDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL250cC9saWJwYXJzZSBjcmVhdGVkIGZv ciAvdXNyL3NyYy91c3Iuc2Jpbi9udHAvbGlicGFyc2UNCj09PT4gdXNyLnNiaW4vbnRwL250cGQN Ci91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vbnRwL250cGQgY3JlYXRlZCBmb3IgL3Vzci9zcmMv dXNyLnNiaW4vbnRwL250cGQNCj09PT4gdXNyLnNiaW4vbnRwL250cGRjDQovdXNyL29iai91c3Iv c3JjL3Vzci5zYmluL250cC9udHBkYyBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9udHAv bnRwZGMNCj09PT4gdXNyLnNiaW4vbnRwL250cHENCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4v bnRwL250cHEgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vbnRwL250cHENCj09PT4gdXNy LnNiaW4vbnRwL250cGRhdGUNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vbnRwL250cGRhdGUg Y3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vbnRwL250cGRhdGUNCj09PT4gdXNyLnNiaW4v bnRwL250cHRyYWNlDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL250cC9udHB0cmFjZSBjcmVh dGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9udHAvbnRwdHJhY2UNCj09PT4gdXNyLnNiaW4vbnRw L250cHRpbWUNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vbnRwL250cHRpbWUgY3JlYXRlZCBm b3IgL3Vzci9zcmMvdXNyLnNiaW4vbnRwL250cHRpbWUNCj09PT4gdXNyLnNiaW4vbnRwL250cC1r ZXlnZW4NCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vbnRwL250cC1rZXlnZW4gY3JlYXRlZCBm b3IgL3Vzci9zcmMvdXNyLnNiaW4vbnRwL250cC1rZXlnZW4NCj09PT4gdXNyLnNiaW4vbnRwL3Nu dHANCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vbnRwL3NudHAgY3JlYXRlZCBmb3IgL3Vzci9z cmMvdXNyLnNiaW4vbnRwL3NudHANCj09PT4gdXNyLnNiaW4vbnRwL2RvYw0KL3Vzci9vYmovdXNy L3NyYy91c3Iuc2Jpbi9udHAvZG9jIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL250cC9k b2MNCj09PT4gdXNyLnNiaW4vcGNjYXJkDQo9PT0+IHVzci5zYmluL3BjY2FyZC9wY2NhcmRjDQov dXNyL29iai91c3Ivc3JjL3Vzci5zYmluL3BjY2FyZC9wY2NhcmRjIGNyZWF0ZWQgZm9yIC91c3Iv c3JjL3Vzci5zYmluL3BjY2FyZC9wY2NhcmRjDQo9PT0+IHVzci5zYmluL3BjY2FyZC9wY2NhcmRk DQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL3BjY2FyZC9wY2NhcmRkIGNyZWF0ZWQgZm9yIC91 c3Ivc3JjL3Vzci5zYmluL3BjY2FyZC9wY2NhcmRkDQo9PT0+IHVzci5zYmluL3BjaWNvbmYNCi91 c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vcGNpY29uZiBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iu c2Jpbi9wY2ljb25mDQo9PT0+IHVzci5zYmluL3BjdnQNCj09PT4gdXNyLnNiaW4vcGN2dC9rZXlj YXANCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vcGN2dC9rZXljYXAgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvdXNyLnNiaW4vcGN2dC9rZXljYXANCj09PT4gdXNyLnNiaW4vcGN2dC9jdXJzb3INCi91 c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vcGN2dC9jdXJzb3IgY3JlYXRlZCBmb3IgL3Vzci9zcmMv dXNyLnNiaW4vcGN2dC9jdXJzb3INCj09PT4gdXNyLnNiaW4vcGN2dC9mb250ZWRpdA0KL3Vzci9v YmovdXNyL3NyYy91c3Iuc2Jpbi9wY3Z0L2ZvbnRlZGl0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vz ci5zYmluL3BjdnQvZm9udGVkaXQNCj09PT4gdXNyLnNiaW4vcGN2dC9mb250cw0KL3Vzci9vYmov dXNyL3NyYy91c3Iuc2Jpbi9wY3Z0L2ZvbnRzIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmlu L3BjdnQvZm9udHMNCj09PT4gdXNyLnNiaW4vcGN2dC9rY29uDQovdXNyL29iai91c3Ivc3JjL3Vz ci5zYmluL3BjdnQva2NvbiBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9wY3Z0L2tjb24N Cj09PT4gdXNyLnNiaW4vcGN2dC9sb2FkZm9udA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9w Y3Z0L2xvYWRmb250IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL3BjdnQvbG9hZGZvbnQN Cj09PT4gdXNyLnNiaW4vcGN2dC9zY29uDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL3BjdnQv c2NvbiBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9wY3Z0L3Njb24NCj09PT4gdXNyLnNi aW4vcGN2dC91c2Vya2V5cw0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9wY3Z0L3VzZXJrZXlz IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL3BjdnQvdXNlcmtleXMNCj09PT4gdXNyLnNi aW4vcGN2dC92dHRlc3QNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vcGN2dC92dHRlc3QgY3Jl YXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vcGN2dC92dHRlc3QNCj09PT4gdXNyLnNiaW4vcGN2 dC9pc3BjdnQNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vcGN2dC9pc3BjdnQgY3JlYXRlZCBm b3IgL3Vzci9zcmMvdXNyLnNiaW4vcGN2dC9pc3BjdnQNCj09PT4gdXNyLnNiaW4vcGN2dC92Z2Fp bw0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9wY3Z0L3ZnYWlvIGNyZWF0ZWQgZm9yIC91c3Iv c3JjL3Vzci5zYmluL3BjdnQvdmdhaW8NCj09PT4gdXNyLnNiaW4vcGN2dC9rYmRpbw0KL3Vzci9v YmovdXNyL3NyYy91c3Iuc2Jpbi9wY3Z0L2tiZGlvIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5z YmluL3BjdnQva2JkaW8NCj09PT4gdXNyLnNiaW4vcGN2dC9kZW1vDQovdXNyL29iai91c3Ivc3Jj L3Vzci5zYmluL3BjdnQvZGVtbyBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9wY3Z0L2Rl bW8NCj09PT4gdXNyLnNiaW4vcGN2dC9NaXNjDQo9PT0+IHVzci5zYmluL3BjdnQvTWlzYy9Eb2MN Cj09PT4gdXNyLnNiaW4vcGN2dC9NaXNjL0V0Yw0KPT09PiB1c3Iuc2Jpbi9wZXJpb2RpYw0KL3Vz ci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9wZXJpb2RpYyBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iu c2Jpbi9wZXJpb2RpYw0KPT09PiB1c3Iuc2Jpbi9wa2dfaW5zdGFsbA0KPT09PiB1c3Iuc2Jpbi9w a2dfaW5zdGFsbC9saWINCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vcGtnX2luc3RhbGwvbGli IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL3BrZ19pbnN0YWxsL2xpYg0KPT09PiB1c3Iu c2Jpbi9wa2dfaW5zdGFsbC9hZGQNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vcGtnX2luc3Rh bGwvYWRkIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL3BrZ19pbnN0YWxsL2FkZA0KPT09 PiB1c3Iuc2Jpbi9wa2dfaW5zdGFsbC9jcmVhdGUNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4v cGtnX2luc3RhbGwvY3JlYXRlIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL3BrZ19pbnN0 YWxsL2NyZWF0ZQ0KPT09PiB1c3Iuc2Jpbi9wa2dfaW5zdGFsbC9kZWxldGUNCi91c3Ivb2JqL3Vz ci9zcmMvdXNyLnNiaW4vcGtnX2luc3RhbGwvZGVsZXRlIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vz ci5zYmluL3BrZ19pbnN0YWxsL2RlbGV0ZQ0KPT09PiB1c3Iuc2Jpbi9wa2dfaW5zdGFsbC9pbmZv DQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL3BrZ19pbnN0YWxsL2luZm8gY3JlYXRlZCBmb3Ig L3Vzci9zcmMvdXNyLnNiaW4vcGtnX2luc3RhbGwvaW5mbw0KPT09PiB1c3Iuc2Jpbi9wa2dfaW5z dGFsbC9zaWduDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL3BrZ19pbnN0YWxsL3NpZ24gY3Jl YXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vcGtnX2luc3RhbGwvc2lnbg0KPT09PiB1c3Iuc2Jp bi9wa2dfaW5zdGFsbC92ZXJzaW9uDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL3BrZ19pbnN0 YWxsL3ZlcnNpb24gY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vcGtnX2luc3RhbGwvdmVy c2lvbg0KPT09PiB1c3Iuc2Jpbi9wbnBpbmZvDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL3Bu cGluZm8gY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vcG5waW5mbw0KPT09PiB1c3Iuc2Jp bi9wcHANCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vcHBwIGNyZWF0ZWQgZm9yIC91c3Ivc3Jj L3Vzci5zYmluL3BwcA0KPT09PiB1c3Iuc2Jpbi9wcHBjdGwNCi91c3Ivb2JqL3Vzci9zcmMvdXNy LnNiaW4vcHBwY3RsIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL3BwcGN0bA0KPT09PiB1 c3Iuc2Jpbi9wcHBkDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL3BwcGQgY3JlYXRlZCBmb3Ig L3Vzci9zcmMvdXNyLnNiaW4vcHBwZA0KPT09PiB1c3Iuc2Jpbi9wcHBzdGF0cw0KL3Vzci9vYmov dXNyL3NyYy91c3Iuc2Jpbi9wcHBzdGF0cyBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9w cHBzdGF0cw0KPT09PiB1c3Iuc2Jpbi9wcm9jY3RsDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmlu L3Byb2NjdGwgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vcHJvY2N0bA0KPT09PiB1c3Iu c2Jpbi9wc3RhdA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9wc3RhdCBjcmVhdGVkIGZvciAv dXNyL3NyYy91c3Iuc2Jpbi9wc3RhdA0KPT09PiB1c3Iuc2Jpbi9wdw0KL3Vzci9vYmovdXNyL3Ny Yy91c3Iuc2Jpbi9wdyBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9wdw0KPT09PiB1c3Iu c2Jpbi9wd2RfbWtkYg0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9wd2RfbWtkYiBjcmVhdGVk IGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9wd2RfbWtkYg0KPT09PiB1c3Iuc2Jpbi9xdW90DQovdXNy L29iai91c3Ivc3JjL3Vzci5zYmluL3F1b3QgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4v cXVvdA0KPT09PiB1c3Iuc2Jpbi9xdW90YW9uDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL3F1 b3Rhb24gY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vcXVvdGFvbg0KPT09PiB1c3Iuc2Jp bi9yYXJwZA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9yYXJwZCBjcmVhdGVkIGZvciAvdXNy L3NyYy91c3Iuc2Jpbi9yYXJwZA0KPT09PiB1c3Iuc2Jpbi9yYXljb250cm9sDQovdXNyL29iai91 c3Ivc3JjL3Vzci5zYmluL3JheWNvbnRyb2wgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4v cmF5Y29udHJvbA0KPT09PiB1c3Iuc2Jpbi9yZXBxdW90YQ0KL3Vzci9vYmovdXNyL3NyYy91c3Iu c2Jpbi9yZXBxdW90YSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9yZXBxdW90YQ0KPT09 PiB1c3Iuc2Jpbi9yaXA2cXVlcnkNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vcmlwNnF1ZXJ5 IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL3JpcDZxdWVyeQ0KPT09PiB1c3Iuc2Jpbi9y bXQNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vcm10IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vz ci5zYmluL3JtdA0KPT09PiB1c3Iuc2Jpbi9yb3V0ZTZkDQovdXNyL29iai91c3Ivc3JjL3Vzci5z YmluL3JvdXRlNmQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vcm91dGU2ZA0KPT09PiB1 c3Iuc2Jpbi9ycGNiaW5kDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL3JwY2JpbmQgY3JlYXRl ZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vcnBjYmluZA0KPT09PiB1c3Iuc2Jpbi9ycGMubG9ja2QN Ci91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vcnBjLmxvY2tkIGNyZWF0ZWQgZm9yIC91c3Ivc3Jj L3Vzci5zYmluL3JwYy5sb2NrZA0KPT09PiB1c3Iuc2Jpbi9ycGMuc3RhdGQNCi91c3Ivb2JqL3Vz ci9zcmMvdXNyLnNiaW4vcnBjLnN0YXRkIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL3Jw Yy5zdGF0ZA0KPT09PiB1c3Iuc2Jpbi9ycGMudW1udGFsbA0KL3Vzci9vYmovdXNyL3NyYy91c3Iu c2Jpbi9ycGMudW1udGFsbCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9ycGMudW1udGFs bA0KPT09PiB1c3Iuc2Jpbi9ycGMueXBwYXNzd2RkDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmlu L3JwYy55cHBhc3N3ZGQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vcnBjLnlwcGFzc3dk ZA0KPT09PiB1c3Iuc2Jpbi9ycGMueXB1cGRhdGVkDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmlu L3JwYy55cHVwZGF0ZWQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vcnBjLnlwdXBkYXRl ZA0KPT09PiB1c3Iuc2Jpbi9ycGMueXB4ZnJkDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL3Jw Yy55cHhmcmQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vcnBjLnlweGZyZA0KPT09PiB1 c3Iuc2Jpbi9ycmVudW1kDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL3JyZW51bWQgY3JlYXRl ZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vcnJlbnVtZA0KPT09PiB1c3Iuc2Jpbi9ydGFkdmQNCi91 c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vcnRhZHZkIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5z YmluL3J0YWR2ZA0KPT09PiB1c3Iuc2Jpbi9ydHByaW8NCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNi aW4vcnRwcmlvIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL3J0cHJpbw0KPT09PiB1c3Iu c2Jpbi9ydHNvbGQNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vcnRzb2xkIGNyZWF0ZWQgZm9y IC91c3Ivc3JjL3Vzci5zYmluL3J0c29sZA0KPT09PiB1c3Iuc2Jpbi9yd2hvZA0KL3Vzci9vYmov dXNyL3NyYy91c3Iuc2Jpbi9yd2hvZCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9yd2hv ZA0KPT09PiB1c3Iuc2Jpbi9zYQ0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9zYSBjcmVhdGVk IGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9zYQ0KPT09PiB1c3Iuc2Jpbi9zZXRmbWFjDQovdXNyL29i ai91c3Ivc3JjL3Vzci5zYmluL3NldGZtYWMgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4v c2V0Zm1hYw0KPT09PiB1c3Iuc2Jpbi9zZXRrZXkNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4v c2V0a2V5IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL3NldGtleQ0KPT09PiB1c3Iuc2Jp bi9zZXRwbWFjDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL3NldHBtYWMgY3JlYXRlZCBmb3Ig L3Vzci9zcmMvdXNyLnNiaW4vc2V0cG1hYw0KPT09PiB1c3Iuc2Jpbi9zaWNvbnRyb2wNCi91c3Iv b2JqL3Vzci9zcmMvdXNyLnNiaW4vc2ljb250cm9sIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5z YmluL3NpY29udHJvbA0KPT09PiB1c3Iuc2Jpbi9zbGlwbG9naW4NCi91c3Ivb2JqL3Vzci9zcmMv dXNyLnNiaW4vc2xpcGxvZ2luIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL3NsaXBsb2dp bg0KPT09PiB1c3Iuc2Jpbi9zbHN0YXQNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vc2xzdGF0 IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL3Nsc3RhdA0KPT09PiB1c3Iuc2Jpbi9zbWJt c2cNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vc21ibXNnIGNyZWF0ZWQgZm9yIC91c3Ivc3Jj L3Vzci5zYmluL3NtYm1zZw0KPT09PiB1c3Iuc2Jpbi9zcGtydGVzdA0KL3Vzci9vYmovdXNyL3Ny Yy91c3Iuc2Jpbi9zcGtydGVzdCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9zcGtydGVz dA0KPT09PiB1c3Iuc2Jpbi9zcHJheQ0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi9zcHJheSBj cmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi9zcHJheQ0KPT09PiB1c3Iuc2Jpbi9zeXNpbnN0 YWxsDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL3N5c2luc3RhbGwgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvdXNyLnNiaW4vc3lzaW5zdGFsbA0KPT09PiB1c3Iuc2Jpbi9zeXNsb2dkDQovdXNyL29i ai91c3Ivc3JjL3Vzci5zYmluL3N5c2xvZ2QgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4v c3lzbG9nZA0KPT09PiB1c3Iuc2Jpbi90Y3BkY2hrDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmlu L3RjcGRjaGsgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vdGNwZGNoaw0KPT09PiB1c3Iu c2Jpbi90Y3BkbWF0Y2gNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vdGNwZG1hdGNoIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL3RjcGRtYXRjaA0KPT09PiB1c3Iuc2Jpbi90Y3BkdW1w DQo9PT0+IHVzci5zYmluL3RjcGR1bXAvdGNwZHVtcA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jp bi90Y3BkdW1wL3RjcGR1bXAgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vdGNwZHVtcC90 Y3BkdW1wDQo9PT0+IHVzci5zYmluL3RjcGR1bXAvdGNwc2xpY2UNCi91c3Ivb2JqL3Vzci9zcmMv dXNyLnNiaW4vdGNwZHVtcC90Y3BzbGljZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi90 Y3BkdW1wL3RjcHNsaWNlDQo9PT0+IHVzci5zYmluL3RpbWVkDQo9PT0+IHVzci5zYmluL3RpbWVk L3RpbWVkDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL3RpbWVkL3RpbWVkIGNyZWF0ZWQgZm9y IC91c3Ivc3JjL3Vzci5zYmluL3RpbWVkL3RpbWVkDQo9PT0+IHVzci5zYmluL3RpbWVkL3RpbWVk Yw0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi90aW1lZC90aW1lZGMgY3JlYXRlZCBmb3IgL3Vz ci9zcmMvdXNyLnNiaW4vdGltZWQvdGltZWRjDQo9PT0+IHVzci5zYmluL3RyYWNlcm91dGUNCi91 c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vdHJhY2Vyb3V0ZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91 c3Iuc2Jpbi90cmFjZXJvdXRlDQo9PT0+IHVzci5zYmluL3RyYWNlcm91dGU2DQovdXNyL29iai91 c3Ivc3JjL3Vzci5zYmluL3RyYWNlcm91dGU2IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmlu L3RyYWNlcm91dGU2DQo9PT0+IHVzci5zYmluL3RycHQNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNi aW4vdHJwdCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi90cnB0DQo9PT0+IHVzci5zYmlu L3R6c2V0dXANCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vdHpzZXR1cCBjcmVhdGVkIGZvciAv dXNyL3NyYy91c3Iuc2Jpbi90enNldHVwDQo9PT0+IHVzci5zYmluL3VnaWRmdw0KL3Vzci9vYmov dXNyL3NyYy91c3Iuc2Jpbi91Z2lkZncgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vdWdp ZGZ3DQo9PT0+IHVzci5zYmluL3VzYmQNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vdXNiZCBj cmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi91c2JkDQo9PT0+IHVzci5zYmluL3VzYmRldnMN Ci91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vdXNiZGV2cyBjcmVhdGVkIGZvciAvdXNyL3NyYy91 c3Iuc2Jpbi91c2JkZXZzDQo9PT0+IHVzci5zYmluL3ZpZGNvbnRyb2wNCi91c3Ivb2JqL3Vzci9z cmMvdXNyLnNiaW4vdmlkY29udHJvbCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi92aWRj b250cm9sDQo9PT0+IHVzci5zYmluL3ZpcHcNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4vdmlw dyBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi92aXB3DQo9PT0+IHVzci5zYmluL3ZuY29u ZmlnDQovdXNyL29iai91c3Ivc3JjL3Vzci5zYmluL3ZuY29uZmlnIGNyZWF0ZWQgZm9yIC91c3Iv c3JjL3Vzci5zYmluL3ZuY29uZmlnDQo9PT0+IHVzci5zYmluL3dhdGNoDQovdXNyL29iai91c3Iv c3JjL3Vzci5zYmluL3dhdGNoIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL3dhdGNoDQo9 PT0+IHVzci5zYmluL3dhdGNoZG9nZA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi93YXRjaGRv Z2QgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vd2F0Y2hkb2dkDQo9PT0+IHVzci5zYmlu L3dpY29udHJvbA0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi93aWNvbnRyb2wgY3JlYXRlZCBm b3IgL3Vzci9zcmMvdXNyLnNiaW4vd2ljb250cm9sDQo9PT0+IHVzci5zYmluL3dsY29uZmlnDQov dXNyL29iai91c3Ivc3JjL3Vzci5zYmluL3dsY29uZmlnIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vz ci5zYmluL3dsY29uZmlnDQo9PT0+IHVzci5zYmluL3lwYmluZA0KL3Vzci9vYmovdXNyL3NyYy91 c3Iuc2Jpbi95cGJpbmQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4veXBiaW5kDQo9PT0+ IHVzci5zYmluL3lwX21rZGINCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4veXBfbWtkYiBjcmVh dGVkIGZvciAvdXNyL3NyYy91c3Iuc2Jpbi95cF9ta2RiDQo9PT0+IHVzci5zYmluL3lwcG9sbA0K L3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi95cHBvbGwgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNy LnNiaW4veXBwb2xsDQo9PT0+IHVzci5zYmluL3lwcHVzaA0KL3Vzci9vYmovdXNyL3NyYy91c3Iu c2Jpbi95cHB1c2ggY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4veXBwdXNoDQo9PT0+IHVz ci5zYmluL3lwc2Vydg0KL3Vzci9vYmovdXNyL3NyYy91c3Iuc2Jpbi95cHNlcnYgY3JlYXRlZCBm b3IgL3Vzci9zcmMvdXNyLnNiaW4veXBzZXJ2DQo9PT0+IHVzci5zYmluL3lwc2V0DQovdXNyL29i ai91c3Ivc3JjL3Vzci5zYmluL3lwc2V0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL3lw c2V0DQo9PT0+IHVzci5zYmluL3ppYw0KPT09PiB1c3Iuc2Jpbi96aWMvemljDQovdXNyL29iai91 c3Ivc3JjL3Vzci5zYmluL3ppYy96aWMgY3JlYXRlZCBmb3IgL3Vzci9zcmMvdXNyLnNiaW4vemlj L3ppYw0KPT09PiB1c3Iuc2Jpbi96aWMvemR1bXANCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4v emljL3pkdW1wIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Vzci5zYmluL3ppYy96ZHVtcA0KPT09PiB1 c3Iuc2Jpbi96enoNCi91c3Ivb2JqL3Vzci9zcmMvdXNyLnNiaW4venp6IGNyZWF0ZWQgZm9yIC91 c3Ivc3JjL3Vzci5zYmluL3p6eg0KPT09PiBldGMNCi91c3Ivb2JqL3Vzci9zcmMvZXRjIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL2V0Yw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IHN0YWdlIDIuMzogYnVpbGQgdG9vbHMN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpjZCAvdXNyL3NyYzsgTUFLRU9CSkRJUlBSRUZJWD0vdXNyL29iaiAgREVTVERJUj0g IElOU1RBTEw9InNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2giICBQQVRIPS91c3Ivb2JqL3Vz ci9zcmMvaTM4Ni9sZWdhY3kvdXNyL3NiaW46L3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91 c3IvYmluOi91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2dhbWVzOi9zYmluOi9iaW46 L3Vzci9zYmluOi91c3IvYmluICBXT1JMRFRNUD0vdXNyL29iai91c3Ivc3JjL2kzODYgIE1BS0VG TEFHUz0iLW0gL3Vzci9zcmMvdG9vbHMvYnVpbGQvbWsgIC1EIE5PX1JFU0NVRSAtbSAvdXNyL3Ny Yy9zaGFyZS9tayAiIC91c3Ivb2JqL3Vzci9zcmMvbWFrZS5pMzg2L21ha2UgLWYgTWFrZWZpbGUu aW5jMSAgQk9PVFNUUkFQUElORz01MDIxMjggLUROT0xJTlQgLUROT19DUFVfQ0ZMQUdTIC1ETk9f V0FSTlMgYnVpbGQtdG9vbHMNCj09PT4gYmluL2NzaA0KZ3JlcCAnRVJSXycgL3Vzci9zcmMvYmlu L2NzaC8uLi8uLi9jb250cmliL3Rjc2gvc2guZXJyLmMgfCBncmVwICdeI2RlZmluZScgPj4gc2gu ZXJyLmgNCmNjIC1FIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2Jpbi9jc2ggLUkvdXNyL3NyYy9i aW4vY3NoLy4uLy4uL2NvbnRyaWIvdGNzaCAtRF9QQVRIX1RDU0hFTEw9JyIvYmluL2NzaCInICAt SS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgL3Vzci9zcmMvYmluL2Nz aC8uLi8uLi9jb250cmliL3Rjc2gvdGMuY29uc3QuYyAvdXNyL3NyYy9iaW4vY3NoLy4uLy4uL2Nv bnRyaWIvdGNzaC9zaC5jaGFyLmggL3Vzci9zcmMvYmluL2NzaC9jb25maWcuaCAvdXNyL3NyYy9i aW4vY3NoLy4uLy4uL2NvbnRyaWIvdGNzaC9jb25maWdfZi5oIC91c3Ivc3JjL2Jpbi9jc2gvLi4v Li4vY29udHJpYi90Y3NoL3NoLnR5cGVzLmggc2guZXJyLmggLURfaF90Y19jb25zdCB8IGdyZXAg J0NoYXIgU1RSJyB8ICBzZWQgLWUgJ3MvQ2hhciBcKFthLXpBLVowLTlfXSpcKVwoLipcKS9leHRl cm4gQ2hhciBcMVtdOy8nIHwgIHNvcnQgPj4gdGMuY29uc3QuaA0KY2MgLW8gZ2V0aG9zdCAgLUwv dXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9saWIgLU8gLXBpcGUgLUkuIC1JL3Vzci9z cmMvYmluL2NzaCAtSS91c3Ivc3JjL2Jpbi9jc2gvLi4vLi4vY29udHJpYi90Y3NoIC1EX1BBVEhf VENTSEVMTD0nIi9iaW4vY3NoIicgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3Iv aW5jbHVkZSAvdXNyL3NyYy9iaW4vY3NoLy4uLy4uL2NvbnRyaWIvdGNzaC9nZXRob3N0LmMNCj09 PT4gYmluL3NoDQpjYyAtTyAtcGlwZSAtRFNIRUxMIC1JLiAtSS91c3Ivc3JjL2Jpbi9zaCAgLUkv dXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2Jpbi9z aC9ta2luaXQuYw0KY2MgLU8gLXBpcGUgLURTSEVMTCAtSS4gLUkvdXNyL3NyYy9iaW4vc2ggIC1J L3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAgLUwvdXNyL29iai91c3Iv c3JjL2kzODYvbGVnYWN5L3Vzci9saWIgbWtpbml0Lm8gIC1vIG1raW5pdA0KY2MgLU8gLXBpcGUg LURTSEVMTCAtSS4gLUkvdXNyL3NyYy9iaW4vc2ggIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xl Z2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9iaW4vc2gvbWtub2Rlcy5jDQpjYyAtTyAtcGlw ZSAtRFNIRUxMIC1JLiAtSS91c3Ivc3JjL2Jpbi9zaCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYv bGVnYWN5L3Vzci9pbmNsdWRlICAtTC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2xp YiBta25vZGVzLm8gIC1vIG1rbm9kZXMNCmNjIC1PIC1waXBlIC1EU0hFTEwgLUkuIC1JL3Vzci9z cmMvYmluL3NoICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMg L3Vzci9zcmMvYmluL3NoL21rc3ludGF4LmMNCmNjIC1PIC1waXBlIC1EU0hFTEwgLUkuIC1JL3Vz ci9zcmMvYmluL3NoICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUg IC1ML3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvbGliIG1rc3ludGF4Lm8gIC1vIG1r c3ludGF4DQo9PT0+IGdudS91c3IuYmluL2NjL2NjX3Rvb2xzDQplY2hvICcjaWZuZGVmIEdDQ19C Q09ORklHX0gnCQkJPiBiY29uZmlnLmgNCmVjaG8gJyNkZWZpbmUgR0NDX0JDT05GSUdfSCcJCQk+ PiBiY29uZmlnLmgNCmVjaG8gJyNpbmNsdWRlICJhdXRvLWhvc3QuaCInCQkJPj4gYmNvbmZpZy5o DQplY2hvICcjZGVmaW5lIEVYVFJBX01PREVTX0ZJTEUgImkzODYvaTM4Ni1tb2Rlcy5kZWYiJyA+ PiBiY29uZmlnLmgNCmVjaG8gJyNpZmRlZiBJTl9HQ0MnCQkJCT4+IGJjb25maWcuaA0KZWNobyAn IyBpbmNsdWRlICJhbnNpZGVjbC5oIicJCQk+PiBiY29uZmlnLmgNCmVjaG8gJyNlbmRpZicJCQkJ CT4+IGJjb25maWcuaA0KZWNobyAnI2VuZGlmIC8qIEdDQ19CQ09ORklHX0ggKi8nCQk+PiBiY29u ZmlnLmgNCmVjaG8gJyNpbmNsdWRlIDxiY29uZmlnLmg+JwkJCT4gY29uZmlnLmgNCmVjaG8gJ3N0 YXRpYyBjb25zdCBjaGFyIGNvbmZpZ3VyYXRpb25fYXJndW1lbnRzW10gPScJPiBjb25maWdhcmdz LmgNCmVjaG8gJwkiRnJlZUJTRC9pMzg2IHN5c3RlbSBjb21waWxlciI7Jwk+PiBjb25maWdhcmdz LmgNCmVjaG8gJ3N0YXRpYyBjb25zdCBjaGFyIHRocmVhZF9tb2RlbFtdID0gInBvc2l4IjsnCT4+ IGNvbmZpZ2FyZ3MuaA0KZWNobyAnc3RhdGljIGNvbnN0IHN0cnVjdCB7JwkJCQk+PiBjb25maWdh cmdzLmgNCmVjaG8gJwljb25zdCBjaGFyICpuYW1lLCAqdmFsdWU7JwkJCT4+IGNvbmZpZ2FyZ3Mu aA0KZWNobyAnfSBjb25maWd1cmVfZGVmYXVsdF9vcHRpb25zW10gPSB7JwkJPj4gY29uZmlnYXJn cy5oDQplY2hvICcJeyAiTlVMTCIsICJOVUxMIiB9IH07JwkJCQk+PiBjb25maWdhcmdzLmgNCmVj aG8gJyNpbmNsdWRlICJjcC9jcC10cmVlLmRlZiInCQk+IGdlbmNoZWNrLmgNCmVjaG8gJyNpbmNs dWRlICJvYmpjL29iamMtdHJlZS5kZWYiJwkJPj4gZ2VuY2hlY2suaA0KZWNobyAnc3RhdGljIGNv bnN0IGNoYXIgKmNvbnN0IG11bHRpbGliX3Jhd1tdID0geyAgImFvdXQgbWFvdXQ7IiwgImVsZiAh bWFvdXQ7IiwgTlVMTCB9OycJPiBtdWx0aWxpYi5oDQplY2hvICdzdGF0aWMgY29uc3QgY2hhciAq Y29uc3QgbXVsdGlsaWJfbWF0Y2hlc19yYXdbXSA9IHsgICJtYW91dCBtYW91dDsiLCAibWVsZiBt ZWxmOyIsIE5VTEwgfTsnCT4+IG11bHRpbGliLmgNCmVjaG8gJ3N0YXRpYyBjb25zdCBjaGFyICpt dWx0aWxpYl9leHRyYSA9ICIiOycJPj4gbXVsdGlsaWIuaA0KZWNobyAnc3RhdGljIGNvbnN0IGNo YXIgKm11bHRpbGliX29wdGlvbnMgPSAiIjsnPj4gbXVsdGlsaWIuaA0KZWNobyAnc3RhdGljIGNv bnN0IGNoYXIgKmNvbnN0IG11bHRpbGliX2V4Y2x1c2lvbnNfcmF3W10gPSB7ICBOVUxMIH07JwkJ CQkJPj4gbXVsdGlsaWIuaA0KZWNobyAnI2luY2x1ZGUgImNwL2xhbmctc3BlY3MuaCInCQk+IHNw ZWNzLmgNCmVjaG8gJyNpbmNsdWRlICJmL2xhbmctc3BlY3MuaCInCQk+PiBzcGVjcy5oDQplY2hv ICcjaW5jbHVkZSAib2JqYy9sYW5nLXNwZWNzLmgiJwkJPj4gc3BlY3MuaA0KZWNobyAnI2luY2x1 ZGUgPGN0eXBlLmg+JwkJCQk+IHNhZmUtY3R5cGUuaA0KZWNobyAnI2RlZmluZSBUT1VQUEVSCXRv dXBwZXInCQkJCT4+IHNhZmUtY3R5cGUuaA0KZWNobyAnI2RlZmluZSBUT0xPV0VSCXRvbG93ZXIn CQkJCT4+IHNhZmUtY3R5cGUuaA0KZWNobyAnI2RlZmluZSBJU0RJR0lUCWlzZGlnaXQnCQkJCT4+ IHNhZmUtY3R5cGUuaA0KZWNobyAnI2RlZmluZSBJU1hESUdJVAlpc3hkaWdpdCcJCQkJPj4gc2Fm ZS1jdHlwZS5oDQplY2hvICcjZGVmaW5lIElTVVBQRVIJaXN1cHBlcicJCQkJPj4gc2FmZS1jdHlw ZS5oDQplY2hvICcjZGVmaW5lIElTTE9XRVIJaXNsb3dlcicJCQkJPj4gc2FmZS1jdHlwZS5oDQpl Y2hvICcjZGVmaW5lIElTQUxQSEEJaXNhbHBoYScJCQkJPj4gc2FmZS1jdHlwZS5oDQplY2hvICcj ZGVmaW5lIElTQUxOVU0JaXNhbG51bScJCQkJPj4gc2FmZS1jdHlwZS5oDQplY2hvICcjZGVmaW5l IElTU1BBQ0UJaXNzcGFjZScJCQkJPj4gc2FmZS1jdHlwZS5oDQplY2hvICcjZGVmaW5lIElTUFVO Q1QJaXNwdW5jdCcJCQkJPj4gc2FmZS1jdHlwZS5oDQplY2hvICcjZGVmaW5lIElTR1JBUEgJaXNn cmFwaCcJCQkJPj4gc2FmZS1jdHlwZS5oDQplY2hvICcjZGVmaW5lIElTQkxBTksJaXNibGFuaycJ CQkJPj4gc2FmZS1jdHlwZS5oDQplY2hvICcjZGVmaW5lIElTUFJJTlQJaXNwcmludCcJCQkJPj4g c2FmZS1jdHlwZS5oDQplY2hvICcjZGVmaW5lIElTQ05UUkwJaXNjbnRybCcJCQkJPj4gc2FmZS1j dHlwZS5oDQplY2hvICIjZGVmaW5lIElTSURTVCh4KQkJICgoeCkgPT0gJ18nIHx8IGlzYWxwaGEo eCkpIgkJCT4+IHNhZmUtY3R5cGUuaA0KZWNobyAiI2RlZmluZSBJU0lETlVNKHgpCSAoaXNkaWdp dCh4KSB8fCBJU0lEU1QoeCkpIgkJCT4+IHNhZmUtY3R5cGUuaA0KZWNobyAiI2RlZmluZSBJU19W U1BBQ0UoeCkJICgoeCkgPT0gJ1xuJyB8fCAoeCkgPT0gJ1xyJykiCQkJPj4gc2FmZS1jdHlwZS5o DQplY2hvICIjZGVmaW5lIElTX05WU1BBQ0UoeCkJICghSVNfVlNQQUNFKHgpICYmIChpc3NwYWNl KHgpIHx8ICh4KSA9PSAnXDAnKSkiCT4+IHNhZmUtY3R5cGUuaA0KZWNobyAiI2RlZmluZSBJU19T UEFDRV9PUl9OVUwoeCkJIChpc3NwYWNlKHgpIHx8ICh4KSA9PSAnXDAnKSIJCQk+PiBzYWZlLWN0 eXBlLmgNCmVjaG8gJyNpZm5kZWYgR0NDX1RDT05GSUdfSCcJCQk+IHRjb25maWcuaA0KZWNobyAn I2RlZmluZSBHQ0NfVENPTkZJR19IJwkJCT4+IHRjb25maWcuaA0KZWNobyAnI2lmZGVmIElOX0dD QycJCQkJPj4gdGNvbmZpZy5oDQplY2hvICcjIGluY2x1ZGUgImFuc2lkZWNsLmgiJwkJCT4+IHRj b25maWcuaA0KZWNobyAnI2VuZGlmJwkJCQkJPj4gdGNvbmZpZy5oDQplY2hvICcjZGVmaW5lIFVT RURfRk9SX1RBUkdFVCcJCQk+PiB0Y29uZmlnLmgNCmVjaG8gJyNlbmRpZiAvKiBHQ0NfVENPTkZJ R19IICovJwkJPj4gdGNvbmZpZy5oDQplY2hvICcjaWZuZGVmIEdDQ19UTV9IJwkJCQk+IHRtLmgN CmVjaG8gJyNkZWZpbmUgR0NDX1RNX0gnCQkJCT4+IHRtLmgNCmVjaG8gJyNpZmRlZiBJTl9HQ0Mn CQkJCT4+IHRtLmgNCmVjaG8gJyNpbmNsdWRlICJpMzg2L2kzODYuaCInCQkJCT4+IHRtLmgNCmVj aG8gJyNpbmNsdWRlICJpMzg2L3VuaXguaCInCQkJCT4+IHRtLmgNCmVjaG8gJyNpbmNsdWRlICJp Mzg2L2F0dC5oIicJCQkJPj4gdG0uaA0KZWNobyAnI2luY2x1ZGUgImRieGVsZi5oIicJCQkJPj4g dG0uaA0KZWNobyAnI2luY2x1ZGUgImVsZm9zLmgiJwkJCQk+PiB0bS5oDQplY2hvICcjaW5jbHVk ZSAiZnJlZWJzZC1uYXRpdmUuaCInCQkJCT4+IHRtLmgNCmVjaG8gJyNpbmNsdWRlICJmcmVlYnNk LXNwZWMuaCInCQkJCT4+IHRtLmgNCmVjaG8gJyNpbmNsdWRlICJmcmVlYnNkLmgiJwkJCQk+PiB0 bS5oDQplY2hvICcjaW5jbHVkZSAiaTM4Ni9mcmVlYnNkLmgiJwkJCQk+PiB0bS5oDQplY2hvICcj aW5jbHVkZSAiZGVmYXVsdHMuaCInCQkJCT4+IHRtLmgNCmVjaG8gJyNpZiAhZGVmaW5lZCBHRU5F UkFUT1JfRklMRSAmJiAhZGVmaW5lZCBVU0VEX0ZPUl9UQVJHRVQnID4+IHRtLmgNCmVjaG8gJyMg aW5jbHVkZSAiaW5zbi1jb25zdGFudHMuaCInCQk+PiB0bS5oDQplY2hvICcjIGluY2x1ZGUgImlu c24tZmxhZ3MuaCInCQkJPj4gdG0uaA0KZWNobyAnI2VuZGlmJwkJCQkJPj4gdG0uaA0KZWNobyAn I2VuZGlmJwkJCQkJPj4gdG0uaA0KZWNobyAnI2RlZmluZSBFWFRSQV9NT0RFU19GSUxFICJpMzg2 L2kzODYtbW9kZXMuZGVmIicgPj4gdG0uaA0KZWNobyAnI2VuZGlmIC8qIEdDQ19UTV9IICovJwkJ CT4+IHRtLmgNCmVjaG8gJyNpbmNsdWRlICJpMzg2L2kzODYtcHJvdG9zLmgiJwk+PiB0bV9wLmgN CmVjaG8gJyNpbmNsdWRlICJ0bS1wcmVkcy5oIicJCQkJPj4gdG1fcC5oDQplY2hvICIjZGVmaW5l IEdDT1ZfVkVSU0lPTiAoKGdjb3ZfdW5zaWduZWRfdCkweDMzMzAzNDcwKSIgPj4gZ2Nvdi1pb3Yu aA0KZWNobyAiLyogVGhpcyBmaWxlIGlzIG1hY2hpbmUgZ2VuZXJhdGVkLiAgRG8gbm90IGVkaXQu ICAqLyIgPiBndHlwLWdlbi5oDQplY2hvICJzdGF0aWMgY29uc3QgY2hhciAqc3JjZGlyID0gIgkJ CT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMv Li4vLi4vLi4vLi4vY29udHJpYi9nY2NcIjsiCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gInN0YXRp YyBjb25zdCBjaGFyICpsYW5nX2ZpbGVzW10gPSB7IgkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIv dXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9j cC9tYW5nbGUuY1wiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUv dXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jcC9uYW1lLWxvb2t1 cC5oXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmlu L2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NwL25hbWUtbG9va3VwLmNcIiwg IgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2Nf dG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY3AvY3AtdHJlZS5oXCIsICIJCQkJCQk+PiBn dHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4u Ly4uLy4uL2NvbnRyaWIvZ2NjL2NwL2RlY2wuaFwiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNo byAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmli L2djYy9jcC9sZXguaFwiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9n bnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jcC9jYWxsLmNc IiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2Mv Y2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY3AvZGVjbC5jXCIsICIJCQkJCQk+PiBn dHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4u Ly4uLy4uL2NvbnRyaWIvZ2NjL2NwL2RlY2wyLmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVj aG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJp Yi9nY2MvY3AvcHQuY1wiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9n bnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jcC9yZXBvLmNc IiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2Mv Y2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY3Avc2VtYW50aWNzLmNcIiwgIgkJCQkJ CT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMv Li4vLi4vLi4vLi4vY29udHJpYi9nY2MvY3AvdHJlZS5jXCIsICIJCQkJCQk+PiBndHlwLWdlbi5o DQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2Nv bnRyaWIvZ2NjL2NwL3BhcnNlci5jXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91 c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2Nw L21ldGhvZC5jXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91 c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2MtY29tbW9uLmNcIiwg IgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2Nf dG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvYy1jb21tb24uaFwiLCAiCQkJCQkJPj4gZ3R5 cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8u Li8uLi9jb250cmliL2djYy9jLXByYWdtYS5jXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hv ICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIv Z2NjL29iamMvb2JqYy1hY3QuaFwiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNy L3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jLXBh cnNlLmluXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3Iu YmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2MtdHJlZS5oXCIsICIJCQkJ CQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xz Ly4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2MtZGVjbC5jXCIsICIJCQkJCQk+PiBndHlwLWdlbi5o DQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2Nv bnRyaWIvZ2NjL2Mtb2JqYy1jb21tb24uY1wiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAi XCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2dj Yy9jLWNvbW1vbi5jXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2du dS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2MtY29tbW9uLmhc IiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2Mv Y2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvYy1wcmFnbWEuY1wiLCAiCQkJCQkJPj4g Z3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8u Li8uLi8uLi9jb250cmliL2djYy9vYmpjL29iamMtYWN0LmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2Vu LmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4v Y29udHJpYi9nY2MvZi9jb20uY1wiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNy L3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9mL2Nv bS5oXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmlu L2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2Yvc3RlLmNcIiwgIgkJCQkJCT4+ IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4v Li4vLi4vLi4vY29udHJpYi9nY2MvZi93aGVyZS5oXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQpl Y2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRy aWIvZ2NjL2Yvd2hlcmUuY1wiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9mL2xleC5j XCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2Nj L2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2MtbGFuZy5jXCIsICIJCQkJCQk+PiBn dHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4u Ly4uLy4uL2NvbnRyaWIvZ2NjL2MtcGFyc2UuaW5cIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVj aG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJp Yi9nY2MvYy10cmVlLmhcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMv Z251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvYy1kZWNsLmNc IiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2Mv Y2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvYy1jb21tb24uY1wiLCAiCQkJCQkJPj4g Z3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8u Li8uLi8uLi9jb250cmliL2djYy9jLWNvbW1vbi5oXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQpl Y2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRy aWIvZ2NjL2MtcHJhZ21hLmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9z cmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvYy1vYmpj LWNvbW1vbi5jXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJOVUxMfTsiCQkJCQkJPj4g Z3R5cC1nZW4uaA0KZWNobyAic3RhdGljIGNvbnN0IGNoYXIgKmxhbmdzX2Zvcl9sYW5nX2ZpbGVz W10gPSB7Igk+PiBndHlwLWdlbi5oDQplY2hvICJcImNwXCIsICIJCQkJCQk+PiBndHlwLWdlbi5o DQplY2hvICJcImNwXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcImNwXCIsICIJCQkJ CQk+PiBndHlwLWdlbi5oDQplY2hvICJcImNwXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hv ICJcImNwXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcImNwXCIsICIJCQkJCQk+PiBn dHlwLWdlbi5oDQplY2hvICJcImNwXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcImNw XCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcImNwXCIsICIJCQkJCQk+PiBndHlwLWdl bi5oDQplY2hvICJcImNwXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcImNwXCIsICIJ CQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcImNwXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQpl Y2hvICJcImNwXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcImNwXCIsICIJCQkJCQk+ PiBndHlwLWdlbi5oDQplY2hvICJcImNwXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJc ImNwXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcImNwXCIsICIJCQkJCQk+PiBndHlw LWdlbi5oDQplY2hvICJcImNwXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIm9iamNc IiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwib2JqY1wiLCAiCQkJCQkJPj4gZ3R5cC1n ZW4uaA0KZWNobyAiXCJvYmpjXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIm9iamNc IiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwib2JqY1wiLCAiCQkJCQkJPj4gZ3R5cC1n ZW4uaA0KZWNobyAiXCJvYmpjXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIm9iamNc IiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwib2JqY1wiLCAiCQkJCQkJPj4gZ3R5cC1n ZW4uaA0KZWNobyAiXCJvYmpjXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcImZcIiwg IgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiZlwiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0K ZWNobyAiXCJmXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcImZcIiwgIgkJCQkJCT4+ IGd0eXAtZ2VuLmgNCmVjaG8gIlwiZlwiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCJm XCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcImNcIiwgIgkJCQkJCT4+IGd0eXAtZ2Vu LmgNCmVjaG8gIlwiY1wiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCJjXCIsICIJCQkJ CQk+PiBndHlwLWdlbi5oDQplY2hvICJcImNcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8g IlwiY1wiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCJjXCIsICIJCQkJCQk+PiBndHlw LWdlbi5oDQplY2hvICJcImNcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiY1wiLCAi CQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiTlVMTH07IgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVj aG8gInN0YXRpYyBjb25zdCBjaGFyICphbGxfZmlsZXNbXSA9IHsiCQk+PiBndHlwLWdlbi5oDQpl Y2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRy aWIvZ2NjL2lucHV0LmhcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMv Z251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29yZXR5cGVz LmhcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4v Y2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY3BwbGliLmhcIiwgIgkJCQkJCT4+ IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvYXV0 by1ob3N0LmhcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vz ci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnL2kzODYvaTM4 Ni5oXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmlu L2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NvbmZpZy9pMzg2L3VuaXguaFwi LCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9j Y190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcvaTM4Ni9hdHQuaFwiLCAiCQkJ CQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29s cy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcvZGJ4ZWxmLmhcIiwgIgkJCQkJCT4+IGd0 eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4v Li4vLi4vY29udHJpYi9nY2MvY29uZmlnL2VsZm9zLmhcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgN CmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvZnJlZWJzZC1uYXRpdmUu aFwiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9j Yy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcvZnJlZWJzZC1zcGVjLmhc IiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2Mv Y2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnL2ZyZWVic2QuaFwiLCAiCQkJ CQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29s cy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcvaTM4Ni9mcmVlYnNkLmhcIiwgIgkJCQkJ CT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMv Li4vLi4vLi4vLi4vY29udHJpYi9nY2MvZGVmYXVsdHMuaFwiLCAiCQkJCQkJPj4gZ3R5cC1nZW4u aA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9j b250cmliL2djYy9oYXNodGFiLmhcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vz ci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2Mvc3Bs YXktdHJlZS5oXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91 c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2JpdG1hcC5oXCIsICIJ CQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rv b2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NvdmVyYWdlLmNcIiwgIgkJCQkJCT4+IGd0eXAt Z2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4v Li4vY29udHJpYi9nY2MvZnVuY3Rpb24uaFwiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAi XCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2dj Yy9ydGwuaFwiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNy LmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9vcHRhYnMuaFwiLCAiCQkJ CQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29s cy8uLi8uLi8uLi8uLi9jb250cmliL2djYy90cmVlLmhcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgN CmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29u dHJpYi9nY2MvbGliZnVuY3MuaFwiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNy L3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9oYXNo dGFibGUuaFwiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNy LmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9yZWFsLmhcIiwgIgkJCQkJ CT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMv Li4vLi4vLi4vLi4vY29udHJpYi9nY2MvdmFycmF5LmhcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgN CmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29u dHJpYi9nY2MvaW5zbi1hZGRyLmhcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vz ci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY3Nl bGliLmhcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5i aW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvYmFzaWMtYmxvY2suaFwiLCAi CQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190 b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jZ3JhcGguaFwiLCAiCQkJCQkJPj4gZ3R5cC1n ZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8u Li9jb250cmliL2djYy9jLWNvbW1vbi5oXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJc Ii91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2Nj L2MtdHJlZS5oXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91 c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2FsaWFzLmNcIiwgIgkJ CQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9v bHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvYml0bWFwLmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2Vu LmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4v Y29udHJpYi9nY2MvY3NlbGliLmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vz ci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY2dy YXBoLmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5i aW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvZGJ4b3V0LmNcIiwgIgkJCQkJ CT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMv Li4vLi4vLi4vLi4vY29udHJpYi9nY2MvZHdhcmYyb3V0LmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2Vu LmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4v Y29udHJpYi9nY2MvZHdhcmYyYXNtLmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwi L3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2Mv ZW1pdC1ydGwuY1wiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUv dXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9leGNlcHQuY1wiLCAi CQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190 b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9leHBsb3cuY1wiLCAiCQkJCQkJPj4gZ3R5cC1n ZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8u Li9jb250cmliL2djYy9leHByLmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vz ci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvZm9s ZC1jb25zdC5jXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91 c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2Z1bmN0aW9uLmNcIiwg IgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2Nf dG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvZ2NzZS5jXCIsICIJCQkJCQk+PiBndHlwLWdl bi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4u L2NvbnRyaWIvZ2NjL2ludGVncmF0ZS5jXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJc Ii91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2Nj L2xpc3RzLmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vz ci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2Mvb3B0YWJzLmNcIiwgIgkJ CQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9v bHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvcHJvZmlsZS5jXCIsICIJCQkJCQk+PiBndHlwLWdl bi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4u L2NvbnRyaWIvZ2NjL3JhLWJ1aWxkLmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwi L3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2Mv cmVnY2xhc3MuY1wiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUv dXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9yZWctc3RhY2suY1wi LCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9j Y190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jZmdsYXlvdXQuY1wiLCAiCQkJCQkJPj4g Z3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8u Li8uLi8uLi9jb250cmliL2djYy9sYW5naG9va3MuY1wiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0K ZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250 cmliL2djYy9zZGJvdXQuY1wiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9zdG10LmNc IiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2Mv Y2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2Mvc3Rvci1sYXlvdXQuY1wiLCAiCQkJCQkJ Pj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8u Li8uLi8uLi8uLi9jb250cmliL2djYy9zdHJpbmdwb29sLmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2Vu LmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4v Y29udHJpYi9nY2MvdHJlZS5jXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Iv c3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL3ZhcmFz bS5jXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmlu L2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NvbmZpZy9pMzg2L2kzODYuY1wi LCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9j Y190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jcC9tYW5nbGUuY1wiLCAiCQkJCQkJPj4g Z3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8u Li8uLi8uLi9jb250cmliL2djYy9jcC9uYW1lLWxvb2t1cC5oXCIsICIJCQkJCQk+PiBndHlwLWdl bi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4u L2NvbnRyaWIvZ2NjL2NwL25hbWUtbG9va3VwLmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVj aG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJp Yi9nY2MvY3AvY3AtdHJlZS5oXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Iv c3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NwL2Rl Y2wuaFwiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJp bi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jcC9sZXguaFwiLCAiCQkJCQkJ Pj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8u Li8uLi8uLi8uLi9jb250cmliL2djYy9jcC9jYWxsLmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgN CmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29u dHJpYi9nY2MvY3AvZGVjbC5jXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Iv c3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NwL2Rl Y2wyLmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5i aW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY3AvcHQuY1wiLCAiCQkJCQkJ Pj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8u Li8uLi8uLi8uLi9jb250cmliL2djYy9jcC9yZXBvLmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgN CmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29u dHJpYi9nY2MvY3Avc2VtYW50aWNzLmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwi L3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2Mv Y3AvdHJlZS5jXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91 c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NwL3BhcnNlci5jXCIs ICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2Nj X3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NwL21ldGhvZC5jXCIsICIJCQkJCQk+PiBn dHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4u Ly4uLy4uL2NvbnRyaWIvZ2NjL2MtY29tbW9uLmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVj aG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJp Yi9nY2MvYy1jb21tb24uaFwiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jLXByYWdt YS5jXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmlu L2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL29iamMvb2JqYy1hY3QuaFwiLCAi CQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190 b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jLXBhcnNlLmluXCIsICIJCQkJCQk+PiBndHlw LWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4u Ly4uL2NvbnRyaWIvZ2NjL2MtdHJlZS5oXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJc Ii91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2Nj L2MtZGVjbC5jXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91 c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2Mtb2JqYy1jb21tb24u Y1wiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9j Yy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jLWNvbW1vbi5jXCIsICIJCQkJCQk+ PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4u Ly4uLy4uLy4uL2NvbnRyaWIvZ2NjL2MtY29tbW9uLmhcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgN CmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29u dHJpYi9nY2MvYy1wcmFnbWEuY1wiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNy L3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9vYmpj L29iamMtYWN0LmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251 L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvZi9jb20uY1wiLCAi CQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190 b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9mL2NvbS5oXCIsICIJCQkJCQk+PiBndHlwLWdl bi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4u L2NvbnRyaWIvZ2NjL2Yvc3RlLmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vz ci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvZi93 aGVyZS5oXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3Iu YmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2Yvd2hlcmUuY1wiLCAiCQkJ CQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29s cy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9mL2xleC5jXCIsICIJCQkJCQk+PiBndHlwLWdlbi5o DQplY2hvICJcIi91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2Nv bnRyaWIvZ2NjL2MtbGFuZy5jXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Iv c3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2MtcGFy c2UuaW5cIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5i aW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvYy10cmVlLmhcIiwgIgkJCQkJ CT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMv Li4vLi4vLi4vLi4vY29udHJpYi9nY2MvYy1kZWNsLmNcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgN CmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29u dHJpYi9nY2MvYy1jb21tb24uY1wiLCAiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCIvdXNy L3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jLWNv bW1vbi5oXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hvICJcIi91c3Ivc3JjL2dudS91c3Iu YmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2MtcHJhZ21hLmNcIiwgIgkJ CQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwiL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9v bHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvYy1vYmpjLWNvbW1vbi5jXCIsICIJCQkJCQk+PiBn dHlwLWdlbi5oDQplY2hvICJOVUxMfTsiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAic3RhdGlj IGNvbnN0IGNoYXIgKmxhbmdfZGlyX25hbWVzW10gPSB7IFwiY1wiLCAiCT4+IGd0eXAtZ2VuLmgN CmVjaG8gIlwiY3BcIiwgIgkJCQkJCT4+IGd0eXAtZ2VuLmgNCmVjaG8gIlwib2JqY1wiLCAiCQkJ CQkJPj4gZ3R5cC1nZW4uaA0KZWNobyAiXCJmXCIsICIJCQkJCQk+PiBndHlwLWdlbi5oDQplY2hv ICJOVUxMfTsiCQkJCQkJPj4gZ3R5cC1nZW4uaA0KY2MgLU8gLXBpcGUgLUkuIC1ESU5fR0NDIC1E SEFWRV9DT05GSUdfSCAtRFBSRUZJWD1cIi91c3JcIiAtSS91c3Ivb2JqL3Vzci9zcmMvZ251L3Vz ci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9j Y190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4u Ly4uLy4uLy4uL2NvbnRyaWIvZ2NjIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMv Li4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnIC1ER0VORVJBVE9SX0ZJTEUgIC1JL3Vzci9v YmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9nbnUvdXNyLmJp bi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9nZW5tb2Rlcy5jDQpjYyAtTyAt cGlwZSAtSS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJR19IIC1EUFJFRklYPVwiL3VzclwiIC1JL3Vz ci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Iv c3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MgLUkvdXNyL3NyYy9nbnUv dXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcgLURHRU5F UkFUT1JfRklMRSAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1j IC91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2Nj L2Nob29zZS10ZW1wLmMNCmNjIC1PIC1waXBlIC1JLiAtRElOX0dDQyAtREhBVkVfQ09ORklHX0gg LURQUkVGSVg9XCIvdXNyXCIgLUkvdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rv b2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2Nf dG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250 cmliL2djYyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2Nv bnRyaWIvZ2NjL2NvbmZpZyAtREdFTkVSQVRPUl9GSUxFICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4 Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMv Li4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uY2F0LmMNCmNjIC1PIC1waXBlIC1JLiAtRElOX0dD QyAtREhBVkVfQ09ORklHX0ggLURQUkVGSVg9XCIvdXNyXCIgLUkvdXNyL29iai91c3Ivc3JjL2du dS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v Y2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29s cy8uLi8uLi8uLi8uLi9jb250cmliL2djYyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rv b2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NvbmZpZyAtREdFTkVSQVRPUl9GSUxFICAtSS91 c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvZ251L3Vz ci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY3AtZGVtYW5nbGUuYw0K Y2MgLU8gLXBpcGUgLUkuIC1ESU5fR0NDIC1ESEFWRV9DT05GSUdfSCAtRFBSRUZJWD1cIi91c3Jc IiAtSS91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMg LUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3Jj L2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjIC1JL3Vzci9z cmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmln IC1ER0VORVJBVE9SX0ZJTEUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5j bHVkZSAtYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250 cmliL2djYy9jcC1kZW1pbnQuYw0KY2MgLU8gLXBpcGUgLUkuIC1ESU5fR0NDIC1ESEFWRV9DT05G SUdfSCAtRFBSRUZJWD1cIi91c3JcIiAtSS91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY2Mv Y2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8u Li9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4u L2NvbnRyaWIvZ2NjIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4v Li4vY29udHJpYi9nY2MvY29uZmlnIC1ER0VORVJBVE9SX0ZJTEUgIC1JL3Vzci9vYmovdXNyL3Ny Yy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190 b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jcGx1cy1kZW0uYw0KY2MgLU8gLXBpcGUgLUku IC1ESU5fR0NDIC1ESEFWRV9DT05GSUdfSCAtRFBSRUZJWD1cIi91c3JcIiAtSS91c3Ivb2JqL3Vz ci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUv dXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2Nj L2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v Y2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnIC1ER0VORVJBVE9SX0ZJ TEUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9keW4tc3Ry aW5nLmMNCmNjIC1PIC1waXBlIC1JLiAtRElOX0dDQyAtREhBVkVfQ09ORklHX0ggLURQUkVGSVg9 XCIvdXNyXCIgLUkvdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2Nj X3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYyAt SS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2Nj L2NvbmZpZyAtREdFTkVSQVRPUl9GSUxFICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kv dXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4v Li4vY29udHJpYi9nY2MvZXJyb3JzLmMNCmNjIC1PIC1waXBlIC1JLiAtRElOX0dDQyAtREhBVkVf Q09ORklHX0ggLURQUkVGSVg9XCIvdXNyXCIgLUkvdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmlu L2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9v bHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8u Li8uLi9jb250cmliL2djYyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4u Ly4uLy4uL2NvbnRyaWIvZ2NjL2NvbmZpZyAtREdFTkVSQVRPUl9GSUxFICAtSS91c3Ivb2JqL3Vz ci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvZ251L3Vzci5iaW4vY2Mv Y2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvZmliaGVhcC5jDQpjYyAtTyAtcGlwZSAt SS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJR19IIC1EUFJFRklYPVwiL3VzclwiIC1JL3Vzci9vYmov dXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2du dS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v Y2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcgLURHRU5FUkFUT1Jf RklMRSAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Iv c3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2dldHB3 ZC5jDQpjYyAtTyAtcGlwZSAtSS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJR19IIC1EUFJFRklYPVwi L3VzclwiIC1JL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190 b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vz ci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MgLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9j b25maWcgLURHRU5FUkFUT1JfRklMRSAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vz ci9pbmNsdWRlIC1jIC91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4u L2NvbnRyaWIvZ2NjL2dldHJ1bnRpbWUuYw0KY2MgLU8gLXBpcGUgLUkuIC1ESU5fR0NDIC1ESEFW RV9DT05GSUdfSCAtRFBSRUZJWD1cIi91c3JcIiAtSS91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5i aW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190 b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4u Ly4uLy4uL2NvbnRyaWIvZ2NjIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4v Li4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnIC1ER0VORVJBVE9SX0ZJTEUgIC1JL3Vzci9vYmov dXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9j Yy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9oYXNodGFiLmMNCmNjIC1PIC1waXBl IC1JLiAtRElOX0dDQyAtREhBVkVfQ09ORklHX0ggLURQUkVGSVg9XCIvdXNyXCIgLUkvdXNyL29i ai91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMv Z251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYyAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NvbmZpZyAtREdFTkVSQVRP Ul9GSUxFICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vz ci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvaGV4 LmMNCmNjIC1PIC1waXBlIC1JLiAtRElOX0dDQyAtREhBVkVfQ09ORklHX0ggLURQUkVGSVg9XCIv dXNyXCIgLUkvdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rv b2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYyAtSS91 c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2Nv bmZpZyAtREdFTkVSQVRPUl9GSUxFICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNy L2luY2x1ZGUgLWMgL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4v Y29udHJpYi9nY2MvbGJhc2VuYW1lLmMNCmNjIC1PIC1waXBlIC1JLiAtRElOX0dDQyAtREhBVkVf Q09ORklHX0ggLURQUkVGSVg9XCIvdXNyXCIgLUkvdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmlu L2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9v bHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8u Li8uLi9jb250cmliL2djYyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4u Ly4uLy4uL2NvbnRyaWIvZ2NjL2NvbmZpZyAtREdFTkVSQVRPUl9GSUxFICAtSS91c3Ivb2JqL3Vz ci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvZ251L3Vzci5iaW4vY2Mv Y2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvbWFrZS10ZW1wLWZpbGUuYw0KY2MgLU8g LXBpcGUgLUkuIC1ESU5fR0NDIC1ESEFWRV9DT05GSUdfSCAtRFBSRUZJWD1cIi91c3JcIiAtSS91 c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjIC1JL3Vzci9zcmMvZ251 L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnIC1ER0VO RVJBVE9SX0ZJTEUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAt YyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2dj Yy9tZDUuYw0KY2MgLU8gLXBpcGUgLUkuIC1ESU5fR0NDIC1ESEFWRV9DT05GSUdfSCAtRFBSRUZJ WD1cIi91c3JcIiAtSS91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4v Y2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAt SS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2Nj IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9n Y2MvY29uZmlnIC1ER0VORVJBVE9SX0ZJTEUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2Fj eS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8u Li8uLi9jb250cmliL2djYy9vYnN0YWNrLmMNCmNjIC1PIC1waXBlIC1JLiAtRElOX0dDQyAtREhB VkVfQ09ORklHX0ggLURQUkVGSVg9XCIvdXNyXCIgLUkvdXNyL29iai91c3Ivc3JjL2dudS91c3Iu YmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2Nf dG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8u Li8uLi8uLi9jb250cmliL2djYyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4u Ly4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NvbmZpZyAtREdFTkVSQVRPUl9GSUxFICAtSS91c3Ivb2Jq L3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvZ251L3Vzci5iaW4v Y2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvcGFydGl0aW9uLmMNCmNjIC1PIC1w aXBlIC1JLiAtRElOX0dDQyAtREhBVkVfQ09ORklHX0ggLURQUkVGSVg9XCIvdXNyXCIgLUkvdXNy L29iai91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9z cmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNy LmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYyAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NvbmZpZyAtREdFTkVS QVRPUl9GSUxFICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMg L3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2Mv cGV4ZWN1dGUuYw0KY2MgLU8gLXBpcGUgLUkuIC1ESU5fR0NDIC1ESEFWRV9DT05GSUdfSCAtRFBS RUZJWD1cIi91c3JcIiAtSS91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMv Li4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29s cyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIv Z2NjIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJp Yi9nY2MvY29uZmlnIC1ER0VORVJBVE9SX0ZJTEUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xl Z2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8u Li8uLi8uLi9jb250cmliL2djYy9waHlzbWVtLmMNCmNjIC1PIC1waXBlIC1JLiAtRElOX0dDQyAt REhBVkVfQ09ORklHX0ggLURQUkVGSVg9XCIvdXNyXCIgLUkvdXNyL29iai91c3Ivc3JjL2dudS91 c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2Mv Y2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8u Li8uLi8uLi8uLi9jb250cmliL2djYyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xz Ly4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NvbmZpZyAtREdFTkVSQVRPUl9GSUxFICAtSS91c3Iv b2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvZ251L3Vzci5i aW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2Mvc3BsYXktdHJlZS5jDQpjYyAt TyAtcGlwZSAtSS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJR19IIC1EUFJFRklYPVwiL3VzclwiIC1J L3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91 c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251 L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MgLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcgLURH RU5FUkFUT1JfRklMRSAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRl IC1jIC91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIv Z2NjL3hleGl0LmMNCmNjIC1PIC1waXBlIC1JLiAtRElOX0dDQyAtREhBVkVfQ09ORklHX0ggLURQ UkVGSVg9XCIvdXNyXCIgLUkvdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xz Ly4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9v bHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmli L2djYyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRy aWIvZ2NjL2NvbmZpZyAtREdFTkVSQVRPUl9GSUxFICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9s ZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4v Li4vLi4vLi4vY29udHJpYi9nY2MveG1hbGxvYy5jDQpjYyAtTyAtcGlwZSAtSS4gLURJTl9HQ0Mg LURIQVZFX0NPTkZJR19IIC1EUFJFRklYPVwiL3VzclwiIC1JL3Vzci9vYmovdXNyL3NyYy9nbnUv dXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2Nj L2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMv Li4vLi4vLi4vLi4vY29udHJpYi9nY2MgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29s cy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcgLURHRU5FUkFUT1JfRklMRSAgLUkvdXNy L29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2dudS91c3Iu YmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL3htZW1kdXAuYw0KY2MgLU8g LXBpcGUgLUkuIC1ESU5fR0NDIC1ESEFWRV9DT05GSUdfSCAtRFBSRUZJWD1cIi91c3JcIiAtSS91 c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjIC1JL3Vzci9zcmMvZ251 L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnIC1ER0VO RVJBVE9SX0ZJTEUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAt YyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2dj Yy94c3RyZHVwLmMNCmNjIC1PIC1waXBlIC1JLiAtRElOX0dDQyAtREhBVkVfQ09ORklHX0ggLURQ UkVGSVg9XCIvdXNyXCIgLUkvdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xz Ly4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9v bHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmli L2djYyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRy aWIvZ2NjL2NvbmZpZyAtREdFTkVSQVRPUl9GSUxFICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9s ZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4v Li4vLi4vLi4vY29udHJpYi9nY2MveHN0cmVycm9yLmMNCnJhbmxpYiBsaWJpYmVydHkuYQ0KY2Mg LU8gLXBpcGUgLUkuIC1ESU5fR0NDIC1ESEFWRV9DT05GSUdfSCAtRFBSRUZJWD1cIi91c3JcIiAt SS91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2du dS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjIC1JL3Vzci9zcmMv Z251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnIC1E R0VORVJBVE9SX0ZJTEUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVk ZSAgLUwvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9saWIgLW8gZ2VubW9kZXMgZ2Vu bW9kZXMubyBsaWJpYmVydHkuYQ0KLi9nZW5tb2RlcyAtaCA+IGluc24tbW9kZXMuaA0KY2MgLU8g LXBpcGUgLUkuIC1ESU5fR0NDIC1ESEFWRV9DT05GSUdfSCAtRFBSRUZJWD1cIi91c3JcIiAtSS91 c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjIC1JL3Vzci9zcmMvZ251 L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnIC1ER0VO RVJBVE9SX0ZJTEUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAt YyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2dj Yy9nZW5nZW5ydGwuYw0KY2MgLU8gLXBpcGUgLUkuIC1ESU5fR0NDIC1ESEFWRV9DT05GSUdfSCAt RFBSRUZJWD1cIi91c3JcIiAtSS91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9v bHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190 b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRy aWIvZ2NjIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29u dHJpYi9nY2MvY29uZmlnIC1ER0VORVJBVE9SX0ZJTEUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2 L2xlZ2FjeS91c3IvaW5jbHVkZSAgLUwvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9s aWIgLW8gZ2VuZ2VucnRsIGdlbmdlbnJ0bC5vIGxpYmliZXJ0eS5hDQouL2dlbmdlbnJ0bCA+IGdl bnJ0bC5jDQouL2dlbmdlbnJ0bCAtaCA+IGdlbnJ0bC5oDQpjYyAtTyAtcGlwZSAtSS4gLURJTl9H Q0MgLURIQVZFX0NPTkZJR19IIC1EUFJFRklYPVwiL3VzclwiIC1JL3Vzci9vYmovdXNyL3NyYy9n bnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmlu L2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9v bHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190 b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcgLURHRU5FUkFUT1JfRklMRSAgLUkv dXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2dudS91 c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2dlbmF0dHIuYw0KY2Mg LU8gLXBpcGUgLUkuIC1ESU5fR0NDIC1ESEFWRV9DT05GSUdfSCAtRFBSRUZJWD1cIi91c3JcIiAt SS91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2du dS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjIC1JL3Vzci9zcmMv Z251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnIC1E R0VORVJBVE9SX0ZJTEUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVk ZSAtYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmli L2djYy9nZW5ndHlwZS5jDQp5YWNjIC1kIC1vIGdlbmd0eXBlLXlhY2MuYyAvdXNyL3NyYy9nbnUv dXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9nZW5ndHlwZS15YWNj LnkNCmNhdCAgICBnZW5ndHlwZS15YWNjLmMgPiBnZW5ndHlwZS15YWNjKyVESUtFRC5jDQpzZWQg LWUgInMveG1hbGxvYy9tYWxsb2MvZyIgIC1lICJzL3hyZWFsbG9jL3JlYWxsb2MvZyIgIC1lICJz L21hbGxvYy94bWFsbG9jL2ciICAtZSAicy9yZWFsbG9jL3hyZWFsbG9jL2ciICBnZW5ndHlwZS15 YWNjLmMgPiBnZW5ndHlwZS15YWNjKyVESUtFRC5jDQpjYyAtTyAtcGlwZSAtSS4gLURJTl9HQ0Mg LURIQVZFX0NPTkZJR19IIC1EUFJFRklYPVwiL3VzclwiIC1JL3Vzci9vYmovdXNyL3NyYy9nbnUv dXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2Nj L2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMv Li4vLi4vLi4vLi4vY29udHJpYi9nY2MgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29s cy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcgLURHRU5FUkFUT1JfRklMRSAgLUkvdXNy L29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIGdlbmd0eXBlLXlhY2MrJURJ S0VELmMNCmxleCAtdCAgL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4v Li4vY29udHJpYi9nY2MvZ2VuZ3R5cGUtbGV4LmwgfCAgc2VkICdzL15cKGNoYXIgbXNnXFtcXTtc KS95eWNvbnN0IFwxLycgPiBnZW5ndHlwZS1sZXguYw0KY2MgLU8gLXBpcGUgLUkuIC1ESU5fR0ND IC1ESEFWRV9DT05GSUdfSCAtRFBSRUZJWD1cIi91c3JcIiAtSS91c3Ivb2JqL3Vzci9zcmMvZ251 L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9j Yy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xz Ly4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9v bHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnIC1ER0VORVJBVE9SX0ZJTEUgIC1JL3Vz ci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyBnZW5ndHlwZS1sZXguYw0K Y2MgLU8gLXBpcGUgLUkuIC1ESU5fR0NDIC1ESEFWRV9DT05GSUdfSCAtRFBSRUZJWD1cIi91c3Jc IiAtSS91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMg LUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3Jj L2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjIC1JL3Vzci9z cmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmln IC1ER0VORVJBVE9SX0ZJTEUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5j bHVkZSAgLUwvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9saWIgLW8gZ2VuZ3R5cGUg Z2VuZ3R5cGUubyBnZW5ndHlwZS15YWNjKyVESUtFRC5vIGdlbmd0eXBlLWxleC5vIGxpYmliZXJ0 eS5hDQouL2dlbmd0eXBlDQp3YXJuaW5nOiBzdHJ1Y3R1cmUgYHJlZ19pbmZvX2RlZicgdXNlZCBi dXQgbm90IGRlZmluZWQNCndhcm5pbmc6IHN0cnVjdHVyZSBgYmFzaWNfYmxvY2tfZGVmJyB1c2Vk IGJ1dCBub3QgZGVmaW5lZA0Kd2FybmluZzogc3RydWN0dXJlIGBhbnN3ZXInIHVzZWQgYnV0IG5v dCBkZWZpbmVkDQp3YXJuaW5nOiBzdHJ1Y3R1cmUgYGNwcF9tYWNybycgdXNlZCBidXQgbm90IGRl ZmluZWQNCndhcm5pbmc6IHN0cnVjdHVyZSBgcmVnX2luZm9fZGVmJyB1c2VkIGJ1dCBub3QgZGVm aW5lZA0Kd2FybmluZzogc3RydWN0dXJlIGBiYXNpY19ibG9ja19kZWYnIHVzZWQgYnV0IG5vdCBk ZWZpbmVkDQp3YXJuaW5nOiBzdHJ1Y3R1cmUgYGFuc3dlcicgdXNlZCBidXQgbm90IGRlZmluZWQN Cndhcm5pbmc6IHN0cnVjdHVyZSBgY3BwX21hY3JvJyB1c2VkIGJ1dCBub3QgZGVmaW5lZA0KdG91 Y2ggZ3R5cGUtdGltZS1zdGFtcA0KY2MgLU8gLXBpcGUgLUkuIC1ESU5fR0NDIC1ESEFWRV9DT05G SUdfSCAtRFBSRUZJWD1cIi91c3JcIiAtSS91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY2Mv Y2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8u Li9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4u L2NvbnRyaWIvZ2NjIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4v Li4vY29udHJpYi9nY2MvY29uZmlnIC1ER0VORVJBVE9SX0ZJTEUgIC1JL3Vzci9vYmovdXNyL3Ny Yy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190 b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9ydGwuYw0KY2MgLU8gLXBpcGUgLUkuIC1ESU5f R0NDIC1ESEFWRV9DT05GSUdfSCAtRFBSRUZJWD1cIi91c3JcIiAtSS91c3Ivb2JqL3Vzci9zcmMv Z251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rv b2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2Nf dG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnIC1ER0VORVJBVE9SX0ZJTEUgIC1J L3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9nbnUv dXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9nZW5wcmVkcy5jDQpj YyAtTyAtcGlwZSAtSS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJR19IIC1EUFJFRklYPVwiL3Vzclwi IC1JL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAt SS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMv Z251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MgLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcg LURHRU5FUkFUT1JfRklMRSAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNs dWRlICAtTC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2xpYiAtbyBnZW5wcmVkcyBn ZW5wcmVkcy5vIGxpYmliZXJ0eS5hDQouL2dlbnByZWRzID4gdG0tcHJlZHMuaA0KY2MgLU8gLXBp cGUgLUkuIC1ESU5fR0NDIC1ESEFWRV9DT05GSUdfSCAtRFBSRUZJWD1cIi91c3JcIiAtSS91c3Iv b2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnIC1ER0VORVJB VE9SX0ZJTEUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAv dXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9n ZW5jaGVjay5jDQpjYyAtTyAtcGlwZSAtSS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJR19IIC1EUFJF RklYPVwiL3VzclwiIC1JL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8u Li9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xz IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9n Y2MgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmli L2djYy9jb25maWcgLURHRU5FUkFUT1JfRklMRSAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVn YWN5L3Vzci9pbmNsdWRlICAtTC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2xpYiAt byBnZW5jaGVjayBnZW5jaGVjay5vIGxpYmliZXJ0eS5hDQouL2dlbmNoZWNrID4gdHJlZS1jaGVj ay5oDQpjYyAtTyAtcGlwZSAtSS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJR19IIC1EUFJFRklYPVwi L3VzclwiIC1JL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190 b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vz ci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MgLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9j b25maWcgLURHRU5FUkFUT1JfRklMRSAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vz ci9pbmNsdWRlIC1jIC91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4u L2NvbnRyaWIvZ2NjL3ByaW50LXJ0bC5jDQpjYyAtTyAtcGlwZSAtSS4gLURJTl9HQ0MgLURIQVZF X0NPTkZJR19IIC1EUFJFRklYPVwiL3VzclwiIC1JL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJp bi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rv b2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4v Li4vLi4vY29udHJpYi9nY2MgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8u Li8uLi8uLi9jb250cmliL2djYy9jb25maWcgLURHRU5FUkFUT1JfRklMRSAgLUkvdXNyL29iai91 c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2dudS91c3IuYmluL2Nj L2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2JpdG1hcC5jDQpjYyAtTyAtcGlwZSAt SS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJR19IIC1EUFJFRklYPVwiL3VzclwiIC1JL3Vzci9vYmov dXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2du dS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v Y2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcgLURHRU5FUkFUT1Jf RklMRSAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Iv c3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2dlbnN1 cHBvcnQuYw0KY2MgLU8gLXBpcGUgLUkuIC1ESU5fR0NDIC1ESEFWRV9DT05GSUdfSCAtRFBSRUZJ WD1cIi91c3JcIiAtSS91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4v Y2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAt SS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2Nj IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9n Y2MvY29uZmlnIC1ER0VORVJBVE9SX0ZJTEUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2Fj eS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8u Li8uLi9jb250cmliL2djYy9nZ2Mtbm9uZS5jDQpjYyAtTyAtcGlwZSAtSS4gLURJTl9HQ0MgLURI QVZFX0NPTkZJR19IIC1EUFJFRklYPVwiL3VzclwiIC1JL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNy LmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2Nj X3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4v Li4vLi4vLi4vY29udHJpYi9nY2MgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8u Li8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcgLURHRU5FUkFUT1JfRklMRSAgLUkvdXNyL29i ai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2dudS91c3IuYmlu L2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL3JlYWQtcnRsLmMNCmNjIC1PIC1w aXBlIC1JLiAtRElOX0dDQyAtREhBVkVfQ09ORklHX0ggLURQUkVGSVg9XCIvdXNyXCIgLUkvdXNy L29iai91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9z cmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNy LmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYyAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NvbmZpZyAtREdFTkVS QVRPUl9GSUxFICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMg L3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2Mv Z2VuY29uZGl0aW9ucy5jDQpjYyAtTyAtcGlwZSAtSS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJR19I IC1EUFJFRklYPVwiL3VzclwiIC1JL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190 b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2Nj X3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29u dHJpYi9nY2MgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9j b250cmliL2djYy9jb25maWcgLURHRU5FUkFUT1JfRklMRSAgLUkvdXNyL29iai91c3Ivc3JjL2kz ODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xz Ly4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2R1bW15LWNvbmRpdGlvbnMuYw0KLi9nZW5tb2RlcyAt bSA+IG1pbi1pbnNuLW1vZGVzLmMNCmNjIC1PIC1waXBlIC1JLiAtRElOX0dDQyAtREhBVkVfQ09O RklHX0ggLURQUkVGSVg9XCIvdXNyXCIgLUkvdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2Nj L2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMv Li4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8u Li9jb250cmliL2djYyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4u Ly4uL2NvbnRyaWIvZ2NjL2NvbmZpZyAtREdFTkVSQVRPUl9GSUxFICAtSS91c3Ivb2JqL3Vzci9z cmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgbWluLWluc24tbW9kZXMuYw0KY2MgLU8gLXBp cGUgLUkuIC1ESU5fR0NDIC1ESEFWRV9DT05GSUdfSCAtRFBSRUZJWD1cIi91c3JcIiAtSS91c3Iv b2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnIC1ER0VORVJB VE9SX0ZJTEUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAgLUwv dXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9saWIgLW8gZ2VuY29uZGl0aW9ucyBnZW5j b25kaXRpb25zLm8gcnRsLm8gYml0bWFwLm8gZ2Vuc3VwcG9ydC5vIGdnYy1ub25lLm8gcmVhZC1y dGwubyBkdW1teS1jb25kaXRpb25zLm8gbWluLWluc24tbW9kZXMubyBsaWJpYmVydHkuYQ0KLi9n ZW5jb25kaXRpb25zIC91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4u L2NvbnRyaWIvZ2NjL2NvbmZpZy9pMzg2L2kzODYubWQgPiBpbnNuLWNvbmRpdGlvbnMuYw0KY2Mg LU8gLXBpcGUgLUkuIC1ESU5fR0NDIC1ESEFWRV9DT05GSUdfSCAtRFBSRUZJWD1cIi91c3JcIiAt SS91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2du dS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjIC1JL3Vzci9zcmMv Z251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnIC1E R0VORVJBVE9SX0ZJTEUgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVk ZSAtYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmli L2djYy9nZW5jb25zdGFudHMuYw0KY2MgLU8gLXBpcGUgLUkuIC1ESU5fR0NDIC1ESEFWRV9DT05G SUdfSCAtRFBSRUZJWD1cIi91c3JcIiAtSS91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY2Mv Y2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8u Li9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4u L2NvbnRyaWIvZ2NjIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4v Li4vY29udHJpYi9nY2MvY29uZmlnIC1ER0VORVJBVE9SX0ZJTEUgIC1JL3Vzci9vYmovdXNyL3Ny Yy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAgLUwvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5 L3Vzci9saWIgLW8gZ2VuY29uc3RhbnRzIGdlbmNvbnN0YW50cy5vIHJ0bC5vIGJpdG1hcC5vIGdl bnN1cHBvcnQubyBnZ2Mtbm9uZS5vIHJlYWQtcnRsLm8gZHVtbXktY29uZGl0aW9ucy5vIG1pbi1p bnNuLW1vZGVzLm8gbGliaWJlcnR5LmENCi4vZ2VuY29uc3RhbnRzIC91c3Ivc3JjL2dudS91c3Iu YmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NvbmZpZy9pMzg2L2kzODYu bWQgPiBpbnNuLWNvbnN0YW50cy5oDQpjYyAtTyAtcGlwZSAtSS4gLURJTl9HQ0MgLURIQVZFX0NP TkZJR19IIC1EUFJFRklYPVwiL3VzclwiIC1JL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9j Yy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xz Ly4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4v Li4vY29udHJpYi9nY2MgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8u Li8uLi9jb250cmliL2djYy9jb25maWcgLURHRU5FUkFUT1JfRklMRSAgLUkvdXNyL29iai91c3Iv c3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIGluc24tY29uZGl0aW9ucy5jDQpjYyAtTyAt cGlwZSAtSS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJR19IIC1EUFJFRklYPVwiL3VzclwiIC1JL3Vz ci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Iv c3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MgLUkvdXNyL3NyYy9nbnUv dXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcgLURHRU5F UkFUT1JfRklMRSAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlICAt TC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2xpYiAtbyBnZW5hdHRyIGdlbmF0dHIu byBydGwubyBwcmludC1ydGwubyBiaXRtYXAubyBnZW5zdXBwb3J0Lm8gZ2djLW5vbmUubyByZWFk LXJ0bC5vIGluc24tY29uZGl0aW9ucy5vIG1pbi1pbnNuLW1vZGVzLm8gbGliaWJlcnR5LmENCmNj IC1PIC1waXBlIC1JLiAtRElOX0dDQyAtREhBVkVfQ09ORklHX0ggLURQUkVGSVg9XCIvdXNyXCIg LUkvdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYyAtSS91c3Ivc3Jj L2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NvbmZpZyAt REdFTkVSQVRPUl9GSUxFICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1 ZGUgLWMgL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJp Yi9nY2MvZ2VuY29kZXMuYw0KY2MgLU8gLXBpcGUgLUkuIC1ESU5fR0NDIC1ESEFWRV9DT05GSUdf SCAtRFBSRUZJWD1cIi91c3JcIiAtSS91c3Ivb2JqL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2Nf dG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9j Y190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2Nv bnRyaWIvZ2NjIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4v Y29udHJpYi9nY2MvY29uZmlnIC1ER0VORVJBVE9SX0ZJTEUgIC1JL3Vzci9vYmovdXNyL3NyYy9p Mzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAgLUwvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vz ci9saWIgLW8gZ2VuY29kZXMgZ2VuY29kZXMubyBydGwubyBwcmludC1ydGwubyBiaXRtYXAubyBn ZW5zdXBwb3J0Lm8gZ2djLW5vbmUubyByZWFkLXJ0bC5vIGluc24tY29uZGl0aW9ucy5vIG1pbi1p bnNuLW1vZGVzLm8gbGliaWJlcnR5LmENCmNjIC1PIC1waXBlIC1JLiAtRElOX0dDQyAtREhBVkVf Q09ORklHX0ggLURQUkVGSVg9XCIvdXNyXCIgLUkvdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmlu L2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9v bHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8u Li8uLi9jb250cmliL2djYyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4u Ly4uLy4uL2NvbnRyaWIvZ2NjL2NvbmZpZyAtREdFTkVSQVRPUl9GSUxFICAtSS91c3Ivb2JqL3Vz ci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvZ251L3Vzci5iaW4vY2Mv Y2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvZ2VuY29uZmlnLmMNCmNjIC1PIC1waXBl IC1JLiAtRElOX0dDQyAtREhBVkVfQ09ORklHX0ggLURQUkVGSVg9XCIvdXNyXCIgLUkvdXNyL29i ai91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMv Z251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYyAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NvbmZpZyAtREdFTkVSQVRP Ul9GSUxFICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgIC1ML3Vz ci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvbGliIC1vIGdlbmNvbmZpZyBnZW5jb25maWcu byBydGwubyBwcmludC1ydGwubyBiaXRtYXAubyBnZW5zdXBwb3J0Lm8gZ2djLW5vbmUubyByZWFk LXJ0bC5vIGluc24tY29uZGl0aW9ucy5vIG1pbi1pbnNuLW1vZGVzLm8gbGliaWJlcnR5LmENCmNj IC1PIC1waXBlIC1JLiAtRElOX0dDQyAtREhBVkVfQ09ORklHX0ggLURQUkVGSVg9XCIvdXNyXCIg LUkvdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYyAtSS91c3Ivc3Jj L2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NvbmZpZyAt REdFTkVSQVRPUl9GSUxFICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1 ZGUgLWMgL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJp Yi9nY2MvZ2VuZW1pdC5jDQpjYyAtTyAtcGlwZSAtSS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJR19I IC1EUFJFRklYPVwiL3VzclwiIC1JL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190 b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2Nj X3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29u dHJpYi9nY2MgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9j b250cmliL2djYy9jb25maWcgLURHRU5FUkFUT1JfRklMRSAgLUkvdXNyL29iai91c3Ivc3JjL2kz ODYvbGVnYWN5L3Vzci9pbmNsdWRlICAtTC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNy L2xpYiAtbyBnZW5lbWl0IGdlbmVtaXQubyBydGwubyBwcmludC1ydGwubyBiaXRtYXAubyBnZW5z dXBwb3J0Lm8gZ2djLW5vbmUubyByZWFkLXJ0bC5vIGluc24tY29uZGl0aW9ucy5vIG1pbi1pbnNu LW1vZGVzLm8gbGliaWJlcnR5LmENCi4vZ2VuY29uZmlnIC91c3Ivc3JjL2dudS91c3IuYmluL2Nj L2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NvbmZpZy9pMzg2L2kzODYubWQgPiBp bnNuLWNvbmZpZy5oDQpjYyAtTyAtcGlwZSAtSS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJR19IIC1E UFJFRklYPVwiL3VzclwiIC1JL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29s cy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rv b2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJp Yi9nY2MgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250 cmliL2djYy9jb25maWcgLURHRU5FUkFUT1JfRklMRSAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYv bGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4u Ly4uLy4uLy4uL2NvbnRyaWIvZ2NjL2dlbmV4dHJhY3QuYw0KY2MgLU8gLXBpcGUgLUkuIC1ESU5f R0NDIC1ESEFWRV9DT05GSUdfSCAtRFBSRUZJWD1cIi91c3JcIiAtSS91c3Ivb2JqL3Vzci9zcmMv Z251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rv b2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2Nf dG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnIC1ER0VORVJBVE9SX0ZJTEUgIC1J L3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAgLUwvdXNyL29iai91c3Iv c3JjL2kzODYvbGVnYWN5L3Vzci9saWIgLW8gZ2VuZXh0cmFjdCBnZW5leHRyYWN0Lm8gcnRsLm8g cHJpbnQtcnRsLm8gYml0bWFwLm8gZ2Vuc3VwcG9ydC5vIGdnYy1ub25lLm8gcmVhZC1ydGwubyBp bnNuLWNvbmRpdGlvbnMubyBtaW4taW5zbi1tb2Rlcy5vIGxpYmliZXJ0eS5hDQpjYyAtTyAtcGlw ZSAtSS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJR19IIC1EUFJFRklYPVwiL3VzclwiIC1JL3Vzci9v YmovdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3Jj L2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5i aW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MgLUkvdXNyL3NyYy9nbnUvdXNy LmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcgLURHRU5FUkFU T1JfRklMRSAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91 c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2dl bmZsYWdzLmMNCmNjIC1PIC1waXBlIC1JLiAtRElOX0dDQyAtREhBVkVfQ09ORklHX0ggLURQUkVG SVg9XCIvdXNyXCIgLUkvdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4u L2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMg LUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2dj YyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIv Z2NjL2NvbmZpZyAtREdFTkVSQVRPUl9GSUxFICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdh Y3kvdXNyL2luY2x1ZGUgIC1ML3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvbGliIC1v IGdlbmZsYWdzIGdlbmZsYWdzLm8gcnRsLm8gcHJpbnQtcnRsLm8gYml0bWFwLm8gZ2Vuc3VwcG9y dC5vIGdnYy1ub25lLm8gcmVhZC1ydGwubyBpbnNuLWNvbmRpdGlvbnMubyBtaW4taW5zbi1tb2Rl cy5vIGxpYmliZXJ0eS5hDQpjYyAtTyAtcGlwZSAtSS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJR19I IC1EUFJFRklYPVwiL3VzclwiIC1JL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190 b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2Nj X3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29u dHJpYi9nY2MgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9j b250cmliL2djYy9jb25maWcgLURHRU5FUkFUT1JfRklMRSAgLUkvdXNyL29iai91c3Ivc3JjL2kz ODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xz Ly4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2dlbm9waW5pdC5jDQpjYyAtTyAtcGlwZSAtSS4gLURJ Tl9HQ0MgLURIQVZFX0NPTkZJR19IIC1EUFJFRklYPVwiL3VzclwiIC1JL3Vzci9vYmovdXNyL3Ny Yy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2Nf dG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9j Y190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcgLURHRU5FUkFUT1JfRklMRSAg LUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlICAtTC91c3Ivb2JqL3Vz ci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2xpYiAtbyBnZW5vcGluaXQgZ2Vub3Bpbml0Lm8gcnRsLm8g cHJpbnQtcnRsLm8gYml0bWFwLm8gZ2Vuc3VwcG9ydC5vIGdnYy1ub25lLm8gcmVhZC1ydGwubyBp bnNuLWNvbmRpdGlvbnMubyBtaW4taW5zbi1tb2Rlcy5vIGxpYmliZXJ0eS5hDQpjYyAtTyAtcGlw ZSAtSS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJR19IIC1EUFJFRklYPVwiL3VzclwiIC1JL3Vzci9v YmovdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3Jj L2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5i aW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MgLUkvdXNyL3NyYy9nbnUvdXNy LmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcgLURHRU5FUkFU T1JfRklMRSAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91 c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2dl bm91dHB1dC5jDQpjYyAtTyAtcGlwZSAtSS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJR19IIC1EUFJF RklYPVwiL3VzclwiIC1JL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8u Li9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xz IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9n Y2MgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmli L2djYy9jb25maWcgLURHRU5FUkFUT1JfRklMRSAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVn YWN5L3Vzci9pbmNsdWRlICAtTC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2xpYiAt byBnZW5vdXRwdXQgZ2Vub3V0cHV0Lm8gcnRsLm8gcHJpbnQtcnRsLm8gYml0bWFwLm8gZ2Vuc3Vw cG9ydC5vIGdnYy1ub25lLm8gcmVhZC1ydGwubyBpbnNuLWNvbmRpdGlvbnMubyBtaW4taW5zbi1t b2Rlcy5vIGxpYmliZXJ0eS5hDQpjYyAtTyAtcGlwZSAtSS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJ R19IIC1EUFJFRklYPVwiL3VzclwiIC1JL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9j Y190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4u L2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4v Y29udHJpYi9nY2MgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8u Li9jb250cmliL2djYy9jb25maWcgLURHRU5FUkFUT1JfRklMRSAgLUkvdXNyL29iai91c3Ivc3Jj L2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rv b2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2dlbnBlZXAuYw0KY2MgLU8gLXBpcGUgLUkuIC1E SU5fR0NDIC1ESEFWRV9DT05GSUdfSCAtRFBSRUZJWD1cIi91c3JcIiAtSS91c3Ivb2JqL3Vzci9z cmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNy LmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2Nj X3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2Mv Y2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnIC1ER0VORVJBVE9SX0ZJTEUg IC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAgLUwvdXNyL29iai91 c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9saWIgLW8gZ2VucGVlcCBnZW5wZWVwLm8gcnRsLm8gcHJp bnQtcnRsLm8gYml0bWFwLm8gZ2Vuc3VwcG9ydC5vIGdnYy1ub25lLm8gcmVhZC1ydGwubyBpbnNu LWNvbmRpdGlvbnMubyBtaW4taW5zbi1tb2Rlcy5vIGxpYmliZXJ0eS5hDQpjYyAtTyAtcGlwZSAt SS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJR19IIC1EUFJFRklYPVwiL3VzclwiIC1JL3Vzci9vYmov dXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2du dS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v Y2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcgLURHRU5FUkFUT1Jf RklMRSAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Iv c3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2dlbnJl Y29nLmMNCmNjIC1PIC1waXBlIC1JLiAtRElOX0dDQyAtREhBVkVfQ09ORklHX0ggLURQUkVGSVg9 XCIvdXNyXCIgLUkvdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2Nj X3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYyAt SS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2Nj L2NvbmZpZyAtREdFTkVSQVRPUl9GSUxFICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kv dXNyL2luY2x1ZGUgIC1ML3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvbGliIC1vIGdl bnJlY29nIGdlbnJlY29nLm8gcnRsLm8gcHJpbnQtcnRsLm8gYml0bWFwLm8gZ2Vuc3VwcG9ydC5v IGdnYy1ub25lLm8gcmVhZC1ydGwubyBpbnNuLWNvbmRpdGlvbnMubyBtaW4taW5zbi1tb2Rlcy5v IGxpYmliZXJ0eS5hDQpjYyAtTyAtcGlwZSAtSS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJR19IIC1E UFJFRklYPVwiL3VzclwiIC1JL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29s cy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rv b2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJp Yi9nY2MgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250 cmliL2djYy9jb25maWcgLURHRU5FUkFUT1JfRklMRSAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYv bGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4u Ly4uLy4uLy4uL2NvbnRyaWIvZ2NjL2dlbmF0dHJ0YWIuYw0KY2MgLU8gLXBpcGUgLUkuIC1ESU5f R0NDIC1ESEFWRV9DT05GSUdfSCAtRFBSRUZJWD1cIi91c3JcIiAtSS91c3Ivb2JqL3Vzci9zcmMv Z251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi9jYy9jY190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rv b2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2Nf dG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnIC1ER0VORVJBVE9SX0ZJTEUgIC1J L3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9nbnUv dXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9nZW5hdXRvbWF0YS5j DQpjYyAtTyAtcGlwZSAtSS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJR19IIC1EUFJFRklYPVwiL3Vz clwiIC1JL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi9jY190b29s cyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9z cmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MgLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25m aWcgLURHRU5FUkFUT1JfRklMRSAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9p bmNsdWRlIC1jIC91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2Nv bnRyaWIvZ2NjL3ZhcnJheS5jDQpjYyAtTyAtcGlwZSAtSS4gLURJTl9HQ0MgLURIQVZFX0NPTkZJ R19IIC1EUFJFRklYPVwiL3VzclwiIC1JL3Vzci9vYmovdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9j Y190b29scy8uLi9jY190b29scyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4u L2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4v Y29udHJpYi9nY2MgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8u Li9jb250cmliL2djYy9jb25maWcgLURHRU5FUkFUT1JfRklMRSAgLUkvdXNyL29iai91c3Ivc3Jj L2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlICAtTC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kv dXNyL2xpYiAtbyBnZW5hdHRydGFiIGdlbmF0dHJ0YWIubyBydGwubyBwcmludC1ydGwubyBiaXRt YXAubyBnZW5zdXBwb3J0Lm8gZ2djLW5vbmUubyByZWFkLXJ0bC5vIGluc24tY29uZGl0aW9ucy5v IGdlbmF1dG9tYXRhLm8gdmFycmF5Lm8gbWluLWluc24tbW9kZXMubyBsaWJpYmVydHkuYSAtbG0N CmNjIC1PIC1waXBlIC1JLiAtRElOX0dDQyAtREhBVkVfQ09ORklHX0ggLURQUkVGSVg9XCIvdXNy XCIgLUkvdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uL2NjX3Rvb2xz IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vY2NfdG9vbHMgLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYyAtSS91c3Iv c3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NvbmZp ZyAtREdFTkVSQVRPUl9GSUxFICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2lu Y2x1ZGUgLWMgL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29u dHJpYi9nY2MvZi9maW5pLmMNCmNjIC1PIC1waXBlIC1JLiAtRElOX0dDQyAtREhBVkVfQ09ORklH X0ggLURQUkVGSVg9XCIvdXNyXCIgLUkvdXNyL29iai91c3Ivc3JjL2dudS91c3IuYmluL2NjL2Nj X3Rvb2xzLy4uL2NjX3Rvb2xzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4v Y2NfdG9vbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9j b250cmliL2djYyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4u L2NvbnRyaWIvZ2NjL2NvbmZpZyAtREdFTkVSQVRPUl9GSUxFICAtSS91c3Ivb2JqL3Vzci9zcmMv aTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgIC1ML3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91 c3IvbGliIC1vIGZpbmkgZmluaS5vIGxpYmliZXJ0eS5hDQovYmluL3NoIC91c3Ivc3JjL2dudS91 c3IuYmluL2NjL2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL29wdHMuc2ggbXYgb3B0 aW9ucy5jIG9wdGlvbnMuaCAvdXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8u Li8uLi9jb250cmliL2djYy9mL2xhbmcub3B0IC91c3Ivc3JjL2dudS91c3IuYmluL2NjL2NjX3Rv b2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2Mub3B0IC91c3Ivc3JjL2dudS91c3IuYmluL2Nj L2NjX3Rvb2xzLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ2NjL2NvbW1vbi5vcHQNCi4vZ2VuYXR0ciAv dXNyL3NyYy9nbnUvdXNyLmJpbi9jYy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9j b25maWcvaTM4Ni9pMzg2Lm1kID4gaW5zbi1hdHRyLmgNCi4vZ2VuY29kZXMgL3Vzci9zcmMvZ251 L3Vzci5iaW4vY2MvY2NfdG9vbHMvLi4vLi4vLi4vLi4vY29udHJpYi9nY2MvY29uZmlnL2kzODYv aTM4Ni5tZCA+IGluc24tY29kZXMuaA0KLi9nZW5mbGFncyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9j Yy9jY190b29scy8uLi8uLi8uLi8uLi9jb250cmliL2djYy9jb25maWcvaTM4Ni9pMzg2Lm1kID4g aW5zbi1mbGFncy5oDQp0b3VjaCBnZW4tdGltZS1zdGFtcA0KLi9nZW5tb2RlcyA+IGluc24tbW9k ZXMuYw0KPT09PiBsaWIvbGlibmN1cnNlcw0Kc2ggL3Vzci9zcmMvbGliL2xpYm5jdXJzZXMvLi4v Li4vY29udHJpYi9uY3Vyc2VzL2luY2x1ZGUvTUtoYXNoc2l6ZS5zaCAvdXNyL3NyYy9saWIvbGli bmN1cnNlcy8uLi8uLi9jb250cmliL25jdXJzZXMvaW5jbHVkZS9DYXBzID4gaGFzaHNpemUuaA0K QVdLPWF3ayBzaCAvdXNyL3NyYy9saWIvbGlibmN1cnNlcy8uLi8uLi9jb250cmliL25jdXJzZXMv aW5jbHVkZS9NS25jdXJzZXNfZGVmLnNoICAvdXNyL3NyYy9saWIvbGlibmN1cnNlcy8uLi8uLi9j b250cmliL25jdXJzZXMvaW5jbHVkZS9uY3Vyc2VzX2RlZnMgPiBuY3Vyc2VzX2RlZi5oDQpzZWQg PC91c3Ivc3JjL2xpYi9saWJuY3Vyc2VzLy4uLy4uL2NvbnRyaWIvbmN1cnNlcy9pbmNsdWRlL2N1 cnNlcy5oLmluID5jdXJzZXMuaGVhZCAgLWUgIi9AQlJPS0VOX0xJTktFUkAvcyUlMCUiICAtZSAi L0BIQVZFX1ZTU0NBTkZAL3MlJTElIiAgLWUgIi9ATkNVUlNFU19DT05TVEAvcyUlY29uc3QlIiAg LWUgIi9ATkNVUlNFU19NQUpPUkAvcyUlNSUiICAtZSAiL0BOQ1VSU0VTX01JTk9SQC9zJSUyJSIg IC1lICIvQE5DVVJTRVNfUEFUQ0hAL3MlJTIwMDIwNjE1JSIgIC1lICIvQE5DVVJTRVNfQ0hfVEAv cyUlY2h0eXBlJSIgIC1lICIvQE5DVVJTRVNfRVhUX0ZVTkNTQC9zJSUxJSIgIC1lICIvQE5DVVJT RVNfTElCVVRGOEAvcyUlMCUiICAtZSAiL0BOQ1VSU0VTX01CU1RBVEVfVEAvcyUlMCUiICAtZSAi cyVAY2ZfY3ZfMVVMQCUxVUwlZyIgIC1lICJzJUBjZl9jdl9idWlsdGluX2Jvb2xAJTElZyIgIC1l ICJzJUBjZl9jdl9jY19ib29sX3R5cGVAJTAlZyIgIC1lICJzJUBjZl9jdl9zaGlmdF9saW1pdEAl MzIlZyIgIC1lICJzJUBjZl9jdl9oZWFkZXJfc3RkYm9vbF9oQCUxJWciICAtZSAicyVAY2ZfY3Zf dHlwZV9vZl9ib29sQCV1bnNpZ25lZCBjaGFyJWciICAtZSAicyVAY2ZfY3ZfdHlwZW9mX2NodHlw ZUAlbG9uZyVnIiAgLWUgInMlQGNmX2N2X3dpZGVjX3NoaWZ0QCU4JWciICAtZSAicy8gX1dDSEFS X1QvIF9fd2NoYXJfdC9nIiAgLWUgInMvIF9XSU5UX1QvIF9fd2ludF90L2ciDQpjYXQgY3Vyc2Vz LmhlYWQgPiBjdXJzZXMuaC5uZXcNCkFXSz1hd2sgX1BPU0lYMl9WRVJTSU9OPTE5OTIwOSBzaCAv dXNyL3NyYy9saWIvbGlibmN1cnNlcy8uLi8uLi9jb250cmliL25jdXJzZXMvaW5jbHVkZS9NS2tl eV9kZWZzLnNoICAvdXNyL3NyYy9saWIvbGlibmN1cnNlcy8uLi8uLi9jb250cmliL25jdXJzZXMv aW5jbHVkZS9DYXBzID4+IGN1cnNlcy5oLm5ldw0KY2F0IC91c3Ivc3JjL2xpYi9saWJuY3Vyc2Vz Ly4uLy4uL2NvbnRyaWIvbmN1cnNlcy9pbmNsdWRlL2N1cnNlcy50YWlsID4+IGN1cnNlcy5oLm5l dw0KbXYgLWYgY3Vyc2VzLmgubmV3IGN1cnNlcy5oDQpzZWQgPC91c3Ivc3JjL2xpYi9saWJuY3Vy c2VzLy4uLy4uL2NvbnRyaWIvbmN1cnNlcy9pbmNsdWRlL01LdGVybS5oLmF3ay5pbiA+TUt0ZXJt LmguYXdrICAtZSAiL0BOQ1VSU0VTX01BSk9SQC9zJSU1JSIgIC1lICIvQE5DVVJTRVNfTUlOT1JA L3MlJTIlIiAgLWUgIi9ATkNVUlNFU19DT05TVEAvcyUlY29uc3QlIiAgLWUgIi9ATkNVUlNFU19Y TkFNRVNAL3MlJTElIg0KYXdrIC1mIE1LdGVybS5oLmF3ayAvdXNyL3NyYy9saWIvbGlibmN1cnNl cy8uLi8uLi9jb250cmliL25jdXJzZXMvaW5jbHVkZS9DYXBzID4gdGVybS5oLm5ldw0Kc2ggL3Vz ci9zcmMvbGliL2xpYm5jdXJzZXMvLi4vLi4vY29udHJpYi9uY3Vyc2VzL2luY2x1ZGUvZWRpdF9j Zmcuc2ggL3Vzci9zcmMvbGliL2xpYm5jdXJzZXMvbmN1cnNlc19jZmcuaCB0ZXJtLmgubmV3DQoq KiBlZGl0OiBIQVZFX1RDR0VUQVRUUiAxDQoqKiBlZGl0OiBIQVZFX1RFUk1JT1NfSCAxDQoqKiBl ZGl0OiBIQVZFX1RFUk1JT19IIDANCioqIGVkaXQ6IEJST0tFTl9MSU5LRVIgMA0KbXYgLWYgdGVy bS5oLm5ldyB0ZXJtLmgNCnNlZCA8L3Vzci9zcmMvbGliL2xpYm5jdXJzZXMvLi4vLi4vY29udHJp Yi9uY3Vyc2VzL2luY2x1ZGUvdGVybWNhcC5oLmluID50ZXJtY2FwLmggIC1lICIvQE5DVVJTRVNf TUFKT1JAL3MlJTUlIiAgLWUgIi9ATkNVUlNFU19NSU5PUkAvcyUlMiUiICAtZSAiL0BOQ1VSU0VT X0NPTlNUQC9zJSVjb25zdCUiICAtZSAiL0BOQ1VSU0VTX09TUEVFREAvcyUlc2hvcnQlIg0Kc2Vk IDwvdXNyL3NyYy9saWIvbGlibmN1cnNlcy8uLi8uLi9jb250cmliL25jdXJzZXMvaW5jbHVkZS91 bmN0cmwuaC5pbiA+dW5jdHJsLmggIC1lICIvQE5DVVJTRVNfTUFKT1JAL3MlJTUlIiAgLWUgIi9A TkNVUlNFU19NSU5PUkAvcyUlMiUiDQpjYyAtbyBtYWtlX2hhc2ggLU8gLXBpcGUgLUkuIC1JL3Vz ci9zcmMvbGliL2xpYm5jdXJzZXMgLUkvdXNyL3NyYy9saWIvbGlibmN1cnNlcy8uLi8uLi9jb250 cmliL25jdXJzZXMvbmN1cnNlcyAtSS91c3Ivc3JjL2xpYi9saWJuY3Vyc2VzLy4uLy4uL2NvbnRy aWIvbmN1cnNlcy9pbmNsdWRlIC1XYWxsIC1ERlJFRUJTRF9OQVRJVkUgLUROREVCVUcgLURIQVZF X0NPTkZJR19IIC1EVEVSTUlPUyAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9p bmNsdWRlIC1ETUFJTl9QUk9HUkFNICAvdXNyL3NyYy9saWIvbGlibmN1cnNlcy8uLi8uLi9jb250 cmliL25jdXJzZXMvbmN1cnNlcy90aW5mby9jb21wX2hhc2guYw0KYXdrIC1mIC91c3Ivc3JjL2xp Yi9saWJuY3Vyc2VzLy4uLy4uL2NvbnRyaWIvbmN1cnNlcy9uY3Vyc2VzL3RpbmZvL01LbmFtZXMu YXdrIC91c3Ivc3JjL2xpYi9saWJuY3Vyc2VzLy4uLy4uL2NvbnRyaWIvbmN1cnNlcy9pbmNsdWRl L0NhcHMNCmNhdCBuYW1laGRyIGJvb2xuYW1lcyBib29sZm5hbWVzIG51bW5hbWVzIG51bWZuYW1l cyBzdHJuYW1lcyBzdHJmbmFtZXMgbmFtZWZ0ciA+IG5hbWVzLmMNCmNjIC1vIG1ha2Vfa2V5cyAt TyAtcGlwZSAtSS4gLUkvdXNyL3NyYy9saWIvbGlibmN1cnNlcyAtSS91c3Ivc3JjL2xpYi9saWJu Y3Vyc2VzLy4uLy4uL2NvbnRyaWIvbmN1cnNlcy9uY3Vyc2VzIC1JL3Vzci9zcmMvbGliL2xpYm5j dXJzZXMvLi4vLi4vY29udHJpYi9uY3Vyc2VzL2luY2x1ZGUgLVdhbGwgLURGUkVFQlNEX05BVElW RSAtRE5ERUJVRyAtREhBVkVfQ09ORklHX0ggLURURVJNSU9TICAtSS91c3Ivb2JqL3Vzci9zcmMv aTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgL3Vzci9zcmMvbGliL2xpYm5jdXJzZXMvLi4vLi4vY29u dHJpYi9uY3Vyc2VzL25jdXJzZXMvdGluZm8vbWFrZV9rZXlzLmMNCj09PT4gdXNyLmJpbi9hd2sN CnlhY2MgLWQgLW8gYXdrZ3JhbS5jIC91c3Ivc3JjL3Vzci5iaW4vYXdrLy4uLy4uL2NvbnRyaWIv b25lLXRydWUtYXdrL2F3a2dyYW0ueQ0KeWFjYzogNDMgc2hpZnQvcmVkdWNlIGNvbmZsaWN0cw0K eWFjYzogODUgcmVkdWNlL3JlZHVjZSBjb25mbGljdHMNCmxuIC1zZiBhd2tncmFtLmggeXRhYi5o DQpjYyAtTyAtcGlwZSAtREhBU19JU0JMQU5LIC1JLiAtSS91c3Ivc3JjL3Vzci5iaW4vYXdrLy4u Ly4uL2NvbnRyaWIvb25lLXRydWUtYXdrICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kv dXNyL2luY2x1ZGUgIC1ML3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvbGliIC91c3Iv c3JjL3Vzci5iaW4vYXdrLy4uLy4uL2NvbnRyaWIvb25lLXRydWUtYXdrL21ha2V0YWIuYyAgLW8g bWFrZXRhYg0KPT09PiBsaWIvbGlibWFnaWMNCmNjIC1ESEFWRV9DT05GSUdfSCAtRENPTVBJTEVf T05MWSAgLUkvdXNyL3NyYy9saWIvbGlibWFnaWMgLUkvdXNyL3NyYy9saWIvbGlibWFnaWMvLi4v Li4vY29udHJpYi9maWxlIC1vIG1rbWFnaWMgL3Vzci9zcmMvbGliL2xpYm1hZ2ljLy4uLy4uL2Nv bnRyaWIvZmlsZS9hcHByZW50aWNlLmMgL3Vzci9zcmMvbGliL2xpYm1hZ2ljLy4uLy4uL2NvbnRy aWIvZmlsZS9mdW5jcy5jIC91c3Ivc3JjL2xpYi9saWJtYWdpYy8uLi8uLi9jb250cmliL2ZpbGUv bWFnaWMuYyAvdXNyL3NyYy9saWIvbGlibWFnaWMvLi4vLi4vY29udHJpYi9maWxlL3ByaW50LmMN Cj09PT4gdXNyLnNiaW4vc3lzaW5zdGFsbA0KY2MgLW8gcnRlcm1jYXAgL3Vzci9zcmMvdXNyLnNi aW4vc3lzaW5zdGFsbC9ydGVybWNhcC5jIC1sdGVybWNhcA0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IHN0YWdlIDM6 IGNyb3NzIHRvb2xzDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KY2QgL3Vzci9zcmM7IFRPT0xTX1BSRUZJWD0vdXNyL29iai91 c3Ivc3JjL2kzODYgTUFLRU9CSkRJUlBSRUZJWD0vdXNyL29iai91c3Ivc3JjL2kzODYgIERFU1RE SVI9ICBJTlNUQUxMPSJzaCAvdXNyL3NyYy90b29scy9pbnN0YWxsLnNoIiAgUEFUSD0vdXNyL29i ai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9zYmluOi91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdh Y3kvdXNyL2JpbjovdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9nYW1lczovc2Jpbjov YmluOi91c3Ivc2JpbjovdXNyL2JpbiAgV09STERUTVA9L3Vzci9vYmovdXNyL3NyYy9pMzg2ICBN QUtFRkxBR1M9Ii1tIC91c3Ivc3JjL3Rvb2xzL2J1aWxkL21rICAtRCBOT19SRVNDVUUgLW0gL3Vz ci9zcmMvc2hhcmUvbWsgIiAvdXNyL29iai91c3Ivc3JjL21ha2UuaTM4Ni9tYWtlIC1mIE1ha2Vm aWxlLmluYzEgIEJPT1RTVFJBUFBJTkc9NTAyMTI4ICAtRE5PSFRNTCAtRE5PSU5GTyAtRE5PTElO VCAtRE5PTUFOIC1ETk9QSUMgLUROT1BST0ZJTEUgIC1ETk9TSEFSRUQgLUROT19DUFVfQ0ZMQUdT IC1ETk9fV0FSTlMgLUROT19GT1JUUkFOIC1ETk9fR0RCIGNyb3NzLXRvb2xzDQo9PT0+IGdudS91 c3IuYmluL2JpbnV0aWxzDQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eQ0KL3Vz ci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5 IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eQ0KPT09 PiBnbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQNCi91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZCBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUv dXNyLmJpbi9iaW51dGlscy9saWJiZmQNCj09PT4gZ251L3Vzci5iaW4vYmludXRpbHMvbGlib3Bj b2Rlcw0KL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMv bGlib3Bjb2RlcyBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJv cGNvZGVzDQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzDQovdXNyL29iai91 c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscyBjcmVh dGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscw0KPT09PiBn bnUvdXNyLmJpbi9iaW51dGlscy9hZGRyMmxpbmUNCi91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FkZHIybGluZSBjcmVhdGVkIGZvciAvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9hZGRyMmxpbmUNCj09PT4gZ251L3Vzci5iaW4vYmludXRpbHMv YXINCi91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2Fy IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FyDQo9PT0+IGdudS91 c3IuYmluL2JpbnV0aWxzL2FzDQovdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNy LmJpbi9iaW51dGlscy9hcyBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9hcw0KPT09PiBnbnUvdXNyLmJpbi9iaW51dGlscy9sZA0KL3Vzci9vYmovdXNyL3NyYy9pMzg2 L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251 L3Vzci5iaW4vYmludXRpbHMvbGQNCj09PT4gZ251L3Vzci5iaW4vYmludXRpbHMvbm0NCi91c3Iv b2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL25tIGNyZWF0ZWQg Zm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL25tDQo9PT0+IGdudS91c3IuYmluL2Jp bnV0aWxzL29iamNvcHkNCi91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL29iamNvcHkgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRp bHMvb2JqY29weQ0KPT09PiBnbnUvdXNyLmJpbi9iaW51dGlscy9vYmpkdW1wDQovdXNyL29iai91 c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9vYmpkdW1wIGNyZWF0ZWQg Zm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL29iamR1bXANCj09PT4gZ251L3Vzci5i aW4vYmludXRpbHMvcmFubGliDQovdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNy LmJpbi9iaW51dGlscy9yYW5saWIgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvcmFubGliDQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxzL3JlYWRlbGYNCi91c3Ivb2Jq L3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL3JlYWRlbGYgY3JlYXRl ZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvcmVhZGVsZg0KPT09PiBnbnUvdXNy LmJpbi9iaW51dGlscy9zaXplDQovdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNy LmJpbi9iaW51dGlscy9zaXplIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0 aWxzL3NpemUNCj09PT4gZ251L3Vzci5iaW4vYmludXRpbHMvc3RyaW5ncw0KL3Vzci9vYmovdXNy L3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvc3RyaW5ncyBjcmVhdGVkIGZv ciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9zdHJpbmdzDQo9PT0+IGdudS91c3IuYmlu L2JpbnV0aWxzL3N0cmlwDQovdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJp bi9iaW51dGlscy9zdHJpcCBjcmVhdGVkIGZvciAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9zdHJpcA0KPT09PiBnbnUvdXNyLmJpbi9iaW51dGlscy9kb2MNCi91c3Ivb2JqL3Vzci9zcmMv aTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2RvYyBjcmVhdGVkIGZvciAvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9kb2MNCj09PT4gZ251L3Vzci5iaW4vYmludXRpbHMvbGli aWJlcnR5DQpybSAtZiAuZGVwZW5kDQpta2RlcCAtZiAuZGVwZW5kIC1hICAgIC1JLiAtSS91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eSAtSS91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2xpYmliZXJ0eS8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNy L3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vbGliYmZkIC1JL3Vzci9zcmMv Z251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRp bHMvaW5jbHVkZSAtREhBVkVfQ09ORklHX0ggLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5 L3Vzci9pbmNsdWRlIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi8u Li8uLi8uLi9jb250cmliL2JpbnV0aWxzL2xpYmliZXJ0eS9hcmd2LmMgL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvbGli aWJlcnR5L2NvbmNhdC5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8u Li8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2xpYmliZXJ0eS9jaG9vc2UtdGVtcC5jIC91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi8uLi8uLi8uLi9jb250cmliL2Jp bnV0aWxzL2xpYmliZXJ0eS9jcC1kZW1hbmdsZS5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0 aWxzL2xpYmliZXJ0eS8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2xpYmliZXJ0eS9jcC1k ZW1pbnQuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vLi4vLi4v Li4vY29udHJpYi9iaW51dGlscy9saWJpYmVydHkvY3BsdXMtZGVtLmMgL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvbGli aWJlcnR5L2R5bi1zdHJpbmcuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVy dHkvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9saWJpYmVydHkvZ2V0cHdkLmMgL3Vzci9z cmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmlu dXRpbHMvbGliaWJlcnR5L2dldHJ1bnRpbWUuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9saWJpYmVydHkvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9saWJpYmVydHkvZmxvYXRm b3JtYXQuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vLi4vLi4v Li4vY29udHJpYi9iaW51dGlscy9saWJpYmVydHkvaGFzaHRhYi5jIC91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2xpYmli ZXJ0eS9oZXguYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vLi4v Li4vLi4vY29udHJpYi9iaW51dGlscy9saWJpYmVydHkvbGJhc2VuYW1lLmMgL3Vzci9zcmMvZ251 L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMv bGliaWJlcnR5L2xyZWFscGF0aC5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmli ZXJ0eS8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2xpYmliZXJ0eS9tYWtlLXJlbGF0aXZl LXByZWZpeC5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi8uLi8u Li8uLi9jb250cmliL2JpbnV0aWxzL2xpYmliZXJ0eS9tYWtlLXRlbXAtZmlsZS5jIC91c3Ivc3Jj L2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0 aWxzL2xpYmliZXJ0eS9vYmphbGxvYy5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xp YmliZXJ0eS8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2xpYmliZXJ0eS9vYnN0YWNrLmMg L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4uLy4uLy4uLy4uL2NvbnRy aWIvYmludXRpbHMvbGliaWJlcnR5L3NhZmUtY3R5cGUuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9saWJpYmVydHkvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9saWJpYmVydHkv eGF0ZXhpdC5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi8uLi8u Li8uLi9jb250cmliL2JpbnV0aWxzL2xpYmliZXJ0eS94ZXhpdC5jIC91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2xpYmli ZXJ0eS94bWFsbG9jLmMgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4u Ly4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvbGliaWJlcnR5L3hzdHJkdXAuYyAvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGls cy9saWJpYmVydHkveHN0cmVycm9yLmMgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGli aWJlcnR5Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvbGliaWJlcnR5L3JlZ2V4LmMgL3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4uLy4uLy4uLy4uL2NvbnRyaWIv YmludXRpbHMvbGliaWJlcnR5L3NwbGF5LXRyZWUuYw0KPT09PiBnbnUvdXNyLmJpbi9iaW51dGls cy9saWJiZmQNCnNlZCAtZSBzL05OLzMyL2cgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMv bGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZkL2VsZnh4LXRhcmdldC5oID4g ZWxmMzItdGFyZ2V0LmgNCnNlZCAtZiAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJi ZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQvdGFyZ21hdGNoLnNlZCAvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGls cy9iZmQvY29uZmlnLmJmZCA+IHRhcmdtYXRjaC5oDQpzZWQgLWUgJ3MsISFUUkFEX0hFQURFUiEh LCJob3N0cy9pMzg2YnNkLmgiLGcnIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJm ZC9jb25maWcuaC5mYnNkID4gY29uZmlnLmgNCmVjaG8gJyNkZWZpbmUgQkZEX1ZFUlNJT04JMjE1 MDAwMDAwJwk+IGJmZHZlci5oDQplY2hvICcjZGVmaW5lIEJGRF9WRVJTSU9OX0RBVEUJMjAwNDA1 MTcnCT4+IGJmZHZlci5oDQplY2hvICcjZGVmaW5lIEJGRF9WRVJTSU9OX1NUUklORyAiMi4xNSBb RnJlZUJTRF0gMjAwNC0wNS0yMyInCT4+IGJmZHZlci5oDQpybSAtZiAuZGVwZW5kDQpta2RlcCAt ZiAuZGVwZW5kIC1hICAgIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJm ZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi9saWJiZmQgLUkvdXNy L29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4v bGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4u L2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZkIC1E U0VMRUNUX0FSQ0hJVEVDVFVSRVM9IiAmYmZkX2kzODZfYXJjaCIgLURIQVZFX2JmZF9lbGYzMl9p Mzg2X2ZyZWVic2RfdmVjIC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl92ZWMgLURTRUxFQ1RfVkVDUz0i ICZiZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAsJmJmZF9lbGYzMl9pMzg2X3ZlYyIgLURERUZB VUxUX1ZFQ1RPUj1iZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAtSS91c3Ivb2JqL3Vzci9zcmMv aTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGli YmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZkL2NwdS1pMzg2LmMgL3Vzci9zcmMv Z251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMv YmZkL2VsZjMyLWkzODYuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4v Li4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQvZWxmMzIuYyAvdXNyL3NyYy9nbnUvdXNyLmJp bi9iaW51dGlscy9saWJiZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQvZWxmbGlu ay5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250 cmliL2JpbnV0aWxzL2JmZC9hcmNoaXZlLmMgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMv bGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZkL2FyY2hpdmU2NC5jIC91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0 aWxzL2JmZC9hcmNodXJlcy5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8u Li8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZC9iZmQuYyAvdXNyL3NyYy9nbnUvdXNyLmJp bi9iaW51dGlscy9saWJiZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQvYmZkd2lu LmMgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRy aWIvYmludXRpbHMvYmZkL2JpbmFyeS5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xp YmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZC9jYWNoZS5jIC91c3Ivc3JjL2du dS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2Jm ZC9jb2ZmZ2VuLmMgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4u Ly4uL2NvbnRyaWIvYmludXRpbHMvYmZkL2NvcmVmaWxlLmMgL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZkL2VsZi5jIC91 c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2Jp bnV0aWxzL2JmZC9lbGYtZWgtZnJhbWUuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9s aWJiZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQvZWxmLXN0cnRhYi5jIC91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0 aWxzL2JmZC9mb3JtYXQuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4v Li4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQvaGFzaC5jIC91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZC9paGV4LmMg L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIv YmludXRpbHMvYmZkL2luaXQuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQv Li4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQvbGliYmZkLmMgL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZkL2xp bmtlci5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9j b250cmliL2JpbnV0aWxzL2JmZC9tZXJnZS5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZC9vcG5jbHMuYyAvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGls cy9iZmQvcmVsb2MuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vLi4v Li4vLi4vY29udHJpYi9iaW51dGlscy9iZmQvc2VjdGlvbi5jIC91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZC9zcmVjLmMg L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIv YmludXRpbHMvYmZkL3N0YWItc3ltcy5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xp YmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZC9zdGFicy5jIC91c3Ivc3JjL2du dS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2Jm ZC9zeW1zLmMgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4u L2NvbnRyaWIvYmludXRpbHMvYmZkL3RhcmdldHMuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51 dGlscy9saWJiZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQvdGVraGV4LmMgL3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmlu dXRpbHMvYmZkL2R3YXJmMS5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8u Li8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZC9kd2FyZjIuYyAvdXNyL3NyYy9nbnUvdXNy LmJpbi9iaW51dGlscy9saWJiZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQvYmZk aW8uYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vLi4vLi4vLi4vY29u dHJpYi9iaW51dGlscy9iZmQvc2ltcGxlLmMNCj09PT4gZ251L3Vzci5iaW4vYmludXRpbHMvbGli b3Bjb2Rlcw0Kcm0gLWYgLmRlcGVuZA0KbWtkZXAgLWYgLmRlcGVuZCAtYSAgICAtSS4gLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJvcGNvZGVzIC1JL3Vzci9zcmMvZ251L3Vzci5i aW4vYmludXRpbHMvbGlib3Bjb2Rlcy8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYv dXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJvcGNvZGVzLy4uL2xpYmJmZCAtSS91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYm9wY29kZXMvLi4vLi4vLi4vLi4vY29udHJpYi9i aW51dGlscy9pbmNsdWRlIC1EQVJDSF9pMzg2IC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUv dXNyLmJpbi9iaW51dGlscy9saWJvcGNvZGVzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMv b3Bjb2RlcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYm9wY29kZXMvLi4vLi4v Li4vLi4vY29udHJpYi9iaW51dGlscy9iZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5 L3Vzci9pbmNsdWRlIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYm9wY29kZXMvLi4v Li4vLi4vLi4vY29udHJpYi9iaW51dGlscy9vcGNvZGVzL2kzODYtZGlzLmMgL3Vzci9zcmMvZ251 L3Vzci5iaW4vYmludXRpbHMvbGlib3Bjb2Rlcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxz L29wY29kZXMvZGlzLWJ1Zi5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYm9wY29k ZXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9vcGNvZGVzL2Rpcy1pbml0LmMgL3Vzci9z cmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGlib3Bjb2Rlcy8uLi8uLi8uLi8uLi9jb250cmliL2Jp bnV0aWxzL29wY29kZXMvZGlzYXNzZW1ibGUuYw0KPT09PiBnbnUvdXNyLmJpbi9iaW51dGlscy9s aWJiaW51dGlscw0KbGV4IC10ICAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51 dGlscy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxzL2FybGV4LmwgPiBhcmxl eC5jDQp5YWNjIC1kIC1vIGFycGFyc2UuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9s aWJiaW51dGlscy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxzL2FycGFyc2Uu eQ0Kcm0gLWYgLmRlcGVuZA0KbWtkZXAgLWYgLmRlcGVuZCAtYSAgICAtSS4gLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2Jp bnV0aWxzL2xpYmJpbnV0aWxzLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uL2xpYmJmZCAtSS91c3Ivc3Jj L2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmlu dXRpbHMvaW5jbHVkZSAtRFRBUkdFVD1cImkzODYtb2JyaWVuLWZyZWVic2RcIiAtREJGRF9WRVJT SU9OX1NUUklORz1cIiIyLjE1IFtGcmVlQlNEXSAyMDA0LTA1LTIzIlwiIC1EX0dOVV9TT1VSQ0Ug LUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscy8uLi8uLi8uLi8uLi9j b250cmliL2JpbnV0aWxzL2JpbnV0aWxzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMv bGliYmludXRpbHMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQgLUkvdXNyL29iai91 c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIGFybGV4LmMgYXJwYXJzZS5jIC91c3Ivc3Jj L2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmlu dXRpbHMvYmludXRpbHMvYXJzdXAuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJi aW51dGlscy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxzL2J1Y29tbS5jIC91 c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uLy4uLy4uLy4uL2NvbnRy aWIvYmludXRpbHMvYmludXRpbHMvZGVidWcuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9saWJiaW51dGlscy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxzL2ZpbGVt b2RlLmMgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vLi4vLi4v Li4vY29udHJpYi9iaW51dGlscy9iaW51dGlscy9pZWVlLmMgL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvbGliYmludXRpbHMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iaW51dGls cy9yZGNvZmYuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscy8uLi8u Li8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxzL3JkZGJnLmMgL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9i aW51dGlscy9yZW5hbWUuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGls cy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxzL3N0YWJzLmMgL3Vzci9zcmMv Z251L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51 dGlscy9iaW51dGlscy91bndpbmQtaWE2NC5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2xpYmJpbnV0aWxzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmludXRpbHMvd3JzdGFi cy5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uLy4uLy4uLy4u L2NvbnRyaWIvYmludXRpbHMvYmludXRpbHMvdmVyc2lvbi5jIC91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmludXRp bHMvYmluZW11bC5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4u Ly4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmludXRpbHMvYnVkZW1hbmcuYyAvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0 aWxzL2JpbnV0aWxzL2VtdWxfdmFuaWxsYS5jDQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxzL2Fk ZHIybGluZQ0Kcm0gLWYgLmRlcGVuZA0KbWtkZXAgLWYgLmRlcGVuZCAtYSAgICAtSS4gLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hZGRyMmxpbmUgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi9iaW51dGlscy9hZGRyMmxpbmUvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYWRkcjJsaW5lLy4uL2xpYmJmZCAtSS91c3Ivc3Jj L2dudS91c3IuYmluL2JpbnV0aWxzL2FkZHIybGluZS8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0 aWxzL2luY2x1ZGUgLURfR05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2FkZHIybGluZS8uLi9saWJiaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2FkZHIybGluZS8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxzIC1JL3Vzci9v YmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9hZGRyMmxpbmUvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iaW51dGlscy9h ZGRyMmxpbmUuYw0KZWNobyBhZGRyMmxpbmU6IC91c3IvbGliL2xpYmMuYSAuLi9saWJiaW51dGls cy9saWJiaW51dGlscy5hIC4uL2xpYmJmZC9saWJiZmQuYSAuLi9saWJpYmVydHkvbGliaWJlcnR5 LmEgL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvbGliL2xpYmVnYWN5LmEgPj4gLmRl cGVuZA0KPT09PiBnbnUvdXNyLmJpbi9iaW51dGlscy9hcg0Kcm0gLWYgLmRlcGVuZA0KbWtkZXAg LWYgLmRlcGVuZCAtYSAgICAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hciAt SS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FyLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vz ci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FyLy4uL2xpYmJmZCAtSS91 c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FyLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRp bHMvaW5jbHVkZSAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMv YXIvLi4vbGliYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hci8uLi8u Li8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvYXIvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQgLUkvdXNyL29iai91 c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0 aWxzL2FyLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmludXRpbHMvYXIuYyAvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9hci8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2Jp bnV0aWxzL25vdC1yYW5saWIuYw0KZWNobyBhcjogL3Vzci9saWIvbGliYy5hIC4uL2xpYmJpbnV0 aWxzL2xpYmJpbnV0aWxzLmEgLi4vbGliYmZkL2xpYmJmZC5hIC4uL2xpYmliZXJ0eS9saWJpYmVy dHkuYSAvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9saWIvbGliZWdhY3kuYSA+PiAu ZGVwZW5kDQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxzL2FzDQpybSAtZiAuZGVwZW5kDQpta2Rl cCAtZiAuZGVwZW5kIC1hICAgIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2Fz IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vbGliYmZkIC1JL3Vzci9vYmov dXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vbGliYmZkIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51 dGlscy9pbmNsdWRlIC1EREVGQVVMVF9BUkNIPVwiaTM4NlwiIC1EVEFSR0VUX0NQVT1cImkzODZc IiAtRFRBUkdFVF9DQU5PTklDQUw9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURUQVJHRVRfQUxJ QVM9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURWRVJTSU9OPVwiIjIuMTUgW0ZyZWVCU0RdIDIw MDQtMDUtMjMiXCIgLURfR05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvZ2FzIC1JL3Vzci9zcmMvZ251L3Vzci5i aW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9nYXMvY29uZmlnIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51 dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvYXMvaTM4Ni1mcmVlYnNkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xl Z2FjeS91c3IvaW5jbHVkZSAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8u Li8uLi9jb250cmliL2JpbnV0aWxzL2dhcy9hcHAuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51 dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2dhcy9hcy5jIC91c3Ivc3JjL2du dS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvZ2FzL2F0 b2YtZ2VuZXJpYy5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4u L2NvbnRyaWIvYmludXRpbHMvZ2FzL2NvbmZpZy9hdG9mLWllZWUuYyAvdXNyL3NyYy9nbnUvdXNy LmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2dhcy9iaWdudW0t Y29weS5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRy aWIvYmludXRpbHMvZ2FzL2NvbmQuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8u Li8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2dhcy9kd2FyZjJkYmcuYyAvdXNyL3NyYy9nbnUv dXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2dhcy9lY29m Zi5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIv YmludXRpbHMvZ2FzL2V4cHIuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8u Li8uLi8uLi9jb250cmliL2JpbnV0aWxzL2dhcy9mbG9udW0tY29weS5jIC91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvZ2FzL2Zsb251 bS1rb25zdC5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2Nv bnRyaWIvYmludXRpbHMvZ2FzL2Zsb251bS1tdWx0LmMgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9nYXMvZnJhZ3MuYyAvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2dh cy9oYXNoLmMgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29u dHJpYi9iaW51dGlscy9nYXMvaW5wdXQtZmlsZS5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0 aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvZ2FzL2lucHV0LXNjcnViLmMgL3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGls cy9nYXMvbGlzdGluZy5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4u Ly4uL2NvbnRyaWIvYmludXRpbHMvZ2FzL2xpdGVyYWwuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2dhcy9tYWNyby5jIC91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMv Z2FzL21lc3NhZ2VzLmMgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4v Li4vY29udHJpYi9iaW51dGlscy9nYXMvY29uZmlnL29iai1lbGYuYyAvdXNyL3NyYy9nbnUvdXNy LmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2dhcy9vdXRwdXQt ZmlsZS5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRy aWIvYmludXRpbHMvZ2FzL3JlYWQuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8u Li8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2dhcy9zYi5jIC91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvZ2FzL3N0YWJzLmMgL3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGls cy9nYXMvc3Vic2Vncy5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4u Ly4uL2NvbnRyaWIvYmludXRpbHMvZ2FzL3N5bWJvbHMuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2dhcy93cml0ZS5jIC91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMv Z2FzL2RlcGVuZC5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4u L2NvbnRyaWIvYmludXRpbHMvZ2FzL2Vob3B0LmMgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRp bHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9nYXMvZHcyZ2VuY2ZpLmMgL3Vzci9z cmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9n YXMvY29uZmlnL3RjLWkzODYuYw0KZWNobyBhczogL3Vzci9saWIvbGliYy5hIC4uL2xpYmJmZC9s aWJiZmQuYSAuLi9saWJpYmVydHkvbGliaWJlcnR5LmEgLi4vbGlib3Bjb2Rlcy9saWJvcGNvZGVz LmEgL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvbGliL2xpYmVnYWN5LmEgPj4gLmRl cGVuZA0KPT09PiBnbnUvdXNyLmJpbi9iaW51dGlscy9sZA0KbG4gLXNmIC91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2xkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvbGQvZW11bHRl bXBsL2FzdHJpbmcuc2VkIHN0cmluZ2lmeS5zZWQNCnNoIC91c3Ivc3JjL2dudS91c3IuYmluL2Jp bnV0aWxzL2xkL2dlbnNjcmlwdHMuc2ggL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGQv Li4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9sZCBcIi91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9s aWJcIjpcIi91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3IvbGliXCIgIC91c3Ivb2JqL3Vzci9zcmMv aTM4Ni91c3IgIGkzODYtb2JyaWVuLWZyZWVic2QgaTM4Ni1vYnJpZW4tZnJlZWJzZCBpMzg2LW9i cmllbi1mcmVlYnNkICAiZWxmX2kzODZfZmJzZCIgIiIgbm8gZWxmX2kzODZfZmJzZCAiaTM4Ni1v YnJpZW4tZnJlZWJzZCINCmVjaG8gIiBleHRlcm4gbGRfZW11bGF0aW9uX3hmZXJfdHlwZSBsZF9l bGZfaTM4Nl9mYnNkX2VtdWxhdGlvbjsiID4gbGRlbXVsLWxpc3QuaA0KZWNobyAiI2RlZmluZSBF TVVMQVRJT05fTElTVCAgJmxkX2VsZl9pMzg2X2Zic2RfZW11bGF0aW9uLCAwIiA+PiBsZGVtdWwt bGlzdC5oDQp5YWNjIC1kIC1vIGxkZ3JhbS5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2xkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvbGQvbGRncmFtLnkNCmxleCAtdCAgL3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGls cy9sZC9sZGxleC5sID4gbGRsZXguYw0Kcm0gLWYgLmRlcGVuZA0KbWtkZXAgLWYgLmRlcGVuZCAt YSAgICAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9sZCAtSS91c3Ivc3JjL2du dS91c3IuYmluL2JpbnV0aWxzL2xkLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91 c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xkLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2xkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAt RFRBUkdFVD1cImkzODYtb2JyaWVuLWZyZWVic2RcIiAtRERFRkFVTFRfRU1VTEFUSU9OPVwiZWxm X2kzODZfZmJzZFwiIC1EU0NSSVBURElSPVwiL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9saWJk YXRhXCIgLURCRkRfVkVSU0lPTl9TVFJJTkc9XCIiMi4xNSBbRnJlZUJTRF0gMjAwNC0wNS0yMyJc IiAtREJJTkRJUj1cIi91c3IvYmluXCIgLURUQVJHRVRfU1lTVEVNX1JPT1Q9XCIvdXNyL29iai91 c3Ivc3JjL2kzODZcIiAtRFRPT0xCSU5ESVI9XCIvdXNyL29iai91c3Ivc3JjL2kzODYvL3Vzci9i aW4vbGliZXhlY1wiIC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9sZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2xkIC1JL3Vzci9zcmMvZ251L3Vzci5i aW4vYmludXRpbHMvbGQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQgLUkvdXNyL29i ai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIGVlbGZfaTM4Nl9mYnNkLmMgL3Vzci9z cmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9s ZC9sZGNyZWYuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9sZC8uLi8uLi8uLi8uLi9j b250cmliL2JpbnV0aWxzL2xkL2xkY3Rvci5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2xkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvbGQvbGRlbXVsLmMgL3Vzci9zcmMvZ251 L3Vzci5iaW4vYmludXRpbHMvbGQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9sZC9sZGV4 cC5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xkLy4uLy4uLy4uLy4uL2NvbnRyaWIv YmludXRpbHMvbGQvbGRmaWxlLmMgbGRncmFtLmMgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRp bHMvbGQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9sZC9sZGxhbmcuYyBsZGxleC5jIC91 c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRp bHMvbGQvbGRtYWluLmMgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGQvLi4vLi4vLi4v Li4vY29udHJpYi9iaW51dGlscy9sZC9sZG1pc2MuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51 dGlscy9sZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2xkL2xkdmVyLmMgL3Vzci9zcmMv Z251L3Vzci5iaW4vYmludXRpbHMvbGQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9sZC9s ZHdyaXRlLmMgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGQvLi4vLi4vLi4vLi4vY29u dHJpYi9iaW51dGlscy9sZC9sZXhzdXAuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9s ZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2xkL21yaS5jDQplY2hvIGxkOiAvdXNyL2xp Yi9saWJjLmEgLi4vbGliYmZkL2xpYmJmZC5hIC4uL2xpYmliZXJ0eS9saWJpYmVydHkuYSAvdXNy L29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9saWIvbGliZWdhY3kuYSA+PiAuZGVwZW5kDQo9 PT0+IGdudS91c3IuYmluL2JpbnV0aWxzL25tDQpybSAtZiAuZGVwZW5kDQpta2RlcCAtZiAuZGVw ZW5kIC1hICAgIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL25tIC1JL3Vzci9z cmMvZ251L3Vzci5iaW4vYmludXRpbHMvbm0vLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9p Mzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbm0vLi4vbGliYmZkIC1JL3Vzci9zcmMv Z251L3Vzci5iaW4vYmludXRpbHMvbm0vLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNs dWRlIC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9ubS8uLi9s aWJiaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL25tLy4uLy4uLy4uLy4u L2NvbnRyaWIvYmludXRpbHMvYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbm0v Li4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iaW51dGlscyAtSS91c3Ivb2JqL3Vzci9zcmMv aTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbm0v Li4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iaW51dGlscy9ubS5jDQplY2hvIG5tOiAvdXNy L2xpYi9saWJjLmEgLi4vbGliYmludXRpbHMvbGliYmludXRpbHMuYSAuLi9saWJiZmQvbGliYmZk LmEgLi4vbGliaWJlcnR5L2xpYmliZXJ0eS5hIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kv dXNyL2xpYi9saWJlZ2FjeS5hID4+IC5kZXBlbmQNCj09PT4gZ251L3Vzci5iaW4vYmludXRpbHMv b2JqY29weQ0Kcm0gLWYgLmRlcGVuZA0KbWtkZXAgLWYgLmRlcGVuZCAtYSAgICAtSS4gLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9vYmpjb3B5IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvb2JqY29weS8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9vYmpjb3B5Ly4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL29iamNvcHkvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNs dWRlIC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9vYmpjb3B5 Ly4uL2xpYmJpbnV0aWxzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvb2JqY29weS8u Li8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxzIC1JL3Vzci9zcmMvZ251L3Vzci5i aW4vYmludXRpbHMvb2JqY29weS8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZCAtSS91 c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgL3Vzci9zcmMvZ251L3Vzci5i aW4vYmludXRpbHMvb2JqY29weS8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxz L29iamNvcHkuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9vYmpjb3B5Ly4uLy4uLy4u Ly4uL2NvbnRyaWIvYmludXRpbHMvYmludXRpbHMvbm90LXN0cmlwLmMNCmVjaG8gb2JqY29weTog L3Vzci9saWIvbGliYy5hIC4uL2xpYmJpbnV0aWxzL2xpYmJpbnV0aWxzLmEgLi4vbGliYmZkL2xp YmJmZC5hIC4uL2xpYmliZXJ0eS9saWJpYmVydHkuYSAvdXNyL29iai91c3Ivc3JjL2kzODYvbGVn YWN5L3Vzci9saWIvbGliZWdhY3kuYSA+PiAuZGVwZW5kDQo9PT0+IGdudS91c3IuYmluL2JpbnV0 aWxzL29iamR1bXANCnJtIC1mIC5kZXBlbmQNCm1rZGVwIC1mIC5kZXBlbmQgLWEgICAgLUkuIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvb2JqZHVtcCAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL29iamR1bXAvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvb2JqZHVtcC8uLi9saWJiZmQgLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9vYmpkdW1wLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMv aW5jbHVkZSAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvb2Jq ZHVtcC8uLi9saWJiaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL29iamR1 bXAvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iaW51dGlscyAtREJGRF9WRVJTSU9OX1NU UklORz1cIiIyLjE1IFtGcmVlQlNEXSAyMDA0LTA1LTIzIlwiIC1JL3Vzci9vYmovdXNyL3NyYy9p Mzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9vYmpk dW1wLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmludXRpbHMvb2JqZHVtcC5jIC91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL29iamR1bXAvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51 dGlscy9iaW51dGlscy9wcmRiZy5jDQplY2hvIG9iamR1bXA6IC91c3IvbGliL2xpYmMuYSAuLi9s aWJiaW51dGlscy9saWJiaW51dGlscy5hIC4uL2xpYm9wY29kZXMvbGlib3Bjb2Rlcy5hIC4uL2xp YmJmZC9saWJiZmQuYSAuLi9saWJpYmVydHkvbGliaWJlcnR5LmEgL3Vzci9vYmovdXNyL3NyYy9p Mzg2L2xlZ2FjeS91c3IvbGliL2xpYmVnYWN5LmEgPj4gLmRlcGVuZA0KPT09PiBnbnUvdXNyLmJp bi9iaW51dGlscy9yYW5saWINCnJtIC1mIC5kZXBlbmQNCm1rZGVwIC1mIC5kZXBlbmQgLWEgICAg LUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvcmFubGliIC1JL3Vzci9zcmMvZ251 L3Vzci5iaW4vYmludXRpbHMvcmFubGliLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4 Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL3JhbmxpYi8uLi9saWJiZmQgLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9yYW5saWIvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGls cy9pbmNsdWRlIC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9y YW5saWIvLi4vbGliYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9yYW5s aWIvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iaW51dGlscyAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL3JhbmxpYi8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZCAt SS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvcmFubGliLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmludXRp bHMvYXIuYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9yYW5saWIvLi4vLi4vLi4vLi4v Y29udHJpYi9iaW51dGlscy9iaW51dGlscy9pcy1yYW5saWIuYw0KZWNobyByYW5saWI6IC91c3Iv bGliL2xpYmMuYSAuLi9saWJiaW51dGlscy9saWJiaW51dGlscy5hIC4uL2xpYmJmZC9saWJiZmQu YSAuLi9saWJpYmVydHkvbGliaWJlcnR5LmEgL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91 c3IvbGliL2xpYmVnYWN5LmEgPj4gLmRlcGVuZA0KPT09PiBnbnUvdXNyLmJpbi9iaW51dGlscy9y ZWFkZWxmDQpybSAtZiAuZGVwZW5kDQpta2RlcCAtZiAuZGVwZW5kIC1hICAgIC1JLiAtSS91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL3JlYWRlbGYgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9yZWFkZWxmLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3Jj L2dudS91c3IuYmluL2JpbnV0aWxzL3JlYWRlbGYvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvcmVhZGVsZi8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2luY2x1 ZGUgLURfR05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL3JlYWRlbGYv Li4vbGliYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9yZWFkZWxmLy4u Ly4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmludXRpbHMgLUkvdXNyL29iai91c3Ivc3JjL2kz ODYvbGVnYWN5L3Vzci9pbmNsdWRlIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL3JlYWRl bGYvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iaW51dGlscy9yZWFkZWxmLmMNCmVjaG8g cmVhZGVsZjogL3Vzci9saWIvbGliYy5hIC4uL2xpYmJpbnV0aWxzL2xpYmJpbnV0aWxzLmEgLi4v bGliYmZkL2xpYmJmZC5hIC4uL2xpYmliZXJ0eS9saWJpYmVydHkuYSAvdXNyL29iai91c3Ivc3Jj L2kzODYvbGVnYWN5L3Vzci9saWIvbGliZWdhY3kuYSA+PiAuZGVwZW5kDQo9PT0+IGdudS91c3Iu YmluL2JpbnV0aWxzL3NpemUNCnJtIC1mIC5kZXBlbmQNCm1rZGVwIC1mIC5kZXBlbmQgLWEgICAg LUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvc2l6ZSAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL3NpemUvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvc2l6ZS8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUv dXNyLmJpbi9iaW51dGlscy9zaXplLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVk ZSAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvc2l6ZS8uLi9s aWJiaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL3NpemUvLi4vLi4vLi4v Li4vY29udHJpYi9iaW51dGlscy9iaW51dGlscyAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdh Y3kvdXNyL2luY2x1ZGUgL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvc2l6ZS8uLi8uLi8u Li8uLi9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxzL3NpemUuYw0KZWNobyBzaXplOiAvdXNyL2xp Yi9saWJjLmEgLi4vbGliYmludXRpbHMvbGliYmludXRpbHMuYSAuLi9saWJiZmQvbGliYmZkLmEg Li4vbGliaWJlcnR5L2xpYmliZXJ0eS5hIC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNy L2xpYi9saWJlZ2FjeS5hID4+IC5kZXBlbmQNCj09PT4gZ251L3Vzci5iaW4vYmludXRpbHMvc3Ry aW5ncw0Kcm0gLWYgLmRlcGVuZA0KbWtkZXAgLWYgLmRlcGVuZCAtYSAgICAtSS4gLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9zdHJpbmdzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvc3RyaW5ncy8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9zdHJpbmdzLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL3N0cmluZ3MvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRl IC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9zdHJpbmdzLy4u L2xpYmJpbnV0aWxzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvc3RyaW5ncy8uLi8u Li8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxzIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2 L2xlZ2FjeS91c3IvaW5jbHVkZSAvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9zdHJpbmdz Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmludXRpbHMvc3RyaW5ncy5jDQplY2hvIHN0 cmluZ3M6IC91c3IvbGliL2xpYmMuYSAuLi9saWJiaW51dGlscy9saWJiaW51dGlscy5hIC4uL2xp YmJmZC9saWJiZmQuYSAuLi9saWJpYmVydHkvbGliaWJlcnR5LmEgL3Vzci9vYmovdXNyL3NyYy9p Mzg2L2xlZ2FjeS91c3IvbGliL2xpYmVnYWN5LmEgPj4gLmRlcGVuZA0KPT09PiBnbnUvdXNyLmJp bi9iaW51dGlscy9zdHJpcA0Kcm0gLWYgLmRlcGVuZA0KbWtkZXAgLWYgLmRlcGVuZCAtYSAgICAt SS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9zdHJpcCAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL3N0cmlwLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91 c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL3N0cmlwLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2du dS91c3IuYmluL2JpbnV0aWxzL3N0cmlwLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5j bHVkZSAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvc3RyaXAv Li4vbGliYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9zdHJpcC8uLi8u Li8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvc3RyaXAvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQgLUkvdXNyL29i ai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC91c3Ivc3JjL2dudS91c3IuYmluL2Jp bnV0aWxzL3N0cmlwLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmludXRpbHMvb2JqY29w eS5jIC91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL3N0cmlwLy4uLy4uLy4uLy4uL2NvbnRy aWIvYmludXRpbHMvYmludXRpbHMvaXMtc3RyaXAuYw0KZWNobyBzdHJpcDogL3Vzci9saWIvbGli Yy5hIC4uL2xpYmJpbnV0aWxzL2xpYmJpbnV0aWxzLmEgLi4vbGliYmZkL2xpYmJmZC5hIC4uL2xp YmliZXJ0eS9saWJpYmVydHkuYSAvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9saWIv bGliZWdhY3kuYSA+PiAuZGVwZW5kDQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxzL2RvYw0KPT09 PiBnbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eSAtSS91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2xpYmliZXJ0eS8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNy L3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vbGliYmZkIC1JL3Vzci9zcmMv Z251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRp bHMvaW5jbHVkZSAtREhBVkVfQ09ORklHX0ggIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2Fj eS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2xpYmliZXJ0eS9hcmd2 LmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmli ZXJ0eSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi9saWJiZmQg LUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJp YmVydHkvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5 Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtREhBVkVfQ09ORklHX0ggIC1J L3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250 cmliL2JpbnV0aWxzL2xpYmliZXJ0eS9jb25jYXQuYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9z cmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvbGliaWJlcnR5Ly4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi9saWJiZmQgLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGls cy9pbmNsdWRlIC1ESEFWRV9DT05GSUdfSCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5 L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvbGliaWJlcnR5L2Nob29z ZS10ZW1wLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2xpYmliZXJ0eSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi9s aWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9saWJpYmVydHkvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGli aWJlcnR5Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtREhBVkVfQ09ORklH X0ggIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3Ny Yy9jb250cmliL2JpbnV0aWxzL2xpYmliZXJ0eS9jcC1kZW1hbmdsZS5jDQpjYyAtTyAtcGlwZSAt SS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkgLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3Ny Yy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4uL2xpYmJmZCAt SS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi8uLi8uLi8uLi9jb250 cmliL2JpbnV0aWxzL2luY2x1ZGUgLURIQVZFX0NPTkZJR19IICAtSS91c3Ivb2JqL3Vzci9zcmMv aTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9iaW51dGlscy9saWJp YmVydHkvY3AtZGVtaW50LmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2xpYmliZXJ0eSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmli ZXJ0eS8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJp bi9iaW51dGlscy9saWJpYmVydHkvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvbGliaWJlcnR5Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtREhB VkVfQ09ORklHX0ggIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAt YyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2xpYmliZXJ0eS9jcGx1cy1kZW0uYw0KY2MgLU8g LXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5IC1JL3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4uL2xpYmJmZCAtSS91c3Ivb2Jq L3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi9s aWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vLi4vLi4v Li4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1ESEFWRV9DT05GSUdfSCAgLUkvdXNyL29iai91 c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmludXRp bHMvbGliaWJlcnR5L2R5bi1zdHJpbmcuYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251 L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRp bHMvbGliaWJlcnR5Ly4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2du dS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNy LmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNs dWRlIC1ESEFWRV9DT05GSUdfSCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9p bmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvbGliaWJlcnR5L2dldHB3ZC5jDQpj YyAtTyAtcGlwZSAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkg LUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vbGliYmZkIC1JL3Vz ci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5 Ly4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi8u Li8uLi8uLi9jb250cmliL2JpbnV0aWxzL2luY2x1ZGUgLURIQVZFX0NPTkZJR19IICAtSS91c3Iv b2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9i aW51dGlscy9saWJpYmVydHkvZ2V0cnVudGltZS5jDQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9saWJpYmVydHkvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9z cmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4uL2xpYmJmZCAtSS91c3Ivc3JjL2du dS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxz L2luY2x1ZGUgLURIQVZFX0NPTkZJR19IICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kv dXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9iaW51dGlscy9saWJpYmVydHkvZmxvYXRm b3JtYXQuYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMv bGliaWJlcnR5IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4uL2xp YmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2xpYmliZXJ0eS8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJp YmVydHkvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1ESEFWRV9DT05GSUdf SCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3Jj L2NvbnRyaWIvYmludXRpbHMvbGliaWJlcnR5L2hhc2h0YWIuYw0KY2MgLU8gLXBpcGUgLUkuIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5IC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4 Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi9saWJiZmQgLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vLi4vLi4vLi4vY29udHJpYi9i aW51dGlscy9pbmNsdWRlIC1ESEFWRV9DT05GSUdfSCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYv bGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvbGliaWJlcnR5 L2hleC5jDQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9s aWJpYmVydHkgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vbGli YmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMv bGliaWJlcnR5Ly4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmli ZXJ0eS8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2luY2x1ZGUgLURIQVZFX0NPTkZJR19I ICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMv Y29udHJpYi9iaW51dGlscy9saWJpYmVydHkvbGJhc2VuYW1lLmMNCmNjIC1PIC1waXBlIC1JLiAt SS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eSAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kz ODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vbGliYmZkIC1JL3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4uLy4uLy4uLy4uL2NvbnRyaWIv YmludXRpbHMvaW5jbHVkZSAtREhBVkVfQ09ORklHX0ggIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2 L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2xpYmliZXJ0 eS9scmVhbHBhdGguYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvbGliaWJlcnR5IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5 Ly4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2Jp bnV0aWxzL2xpYmliZXJ0eS8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9saWJpYmVydHkvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1ESEFWRV9D T05GSUdfSCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91 c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvbGliaWJlcnR5L21ha2UtcmVsYXRpdmUtcHJlZml4LmMN CmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0 eSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi9saWJiZmQgLUkv dXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVy dHkvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4u Ly4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtREhBVkVfQ09ORklHX0ggIC1JL3Vz ci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmli L2JpbnV0aWxzL2xpYmliZXJ0eS9tYWtlLXRlbXAtZmlsZS5jDQpjYyAtTyAtcGlwZSAtSS4gLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkgLUkvdXNyL3NyYy9nbnUvdXNy LmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2 L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4uL2xpYmJmZCAtSS91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi8uLi8uLi8uLi9jb250cmliL2Jp bnV0aWxzL2luY2x1ZGUgLURIQVZFX0NPTkZJR19IICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9s ZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9iaW51dGlscy9saWJpYmVydHkv b2JqYWxsb2MuYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRp bHMvbGliaWJlcnR5IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4u L2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0 aWxzL2xpYmliZXJ0eS8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9s aWJpYmVydHkvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1ESEFWRV9DT05G SUdfSCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Iv c3JjL2NvbnRyaWIvYmludXRpbHMvbGliaWJlcnR5L29ic3RhY2suYw0KY2MgLU8gLXBpcGUgLUku IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5IC1JL3Vzci9zcmMvZ251 L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMv aTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi9saWJiZmQgLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vLi4vLi4vLi4vY29udHJp Yi9iaW51dGlscy9pbmNsdWRlIC1ESEFWRV9DT05GSUdfSCAgLUkvdXNyL29iai91c3Ivc3JjL2kz ODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvbGliaWJl cnR5L3NhZmUtY3R5cGUuYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvbGliaWJlcnR5IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJl cnR5Ly4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2xpYmliZXJ0eS8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51 dGlscy9saWJpYmVydHkvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1ESEFW RV9DT05GSUdfSCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1j IC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvbGliaWJlcnR5L3hhdGV4aXQuYw0KY2MgLU8gLXBp cGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5IC1JL3Vzci9z cmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vz ci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi9saWJi ZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vLi4vLi4vLi4v Y29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1ESEFWRV9DT05GSUdfSCAgLUkvdXNyL29iai91c3Iv c3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMv bGliaWJlcnR5L3hleGl0LmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2xpYmliZXJ0eSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmli ZXJ0eS8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJp bi9iaW51dGlscy9saWJpYmVydHkvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvbGliaWJlcnR5Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtREhB VkVfQ09ORklHX0ggIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAt YyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2xpYmliZXJ0eS94bWFsbG9jLmMNCmNjIC1PIC1w aXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eSAtSS91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8uLi9saWJiZmQgLUkvdXNyL29iai91 c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vbGli YmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4uLy4uLy4uLy4u L2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtREhBVkVfQ09ORklHX0ggIC1JL3Vzci9vYmovdXNy L3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxz L2xpYmliZXJ0eS94c3RyZHVwLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL2xpYmliZXJ0eSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xp YmliZXJ0eS8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNy LmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvbGliaWJlcnR5Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAt REhBVkVfQ09ORklHX0ggIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVk ZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2xpYmliZXJ0eS94c3RyZXJyb3IuYw0KY2Mg LU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5IC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliaWJlcnR5Ly4uL2xpYmJmZCAtSS91c3Iv b2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eS8u Li9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vLi4v Li4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1ESEFWRV9DT05GSUdfSCAgLUkvdXNyL29i ai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmlu dXRpbHMvbGliaWJlcnR5L3JlZ2V4LmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2xpYmliZXJ0eSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2xpYmliZXJ0eS8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUv dXNyLmJpbi9iaW51dGlscy9saWJpYmVydHkvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5i aW4vYmludXRpbHMvbGliaWJlcnR5Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVk ZSAtREhBVkVfQ09ORklHX0ggIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5j bHVkZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2xpYmliZXJ0eS9zcGxheS10cmVlLmMN CmJ1aWxkaW5nIHN0YXRpYyBpYmVydHkgbGlicmFyeQ0KcmFubGliIGxpYmliZXJ0eS5hDQo9PT0+ IGdudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZA0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMv Z251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRp bHMvbGliYmZkLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9saWJiZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EX0dO VV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vLi4vLi4v Li4vY29udHJpYi9iaW51dGlscy9iZmQgLURTRUxFQ1RfQVJDSElURUNUVVJFUz0iICZiZmRfaTM4 Nl9hcmNoIiAtREhBVkVfYmZkX2VsZjMyX2kzODZfZnJlZWJzZF92ZWMgLURIQVZFX2JmZF9lbGYz Ml9pMzg2X3ZlYyAtRFNFTEVDVF9WRUNTPSIgJmJmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjICwm YmZkX2VsZjMyX2kzODZfdmVjIiAtRERFRkFVTFRfVkVDVE9SPWJmZF9lbGYzMl9pMzg2X2ZyZWVi c2RfdmVjICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vz ci9zcmMvY29udHJpYi9iaW51dGlscy9iZmQvY3B1LWkzODYuYw0KY2MgLU8gLXBpcGUgLUkuIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5i aW4vYmludXRpbHMvbGliYmZkLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUv dXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNs dWRlIC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQv Li4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQgLURTRUxFQ1RfQVJDSElURUNUVVJFUz0i ICZiZmRfaTM4Nl9hcmNoIiAtREhBVkVfYmZkX2VsZjMyX2kzODZfZnJlZWJzZF92ZWMgLURIQVZF X2JmZF9lbGYzMl9pMzg2X3ZlYyAtRFNFTEVDVF9WRUNTPSIgJmJmZF9lbGYzMl9pMzg2X2ZyZWVi c2RfdmVjICwmYmZkX2VsZjMyX2kzODZfdmVjIiAtRERFRkFVTFRfVkVDVE9SPWJmZF9lbGYzMl9p Mzg2X2ZyZWVic2RfdmVjICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1 ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9iaW51dGlscy9iZmQvZWxmMzItaTM4Ni5jDQpjYyAtTyAt cGlwZSAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQgLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3Ny Yy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uL2xpYmJmZCAtSS91 c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2Jp bnV0aWxzL2luY2x1ZGUgLURfR05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0 aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZCAtRFNFTEVDVF9BUkNI SVRFQ1RVUkVTPSIgJmJmZF9pMzg2X2FyY2giIC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl9mcmVlYnNk X3ZlYyAtREhBVkVfYmZkX2VsZjMyX2kzODZfdmVjIC1EU0VMRUNUX1ZFQ1M9IiAmYmZkX2VsZjMy X2kzODZfZnJlZWJzZF92ZWMgLCZiZmRfZWxmMzJfaTM4Nl92ZWMiIC1EREVGQVVMVF9WRUNUT1I9 YmZkX2VsZjMyX2kzODZfZnJlZWJzZF92ZWMgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2Fj eS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2JmZC9lbGYzMi5jDQpj YyAtTyAtcGlwZSAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQgLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vbGliYmZkIC1JL3Vzci9vYmov dXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uL2xpYmJm ZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250 cmliL2JpbnV0aWxzL2luY2x1ZGUgLURfR05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZCAtRFNFTEVD VF9BUkNISVRFQ1RVUkVTPSIgJmJmZF9pMzg2X2FyY2giIC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl9m cmVlYnNkX3ZlYyAtREhBVkVfYmZkX2VsZjMyX2kzODZfdmVjIC1EU0VMRUNUX1ZFQ1M9IiAmYmZk X2VsZjMyX2kzODZfZnJlZWJzZF92ZWMgLCZiZmRfZWxmMzJfaTM4Nl92ZWMiIC1EREVGQVVMVF9W RUNUT1I9YmZkX2VsZjMyX2kzODZfZnJlZWJzZF92ZWMgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2 L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2JmZC9lbGZs aW5rLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xp YmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi9saWJiZmQgLUkv dXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQv Li4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4u Ly4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251 L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZk IC1EU0VMRUNUX0FSQ0hJVEVDVFVSRVM9IiAmYmZkX2kzODZfYXJjaCIgLURIQVZFX2JmZF9lbGYz Ml9pMzg2X2ZyZWVic2RfdmVjIC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl92ZWMgLURTRUxFQ1RfVkVD Uz0iICZiZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAsJmJmZF9lbGYzMl9pMzg2X3ZlYyIgLURE RUZBVUxUX1ZFQ1RPUj1iZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAgLUkvdXNyL29iai91c3Iv c3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMv YmZkL2FyY2hpdmUuYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uL2xp YmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2xpYmJmZC8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQv Li4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EX0dOVV9TT1VSQ0UgLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51 dGlscy9iZmQgLURTRUxFQ1RfQVJDSElURUNUVVJFUz0iICZiZmRfaTM4Nl9hcmNoIiAtREhBVkVf YmZkX2VsZjMyX2kzODZfZnJlZWJzZF92ZWMgLURIQVZFX2JmZF9lbGYzMl9pMzg2X3ZlYyAtRFNF TEVDVF9WRUNTPSIgJmJmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjICwmYmZkX2VsZjMyX2kzODZf dmVjIiAtRERFRkFVTFRfVkVDVE9SPWJmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjICAtSS91c3Iv b2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9i aW51dGlscy9iZmQvYXJjaGl2ZTY0LmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xp YmJmZC8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJp bi9iaW51dGlscy9saWJiZmQvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRp bHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRF9HTlVfU09V UkNFIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2Nv bnRyaWIvYmludXRpbHMvYmZkIC1EU0VMRUNUX0FSQ0hJVEVDVFVSRVM9IiAmYmZkX2kzODZfYXJj aCIgLURIQVZFX2JmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjIC1ESEFWRV9iZmRfZWxmMzJfaTM4 Nl92ZWMgLURTRUxFQ1RfVkVDUz0iICZiZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAsJmJmZF9l bGYzMl9pMzg2X3ZlYyIgLURERUZBVUxUX1ZFQ1RPUj1iZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3Zl YyAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3Jj L2NvbnRyaWIvYmludXRpbHMvYmZkL2FyY2h1cmVzLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2Jp bnV0aWxzL2xpYmJmZC8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5i aW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAt RF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4u Ly4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZkIC1EU0VMRUNUX0FSQ0hJVEVDVFVSRVM9IiAmYmZk X2kzODZfYXJjaCIgLURIQVZFX2JmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjIC1ESEFWRV9iZmRf ZWxmMzJfaTM4Nl92ZWMgLURTRUxFQ1RfVkVDUz0iICZiZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3Zl YyAsJmJmZF9lbGYzMl9pMzg2X3ZlYyIgLURERUZBVUxUX1ZFQ1RPUj1iZmRfZWxmMzJfaTM4Nl9m cmVlYnNkX3ZlYyAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1j IC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvYmZkL2JmZC5jDQpjYyAtTyAtcGlwZSAtSS4gLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi9iaW51dGlscy9saWJiZmQvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9z cmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2luY2x1 ZGUgLURfR05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8u Li8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZCAtRFNFTEVDVF9BUkNISVRFQ1RVUkVTPSIg JmJmZF9pMzg2X2FyY2giIC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAtREhBVkVf YmZkX2VsZjMyX2kzODZfdmVjIC1EU0VMRUNUX1ZFQ1M9IiAmYmZkX2VsZjMyX2kzODZfZnJlZWJz ZF92ZWMgLCZiZmRfZWxmMzJfaTM4Nl92ZWMiIC1EREVGQVVMVF9WRUNUT1I9YmZkX2VsZjMyX2kz ODZfZnJlZWJzZF92ZWMgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVk ZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2JmZC9iZmR3aW4uYw0KY2MgLU8gLXBpcGUg LUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkIC1JL3Vzci9zcmMvZ251 L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4 Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi9saWJiZmQgLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGls cy9pbmNsdWRlIC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9s aWJiZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQgLURTRUxFQ1RfQVJDSElURUNU VVJFUz0iICZiZmRfaTM4Nl9hcmNoIiAtREhBVkVfYmZkX2VsZjMyX2kzODZfZnJlZWJzZF92ZWMg LURIQVZFX2JmZF9lbGYzMl9pMzg2X3ZlYyAtRFNFTEVDVF9WRUNTPSIgJmJmZF9lbGYzMl9pMzg2 X2ZyZWVic2RfdmVjICwmYmZkX2VsZjMyX2kzODZfdmVjIiAtRERFRkFVTFRfVkVDVE9SPWJmZF9l bGYzMl9pMzg2X2ZyZWVic2RfdmVjICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNy L2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9iaW51dGlscy9iZmQvYmluYXJ5LmMNCmNjIC1P IC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZCAtSS91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi9saWJiZmQgLUkvdXNyL29iai91c3Iv c3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vbGliYmZkIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIv YmludXRpbHMvaW5jbHVkZSAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZkIC1EU0VMRUNUX0FS Q0hJVEVDVFVSRVM9IiAmYmZkX2kzODZfYXJjaCIgLURIQVZFX2JmZF9lbGYzMl9pMzg2X2ZyZWVi c2RfdmVjIC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl92ZWMgLURTRUxFQ1RfVkVDUz0iICZiZmRfZWxm MzJfaTM4Nl9mcmVlYnNkX3ZlYyAsJmJmZF9lbGYzMl9pMzg2X3ZlYyIgLURERUZBVUxUX1ZFQ1RP Uj1iZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVn YWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvYmZkL2NhY2hlLmMN CmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZCAt SS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi9saWJiZmQgLUkvdXNyL29i ai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vbGli YmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2Nv bnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vzci5i aW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZkIC1EU0VM RUNUX0FSQ0hJVEVDVFVSRVM9IiAmYmZkX2kzODZfYXJjaCIgLURIQVZFX2JmZF9lbGYzMl9pMzg2 X2ZyZWVic2RfdmVjIC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl92ZWMgLURTRUxFQ1RfVkVDUz0iICZi ZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAsJmJmZF9lbGYzMl9pMzg2X3ZlYyIgLURERUZBVUxU X1ZFQ1RPUj1iZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAgLUkvdXNyL29iai91c3Ivc3JjL2kz ODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvYmZkL2Nv ZmZnZW4uYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMv bGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uL2xpYmJmZCAt SS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJm ZC8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vLi4v Li4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9i ZmQgLURTRUxFQ1RfQVJDSElURUNUVVJFUz0iICZiZmRfaTM4Nl9hcmNoIiAtREhBVkVfYmZkX2Vs ZjMyX2kzODZfZnJlZWJzZF92ZWMgLURIQVZFX2JmZF9lbGYzMl9pMzg2X3ZlYyAtRFNFTEVDVF9W RUNTPSIgJmJmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjICwmYmZkX2VsZjMyX2kzODZfdmVjIiAt RERFRkFVTFRfVkVDVE9SPWJmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjICAtSS91c3Ivb2JqL3Vz ci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9iaW51dGls cy9iZmQvY29yZWZpbGUuYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4u L2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0 aWxzL2xpYmJmZC8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJi ZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EX0dOVV9TT1VSQ0UgLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vLi4vLi4vLi4vY29udHJpYi9i aW51dGlscy9iZmQgLURTRUxFQ1RfQVJDSElURUNUVVJFUz0iICZiZmRfaTM4Nl9hcmNoIiAtREhB VkVfYmZkX2VsZjMyX2kzODZfZnJlZWJzZF92ZWMgLURIQVZFX2JmZF9lbGYzMl9pMzg2X3ZlYyAt RFNFTEVDVF9WRUNTPSIgJmJmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjICwmYmZkX2VsZjMyX2kz ODZfdmVjIiAtRERFRkFVTFRfVkVDVE9SPWJmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjICAtSS91 c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJp Yi9iaW51dGlscy9iZmQvZWxmLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJm ZC8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9saWJiZmQvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMv bGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRF9HTlVfU09VUkNF IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRy aWIvYmludXRpbHMvYmZkIC1EU0VMRUNUX0FSQ0hJVEVDVFVSRVM9IiAmYmZkX2kzODZfYXJjaCIg LURIQVZFX2JmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjIC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl92 ZWMgLURTRUxFQ1RfVkVDUz0iICZiZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAsJmJmZF9lbGYz Ml9pMzg2X3ZlYyIgLURERUZBVUxUX1ZFQ1RPUj1iZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAg LUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2Nv bnRyaWIvYmludXRpbHMvYmZkL2VsZi1laC1mcmFtZS5jDQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9saWJiZmQvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMv Z251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2luY2x1ZGUg LURfR05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi8u Li8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZCAtRFNFTEVDVF9BUkNISVRFQ1RVUkVTPSIgJmJm ZF9pMzg2X2FyY2giIC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAtREhBVkVfYmZk X2VsZjMyX2kzODZfdmVjIC1EU0VMRUNUX1ZFQ1M9IiAmYmZkX2VsZjMyX2kzODZfZnJlZWJzZF92 ZWMgLCZiZmRfZWxmMzJfaTM4Nl92ZWMiIC1EREVGQVVMVF9WRUNUT1I9YmZkX2VsZjMyX2kzODZf ZnJlZWJzZF92ZWMgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAt YyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2JmZC9lbGYtc3RydGFiLmMNCmNjIC1PIC1waXBl IC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZCAtSS91c3Ivc3JjL2du dS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kz ODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vbGliYmZkIC1JL3Vzci9z cmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRp bHMvaW5jbHVkZSAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMv bGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZkIC1EU0VMRUNUX0FSQ0hJVEVD VFVSRVM9IiAmYmZkX2kzODZfYXJjaCIgLURIQVZFX2JmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVj IC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl92ZWMgLURTRUxFQ1RfVkVDUz0iICZiZmRfZWxmMzJfaTM4 Nl9mcmVlYnNkX3ZlYyAsJmJmZF9lbGYzMl9pMzg2X3ZlYyIgLURERUZBVUxUX1ZFQ1RPUj1iZmRf ZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vz ci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvYmZkL2Zvcm1hdC5jDQpjYyAt TyAtcGlwZSAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQgLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNy L3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uL2xpYmJmZCAt SS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmli L2JpbnV0aWxzL2luY2x1ZGUgLURfR05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2Jp bnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZCAtRFNFTEVDVF9B UkNISVRFQ1RVUkVTPSIgJmJmZF9pMzg2X2FyY2giIC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl9mcmVl YnNkX3ZlYyAtREhBVkVfYmZkX2VsZjMyX2kzODZfdmVjIC1EU0VMRUNUX1ZFQ1M9IiAmYmZkX2Vs ZjMyX2kzODZfZnJlZWJzZF92ZWMgLCZiZmRfZWxmMzJfaTM4Nl92ZWMiIC1EREVGQVVMVF9WRUNU T1I9YmZkX2VsZjMyX2kzODZfZnJlZWJzZF92ZWMgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xl Z2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2JmZC9oYXNoLmMN CmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZCAt SS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi9saWJiZmQgLUkvdXNyL29i ai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vbGli YmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2Nv bnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vzci5i aW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZkIC1EU0VM RUNUX0FSQ0hJVEVDVFVSRVM9IiAmYmZkX2kzODZfYXJjaCIgLURIQVZFX2JmZF9lbGYzMl9pMzg2 X2ZyZWVic2RfdmVjIC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl92ZWMgLURTRUxFQ1RfVkVDUz0iICZi ZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAsJmJmZF9lbGYzMl9pMzg2X3ZlYyIgLURERUZBVUxU X1ZFQ1RPUj1iZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAgLUkvdXNyL29iai91c3Ivc3JjL2kz ODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvYmZkL2lo ZXguYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGli YmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uL2xpYmJmZCAtSS91 c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8u Li9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vLi4vLi4v Li4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUv dXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQg LURTRUxFQ1RfQVJDSElURUNUVVJFUz0iICZiZmRfaTM4Nl9hcmNoIiAtREhBVkVfYmZkX2VsZjMy X2kzODZfZnJlZWJzZF92ZWMgLURIQVZFX2JmZF9lbGYzMl9pMzg2X3ZlYyAtRFNFTEVDVF9WRUNT PSIgJmJmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjICwmYmZkX2VsZjMyX2kzODZfdmVjIiAtRERF RkFVTFRfVkVDVE9SPWJmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjICAtSS91c3Ivb2JqL3Vzci9z cmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9iaW51dGlscy9i ZmQvaW5pdC5jDQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vbGliYmZk IC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGli YmZkLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi8u Li8uLi8uLi9jb250cmliL2JpbnV0aWxzL2luY2x1ZGUgLURfR05VX1NPVVJDRSAtSS91c3Ivc3Jj L2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxz L2JmZCAtRFNFTEVDVF9BUkNISVRFQ1RVUkVTPSIgJmJmZF9pMzg2X2FyY2giIC1ESEFWRV9iZmRf ZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAtREhBVkVfYmZkX2VsZjMyX2kzODZfdmVjIC1EU0VMRUNU X1ZFQ1M9IiAmYmZkX2VsZjMyX2kzODZfZnJlZWJzZF92ZWMgLCZiZmRfZWxmMzJfaTM4Nl92ZWMi IC1EREVGQVVMVF9WRUNUT1I9YmZkX2VsZjMyX2kzODZfZnJlZWJzZF92ZWMgIC1JL3Vzci9vYmov dXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0 aWxzL2JmZC9saWJiZmQuYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4u L2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0 aWxzL2xpYmJmZC8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJi ZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EX0dOVV9TT1VSQ0UgLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vLi4vLi4vLi4vY29udHJpYi9i aW51dGlscy9iZmQgLURTRUxFQ1RfQVJDSElURUNUVVJFUz0iICZiZmRfaTM4Nl9hcmNoIiAtREhB VkVfYmZkX2VsZjMyX2kzODZfZnJlZWJzZF92ZWMgLURIQVZFX2JmZF9lbGYzMl9pMzg2X3ZlYyAt RFNFTEVDVF9WRUNTPSIgJmJmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjICwmYmZkX2VsZjMyX2kz ODZfdmVjIiAtRERFRkFVTFRfVkVDVE9SPWJmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjICAtSS91 c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJp Yi9iaW51dGlscy9iZmQvbGlua2VyLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xp YmJmZC8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJp bi9iaW51dGlscy9saWJiZmQvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRp bHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRF9HTlVfU09V UkNFIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2Nv bnRyaWIvYmludXRpbHMvYmZkIC1EU0VMRUNUX0FSQ0hJVEVDVFVSRVM9IiAmYmZkX2kzODZfYXJj aCIgLURIQVZFX2JmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjIC1ESEFWRV9iZmRfZWxmMzJfaTM4 Nl92ZWMgLURTRUxFQ1RfVkVDUz0iICZiZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAsJmJmZF9l bGYzMl9pMzg2X3ZlYyIgLURERUZBVUxUX1ZFQ1RPUj1iZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3Zl YyAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3Jj L2NvbnRyaWIvYmludXRpbHMvYmZkL21lcmdlLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3Jj L2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0 aWxzL2xpYmJmZC8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUv dXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRF9H TlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4u Ly4uL2NvbnRyaWIvYmludXRpbHMvYmZkIC1EU0VMRUNUX0FSQ0hJVEVDVFVSRVM9IiAmYmZkX2kz ODZfYXJjaCIgLURIQVZFX2JmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjIC1ESEFWRV9iZmRfZWxm MzJfaTM4Nl92ZWMgLURTRUxFQ1RfVkVDUz0iICZiZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAs JmJmZF9lbGYzMl9pMzg2X3ZlYyIgLURERUZBVUxUX1ZFQ1RPUj1iZmRfZWxmMzJfaTM4Nl9mcmVl YnNkX3ZlYyAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91 c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvYmZkL29wbmNscy5jDQpjYyAtTyAtcGlwZSAtSS4gLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi9iaW51dGlscy9saWJiZmQvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9z cmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2luY2x1 ZGUgLURfR05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8u Li8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZCAtRFNFTEVDVF9BUkNISVRFQ1RVUkVTPSIg JmJmZF9pMzg2X2FyY2giIC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAtREhBVkVf YmZkX2VsZjMyX2kzODZfdmVjIC1EU0VMRUNUX1ZFQ1M9IiAmYmZkX2VsZjMyX2kzODZfZnJlZWJz ZF92ZWMgLCZiZmRfZWxmMzJfaTM4Nl92ZWMiIC1EREVGQVVMVF9WRUNUT1I9YmZkX2VsZjMyX2kz ODZfZnJlZWJzZF92ZWMgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVk ZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2JmZC9yZWxvYy5jDQpjYyAtTyAtcGlwZSAt SS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQgLUkvdXNyL3NyYy9nbnUv dXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2 L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uL2xpYmJmZCAtSS91c3Ivc3Jj L2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxz L2luY2x1ZGUgLURfR05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xp YmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZCAtRFNFTEVDVF9BUkNISVRFQ1RV UkVTPSIgJmJmZF9pMzg2X2FyY2giIC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAt REhBVkVfYmZkX2VsZjMyX2kzODZfdmVjIC1EU0VMRUNUX1ZFQ1M9IiAmYmZkX2VsZjMyX2kzODZf ZnJlZWJzZF92ZWMgLCZiZmRfZWxmMzJfaTM4Nl92ZWMiIC1EREVGQVVMVF9WRUNUT1I9YmZkX2Vs ZjMyX2kzODZfZnJlZWJzZF92ZWMgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3Iv aW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2JmZC9zZWN0aW9uLmMNCmNjIC1P IC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZCAtSS91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi9saWJiZmQgLUkvdXNyL29iai91c3Iv c3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vbGliYmZkIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIv YmludXRpbHMvaW5jbHVkZSAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZkIC1EU0VMRUNUX0FS Q0hJVEVDVFVSRVM9IiAmYmZkX2kzODZfYXJjaCIgLURIQVZFX2JmZF9lbGYzMl9pMzg2X2ZyZWVi c2RfdmVjIC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl92ZWMgLURTRUxFQ1RfVkVDUz0iICZiZmRfZWxm MzJfaTM4Nl9mcmVlYnNkX3ZlYyAsJmJmZF9lbGYzMl9pMzg2X3ZlYyIgLURERUZBVUxUX1ZFQ1RP Uj1iZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVn YWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvYmZkL3NyZWMuYw0K Y2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uL2xpYmJmZCAtSS91c3Ivb2Jq L3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi9saWJi ZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vLi4vLi4vLi4vY29u dHJpYi9iaW51dGlscy9pbmNsdWRlIC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi9iaW51dGlscy9saWJiZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQgLURTRUxF Q1RfQVJDSElURUNUVVJFUz0iICZiZmRfaTM4Nl9hcmNoIiAtREhBVkVfYmZkX2VsZjMyX2kzODZf ZnJlZWJzZF92ZWMgLURIQVZFX2JmZF9lbGYzMl9pMzg2X3ZlYyAtRFNFTEVDVF9WRUNTPSIgJmJm ZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjICwmYmZkX2VsZjMyX2kzODZfdmVjIiAtRERFRkFVTFRf VkVDVE9SPWJmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4 Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9iaW51dGlscy9iZmQvc3Rh Yi1zeW1zLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi9saWJiZmQg LUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJi ZmQvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4u Ly4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMv Z251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMv YmZkIC1EU0VMRUNUX0FSQ0hJVEVDVFVSRVM9IiAmYmZkX2kzODZfYXJjaCIgLURIQVZFX2JmZF9l bGYzMl9pMzg2X2ZyZWVic2RfdmVjIC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl92ZWMgLURTRUxFQ1Rf VkVDUz0iICZiZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAsJmJmZF9lbGYzMl9pMzg2X3ZlYyIg LURERUZBVUxUX1ZFQ1RPUj1iZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAgLUkvdXNyL29iai91 c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmludXRp bHMvYmZkL3N0YWJzLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2Jp bnV0aWxzL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi9s aWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9saWJiZmQvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZk Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRF9HTlVfU09VUkNFIC1JL3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmlu dXRpbHMvYmZkIC1EU0VMRUNUX0FSQ0hJVEVDVFVSRVM9IiAmYmZkX2kzODZfYXJjaCIgLURIQVZF X2JmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjIC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl92ZWMgLURT RUxFQ1RfVkVDUz0iICZiZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAsJmJmZF9lbGYzMl9pMzg2 X3ZlYyIgLURERUZBVUxUX1ZFQ1RPUj1iZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAgLUkvdXNy L29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIv YmludXRpbHMvYmZkL3N5bXMuYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5i aW4vYmludXRpbHMvbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZk Ly4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2Jp bnV0aWxzL2xpYmJmZC8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9s aWJiZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EX0dOVV9TT1VSQ0Ug LUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vLi4vLi4vLi4vY29udHJp Yi9iaW51dGlscy9iZmQgLURTRUxFQ1RfQVJDSElURUNUVVJFUz0iICZiZmRfaTM4Nl9hcmNoIiAt REhBVkVfYmZkX2VsZjMyX2kzODZfZnJlZWJzZF92ZWMgLURIQVZFX2JmZF9lbGYzMl9pMzg2X3Zl YyAtRFNFTEVDVF9WRUNTPSIgJmJmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjICwmYmZkX2VsZjMy X2kzODZfdmVjIiAtRERFRkFVTFRfVkVDVE9SPWJmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjICAt SS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29u dHJpYi9iaW51dGlscy9iZmQvdGFyZ2V0cy5jDQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9saWJiZmQvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvbGliYmZkLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2Jp bnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2luY2x1ZGUgLURfR05V X1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8u Li9jb250cmliL2JpbnV0aWxzL2JmZCAtRFNFTEVDVF9BUkNISVRFQ1RVUkVTPSIgJmJmZF9pMzg2 X2FyY2giIC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl9mcmVlYnNkX3ZlYyAtREhBVkVfYmZkX2VsZjMy X2kzODZfdmVjIC1EU0VMRUNUX1ZFQ1M9IiAmYmZkX2VsZjMyX2kzODZfZnJlZWJzZF92ZWMgLCZi ZmRfZWxmMzJfaTM4Nl92ZWMiIC1EREVGQVVMVF9WRUNUT1I9YmZkX2VsZjMyX2kzODZfZnJlZWJz ZF92ZWMgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNy L3NyYy9jb250cmliL2JpbnV0aWxzL2JmZC90ZWtoZXguYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvbGliYmZkLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3Jj L2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNy LmJpbi9iaW51dGlscy9saWJiZmQvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRl IC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4v Li4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQgLURTRUxFQ1RfQVJDSElURUNUVVJFUz0iICZi ZmRfaTM4Nl9hcmNoIiAtREhBVkVfYmZkX2VsZjMyX2kzODZfZnJlZWJzZF92ZWMgLURIQVZFX2Jm ZF9lbGYzMl9pMzg2X3ZlYyAtRFNFTEVDVF9WRUNTPSIgJmJmZF9lbGYzMl9pMzg2X2ZyZWVic2Rf dmVjICwmYmZkX2VsZjMyX2kzODZfdmVjIiAtRERFRkFVTFRfVkVDVE9SPWJmZF9lbGYzMl9pMzg2 X2ZyZWVic2RfdmVjICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUg LWMgL3Vzci9zcmMvY29udHJpYi9iaW51dGlscy9iZmQvZHdhcmYxLmMNCmNjIC1PIC1waXBlIC1J LiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYv dXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vbGliYmZkIC1JL3Vzci9zcmMv Z251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMv aW5jbHVkZSAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGli YmZkLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZkIC1EU0VMRUNUX0FSQ0hJVEVDVFVS RVM9IiAmYmZkX2kzODZfYXJjaCIgLURIQVZFX2JmZF9lbGYzMl9pMzg2X2ZyZWVic2RfdmVjIC1E SEFWRV9iZmRfZWxmMzJfaTM4Nl92ZWMgLURTRUxFQ1RfVkVDUz0iICZiZmRfZWxmMzJfaTM4Nl9m cmVlYnNkX3ZlYyAsJmJmZF9lbGYzMl9pMzg2X3ZlYyIgLURERUZBVUxUX1ZFQ1RPUj1iZmRfZWxm MzJfaTM4Nl9mcmVlYnNkX3ZlYyAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9p bmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvYmZkL2R3YXJmMi5jDQpjYyAtTyAt cGlwZSAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQgLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3Ny Yy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uL2xpYmJmZCAtSS91 c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2Jp bnV0aWxzL2luY2x1ZGUgLURfR05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0 aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZCAtRFNFTEVDVF9BUkNI SVRFQ1RVUkVTPSIgJmJmZF9pMzg2X2FyY2giIC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl9mcmVlYnNk X3ZlYyAtREhBVkVfYmZkX2VsZjMyX2kzODZfdmVjIC1EU0VMRUNUX1ZFQ1M9IiAmYmZkX2VsZjMy X2kzODZfZnJlZWJzZF92ZWMgLCZiZmRfZWxmMzJfaTM4Nl92ZWMiIC1EREVGQVVMVF9WRUNUT1I9 YmZkX2VsZjMyX2kzODZfZnJlZWJzZF92ZWMgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2Fj eS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2JmZC9iZmRpby5jDQpj YyAtTyAtcGlwZSAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQgLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiZmQvLi4vbGliYmZkIC1JL3Vzci9vYmov dXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmZkLy4uL2xpYmJm ZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250 cmliL2JpbnV0aWxzL2luY2x1ZGUgLURfR05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2xpYmJmZC8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZCAtRFNFTEVD VF9BUkNISVRFQ1RVUkVTPSIgJmJmZF9pMzg2X2FyY2giIC1ESEFWRV9iZmRfZWxmMzJfaTM4Nl9m cmVlYnNkX3ZlYyAtREhBVkVfYmZkX2VsZjMyX2kzODZfdmVjIC1EU0VMRUNUX1ZFQ1M9IiAmYmZk X2VsZjMyX2kzODZfZnJlZWJzZF92ZWMgLCZiZmRfZWxmMzJfaTM4Nl92ZWMiIC1EREVGQVVMVF9W RUNUT1I9YmZkX2VsZjMyX2kzODZfZnJlZWJzZF92ZWMgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2 L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2JmZC9zaW1w bGUuYw0KYnVpbGRpbmcgc3RhdGljIGJmZCBsaWJyYXJ5DQpyYW5saWIgbGliYmZkLmENCj09PT4g Z251L3Vzci5iaW4vYmludXRpbHMvbGlib3Bjb2Rlcw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9z cmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGlib3Bjb2RlcyAtSS91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2xpYm9wY29kZXMvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGlib3Bjb2Rlcy8uLi9saWJiZmQgLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJvcGNvZGVzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmlu dXRpbHMvaW5jbHVkZSAtREFSQ0hfaTM4NiAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvbGlib3Bjb2Rlcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL29w Y29kZXMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJvcGNvZGVzLy4uLy4uLy4u Ly4uL2NvbnRyaWIvYmludXRpbHMvYmZkICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kv dXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9iaW51dGlscy9vcGNvZGVzL2kzODYtZGlz LmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYm9w Y29kZXMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJvcGNvZGVzLy4uL2xpYmJm ZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xp Ym9wY29kZXMvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGlib3Bj b2Rlcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2luY2x1ZGUgLURBUkNIX2kzODYgLURf R05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYm9wY29kZXMvLi4v Li4vLi4vLi4vY29udHJpYi9iaW51dGlscy9vcGNvZGVzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvbGlib3Bjb2Rlcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZCAgLUkv dXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRy aWIvYmludXRpbHMvb3Bjb2Rlcy9kaXMtYnVmLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3Jj L2dudS91c3IuYmluL2JpbnV0aWxzL2xpYm9wY29kZXMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9saWJvcGNvZGVzLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYm9wY29kZXMvLi4vbGliYmZkIC1JL3Vzci9zcmMv Z251L3Vzci5iaW4vYmludXRpbHMvbGlib3Bjb2Rlcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0 aWxzL2luY2x1ZGUgLURBUkNIX2kzODYgLURfR05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL2xpYm9wY29kZXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9vcGNv ZGVzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGlib3Bjb2Rlcy8uLi8uLi8uLi8u Li9jb250cmliL2JpbnV0aWxzL2JmZCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vz ci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvb3Bjb2Rlcy9kaXMtaW5pdC5j DQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJvcGNv ZGVzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGlib3Bjb2Rlcy8uLi9saWJiZmQg LUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJv cGNvZGVzLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYm9wY29k ZXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EQVJDSF9pMzg2IC1EX0dO VV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJvcGNvZGVzLy4uLy4u Ly4uLy4uL2NvbnRyaWIvYmludXRpbHMvb3Bjb2RlcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2Jp bnV0aWxzL2xpYm9wY29kZXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQgIC1JL3Vz ci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmli L2JpbnV0aWxzL29wY29kZXMvZGlzYXNzZW1ibGUuYw0KYnVpbGRpbmcgc3RhdGljIG9wY29kZXMg bGlicmFyeQ0KcmFubGliIGxpYm9wY29kZXMuYQ0KPT09PiBnbnUvdXNyLmJpbi9iaW51dGlscy9s aWJiaW51dGlscw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRp bHMvbGliYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGls cy8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9saWJiaW51dGlscy8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51 dGlscy9saWJiaW51dGlscy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2luY2x1ZGUgLURU QVJHRVQ9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURCRkRfVkVSU0lPTl9TVFJJTkc9XCIiMi4x NSBbRnJlZUJTRF0gMjAwNC0wNS0yMyJcIiAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9i aW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uLy4u Ly4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZkICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdh Y3kvdXNyL2luY2x1ZGUgLWMgYXJsZXguYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251 L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51 dGlscy9saWJiaW51dGlscy8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscy8uLi9saWJiZmQgLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0 aWxzL2luY2x1ZGUgLURUQVJHRVQ9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURCRkRfVkVSU0lP Tl9TVFJJTkc9XCIiMi4xNSBbRnJlZUJTRF0gMjAwNC0wNS0yMyJcIiAtRF9HTlVfU09VUkNFIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vLi4vLi4vLi4vY29u dHJpYi9iaW51dGlscy9iaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xp YmJpbnV0aWxzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZkICAtSS91c3Ivb2JqL3Vz ci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgYXJwYXJzZS5jDQpjYyAtTyAtcGlwZSAt SS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscyAtSS91c3Ivc3Jj L2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vz ci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uL2xp YmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uLy4uLy4u Ly4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRFRBUkdFVD1cImkzODYtb2JyaWVuLWZyZWVi c2RcIiAtREJGRF9WRVJTSU9OX1NUUklORz1cIiIyLjE1IFtGcmVlQlNEXSAyMDA0LTA1LTIzIlwi IC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGls cy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxzIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9i ZmQgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3Ny Yy9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxzL2Fyc3VwLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91 c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9p Mzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vbGliYmZkIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vLi4vLi4vLi4vY29u dHJpYi9iaW51dGlscy9pbmNsdWRlIC1EVEFSR0VUPVwiaTM4Ni1vYnJpZW4tZnJlZWJzZFwiIC1E QkZEX1ZFUlNJT05fU1RSSU5HPVwiIjIuMTUgW0ZyZWVCU0RdIDIwMDQtMDUtMjMiXCIgLURfR05V X1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uLy4u Ly4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9saWJiaW51dGlscy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZCAgLUkv dXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRy aWIvYmludXRpbHMvYmludXRpbHMvYnVjb21tLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3Jj L2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvbGliYmludXRpbHMvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vbGliYmZkIC1JL3Vzci9z cmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vLi4vLi4vLi4vY29udHJpYi9i aW51dGlscy9pbmNsdWRlIC1EVEFSR0VUPVwiaTM4Ni1vYnJpZW4tZnJlZWJzZFwiIC1EQkZEX1ZF UlNJT05fU1RSSU5HPVwiIjIuMTUgW0ZyZWVCU0RdIDIwMDQtMDUtMjMiXCIgLURfR05VX1NPVVJD RSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uLy4uLy4uLy4u L2NvbnRyaWIvYmludXRpbHMvYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9saWJiaW51dGlscy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZCAgLUkvdXNyL29i ai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmlu dXRpbHMvYmludXRpbHMvZGVidWcuYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvbGliYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9saWJiaW51dGlscy8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscy8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUv dXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxz L2luY2x1ZGUgLURUQVJHRVQ9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURCRkRfVkVSU0lPTl9T VFJJTkc9XCIiMi4xNSBbRnJlZUJTRF0gMjAwNC0wNS0yMyJcIiAtRF9HTlVfU09VUkNFIC1JL3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vLi4vLi4vLi4vY29udHJp Yi9iaW51dGlscy9iaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJp bnV0aWxzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZkICAtSS91c3Ivb2JqL3Vzci9z cmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9iaW51dGlscy9i aW51dGlscy9maWxlbW9kZS5jDQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi9iaW51dGlscy9saWJiaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xp YmJpbnV0aWxzLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5j bHVkZSAtRFRBUkdFVD1cImkzODYtb2JyaWVuLWZyZWVic2RcIiAtREJGRF9WRVJTSU9OX1NUUklO Rz1cIiIyLjE1IFtGcmVlQlNEXSAyMDA0LTA1LTIzIlwiIC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscy8uLi8uLi8uLi8uLi9jb250cmliL2Jp bnV0aWxzL2JpbnV0aWxzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRp bHMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQgIC1JL3Vzci9vYmovdXNyL3NyYy9p Mzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2JpbnV0 aWxzL2llZWUuYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRp bHMvbGliYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGls cy8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9saWJiaW51dGlscy8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51 dGlscy9saWJiaW51dGlscy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2luY2x1ZGUgLURU QVJHRVQ9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURCRkRfVkVSU0lPTl9TVFJJTkc9XCIiMi4x NSBbRnJlZUJTRF0gMjAwNC0wNS0yMyJcIiAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9i aW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uLy4u Ly4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZkICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdh Y3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9iaW51dGlscy9iaW51dGlscy9yZGNv ZmYuYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGli YmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscy8uLi9s aWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9saWJiaW51dGlscy8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9s aWJiaW51dGlscy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2luY2x1ZGUgLURUQVJHRVQ9 XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURCRkRfVkVSU0lPTl9TVFJJTkc9XCIiMi4xNSBbRnJl ZUJTRF0gMjAwNC0wNS0yMyJcIiAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvbGliYmludXRpbHMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iaW51dGls cyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uLy4uLy4uLy4u L2NvbnRyaWIvYmludXRpbHMvYmZkICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNy L2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9iaW51dGlscy9iaW51dGlscy9yZGRiZy5jDQpj YyAtTyAtcGlwZSAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGls cyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uL2xpYmJmZCAt SS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJp bnV0aWxzLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0 aWxzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRFRBUkdFVD1cImkzODYt b2JyaWVuLWZyZWVic2RcIiAtREJGRF9WRVJTSU9OX1NUUklORz1cIiIyLjE1IFtGcmVlQlNEXSAy MDA0LTA1LTIzIlwiIC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9saWJiaW51dGlscy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxzIC1JL3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vLi4vLi4vLi4vY29udHJp Yi9iaW51dGlscy9iZmQgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVk ZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxzL3JlbmFtZS5jDQpjYyAtTyAt cGlwZSAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscyAtSS91 c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uL2xpYmJmZCAtSS91c3Iv b2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxz Ly4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4u Ly4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRFRBUkdFVD1cImkzODYtb2JyaWVu LWZyZWVic2RcIiAtREJGRF9WRVJTSU9OX1NUUklORz1cIiIyLjE1IFtGcmVlQlNEXSAyMDA0LTA1 LTIzIlwiIC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJi aW51dGlscy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxzIC1JL3Vzci9zcmMv Z251L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51 dGlscy9iZmQgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAv dXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxzL3N0YWJzLmMNCmNjIC1PIC1waXBlIC1J LiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzIC1JL3Vzci9zcmMv Z251L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNy L3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vbGli YmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vLi4vLi4v Li4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EVEFSR0VUPVwiaTM4Ni1vYnJpZW4tZnJlZWJz ZFwiIC1EQkZEX1ZFUlNJT05fU1RSSU5HPVwiIjIuMTUgW0ZyZWVCU0RdIDIwMDQtMDUtMjMiXCIg LURfR05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxz Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNy LmJpbi9iaW51dGlscy9saWJiaW51dGlscy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2Jm ZCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3Jj L2NvbnRyaWIvYmludXRpbHMvYmludXRpbHMvdW53aW5kLWlhNjQuYw0KY2MgLU8gLXBpcGUgLUku IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMgLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscy8uLi9saWJiZmQgLUkvdXNyL29iai91c3Iv c3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscy8uLi9saWJi ZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscy8uLi8uLi8uLi8u Li9jb250cmliL2JpbnV0aWxzL2luY2x1ZGUgLURUQVJHRVQ9XCJpMzg2LW9icmllbi1mcmVlYnNk XCIgLURCRkRfVkVSU0lPTl9TVFJJTkc9XCIiMi4xNSBbRnJlZUJTRF0gMjAwNC0wNS0yMyJcIiAt RF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMv Li4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZk ICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMv Y29udHJpYi9iaW51dGlscy9iaW51dGlscy93cnN0YWJzLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91 c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9p Mzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vbGliYmZkIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vLi4vLi4vLi4vY29u dHJpYi9iaW51dGlscy9pbmNsdWRlIC1EVEFSR0VUPVwiaTM4Ni1vYnJpZW4tZnJlZWJzZFwiIC1E QkZEX1ZFUlNJT05fU1RSSU5HPVwiIjIuMTUgW0ZyZWVCU0RdIDIwMDQtMDUtMjMiXCIgLURfR05V X1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uLy4u Ly4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9saWJiaW51dGlscy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZCAgLUkv dXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRy aWIvYmludXRpbHMvYmludXRpbHMvdmVyc2lvbi5jDQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91 c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uL2xpYmJmZCAtSS91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uLy4uLy4uLy4uL2NvbnRyaWIv YmludXRpbHMvaW5jbHVkZSAtRFRBUkdFVD1cImkzODYtb2JyaWVuLWZyZWVic2RcIiAtREJGRF9W RVJTSU9OX1NUUklORz1cIiIyLjE1IFtGcmVlQlNEXSAyMDA0LTA1LTIzIlwiIC1EX0dOVV9TT1VS Q0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscy8uLi8uLi8uLi8u Li9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRp bHMvbGliYmludXRpbHMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQgIC1JL3Vzci9v YmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL2Jp bnV0aWxzL2JpbnV0aWxzL2JpbmVtdWwuYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251 L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51 dGlscy9saWJiaW51dGlscy8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscy8uLi9saWJiZmQgLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0 aWxzL2luY2x1ZGUgLURUQVJHRVQ9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURCRkRfVkVSU0lP Tl9TVFJJTkc9XCIiMi4xNSBbRnJlZUJTRF0gMjAwNC0wNS0yMyJcIiAtRF9HTlVfU09VUkNFIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmludXRpbHMvLi4vLi4vLi4vLi4vY29u dHJpYi9iaW51dGlscy9iaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2xp YmJpbnV0aWxzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmZkICAtSS91c3Ivb2JqL3Vz ci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9iaW51dGls cy9iaW51dGlscy9idWRlbWFuZy5jDQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNyL3NyYy9nbnUvdXNy LmJpbi9iaW51dGlscy9saWJiaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2xpYmJpbnV0aWxzLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2du dS91c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2xpYmJpbnV0aWxzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMv aW5jbHVkZSAtRFRBUkdFVD1cImkzODYtb2JyaWVuLWZyZWVic2RcIiAtREJGRF9WRVJTSU9OX1NU UklORz1cIiIyLjE1IFtGcmVlQlNEXSAyMDA0LTA1LTIzIlwiIC1EX0dOVV9TT1VSQ0UgLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9saWJiaW51dGlscy8uLi8uLi8uLi8uLi9jb250cmli L2JpbnV0aWxzL2JpbnV0aWxzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvbGliYmlu dXRpbHMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQgIC1JL3Vzci9vYmovdXNyL3Ny Yy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2Jp bnV0aWxzL2VtdWxfdmFuaWxsYS5jDQpidWlsZGluZyBzdGF0aWMgYmludXRpbHMgbGlicmFyeQ0K cmFubGliIGxpYmJpbnV0aWxzLmENCj09PT4gZ251L3Vzci5iaW4vYmludXRpbHMvYWRkcjJsaW5l DQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hZGRyMmxp bmUgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hZGRyMmxpbmUvLi4vbGliYmZkIC1J L3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYWRkcjJs aW5lLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FkZHIybGluZS8u Li8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2luY2x1ZGUgLURfR05VX1NPVVJDRSAtSS91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FkZHIybGluZS8uLi9saWJiaW51dGlscyAtSS91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FkZHIybGluZS8uLi8uLi8uLi8uLi9jb250cmliL2Jp bnV0aWxzL2JpbnV0aWxzICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1 ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9iaW51dGlscy9iaW51dGlscy9hZGRyMmxpbmUuYw0KY2Mg LU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYWRkcjJsaW5lIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYWRkcjJsaW5lLy4uL2xpYmJmZCAtSS91c3Iv b2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FkZHIybGluZS8u Li9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hZGRyMmxpbmUvLi4vLi4v Li4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9hZGRyMmxpbmUvLi4vbGliYmludXRpbHMgLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9hZGRyMmxpbmUvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGls cy9iaW51dGlscyAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlICAt c3RhdGljIC1ML3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvbGliIC1vIGFkZHIybGlu ZSBhZGRyMmxpbmUubyAuLi9saWJiaW51dGlscy9saWJiaW51dGlscy5hIC4uL2xpYmJmZC9saWJi ZmQuYSAuLi9saWJpYmVydHkvbGliaWJlcnR5LmEgL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2Fj eS91c3IvbGliL2xpYmVnYWN5LmEgLWxlZ2FjeQ0KLi4vbGliYmludXRpbHMvbGliYmludXRpbHMu YShidWNvbW0ubyk6IEluIGZ1bmN0aW9uIGBtYWtlX3RlbXBuYW1lJzoNCmJ1Y29tbS5vKC50ZXh0 KzB4OTk5KTogd2FybmluZzogbWt0ZW1wKCkgcG9zc2libHkgdXNlZCB1bnNhZmVseTsgY29uc2lk ZXIgdXNpbmcgbWtzdGVtcCgpDQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxzL2FyDQpjYyAtTyAt cGlwZSAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hciAtSS91c3Ivc3JjL2du dS91c3IuYmluL2JpbnV0aWxzL2FyLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91 c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FyLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2FyLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAt RF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXIvLi4vbGliYmlu dXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hci8uLi8uLi8uLi8uLi9jb250 cmliL2JpbnV0aWxzL2JpbnV0aWxzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXIv Li4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9iZmQgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2 L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxz L2FyLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2Fy IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXIvLi4vbGliYmZkIC1JL3Vzci9vYmov dXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXIvLi4vbGliYmZkIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXIvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51 dGlscy9pbmNsdWRlIC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9hci8uLi9saWJiaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FyLy4u Ly4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi9iaW51dGlscy9hci8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JmZCAgLUkvdXNyL29i ai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmlu dXRpbHMvYmludXRpbHMvbm90LXJhbmxpYi5jDQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9hciAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2Fy Ly4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2Jp bnV0aWxzL2FyLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FyLy4u Ly4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRF9HTlVfU09VUkNFIC1JL3Vzci9z cmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXIvLi4vbGliYmludXRpbHMgLUkvdXNyL3NyYy9nbnUv dXNyLmJpbi9iaW51dGlscy9hci8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2JpbnV0aWxz IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXIvLi4vLi4vLi4vLi4vY29udHJpYi9i aW51dGlscy9iZmQgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAg LXN0YXRpYyAtTC91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2xpYiAtbyBhciBhci5v IG5vdC1yYW5saWIubyAuLi9saWJiaW51dGlscy9saWJiaW51dGlscy5hIC4uL2xpYmJmZC9saWJi ZmQuYSAuLi9saWJpYmVydHkvbGliaWJlcnR5LmEgL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2Fj eS91c3IvbGliL2xpYmVnYWN5LmEgLWxlZ2FjeQ0KLi4vbGliYmludXRpbHMvbGliYmludXRpbHMu YShidWNvbW0ubyk6IEluIGZ1bmN0aW9uIGBtYWtlX3RlbXBuYW1lJzoNCmJ1Y29tbS5vKC50ZXh0 KzB4OTk5KTogd2FybmluZzogbWt0ZW1wKCkgcG9zc2libHkgdXNlZCB1bnNhZmVseTsgY29uc2lk ZXIgdXNpbmcgbWtzdGVtcCgpDQo9PT0+IGdudS91c3IuYmluL2JpbnV0aWxzL2FzDQpjYyAtTyAt cGlwZSAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcyAtSS91c3Ivc3JjL2du dS91c3IuYmluL2JpbnV0aWxzL2FzLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91 c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAt RERFRkFVTFRfQVJDSD1cImkzODZcIiAtRFRBUkdFVF9DUFU9XCJpMzg2XCIgLURUQVJHRVRfQ0FO T05JQ0FMPVwiaTM4Ni1vYnJpZW4tZnJlZWJzZFwiIC1EVEFSR0VUX0FMSUFTPVwiaTM4Ni1vYnJp ZW4tZnJlZWJzZFwiIC1EVkVSU0lPTj1cIiIyLjE1IFtGcmVlQlNEXSAyMDA0LTA1LTIzIlwiIC1E X0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8u Li9jb250cmliL2JpbnV0aWxzL2dhcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2Fz Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvZ2FzL2NvbmZpZyAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMgLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2FzL2kzODYtZnJlZWJzZCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNs dWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvZ2FzL2FwcC5jDQpjYyAtTyAtcGlwZSAt SS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcyAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL2FzLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3Jj L2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRERFRkFV TFRfQVJDSD1cImkzODZcIiAtRFRBUkdFVF9DUFU9XCJpMzg2XCIgLURUQVJHRVRfQ0FOT05JQ0FM PVwiaTM4Ni1vYnJpZW4tZnJlZWJzZFwiIC1EVEFSR0VUX0FMSUFTPVwiaTM4Ni1vYnJpZW4tZnJl ZWJzZFwiIC1EVkVSU0lPTj1cIiIyLjE1IFtGcmVlQlNEXSAyMDA0LTA1LTIzIlwiIC1EX0dOVV9T T1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250 cmliL2JpbnV0aWxzL2dhcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4u Ly4uLy4uL2NvbnRyaWIvYmludXRpbHMvZ2FzL2NvbmZpZyAtSS91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMgLUkvdXNyL3NyYy9nbnUv dXNyLmJpbi9iaW51dGlscy9hcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzL2kz ODYtZnJlZWJzZCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1j IC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvZ2FzL2FzLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91 c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvYXMvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvYXMvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRp bHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EREVGQVVMVF9BUkNI PVwiaTM4NlwiIC1EVEFSR0VUX0NQVT1cImkzODZcIiAtRFRBUkdFVF9DQU5PTklDQUw9XCJpMzg2 LW9icmllbi1mcmVlYnNkXCIgLURUQVJHRVRfQUxJQVM9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIg LURWRVJTSU9OPVwiIjIuMTUgW0ZyZWVCU0RdIDIwMDQtMDUtMjMiXCIgLURfR05VX1NPVVJDRSAt SS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmlu dXRpbHMvZ2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4v Y29udHJpYi9iaW51dGlscy9nYXMvY29uZmlnIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRp bHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvaTM4Ni1mcmVl YnNkICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9z cmMvY29udHJpYi9iaW51dGlscy9nYXMvYXRvZi1nZW5lcmljLmMNCmNjIC1PIC1waXBlIC1JLiAt SS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvYXMvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251 L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EREVGQVVMVF9B UkNIPVwiaTM4NlwiIC1EVEFSR0VUX0NQVT1cImkzODZcIiAtRFRBUkdFVF9DQU5PTklDQUw9XCJp Mzg2LW9icmllbi1mcmVlYnNkXCIgLURUQVJHRVRfQUxJQVM9XCJpMzg2LW9icmllbi1mcmVlYnNk XCIgLURWRVJTSU9OPVwiIjIuMTUgW0ZyZWVCU0RdIDIwMDQtMDUtMjMiXCIgLURfR05VX1NPVVJD RSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIv YmludXRpbHMvZ2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4v Li4vY29udHJpYi9iaW51dGlscy9nYXMvY29uZmlnIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvaTM4Ni1m cmVlYnNkICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vz ci9zcmMvY29udHJpYi9iaW51dGlscy9nYXMvY29uZmlnL2F0b2YtaWVlZS5jDQpjYyAtTyAtcGlw ZSAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcyAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2FzLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRERF RkFVTFRfQVJDSD1cImkzODZcIiAtRFRBUkdFVF9DUFU9XCJpMzg2XCIgLURUQVJHRVRfQ0FOT05J Q0FMPVwiaTM4Ni1vYnJpZW4tZnJlZWJzZFwiIC1EVEFSR0VUX0FMSUFTPVwiaTM4Ni1vYnJpZW4t ZnJlZWJzZFwiIC1EVkVSU0lPTj1cIiIyLjE1IFtGcmVlQlNEXSAyMDA0LTA1LTIzIlwiIC1EX0dO VV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9j b250cmliL2JpbnV0aWxzL2dhcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4u Ly4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvZ2FzL2NvbmZpZyAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMgLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9hcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2Fz L2kzODYtZnJlZWJzZCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRl IC1jIC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvZ2FzL2JpZ251bS1jb3B5LmMNCmNjIC1PIC1w aXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251 L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1E REVGQVVMVF9BUkNIPVwiaTM4NlwiIC1EVEFSR0VUX0NQVT1cImkzODZcIiAtRFRBUkdFVF9DQU5P TklDQUw9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURUQVJHRVRfQUxJQVM9XCJpMzg2LW9icmll bi1mcmVlYnNkXCIgLURWRVJTSU9OPVwiIjIuMTUgW0ZyZWVCU0RdIDIwMDQtMDUtMjMiXCIgLURf R05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4u L2NvbnRyaWIvYmludXRpbHMvZ2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMv Li4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9nYXMvY29uZmlnIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscyAtSS91c3Ivc3Jj L2dudS91c3IuYmluL2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMv YXMvaTM4Ni1mcmVlYnNkICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1 ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9iaW51dGlscy9nYXMvY29uZC5jDQpjYyAtTyAtcGlwZSAt SS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcyAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL2FzLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3Jj L2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRERFRkFV TFRfQVJDSD1cImkzODZcIiAtRFRBUkdFVF9DUFU9XCJpMzg2XCIgLURUQVJHRVRfQ0FOT05JQ0FM PVwiaTM4Ni1vYnJpZW4tZnJlZWJzZFwiIC1EVEFSR0VUX0FMSUFTPVwiaTM4Ni1vYnJpZW4tZnJl ZWJzZFwiIC1EVkVSU0lPTj1cIiIyLjE1IFtGcmVlQlNEXSAyMDA0LTA1LTIzIlwiIC1EX0dOVV9T T1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250 cmliL2JpbnV0aWxzL2dhcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4u Ly4uLy4uL2NvbnRyaWIvYmludXRpbHMvZ2FzL2NvbmZpZyAtSS91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMgLUkvdXNyL3NyYy9nbnUv dXNyLmJpbi9iaW51dGlscy9hcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzL2kz ODYtZnJlZWJzZCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1j IC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvZ2FzL2R3YXJmMmRiZy5jDQpjYyAtTyAtcGlwZSAt SS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcyAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL2FzLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3Jj L2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRERFRkFV TFRfQVJDSD1cImkzODZcIiAtRFRBUkdFVF9DUFU9XCJpMzg2XCIgLURUQVJHRVRfQ0FOT05JQ0FM PVwiaTM4Ni1vYnJpZW4tZnJlZWJzZFwiIC1EVEFSR0VUX0FMSUFTPVwiaTM4Ni1vYnJpZW4tZnJl ZWJzZFwiIC1EVkVSU0lPTj1cIiIyLjE1IFtGcmVlQlNEXSAyMDA0LTA1LTIzIlwiIC1EX0dOVV9T T1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250 cmliL2JpbnV0aWxzL2dhcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4u Ly4uLy4uL2NvbnRyaWIvYmludXRpbHMvZ2FzL2NvbmZpZyAtSS91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMgLUkvdXNyL3NyYy9nbnUv dXNyLmJpbi9iaW51dGlscy9hcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzL2kz ODYtZnJlZWJzZCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1j IC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvZ2FzL2Vjb2ZmLmMNCmNjIC1PIC1waXBlIC1JLiAt SS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvYXMvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251 L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EREVGQVVMVF9B UkNIPVwiaTM4NlwiIC1EVEFSR0VUX0NQVT1cImkzODZcIiAtRFRBUkdFVF9DQU5PTklDQUw9XCJp Mzg2LW9icmllbi1mcmVlYnNkXCIgLURUQVJHRVRfQUxJQVM9XCJpMzg2LW9icmllbi1mcmVlYnNk XCIgLURWRVJTSU9OPVwiIjIuMTUgW0ZyZWVCU0RdIDIwMDQtMDUtMjMiXCIgLURfR05VX1NPVVJD RSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIv YmludXRpbHMvZ2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4v Li4vY29udHJpYi9iaW51dGlscy9nYXMvY29uZmlnIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvaTM4Ni1m cmVlYnNkICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vz ci9zcmMvY29udHJpYi9iaW51dGlscy9nYXMvZXhwci5jDQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0 aWxzL2FzLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL2FzLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRERFRkFVTFRfQVJDSD1c ImkzODZcIiAtRFRBUkdFVF9DUFU9XCJpMzg2XCIgLURUQVJHRVRfQ0FOT05JQ0FMPVwiaTM4Ni1v YnJpZW4tZnJlZWJzZFwiIC1EVEFSR0VUX0FMSUFTPVwiaTM4Ni1vYnJpZW4tZnJlZWJzZFwiIC1E VkVSU0lPTj1cIiIyLjE1IFtGcmVlQlNEXSAyMDA0LTA1LTIzIlwiIC1EX0dOVV9TT1VSQ0UgLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0 aWxzL2dhcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2Nv bnRyaWIvYmludXRpbHMvZ2FzL2NvbmZpZyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9hcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzL2kzODYtZnJlZWJz ZCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3Jj L2NvbnRyaWIvYmludXRpbHMvZ2FzL2Zsb251bS1jb3B5LmMNCmNjIC1PIC1waXBlIC1JLiAtSS91 c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvYXMvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvYXMvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRp bHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EREVGQVVMVF9BUkNI PVwiaTM4NlwiIC1EVEFSR0VUX0NQVT1cImkzODZcIiAtRFRBUkdFVF9DQU5PTklDQUw9XCJpMzg2 LW9icmllbi1mcmVlYnNkXCIgLURUQVJHRVRfQUxJQVM9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIg LURWRVJTSU9OPVwiIjIuMTUgW0ZyZWVCU0RdIDIwMDQtMDUtMjMiXCIgLURfR05VX1NPVVJDRSAt SS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmlu dXRpbHMvZ2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4v Y29udHJpYi9iaW51dGlscy9nYXMvY29uZmlnIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRp bHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvaTM4Ni1mcmVl YnNkICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9z cmMvY29udHJpYi9iaW51dGlscy9nYXMvZmxvbnVtLWtvbnN0LmMNCmNjIC1PIC1waXBlIC1JLiAt SS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvYXMvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251 L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EREVGQVVMVF9B UkNIPVwiaTM4NlwiIC1EVEFSR0VUX0NQVT1cImkzODZcIiAtRFRBUkdFVF9DQU5PTklDQUw9XCJp Mzg2LW9icmllbi1mcmVlYnNkXCIgLURUQVJHRVRfQUxJQVM9XCJpMzg2LW9icmllbi1mcmVlYnNk XCIgLURWRVJTSU9OPVwiIjIuMTUgW0ZyZWVCU0RdIDIwMDQtMDUtMjMiXCIgLURfR05VX1NPVVJD RSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIv YmludXRpbHMvZ2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4v Li4vY29udHJpYi9iaW51dGlscy9nYXMvY29uZmlnIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvaTM4Ni1m cmVlYnNkICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vz ci9zcmMvY29udHJpYi9iaW51dGlscy9nYXMvZmxvbnVtLW11bHQuYw0KY2MgLU8gLXBpcGUgLUku IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi9iaW51dGlscy9hcy8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2luY2x1ZGUgLURERUZBVUxU X0FSQ0g9XCJpMzg2XCIgLURUQVJHRVRfQ1BVPVwiaTM4NlwiIC1EVEFSR0VUX0NBTk9OSUNBTD1c ImkzODYtb2JyaWVuLWZyZWVic2RcIiAtRFRBUkdFVF9BTElBUz1cImkzODYtb2JyaWVuLWZyZWVi c2RcIiAtRFZFUlNJT049XCIiMi4xNSBbRnJlZUJTRF0gMjAwNC0wNS0yMyJcIiAtRF9HTlVfU09V UkNFIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJp Yi9iaW51dGlscy9nYXMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8u Li8uLi9jb250cmliL2JpbnV0aWxzL2dhcy9jb25maWcgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvYXMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy9pMzg2 LWZyZWVic2QgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAv dXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2dhcy9mcmFncy5jDQpjYyAtTyAtcGlwZSAtSS4gLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2Jp bnV0aWxzL2FzLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2FzLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0 aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRERFRkFVTFRfQVJD SD1cImkzODZcIiAtRFRBUkdFVF9DUFU9XCJpMzg2XCIgLURUQVJHRVRfQ0FOT05JQ0FMPVwiaTM4 Ni1vYnJpZW4tZnJlZWJzZFwiIC1EVEFSR0VUX0FMSUFTPVwiaTM4Ni1vYnJpZW4tZnJlZWJzZFwi IC1EVkVSU0lPTj1cIiIyLjE1IFtGcmVlQlNEXSAyMDA0LTA1LTIzIlwiIC1EX0dOVV9TT1VSQ0Ug LUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2Jp bnV0aWxzL2dhcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4u L2NvbnRyaWIvYmludXRpbHMvZ2FzL2NvbmZpZyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0 aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi9iaW51dGlscy9hcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzL2kzODYtZnJl ZWJzZCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Iv c3JjL2NvbnRyaWIvYmludXRpbHMvZ2FzL2hhc2guYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9z cmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9hcy8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJp bi9iaW51dGlscy9hcy8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9h cy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2luY2x1ZGUgLURERUZBVUxUX0FSQ0g9XCJp Mzg2XCIgLURUQVJHRVRfQ1BVPVwiaTM4NlwiIC1EVEFSR0VUX0NBTk9OSUNBTD1cImkzODYtb2Jy aWVuLWZyZWVic2RcIiAtRFRBUkdFVF9BTElBUz1cImkzODYtb2JyaWVuLWZyZWVic2RcIiAtRFZF UlNJT049XCIiMi4xNSBbRnJlZUJTRF0gMjAwNC0wNS0yMyJcIiAtRF9HTlVfU09VUkNFIC1JL3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGls cy9nYXMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250 cmliL2JpbnV0aWxzL2dhcy9jb25maWcgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9h cy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvYXMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy9pMzg2LWZyZWVic2Qg IC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9j b250cmliL2JpbnV0aWxzL2dhcy9pbnB1dC1maWxlLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRp bHMvYXMvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5i aW4vYmludXRpbHMvYXMvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMv YXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EREVGQVVMVF9BUkNIPVwi aTM4NlwiIC1EVEFSR0VUX0NQVT1cImkzODZcIiAtRFRBUkdFVF9DQU5PTklDQUw9XCJpMzg2LW9i cmllbi1mcmVlYnNkXCIgLURUQVJHRVRfQUxJQVM9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURW RVJTSU9OPVwiIjIuMTUgW0ZyZWVCU0RdIDIwMDQtMDUtMjMiXCIgLURfR05VX1NPVVJDRSAtSS91 c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRp bHMvZ2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29u dHJpYi9iaW51dGlscy9nYXMvY29uZmlnIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMv YXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2Jp bnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvaTM4Ni1mcmVlYnNk ICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMv Y29udHJpYi9iaW51dGlscy9nYXMvaW5wdXQtc2NydWIuYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51 dGlscy9hcy8uLi9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNy LmJpbi9iaW51dGlscy9hcy8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2luY2x1ZGUgLURERUZBVUxUX0FSQ0g9 XCJpMzg2XCIgLURUQVJHRVRfQ1BVPVwiaTM4NlwiIC1EVEFSR0VUX0NBTk9OSUNBTD1cImkzODYt b2JyaWVuLWZyZWVic2RcIiAtRFRBUkdFVF9BTElBUz1cImkzODYtb2JyaWVuLWZyZWVic2RcIiAt RFZFUlNJT049XCIiMi4xNSBbRnJlZUJTRF0gMjAwNC0wNS0yMyJcIiAtRF9HTlVfU09VUkNFIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51 dGlscy9nYXMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9j b250cmliL2JpbnV0aWxzL2dhcy9jb25maWcgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvYXMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy9pMzg2LWZyZWVi c2QgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3Ny Yy9jb250cmliL2JpbnV0aWxzL2dhcy9saXN0aW5nLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRp bHMvYXMvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5i aW4vYmludXRpbHMvYXMvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMv YXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EREVGQVVMVF9BUkNIPVwi aTM4NlwiIC1EVEFSR0VUX0NQVT1cImkzODZcIiAtRFRBUkdFVF9DQU5PTklDQUw9XCJpMzg2LW9i cmllbi1mcmVlYnNkXCIgLURUQVJHRVRfQUxJQVM9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURW RVJTSU9OPVwiIjIuMTUgW0ZyZWVCU0RdIDIwMDQtMDUtMjMiXCIgLURfR05VX1NPVVJDRSAtSS91 c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRp bHMvZ2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29u dHJpYi9iaW51dGlscy9nYXMvY29uZmlnIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMv YXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2Jp bnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvaTM4Ni1mcmVlYnNk ICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMv Y29udHJpYi9iaW51dGlscy9nYXMvbGl0ZXJhbC5jDQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2FzLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2FzLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2Fz Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRERFRkFVTFRfQVJDSD1cImkz ODZcIiAtRFRBUkdFVF9DUFU9XCJpMzg2XCIgLURUQVJHRVRfQ0FOT05JQ0FMPVwiaTM4Ni1vYnJp ZW4tZnJlZWJzZFwiIC1EVEFSR0VUX0FMSUFTPVwiaTM4Ni1vYnJpZW4tZnJlZWJzZFwiIC1EVkVS U0lPTj1cIiIyLjE1IFtGcmVlQlNEXSAyMDA0LTA1LTIzIlwiIC1EX0dOVV9TT1VSQ0UgLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxz L2dhcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRy aWIvYmludXRpbHMvZ2FzL2NvbmZpZyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2Fz Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51 dGlscy9hcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzL2kzODYtZnJlZWJzZCAg LUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2Nv bnRyaWIvYmludXRpbHMvZ2FzL21hY3JvLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2du dS91c3IuYmluL2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMv Li4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmlu dXRpbHMvYXMvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4v Li4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EREVGQVVMVF9BUkNIPVwiaTM4Nlwi IC1EVEFSR0VUX0NQVT1cImkzODZcIiAtRFRBUkdFVF9DQU5PTklDQUw9XCJpMzg2LW9icmllbi1m cmVlYnNkXCIgLURUQVJHRVRfQUxJQVM9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURWRVJTSU9O PVwiIjIuMTUgW0ZyZWVCU0RdIDIwMDQtMDUtMjMiXCIgLURfR05VX1NPVVJDRSAtSS91c3Ivc3Jj L2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvZ2Fz IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9i aW51dGlscy9nYXMvY29uZmlnIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4v Li4vLi4vLi4vY29udHJpYi9iaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvaTM4Ni1mcmVlYnNkICAtSS91 c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJp Yi9iaW51dGlscy9nYXMvbWVzc2FnZXMuYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251 L3Vzci5iaW4vYmludXRpbHMvYXMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8u Li9saWJiZmQgLUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51 dGlscy9hcy8uLi9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8u Li8uLi8uLi9jb250cmliL2JpbnV0aWxzL2luY2x1ZGUgLURERUZBVUxUX0FSQ0g9XCJpMzg2XCIg LURUQVJHRVRfQ1BVPVwiaTM4NlwiIC1EVEFSR0VUX0NBTk9OSUNBTD1cImkzODYtb2JyaWVuLWZy ZWVic2RcIiAtRFRBUkdFVF9BTElBUz1cImkzODYtb2JyaWVuLWZyZWVic2RcIiAtRFZFUlNJT049 XCIiMi4xNSBbRnJlZUJTRF0gMjAwNC0wNS0yMyJcIiAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMv Z251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9nYXMg LUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2Jp bnV0aWxzL2dhcy9jb25maWcgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8u Li8uLi8uLi9jb250cmliL2JpbnV0aWxzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMv YXMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy9pMzg2LWZyZWVic2QgIC1JL3Vz ci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmli L2JpbnV0aWxzL2dhcy9jb25maWcvb2JqLWVsZi5jDQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2FzLy4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2FzLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2Fz Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRERFRkFVTFRfQVJDSD1cImkz ODZcIiAtRFRBUkdFVF9DUFU9XCJpMzg2XCIgLURUQVJHRVRfQ0FOT05JQ0FMPVwiaTM4Ni1vYnJp ZW4tZnJlZWJzZFwiIC1EVEFSR0VUX0FMSUFTPVwiaTM4Ni1vYnJpZW4tZnJlZWJzZFwiIC1EVkVS U0lPTj1cIiIyLjE1IFtGcmVlQlNEXSAyMDA0LTA1LTIzIlwiIC1EX0dOVV9TT1VSQ0UgLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxz L2dhcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRy aWIvYmludXRpbHMvZ2FzL2NvbmZpZyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2Fz Ly4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51 dGlscy9hcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzL2kzODYtZnJlZWJzZCAg LUkvdXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2Nv bnRyaWIvYmludXRpbHMvZ2FzL291dHB1dC1maWxlLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Iv c3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRp bHMvYXMvLi4vbGliYmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5i aW4vYmludXRpbHMvYXMvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMv YXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EREVGQVVMVF9BUkNIPVwi aTM4NlwiIC1EVEFSR0VUX0NQVT1cImkzODZcIiAtRFRBUkdFVF9DQU5PTklDQUw9XCJpMzg2LW9i cmllbi1mcmVlYnNkXCIgLURUQVJHRVRfQUxJQVM9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURW RVJTSU9OPVwiIjIuMTUgW0ZyZWVCU0RdIDIwMDQtMDUtMjMiXCIgLURfR05VX1NPVVJDRSAtSS91 c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRp bHMvZ2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29u dHJpYi9iaW51dGlscy9nYXMvY29uZmlnIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMv YXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2Jp bnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvaTM4Ni1mcmVlYnNk ICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMv Y29udHJpYi9iaW51dGlscy9nYXMvcmVhZC5jDQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi9iaW51dGlscy9hcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2Fz Ly4uL2xpYmJmZCAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2Jp bnV0aWxzL2FzLy4uL2xpYmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4u Ly4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvaW5jbHVkZSAtRERFRkFVTFRfQVJDSD1cImkzODZc IiAtRFRBUkdFVF9DUFU9XCJpMzg2XCIgLURUQVJHRVRfQ0FOT05JQ0FMPVwiaTM4Ni1vYnJpZW4t ZnJlZWJzZFwiIC1EVEFSR0VUX0FMSUFTPVwiaTM4Ni1vYnJpZW4tZnJlZWJzZFwiIC1EVkVSU0lP Tj1cIiIyLjE1IFtGcmVlQlNEXSAyMDA0LTA1LTIzIlwiIC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2dh cyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIv YmludXRpbHMvZ2FzL2NvbmZpZyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4u Ly4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9hcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzL2kzODYtZnJlZWJzZCAgLUkv dXNyL29iai91c3Ivc3JjL2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRy aWIvYmludXRpbHMvZ2FzL3NiLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vbGli YmZkIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMv YXMvLi4vbGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4v Li4vY29udHJpYi9iaW51dGlscy9pbmNsdWRlIC1EREVGQVVMVF9BUkNIPVwiaTM4NlwiIC1EVEFS R0VUX0NQVT1cImkzODZcIiAtRFRBUkdFVF9DQU5PTklDQUw9XCJpMzg2LW9icmllbi1mcmVlYnNk XCIgLURUQVJHRVRfQUxJQVM9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURWRVJTSU9OPVwiIjIu MTUgW0ZyZWVCU0RdIDIwMDQtMDUtMjMiXCIgLURfR05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvZ2FzIC1JL3Vz ci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGls cy9nYXMvY29uZmlnIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4v Li4vY29udHJpYi9iaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvaTM4Ni1mcmVlYnNkICAtSS91c3Ivb2Jq L3Vzci9zcmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9iaW51 dGlscy9nYXMvc3RhYnMuYw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4v YmludXRpbHMvYXMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi9saWJiZmQg LUkvdXNyL29iai91c3Ivc3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8u Li9saWJiZmQgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9j b250cmliL2JpbnV0aWxzL2luY2x1ZGUgLURERUZBVUxUX0FSQ0g9XCJpMzg2XCIgLURUQVJHRVRf Q1BVPVwiaTM4NlwiIC1EVEFSR0VUX0NBTk9OSUNBTD1cImkzODYtb2JyaWVuLWZyZWVic2RcIiAt RFRBUkdFVF9BTElBUz1cImkzODYtb2JyaWVuLWZyZWVic2RcIiAtRFZFUlNJT049XCIiMi4xNSBb RnJlZUJTRF0gMjAwNC0wNS0yMyJcIiAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vzci5i aW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9nYXMgLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2dh cy9jb25maWcgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9j b250cmliL2JpbnV0aWxzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMgLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy9pMzg2LWZyZWVic2QgIC1JL3Vzci9vYmovdXNy L3NyYy9pMzg2L2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxz L2dhcy9zdWJzZWdzLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2Jp bnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vbGliYmZkIC1J L3Vzci9vYmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4v bGliYmZkIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29u dHJpYi9iaW51dGlscy9pbmNsdWRlIC1EREVGQVVMVF9BUkNIPVwiaTM4NlwiIC1EVEFSR0VUX0NQ VT1cImkzODZcIiAtRFRBUkdFVF9DQU5PTklDQUw9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURU QVJHRVRfQUxJQVM9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURWRVJTSU9OPVwiIjIuMTUgW0Zy ZWVCU0RdIDIwMDQtMDUtMjMiXCIgLURfR05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmlu L2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvZ2FzIC1JL3Vzci9zcmMv Z251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9nYXMv Y29uZmlnIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29u dHJpYi9iaW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzIC1JL3Vzci9z cmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvaTM4Ni1mcmVlYnNkICAtSS91c3Ivb2JqL3Vzci9z cmMvaTM4Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9iaW51dGlscy9n YXMvc3ltYm9scy5jDQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51 dGlscy9hcyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uL2xpYmJmZCAtSS91 c3Ivb2JqL3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uL2xp YmJmZCAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRy aWIvYmludXRpbHMvaW5jbHVkZSAtRERFRkFVTFRfQVJDSD1cImkzODZcIiAtRFRBUkdFVF9DUFU9 XCJpMzg2XCIgLURUQVJHRVRfQ0FOT05JQ0FMPVwiaTM4Ni1vYnJpZW4tZnJlZWJzZFwiIC1EVEFS R0VUX0FMSUFTPVwiaTM4Ni1vYnJpZW4tZnJlZWJzZFwiIC1EVkVSU0lPTj1cIiIyLjE1IFtGcmVl QlNEXSAyMDA0LTA1LTIzIlwiIC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2dhcyAtSS91c3Ivc3JjL2du dS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvZ2FzL2Nv bmZpZyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRy aWIvYmludXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcyAtSS91c3Ivc3Jj L2dudS91c3IuYmluL2JpbnV0aWxzL2FzL2kzODYtZnJlZWJzZCAgLUkvdXNyL29iai91c3Ivc3Jj L2kzODYvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL2NvbnRyaWIvYmludXRpbHMvZ2Fz L3dyaXRlLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2FzIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vbGliYmZkIC1JL3Vzci9v YmovdXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vbGliYmZk IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9i aW51dGlscy9pbmNsdWRlIC1EREVGQVVMVF9BUkNIPVwiaTM4NlwiIC1EVEFSR0VUX0NQVT1cImkz ODZcIiAtRFRBUkdFVF9DQU5PTklDQUw9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURUQVJHRVRf QUxJQVM9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURWRVJTSU9OPVwiIjIuMTUgW0ZyZWVCU0Rd IDIwMDQtMDUtMjMiXCIgLURfR05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0 aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvZ2FzIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9nYXMvY29uZmln IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9i aW51dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251 L3Vzci5iaW4vYmludXRpbHMvYXMvaTM4Ni1mcmVlYnNkICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4 Ni9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9iaW51dGlscy9nYXMvZGVw ZW5kLmMNCmNjIC1PIC1waXBlIC1JLiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2Fz IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vbGliYmZkIC1JL3Vzci9vYmov dXNyL3NyYy9pMzg2L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vbGliYmZkIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51 dGlscy9pbmNsdWRlIC1EREVGQVVMVF9BUkNIPVwiaTM4NlwiIC1EVEFSR0VUX0NQVT1cImkzODZc IiAtRFRBUkdFVF9DQU5PTklDQUw9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURUQVJHRVRfQUxJ QVM9XCJpMzg2LW9icmllbi1mcmVlYnNkXCIgLURWRVJTSU9OPVwiIjIuMTUgW0ZyZWVCU0RdIDIw MDQtMDUtMjMiXCIgLURfR05VX1NPVVJDRSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxz L2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvZ2FzIC1JL3Vzci9zcmMvZ251L3Vzci5i aW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9nYXMvY29uZmlnIC1J L3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMvLi4vLi4vLi4vLi4vY29udHJpYi9iaW51 dGlscyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzIC1JL3Vzci9zcmMvZ251L3Vz ci5iaW4vYmludXRpbHMvYXMvaTM4Ni1mcmVlYnNkICAtSS91c3Ivb2JqL3Vzci9zcmMvaTM4Ni9s ZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvY29udHJpYi9iaW51dGlscy9nYXMvZWhvcHQu Yw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMgLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi9saWJiZmQgLUkvdXNyL29iai91c3Iv c3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi9saWJiZmQgLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxz L2luY2x1ZGUgLURERUZBVUxUX0FSQ0g9XCJpMzg2XCIgLURUQVJHRVRfQ1BVPVwiaTM4NlwiIC1E VEFSR0VUX0NBTk9OSUNBTD1cImkzODYtb2JyaWVuLWZyZWVic2RcIiAtRFRBUkdFVF9BTElBUz1c ImkzODYtb2JyaWVuLWZyZWVic2RcIiAtRFZFUlNJT049XCIiMi4xNSBbRnJlZUJTRF0gMjAwNC0w NS0yMyJcIiAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMv Li4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9nYXMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2dhcy9jb25maWcgLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxz IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi9iaW51dGlscy9hcy9pMzg2LWZyZWVic2QgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2Fj eS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2dhcy9kdzJnZW5jZmku Yw0KY2MgLU8gLXBpcGUgLUkuIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMgLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi9saWJiZmQgLUkvdXNyL29iai91c3Iv c3JjL2kzODYvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi9saWJiZmQgLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxz L2luY2x1ZGUgLURERUZBVUxUX0FSQ0g9XCJpMzg2XCIgLURUQVJHRVRfQ1BVPVwiaTM4NlwiIC1E VEFSR0VUX0NBTk9OSUNBTD1cImkzODYtb2JyaWVuLWZyZWVic2RcIiAtRFRBUkdFVF9BTElBUz1c ImkzODYtb2JyaWVuLWZyZWVic2RcIiAtRFZFUlNJT049XCIiMi4xNSBbRnJlZUJTRF0gMjAwNC0w NS0yMyJcIiAtRF9HTlVfU09VUkNFIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMv Li4vLi4vLi4vLi4vY29udHJpYi9iaW51dGlscy9nYXMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9i aW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2dhcy9jb25maWcgLUkvdXNy L3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxz IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMgLUkvdXNyL3NyYy9nbnUvdXNyLmJp bi9iaW51dGlscy9hcy9pMzg2LWZyZWVic2QgIC1JL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2Fj eS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9jb250cmliL2JpbnV0aWxzL2dhcy9jb25maWcvdGMt aTM4Ni5jDQpjYyAtTyAtcGlwZSAtSS4gLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9h cyAtSS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uL2xpYmJmZCAtSS91c3Ivb2Jq L3Vzci9zcmMvaTM4Ni91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uL2xpYmJmZCAt SS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmlu dXRpbHMvaW5jbHVkZSAtRERFRkFVTFRfQVJDSD1cImkzODZcIiAtRFRBUkdFVF9DUFU9XCJpMzg2 XCIgLURUQVJHRVRfQ0FOT05JQ0FMPVwiaTM4Ni1vYnJpZW4tZnJlZWJzZFwiIC1EVEFSR0VUX0FM SUFTPVwiaTM4Ni1vYnJpZW4tZnJlZWJzZFwiIC1EVkVSU0lPTj1cIiIyLjE1IFtGcmVlQlNEXSAy MDA0LTA1LTIzIlwiIC1EX0dOVV9TT1VSQ0UgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGls cy9hcy8uLi8uLi8uLi8uLi9jb250cmliL2JpbnV0aWxzL2dhcyAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmludXRpbHMvZ2FzL2NvbmZpZyAt SS91c3Ivc3JjL2dudS91c3IuYmluL2JpbnV0aWxzL2FzLy4uLy4uLy4uLy4uL2NvbnRyaWIvYmlu dXRpbHMgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9iaW51dGlscy9hcyAtSS91c3Ivc3JjL2dudS91 c3IuYmluL2JpbnV0aWxzL2FzL2kzODYtZnJlZWJzZCAgLUkvdXNyL29iai91c3Ivc3JjL2kzODYv bGVnYWN5L3Vzci9pbmNsdWRlICAtc3RhdGljIC1ML3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2Fj eS91c3IvbGliIC1vIGFzIGFwcC5vIGFzLm8gYXRvZi1nZW5lcmljLm8gYXRvZi1pZWVlLm8gYmln bnVtLWNvcHkubyBjb25kLm8gZHdhcmYyZGJnLm8gZWNvZmYubyBleHByLm8gZmxvbnVtLWNvcHku byBmbG9udW0ta29uc3QubyBmbG9udW0tbXVsdC5vIGZyYWdzLm8gaGFzaC5vIGlucHV0LWZpbGUu byBpbnB1dC1zY3J1Yi5vIGxpc3RpbmcubyBsaXRlcmFsLm8gbWFjcm8ubyBtZXNzYWdlcy5vIG9i ai1lbGYubyBvdXRwdXQtZmlsZS5vIHJlYWQubyBzYi5vIHN0YWJzLm8gc3Vic2Vncy5vIHN5bWJv bHMubyB3cml0ZS5vIGRlcGVuZC5vIGVob3B0Lm8gZHcyZ2VuY2ZpLm8gdGMtaTM4Ni5vIC4uL2xp YmJmZC9saWJiZmQuYSAuLi9saWJpYmVydHkvbGliaWJlcnR5LmEgLi4vbGlib3Bjb2Rlcy9saWJv cGNvZGVzLmEgL3Vzci9vYmovdXNyL3NyYy9pMzg2L2xlZ2FjeS91c3IvbGliL2xpYmVnYWN5LmEg LWxlZ2FjeQ0KYXMubzogSW4gZnVuY3Rpb24gYHBhcnNlX2FyZ3MnOg0KYXMubygudGV4dCsweDNi OCk6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGdldG9wdF9sb25nX29ubHknDQoqKiogRXJyb3Ig Y29kZSAxDQoNClN0b3AgaW4gL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMvYXMuDQoqKiog RXJyb3IgY29kZSAxDQoNClN0b3AgaW4gL3Vzci9zcmMvZ251L3Vzci5iaW4vYmludXRpbHMuDQoq KiogRXJyb3IgY29kZSAxDQoNClN0b3AgaW4gL3Vzci9zcmMuDQoqKiogRXJyb3IgY29kZSAxDQoN ClN0b3AgaW4gL3Vzci9zcmMuDQoqKiogRXJyb3IgY29kZSAxDQoNClN0b3AgaW4gL3Vzci9zcmMu DQoNCnJlYWwJNG0xNi41NDZzDQp1c2VyCTJtNDkuMzY4cw0Kc3lzCTBtNDAuNDkwcw0KaWFuY2hv djovdXNyL3NyYyMgZXhpdA0KZXhpdA0KClNjcmlwdCBkb25lIG9uIFdlZCBBdWcgMTEgMjI6NTA6 MDUgMjAwNAo= ------=_Part_15308_624519631.1092254560681-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 20:19:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EB9816A4CE for ; Wed, 11 Aug 2004 20:19:36 +0000 (GMT) Received: from dragon.relcom.ru (dragon.relcom.ru [194.58.36.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1832D43D1F for ; Wed, 11 Aug 2004 20:19:36 +0000 (GMT) (envelope-from anatoly@relcom.ru) Received: from [213.128.192.73] (moscow3-a9.sibintek.net [213.128.192.73]) by dragon.relcom.ru with asmtp (encrypted) id 1BuzW4-000H6y-QF for freebsd-current@freebsd.org; (v1.249) (envelope-from ); Thu, 12 Aug 2004 00:16:09 +0400 Message-ID: <411A7F28.6000108@relcom.ru> Date: Thu, 12 Aug 2004 00:18:48 +0400 From: anatoly@relcom.ru User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040807) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 12 Aug 2004 01:54:22 +0000 Subject: boot hangs due acd init X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 20:19:36 -0000 hey folks i run recent current and somewhile ago i noticed that i cant boot my fujitsu lifebook P series with this dvd-cdrw device: acd0: CDRW at ata1-master PIO4 it hangs on boot. I'd mention that it was working nice before. I can provide necessary debugging information if needed. From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 20:32:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DF4B16A4CE for ; Wed, 11 Aug 2004 20:32:34 +0000 (GMT) Received: from dragon.relcom.ru (dragon.relcom.ru [194.58.36.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 299AE43D4C for ; Wed, 11 Aug 2004 20:32:34 +0000 (GMT) (envelope-from anatoly@relcom.ru) Received: from [213.128.192.73] (moscow3-a9.sibintek.net [213.128.192.73]) by dragon.relcom.ru with asmtp (encrypted) id 1BuziW-000PKg-D5 for freebsd-current@freebsd.org; (v1.249) (envelope-from ); Thu, 12 Aug 2004 00:29:07 +0400 Message-ID: <411A820B.3040309@relcom.ru> Date: Thu, 12 Aug 2004 00:31:08 +0400 From: anatoly@relcom.ru User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040807) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 12 Aug 2004 01:54:22 +0000 Subject: strange ipfilter's behavior X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 20:32:34 -0000 hey, after few current cvsup's ipfilter doesnt work properly. Seems none saw this problem. After boot process passed it seems ipfilter rules are not working properly (but they're loaded and you can see them via ipfstat -io). rules themself are applied for tun0 with ppp on it. If I run ipf -Fa -f /etc/ipf.conf manually ipfilter start working as it ought to. (same situation with ipnat) Question is.. i missed something in recent /etc/rc updates or its a bug? uname -a: FreeBSD lifebook 5.2-CURRENT FreeBSD 5.2-CURRENT #0: Wed Aug 11 15:34:13 MSD 2004 root@lifebook:/usr/obj/usr/src/sys/LIFEBOOK i386 /etc/rc.conf: ipfilter_enable="YES" ipfilter_program="/sbin/ipf" ipfilter_rules="/etc/ipf.conf" ipfilter_flags="" ipnat_enable="YES" # Set to YES to enable ipnat functionality ipnat_program="/sbin/ipnat" # where the ipnat program lives ipnat_rules="/etc/ipnat.conf" # rules definition file for ipnat ipnat_flags="" # additional flags for ipnat ipmon_enable="YES" ipmon_program="/sbin/ipmon" # where the ipfilter monitor program lives ipmon_flags="-Ds" # typically "-Ds" or "-D /var/log/ipflog" /etc/ipf.conf: (pretty ugly) count out on tun0 from any to any count in on tun0 from any to any pass out quick on tun0 proto tcp from any to any keep state pass out quick on tun0 proto icmp from any to any keep state pass out quick on tun0 proto udp from any to any keep state block return-icmp in log quick on tun0 proto udp from any to any block return-icmp(proto-unr) in log quick on tun0 proto icmp from any to any block return-rst in log quick on tun0 proto tcp from any to any From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 21:02:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8BDF16A4CE for ; Wed, 11 Aug 2004 21:02:14 +0000 (GMT) Received: from ns.atcom.spb.ru (ns.atcom.spb.ru [213.182.169.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60BAB43D45 for ; Wed, 11 Aug 2004 21:02:14 +0000 (GMT) (envelope-from toxa@cterra.ru) Received: by ns.atcom.spb.ru (Postfix, from userid 1042) id D494F334; Thu, 12 Aug 2004 01:01:53 +0400 (MSD) Received: from localhost (ppp-dialup-12.atcom.spb.ru [213.182.168.12]) by ns.atcom.spb.ru (Postfix) with ESMTP id B90482FC for ; Thu, 12 Aug 2004 01:01:48 +0400 (MSD) Date: Thu, 12 Aug 2004 01:00:24 +0400 From: Toxa To: current@freebsd.org X-Comment-To: "Anton Karpov" Message-ID: <20040811210024.GA14304@laptoxa.toxa.lan> Mail-Followup-To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Outluck Express 1.5.6i for MS-DOS 6.22-SMP X-Mailer: See User-Agent above :) X-Operating-System: MS-DOS 6.22-CURRENT on Sony VAIO laptop X-PGP-Public-Key: http://toxahost.org/gpg/pubkey.asc X-Useless-Header: Do Androids Dream of Electric Sheep? X-Mailman-Approved-At: Thu, 12 Aug 2004 01:54:22 +0000 Subject: acpi_video on sony vaio... does anybody got it to work? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 11 Aug 2004 21:02:15 -0000 I'm fall into despair with acpi_video on sony vaio pcg-v505bx, it's simply doesn't work. There's no video-related sysctl variables, video is the only thing which have porblems after wakeup from suspend (e.g. i can log in only remotely after wakeup, local console hangs). Does anybody tried to mess with vaio laptops and suspend? -- Anton A. Karpov PGP key: http://www.toxahost.org/pgp/pubkey.asc You can finger me @toxahost.org for my current status #-------------------------------------------------- "Anyone who quotes me in their sig is an idiot." Rusty Russell. #-------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 02:13:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32ADE16A4CF for ; Thu, 12 Aug 2004 02:13:12 +0000 (GMT) Received: from endif.cjb.net (65-101-250-157.dnvr.qwest.net [65.101.250.157]) by mx1.FreeBSD.org (Postfix) with SMTP id EDA4043D2D for ; Thu, 12 Aug 2004 02:13:08 +0000 (GMT) (envelope-from end@endif.cjb.net) Received: (qmail 29683 invoked by uid 0); 12 Aug 2004 02:13:03 -0000 Received: from localhost (HELO rogue) (127.0.0.1) by localhost with SMTP; 12 Aug 2004 02:13:03 -0000 Date: Wed, 11 Aug 2004 20:13:02 -0600 From: Robin Schoonover To: freebsd-current@freebsd.org X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20040812021308.EDA4043D2D@mx1.FreeBSD.org> Subject: DWL-650 RevP does not work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 02:13:12 -0000 (This is on a 5.2.1 laptop, but I've ported small parts like ndis and pccarddevs from -current back to my src tree) I recently bought a DWL-650 revP 802.11b wireless pcmcia card with the expectation that it would work with FreeBSD. Early revisions of that card apparently do, but not revP. I think this is a somewhat known problem, but I'm trying to help document my troubles so maybe someday we'll have it working. :) Upon finding out that it does not work, I did some research. Apparently, it uses the PRISM3 chipset, which according to the wi(4) manpage is supported, but I do not see any cards listed with it there. DWL-650 -is- listed there, but only applies to earlier versions of the card (not revP) Anyhow, an earlier thread on -current@ mentioned making some changes so that wi(4) would know about this card from the wild, but for the person involved it did not work with the message that the busy bit would not clear. It fails for me in the same way. Supposedly this is because the firmware is not loaded, and there are certain tools available for windows and linux which will load it. I tried the card with a win2k laptop, and it worked fine (firmware was 1.8.0 I think). Brought it back to FreeBSD, and the card still did not work. Tried ndis, that didn't work either (more on that later). Apparently, from what I understand from my googling, it is the responsibility of the driver to load the firmware at startup because the chip lacks the ROM to hold it (so it has to be loaded into card's RAM instead?). (Hmm... Apparently this is called Short Serial Flash) About my attempts to make it work with ndis: it simply did not work. At first, ndiscvt had trouble with the .inf file. There was no newline at the end of file, but once I added one it was fine. Managed to compile the modules fine, tried to run it, and nope, still doesn't work. The wi(4) driver would continue to try to grab it, so I compiled wi out. Nope...ndis did not appear to match itself with the card at all. In the end I ended up erasing the card entirely (I think...somehow?). Oops. It doesn't work with the windows laptop anymore. However, windows keeps pulling the driver out of somewhere, so I haven't been able to get it to deinstall/reinstall properly so I can possibly hopefully make the card work again. Interestingly enough, FreeBSD complains about the busy bit no matter if it happens to work in windows or not. For reference, wi(4) displays this: wi0: at port 0x400-0x47f irq 11 function 0 config 1 on pccard1 wi0: wi_cmd: busy bit won't clear. : init failed device_probe_and_attach: wi0 attach returned 6 -- Robin Schoonover (aka End) # # "Did you know that black paint is an excellent stain remover?" # - Dogbert From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 02:29:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 228D916A4CE for ; Thu, 12 Aug 2004 02:29:35 +0000 (GMT) Received: from meitner.wh.uni-dortmund.de (meitner.wh.Uni-Dortmund.DE [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7986543D2D for ; Thu, 12 Aug 2004 02:29:34 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id 427AC1674EA; Thu, 12 Aug 2004 04:29:33 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i7C2TV46062534 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 12 Aug 2004 04:29:31 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: freebsd-current@FreeBSD.org Date: Thu, 12 Aug 2004 04:29:22 +0200 User-Agent: KMail/1.6.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_KYtGBQaeQBVi/hN"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408120429.30081.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new cc: rnejdl@ringofsaturn.com cc: Trent Nelson Subject: Re: Signal 11 compiling qt33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 02:29:35 -0000 --Boundary-02=_KYtGBQaeQBVi/hN Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 11 August 2004 18:59, Trent Nelson wrote: > I typically have to run 'make' about 10-15 times before Qt will completely > build. Compiling Qt in general is probably more strenuous on the system > than doing a 'make world' due to the nature of their classes and such. Indeed compiling qt is making the compiler rotate quite a lot. > I've never seen any problems with my hardware apart from this. I guess > there always is the possibility I do have dodgy memory and this is the on= ly > thing that is stressing the system enough to make things break. Maybe. Maybe there are some software related factors there, too (qt isn't=20 generally more sensitive to typical scenarios of ports-based installations= =20 being inconsistent in a way that makes stuff break - like the mixed threads= =20 libraries example. The difference is, qt very often just fails in a rather= =20 undescriptive way, and as it seems, way more often in some places than othe= rs=20 (uic)). However, qt does not randomly fail on the package builders - and packages a= re=20 an excellent way to avoid the compilation stress. :) BTW: A new qt version has been released yesterday... I'm already busy porti= ng=20 it. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --Boundary-02=_KYtGBQaeQBVi/hN Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBGtYKXhc68WspdLARAtTiAJ9NBr3PhWZZ+YwInDyCycSIjVhPBwCeIbIT tio8awUyW4h0/puQfkUHPRk= =zPK1 -----END PGP SIGNATURE----- --Boundary-02=_KYtGBQaeQBVi/hN-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 03:46:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6865616A4CE for ; Thu, 12 Aug 2004 03:46:21 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3916A43D54 for ; Thu, 12 Aug 2004 03:46:21 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-94.dsl.snfc21.pacbell.net [64.171.186.94]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7C3kK8U010570; Wed, 11 Aug 2004 20:46:20 -0700 Message-ID: <411AE80A.3040007@root.org> Date: Wed, 11 Aug 2004 20:46:18 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eriksson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/sys/dev/acpica acpi_pci_link.c acpi_pcib.c acpi_pcib_acpi.c acpi_pcib_pci.c acpi_pcibvar.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 03:46:21 -0000 Daniel Eriksson wrote: > This(?) breaks interrupt routing pretty badly on ASUS A7V600-X (VIA KT-600 > chipset). > > A kernel/userland from 2004.08.09.13.00.00 works just fine (sorry, no dmesg > available right now), but a kernel/userland from 2004.08.11.15.00.00 breaks > routing of interrupts to (at least) two HighPoint RocketRAID 454 cards. > > Below is part of the dmesg from a boot with ACPI on. Does it matter that > "PnP OS installed" is turned off in the BIOS? I will run some more tests > later tonight and report the results here. This is just a FYI that something > might be broken... Please cvsup and test, I've committed fixes for all known problems. -- Nate From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 04:19:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B47FD16A4CE for ; Thu, 12 Aug 2004 04:19:35 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EA0943D46 for ; Thu, 12 Aug 2004 04:19:35 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 17271 invoked from network); 12 Aug 2004 04:19:35 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail4.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Aug 2004 04:19:35 -0000 Received: from hydrogen.funkthat.com (qxabuf@localhost.funkthat.com [127.0.0.1])i7C4JYuU014514; Wed, 11 Aug 2004 21:19:34 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i7C4JYxr014513; Wed, 11 Aug 2004 21:19:34 -0700 (PDT) Date: Wed, 11 Aug 2004 21:19:34 -0700 From: John-Mark Gurney To: Jeffrey Katcher Message-ID: <20040812041934.GZ991@funkthat.com> Mail-Followup-To: Jeffrey Katcher , current@freebsd.org References: <20040811164508.74419.qmail@web41104.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040811164508.74419.qmail@web41104.mail.yahoo.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: current@freebsd.org Subject: Re: Can someone please commit a sane module path in loader.conf? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2004 04:19:35 -0000 Jeffrey Katcher wrote this message on Wed, Aug 11, 2004 at 09:45 -0700: > I know I can override it in my local loader.conf, but the change to > /boot/modules only was _really_ annoying and unexpected. FYI, it should be > /boot/kernel for most people. No. Could you please upgrade your loader.rc as per UPDATING? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 04:36:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D70E216A4CE for ; Thu, 12 Aug 2004 04:36:35 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id B34CA43D49 for ; Thu, 12 Aug 2004 04:36:35 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 5894 invoked from network); 12 Aug 2004 04:36:35 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Aug 2004 04:36:35 -0000 Received: from hydrogen.funkthat.com (spslgh@localhost.funkthat.com [127.0.0.1])i7C4aYuU014842; Wed, 11 Aug 2004 21:36:35 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i7C4aYnA014841; Wed, 11 Aug 2004 21:36:34 -0700 (PDT) Date: Wed, 11 Aug 2004 21:36:34 -0700 From: John-Mark Gurney To: Jeffrey Katcher Message-ID: <20040812043634.GB991@funkthat.com> Mail-Followup-To: Jeffrey Katcher , current@freebsd.org References: <20040812041934.GZ991@funkthat.com> <20040812042833.56392.qmail@web41105.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040812042833.56392.qmail@web41105.mail.yahoo.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: current@freebsd.org Subject: Re: Can someone please commit a sane module path in loader.conf? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2004 04:36:36 -0000 Jeffrey Katcher wrote this message on Wed, Aug 11, 2004 at 21:28 -0700: > --- John-Mark Gurney wrote: > > Jeffrey Katcher wrote this message on Wed, Aug 11, 2004 at 09:45 -0700: > > > I know I can override it in my local loader.conf, but the change to > > > /boot/modules only was _really_ annoying and unexpected. FYI, it should be > > > /boot/kernel for most people. > > > > No. Could you please upgrade your loader.rc as per UPDATING? > Of course, but UPDATING was only changed recently to mention this, and wasn't > as of ~9am PDT when I posted my request. sorry, I was a bit short with my original response. Just anoying that about half the user community didn't see the problems the other had.. (and I was one who couldn't see it)... It came down to people who had installed 5.1-RELEASE and upgraded from it that experienced the problem. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 04:44:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6879A16A4CE for ; Thu, 12 Aug 2004 04:44:47 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9E9443D46 for ; Thu, 12 Aug 2004 04:44:46 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by mproxy.gmail.com with SMTP id 75so199364rnl for ; Wed, 11 Aug 2004 21:44:46 -0700 (PDT) Received: by 10.38.92.32 with SMTP id p32mr1351183rnb; Wed, 11 Aug 2004 21:44:46 -0700 (PDT) Message-ID: Date: Thu, 12 Aug 2004 12:44:45 +0800 From: Jiawei Ye To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_176_2344176.1092285885887" Subject: Latest ACPI changes causing Interrupt Storm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 04:44:47 -0000 ------=_Part_176_2344176.1092285885887 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline kernel 30 mins old. dmesg -a, please also note the failing fdc, this has been broken for months. Copyright (c) 1992-2004 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 5.2-CURRENT #2: Thu Aug 12 12:19:04 CST 2004 leafy@chihiro.leafy.idv.tw:/usr/obj/usr/src/sys/CHIHIRO Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz (1794.56-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf12 Stepping = 2 Features=0x3febf9ff real memory = 268369920 (255 MB) avail memory = 252952576 (241 MB) netsmb_dev: loaded npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [GIANT-LOCKED] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 acpi link set: \\_SB_.LNKD resource is not an IRQ (2) acpi link set: \\_SB_.LNKD resource is not an IRQ (2) unknown: _SRS failed, irq 11 via \\_SB_.LNKD acpi link set: \\_SB_.LNKD resource is not an IRQ (2) unknown: _SRS failed, irq 10 via \\_SB_.LNKD acpi link set: \\_SB_.LNKD resource is not an IRQ (2) unknown: _SRS failed, irq 5 via \\_SB_.LNKD acpi link set: \\_SB_.LNKD resource is not an IRQ (2) unknown: _SRS failed, irq 9 via \\_SB_.LNKD acpi link set: \\_SB_.LNKD resource is not an IRQ (2) unknown: _SRS failed, irq 12 via \\_SB_.LNKD acpi link set: \\_SB_.LNKD resource is not an IRQ (2) unknown: _SRS failed, irq 7 via \\_SB_.LNKD acpi link set: \\_SB_.LNKD resource is not an IRQ (2) unknown: _SRS failed, irq 6 via \\_SB_.LNKD acpi link set: \\_SB_.LNKD resource is not an IRQ (2) unknown: _SRS failed, irq 4 via \\_SB_.LNKD acpi link set: \\_SB_.LNKD resource is not an IRQ (2) unknown: _SRS failed, irq 3 via \\_SB_.LNKD acpi link set: \\_SB_.LNKD resource is not an IRQ (2) unknown: _SRS failed, irq 15 via \\_SB_.LNKD acpi link set: \\_SB_.LNKD resource is not an IRQ (2) unknown: _SRS failed, irq 14 via \\_SB_.LNKD acpi link set: \\_SB_.LNKB resource is not an IRQ (2) acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 11 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 10 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 5 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 9 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 12 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 7 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 6 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 4 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 3 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 15 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 14 via \\_SB_.LNKB acpi link set: \\_SB_.LNKH resource is not an IRQ (2) acpi link set: \\_SB_.LNKH resource is not an IRQ (2) unknown: _SRS failed, irq 11 via \\_SB_.LNKH acpi link set: \\_SB_.LNKH resource is not an IRQ (2) unknown: _SRS failed, irq 10 via \\_SB_.LNKH acpi link set: \\_SB_.LNKH resource is not an IRQ (2) unknown: _SRS failed, irq 5 via \\_SB_.LNKH acpi link set: \\_SB_.LNKH resource is not an IRQ (2) unknown: _SRS failed, irq 9 via \\_SB_.LNKH acpi link set: \\_SB_.LNKH resource is not an IRQ (2) unknown: _SRS failed, irq 12 via \\_SB_.LNKH acpi link set: \\_SB_.LNKH resource is not an IRQ (2) unknown: _SRS failed, irq 7 via \\_SB_.LNKH acpi link set: \\_SB_.LNKH resource is not an IRQ (2) unknown: _SRS failed, irq 6 via \\_SB_.LNKH acpi link set: \\_SB_.LNKH resource is not an IRQ (2) unknown: _SRS failed, irq 4 via \\_SB_.LNKH acpi link set: \\_SB_.LNKH resource is not an IRQ (2) unknown: _SRS failed, irq 3 via \\_SB_.LNKH acpi link set: \\_SB_.LNKH resource is not an IRQ (2) unknown: _SRS failed, irq 15 via \\_SB_.LNKH acpi link set: \\_SB_.LNKH resource is not an IRQ (2) unknown: _SRS failed, irq 14 via \\_SB_.LNKH acpi link set: \\_SB_.LNKB resource is not an IRQ (2) acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 11 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 10 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 5 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 9 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 12 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 7 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 6 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 4 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 3 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 15 via \\_SB_.LNKB acpi link set: \\_SB_.LNKB resource is not an IRQ (2) unknown: _SRS failed, irq 14 via \\_SB_.LNKB agp0: mem 0xe8000000-0xebffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 acpi link set: \\_SB_.LNKA resource is not an IRQ (2) acpi link set: \\_SB_.LNKA resource is not an IRQ (2) pcib1: _SRS failed, irq 11 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) pcib1: _SRS failed, irq 10 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) pcib1: _SRS failed, irq 5 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) pcib1: _SRS failed, irq 9 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) pcib1: _SRS failed, irq 12 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) pcib1: _SRS failed, irq 7 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) pcib1: _SRS failed, irq 6 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) pcib1: _SRS failed, irq 4 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) pcib1: _SRS failed, irq 3 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) pcib1: _SRS failed, irq 15 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) pcib1: _SRS failed, irq 14 via \\_SB_.LNKA pci1: at device 0.0 (no driver attached) pcib2: at device 30.0 on pci0 pci2: on pcib2 acpi link set: \\_SB_.LNKF resource is not an IRQ (2) acpi link set: \\_SB_.LNKF resource is not an IRQ (2) unknown: _SRS failed, irq 11 via \\_SB_.LNKF acpi link set: \\_SB_.LNKF resource is not an IRQ (2) unknown: _SRS failed, irq 10 via \\_SB_.LNKF acpi link set: \\_SB_.LNKF resource is not an IRQ (2) unknown: _SRS failed, irq 5 via \\_SB_.LNKF acpi link set: \\_SB_.LNKF resource is not an IRQ (2) unknown: _SRS failed, irq 9 via \\_SB_.LNKF acpi link set: \\_SB_.LNKF resource is not an IRQ (2) unknown: _SRS failed, irq 12 via \\_SB_.LNKF acpi link set: \\_SB_.LNKF resource is not an IRQ (2) unknown: _SRS failed, irq 7 via \\_SB_.LNKF acpi link set: \\_SB_.LNKF resource is not an IRQ (2) unknown: _SRS failed, irq 6 via \\_SB_.LNKF acpi link set: \\_SB_.LNKF resource is not an IRQ (2) unknown: _SRS failed, irq 4 via \\_SB_.LNKF acpi link set: \\_SB_.LNKF resource is not an IRQ (2) unknown: _SRS failed, irq 3 via \\_SB_.LNKF acpi link set: \\_SB_.LNKF resource is not an IRQ (2) unknown: _SRS failed, irq 15 via \\_SB_.LNKF acpi link set: \\_SB_.LNKF resource is not an IRQ (2) unknown: _SRS failed, irq 14 via \\_SB_.LNKF acpi link set: \\_SB_.LNKG resource is not an IRQ (2) acpi link set: \\_SB_.LNKG resource is not an IRQ (2) unknown: _SRS failed, irq 11 via \\_SB_.LNKG acpi link set: \\_SB_.LNKG resource is not an IRQ (2) unknown: _SRS failed, irq 10 via \\_SB_.LNKG acpi link set: \\_SB_.LNKG resource is not an IRQ (2) unknown: _SRS failed, irq 5 via \\_SB_.LNKG acpi link set: \\_SB_.LNKG resource is not an IRQ (2) unknown: _SRS failed, irq 9 via \\_SB_.LNKG acpi link set: \\_SB_.LNKG resource is not an IRQ (2) unknown: _SRS failed, irq 12 via \\_SB_.LNKG acpi link set: \\_SB_.LNKG resource is not an IRQ (2) unknown: _SRS failed, irq 7 via \\_SB_.LNKG acpi link set: \\_SB_.LNKG resource is not an IRQ (2) unknown: _SRS failed, irq 6 via \\_SB_.LNKG acpi link set: \\_SB_.LNKG resource is not an IRQ (2) unknown: _SRS failed, irq 4 via \\_SB_.LNKG acpi link set: \\_SB_.LNKG resource is not an IRQ (2) unknown: _SRS failed, irq 3 via \\_SB_.LNKG acpi link set: \\_SB_.LNKG resource is not an IRQ (2) unknown: _SRS failed, irq 15 via \\_SB_.LNKG acpi link set: \\_SB_.LNKG resource is not an IRQ (2) unknown: _SRS failed, irq 14 via \\_SB_.LNKG acpi link set: \\_SB_.LNKA resource is not an IRQ (2) acpi link set: \\_SB_.LNKA resource is not an IRQ (2) unknown: _SRS failed, irq 11 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) unknown: _SRS failed, irq 10 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) unknown: _SRS failed, irq 5 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) unknown: _SRS failed, irq 9 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) unknown: _SRS failed, irq 12 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) unknown: _SRS failed, irq 7 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) unknown: _SRS failed, irq 6 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) unknown: _SRS failed, irq 4 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) unknown: _SRS failed, irq 3 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) unknown: _SRS failed, irq 15 via \\_SB_.LNKA acpi link set: \\_SB_.LNKA resource is not an IRQ (2) unknown: _SRS failed, irq 14 via \\_SB_.LNKA rl0: port 0xa800-0xa8ff mem 0xefefef00-0xefefefff irq 10 at device 1.0 on pci2 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:40:95:07:53:6b rl0: [GIANT-LOCKED] fxp0: port 0xa400-0xa41f mem 0xefd00000-0xefdfffff,0xe77ff000-0xe77fffff irq 9 at device 2.0 on pci2 miibus1: on fxp0 inphy0: on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:90:27:13:a4:48 fxp0: [GIANT-LOCKED] ahc0: port 0xac00-0xacff mem 0xefeff000-0xefefffff irq 11 at device 3.0 on pci2 ahc0: [GIANT-LOCKED] aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xff00-0xff0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xcc00-0xcc1f irq 10 at device 31.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 31.3 (no driver attached) uhci1: port 0xd400-0xd41f irq 10 at device 31.4 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pcm0: port 0xd800-0xd83f,0xdc00-0xdcff irq 5 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: acpi_button1: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3 irq 6 drq 2 on acpi0 fdc0: I/O to control range incorrect device_attach: fdc0 attach returned 6 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3 irq 6 drq 2 on acpi0 fdc0: I/O to control range incorrect device_attach: fdc0 attach returned 6 orm0: at iomem 0xe0000-0xe0fff,0xcc000-0xd17ff,0xc0000-0xcbfff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1794555960 Hz quality 800 Timecounters tick every 0.976 msec Waiting 15 seconds for SCSI devices to settle Interrupt storm detected on "irq5: pcm0"; throttling interrupt source Interrupt storm detected on "irq10: rl0 uhci0+"; throttling interrupt source Interrupt storm detected on "irq11: ahc0"; throttling interrupt source acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 30, 16bit), Tagged Queueing Enabled da0: 8678MB (17774160 512 byte sectors: 255H 63S/T 1106C) Mounting root from ufs:/dev/da0s1a ------=_Part_176_2344176.1092285885887 Content-Type: text/plain; name="foo.asl" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="foo.asl" /* RSD PTR: OEM=3DAMI, ACPI_Rev=3D1.0x (0) =09RSDT=3D0x0fff0000, cksum=3D156 */ /* RSDT: Length=3D40, Revision=3D1, Checksum=3D14, =09OEMID=3DAMIINT, OEM Table ID=3DAMIINT10, OEM Revision=3D0x1011, =09Creator ID=3DMSFT, Creator Revision=3D0x100000d =09Entries=3D{ 0x0fff0030 } */ /* FACP: Length=3D116, Revision=3D1, Checksum=3D120, =09OEMID=3DAMIINT, OEM Table ID=3DAMIINT10, OEM Revision=3D0x1011, =09Creator ID=3DMSFT, Creator Revision=3D0x100000d =09FACS=3D0xfff8000, DSDT=3D0xfff00b0 =09INT_MODEL=3DPIC =09Preferred_PM_Profile=3DUnspecified (0) =09SCI_INT=3D9 =09SMI_CMD=3D0xb2, ACPI_ENABLE=3D0xe1, ACPI_DISABLE=3D0x1e, S4BIOS_REQ=3D0x= 1f =09PSTATE_CNT=3D0x0 =09PM1a_EVT_BLK=3D0x400-0x403 =09PM1a_CNT_BLK=3D0x404-0x405 =09PM2_CNT_BLK=3D0x420-0x420 =09PM_TMR_BLK=3D0x408-0x40b =09GPE0_BLK=3D0x428-0x42b =09GPE1_BLK=3D0x42c-0x42f, GPE1_BASE=3D16 =09P_LVL2_LAT=3D100 us, P_LVL3_LAT=3D1000 us =09FLUSH_SIZE=3D1024, FLUSH_STRIDE=3D16 =09DUTY_OFFSET=3D1, DUTY_WIDTH=3D3 =09DAY_ALRM=3D13, MON_ALRM=3D0, CENTURY=3D50 =09IAPC_BOOT_ARCH=3D =09Flags=3D{WBINVD,PROC_C1,SLP_BUTTON} */ /* FACS:=09Length=3D64, HwSig=3D0x00000000, Firm_Wake_Vec=3D0x00000000 =09Global_Lock=3D =09Flags=3D =09Version=3D0 */ /* DSDT: Length=3D12551, Revision=3D1, Checksum=3D89, =09OEMID=3DINTEL, OEM Table ID=3DWHITNEY, OEM Revision=3D0x1000, =09Creator ID=3DMSFT, Creator Revision=3D0x100000d */ /* * Intel ACPI Component Architecture * AML Disassembler version 20040527 * * Disassembly of /tmp/acpidump.3fiW25, Thu Aug 12 12:41:42 2004 */ DefinitionBlock ("DSDT.aml", "DSDT", 1, "INTEL", "WHITNEY", 4096) { Scope (\_PR) { Processor (CPU1, 0x01, 0x00000410, 0x06) {} } OperationRegion (CM72, SystemIO, 0x72, 0x02) Field (CM72, ByteAcc, NoLock, Preserve) { CI72, 8,=20 CO73, 8 } IndexField (CI72, CO73, ByteAcc, NoLock, Preserve) { Offset (0xD5),=20 ULED, 8,=20 Offset (0xDA),=20 UASB, 1,=20 USBE, 1,=20 FLOS, 2,=20 Offset (0xDC),=20 , 3,=20 , 1,=20 ACST, 3,=20 Offset (0xDE),=20 LNRI, 8 } Name (\_S0, Package (0x04) { 0x00,=20 0x00,=20 0x00,=20 0x00 }) Name (\_S1, Package (0x04) { 0x01,=20 0x00,=20 0x00,=20 0x00 }) Name (\_S4, Package (0x04) { 0x06,=20 0x00,=20 0x00,=20 0x00 }) Name (\_S5, Package (0x04) { 0x07,=20 0x00,=20 0x00,=20 0x00 }) Method (MCTH, 2, NotSerialized) { If (LLess (SizeOf (Arg0), SizeOf (Arg1))) { Return (0x00) } Add (SizeOf (Arg0), 0x01, Local0) Name (BUF0, Buffer (Local0) {}) Name (BUF1, Buffer (Local0) {}) Store (Arg0, BUF0) Store (Arg1, BUF1) While (Local0) { Decrement (Local0) If (LEqual (DerefOf (Index (BUF0, Local0)), DerefOf (Index (BUF= 1, Local0)))) {} Else { Return (Zero) } } Return (One) } Scope (\_SB) { Name (APIC, 0x00) Method (_PIC, 1, NotSerialized) { Store (Arg0, APIC) } Device (PWRB) { Name (_HID, EisaId ("PNP0C0C")) Method (_STA, 0, NotSerialized) { Return (0x0B) } } Device (PCI0) { Name (_HID, EisaId ("PNP0A03")) Name (_UID, 0x01) Name (_ADR, 0x00) Name (_BBN, 0x00) Name (SS3D, 0x02) Name (CRS, ResourceTemplate () { WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDec= ode, 0x0000, 0x0000, 0x00FF, 0x0000, 0x0100) IO (Decode16, 0x0CF8, 0x0CF8, 0x01, 0x08) WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, En= tireRange, 0x0000, 0x0000, 0x0CF7, 0x0000, 0x0CF8) WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, En= tireRange, 0x0000, 0x0D00, 0xFFFF, 0x0000, 0xF300) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixe= d, Cacheable, ReadWrite, 0x00000000, 0x000A0000, 0x000BFFFF, 0x00000000, 0x00020000) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixe= d, Cacheable, ReadWrite, 0x00000000, 0x000CB000, 0x000DFFFF, 0x00000000, 0x00015000) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixe= d, Cacheable, ReadWrite, 0x00000000, 0x20000000, 0xFFDFFFFF, 0x00000000, 0xDFE00000) }) OperationRegion (TMEM, PCI_Config, 0x7E, 0x02) Field (TMEM, WordAcc, NoLock, Preserve) { MEMT, 11 } Name (TOM, 0x00) Method (MDET, 0, NotSerialized) { If (LNot (TOM)) { If (FLAG) { ShiftLeft (MEMT, 0x18, TOM) } Else { Return (0x20000000) } } Return (TOM) } Name (FLAG, 0x01) Name (OSFL, 0x02) Method (_INI, 0, NotSerialized) { \_SB.PCI0.SBRG.IODT () If (MCTH (\_OS, "Microsoft Windows")) { Store (0x02, OSFL) } Else { If (MCTH (\_OS, "Microsoft WindowsME: Millennium Editio= n")) { Store (0x03, OSFL) } Else { Store (0x01, OSFL) } } } Method (_REG, 2, NotSerialized) { If (LEqual (Arg0, 0x02)) { Store (Arg1, FLAG) } } Method (_CRS, 0, NotSerialized) { CreateDWordField (CRS, 0x76, TMEM) CreateDWordField (CRS, 0x82, TLEN) Store (MDET (), TMEM) Subtract (0xFFE00000, TMEM, TLEN) Return (CRS) } Name (_PRT, Package (0x06) { Package (0x04) { 0x001FFFFF,=20 0x00,=20 \_SB.LNKA,=20 0x00 },=20 Package (0x04) { 0x001FFFFF,=20 0x01,=20 \_SB.LNKB,=20 0x00 },=20 Package (0x04) { 0x001FFFFF,=20 0x02,=20 \_SB.LNKH,=20 0x00 },=20 Package (0x04) { 0x001FFFFF,=20 0x03,=20 \_SB.LNKD,=20 0x00 },=20 Package (0x04) { 0x0001FFFF,=20 0x00,=20 LNKA,=20 0x00 },=20 Package (0x04) { 0x0001FFFF,=20 0x01,=20 LNKB,=20 0x00 } }) Device (SBRG) { Name (_ADR, 0x001F0000) Name (\_SB.IPRS, ResourceTemplate () { StartDependentFnNoPri () { IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,9,10,11,1= 2,14,15} } EndDependentFn () }) OperationRegion (PIX0, PCI_Config, 0x60, 0x04) OperationRegion (PIX1, PCI_Config, 0x68, 0x04) OperationRegion (LPC0, PCI_Config, 0xE0, 0x08) OperationRegion (LPC1, PCI_Config, 0xEC, 0x02) Scope (\_SB) { Field (\_SB.PCI0.SBRG.PIX0, ByteAcc, NoLock, Preserve) { PIRA, 8,=20 PIRB, 8,=20 PIRC, 8,=20 PIRD, 8 } Field (\_SB.PCI0.SBRG.PIX1, ByteAcc, NoLock, Preserve) { PIRE, 8,=20 PIRF, 8,=20 PIRG, 8,=20 PIRH, 8 } Field (\_SB.PCI0.SBRG.LPC0, ByteAcc, NoLock, Preserve) { LPCA, 3,=20 , 1,=20 LPCB, 3,=20 Offset (0x01),=20 LPLP, 2,=20 , 2,=20 LPFD, 1,=20 Offset (0x02),=20 LPSB, 2,=20 , 1,=20 LPMD, 1,=20 LPMS, 2,=20 Offset (0x03),=20 Offset (0x04),=20 GEN1, 16,=20 CAEN, 1,=20 CBEN, 1,=20 LPEN, 1,=20 FDEN, 1,=20 SBEN, 1,=20 MDEN, 1,=20 MSEN, 1,=20 ADEN, 1,=20 GMLE, 1,=20 GMHE, 1,=20 KBEN, 1,=20 MCEN, 1,=20 CF1E, 1,=20 CF2E, 1,=20 Offset (0x08) } Field (\_SB.PCI0.SBRG.LPC1, ByteAcc, NoLock, Preserve) { GEN2, 16 } Name (BUFA, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {15} }) CreateWordField (BUFA, 0x01, IRA0) Device (LNKA) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x01) Method (_STA, 0, NotSerialized) { And (PIRA, 0x80, Local0) If (Local0) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (IPRS) } Method (_DIS, 0, NotSerialized) { Or (PIRA, 0x80, PIRA) } Method (_CRS, 0, NotSerialized) { And (PIRA, 0x0F, Local0) ShiftLeft (0x01, Local0, IRA0) Return (BUFA) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRA) FindSetRightBit (IRA, Local0) Decrement (Local0) Store (Local0, PIRA) } } Device (LNKB) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x02) Method (_STA, 0, NotSerialized) { And (PIRB, 0x80, Local0) If (Local0) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (IPRS) } Method (_DIS, 0, NotSerialized) { Or (PIRB, 0x80, PIRB) } Method (_CRS, 0, NotSerialized) { And (PIRB, 0x0F, Local0) ShiftLeft (0x01, Local0, IRA0) Return (BUFA) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRA) FindSetRightBit (IRA, Local0) Decrement (Local0) Store (Local0, PIRB) } } Device (LNKC) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x03) Method (_STA, 0, NotSerialized) { And (PIRC, 0x80, Local0) If (Local0) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (IPRS) } Method (_DIS, 0, NotSerialized) { Or (PIRC, 0x80, PIRC) } Method (_CRS, 0, NotSerialized) { And (PIRC, 0x0F, Local0) ShiftLeft (0x01, Local0, IRA0) Return (BUFA) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRA) FindSetRightBit (IRA, Local0) Decrement (Local0) Store (Local0, PIRC) } } Device (LNKD) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x04) Method (_STA, 0, NotSerialized) { And (PIRD, 0x80, Local0) If (Local0) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (IPRS) } Method (_DIS, 0, NotSerialized) { Or (PIRD, 0x80, PIRD) } Method (_CRS, 0, NotSerialized) { And (PIRD, 0x0F, Local0) ShiftLeft (0x01, Local0, IRA0) Return (BUFA) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRA) FindSetRightBit (IRA, Local0) Decrement (Local0) Store (Local0, PIRD) } } Device (LNKE) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x05) Method (_STA, 0, NotSerialized) { And (PIRE, 0x80, Local0) If (Local0) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (IPRS) } Method (_DIS, 0, NotSerialized) { Or (PIRE, 0x80, PIRE) } Method (_CRS, 0, NotSerialized) { And (PIRE, 0x0F, Local0) ShiftLeft (0x01, Local0, IRA0) Return (BUFA) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRA) FindSetRightBit (IRA, Local0) Decrement (Local0) Store (Local0, PIRE) } } Device (LNKF) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x06) Method (_STA, 0, NotSerialized) { And (PIRF, 0x80, Local0) If (Local0) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (IPRS) } Method (_DIS, 0, NotSerialized) { Or (PIRF, 0x80, PIRF) } Method (_CRS, 0, NotSerialized) { And (PIRF, 0x0F, Local0) ShiftLeft (0x01, Local0, IRA0) Return (BUFA) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRA) FindSetRightBit (IRA, Local0) Decrement (Local0) Store (Local0, PIRF) } } Device (LNKG) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x07) Method (_STA, 0, NotSerialized) { And (PIRG, 0x80, Local0) If (Local0) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (IPRS) } Method (_DIS, 0, NotSerialized) { Or (PIRG, 0x80, PIRG) } Method (_CRS, 0, NotSerialized) { And (PIRG, 0x0F, Local0) ShiftLeft (0x01, Local0, IRA0) Return (BUFA) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRA) FindSetRightBit (IRA, Local0) Decrement (Local0) Store (Local0, PIRG) } } Device (LNKH) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x08) Method (_STA, 0, NotSerialized) { And (PIRH, 0x80, Local0) If (Local0) { Return (0x09) } Else { Return (0x0B) } } Method (_PRS, 0, NotSerialized) { Return (IPRS) } Method (_DIS, 0, NotSerialized) { Or (PIRH, 0x80, PIRH) } Method (_CRS, 0, NotSerialized) { And (PIRH, 0x0F, Local0) ShiftLeft (0x01, Local0, IRA0) Return (BUFA) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRA) FindSetRightBit (IRA, Local0) Decrement (Local0) Store (Local0, PIRH) } } } OperationRegion (SBFN, PCI_Config, 0xF2, 0x01) Device (SYSR) { Name (_HID, EisaId ("PNP0C02")) Method (_STA, 0, NotSerialized) { Store (OSFL, FLOS) If (And (OSFL, 0x02)) { Return (0x0F) } Return (0x00) } Name (IORG, ResourceTemplate () { FixedIO (0x0010, 0x10) FixedIO (0x0022, 0x1E) FixedIO (0x0044, 0x1C) FixedIO (0x0062, 0x02) FixedIO (0x0065, 0x0B) FixedIO (0x0072, 0x0E) FixedIO (0x0080, 0x01) FixedIO (0x0084, 0x03) FixedIO (0x0088, 0x01) FixedIO (0x008C, 0x03) FixedIO (0x0090, 0x10) FixedIO (0x00A2, 0x1E) FixedIO (0x00E0, 0x10) FixedIO (0x0295, 0x02) IO (Decode16, 0x04D0, 0x04D0, 0x00, 0x02) IO (Decode16, 0x0400, 0x0400, 0x00, 0x80) IO (Decode16, 0x0480, 0x0480, 0x00, 0x40) }) Method (_CRS, 0, NotSerialized) { Return (IORG) } } Device (FWH) { Name (_HID, EisaId ("INT0800")) Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadWrite, 0xFFB80000, 0x00080000) }) } Device (\_SB.MEM) { Name (_HID, EisaId ("PNP0C01")) Method (_STA, 0, NotSerialized) { If (And (\_SB.PCI0.OSFL, 0x02)) { Return (0x0F) } Return (0x00) } Name (MEM1, ResourceTemplate () { Memory32Fixed (ReadWrite, 0x00000000, 0x000A0000) Memory32Fixed (ReadOnly, 0x000E0000, 0x00020000) Memory32Fixed (ReadWrite, 0x00100000, 0x1FF00000) Memory32Fixed (ReadOnly, 0xFFF80000, 0x00080000) }) Method (_CRS, 0, NotSerialized) { CreateDWordField (MEM1, 0x20, TOP1) Subtract (\_SB.PCI0.MDET (), 0x00100000, TOP1) Return (MEM1) } } Device (PIC) { Name (_HID, EisaId ("PNP0000")) Name (_CRS, ResourceTemplate () { FixedIO (0x0020, 0x02) FixedIO (0x00A0, 0x02) IRQNoFlags () {2} }) } Device (DMAD) { Name (_HID, EisaId ("PNP0200")) Name (_CRS, ResourceTemplate () { DMA (Compatibility, BusMaster, Transfer8) {4} FixedIO (0x0000, 0x10) FixedIO (0x0081, 0x03) FixedIO (0x0087, 0x01) FixedIO (0x0089, 0x03) FixedIO (0x008F, 0x01) FixedIO (0x00C0, 0x20) }) } Device (TMR) { Name (_HID, EisaId ("PNP0100")) Name (_CRS, ResourceTemplate () { FixedIO (0x0040, 0x04) IRQNoFlags () {0} }) } Device (RTC) { Name (_HID, EisaId ("PNP0B00")) Name (_CRS, ResourceTemplate () { FixedIO (0x0070, 0x02) IRQNoFlags () {8} }) } Device (SPKR) { Name (_HID, EisaId ("PNP0800")) Name (_CRS, ResourceTemplate () { FixedIO (0x0061, 0x01) }) } Device (COPR) { Name (_HID, EisaId ("PNP0C04")) Name (_CRS, ResourceTemplate () { FixedIO (0x00F0, 0x10) IRQNoFlags () {13} }) } OperationRegion (PSRG, SystemMemory, 0x0410, 0x01) Field (PSRG, ByteAcc, NoLock, Preserve) { , 2,=20 PS2E, 1 } Device (PS2M) { Name (_HID, EisaId ("PNP0F03")) Name (_CID, 0x130FD041) Method (_STA, 0, NotSerialized) { If (PS2E) { Return (0x0F) } Else { Return (0x00) } } Name (MCRS, ResourceTemplate () { IRQNoFlags () {12} }) Method (_CRS, 0, NotSerialized) { Return (MCRS) } } Device (PS2K) { Name (_HID, EisaId ("PNP0303")) Name (_CID, 0x0B03D041) Name (KCRS, ResourceTemplate () { FixedIO (0x0060, 0x01) FixedIO (0x0064, 0x01) IRQNoFlags () {1} }) Method (_CRS, 0, NotSerialized) { Return (KCRS) } } Name (SPIO, 0x2E) OperationRegion (WIN1, SystemIO, SPIO, 0x02) Field (WIN1, ByteAcc, NoLock, Preserve) { INDX, 8,=20 DATA, 8 } IndexField (INDX, DATA, ByteAcc, NoLock, Preserve) { Offset (0x02),=20 CFG, 8,=20 Offset (0x07),=20 LDN, 8,=20 Offset (0x30),=20 ACTR, 1,=20 ACT1, 1,=20 ACT2, 1,=20 Offset (0x31),=20 Offset (0x60),=20 IOAH, 8,=20 IOAL, 8,=20 IOEH, 8,=20 IOEL, 8,=20 Offset (0x70),=20 INTR, 8,=20 Offset (0x72),=20 INT1, 8,=20 Offset (0x74),=20 DMCH, 8,=20 Offset (0xC0),=20 GP40, 8,=20 Offset (0xE0),=20 RGE0, 8,=20 RGE1, 8,=20 RGE2, 8,=20 RGE3, 8,=20 RGE4, 8,=20 Offset (0xF0),=20 OPT1, 8,=20 OPT2, 8,=20 OPT3, 8,=20 OPT4, 8,=20 OPT5, 8,=20 OPT6, 8,=20 OPT7, 8,=20 OPT8, 8,=20 OPT9, 8,=20 OPTA, 8 } OperationRegion (HWMT, SystemIO, 0x0295, 0x02) Field (HWMT, ByteAcc, NoLock, Preserve) { HWIN, 8,=20 HWDT, 8 } IndexField (HWIN, HWDT, ByteAcc, NoLock, Preserve) { Offset (0x40),=20 HW40, 8,=20 HW41, 8,=20 HW42, 8,=20 HW43, 8,=20 HW44, 8,=20 Offset (0x46),=20 HW46, 8,=20 HW47, 8,=20 HW48, 8,=20 HW49, 8,=20 HW4A, 8,=20 HW4B, 8,=20 HW4C, 8,=20 HW4D, 8,=20 HW4E, 8,=20 HW4F, 8,=20 HW50, 8,=20 HW51, 8,=20 HW52, 8,=20 HW53, 8,=20 HW54, 8,=20 HW55, 8,=20 HW56, 8,=20 HW57, 8,=20 HW58, 8,=20 HW59, 8,=20 HW5A, 8,=20 HW5B, 8,=20 HW5C, 8,=20 HW5D, 8,=20 HW5E, 8,=20 HW5F, 8 } Method (ENFG, 0, NotSerialized) { Store (0x87, INDX) Store (0x87, INDX) } Method (EXFG, 0, NotSerialized) { Store (0xAA, INDX) } Name (LDFD, 0x00) Name (LDU1, 0x02) Name (LDU2, 0x03) Name (LDIR, 0x06) Name (LDLP, 0x01) Name (LDGM, 0x07) Name (LDMD, 0x07) Device (FDC0) { Name (_HID, EisaId ("PNP0700")) Method (_STA, 0, NotSerialized) { If (FDST) { Return (GSTA (0x00)) } Return (0x00) } Method (_DIS, 0, NotSerialized) { Store (Zero, FDEN) DDIS (0x00) } Method (_CRS, 0, NotSerialized) { Return (FCRS) } Method (_PRS, 0, NotSerialized) { Return (FPRS) } Method (_SRS, 1, NotSerialized) { Store (One, FDEN) DENB (0x00) } } Device (UAR1) { Name (_HID, EisaId ("PNP0501")) Name (_UID, 0x01) Method (_STA, 0, NotSerialized) { If (U1ST) { Return (GSTA (0x02)) } Return (0x00) } Method (_DIS, 0, NotSerialized) { Store (Zero, CAEN) DDIS (0x02) } Method (_CRS, 0, NotSerialized) { Return (PCRS (0x02, 0x01, 0x08)) } Method (_SRS, 1, NotSerialized) { PSRS (Arg0, 0x02) Store (One, CAEN) ENFG () If (LEqual (IOAH, 0x03)) { If (LEqual (IOAL, 0xF8)) { Store (Zero, LPCA) } Else { Store (0x07, LPCA) } } Else { If (LEqual (IOAL, 0xF8)) { Store (One, LPCA) } Else { Store (0x05, LPCA) } } EXFG () } Method (_PRS, 0, NotSerialized) { Return (C1PR) } } Device (UAR2) { Method (_HID, 0, NotSerialized) { ENFG () Store (LDU2, LDN) And (OPT2, 0x38, Local0) EXFG () If (Local0) { Return (0x1005D041) } Else { Return (0x0105D041) } } Name (_UID, 0x02) Method (_STA, 0, NotSerialized) { If (U2ST) { Return (GSTA (0x03)) } Return (0x00) } Method (_DIS, 0, NotSerialized) { Store (Zero, CBEN) DDIS (0x03) } Method (_CRS, 0, NotSerialized) { Return (PCRS (0x03, 0x01, 0x08)) } Method (_SRS, 1, NotSerialized) { PSRS (Arg0, 0x03) Store (One, CBEN) ENFG () If (LEqual (IOAH, 0x03)) { If (LEqual (IOAL, 0xF8)) { Store (Zero, LPCB) } Else { Store (0x07, LPCB) } } Else { If (LEqual (IOAL, 0xF8)) { Store (One, LPCB) } Else { Store (0x05, LPCB) } } EXFG () } Method (_PRS, 0, NotSerialized) { Return (C2PR) } } Device (IRDA) { Name (_HID, EisaId ("PNP0510")) Method (_STA, 0, NotSerialized) { If (IRST) { Return (GSTA (LDIR)) } Return (0x00) } Method (_DIS, 0, NotSerialized) { DDIS (LDIR) } Method (_CRS, 0, NotSerialized) { Name (BUF6, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x10, 0x08) IRQNoFlags () {} }) CreateByteField (BUF6, 0x02, IOLO) CreateByteField (BUF6, 0x03, IOHI) CreateByteField (BUF6, 0x04, IORL) CreateByteField (BUF6, 0x05, IORH) CreateWordField (BUF6, 0x09, IRQM) ENFG () Store (LDIR, LDN) If (ACTR) { Store (0x98, IOLO) Store (0x02, IOHI) } Else { Store (0x00, IOLO) Store (0x00, IOHI) } Store (IOLO, IORL) Store (IOHI, IORH) ShiftLeft (0x01, INTR, IRQM) EXFG () Return (BUF6) } Method (_SRS, 1, NotSerialized) { PSRS (Arg0, LDIR) } Name (_PRS, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x0298, 0x0298, 0x08, 0x08) IRQNoFlags () {3,4,9,10,11} } EndDependentFn () }) } Device (LPT) { Name (_HID, EisaId ("PNP0400")) Method (_STA, 0, NotSerialized) { ENFG () Store (0x01, LDN) And (OPT1, 0x02, Local0) EXFG () If (Or (Local0, And (Not (LPST), 0x01))) { Return (Zero) } Else { Return (GSTA (0x01)) } } Method (_DIS, 0, NotSerialized) { Store (Zero, LPEN) DDIS (0x01) } Method (_CRS, 0, NotSerialized) { Return (PCRS (0x01, 0x01, 0x08)) } Method (_SRS, 1, NotSerialized) { PSRS (Arg0, 0x01) Store (One, LPEN) ENFG () If (LEqual (IOAH, 0x03)) { If (LEqual (IOAL, 0x78)) { Store (Zero, LPLP) } Else { Store (0x02, LPLP) } } Else { Store (One, LPLP) } EXFG () } Method (_PRS, 0, NotSerialized) { Return (LPPR) } } Device (ECP) { Name (_HID, EisaId ("PNP0401")) Method (_STA, 0, NotSerialized) { ENFG () Store (0x01, LDN) And (OPT1, 0x02, Local0) EXFG () If (Local0) { If (LPST) { Return (GSTA (0x01)) } Else { Return (Zero) } } Else { Return (Zero) } } Method (_DIS, 0, NotSerialized) { Store (Zero, LPEN) DDIS (0x01) } Method (_CRS, 0, NotSerialized) { Return (ECRS (0x01)) } Method (_SRS, 1, NotSerialized) { ESRS (Arg0, 0x01) Store (One, LPEN) ENFG () If (LEqual (IOAH, 0x03)) { If (LEqual (IOAL, 0x78)) { Store (Zero, LPLP) } Else { Store (0x02, LPLP) } } Else { Store (One, LPLP) } EXFG () } Method (_PRS, 0, NotSerialized) { Return (EPRS) } } Device (GAME) { Name (_HID, EisaId ("PNPB02F")) Method (_STA, 0, NotSerialized) { ENFG () Store (LDGM, LDN) If (LOr (GMLE, GMHE)) { EXFG () Return (0x0F) } Else { Add (IOAH, IOAL, Local0) If (Local0) { EXFG () Return (0x0D) } Else { EXFG () Return (Zero) } } } Method (_DIS, 0, NotSerialized) { Store (Zero, GMLE) Store (Zero, GMHE) } Method (_CRS, 0, NotSerialized) { Name (BUF6, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x08, 0x08) }) CreateByteField (BUF6, 0x02, IOLO) CreateByteField (BUF6, 0x03, IOHI) CreateByteField (BUF6, 0x04, IORL) CreateByteField (BUF6, 0x05, IORH) ENFG () Store (LDGM, LDN) If (LEqual (IOAL, 0x00)) { Store (0x00, IOLO) Store (0x02, IOHI) } Else { Store (0x08, IOLO) Store (0x02, IOHI) } Store (IOLO, IORL) Store (IOHI, IORH) EXFG () Return (BUF6) } Name (_PRS, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x0200, 0x0200, 0x08, 0x08) } StartDependentFnNoPri () { IO (Decode16, 0x0208, 0x0208, 0x08, 0x08) } EndDependentFn () }) Method (_SRS, 1, NotSerialized) { CreateByteField (Arg0, 0x02, IOLO) CreateByteField (Arg0, 0x03, IOHI) ENFG () Store (LDGM, LDN) If (LEqual (IOLO, 0x00)) { Store (0x02, IOAH) Store (0x00, IOAL) } Else { Store (0x02, IOAH) Store (0x08, IOAL) } If (LEqual (IOAL, 0x00)) { Store (One, GMLE) Store (Zero, GMHE) } Else { Store (Zero, GMLE) Store (One, GMHE) } EXFG () } } Device (MIDI) { Name (_HID, EisaId ("PNPB006")) Method (_STA, 0, NotSerialized) { ENFG () Store (LDMD, LDN) If (LOr (MDEN, LEqual (IOEH, 0x02))) { EXFG () Return (0x0F) } Else { Add (IOEH, IOEL, Local0) If (Local0) { EXFG () Return (0x0D) } Else { EXFG () Return (Zero) } } } Method (_DIS, 0, NotSerialized) { Store (Zero, MDEN) } Method (_CRS, 0, NotSerialized) { Name (BUF6, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x02, 0x02) IRQNoFlags () {} }) CreateByteField (BUF6, 0x02, IOLO) CreateByteField (BUF6, 0x03, IOHI) CreateByteField (BUF6, 0x04, IORL) CreateByteField (BUF6, 0x05, IORH) CreateWordField (BUF6, 0x09, IRQM) ENFG () Store (LDMD, LDN) If (LEqual (IOEH, 0x03)) { Store (0x03, IOHI) If (LEqual (IOEL, 0x30)) { Store (0x30, IOLO) } Else { Store (0x00, IOLO) } } Else { Store (0x02, IOHI) If (LEqual (IOEL, 0x90)) { Store (0x90, IOLO) } Else { Store (0x92, IOLO) } } Store (IOLO, IORL) Store (IOHI, IORH) ShiftLeft (0x01, INTR, IRQM) EXFG () Return (BUF6) } Name (_PRS, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x0330, 0x0330, 0x02, 0x02) IRQNoFlags () {5,7,9,10} } StartDependentFnNoPri () { IO (Decode16, 0x0300, 0x0300, 0x02, 0x02) IRQNoFlags () {5,7,9,10} } StartDependentFnNoPri () { IO (Decode16, 0x0290, 0x0290, 0x02, 0x02) IRQNoFlags () {5,7,9,10} } StartDependentFnNoPri () { IO (Decode16, 0x0292, 0x0292, 0x02, 0x02) IRQNoFlags () {5,7,9,10} } EndDependentFn () }) Method (_SRS, 1, NotSerialized) { CreateByteField (Arg0, 0x02, IOLO) CreateByteField (Arg0, 0x03, IOHI) CreateWordField (Arg0, 0x09, IRQM) ENFG () Store (LDMD, LDN) If (LEqual (IOHI, 0x03)) { Store (0x03, IOEH) If (LEqual (IOLO, 0x30)) { Store (0x30, IOEL) Store (Zero, LPMD) } Else { Store (0x00, IOEL) Store (One, LPMD) } Store (One, MDEN) } Else { Store (0x02, IOEH) If (LEqual (IOLO, 0x90)) { Store (0x90, IOEL) } Else { Store (0x92, IOEL) } } FindSetRightBit (IRQM, Local0) Subtract (Local0, 0x01, INTR) EXFG () } } Name (FDST, 0x00) Name (U1ST, 0x00) Name (U2ST, 0x00) Name (IRST, 0x00) Name (LPST, 0x00) Method (IODT, 0, NotSerialized) { If (LEqual (GSTA (LDFD), 0x0F)) { Store (0x01, FDST) } If (LEqual (GSTA (LDU1), 0x0F)) { Store (0x01, U1ST) } If (LEqual (GSTA (LDU2), 0x0F)) { Store (0x01, U2ST) } If (LEqual (GSTA (LDIR), 0x0F)) { Store (0x01, IRST) } If (LEqual (GSTA (LDLP), 0x0F)) { Store (0x01, LPST) } } Method (GSTA, 1, NotSerialized) { ENFG () Store (Arg0, LDN) If (ACTR) { Store (0x0F, Local0) } Else { If (Or (IOAH, IOAL)) { Store (0x0D, Local0) } Else { Store (0x00, Local0) } } EXFG () Return (Local0) } Method (DDIS, 1, NotSerialized) { ENFG () Store (Arg0, LDN) Store (Zero, ACTR) EXFG () } Method (DENB, 1, NotSerialized) { ENFG () Store (Arg0, LDN) Store (One, ACTR) EXFG () } Method (PCRS, 3, NotSerialized) { CreateByteField (PBUF, 0x02, IOLO) CreateByteField (PBUF, 0x03, IOHI) CreateWordField (PBUF, 0x02, IOHL) CreateWordField (PBUF, 0x04, IORL) CreateByteField (PBUF, 0x06, ALMN) CreateByteField (PBUF, 0x07, LENG) CreateByteField (PBUF, 0x09, IRQL) ENFG () Store (Arg0, LDN) Store (IOAH, IOHI) Store (IOAL, IOLO) Store (IOHL, IORL) Store (Arg1, ALMN) If (LEqual (IOLO, 0xBC)) { Store (0x04, LENG) } Else { Store (Arg2, LENG) } Store (One, Local0) ShiftLeft (Local0, INTR, IRQL) EXFG () Return (PBUF) } Method (PSRS, 2, NotSerialized) { CreateByteField (Arg0, 0x02, POLB) CreateByteField (Arg0, 0x03, POHB) CreateByteField (Arg0, 0x09, PIRQ) ENFG () Store (Arg1, LDN) Store (POLB, IOAL) Store (POHB, IOAH) FindSetRightBit (PIRQ, Local0) Subtract (Local0, 0x01, INTR) Store (One, ACTR) EXFG () } Method (ECRS, 1, NotSerialized) { CreateByteField (EBUF, 0x02, EPLO) CreateByteField (EBUF, 0x03, EPHI) CreateWordField (EBUF, 0x02, EPHL) CreateWordField (EBUF, 0x04, EPRL) CreateWordField (EBUF, 0x06, ALM1) CreateWordField (EBUF, 0x0A, E4LO) CreateWordField (EBUF, 0x0C, E4RL) CreateWordField (EBUF, 0x11, EIRQ) CreateWordField (EBUF, 0x14, EDMA) ENFG () Store (Arg0, LDN) Store (IOAH, EPHI) Store (IOAL, EPLO) Store (EPHL, EPRL) Add (EPHL, 0x0400, E4LO) Store (E4LO, E4RL) If (LEqual (EPHL, 0x03BC)) { Store (0x0401, ALM1) } Else { Store (0x0801, ALM1) } Store (One, Local0) Store (INTR, Local1) ShiftLeft (Local0, Local1, EIRQ) Store (DMCH, Local1) If (LGreater (Local1, 0x03)) { Store (0x00, EDMA) } Else { Store (One, Local0) ShiftLeft (Local0, Local1, EDMA) } EXFG () Return (EBUF) } Method (ESRS, 2, NotSerialized) { CreateByteField (Arg0, 0x02, LOEP) CreateByteField (Arg0, 0x03, HIEP) CreateWordField (Arg0, 0x11, IRQE) CreateWordField (Arg0, 0x14, DMAE) ENFG () Store (Arg1, LDN) Store (LOEP, IOAL) Store (HIEP, IOAH) FindSetRightBit (IRQE, Local0) Subtract (Local0, 0x01, INTR) If (DMAE) { FindSetRightBit (DMAE, Local0) Subtract (Local0, 0x01, DMCH) } Else { Store (0x04, DMCH) } Store (One, ACTR) EXFG () } Name (CNBF, Buffer (0x02) { 0xF8, 0x03 }) Method (UABS, 1, NotSerialized) { ENFG () Store (Arg0, LDN) CreateByteField (CNBF, 0x00, IOLO) CreateByteField (CNBF, 0x01, IOHI) CreateWordField (CNBF, 0x00, IOAD) Store (IOAL, IOLO) Store (IOAH, IOHI) EXFG () Return (IOAD) } Name (CSCP, 0x00) PowerResource (URP1, 0x01, 0x0000) { Method (_STA, 0, NotSerialized) { Return (CSCP) } Method (_ON, 0, NotSerialized) { Store (0x01, CSCP) } Method (_OFF, 0, NotSerialized) { Store (0x00, CSCP) } } PowerResource (URP2, 0x01, 0x0000) { Method (_STA, 0, NotSerialized) { Return (CSCP) } Method (_ON, 0, NotSerialized) { Store (0x01, CSCP) } Method (_OFF, 0, NotSerialized) { Store (0x00, CSCP) } } PowerResource (FDDP, 0x00, 0x0000) { Method (_STA, 0, NotSerialized) { Return (CSCP) } Method (_ON, 0, NotSerialized) { Store (0x01, CSCP) } Method (_OFF, 0, NotSerialized) { Store (0x00, CSCP) } } PowerResource (LPTP, 0x00, 0x0000) { Method (_STA, 0, NotSerialized) { Return (CSCP) } Method (_ON, 0, NotSerialized) { Store (0x01, CSCP) } Method (_OFF, 0, NotSerialized) { Store (0x00, CSCP) } } Name (FCRS, ResourceTemplate () { IO (Decode16, 0x03F2, 0x03F2, 0x01, 0x02) IO (Decode16, 0x03F4, 0x03F4, 0x01, 0x02) IO (Decode16, 0x03F7, 0x03F7, 0x01, 0x01) IRQNoFlags () {6} DMA (Compatibility, NotBusMaster, Transfer8) {2} }) Name (PBUF, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x01, 0x08) IRQNoFlags () {0} }) Name (EBUF, ResourceTemplate () { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IO (Decode16, 0x0778, 0x0778, 0x01, 0x04) IRQNoFlags () {7} DMA (Compatibility, NotBusMaster, Transfer8) {} }) Name (FPRS, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x03F2, 0x03F2, 0x01, 0x02) IO (Decode16, 0x03F4, 0x03F4, 0x01, 0x02) IO (Decode16, 0x03F7, 0x03F7, 0x01, 0x01) IRQNoFlags () {6} DMA (Compatibility, NotBusMaster, Transfer8) {2} } EndDependentFn () }) Name (C1PR, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x03F8, 0x03F8, 0x04, 0x08) IRQNoFlags () {4} } StartDependentFnNoPri () { IO (Decode16, 0x03F8, 0x03F8, 0x04, 0x08) IRQNoFlags () {3,4,10,11} } StartDependentFnNoPri () { IO (Decode16, 0x02F8, 0x02F8, 0x04, 0x08) IRQNoFlags () {3,4,10,11} } StartDependentFnNoPri () { IO (Decode16, 0x03E8, 0x03E8, 0x04, 0x08) IRQNoFlags () {3,4,10,11} } StartDependentFnNoPri () { IO (Decode16, 0x02E8, 0x02E8, 0x04, 0x08) IRQNoFlags () {3,4,10,11} } EndDependentFn () }) Name (C2PR, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x02F8, 0x02F8, 0x04, 0x08) IRQNoFlags () {3} } StartDependentFnNoPri () { IO (Decode16, 0x02F8, 0x02F8, 0x04, 0x08) IRQNoFlags () {3,4,10,11} } StartDependentFnNoPri () { IO (Decode16, 0x03F8, 0x03F8, 0x04, 0x08) IRQNoFlags () {3,4,10,11} } StartDependentFnNoPri () { IO (Decode16, 0x03E8, 0x03E8, 0x04, 0x08) IRQNoFlags () {3,4,10,11} } StartDependentFnNoPri () { IO (Decode16, 0x02E8, 0x02E8, 0x04, 0x08) IRQNoFlags () {3,4,10,11} } EndDependentFn () }) Name (LPPR, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IRQNoFlags () {7} } StartDependentFnNoPri () { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IRQNoFlags () {5,7} } StartDependentFnNoPri () { IO (Decode16, 0x0278, 0x0278, 0x01, 0x08) IRQNoFlags () {5,7} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, 0x03BC, 0x01, 0x04) IRQNoFlags () {5,7} } EndDependentFn () }) Name (EPRS, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IO (Decode16, 0x0778, 0x0778, 0x01, 0x04) IRQNoFlags () {7} DMA (Compatibility, NotBusMaster, Transfer8) {1} } StartDependentFnNoPri () { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IO (Decode16, 0x0778, 0x0778, 0x01, 0x04) IRQNoFlags () {5,7} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,3= } } StartDependentFnNoPri () { IO (Decode16, 0x0278, 0x0278, 0x01, 0x08) IO (Decode16, 0x0678, 0x0678, 0x01, 0x04) IRQNoFlags () {5,7} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,3= } } StartDependentFnNoPri () { IO (Decode16, 0x03BC, 0x03BC, 0x01, 0x04) IO (Decode16, 0x07BC, 0x07BC, 0x01, 0x04) IRQNoFlags () {5,7} DMA (Compatibility, NotBusMaster, Transfer8) {0,1,3= } } StartDependentFnNoPri () { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IO (Decode16, 0x0778, 0x0778, 0x01, 0x04) IRQNoFlags () {5,7} DMA (Compatibility, NotBusMaster, Transfer8) {} } StartDependentFnNoPri () { IO (Decode16, 0x0278, 0x0278, 0x01, 0x08) IO (Decode16, 0x0678, 0x0678, 0x01, 0x04) IRQNoFlags () {5,7} DMA (Compatibility, NotBusMaster, Transfer8) {} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, 0x03BC, 0x01, 0x04) IO (Decode16, 0x07BC, 0x07BC, 0x01, 0x04) IRQNoFlags () {5,7} DMA (Compatibility, NotBusMaster, Transfer8) {} } EndDependentFn () }) } Device (ICH) { Name (_ADR, 0x001E0000) Name (_PRT, Package (0x19) { Package (0x04) { 0xFFFF,=20 0x00,=20 \_SB.LNKC,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x01,=20 \_SB.LNKF,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x02,=20 \_SB.LNKG,=20 0x00 },=20 Package (0x04) { 0xFFFF,=20 0x03,=20 \_SB.LNKA,=20 0x00 },=20 Package (0x04) { 0x0001FFFF,=20 0x00,=20 \_SB.LNKF,=20 0x00 },=20 Package (0x04) { 0x0001FFFF,=20 0x01,=20 \_SB.LNKG,=20 0x00 },=20 Package (0x04) { 0x0001FFFF,=20 0x02,=20 \_SB.LNKA,=20 0x00 },=20 Package (0x04) { 0x0001FFFF,=20 0x03,=20 \_SB.LNKC,=20 0x00 },=20 Package (0x04) { 0x0002FFFF,=20 0x00,=20 \_SB.LNKG,=20 0x00 },=20 Package (0x04) { 0x0002FFFF,=20 0x01,=20 \_SB.LNKA,=20 0x00 },=20 Package (0x04) { 0x0002FFFF,=20 0x02,=20 \_SB.LNKC,=20 0x00 },=20 Package (0x04) { 0x0002FFFF,=20 0x03,=20 \_SB.LNKF,=20 0x00 },=20 Package (0x04) { 0x0003FFFF,=20 0x00,=20 \_SB.LNKA,=20 0x00 },=20 Package (0x04) { 0x0003FFFF,=20 0x01,=20 \_SB.LNKC,=20 0x00 },=20 Package (0x04) { 0x0003FFFF,=20 0x02,=20 \_SB.LNKF,=20 0x00 },=20 Package (0x04) { 0x0003FFFF,=20 0x03,=20 \_SB.LNKG,=20 0x00 },=20 Package (0x04) { 0x0004FFFF,=20 0x00,=20 \_SB.LNKC,=20 0x00 },=20 Package (0x04) { 0x0004FFFF,=20 0x01,=20 \_SB.LNKF,=20 0x00 },=20 Package (0x04) { 0x0004FFFF,=20 0x02,=20 \_SB.LNKG,=20 0x00 },=20 Package (0x04) { 0x0004FFFF,=20 0x03,=20 \_SB.LNKA,=20 0x00 },=20 Package (0x04) { 0x0005FFFF,=20 0x00,=20 \_SB.LNKF,=20 0x00 },=20 Package (0x04) { 0x0005FFFF,=20 0x01,=20 \_SB.LNKG,=20 0x00 },=20 Package (0x04) { 0x0005FFFF,=20 0x02,=20 \_SB.LNKA,=20 0x00 },=20 Package (0x04) { 0x0005FFFF,=20 0x03,=20 \_SB.LNKC,=20 0x00 },=20 Package (0x04) { 0x0008FFFF,=20 0x00,=20 \_SB.LNKE,=20 0x00 } }) Name (_PRW, Package (0x02) { 0x0B,=20 0x04 }) Scope (\_GPE) { Method (_L0B, 0, NotSerialized) { Notify (\_SB.PCI0.ICH, 0x02) } } } Device (IDE0) { Name (_ADR, 0x001F0001) Name (TIM0, Package (0x08) { Package (0x04) { 0x78,=20 0xB4,=20 0xF0,=20 0x0384 },=20 Package (0x04) { 0x23,=20 0x21,=20 0x10,=20 0x00 },=20 Package (0x04) { 0x0B,=20 0x09,=20 0x04,=20 0x00 },=20 Package (0x06) { 0x70,=20 0x49,=20 0x36,=20 0x27,=20 0x19,=20 0x11 },=20 Package (0x06) { 0x00,=20 0x01,=20 0x02,=20 0x01,=20 0x02,=20 0x01 },=20 Package (0x06) { 0x00,=20 0x00,=20 0x00,=20 0x01,=20 0x01,=20 0x01 },=20 Package (0x04) { 0x04,=20 0x03,=20 0x02,=20 0x00 },=20 Package (0x04) { 0x02,=20 0x01,=20 0x00,=20 0x00 } }) Name (TMD0, Buffer (0x14) {}) CreateDWordField (TMD0, 0x00, PIO0) CreateDWordField (TMD0, 0x04, DMA0) CreateDWordField (TMD0, 0x08, PIO1) CreateDWordField (TMD0, 0x0C, DMA1) CreateDWordField (TMD0, 0x10, CHNF) OperationRegion (CFG2, PCI_Config, 0x40, 0x20) Field (CFG2, DWordAcc, NoLock, Preserve) { TIMP, 16,=20 TIMS, 16,=20 STMP, 4,=20 STMS, 4,=20 Offset (0x08),=20 UDMP, 2,=20 UDMS, 2,=20 Offset (0x0A),=20 UDTP, 6,=20 Offset (0x0B),=20 UDTS, 6,=20 Offset (0x14),=20 PCB0, 2,=20 SCB0, 2,=20 PCA0, 2,=20 SCA0, 2,=20 , 4,=20 FPCB, 2,=20 FSCB, 2 } Method (GTM, 6, Serialized) { Store (Ones, PIO0) Store (Ones, PIO1) Store (Ones, DMA0) Store (Ones, DMA1) Store (Zero, CHNF) If (And (Arg0, 0x02)) { Or (CHNF, 0x02, CHNF) } ShiftRight (And (Arg0, 0x3300), 0x08, Local5) Store (Match (DerefOf (Index (TIM0, 0x01)), MLE, Local5= , MTR, 0x00, 0x00), Local6) Store (DerefOf (Index (DerefOf (Index (TIM0, 0x00)), Lo= cal6)), Local7) Store (Local7, DMA0) If (And (Arg0, 0x08)) { Store (0x0384, PIO0) } Else { Store (Local7, PIO0) } If (And (Arg0, 0x20)) { Or (CHNF, 0x08, CHNF) } If (And (Arg0, 0x4000)) { Or (CHNF, 0x10, CHNF) Store (Match (DerefOf (Index (TIM0, 0x02)), MLE, Ar= g1, MTR, 0x00, 0x00), Local5) Store (DerefOf (Index (DerefOf (Index (TIM0, 0x00))= , Local5)), Local6) Store (Local6, DMA1) If (And (Arg0, 0x80)) { Store (0x0384, PIO1) } Else { Store (Local6, PIO1) } } If (And (Arg2, 0x01)) { And (Arg3, 0x03, Local5) If (And (Arg5, 0x01)) { Add (Local5, 0x04, Local5) } Else { If (And (Arg4, 0x01)) { Add (Local5, 0x02, Local5) } } Store (DerefOf (Index (DerefOf (Index (TIM0, 0x03))= , Local5)), DMA0) Or (CHNF, 0x01, CHNF) } If (And (Arg2, 0x02)) { And (ShiftRight (Arg3, 0x04), 0x03, Local5) If (And (Arg5, 0x02)) { Add (Local5, 0x04, Local5) } Else { If (And (Arg4, 0x02)) { Add (Local5, 0x02, Local5) } } Store (DerefOf (Index (DerefOf (Index (TIM0, 0x03))= , Local5)), DMA1) Or (CHNF, 0x04, CHNF) } Return (TMD0) } Method (STM, 7, Serialized) { Store (Arg0, TMD0) Store (Arg5, Local1) And (Arg1, 0x8044, Arg1) And (Arg3, 0xFC, Arg3) And (Arg4, 0xCC, Arg4) And (Arg5, 0xFC, Arg5) And (Arg6, 0xFC, Arg6) If (And (CHNF, 0x01)) { Store (Match (DerefOf (Index (TIM0, 0x03)), MLE, DM= A0, MTR, 0x00, 0x00), Local0) If (LGreater (Local0, 0x05)) { Store (0x05, Local0) } If (LGreater (Local0, 0x02)) { If (And (Local1, 0x01)) { Store (0x02, Local0) } } Or (Arg4, DerefOf (Index (DerefOf (Index (TIM0, 0x0= 4)), Local0)), Arg4) Or (Arg5, DerefOf (Index (DerefOf (Index (TIM0, 0x0= 5)), Local0)), Arg5) Or (Arg3, 0x01, Arg3) If (LEqual (Local0, 0x05)) { Or (Arg6, 0x01, Arg6) } } Else { If (Or (LEqual (PIO0, Ones), LEqual (PIO0, 0x00))) { If (And (LLess (DMA0, Ones), LGreater (DMA0, 0x= 00))) { Store (DMA0, PIO0) Or (Arg1, 0x08, Arg1) } } } If (And (CHNF, 0x04)) { Store (Match (DerefOf (Index (TIM0, 0x03)), MLE, DM= A1, MTR, 0x00, 0x00), Local0) If (LGreater (Local0, 0x05)) { Store (0x05, Local0) } If (LGreater (Local0, 0x02)) { If (And (Local1, 0x02)) { Store (0x02, Local0) } } Or (Arg4, ShiftLeft (DerefOf (Index (DerefOf (Index= (TIM0, 0x04)), Local0)), 0x04), Arg4) Or (Arg5, DerefOf (Index (DerefOf (Index (TIM0, 0x0= 5)), Local0)), Arg5) Or (Arg3, 0x02, Arg3) If (LEqual (Local0, 0x05)) { Or (Arg6, 0x02, Arg6) } } Else { If (Or (LEqual (PIO1, Ones), LEqual (PIO1, 0x00))) { If (And (LLess (DMA1, Ones), LGreater (DMA1, 0x= 00))) { Store (DMA1, PIO1) Or (Arg1, 0x80, Arg1) } } } If (And (CHNF, 0x02)) { Or (Arg1, 0x03, Arg1) } If (And (CHNF, 0x08)) { Or (Arg1, 0x30, Arg1) } And (Match (DerefOf (Index (TIM0, 0x00)), MGE, PIO0, MT= R, 0x00, 0x00), 0x03, Local0) Store (DerefOf (Index (DerefOf (Index (TIM0, 0x01)), Lo= cal0)), Local1) ShiftLeft (Local1, 0x08, Local2) Or (Arg1, Local2, Arg1) If (And (CHNF, 0x10)) { Or (Arg1, 0x4000, Arg1) And (Match (DerefOf (Index (TIM0, 0x00)), MGE, PIO1= , MTR, 0x00, 0x00), 0x03, Local0) Store (DerefOf (Index (DerefOf (Index (TIM0, 0x02))= , Local0)), Local1) Or (Arg2, Local1, Arg2) } } Name (AT01, Buffer (0x07) { 0x03, 0x08, 0x00, 0x00, 0x00, 0x00, 0xEF }) Name (AT02, Buffer (0x07) { 0x03, 0x40, 0x00, 0x00, 0x00, 0x00, 0xEF }) Name (AT03, Buffer (0x07) { 0x03, 0x20, 0x00, 0x00, 0x00, 0x00, 0xEF }) Name (AT05, Buffer (0x07) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC6 }) Name (AT06, Buffer (0x07) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x91 }) Name (ATA0, Buffer (0x24) {}) Name (ATA1, Buffer (0x24) {}) Name (ATA2, Buffer (0x24) {}) Name (ATA3, Buffer (0x24) {}) Name (GTIM, 0x00) Name (GSTM, 0x00) Name (GUDM, 0x00) Name (GUDT, 0x00) Name (GCB0, 0x00) Name (GFCB, 0x00) Method (GTF, 3, Serialized) { Name (ATAD, Buffer (0x07) { 0x00 }) Name (ATAB, Buffer (0x24) { 0x01 }) Store (SizeOf (Arg1), Local0) If (Local0) { CreateWordField (Arg1, 0x00, ID00) If (Or (LEqual (ID00, 0x00), LLess (Local0, 0x78))) { Return (ATAB) } } Else { Return (ATAB) } Store (Arg2, TMD0) CreateByteField (Arg1, 0x06, ID03) CreateByteField (Arg1, 0x0C, ID06) CreateWordField (Arg1, 0x62, ID49) CreateWordField (Arg1, 0x6A, ID53) CreateWordField (Arg1, 0x76, ID59) CreateByteField (ATAD, 0x01, A001) CreateByteField (ATAD, 0x05, A005) CreateByteField (ATAB, 0x00, CMD0) Store (0xA0, Local7) If (Arg0) { Store (0xB0, Local7) } Store (0x00, CMD0) Store (0x00, Local1) CreateField (ATAB, 0x08, 0x38, CMD1) If (And (ID00, 0x80)) {} Else { Store (AT06, ATAD) Store (ID06, A001) Store (Local7, A005) Store (ID03, Local0) If (LGreater (ID03, 0x0F)) { Store (0x0F, Local0) } Or (A005, Local0, A005) Store (ATAD, CMD1) Store (0x01, CMD0) } Store (0x00, Local0) If (Arg0) { If (And (CHNF, 0x04)) { Store (DMA1, Local0) } } Else { If (And (CHNF, 0x01)) { Store (DMA0, Local0) } } If (Local0) { Store (Match (DerefOf (Index (TIM0, 0x03)), MLE, Lo= cal0, MTR, 0x00, 0x00), Local0) Multiply (CMD0, 0x38, Local5) Add (Local5, 0x08, Local6) CreateField (ATAB, Local6, 0x38, CMD2) Store (AT02, ATAD) Or (A001, Local0, A001) Store (Local7, A005) Store (ATAD, CMD2) Store (0x01, Local1) Increment (CMD0) } Store (0x00, Local0) If (Arg0) { If (And (CHNF, 0x08)) { Store (PIO1, Local0) } } Else { If (And (CHNF, 0x02)) { Store (PIO0, Local0) } } If (Local0) { Multiply (CMD0, 0x38, Local5) Add (Local5, 0x08, Local6) CreateField (ATAB, Local6, 0x38, CMD3) Store (AT01, ATAD) And (Match (DerefOf (Index (TIM0, 0x00)), MGE, Loca= l0, MTR, 0x00, 0x00), 0x03, Local0) Or (A001, DerefOf (Index (DerefOf (Index (TIM0, 0x0= 4)), Local0)), A001) Store (Local7, A005) Store (ATAD, CMD3) Increment (CMD0) } If (LNot (Local1)) { Multiply (CMD0, 0x38, Local5) Add (Local5, 0x08, Local6) CreateField (ATAB, Local6, 0x38, CMD4) If (And (ID49, 0x0200)) { CreateWordField (Arg1, 0x7E, ID63) FindSetLeftBit (And (ID63, 0x0F, ID63), Local0) If (Local0) { Store (AT03, ATAD) Or (A001, Decrement (Local0), A001) Store (Local7, A005) Store (ATAD, CMD4) Increment (CMD0) } } } If (And (ID59, 0x0100)) { Multiply (CMD0, 0x38, Local5) Add (Local5, 0x08, Local6) CreateField (ATAB, Local6, 0x38, CMD5) Store (AT05, ATAD) And (ID59, 0xFF, A001) Store (Local7, A005) Store (ATAD, CMD5) Increment (CMD0) } Return (ATAB) } Method (GTFD, 1, NotSerialized) { CreateByteField (Arg0, 0x00, CMD0) Multiply (CMD0, 0x07, Local0) Multiply (Local0, 0x08, Local1) Name (GTFB, Buffer (Local0) {}) CreateField (GTFB, 0x00, Local1, DST0) CreateField (Arg0, 0x08, Local1, SRC0) Store (SRC0, DST0) Return (GTFB) } Device (CHN0) { Name (_ADR, 0x00) Method (_GTM, 0, NotSerialized) { Return (GTM (TIMP, STMP, UDMP, UDTP, PCB0, FPCB)) } Method (_STM, 3, NotSerialized) { Store (TIMP, GTIM) Store (STMP, GSTM) Store (UDMP, GUDM) Store (UDTP, GUDT) Store (PCB0, GCB0) Store (FPCB, GFCB) STM (Arg0, GTIM, GSTM, GUDM, GUDT, GCB0, GFCB) Store (GTIM, TIMP) Store (GSTM, STMP) Store (GUDM, UDMP) Store (GUDT, UDTP) Store (GCB0, PCB0) Store (GFCB, FPCB) Store (GTF (0x00, Arg1, Arg0), ATA0) Store (GTF (0x01, Arg2, Arg0), ATA1) } Device (DRV0) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Return (GTFD (ATA0)) } } Device (DRV1) { Name (_ADR, 0x01) Method (_GTF, 0, NotSerialized) { Return (GTFD (ATA1)) } } } Device (CHN1) { Name (_ADR, 0x01) Method (_GTM, 0, NotSerialized) { Return (GTM (TIMS, STMS, UDMS, UDTS, SCB0, FSCB)) } Method (_STM, 3, NotSerialized) { Store (TIMS, GTIM) Store (STMS, GSTM) Store (UDMS, GUDM) Store (UDTS, GUDT) Store (SCB0, GCB0) Store (FSCB, GFCB) STM (Arg0, GTIM, GSTM, GUDM, GUDT, GCB0, GFCB) Store (GTIM, TIMS) Store (GSTM, STMS) Store (GUDM, UDMS) Store (GUDT, UDTS) Store (GCB0, SCB0) Store (GFCB, FSCB) Store (GTF (0x00, Arg1, Arg0), ATA2) Store (GTF (0x01, Arg2, Arg0), ATA3) } Device (DRV0) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Return (GTFD (ATA2)) } } Device (DRV1) { Name (_ADR, 0x01) Method (_GTF, 0, NotSerialized) { Return (GTFD (ATA3)) } } } } Device (USB) { Name (_ADR, 0x001F0002) Name (SS3D, 0x02) Name (_PRW, Package (0x02) { 0x03,=20 0x04 }) Scope (\_GPE) { Method (_L03, 0, NotSerialized) { Notify (\_SB.PCI0.USB, 0x02) } } } Device (USB2) { Name (_ADR, 0x001F0004) Name (SS3D, 0x02) Name (_PRW, Package (0x02) { 0x04,=20 0x04 }) Scope (\_GPE) { Method (_L04, 0, NotSerialized) { Notify (\_SB.PCI0.USB2, 0x02) } } } Device (MM97) { Name (_ADR, 0x001F0006) Name (_PRW, Package (0x02) { 0x05,=20 0x04 }) Scope (\_GPE) { Method (_L05, 0, NotSerialized) { Notify (\_SB.PCI0, 0x02) } } } } Name (SLPS, 0x00) Device (SLPB) { Name (_HID, EisaId ("PNP0C0E")) Method (SBEV, 0, NotSerialized) { If (SLPS) { Store (0x00, SLPS) Notify (SLPB, 0x02) } Else { Store (0x01, SLPS) Notify (SLPB, 0x80) } } Scope (\_GPE) { Method (_L16, 0, NotSerialized) { \_SB.SLPB.SBEV () } } } } OperationRegion (FNOR, SystemIO, 0x0434, 0x04) Scope (_SI) { Method (_SST, 1, NotSerialized) { If (Arg0) { If (LEqual (Arg0, 0x01)) { \_SB.PCI0.SBRG.ENFG () Store (0x08, \_SB.PCI0.SBRG.LDN) Store (0x00, \_SB.PCI0.SBRG.OPT6) Store (0x09, \_SB.PCI0.SBRG.LDN) Store (0x00, \_SB.PCI0.SBRG.OPT4) \_SB.PCI0.SBRG.EXFG () } If (LEqual (Arg0, 0x02)) { \_SB.PCI0.SBRG.ENFG () Store (0x08, \_SB.PCI0.SBRG.LDN) Store (0x00, \_SB.PCI0.SBRG.OPT6) Store (0x09, \_SB.PCI0.SBRG.LDN) Store (0x00, \_SB.PCI0.SBRG.OPT4) \_SB.PCI0.SBRG.EXFG () } If (LEqual (Arg0, 0x03)) { \_SB.PCI0.SBRG.ENFG () Store (0x08, \_SB.PCI0.SBRG.LDN) Store (0x80, \_SB.PCI0.SBRG.OPT6) Store (0x09, \_SB.PCI0.SBRG.LDN) Store (0x40, \_SB.PCI0.SBRG.OPT4) \_SB.PCI0.SBRG.EXFG () } If (LEqual (Arg0, 0x04)) { \_SB.PCI0.SBRG.ENFG () Store (0x08, \_SB.PCI0.SBRG.LDN) Store (0xC0, \_SB.PCI0.SBRG.OPT6) Store (0x09, \_SB.PCI0.SBRG.LDN) Store (0x40, \_SB.PCI0.SBRG.OPT4) \_SB.PCI0.SBRG.EXFG () } } Else { \_SB.PCI0.SBRG.ENFG () Store (0x08, \_SB.PCI0.SBRG.LDN) Store (0x40, \_SB.PCI0.SBRG.OPT6) Store (0x09, \_SB.PCI0.SBRG.LDN) Store (0x00, \_SB.PCI0.SBRG.OPT4) \_SB.PCI0.SBRG.EXFG () } } } OperationRegion (HWMI, SystemIO, 0x0295, 0x02) Field (HWMI, ByteAcc, NoLock, Preserve) { HWMD, 8,=20 HWMT, 8 } IndexField (HWMD, HWMT, ByteAcc, NoLock, Preserve) { Offset (0x57),=20 BECL, 8,=20 Offset (0x5A),=20 FNW1, 8,=20 FNW2, 8 } OperationRegion (ACIO, SystemIO, 0xB2, 0x01) Field (ACIO, ByteAcc, NoLock, Preserve) { ACFG, 8 } OperationRegion (PMIO, SystemIO, 0x0400, 0x50) Field (PMIO, WordAcc, NoLock, Preserve) { PMS0, 8,=20 PWST, 1,=20 , 1,=20 RTCS, 1,=20 PMS1, 5,=20 Offset (0x03),=20 PWEN, 1,=20 Offset (0x28),=20 GP0S, 16,=20 GP0E, 16,=20 GP1S, 16,=20 GP1E, 16,=20 Offset (0x40),=20 IOMO, 16 } OperationRegion (GPIO, SystemIO, 0x0480, 0x20) Field (GPIO, WordAcc, NoLock, Preserve) { Offset (0x0E),=20 GPO1, 8,=20 GPO2, 8 } OperationRegion (IR21, SystemIO, 0x21, 0x01) Field (IR21, ByteAcc, NoLock, Preserve) { IQ21, 8 } OperationRegion (KDAT, SystemIO, 0x60, 0x05) Field (KDAT, ByteAcc, NoLock, Preserve) { KBDT, 8,=20 Offset (0x04),=20 KBID, 1,=20 Offset (0x05) } Method (_PTS, 1, NotSerialized) { Store (Arg0, DBG8) Store (Arg0, ACST) Store (0xFFFF, GP0S) Store (0xFFFF, GP1S) And (BECL, 0x7F, BECL) If (LNot (LEqual (Arg0, 0x05))) { Store (0x00, FNW1) Store (0x00, FNW2) } \_SB.PCI0.SBRG.ENFG () Store (0x0A, \_SB.PCI0.SBRG.LDN) If (LNot (LEqual (Arg0, 0x05))) { While (\_SB.PCI0.SBRG.OPT4) { Stall (0x50) Store (0xFF, \_SB.PCI0.SBRG.OPT4) } } If (LEqual (Arg0, 0x01)) { Store (0x33, \_SB.PCI0.SBRG.OPT7) } \_SB.PCI0.SBRG.EXFG () If (LEqual (ACFG, 0x1E)) { Store (0x3000, IOMO) } Else { If (LEqual (Arg0, 0x01)) { Store (0x3100, IOMO) } If (LEqual (Arg0, 0x03)) { Store (0x3100, IOMO) } If (LEqual (Arg0, 0x05)) { Store (0x3100, IOMO) } } } Method (_WAK, 1, NotSerialized) { ShiftLeft (Arg0, 0x04, DBG8) If (LEqual (Arg0, 0x01)) { Sleep (0x0BB8) } Store (0x3000, IOMO) If (LEqual (RTCS, 0x00)) { Notify (\_SB.SLPB, 0x02) } Store (0xFF, FNW1) Store (0xFF, FNW2) \_SB.PCI0.SBRG.ENFG () Store (0x0A, \_SB.PCI0.SBRG.LDN) Store (0x00, \_SB.PCI0.SBRG.OPT7) \_SB.PCI0.SBRG.EXFG () Or (BECL, 0x80, BECL) Store (0xFFFF, GP0S) Store (0xFFFF, GP1S) Store (0x01, PWEN) } OperationRegion (TEMP, SystemIO, 0x80, 0x01) Field (TEMP, ByteAcc, NoLock, Preserve) { DBG8, 8 } } ------=_Part_176_2344176.1092285885887 Content-Type: application/octet-stream; name="foo.dsdt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="foo.dsdt" RFNEVAcxAAABWUlOVEVMAFdISVRORVkAABAAAE1TRlQNAAABEBNcX1BSX1uDC0NQVTEBEAQAAAZb gENNNzIBCnIKAluBEENNNzIBQ0k3MghDTzczCFuGNUNJNzJDTzczAQBIalVMRUQIACBVQVNCAVVT QkUBRkxPUwIADAADAAFBQ1NUAwAJTE5SSQgIXF9TMF8SCgQKAAoACgAKAAhcX1MxXxIKBAoBCgAK AAoACFxfUzRfEgoECgYKAAoACgAIXF9TNV8SCgQKBwoACgAKABRBBU1DVEgCoAmVh2iHaaQKAHKH aAoBYAhCVUYwEQJgCEJVRjERAmBwaEJVRjBwaUJVRjGiG2B2YKASk4OIQlVGMGAAg4hCVUYxYACh A6QApAEQjaQCXF9TQl8IQVBJQwoAFAxfUElDAXBoQVBJQ1uCGVBXUkIIX0hJRAxB0AwMFAlfU1RB AKQKC1uCg5sCUENJMAhfSElEDEHQCgMIX1VJRAoBCF9BRFIKAAhfQkJOCgAIU1MzRAoCCENSU18R TAgKiIgNAAIMAAAAAAD/AAAAAAFHAfgM+AwBCIgNAAEMAwAAAAD3DAAA+AyIDQABDAMAAAAN//8A AADzhxcAAAwDAAAAAAAACgD//wsAAAAAAAAAAgCHFwAADAMAAAAAALAMAP//DQAAAAAAAFABAIcX AAAMAwAAAAAAAAAg///f/wAAAAAAAODfeQBbgFRNRU0CCn4KAluBC1RNRU0CTUVNVAsIVE9NXwoA FCtNREVUAKAfklRPTV+gEEZMQUd5TUVNVAoYVE9NX6EHpAwAAAAgpFRPTV8IRkxBRwoBCE9TRkwK AhRGCF9JTkkAXC8EX1NCX1BDSTBTQlJHSU9EVKAkTUNUSFxfT1NfDU1pY3Jvc29mdCBXaW5kb3dz AHAKAk9TRkyhRgSgOk1DVEhcX09TXw1NaWNyb3NvZnQgV2luZG93c01FOiBNaWxsZW5uaXVtIEVk aXRpb24AcAoDT1NGTKEIcAoBT1NGTBQSX1JFRwKgC5NoCgJwaUZMQUcUOF9DUlMAikNSU18KdlRN RU2KQ1JTXwqCVExFTnBNREVUVE1FTXQMAADg/1RNRU1UTEVOpENSU18IX1BSVBJLBwYSFQQM//8f AAoAXC5fU0JfTE5LQQoAEhUEDP//HwAKAVwuX1NCX0xOS0IKABIVBAz//x8ACgJcLl9TQl9MTktI CgASFQQM//8fAAoDXC5fU0JfTE5LRAoAEg8EDP//AQAKAExOS0EKABIPBAz//wEACgFMTktCCgBb goWZAVNCUkcIX0FEUgwAAB8ACFwuX1NCX0lQUlMRCwoIMCP43hg4eQBbgFBJWDACCmAKBFuAUElY MQIKaAoEW4BMUEMwAgrgCghbgExQQzECCuwKAhBJV1xfU0JfW4EpXC8EX1NCX1BDSTBTQlJHUElY MAFQSVJBCFBJUkIIUElSQwhQSVJECFuBKVwvBF9TQl9QQ0kwU0JSR1BJWDEBUElSRQhQSVJGCFBJ UkcIUElSSAhbgUQJXC8EX1NCX1BDSTBTQlJHTFBDMAFMUENBAwABTFBDQgMAAUxQTFACAAJMUEZE AQADTFBTQgIAAUxQTUQBTFBNUwIAAgAIR0VOMRBDQUVOAUNCRU4BTFBFTgFGREVOAVNCRU4BTURF TgFNU0VOAUFERU4BR01MRQFHTUhFAUtCRU4BTUNFTgFDRjFFAUNGMkUBAAJbgRpcLwRfU0JfUENJ MFNCUkdMUEMxAUdFTjIQCEJVRkERCQoGIwCAGHkAi0JVRkEKAUlSQTBbgkgITE5LQQhfSElEDEHQ DA8IX1VJRAoBFBlfU1RBAHtQSVJBCoBgoAVgpAoJoQSkCgsUC19QUlMApElQUlMUEV9ESVMAfVBJ UkEKgFBJUkEUG19DUlMAe1BJUkEKD2B5CgFgSVJBMKRCVUZBFBxfU1JTAYtoCgFJUkFfgklSQV9g dmBwYFBJUkFbgkgITE5LQghfSElEDEHQDA8IX1VJRAoCFBlfU1RBAHtQSVJCCoBgoAVgpAoJoQSk CgsUC19QUlMApElQUlMUEV9ESVMAfVBJUkIKgFBJUkIUG19DUlMAe1BJUkIKD2B5CgFgSVJBMKRC VUZBFBxfU1JTAYtoCgFJUkFfgklSQV9gdmBwYFBJUkJbgkgITE5LQwhfSElEDEHQDA8IX1VJRAoD FBlfU1RBAHtQSVJDCoBgoAVgpAoJoQSkCgsUC19QUlMApElQUlMUEV9ESVMAfVBJUkMKgFBJUkMU G19DUlMAe1BJUkMKD2B5CgFgSVJBMKRCVUZBFBxfU1JTAYtoCgFJUkFfgklSQV9gdmBwYFBJUkNb gkgITE5LRAhfSElEDEHQDA8IX1VJRAoEFBlfU1RBAHtQSVJECoBgoAVgpAoJoQSkCgsUC19QUlMA pElQUlMUEV9ESVMAfVBJUkQKgFBJUkQUG19DUlMAe1BJUkQKD2B5CgFgSVJBMKRCVUZBFBxfU1JT AYtoCgFJUkFfgklSQV9gdmBwYFBJUkRbgkgITE5LRQhfSElEDEHQDA8IX1VJRAoFFBlfU1RBAHtQ SVJFCoBgoAVgpAoJoQSkCgsUC19QUlMApElQUlMUEV9ESVMAfVBJUkUKgFBJUkUUG19DUlMAe1BJ UkUKD2B5CgFgSVJBMKRCVUZBFBxfU1JTAYtoCgFJUkFfgklSQV9gdmBwYFBJUkVbgkgITE5LRghf SElEDEHQDA8IX1VJRAoGFBlfU1RBAHtQSVJGCoBgoAVgpAoJoQSkCgsUC19QUlMApElQUlMUEV9E SVMAfVBJUkYKgFBJUkYUG19DUlMAe1BJUkYKD2B5CgFgSVJBMKRCVUZBFBxfU1JTAYtoCgFJUkFf gklSQV9gdmBwYFBJUkZbgkgITE5LRwhfSElEDEHQDA8IX1VJRAoHFBlfU1RBAHtQSVJHCoBgoAVg pAoJoQSkCgsUC19QUlMApElQUlMUEV9ESVMAfVBJUkcKgFBJUkcUG19DUlMAe1BJUkcKD2B5CgFg SVJBMKRCVUZBFBxfU1JTAYtoCgFJUkFfgklSQV9gdmBwYFBJUkdbgkgITE5LSAhfSElEDEHQDA8I X1VJRAoIFBlfU1RBAHtQSVJICoBgoAVgpAoJoQSkCgsUC19QUlMApElQUlMUEV9ESVMAfVBJUkgK gFBJUkgUG19DUlMAe1BJUkgKD2B5CgFgSVJBMKRCVUZBFBxfU1JTAYtoCgFJUkFfgklSQV9gdmBw YFBJUkhbgFNCRk4CCvIKAVuCSAlTWVNSCF9ISUQMQdAMAhQfX1NUQQBwT1NGTEZMT1OgDHtPU0ZM CgIApAoPpAoACElPUkcRRgUKUksQABBLIgAeS0QAHEtiAAJLZQALS3IADkuAAAFLhAADS4gAAUuM AANLkAAQS6IAHkvgABBLlQICRwHQBNAEAAJHAQAEAAQAgEcBgASABABAeQAUC19DUlMApElPUkdb giZGV0hfCF9ISUQMJdQIAAhfQ1JTEREKDoYJAAEAALj/AAAIAHkAW4JDClwuX1NCX01FTV8IX0hJ RAxB0AwBFCFfU1RBAKAXe1wvA19TQl9QQ0kwT1NGTAoCAKQKD6QKAAhNRU0xETUKMoYJAAEAAAAA AAAKAIYJAAAAAA4AAAACAIYJAAEAABAAAADwH4YJAAAAAPj/AAAIAHkAFC9fQ1JTAIpNRU0xCiBU T1AxdFwvA19TQl9QQ0kwTURFVAwAABAAVE9QMaRNRU0xW4IjUElDXwhfSElEC0HQCF9DUlMREAoN SyAAAkugAAIiBAB5AFuCNURNQUQIX0hJRAxB0AIACF9DUlMRIAodKhAESwAAEEuBAANLhwABS4kA A0uPAAFLwAAgeQBbgiFUTVJfCF9ISUQMQdABAAhfQ1JTEQwKCUtAAAQiAQB5AFuCIVJUQ18IX0hJ RAxB0AsACF9DUlMRDAoJS3AAAiIAAXkAW4IeU1BLUghfSElEDEHQCAAIX0NSUxEJCgZLYQABeQBb giFDT1BSCF9ISUQMQdAMBAhfQ1JTEQwKCUvwABAiACB5AFuAUFNSRwALEAQKAVuBDVBTUkcBAAJQ UzJFAVuCSQRQUzJNCF9ISUQMQdAPAwhfQ0lEDEHQDxMUFF9TVEEAoAhQUzJFpAoPoQSkCgAITUNS UxEICgUiABB5ABQLX0NSUwCkTUNSU1uCO1BTMksIX0hJRAxB0AMDCF9DSUQMQdADCwhLQ1JTERAK DUtgAAFLZAABIgIAeQAUC19DUlMApEtDUlMIU1BJTwouW4BXSU4xAVNQSU8KAluBEFdJTjEBSU5E WAhEQVRBCFuGQwtJTkRYREFUQQEAEENGR18IACBMRE5fCABAFEFDVFIBQUNUMQFBQ1QyAQAFAEgX SU9BSAhJT0FMCElPRUgISU9FTAgAQAZJTlRSCAAISU5UMQgACERNQ0gIAEglR1A0MAgASA9SR0Uw CFJHRTEIUkdFMghSR0UzCFJHRTQIAEgFT1BUMQhPUFQyCE9QVDMIT1BUNAhPUFQ1CE9QVDYIT1BU NwhPUFQ4CE9QVDkIT1BUQQhbgEhXTVQBC5UCCgJbgRBIV01UAUhXSU4ISFdEVAhbhksKSFdJTkhX RFQBAEAgSFc0MAhIVzQxCEhXNDIISFc0MwhIVzQ0CAAISFc0NghIVzQ3CEhXNDgISFc0OQhIVzRB CEhXNEIISFc0QwhIVzRECEhXNEUISFc0RghIVzUwCEhXNTEISFc1MghIVzUzCEhXNTQISFc1NQhI VzU2CEhXNTcISFc1OAhIVzU5CEhXNUEISFc1QghIVzVDCEhXNUQISFc1RQhIVzVGCBQURU5GRwBw CodJTkRYcAqHSU5EWBQNRVhGRwBwCqpJTkRYCExERkQKAAhMRFUxCgIITERVMgoDCExESVIKBghM RExQCgEITERHTQoHCExETUQKB1uCRQZGREMwCF9ISUQMQdAHABQWX1NUQQCgDEZEU1SkR1NUQQoA pAoAFBJfRElTAHAARkRFTkRESVMKABQLX0NSUwCkRkNSUxQLX1BSUwCkRlBSUxQSX1NSUwFwAUZE RU5ERU5CCgBbgkcLVUFSMQhfSElEDEHQBQEIX1VJRAoBFBZfU1RBAKAMVTFTVKRHU1RBCgKkCgAU El9ESVMAcABDQUVORERJUwoCFBFfQ1JTAKRQQ1JTCgIKAQoIFEcFX1NSUwFQU1JTaAoCcAFDQUVO RU5GR6Agk0lPQUgKA6AOk0lPQUwK+HAATFBDQaEIcAoHTFBDQaEZoA6TSU9BTAr4cAFMUENBoQhw CgVMUENBRVhGRxQLX1BSUwCkQzFQUluCTg1VQVIyFDBfSElEAEVORkdwTERVMkxETl97T1BUMgo4 YEVYRkegCGCkDEHQBRChB6QMQdAFAQhfVUlECgIUFl9TVEEAoAxVMlNUpEdTVEEKA6QKABQSX0RJ UwBwAENCRU5ERElTCgMUEV9DUlMApFBDUlMKAwoBCggURwVfU1JTAVBTUlNoCgNwAUNCRU5FTkZH oCCTSU9BSAoDoA6TSU9BTAr4cABMUENCoQhwCgdMUENCoRmgDpNJT0FMCvhwAUxQQ0KhCHAKBUxQ Q0JFWEZHFAtfUFJTAKRDMlBSW4JMEElSREEIX0hJRAxB0AUQFBhfU1RBAKAOSVJTVKRHU1RBTERJ UqQKABQOX0RJUwBERElTTERJUhRLCl9DUlMACEJVRjYREAoNRwEAAAAAEAgiAAB5AIxCVUY2CgJJ T0xPjEJVRjYKA0lPSEmMQlVGNgoESU9STIxCVUY2CgVJT1JIi0JVRjYKCUlSUU1FTkZHcExESVJM RE5foBNBQ1RScAqYSU9MT3AKAklPSEmhD3AKAElPTE9wCgBJT0hJcElPTE9JT1JMcElPSElJT1JI eQoBSU5UUklSUU1FWEZHpEJVRjYUD19TUlMBUFNSU2hMRElSCF9QUlMREgoPMEcBmAKYAggIIhgO OHkAW4JPC0xQVF8IX0hJRAxB0AQAFDdfU1RBAEVORkdwCgFMRE5fe09QVDEKAmBFWEZHoBB9YHuA TFBTVAAKAQAApAChCKRHU1RBCgEUEl9ESVMAcABMUEVORERJUwoBFBFfQ1JTAKRQQ1JTCgEKAQoI FEUEX1NSUwFQU1JTaAoBcAFMUEVORU5GR6Agk0lPQUgKA6AOk0lPQUwKeHAATFBMUKEIcAoCTFBM UKEHcAFMUExQRVhGRxQLX1BSUwCkTFBQUluCSQtFQ1BfCF9ISUQMQdAEARQ1X1NUQQBFTkZHcAoB TEROX3tPUFQxCgJgRVhGR6ATYKAMTFBTVKRHU1RBCgGhA6QAoQOkABQSX0RJUwBwAExQRU5ERElT CgEUDV9DUlMApEVDUlMKARRFBF9TUlMBRVNSU2gKAXABTFBFTkVORkegIJNJT0FICgOgDpNJT0FM CnhwAExQTFChCHAKAkxQTFChB3ABTFBMUEVYRkcUC19QUlMApEVQUlNbgk8YR0FNRQhfSElEDEHQ sC8URARfU1RBAEVORkdwTERHTUxETl+gEZFHTUxFR01IRUVYRkekCg+hHXJJT0FISU9BTGCgCWBF WEZHpAoNoQdFWEZHpAAUEl9ESVMAcABHTUxFcABHTUhFFEUJX0NSUwAIQlVGNhENCgpHAQAAAAAI CHkAjEJVRjYKAklPTE+MQlVGNgoDSU9ISYxCVUY2CgRJT1JMjEJVRjYKBUlPUkhFTkZHcExER01M RE5foBaTSU9BTAoAcAoASU9MT3AKAklPSEmhD3AKCElPTE9wCgJJT0hJcElPTE9JT1JMcElPSElJ T1JIRVhGR6RCVUY2CF9QUlMRGAoVMEcBAAIAAggIMEcBCAIIAggIOHkAFEIHX1NSUwGMaAoCSU9M T4xoCgNJT0hJRU5GR3BMREdNTEROX6AWk0lPTE8KAHAKAklPQUhwCgBJT0FMoQ9wCgJJT0FIcAoI SU9BTKAUk0lPQUwKAHABR01MRXAAR01IRaENcABHTUxFcAFHTUhFRVhGR1uCQCFNSURJCF9ISUQM QdCwBhRHBF9TVEEARU5GR3BMRE1ETEROX6AUkU1ERU6TSU9FSAoCRVhGR6QKD6EdcklPRUhJT0VM YKAJYEVYRkekCg2hB0VYRkekABQMX0RJUwBwAE1ERU4UQg1fQ1JTAAhCVUY2ERAKDUcBAAAAAAIC IgAAeQCMQlVGNgoCSU9MT4xCVUY2CgNJT0hJjEJVRjYKBElPUkyMQlVGNgoFSU9SSItCVUY2CglJ UlFNRU5GR3BMRE1ETEROX6Aok0lPRUgKA3AKA0lPSEmgD5NJT0VMCjBwCjBJT0xPoQhwCgBJT0xP oSFwCgJJT0hJoA+TSU9FTAqQcAqQSU9MT6EIcAqSSU9MT3BJT0xPSU9STHBJT0hJSU9SSHkKAUlO VFJJUlFNRVhGR6RCVUY2CF9QUlMRNgozMEcBMAMwAwICIqAGMEcBAAMAAwICIqAGMEcBkAKQAgIC IqAGMEcBkgKSAgICIqAGOHkAFEsJX1NSUwGMaAoCSU9MT4xoCgNJT0hJi2gKCUlSUU1FTkZHcExE TURMRE5foDqTSU9ISQoDcAoDSU9FSKAVk0lPTE8KMHAKMElPRUxwAExQTUShDnAKAElPRUxwAUxQ TURwAU1ERU6hIXAKAklPRUigD5NJT0xPCpBwCpBJT0VMoQhwCpJJT0VMgklSUU1gdGAKAUlOVFJF WEZHCEZEU1QKAAhVMVNUCgAIVTJTVAoACElSU1QKAAhMUFNUCgAUSwZJT0RUAKATk0dTVEFMREZE Cg9wCgFGRFNUoBOTR1NUQUxEVTEKD3AKAVUxU1SgE5NHU1RBTERVMgoPcAoBVTJTVKATk0dTVEFM RElSCg9wCgFJUlNUoBOTR1NUQUxETFAKD3AKAUxQU1QUOEdTVEEBRU5GR3BoTEROX6AJQUNUUnAK D2ChF6APfUlPQUhJT0FMAHAKDWChBXAKAGBFWEZHpGAUGkRESVMBRU5GR3BoTEROX3AAQUNUUkVY RkcUGkRFTkIBRU5GR3BoTEROX3ABQUNUUkVYRkcUTQpQQ1JTA4xQQlVGCgJJT0xPjFBCVUYKA0lP SEmLUEJVRgoCSU9ITItQQlVGCgRJT1JMjFBCVUYKBkFMTU6MUEJVRgoHTEVOR4xQQlVGCglJUlFM RU5GR3BoTEROX3BJT0FISU9ISXBJT0FMSU9MT3BJT0hMSU9STHBpQUxNTqAPk0lPTE8KvHAKBExF TkehB3BqTEVOR3ABYHlgSU5UUklSUUxFWEZHpFBCVUYUQwVQU1JTAoxoCgJQT0xCjGgKA1BPSEKM aAoJUElSUUVORkdwaUxETl9wUE9MQklPQUxwUE9IQklPQUiCUElSUWB0YAoBSU5UUnABQUNUUkVY RkcUSA9FQ1JTAYxFQlVGCgJFUExPjEVCVUYKA0VQSEmLRUJVRgoCRVBITItFQlVGCgRFUFJMi0VC VUYKBkFMTTGLRUJVRgoKRTRMT4tFQlVGCgxFNFJMi0VCVUYKEUVJUlGLRUJVRgoURURNQUVORkdw aExETl9wSU9BSEVQSElwSU9BTEVQTE9wRVBITEVQUkxyRVBITAsABEU0TE9wRTRMT0U0UkygEZNF UEhMC7wDcAsBBEFMTTGhCXALAQhBTE0xcAFgcElOVFJheWBhRUlSUXBETUNIYaAMlGEKA3AKAEVE TUGhC3ABYHlgYUVETUFFWEZHpEVCVUYUSAdFU1JTAoxoCgJMT0VQjGgKA0hJRVCLaAoRSVJRRYto ChRETUFFRU5GR3BpTEROX3BMT0VQSU9BTHBISUVQSU9BSIJJUlFFYHRgCgFJTlRSoBNETUFFgkRN QUVgdGAKAURNQ0ihCHAKBERNQ0hwAUFDVFJFWEZHCENOQkYRBQoC+AMUTQRVQUJTAUVORkdwaExE Tl+MQ05CRgoASU9MT4xDTkJGCgFJT0hJi0NOQkYKAElPQURwSU9BTElPTE9wSU9BSElPSElFWEZH pElPQUQIQ1NDUAoAW4QwVVJQMQEAABQLX1NUQQCkQ1NDUBQNX09OXwBwCgFDU0NQFA1fT0ZGAHAK AENTQ1BbhDBVUlAyAQAAFAtfU1RBAKRDU0NQFA1fT05fAHAKAUNTQ1AUDV9PRkYAcAoAQ1NDUFuE MEZERFAAAAAUC19TVEEApENTQ1AUDV9PTl8AcAoBQ1NDUBQNX09GRgBwCgBDU0NQW4QwTFBUUAAA ABQLX1NUQQCkQ1NDUBQNX09OXwBwCgFDU0NQFA1fT0ZGAHAKAENTQ1AIRkNSUxEjCiBHAfID8gMB AkcB9AP0AwECRwH3A/cDAQEiQAAqBAB5AAhQQlVGERAKDUcBAAAAAAEIIgEAeQAIRUJVRhEbChhH AXgDeAMBCEcBeAd4BwEEIoAAKgAAeQAIRlBSUxEmCiMxAEcB8gPyAwECRwH0A/QDAQJHAfcD9wMB ASJAACoEADh5AAhDMVBSEUQECkAxAEcB+AP4AwQIIhAAMEcB+AP4AwQIIhgMMEcB+AL4AgQIIhgM MEcB6APoAwQIIhgMMEcB6ALoAgQIIhgMOHkACEMyUFIRRAQKQDEARwH4AvgCBAgiCAAwRwH4AvgC BAgiGAwwRwH4A/gDBAgiGAwwRwHoA+gDBAgiGAwwRwHoAugCBAgiGAw4eQAITFBQUhE3CjQxAEcB eAN4AwEIIoAAMEcBeAN4AwEIIqAAMEcBeAJ4AgEIIqAAMEcBvAO8AwEEIqAAOHkACEVQUlMRSQoK pTEARwF4A3gDAQhHAXgHeAcBBCKAACoCADBHAXgDeAMBCEcBeAd4BwEEIqAAKgsAMEcBeAJ4AgEI RwF4BngGAQQioAAqCwAwRwG8A7wDAQRHAbwHvAcBBCKgACoLADBHAXgDeAMBCEcBeAd4BwEEIqAA KgAAMEcBeAJ4AgEIRwF4BngGAQQioAAqAAAwRwG8A7wDAQRHAbwHvAcBBCKgACoAADh5AFuCQyZJ Q0hfCF9BRFIMAAAeAAhfUFJUEkEiGRITBAv//woAXC5fU0JfTE5LQwoAEhMEC///CgFcLl9TQl9M TktGCgASEwQL//8KAlwuX1NCX0xOS0cKABITBAv//woDXC5fU0JfTE5LQQoAEhUEDP//AQAKAFwu X1NCX0xOS0YKABIVBAz//wEACgFcLl9TQl9MTktHCgASFQQM//8BAAoCXC5fU0JfTE5LQQoAEhUE DP//AQAKA1wuX1NCX0xOS0MKABIVBAz//wIACgBcLl9TQl9MTktHCgASFQQM//8CAAoBXC5fU0Jf TE5LQQoAEhUEDP//AgAKAlwuX1NCX0xOS0MKABIVBAz//wIACgNcLl9TQl9MTktGCgASFQQM//8D AAoAXC5fU0JfTE5LQQoAEhUEDP//AwAKAVwuX1NCX0xOS0MKABIVBAz//wMACgJcLl9TQl9MTktG CgASFQQM//8DAAoDXC5fU0JfTE5LRwoAEhUEDP//BAAKAFwuX1NCX0xOS0MKABIVBAz//wQACgFc Ll9TQl9MTktGCgASFQQM//8EAAoCXC5fU0JfTE5LRwoAEhUEDP//BAAKA1wuX1NCX0xOS0EKABIV BAz//wUACgBcLl9TQl9MTktGCgASFQQM//8FAAoBXC5fU0JfTE5LRwoAEhUEDP//BQAKAlwuX1NC X0xOS0EKABIVBAz//wUACgNcLl9TQl9MTktDCgASFQQM//8IAAoAXC5fU0JfTE5LRQoACF9QUlcS BgIKCwoEEB9cX0dQRRQYX0wwQgCGXC8DX1NCX1BDSTBJQ0hfCgJbgkeoSURFMAhfQURSDAEAHwAI VElNMBJIBggSCwQKeAq0CvALhAMSCgQKIwohChAKABIKBAoLCgkKBAoAEg4GCnAKSQo2CicKGQoR Eg4GCgAKAQoCCgEKAgoBEg4GCgAKAAoACgEKAQoBEgoECgQKAwoCCgASCgQKAgoBCgAKAAhUTUQw EQMKFIpUTUQwCgBQSU8wilRNRDAKBERNQTCKVE1EMAoIUElPMYpUTUQwCgxETUExilRNRDAKEENI TkZbgENGRzICCkAKIFuBSAVDRkcyA1RJTVAQVElNUxBTVE1QBFNUTVMEABhVRE1QAlVETVMCAAxV RFRQBgACVURUUwYAQgRQQ0IwAlNDQjACUENBMAJTQ0EwAgAERlBDQgJGU0NCAhRGF0dUTV8OcP9Q SU8wcP9QSU8xcP9ETUEwcP9ETUExcABDSE5GoBF7aAoCAH1DSE5GCgJDSE5GentoCwAzAAoIZXCJ g4hUSU0wCgEAAmUACgAKAGZwg4iDiFRJTTAKAABmAGdwZ0RNQTCgDntoCggAcAuEA1BJTzChB3Bn UElPMKARe2gKIAB9Q0hORgoIQ0hORqBCBXtoCwBAAH1DSE5GChBDSE5GcImDiFRJTTAKAgACaQAK AAoAZXCDiIOIVElNMAoAAGUAZnBmRE1BMaAOe2gKgABwC4QDUElPMaEHcGZQSU8xoEMEe2oKAQB7 awoDZaALe20KAQByZQoEZaENoAt7bAoBAHJlCgJlcIOIg4hUSU0wCgMAZQBETUEwfUNITkYKAUNI TkagRwR7agoCAHt6awoEAAoDZaALe20KAgByZQoEZaENoAt7bAoCAHJlCgJlcIOIg4hUSU0wCgMA ZQBETUExfUNITkYKBENITkakVE1EMBRDH1NUTV8PcGhUTUQwcG1he2kLRIBpe2sK/Gt7bArMbHtt Cvxte24K/G6gSwZ7Q0hORgoBAHCJg4hUSU0wCgMAAkRNQTAACgAKAGCgCZRgCgVwCgVgoBCUYAoC oAp7YQoBAHAKAmB9bIOIg4hUSU0wCgQAYABsfW2DiIOIVElNMAoFAGAAbX1rCgFroAqTYAoFfW4K AW6hMaAvfZNQSU8w/5NQSU8wCgAAoB57lURNQTD/lERNQTAKAABwRE1BMFBJTzB9aQoIaaBPBntD SE5GCgQAcImDiFRJTTAKAwACRE1BMQAKAAoAYKAJlGAKBXAKBWCgEJRgCgKgCnthCgIAcAoCYH1s eYOIg4hUSU0wCgQAYAAKBABsfW2DiIOIVElNMAoFAGAAbX1rCgJroAqTYAoFfW4KAm6hMaAvfZNQ SU8x/5NQSU8xCgAAoB57lURNQTH/lERNQTEKAABwRE1BMVBJTzF9aQqAaaAOe0NITkYKAgB9aQoD aaAOe0NITkYKCAB9aQowaXuJg4hUSU0wCgAABFBJTzAACgAKAAoDYHCDiIOIVElNMAoBAGAAYXlh CghifWliaaA6e0NITkYKEAB9aQsAQGl7iYOIVElNMAoAAARQSU8xAAoACgAKA2Bwg4iDiFRJTTAK AgBgAGF9amFqCEFUMDERCgoHAwgAAAAA7whBVDAyEQoKBwNAAAAAAO8IQVQwMxEKCgcDIAAAAADv CEFUMDURCgoHAAAAAAAAxghBVDA2EQoKBwAAAAAAAJEIQVRBMBEDCiQIQVRBMREDCiQIQVRBMhED CiQIQVRBMxEDCiQIR1RJTQoACEdTVE0KAAhHVURNCgAIR1VEVAoACEdDQjAKAAhHRkNCCgAUTC1H VEZfCwhBVEFEEQQKBwAIQVRBQhEECiQBcIdpYKAeYItpCgBJRDAwoBN9k0lEMDAKAJVgCngApEFU QUKhBqRBVEFCcGpUTUQwjGkKBklEMDOMaQoMSUQwNotpCmJJRDQ5i2kKaklENTOLaQp2SUQ1OYxB VEFECgFBMDAxjEFUQUQKBUEwMDWMQVRBQgoAQ01EMHAKoGegBmhwCrBncAoAQ01EMHAKAGFbE0FU QUIKCAo4Q01EMaAJe0lEMDAKgAChRwRwQVQwNkFUQURwSUQwNkEwMDFwZ0EwMDVwSUQwM2CgDJRJ RDAzCg9wCg9gfUEwMDVgQTAwNXBBVEFEQ01EMXAKAUNNRDBwCgBgoBJooA97Q0hORgoEAHBETUEx YKERoA97Q0hORgoBAHBETUEwYKBLBWBwiYOIVElNMAoDAAJgAAoACgBgd0NNRDAKOGVyZQoIZlsT QVRBQmYKOENNRDJwQVQwMkFUQUR9QTAwMWBBMDAxcGdBMDA1cEFUQURDTUQycAoBYXVDTUQwcAoA YKASaKAPe0NITkYKCABwUElPMWChEaAPe0NITkYKAgBwUElPMGCgRQZgd0NNRDAKOGVyZQoIZlsT QVRBQmYKOENNRDNwQVQwMUFUQUR7iYOIVElNMAoAAARgAAoACgAKA2B9QTAwMYOIg4hUSU0wCgQA YABBMDAxcGdBMDA1cEFUQURDTUQzdUNNRDCgSgaSYXdDTUQwCjhlcmUKCGZbE0FUQUJmCjhDTUQ0 oEsEe0lENDkLAAIAi2kKfklENjOBe0lENjMKD0lENjNgoCpgcEFUMDNBVEFEfUEwMDF2YEEwMDFw Z0EwMDVwQVRBRENNRDR1Q01EMKBNBHtJRDU5CwABAHdDTUQwCjhlcmUKCGZbE0FUQUJmCjhDTUQ1 cEFUMDVBVEFEe0lENTkK/0EwMDFwZ0EwMDVwQVRBRENNRDV1Q01EMKRBVEFCFEkER1RGRAGMaAoA Q01EMHdDTUQwCgdgd2AKCGEIR1RGQhECYFsTR1RGQgoAYURTVDBbE2gKCGFTUkMwcFNSQzBEU1Qw pEdURkJbgkgRQ0hOMAhfQURSCgAUI19HVE0ApEdUTV9USU1QU1RNUFVETVBVRFRQUENCMEZQQ0IU SgpfU1RNA3BUSU1QR1RJTXBTVE1QR1NUTXBVRE1QR1VETXBVRFRQR1VEVHBQQ0IwR0NCMHBGUENC R0ZDQlNUTV9oR1RJTUdTVE1HVURNR1VEVEdDQjBHRkNCcEdUSU1USU1QcEdTVE1TVE1QcEdVRE1V RE1QcEdVRFRVRFRQcEdDQjBQQ0IwcEdGQ0JGUENCcEdURl8KAGloQVRBMHBHVEZfCgFqaEFUQTFb ghxEUlYwCF9BRFIKABQPX0dURgCkR1RGREFUQTBbghxEUlYxCF9BRFIKARQPX0dURgCkR1RGREFU QTFbgkgRQ0hOMQhfQURSCgEUI19HVE0ApEdUTV9USU1TU1RNU1VETVNVRFRTU0NCMEZTQ0IUSgpf U1RNA3BUSU1TR1RJTXBTVE1TR1NUTXBVRE1TR1VETXBVRFRTR1VEVHBTQ0IwR0NCMHBGU0NCR0ZD QlNUTV9oR1RJTUdTVE1HVURNR1VEVEdDQjBHRkNCcEdUSU1USU1TcEdTVE1TVE1TcEdVRE1VRE1T cEdVRFRVRFRTcEdDQjBTQ0IwcEdGQ0JGU0NCcEdURl8KAGloQVRBMnBHVEZfCgFqaEFUQTNbghxE UlYwCF9BRFIKABQPX0dURgCkR1RGREFUQTJbghxEUlYxCF9BRFIKARQPX0dURgCkR1RGREFUQTNb gkMEVVNCXwhfQURSDAIAHwAIU1MzRAoCCF9QUlcSBgIKAwoEEB9cX0dQRRQYX0wwMwCGXC8DX1NC X1BDSTBVU0JfCgJbgkMEVVNCMghfQURSDAQAHwAIU1MzRAoCCF9QUlcSBgIKBAoEEB9cX0dQRRQY X0wwNACGXC8DX1NCX1BDSTBVU0IyCgJbgjZNTTk3CF9BRFIMBgAfAAhfUFJXEgYCCgUKBBAaXF9H UEUUE19MMDUAhlwuX1NCX1BDSTAKAghTTFBTCgBbgkgFU0xQQghfSElEDEHQDA4UKlNCRVYAoBNT TFBTcAoAU0xQU4ZTTFBCCgKhD3AKAVNMUFOGU0xQQgqAEBxcX0dQRRQVX0wxNgBcLwNfU0JfU0xQ QlNCRVZbgEZOT1IBCzQECgQQRypfU0lfFEAqX1NTVAGgRyFooEQIk2gKAVwvBF9TQl9QQ0kwU0JS R0VORkdwCghcLwRfU0JfUENJMFNCUkdMRE5fcAoAXC8EX1NCX1BDSTBTQlJHT1BUNnAKCVwvBF9T Ql9QQ0kwU0JSR0xETl9wCgBcLwRfU0JfUENJMFNCUkdPUFQ0XC8EX1NCX1BDSTBTQlJHRVhGR6BE CJNoCgJcLwRfU0JfUENJMFNCUkdFTkZHcAoIXC8EX1NCX1BDSTBTQlJHTEROX3AKAFwvBF9TQl9Q Q0kwU0JSR09QVDZwCglcLwRfU0JfUENJMFNCUkdMRE5fcAoAXC8EX1NCX1BDSTBTQlJHT1BUNFwv BF9TQl9QQ0kwU0JSR0VYRkegRAiTaAoDXC8EX1NCX1BDSTBTQlJHRU5GR3AKCFwvBF9TQl9QQ0kw U0JSR0xETl9wCoBcLwRfU0JfUENJMFNCUkdPUFQ2cAoJXC8EX1NCX1BDSTBTQlJHTEROX3AKQFwv BF9TQl9QQ0kwU0JSR09QVDRcLwRfU0JfUENJMFNCUkdFWEZHoEQIk2gKBFwvBF9TQl9QQ0kwU0JS R0VORkdwCghcLwRfU0JfUENJMFNCUkdMRE5fcArAXC8EX1NCX1BDSTBTQlJHT1BUNnAKCVwvBF9T Ql9QQ0kwU0JSR0xETl9wCkBcLwRfU0JfUENJMFNCUkdPUFQ0XC8EX1NCX1BDSTBTQlJHRVhGR6FA CFwvBF9TQl9QQ0kwU0JSR0VORkdwCghcLwRfU0JfUENJMFNCUkdMRE5fcApAXC8EX1NCX1BDSTBT QlJHT1BUNnAKCVwvBF9TQl9QQ0kwU0JSR0xETl9wCgBcLwRfU0JfUENJMFNCUkdPUFQ0XC8EX1NC X1BDSTBTQlJHRVhGR1uASFdNSQELlQIKAluBEEhXTUkBSFdNRAhIV01UCFuGHkhXTURIV01UAQBI K0JFQ0wIABBGTlcxCEZOVzIIW4BBQ0lPAQqyCgFbgQtBQ0lPAUFDRkcIW4BQTUlPAQsABApQW4FD BFBNSU8CUE1TMAhQV1NUAQABUlRDUwFQTVMxBQAIUFdFTgEARxJHUDBTEEdQMEUQR1AxUxBHUDFF EABACElPTU8QW4BHUElPAQuABAogW4ETR1BJTwIAQAdHUE8xCEdQTzIIW4BJUjIxAQohCgFbgQtJ UjIxAUlRMjEIW4BLREFUAQpgCgVbgRRLREFUAUtCRFQIABhLQklEAQAHFE4QX1BUUwFwaERCRzhw aEFDU1RwC///R1AwU3AL//9HUDFTe0JFQ0wKf0JFQ0ygFJKTaAoFcAoARk5XMXAKAEZOVzJcLwRf U0JfUENJMFNCUkdFTkZHcAoKXC8EX1NCX1BDSTBTQlJHTEROX6A1kpNoCgWiLlwvBF9TQl9QQ0kw U0JSR09QVDRbIQpQcAr/XC8EX1NCX1BDSTBTQlJHT1BUNKAbk2gKAXAKM1wvBF9TQl9QQ0kwU0JS R09QVDdcLwRfU0JfUENJMFNCUkdFWEZHoBCTQUNGRwoecAsAMElPTU+hK6ANk2gKAXALADFJT01P oA2TaAoDcAsAMUlPTU+gDZNoCgVwCwAxSU9NTxRKC19XQUsBeWgKBERCRzigCpNoCgFbIgu4C3AL ADBJT01PoBWTUlRDUwoAhlwuX1NCX1NMUEIKAnAK/0ZOVzFwCv9GTlcyXC8EX1NCX1BDSTBTQlJH RU5GR3AKClwvBF9TQl9QQ0kwU0JSR0xETl9wCgBcLwRfU0JfUENJMFNCUkdPUFQ3XC8EX1NCX1BD STBTQlJHRVhGR31CRUNMCoBCRUNMcAv//0dQMFNwC///R1AxU3AKAVBXRU5bgFRFTVABCoAKAVuB C1RFTVABREJHOAg= ------=_Part_176_2344176.1092285885887-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 05:10:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 103B516A4CE for ; Thu, 12 Aug 2004 05:10:12 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id D29DE43D2D for ; Thu, 12 Aug 2004 05:10:11 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-94.dsl.snfc21.pacbell.net [64.171.186.94]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7C5AA8U011823; Wed, 11 Aug 2004 22:10:10 -0700 Message-ID: <411AFBB1.6020302@root.org> Date: Wed, 11 Aug 2004 22:10:09 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiawei Ye References: <411A4C30.6050300@root.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: HEADSUP: new pci irq routing committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 05:10:12 -0000 Jiawei Ye wrote: > On Wed, 11 Aug 2004 09:41:20 -0700, Nate Lawson wrote: > >>Thanks to all the testers. The new pci irq routing code fixes devices >>for several users. If anyone has PCI device problems (timeouts, etc.), >>let me know. Send me the output of dmesg from boot -v and your ASL >>(acpidump -t -d > machine.asl) >> >>Thanks, >>-Nate > > Hi Nate, > > Please find my dmesg -a below and attached asl file. > Copyright (c) 1992-2004 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 5.2-CURRENT #2: Thu Aug 12 12:19:04 CST 2004 > leafy@chihiro.leafy.idv.tw:/usr/obj/usr/src/sys/CHIHIRO > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz (1794.56-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf12 Stepping = 2 > Features=0x3febf9ff > real memory = 268369920 (255 MB) > avail memory = 252952576 (241 MB) > netsmb_dev: loaded > npx0: [FAST] > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > acpi0: [GIANT-LOCKED] > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > cpu0: on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > acpi link set: \\_SB_.LNKD resource is not an IRQ (2) > acpi link set: \\_SB_.LNKD resource is not an IRQ (2) > unknown: _SRS failed, irq 11 via \\_SB_.LNKD First, you need to be sure you're running the latest versions I just committed so send the output of "ident acpi.ko | grep acpi_pci". Second, I need dmesg from boot -v to know more about what is happening here. Regular dmesg doesn't show the arbitration. -- Nate From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 05:17:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E08F716A4CE; Thu, 12 Aug 2004 05:17:29 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20AE143D1D; Thu, 12 Aug 2004 05:17:29 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id 1118850B7A; Thu, 12 Aug 2004 14:17:24 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id A128D50B20; Thu, 12 Aug 2004 14:17:22 +0900 (JST) Date: Thu, 12 Aug 2004 14:17:22 +0900 Message-ID: <7md61xgckd.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: "George V. Neville-Neil" In-Reply-To: References: <7mbrhiibby.wl@black.imgsrc.co.jp> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 cc: Current cc: Robert Watson Subject: Re: Sleeping in "rip6_output" with the following non-sleepable locks held X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 05:17:30 -0000 At Tue, 10 Aug 2004 21:39:09 -0700, George V. Neville-Neil wrote: > > I believe this is what you mean: > > > > @@ -376,7 +377,12 @@ > > code = icmp6->icmp6_code; > > } > > > > - M_PREPEND(m, sizeof(*ip6), M_TRYWAIT); > > + M_PREPEND(m, sizeof(*ip6), M_DONTWAIT); > > + if (m == NULL) { > > + error = ENOBUFS; > > + goto bad; > > + } > > + > > ip6 = mtod(m, struct ip6_hdr *); > > > > /* > > Sorry, forgot to put in the the name of the file. It's > > sys/netinet6/raw_ip6.c Do you have a plan to commit this? -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 05:19:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 011F116A4CE; Thu, 12 Aug 2004 05:19:48 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF9B343D4C; Thu, 12 Aug 2004 05:19:47 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-94.dsl.snfc21.pacbell.net [64.171.186.94]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7C5Jk8U011931; Wed, 11 Aug 2004 22:19:47 -0700 Message-ID: <411AFDF1.6050609@root.org> Date: Wed, 11 Aug 2004 22:19:45 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiawei Ye References: <411A4C30.6050300@root.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: HEADSUP: new pci irq routing committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 05:19:48 -0000 Regarding your floppy problems, here's the issue: > fdc0: > port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3 irq 6 drq 2 on acpi0 ^^^^^^^^^^^^^^^^^^^^^^^ What a lame way for your BIOS author to say 0x3f0-0x3f5. I think Warner was fixing some things in that area. > fdc0: I/O to control range incorrect > device_attach: fdc0 attach returned 6 -- Nate From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 05:20:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B91716A4CE for ; Thu, 12 Aug 2004 05:20:39 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00D3643D2D for ; Thu, 12 Aug 2004 05:20:39 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7C5J1ZD046973; Thu, 12 Aug 2004 01:19:01 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7C5J1tx046970; Thu, 12 Aug 2004 01:19:01 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 12 Aug 2004 01:19:01 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Jun Kuriyama In-Reply-To: <7md61xgckd.wl@black.imgsrc.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "George V. Neville-Neil" cc: Current Subject: Re: Sleeping in "rip6_output" with the following non-sleepable locks held X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 05:20:39 -0000 On Thu, 12 Aug 2004, Jun Kuriyama wrote: > > Sorry, forgot to put in the the name of the file. It's > > > > sys/netinet6/raw_ip6.c > > Do you have a plan to commit this? Yes, most likely tomorrow. It's merged into the rwatson_netperf branch but I wanted to let it settle there for at least 24 hours and finish my next test run. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 05:37:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B83A16A4CE; Thu, 12 Aug 2004 05:37:43 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D61D43D31; Thu, 12 Aug 2004 05:37:43 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-94.dsl.snfc21.pacbell.net [64.171.186.94]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7C5bg8U012242; Wed, 11 Aug 2004 22:37:42 -0700 Message-ID: <411B0226.3030806@root.org> Date: Wed, 11 Aug 2004 22:37:42 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: LoR aironet/VM subsystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 05:37:43 -0000 an0: at port 0x2000-0x203f irq 11 function 0 config 5 on pccard1 an0: got RSSI <-> dBM map an0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps an0: Ethernet address: 00:40:96:42:91:c5 an0: [GIANT-LOCKED] lock order reversal 1st 0xc163339c an0 (network driver) @ dev/an/if_an.c:1931 2nd 0xc134b164 user map (user map) @ vm/vm_map.c:2902 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c0696d88,c0697a08,c066630c) at kdb_backtrace+0x29 witness_checkorder(c134b164,9,c06469a0,b56) at witness_checkorder+0x544 _sx_xlock(c134b164,c0646997,b56) at _sx_xlock+0x50 _vm_map_lock_read(c134b128,c0646997,b56,1b69978,c1402e4c) at _vm_map_lock_read+0x33 vm_map_lookup(d0b69a10,bfbfd000,1,d0b69a14,d0b69a04) at vm_map_lookup+0x28 vm_fault(c134b128,bfbfd000,1,0,c1371840) at vm_fault+0x66 trap_pfault(d0b69ad8,0,bfbfd000) at trap_pfault+0xd2 trap(c04f0018,c06b0010,c1630010,c1633df4,bfbfd000) at trap+0x311 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc060661e, esp = 0xd0b69b18, ebp = 0xd0b69ba4 --- generic_copyin(c1632000,c020693a,d0b69c60,c04d4b78,c06bb8e0) at generic_copyin+0x32 ifhwioctl(c020693a,c1632000,d0b69c60,c1371840,c0698048) at ifhwioctl+0x854 ifioctl(c16219e0,c020693a,d0b69c60,c1371840,0) at ifioctl+0xbd soo_ioctl(c158f440,c020693a,d0b69c60,c133c480,c1371840) at soo_ioctl+0x2b1 ioctl(c1371840,d0b69d14,3,2,292) at ioctl+0x3e0 syscall(2f,2f,2f,3,bfbfef64) at syscall+0x217 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280d0083, esp = 0xbfbfad7c, ebp = 0xbfbfadb8 --- -Nate From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 05:50:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 727CB16A4CE for ; Thu, 12 Aug 2004 05:50:02 +0000 (GMT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5724643D48 for ; Thu, 12 Aug 2004 05:50:01 +0000 (GMT) (envelope-from alc@cs.rice.edu) Received: from localhost (calypso.cs.rice.edu [128.42.1.127]) by cs.rice.edu (Postfix) with ESMTP id 7F4364AB66; Thu, 12 Aug 2004 00:50:00 -0500 (CDT) Received: from cs.rice.edu ([128.42.1.30]) by localhost (calypso.cs.rice.edu [128.42.1.127]) (amavisd-new, port 10024) with LMTP id 07557-01-22; Thu, 12 Aug 2004 00:50:00 -0500 (CDT) Received: by cs.rice.edu (Postfix, from userid 19572) id 2D1DA4AB4F; Thu, 12 Aug 2004 00:50:00 -0500 (CDT) Date: Thu, 12 Aug 2004 00:49:59 -0500 From: Alan Cox To: Nate Lawson Message-ID: <20040812054959.GF3527@cs.rice.edu> References: <411B0226.3030806@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <411B0226.3030806@root.org> User-Agent: Mutt/1.4.2i X-Virus-Scanned: by amavis-20030616-p7 at cs.rice.edu cc: current@freebsd.org Subject: Re: LoR aironet/VM subsystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 05:50:02 -0000 On Wed, Aug 11, 2004 at 10:37:42PM -0700, Nate Lawson wrote: > an0: at port > 0x2000-0x203f irq 11 function 0 config 5 on pccard1 > an0: got RSSI <-> dBM map > an0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > an0: Ethernet address: 00:40:96:42:91:c5 > an0: [GIANT-LOCKED] > lock order reversal > 1st 0xc163339c an0 (network driver) @ dev/an/if_an.c:1931 > 2nd 0xc134b164 user map (user map) @ vm/vm_map.c:2902 > KDB: stack backtrace: > kdb_backtrace(0,ffffffff,c0696d88,c0697a08,c066630c) at kdb_backtrace+0x29 > witness_checkorder(c134b164,9,c06469a0,b56) at witness_checkorder+0x544 > _sx_xlock(c134b164,c0646997,b56) at _sx_xlock+0x50 > _vm_map_lock_read(c134b128,c0646997,b56,1b69978,c1402e4c) at > _vm_map_lock_read+0x33 > vm_map_lookup(d0b69a10,bfbfd000,1,d0b69a14,d0b69a04) at vm_map_lookup+0x28 > vm_fault(c134b128,bfbfd000,1,0,c1371840) at vm_fault+0x66 > trap_pfault(d0b69ad8,0,bfbfd000) at trap_pfault+0xd2 > trap(c04f0018,c06b0010,c1630010,c1633df4,bfbfd000) at trap+0x311 > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc060661e, esp = 0xd0b69b18, ebp = 0xd0b69ba4 --- > generic_copyin(c1632000,c020693a,d0b69c60,c04d4b78,c06bb8e0) at > generic_copyin+0x32 > ifhwioctl(c020693a,c1632000,d0b69c60,c1371840,c0698048) at ifhwioctl+0x854 > ifioctl(c16219e0,c020693a,d0b69c60,c1371840,0) at ifioctl+0xbd > soo_ioctl(c158f440,c020693a,d0b69c60,c133c480,c1371840) at soo_ioctl+0x2b1 > ioctl(c1371840,d0b69d14,3,2,292) at ioctl+0x3e0 > syscall(2f,2f,2f,3,bfbfef64) at syscall+0x217 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280d0083, esp = > 0xbfbfad7c, ebp = 0xbfbfadb8 --- > This looks like a programming error in the driver. Specifically, the driver is calling copyin() while holding a mutex. That's not allowed because of the potential for a page fault that sleeps. Alan From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 05:51:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBF7816A4CE for ; Thu, 12 Aug 2004 05:51:07 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 701D943D31 for ; Thu, 12 Aug 2004 05:51:07 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7C5nHCD001148; Wed, 11 Aug 2004 23:49:17 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 11 Aug 2004 23:49:28 -0600 (MDT) Message-Id: <20040811.234928.116874684.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <411AFDF1.6050609@root.org> References: <411A4C30.6050300@root.org> <411AFDF1.6050609@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: leafy7382@gmail.com cc: current@freebsd.org Subject: Re: HEADSUP: new pci irq routing committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 05:51:08 -0000 In message: <411AFDF1.6050609@root.org> Nate Lawson writes: : Regarding your floppy problems, here's the issue: : > fdc0: : > port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3 irq 6 drq 2 on acpi0 : ^^^^^^^^^^^^^^^^^^^^^^^ : What a lame way for your BIOS author to say 0x3f0-0x3f5. I think Warner : was fixing some things in that area. I didn't think I was, but I'll be happy to take a look at it... Warner From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 06:15:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F67516A4CE for ; Thu, 12 Aug 2004 06:15:18 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBF5343D2F for ; Thu, 12 Aug 2004 06:15:17 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7C6EWKI001339; Thu, 12 Aug 2004 00:14:32 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 12 Aug 2004 00:14:43 -0600 (MDT) Message-Id: <20040812.001443.32983963.imp@bsdimp.com> To: jmkatcher@yahoo.com From: "M. Warner Losh" In-Reply-To: <20040811164508.74419.qmail@web41104.mail.yahoo.com> References: <20040811164508.74419.qmail@web41104.mail.yahoo.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: Can someone please commit a sane module path in loader.conf? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 06:15:18 -0000 In message: <20040811164508.74419.qmail@web41104.mail.yahoo.com> Jeffrey Katcher writes: : I know I can override it in my local loader.conf, but the change to : /boot/modules only was _really_ annoying and unexpected. FYI, it should be : /boot/kernel for most people. >From UPDATING: 20040806: Module loading has been fixed. Some older installations will drop proper module_path initalization and modules will fail to load properly. If you have a line in /boot/loader.rc that says: "initialize drop", do (i386 only): cp /usr/src/sys/boot/i386/loader/loader.rc /boot/loader.rc chown root:wheel /boot/loader.rc chmod 444 /boot/loader.rc From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 06:30:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3169D16A4CE for ; Thu, 12 Aug 2004 06:30:05 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id D071943D2D for ; Thu, 12 Aug 2004 06:30:04 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7C6S2x8001518 for ; Thu, 12 Aug 2004 00:28:02 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 12 Aug 2004 00:28:13 -0600 (MDT) Message-Id: <20040812.002813.115746732.imp@bsdimp.com> To: current@freebsd.org From: "M. Warner Losh" In-Reply-To: <200408110916.i7B9GTj43770@Mail.NOSPAM.DynDNS.dK> References: <20040811065912.GA95263@xor.obsecurity.org> <20040811080350.GK80234@ip.net.ua> <200408110916.i7B9GTj43770@Mail.NOSPAM.DynDNS.dK> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 06:30:05 -0000 In message: <200408110916.i7B9GTj43770@Mail.NOSPAM.DynDNS.dK> Barry Bouwsma writes: : Which brings up something else -- has there been any : resolution of the conflict between `DISTDIR' as used by : ports, and `DISTDIR' as used by the `distribute' targets? : I have the former set in my make.conf, which resulted in : some odd paths, no matter how I specified `DESTDIR=' and : `DISTDIR=' as both environment and `make' options when in : the top-level src directory, but resolved itself only when : given as an option within the `etc' subdirectory. No. At work we do unnatural things to make ports honor DESTDIR in the way that we think it should work (build in a chroot, install into a chroot, make the package, and then chroot to DESTDIR and install there again). Warner From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 07:19:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FC4416A4CE; Thu, 12 Aug 2004 07:19:31 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id CECEE43D41; Thu, 12 Aug 2004 07:19:29 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i7C7JFX496118; Thu, 12 Aug 2004 09:19:15 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) i7C7JDf562386; Thu, 12 Aug 2004 09:19:14 +0200 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i7C7JCe05882; Thu, 12 Aug 2004 09:19:12 +0200 (MET DST) Date: Thu, 12 Aug 2004 09:19:12 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: "M. Warner Losh" In-Reply-To: <20040811.162640.00482545.imp@bsdimp.com> Message-ID: <20040812091334.F25699@beagle.kn.op.dlr.de> References: <20040810231044.GA70020@xor.obsecurity.org> <20040811.160420.34008155.imp@bsdimp.com> <20040811221348.GB93983@ip.net.ua> <20040811.162640.00482545.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org cc: kris@obsecurity.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2004 07:19:31 -0000 On Wed, 11 Aug 2004, M. Warner Losh wrote: MWL>In message: <20040811221348.GB93983@ip.net.ua> MWL> Ruslan Ermilov writes: MWL>: On Wed, Aug 11, 2004 at 04:04:20PM -0600, M. Warner Losh wrote: MWL>: > In message: <20040810231044.GA70020@xor.obsecurity.org> MWL>: > Kris Kennaway writes: MWL>: > : More fallout from the wonderful new make(1) semantics? MWL>: > MWL>: > I think it is speficially related to the changes to src/Makefile and MWL>: > src/Makefile.inc1. If I s/${_+_}//g on those two files, it appears MWL>: > that I can buildworld again (at least it doesn't die right away). MWL>: > MWL>: How exactly does it die for you, please provide some logs. MWL> MWL>The problem is due to the following in share/mk/sys.mk: MWL> MWL>.if !empty(.MAKEFLAGS:M-n) && ${.MAKEFLAGS:M-n} == "-n" MWL>_+_ ?= MWL>.else MWL>_+_ ?= + MWL>.endif MWL> MWL>This should have a third clause: MWL> MWL>.if ${MAKE_VERSION} >= 5200408030 && !empty(.MAKEFLAGS:M-n) && ${.MAKEFLAGS:M-n} == "-n" MWL> MWL>so that _+_ is defined to be nothing for those versions of make that MWL>don't yet support this new feature of posix. That should just 'not happen'. There has been one problem here: a bug in crunchgen emitting a line causing the wrong make to be used. This should not and was not fixed by causing the new .mk files to be usable with the old make but causing the right make to use in rescue. Otherwise you should obviously not forcibly use the old make with new .mk scripts or the other way around. The makefiles are usually smart enough to use either the new make and the new .mk files or the old, installed make and the old, installed .mk scripts. Any mismatch is either cause by a bug somewhere (as in the case of crunchgen) or forced by the user. harti From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 07:50:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C82DE16A4CE for ; Thu, 12 Aug 2004 07:50:58 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC8FF43D53 for ; Thu, 12 Aug 2004 07:50:57 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i7C7orE9021158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Aug 2004 11:50:54 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i7C7orKR021157 for current@freebsd.org; Thu, 12 Aug 2004 11:50:53 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Thu, 12 Aug 2004 11:50:53 +0400 From: Gleb Smirnoff To: current@freebsd.org Message-ID: <20040812075053.GA21129@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: m_pkthdr.rcvif->if_index broken in recent CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 07:50:58 -0000 I can see this at least in fxp driver: if I capture packets using ng_ether(4), and check interface name like this printf("idx %d, name %s\n", (*m)->m_pkthdr.rcvif->if_index, (*m)->m_pkthdr.rcvif->if_xname); I get on console: idx 0, name fxp0 Really fxp's index is 1 (AFAIK if_index must be > 0), I have checked this using if_nametoindex() from userland. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 07:56:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A88A16A4CE for ; Thu, 12 Aug 2004 07:56:31 +0000 (GMT) Received: from mr01.hansenet.de (mr01.hansenet.de [213.191.74.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F89543D4C for ; Thu, 12 Aug 2004 07:56:30 +0000 (GMT) (envelope-from db@nipsi.de) Received: from mail.nipsi.de (213.39.189.144) by mr01.hansenet.de (6.7.010) id 4119D65100003B28 for freebsd-current@freebsd.org; Thu, 12 Aug 2004 09:56:28 +0200 Received: from localhost (localhost [127.0.0.1]) (uid 1001) by mail.nipsi.de with local; Thu, 12 Aug 2004 09:56:15 +0200 Date: Thu, 12 Aug 2004 09:56:15 +0200 From: Dennis Berger To: Evan Dower Message-ID: <20040812075615.GA20444@nipsi.home.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: Project Evil: TI ACX111 non-success X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 07:56:31 -0000 I have the dlink g650+ which also has the acx111 chipset... NDIS failed acx driver failed also. regards, -Dennis On Wed, Aug 11, 2004 at 04:40:58PM -0700, Evan Dower wrote: > I've been trying to get the ndisulator to work for my NetGear WG311v2 so I > can take the ethernet cables and switches offthe floor in my hall. The > following is the "conversation" I've had with Bill Paul. It is perhaps best > to read from the bottom up to get the chronology right. Also, as it turns > out the net/acx100 port makes no claim to support the acx111, and I was > eventually able to build and load it, though of course it didn't work > because it doesn't support the acx111. Any help would be greatly > appreciated. > > -- > > I managed to get rid of the "can't re-use a leaf" messaged by deleting > the duplicate entry in ndis_driver_data.h. For some reason, whenever I > try to load if_ndis.ko (ndis.ko is already loaded), I get messages about > amdpm. Perhaps ndis returning 6 and failing to load is a result of the > same return value from trying to attach amdpm. > > amdpm0: port > 0xe4e0-0xe4ff at device 7.3 on pci0 > amdpm0: could not map i/o space > device_attach: amdpm0 attach returned 6 > ndis0: mem > 0xf0800000-0xf081ffff,0xf1000000-0xf1001fff irq 17 at device 6.0 on pci2 > ndis0: [GIANT-LOCKED] > no match for srand > ndis0: NDIS API version: 5.1 > ndis0: init handler failed > device_attach: ndis0 attach returned 6 > > Thanks again, > Evan Dower > > El mar, 20-07-2004 a las 10:58, Evan Dower escribi?: > >I have figured out that the "can't re-use a leaf" message is coming from > >trying to register a sysctl, which comes from the .inf file. This seems > >to indicate some limitations on the complexity of .inf files that can be > >properly parsed and turned into a list of sysctls. Since I'm not exactly > >sure what those limitations are, I'm sending you a link to the .inf file > >(and the .sys file for good measure)? Other than that, it looks like > >srand might just need to be plugged into one of the function tables > >(probably the hal table, I guess). Also, if you can tell me what > >limitations exist for the .inf file, I will gladly modify it to work and > >make it available to other WG311v2 owners. > >Thanks again, > >Evan Dower > >Note: Much of the .inf file (anything not for XP) is commented out in an > >attempt to make things work. This was my doing. It didn't ship that way. > >Since I don't really understand the Windows registry, I didn't get too > >adventurous. > > > >Files at: http://students.washington.edu/evantd/pub/evil/ > > > >El lun, 12-07-2004 a las 16:05, Evan Dower escribi?: > >> I have a Netgear WG311v2. The v2 turns out to be very important as the > >> original (v1 you might call it now) was based on an Atheros AR5212 and > >> was thus supported by the ath driver. v2 is based on the the TI AXC111 > >> (aka TNETW1130), which should be supported by the net/acx100 port, but > >> if_acx.ko fails to load due to a missing __panic symbol. Following the > >> instructions you posted in an email, I made ndis_driver_data.h and > >> built and loaded the if_ndis.ko module (after loading ndis.ko or > >> compiling it into the kernel). I used the Windows XP .SYS and .INF > >> files, though the Windows 2000 versions gave the same result, the > >> Windows 98 files produced a module that panicked on load, and I didn't > >> try the Windows ME files. The following is the output from `make > >> load`. > >> > /sbin/kldload -v /usr/current/src/sys/modules/if_ndis/if_ndis.ko > >> ndis0: mem > >> 0xec800000-0xec81ffff, > >> 0xed000000-0xed001fff irq 17 at device 6.0 on pci2 > >> ndis0: [GIANT-LOCKED] > >> can't re-use a leaf (dot11DesiredBSSType)! > >> no match for srand > >> ndis0: NDIS API version: 5.1 > >> ndis0: init handler failed > >> device_attach: ndis0 attach returned 6 > >> Loaded /usr/current/src/sys/modules/if_ndis/if_ndis.ko, id=11 > >> > Loading the module does not create /dev/ndis0 or /dev/if_ndis0 (or > >> anything of the sort). I am running today's -CURRENT. > >> > It seems that it requires srand, and I assume the 'can't re-use a leaf > >> (dot11DesiredBSSType)!' is also a show-stopper. I ordered my card from > >> newegg.com for about $50. > >> > If there is anything else you might be interested in (a verbose boot > >> log, copies of the .SYS and .INF files, testing for patches, etc.), > >> just let me know. I'd be happy to help (especially since the result is > >> a working wireless connection). > >> > Thanks very much, > > -- > Evan Dower > Undergraduate, Computer Science > University of Washington > Public key: http://students.washington.edu/evantd/pgp-pub-key.txt > Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D > > _________________________________________________________________ > Don?t just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > _______________________________________________ > 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 Aug 12 07:59:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B50516A4CE for ; Thu, 12 Aug 2004 07:59:34 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF17143D2F for ; Thu, 12 Aug 2004 07:59:32 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i7C7xSYK021250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Aug 2004 11:59:29 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i7C7xS27021249 for current@freebsd.org; Thu, 12 Aug 2004 11:59:28 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Thu, 12 Aug 2004 11:59:28 +0400 From: Gleb Smirnoff To: current@freebsd.org Message-ID: <20040812075928.GA21205@cell.sick.ru> References: <20040812075053.GA21129@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040812075053.GA21129@cell.sick.ru> User-Agent: Mutt/1.5.6i Subject: if_index in struct ifnet broken in recent CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 07:59:34 -0000 Hmm, some more information: actually if_index is broken not only in in mbuf packet headers. This code with different addresses: bzero((caddr_t)&ro, sizeof(ro)); sin = (struct sockaddr_in *)&ro.ro_dst; sin->sin_len = sizeof(*sin); sin->sin_family = AF_INET; sin->sin_addr = \\some address\\; rtalloc_ign(&ro, RTF_CLONING); if (ro.ro_rt != NULL) { struct rtentry *rt = ro.ro_rt; printf("rt idx %d, name %s\n", rt->rt_ifp->if_index, rt->rt_ifp->if_xname); produces rt idx 0, name fxp0 rt idx 0, name lo0 On Thu, Aug 12, 2004 at 11:50:53AM +0400, Gleb Smirnoff wrote: T> I can see this at least in fxp driver: if I capture packets using T> ng_ether(4), and check interface name like this T> T> printf("idx %d, name %s\n", T> (*m)->m_pkthdr.rcvif->if_index, T> (*m)->m_pkthdr.rcvif->if_xname); T> I get on console: T> T> idx 0, name fxp0 T> T> Really fxp's index is 1 (AFAIK if_index must be > 0), I have checked this T> using if_nametoindex() from userland. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 09:11:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D063F16A4CE for ; Thu, 12 Aug 2004 09:11:52 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CAD143D1F for ; Thu, 12 Aug 2004 09:11:52 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.13.1/8.12.11) with ESMTP id i7C9Bpw8007193; Thu, 12 Aug 2004 02:11:51 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i7C9BnVn007192; Thu, 12 Aug 2004 02:11:49 -0700 (PDT) (envelope-from obrien) Date: Thu, 12 Aug 2004 02:11:48 -0700 From: "David O'Brien" To: Kris Kennaway Message-ID: <20040812091148.GB57570@dragon.nuxi.com> Mail-Followup-To: David O'Brien , Kris Kennaway , current@FreeBSD.org References: <20040811224504.GA46960@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040811224504.GA46960@xor.obsecurity.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: current@FreeBSD.org Subject: Re: gcc 3.4.2/x.org packages uploaded X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2004 09:11:52 -0000 On Wed, Aug 11, 2004 at 03:45:04PM -0700, Kris Kennaway wrote: > I've uploaded a full package set built with gcc 3.4.2 and x.org, Thanks! Any timeline on updated AMD64 64-bit packages? -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 04:28:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A796816A4CE for ; Thu, 12 Aug 2004 04:28:33 +0000 (GMT) Received: from web41105.mail.yahoo.com (web41105.mail.yahoo.com [66.218.93.21]) by mx1.FreeBSD.org (Postfix) with SMTP id 848D743D31 for ; Thu, 12 Aug 2004 04:28:33 +0000 (GMT) (envelope-from jmkatcher@yahoo.com) Message-ID: <20040812042833.56392.qmail@web41105.mail.yahoo.com> Received: from [24.18.54.216] by web41105.mail.yahoo.com via HTTP; Wed, 11 Aug 2004 21:28:33 PDT Date: Wed, 11 Aug 2004 21:28:33 -0700 (PDT) From: Jeffrey Katcher To: John-Mark Gurney In-Reply-To: <20040812041934.GZ991@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 12 Aug 2004 11:51:08 +0000 cc: current@freebsd.org Subject: Re: Can someone please commit a sane module path in loader.conf? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 04:28:33 -0000 --- John-Mark Gurney wrote: > Jeffrey Katcher wrote this message on Wed, Aug 11, 2004 at 09:45 -0700: > > I know I can override it in my local loader.conf, but the change to > > /boot/modules only was _really_ annoying and unexpected. FYI, it should be > > /boot/kernel for most people. > > No. Could you please upgrade your loader.rc as per UPDATING? Of course, but UPDATING was only changed recently to mention this, and wasn't as of ~9am PDT when I posted my request. Jeff Katcher From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 08:29:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9591416A4CE; Thu, 12 Aug 2004 08:29:47 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37BE943D54; Thu, 12 Aug 2004 08:29:47 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id i7C8TkLu044180; Thu, 12 Aug 2004 04:29:46 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)i7C8TkJA044174; Thu, 12 Aug 2004 04:29:46 -0400 (EDT) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Thu, 12 Aug 2004 04:29:45 -0400 (EDT) From: Jeff Roberson To: Martin Blapp In-Reply-To: <20040811200323.B31181@cvs.imp.ch> Message-ID: <20040812042621.O7322@mail.chesapeake.net> References: <20040811200323.B31181@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Thu, 12 Aug 2004 11:51:08 +0000 cc: freebsd-current@freebsd.org cc: Robert Watson Subject: Re: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 08:29:47 -0000 On Wed, 11 Aug 2004, Martin Blapp wrote: > > Hi, > > > > > You might well want to try 4BSD. > > > > I did that too. The milter stress test I run was sending 200 mails > with 5 different sorts of attachements into a mail loop. This means > these 200 mails are going 26 times trough the milter. > > The ULE scheduler did process them first very fast. With more processes, > the sendmail transactions lagged a lot and it was only running 1-2 of > them at one time. This sucks because there is also a lot of timeout > handling (waiting for DNS responses). > > All in one I must say that the SCHED4BSD processed the mails in half of > the time as SCHEDULE did. The mix involved included everything: > > - Preforked mimedefang workers > - Forked Sendmails > - Threaded applications like clamd, mimedefang-milter > > So I'd call it a typical real world situation. > > Another thing I observed was that SCHED4BSD has zero IDLE time, while > SCHEDULE always idled between 20% and 50% ! This with 500 running processes > and a load of 2.5 -3.0. > Hi martin. This is a great test. Can you try it with my most recent change to sched_ule.c? Your version should be 1.21. I found some serious issues that have been addressed. Secondly, what kind of machine is this? Is this test simple to setup so that I may reproduce it here? Thanks! Jeff > Martin > > _______________________________________________ > 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 Aug 12 12:02:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD60F16A4CE for ; Thu, 12 Aug 2004 12:02:16 +0000 (GMT) Received: from smarthost.enta.net (smarthost.enta.net [195.74.97.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA03D43D1F for ; Thu, 12 Aug 2004 12:02:16 +0000 (GMT) (envelope-from jacs@gnome.co.uk) Received: from smartsmtp.enta.net (smtp.enta.net [195.74.97.230]) by smarthost.enta.net (Postfix) with ESMTP id 48557F67FE for ; Thu, 12 Aug 2004 12:51:32 +0100 (BST) Received: from smtp.enta.net (localhost [127.0.0.1]) by smartsmtp.enta.net (8.12.3/8.12.3) with ESMTP id i7CBr1b4010398 for ; Thu, 12 Aug 2004 12:53:02 +0100 (BST) (envelope-from jacs@gnome.co.uk) Received: from hawk.gnome.co.uk (81-31-113-153.adsl.entanet.co.uk [81.31.113.153]) by smtp.enta.net (Postfix) with SMTP id 3D4EE98B99 for ; Thu, 12 Aug 2004 12:53:01 +0100 (BST) Received: from [192.168.123.12] (hawk.gnome.co.uk [192.168.123.12]) by hawk.gnome.co.uk (8.12.10/8.12.10) with ESMTP id i7CBowkS013197 for ; Thu, 12 Aug 2004 12:50:59 +0100 (BST) (envelope-from jacs@gnome.co.uk) From: Chris Stenton To: FreeBSD Current Content-Type: text/plain Message-Id: <1092311458.13121.6.camel@hawk.gnome.co.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 12 Aug 2004 12:50:58 +0100 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.44 Subject: bad tcp cksum on outgoing packets X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 12:02:17 -0000 I have just been doing some debugging on my 5.2.1 box and noticed that outgoing tcp packets on the box are coming up with bad checksums on tcpdump. I am using the nge interface. Here is a sample output. 12:44:29.458021 0:4:e2:10:60:83 0:c:6e:4e:a0:cc ip 82: hawk.gnome.co.uk.ssh > kite.gnome.co.uk.2167: P [bad tcp cksum 9420!] 2071:2099(28) ack 753 win 65535 (DF) [tos 0x10] (ttl 64, id 35623, len 68, bad cksum 0!) 12:44:29.642088 0:c:6e:4e:a0:cc 0:4:e2:10:60:83 ip 60: kite.gnome.co.uk.2167 > hawk.gnome.co.uk.ssh: . [tcp sum ok] 753:753(0) ack 2099 win 64956 (DF) (ttl 128, id 44852, len 40) Any ideas whats going on as the packet does not seem to be resent? Chris From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 12:35:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69B9D16A4D0; Thu, 12 Aug 2004 12:35:10 +0000 (GMT) Received: from mx1.imp.ch (mx1.imp.ch [157.161.9.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ECF643D2F; Thu, 12 Aug 2004 12:35:09 +0000 (GMT) (envelope-from mb@imp.ch) Received: from mx1.imp.ch (mx.imp.ch [157.161.9.64]) by mx1.imp.ch (8.12.11/8.12.11) with ESMTP id i7CCZ0us007019; Thu, 12 Aug 2004 14:35:01 +0200 (CEST) (envelope-from mb@imp.ch) Received: from mx1.imp.ch (localhost [127.0.0.1]) by mx1.imp.ch (8.12.11/8.12.11/Submit) with ESMTP id i7CCYwCd006944; Thu, 12 Aug 2004 14:34:58 +0200 (CEST) (envelope-from mb@imp.ch) Received: (from clamav@localhost) by mx1.imp.ch (8.12.11/8.12.11/Submit) id i7CCYue5006923; Thu, 12 Aug 2004 14:34:56 +0200 (CEST) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by ns1.imp.ch (MIMEDefang) with ESMTP id i7CCYqpq040960; Thu, 12 Aug 2004 14:34:56 +0200 (CEST) Date: Thu, 12 Aug 2004 14:34:52 +0200 (CEST) From: Martin Blapp To: Jeff Roberson In-Reply-To: <20040812042621.O7322@mail.chesapeake.net> Message-ID: <20040812143133.G31181@cvs.imp.ch> References: <20040811200323.B31181@cvs.imp.ch> <20040812042621.O7322@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Resent: Yes X-Spam-Checksum: 6106f5af11461863ed9d40209e3f5b96 X-Virus-Message-Status: No X-Virus-Status: No, scantime="0.0066 seconds" X-Spam-Status: No, hits=-5.897 required=5 scantime="4.2512 seconds" tests=BAYES_00,FORGED_RCVD_HELO, SMILEY X-Scanned-By: MIMEDefang 2.44 cc: freebsd-current@freebsd.org cc: Robert Watson Subject: Re: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 12:35:10 -0000 Hi, > Hi martin. This is a great test. Can you try it with my most recent > change to sched_ule.c? Your version should be 1.21. I found some serious > issues that have been addressed. > > Secondly, what kind of machine is this? Is this test simple to setup so > that I may reproduce it here? This is a IBM X-Series i345 SMP 2CPU 3.1 GHz Xeon Server with 2GB mem each. I used this small script here to load it. I've prepared a shell script which calls this 200 times. The mails are then rotating from sendmail to milter in a 26 times loop which takes almost forever ;-). #!/usr/bin/perl use Net::SMTP; $target_smtp_host = $ARGV[0]; $target_user1 = $ARGV[1]; $target_user2 = $ARGV[2]; while () { $mailmessage .= $_; } $smtp = Net::SMTP->new($target_smtp_host, Hello => 'myhost', Timeout => 10, Debug => 0, ); $smtp->mail('testuser@imp.ch'); $smtp->to($target_user1, $target_user2); $smtp->data(); $smtp->datasend("To: postmaster\n"); $smtp->datasend($mailmessage); $success = $smtp->dataend(); $smtp->quit; if ($success) { print "OK\n"; exit(0); } else { print "NO\n"; exit(1); } From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 12:37:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F99B16A4CF for ; Thu, 12 Aug 2004 12:37:29 +0000 (GMT) Received: from mail0.ewetel.de (mail0.ewetel.de [212.6.122.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58A5E43D45 for ; Thu, 12 Aug 2004 12:37:28 +0000 (GMT) (envelope-from uwe@laverenz.de) Received: from ensign.laverenz.de (dialin-80-228-12-060.ewetel.net [80.228.12.60]) by mail0.ewetel.de (8.12.1/8.12.9) with ESMTP id i7CCbPt4026776 for ; Thu, 12 Aug 2004 14:37:26 +0200 (MEST) Received: from localhost (localhost.laverenz.de [127.0.0.1]) by ensign.laverenz.de (Postfix) with ESMTP id E57D876F42B for ; Thu, 12 Aug 2004 14:37:24 +0200 (CEST) Received: from ensign.laverenz.de ([127.0.0.1]) by localhost (ensign.laverenz.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 71559-01-4 for ; Thu, 12 Aug 2004 14:37:17 +0200 (CEST) Received: by ensign.laverenz.de (Postfix, from userid 2000) id 1C1D776F42C; Thu, 12 Aug 2004 14:35:03 +0200 (CEST) Date: Thu, 12 Aug 2004 14:35:02 +0200 From: Uwe Laverenz To: current@freebsd.org Message-ID: <20040812123502.GA71807@ensign.laverenz.de> Mail-Followup-To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: private site Sender: uwe@laverenz.de User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at laverenz.de X-CheckCompat: OK Subject: VIA C3M-266 vs. Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 12:37:29 -0000 Hi, I just wanted to report a quite annoying (for me ;) problem with -CURRENT: I've been running a small server with 5.2.1p9 on a VIA C3M-266 board for several months. This is a micro-ATX board with VIA's CLE-266 chipset for PIII-comaptible CPUs. I experienced problems with rpc.lockd and decided to switch to -CURRENT. I first bootet with a new kernel and the old 5.2.1 userland: no problem. I continued with the upgrade and did the necessary installworld and mergemaster stuff. After the complete upgrade, the machine does not boot correctly anymore, it crashes in or shortly after the bootloader. I don't get any useful error messages. This problem must be related to the VIA motherboard, because the system starts fine with other boards (Asus A7V600, Asus P5A). Is this a known problem? thank you, Uwe From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 12:46:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B04216A4CE; Thu, 12 Aug 2004 12:46:33 +0000 (GMT) Received: from mx1.imp.ch (mx1.imp.ch [157.161.9.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id C834D43D3F; Thu, 12 Aug 2004 12:46:32 +0000 (GMT) (envelope-from mb@imp.ch) Received: from mx1.imp.ch (mx.imp.ch [157.161.9.64]) by mx1.imp.ch (8.12.11/8.12.11) with ESMTP id i7CCkRN4022014; Thu, 12 Aug 2004 14:46:27 +0200 (CEST) (envelope-from mb@imp.ch) Received: from mx1.imp.ch (localhost [127.0.0.1]) by mx1.imp.ch (8.12.11/8.12.11/Submit) with ESMTP id i7CCkOQq021953; Thu, 12 Aug 2004 14:46:25 +0200 (CEST) (envelope-from mb@imp.ch) Received: (from clamav@localhost) by mx1.imp.ch (8.12.11/8.12.11/Submit) id i7CCkOdA021942; Thu, 12 Aug 2004 14:46:24 +0200 (CEST) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by ns1.imp.ch (MIMEDefang) with ESMTP id i7CCkJpq044084; Thu, 12 Aug 2004 14:46:24 +0200 (CEST) Date: Thu, 12 Aug 2004 14:46:19 +0200 (CEST) From: Martin Blapp To: Jeff Roberson In-Reply-To: <20040812143133.G31181@cvs.imp.ch> Message-ID: <20040812144448.F31181@cvs.imp.ch> References: <20040811200323.B31181@cvs.imp.ch> <20040812042621.O7322@mail.chesapeake.net> <20040812143133.G31181@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Resent: Yes X-Spam-Checksum: f32f0a1ae76e5060cb510e16a14bb40a X-Virus-Message-Status: No X-Virus-Status: No, scantime="0.0209 seconds" X-Spam-Status: No, hits=-5.637 required=5 scantime="2.1513 seconds" tests=BAYES_00,FORGED_RCVD_HELO,SMILEY, UPPERCASE_25_50 X-Scanned-By: MIMEDefang 2.44 cc: freebsd-current@freebsd.org cc: Robert Watson Subject: Re: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 12:46:33 -0000 > I used this small script here to load it. I've prepared a shell script which > calls this 200 times. The mails are then rotating from sendmail to milter in > a 26 times loop which takes almost forever ;-). If you use sendmail, be sure you have these set up in the .mc configuration: define(`confREFUSE_LA', `800') define(`confQUEUE_LA', `600') define(`confDELAY_LA',`500') define(`confMAX_DAEMON_CHILDREN', `1000') define(`confMAX_QUEUE_CHILDREN', `500') define(`confBAD_RCPT_THROTTLE',`500')dnl define(`confMAX_CONNECTION_RATE', `600') define(`confBAD_RCPT_THROTTLE_TIME', `1000') define(`confMAX_CLIENT_CONNECTION_RATE', `1000') define(`confCONNECTION_RATE_WINDOW_SIZE', `600') Else sendmail will refuse connections. If you need an exact setup, I can prepare something for you (package) which you can just install and then do the tests. Martin From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 12:53:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4334A16A4CE for ; Thu, 12 Aug 2004 12:53:44 +0000 (GMT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A115F43D46 for ; Thu, 12 Aug 2004 12:53:41 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 44606 invoked from network); 12 Aug 2004 12:53:39 -0000 Received: from 0x50a43fc7.hknxx1.adsl-dhcp.tele.dk (HELO peter.osted.lan) (80.164.63.199) by relay.pair.com with SMTP; 12 Aug 2004 12:53:39 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost [127.0.0.1]) by peter.osted.lan (8.12.10/8.12.10) with ESMTP id i7CCrcRf001615 for ; Thu, 12 Aug 2004 14:53:39 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.12.10/8.12.10/Submit) id i7CCrcb8001614 for current@freebsd.org; Thu, 12 Aug 2004 14:53:38 +0200 (CEST) (envelope-from pho) Date: Thu, 12 Aug 2004 14:53:38 +0200 From: Peter Holm To: current@freebsd.org Message-ID: <20040812125338.GA1476@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: panic: no upcall owned X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 12:53:44 -0000 During stress test of current from Aug 11 01:16 UTC, I got: #23 0xc064fb36 in thread_user_enter (p=0xc2052378, td=0xc1e01160) at ../../../kern/kern_kse.c:1179 1179 KASSERT(ku != NULL, ("no upcall owned")); More info @ http://www.holm.cc/stress/log/cons64.html -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 13:03:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9552416A4CF for ; Thu, 12 Aug 2004 13:03:25 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id B81DC43D41 for ; Thu, 12 Aug 2004 13:03:24 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i7CD3MnH023910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Aug 2004 17:03:22 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i7CD3LqU023909 for current@freebsd.org; Thu, 12 Aug 2004 17:03:21 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Thu, 12 Aug 2004 17:03:21 +0400 From: Gleb Smirnoff To: current@freebsd.org Message-ID: <20040812130321.GA23885@cell.sick.ru> References: <20040812075053.GA21129@cell.sick.ru> <20040812075928.GA21205@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040812075928.GA21205@cell.sick.ru> User-Agent: Mutt/1.5.6i Subject: Resolved: if_index in struct ifnet broken in recent CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 13:03:25 -0000 The problem was that kernel source tree from which I was building module was newer than running kernel, and struct ifnet size has changed recently... On Thu, Aug 12, 2004 at 11:59:28AM +0400, Gleb Smirnoff wrote: T> Hmm, some more information: actually if_index is broken T> not only in in mbuf packet headers. T> T> This code with different addresses: T> T> bzero((caddr_t)&ro, sizeof(ro)); T> sin = (struct sockaddr_in *)&ro.ro_dst; T> sin->sin_len = sizeof(*sin); T> sin->sin_family = AF_INET; T> sin->sin_addr = \\some address\\; T> rtalloc_ign(&ro, RTF_CLONING); T> if (ro.ro_rt != NULL) { T> struct rtentry *rt = ro.ro_rt; T> T> printf("rt idx %d, name %s\n", T> rt->rt_ifp->if_index, T> rt->rt_ifp->if_xname); T> T> produces T> T> rt idx 0, name fxp0 T> rt idx 0, name lo0 T> T> On Thu, Aug 12, 2004 at 11:50:53AM +0400, Gleb Smirnoff wrote: T> T> I can see this at least in fxp driver: if I capture packets using T> T> ng_ether(4), and check interface name like this T> T> T> T> printf("idx %d, name %s\n", T> T> (*m)->m_pkthdr.rcvif->if_index, T> T> (*m)->m_pkthdr.rcvif->if_xname); T> T> I get on console: T> T> T> T> idx 0, name fxp0 T> T> T> T> Really fxp's index is 1 (AFAIK if_index must be > 0), I have checked this T> T> using if_nametoindex() from userland. T> T> -- T> Totus tuus, Glebius. T> GLEBIUS-RIPN GLEB-RIPE T> _______________________________________________ T> freebsd-current@freebsd.org mailing list T> http://lists.freebsd.org/mailman/listinfo/freebsd-current T> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 13:10:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DF6116A4CE; Thu, 12 Aug 2004 13:10:41 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B573343D45; Thu, 12 Aug 2004 13:10:40 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7CDAZQA017517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2004 16:10:36 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7CDAcm3024911; Thu, 12 Aug 2004 16:10:38 +0300 (EEST) (envelope-from ru) Date: Thu, 12 Aug 2004 16:09:17 +0300 From: Ruslan Ermilov To: Chris Stenton Message-ID: <20040812130917.GC24142@ip.net.ua> Mail-Followup-To: net@FreeBSD.org References: <1092311458.13121.6.camel@hawk.gnome.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5G06lTa6Jq83wMTw" Content-Disposition: inline In-Reply-To: <1092311458.13121.6.camel@hawk.gnome.co.uk> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: FreeBSD Current cc: net@freebsd.org Subject: Re: bad tcp cksum on outgoing packets X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 13:10:41 -0000 --5G06lTa6Jq83wMTw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Cc: freebsd-net] On Thu, Aug 12, 2004 at 12:50:58PM +0100, Chris Stenton wrote: > I have just been doing some debugging on my 5.2.1 box and noticed that > outgoing tcp packets on the box are coming up with bad checksums on > tcpdump. I am using the nge interface. >=20 > Here is a sample output. >=20 > 12:44:29.458021 0:4:e2:10:60:83 0:c:6e:4e:a0:cc ip 82: > hawk.gnome.co.uk.ssh > kite.gnome.co.uk.2167: P [bad tcp cksum 9420!] > 2071:2099(28) ack 753 win 65535 (DF) [tos 0x10] (ttl 64, id 35623, len > 68, bad cksum 0!) >=20 > 12:44:29.642088 0:c:6e:4e:a0:cc 0:4:e2:10:60:83 ip 60: > kite.gnome.co.uk.2167 > hawk.gnome.co.uk.ssh: . [tcp sum ok] 753:753(0) > ack 2099 win 64956 (DF) (ttl 128, id 44852, len 40) >=20 >=20 > Any ideas whats going on as the packet does not seem to be resent? >=20 You don't have hardware checksums enabled, do you? I barely recall they are incompatible with bpf(4). Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --5G06lTa6Jq83wMTw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBG2v9qRfpzJluFF4RArWxAKCYaNQSzY4GbX34pTfuYrx/sRIJ1wCfRRHJ 81zCPUKuIGlwNtRYrAdIJGI= =4GvF -----END PGP SIGNATURE----- --5G06lTa6Jq83wMTw-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 13:11:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8AD916A4CF for ; Thu, 12 Aug 2004 13:11:40 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F6DC43D39 for ; Thu, 12 Aug 2004 13:11:40 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 16070 invoked from network); 12 Aug 2004 13:11:40 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 12 Aug 2004 13:11:39 -0000 Received: from [10.50.41.91] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i7CDBGbV099702; Thu, 12 Aug 2004 09:11:36 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Bruce Evans Date: Wed, 11 Aug 2004 17:29:23 -0400 User-Agent: KMail/1.6.2 References: <20040805050422.GA41201@cat.robbins.dropbear.id.au> <200408051759.53079.jhb@FreeBSD.org> <20040811170302.T1037@epsplex.bde.org> In-Reply-To: <20040811170302.T1037@epsplex.bde.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408111729.23451.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-current@FreeBSD.org cc: Tim Robbins Subject: Re: Atomic operations on i386/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 13:11:40 -0000 On Wednesday 11 August 2004 04:56 am, Bruce Evans wrote: > On Thu, 5 Aug 2004, John Baldwin wrote: > > Actually, using mov instead of lock xchg for store_rel reduced > > performance in some benchmarks Scott ran on an SMP machine, I'm guessing > > due to the higher latency of locks becoming available to other CPUs. I'm > > still waiting for benchmark results on UP to see if the change should be > > made under #ifndef SMP or some such. > > I don't believe unlocked instructions could be slower, and using > unlocked && unfenced instructions is just broken in the SMP case. > Perhaps there is enough synchronization provided by the lock in load_acq > (which in theory needs less locking than store_rel) for missing > synchronization in store_rel to sort of work. x86 processors ensure program order of stores, so you don't actually need an sfence because it would be redundant. The problem with using a simple mov is that even though it is faster it can sit in a cache for a while before it is visible to other CPUs hence the higher latency problem that I alluded to above. > > > Also, could we use MFENCE/LFENCE/SFENCE in combination with MOV on > > > SMP systems instead of LOCK CMPXCHG / (implied LOCK) XCHG? > > It isn't clear to me (from amd64 manuals) that *FENCE affects caches > other than ones seen by the current CPU. I think they do, and can be > used (MFENCE might be needed for both). They should work for the same > reasons that "LOCK MOV" is an invalid instruction (MOV is inherently > atomic (?)). Apparently we are using fake "LOCK MOV"s just for the > side effects of the lock instruction (at least on amd64's, the lock > instruction does *FENCE implicitly). *FENCE doesn't do cache flushing, it determines write ordering as far as the order that writes become visible to devices outside of the CPU, e.g. other CPUs and other devices that can access memory via DMA, etc. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 13:31:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75B8916A4CE for ; Thu, 12 Aug 2004 13:31:24 +0000 (GMT) Received: from mail.gactr.uga.edu (mail.gactr.uga.edu [128.192.37.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 132F143D53 for ; Thu, 12 Aug 2004 13:31:24 +0000 (GMT) (envelope-from robin.blanchard@gactr.uga.edu) Received: from localhost (localhost [127.0.0.1]) by mail.gactr.uga.edu (Postfix) with ESMTP id 4F5A2DA8B2 for ; Thu, 12 Aug 2004 09:31:05 -0400 (EDT) Received: from EBE1.gc.nat (E2K1.gc.nat [10.10.11.21]) by mail.gactr.uga.edu (Postfix) with ESMTP id 7FFD7DA8AD for ; Thu, 12 Aug 2004 09:31:04 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Aug 2004 09:31:22 -0400 Message-ID: <9B5C1FCAFB35084787C21EFFFA78DD9E612D6C@EBE1.gc.nat> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: cvs commit: src/sys/dev/acpica acpi_pci_link.c acpi_pcib.cacpi_pcib_acpi.c acpi_pcib_pci.c acpi_pcibvar.h Thread-Index: AcR/zIElU3VBkDWgRde9xCb4t/ctGQAN61hwABsOSHA= From: "Robin P. Blanchard" To: "Daniel Eriksson" , X-Virus-Scanned: by amavisd-new at gactr.uga.edu Subject: RE: cvs commit: src/sys/dev/acpica acpi_pci_link.c acpi_pcib.cacpi_pcib_acpi.c acpi_pcib_pci.c acpi_pcibvar.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 13:31:24 -0000 > -----Original Message----- > From: owner-freebsd-current@freebsd.org=20 > [mailto:owner-freebsd-current@freebsd.org] On Behalf Of=20 > Daniel Eriksson > Sent: Wednesday, August 11, 2004 8:49 PM > To: 'Nate Lawson' > Cc: freebsd-current@freebsd.org > Subject: RE: cvs commit: src/sys/dev/acpica acpi_pci_link.c=20 > acpi_pcib.cacpi_pcib_acpi.c acpi_pcib_pci.c acpi_pcibvar.h >=20 > Nate Lawson wrote: >=20 > > I need the dmesg output from boot -v to see the link priority=20 > > settings. >=20 > Attached is the "boot -v" output from two separate boots with=20 > a kernel built from sources dated 2004.08.11.21.00.00 (after=20 > your patch with additional debug output). >=20 > The two logs (with "PnP OS installed" set to Yes or No in=20 > BIOS) are pretty similar, so I don't think that setting in=20 > the BIOS makes much difference for your code. >=20 > The next thing to try (I guess) is a kernel without "device=20 > apic". However, my users are a bit upset about the downtime=20 > (already 3 reboots today) so I might have to wait with that=20 > until tomorrow. >=20 > /Daniel Eriksson >=20 I don't believe you have to maintain separate kernels to enable/disable = apic. You can set this in loader.conf via: hint.apic.0.disabled=3D1 For the record, I have to set this on my dell pe2450, pe2550, and = pe1550; otherwise, the machines hang during boot. From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 13:33:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7FC616A4CF; Thu, 12 Aug 2004 13:33:52 +0000 (GMT) Received: from mx1.imp.ch (mx1.imp.ch [157.161.9.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20F2B43D46; Thu, 12 Aug 2004 13:33:52 +0000 (GMT) (envelope-from mb@imp.ch) Received: from mx1.imp.ch (mx.imp.ch [157.161.9.64]) by mx1.imp.ch (8.12.11/8.12.11) with ESMTP id i7CDXkZd083984; Thu, 12 Aug 2004 15:33:47 +0200 (CEST) (envelope-from mb@imp.ch) Received: from mx1.imp.ch (localhost [127.0.0.1]) by mx1.imp.ch (8.12.11/8.12.11/Submit) with ESMTP id i7CDXiNh083948; Thu, 12 Aug 2004 15:33:44 +0200 (CEST) (envelope-from mb@imp.ch) Received: (from clamav@localhost) by mx1.imp.ch (8.12.11/8.12.11/Submit) id i7CDXhQY083932; Thu, 12 Aug 2004 15:33:43 +0200 (CEST) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by ns1.imp.ch (MIMEDefang) with ESMTP id i7CDXdpq056685; Thu, 12 Aug 2004 15:33:43 +0200 (CEST) Date: Thu, 12 Aug 2004 15:33:39 +0200 (CEST) From: Martin Blapp To: Jeff Roberson In-Reply-To: <20040812144448.F31181@cvs.imp.ch> Message-ID: <20040812151731.T31181@cvs.imp.ch> References: <20040811200323.B31181@cvs.imp.ch> <20040812042621.O7322@mail.chesapeake.net> <20040812143133.G31181@cvs.imp.ch> <20040812144448.F31181@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Resent: Yes X-Spam-Checksum: 38f500b94e15884ed40d300dec586fa7 X-Virus-Message-Status: No X-Virus-Status: No, scantime="0.0038 seconds" X-Spam-Status: No, hits=-4.897 required=5 scantime="1.4733 seconds" tests=BAYES_00, FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.44 cc: freebsd-current@freebsd.org cc: Robert Watson Subject: Re: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 13:33:53 -0000 Hi, With the lastest ULE changes, the stress test doesn't run 30 seconds till FreeBSD crashes. Since the machine is spare, I'm still connected to it. I can give you access if you like. Note that this is a new panic message. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x14 fault code = supervisor write, page not present instruction pointer = 0x8:0xc066a1c7 stack pointer = 0x10:0xe2626aa8 frame pointer = 0x10:0xe2626ab8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 27897 (mimedefang) Mimedefang is threaded and uses currently libpthreads (kse). x/x 0xc066a1c7 unp_connect2+0x2a: f144b89 db> where unp_connect2(c4bb78a4,c39cc13c,0,0,0) at unp_connect2+0x2a unp_connect(c4bb78a4,c43d9380,c4dee9a0,c43d9380,80) at unp_connect+0x3d5 uipc_connect(c4bb78a4,c43d9380,c4dee9a0) at uipc_connect+0x76 soconnect(c4bb78a4,c43d9380,c4dee9a0,0,bf1dad88) at soconnect+0x54 kern_connect(c4dee9a0,3,c43d9380,c43d9380,c3e958ac) at kern_connect+0xb0 connect(c4dee9a0,e2626d14,c,c4dee9a0,e2626d3c) at connect+0x42 syscall(2f,2f,2f,bf1dad88,bf1dad8a) at syscall+0x300 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (98, FreeBSD ELF32, connect), eip = 0x28101d23, esp = 0xbf1dad74, ebp = 0xbf1dae10 --- db> show registers cs 0x8 ds 0x10 es 0x10 fs 0x18 ss 0x10 eax 0x2 ecx 0xc3a79ec4 edx 0x29 ebx 0 esp 0xe2626aa8 ebp 0xe2626ab8 esi 0xc39cc13c edi 0xc4bb78a4 eip 0xc066a1c7 unp_connect2+0x2a efl 0x10246 dr0 0 dr1 0 dr2 0 dr3 0 dr4 0xffff0ff0 dr5 0x400 dr6 0xffff0ff0 dr7 0x400 unp_connect2+0x2a: movl %ecx,0x14(%ebx) Martin From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 13:41:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D643F16A4CE; Thu, 12 Aug 2004 13:41:01 +0000 (GMT) Received: from energistic.com (mail.virtual-voodoo.com [65.204.79.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B71B43D48; Thu, 12 Aug 2004 13:41:01 +0000 (GMT) (envelope-from steve@energistic.com) Received: from energistic.com (steve@localhost.virtual-voodoo.com [127.0.0.1]) by energistic.com (8.13.1/8.13.1) with ESMTP id i7CDf0o7052334; Thu, 12 Aug 2004 08:41:00 -0500 (EST) (envelope-from steve@energistic.com) Received: (from steve@localhost) by energistic.com (8.13.1/8.13.1/Submit) id i7CDexxO052034; Thu, 12 Aug 2004 08:40:59 -0500 (EST) (envelope-from steve) Date: Thu, 12 Aug 2004 08:40:59 -0500 From: Steve Ames To: "David O'Brien" , Kris Kennaway , current@FreeBSD.org Message-ID: <20040812134059.GA47431@energistic.com> References: <20040811224504.GA46960@xor.obsecurity.org> <20040812091148.GB57570@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040812091148.GB57570@dragon.nuxi.com> User-Agent: Mutt/1.5.6i Subject: Re: gcc 3.4.2/x.org packages uploaded X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 13:41:01 -0000 On Thu, Aug 12, 2004 at 02:11:48AM -0700, David O'Brien wrote: > On Wed, Aug 11, 2004 at 03:45:04PM -0700, Kris Kennaway wrote: > > I've uploaded a full package set built with gcc 3.4.2 and x.org, > > Thanks! > > Any timeline on updated AMD64 64-bit packages? If there are now packages missing (gatekeeper for instance) its because they didn't compile? -Steve From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 13:44:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A507D16A4CE for ; Thu, 12 Aug 2004 13:44:29 +0000 (GMT) Received: from out005.verizon.net (out005pub.verizon.net [206.46.170.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BE7743D1D for ; Thu, 12 Aug 2004 13:44:29 +0000 (GMT) (envelope-from skip.ford@verizon.net) Received: from pool-70-17-33-167.pskn.east.verizon.net ([70.17.33.167]) by out005.verizon.netESMTP <20040812134428.ZKAE3910.out005.verizon.net@pool-70-17-33-167.pskn.east.verizon.net> for ; Thu, 12 Aug 2004 08:44:28 -0500 Date: Thu, 12 Aug 2004 09:44:22 -0400 From: Skip Ford To: freebsd-current@freebsd.org Message-ID: <20040812134422.GA585@lucy.pool-70-17-33-167.pskn.east.verizon.net> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Authentication-Info: Submitted using SMTP AUTH at out005.verizon.net from [70.17.33.167] at Thu, 12 Aug 2004 08:44:28 -0500 Subject: savecore -z dumps core: linker or libz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 13:44:29 -0000 With sources from 36 hours ago, linking savecore produces: /usr/bin/ld: Warning: size of symbol `compress' changed from 4 in savecore.o to 27 in /usr/lib/libz.a(compress.o) /usr/bin/ld: Warning: type of symbol `compress' changed from 1 to 2 in /usr/lib/libz.a(compress.o) 'savecore -z' dumps core. 's/compress/compress_core//' as included below works around the problem. Index: sbin/savecore/savecore.c =================================================================== RCS file: /cvs/ncvs/src/sbin/savecore/savecore.c,v retrieving revision 1.68 diff -u -r1.68 savecore.c --- sbin/savecore/savecore.c 28 Feb 2004 10:42:27 -0000 1.68 +++ sbin/savecore/savecore.c 12 Aug 2004 13:14:21 -0000 @@ -88,7 +88,7 @@ /* The size of the buffer used for I/O. */ #define BUFFERSIZE (1024*1024) -int checkfor, compress, clear, force, keep, verbose; /* flags */ +int checkfor, compress_core, clear, force, keep, verbose; /* flags */ int nfound, nsaved, nerr; /* statistics */ extern FILE *zopen(const char *, const char *); @@ -347,7 +347,7 @@ goto closefd; } oumask = umask(S_IRWXG|S_IRWXO); /* Restrict access to the core file.*/ - if (compress) { + if (compress_core) { sprintf(buf, "vmcore.%d.gz", bounds); fp = zopen(buf, "w"); } else { @@ -371,7 +371,7 @@ fclose(info); syslog(LOG_NOTICE, "writing %score to %s", - compress ? "compressed " : "", buf); + compress_core ? "compressed " : "", buf); while (dumpsize > 0) { wl = BUFFERSIZE; @@ -387,7 +387,7 @@ nerr++; goto closeall; } - if (compress) { + if (compress_core) { nw = fwrite(buf, 1, wl, fp); } else { for (nw = 0; nw < nr; nw = he) { @@ -515,7 +515,7 @@ force = 1; break; case 'z': - compress = 1; + compress_core = 1; break; case '?': default: -- Skip From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 14:12:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 825EA16A4CE; Thu, 12 Aug 2004 14:12:29 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E5BB43D1D; Thu, 12 Aug 2004 14:12:29 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smtp3.sentex.ca (8.12.11/8.12.11) with ESMTP id i7CECQ8I059847; Thu, 12 Aug 2004 10:12:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7CECSpF065901; Thu, 12 Aug 2004 10:12:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 418A07303F; Thu, 12 Aug 2004 10:12:28 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040812141228.418A07303F@freebsd-current.sentex.ca> Date: Thu, 12 Aug 2004 10:12:28 -0400 (EDT) Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2004 14:12:29 -0000 TB --- 2004-08-12 13:01:34 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-12 13:01:34 - starting CURRENT tinderbox run for i386/pc98 TB --- 2004-08-12 13:01:34 - checking out the source tree TB --- 2004-08-12 13:01:34 - cd /home/tinderbox/sandbox/CURRENT/i386/pc98 TB --- 2004-08-12 13:01:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-12 13:07:29 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-12 13:07:29 - cd /home/tinderbox/sandbox/CURRENT/i386/pc98/src TB --- 2004-08-12 13:07:29 - /usr/bin/make -B buildworld >>> 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 TB --- 2004-08-12 14:11:26 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-12 14:11:26 - cd /home/tinderbox/sandbox/CURRENT/i386/pc98/src TB --- 2004-08-12 14:11:26 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Aug 12 14:11:26 UTC 2004 >>> 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 [...] awk -f /tinderbox/CURRENT/i386/pc98/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/i386/pc98/src/sys/dev/ppbus/ppbus_if.m -h awk -f /tinderbox/CURRENT/i386/pc98/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/i386/pc98/src/sys/isa/isa_if.m -h if [ -f .olddep ]; then mv .olddep .depend; fi rm -f .newdep /home/tinderbox/sandbox/CURRENT/i386/pc98/obj/tinderbox/CURRENT/i386/pc98/src/make.i386/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stac k-boundary=2 -ffreestanding /tinderbox/CURRENT/i386/pc98/src/sys/pccard/pcic.c:51:32: dev/pcic/i82365reg.h: No such file or directory /tinderbox/CURRENT/i386/pc98/src/sys/pccard/pcic_isa.c:43:32: dev/pcic/i82365reg.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2004-08-12 14:12:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-12 14:12:28 - ERROR: failed to build generic kernel TB --- 2004-08-12 14:12:28 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 14:38:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E605416A4CE for ; Thu, 12 Aug 2004 14:38:53 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8053243D41 for ; Thu, 12 Aug 2004 14:38:53 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7CEbCE2055550; Thu, 12 Aug 2004 10:37:12 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7CEbCO0055547; Thu, 12 Aug 2004 10:37:12 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 12 Aug 2004 10:37:12 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Martin Blapp In-Reply-To: <20040812151731.T31181@cvs.imp.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Jeff Roberson cc: freebsd-current@freebsd.org Subject: Re: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 14:38:54 -0000 On Thu, 12 Aug 2004, Martin Blapp wrote: > With the lastest ULE changes, the stress test doesn't run 30 seconds > till FreeBSD crashes. Since the machine is spare, I'm still connected to > it. I can give you access if you like. Note that this is a new panic > message. > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x14 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc066a1c7 > stack pointer = 0x10:0xe2626aa8 > frame pointer = 0x10:0xe2626ab8 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 27897 (mimedefang) Looks like a NULL pointer dereference. Are you running with debug.mpsafenet=1 or the default? > x/x 0xc066a1c7 > unp_connect2+0x2a: f144b89 > > db> where > unp_connect2(c4bb78a4,c39cc13c,0,0,0) at unp_connect2+0x2a > unp_connect(c4bb78a4,c43d9380,c4dee9a0,c43d9380,80) at unp_connect+0x3d5 > uipc_connect(c4bb78a4,c43d9380,c4dee9a0) at uipc_connect+0x76 > soconnect(c4bb78a4,c43d9380,c4dee9a0,0,bf1dad88) at soconnect+0x54 > kern_connect(c4dee9a0,3,c43d9380,c43d9380,c3e958ac) at kern_connect+0xb0 > connect(c4dee9a0,e2626d14,c,c4dee9a0,e2626d3c) at connect+0x42 > syscall(2f,2f,2f,bf1dad88,bf1dad8a) at syscall+0x300 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (98, FreeBSD ELF32, connect), eip = 0x28101d23, esp = 0xbf1dad74, ebp = 0xbf1dae10 --- I'll need you to run gdb on a copy of your kernel with debugging symbols and convert the symbol+offsets into file and line numbers. When I compile a few local kernels, these offsets map to less than meaningful locations, so I'm probably building with somewhat different kernel options. Thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 14:45:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20F1A16A4CF; Thu, 12 Aug 2004 14:45:51 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C586B43D31; Thu, 12 Aug 2004 14:45:50 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7CEiCQL055720; Thu, 12 Aug 2004 10:44:12 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7CEiCCN055717; Thu, 12 Aug 2004 10:44:12 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 12 Aug 2004 10:44:12 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Ruslan Ermilov In-Reply-To: <20040812130917.GC24142@ip.net.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@freebsd.org cc: Chris Stenton cc: FreeBSD Current Subject: Re: bad tcp cksum on outgoing packets X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 14:45:51 -0000 On Thu, 12 Aug 2004, Ruslan Ermilov wrote: > On Thu, Aug 12, 2004 at 12:50:58PM +0100, Chris Stenton wrote: > > I have just been doing some debugging on my 5.2.1 box and noticed that > > outgoing tcp packets on the box are coming up with bad checksums on > > tcpdump. I am using the nge interface. > > > > Here is a sample output. > > > > 12:44:29.458021 0:4:e2:10:60:83 0:c:6e:4e:a0:cc ip 82: > > hawk.gnome.co.uk.ssh > kite.gnome.co.uk.2167: P [bad tcp cksum 9420!] > > 2071:2099(28) ack 753 win 65535 (DF) [tos 0x10] (ttl 64, id 35623, len > > 68, bad cksum 0!) > > > > 12:44:29.642088 0:c:6e:4e:a0:cc 0:4:e2:10:60:83 ip 60: > > kite.gnome.co.uk.2167 > hawk.gnome.co.uk.ssh: . [tcp sum ok] 753:753(0) > > ack 2099 win 64956 (DF) (ttl 128, id 44852, len 40) > > > > > > Any ideas whats going on as the packet does not seem to be resent? > > > You don't have hardware checksums enabled, do you? I barely > recall they are incompatible with bpf(4). They're not incompatible per se, but if you're sniffing outgoing packets and the network interface is calculating the checksum on send, BPF will see a version of the packet before the checksum is calculated. If tcpdump later attempts to verify the checksum, it still won't be calculated in the copy it sees, and will whine. It was unclear to me in the above e-mail if this was a tcpdump of packets on the wire (say, the receiver), or on the sender before they hit the wire. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 14:48:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E057216A4CE; Thu, 12 Aug 2004 14:48:34 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EB1743D2F; Thu, 12 Aug 2004 14:48:34 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7CEmSG3027758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2004 17:48:29 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7CEmVKa072747; Thu, 12 Aug 2004 17:48:31 +0300 (EEST) (envelope-from ru) Date: Thu, 12 Aug 2004 17:47:10 +0300 From: Ruslan Ermilov To: Robert Watson Message-ID: <20040812144710.GA72404@ip.net.ua> References: <20040812130917.GC24142@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: net@freebsd.org cc: Chris Stenton cc: FreeBSD Current Subject: Re: bad tcp cksum on outgoing packets X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 14:48:35 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 12, 2004 at 10:44:12AM -0400, Robert Watson wrote: >=20 > On Thu, 12 Aug 2004, Ruslan Ermilov wrote: >=20 > > On Thu, Aug 12, 2004 at 12:50:58PM +0100, Chris Stenton wrote: > > > I have just been doing some debugging on my 5.2.1 box and noticed that > > > outgoing tcp packets on the box are coming up with bad checksums on > > > tcpdump. I am using the nge interface. > > >=20 > > > Here is a sample output. > > >=20 > > > 12:44:29.458021 0:4:e2:10:60:83 0:c:6e:4e:a0:cc ip 82: > > > hawk.gnome.co.uk.ssh > kite.gnome.co.uk.2167: P [bad tcp cksum 9420!] > > > 2071:2099(28) ack 753 win 65535 (DF) [tos 0x10] (ttl 64, id 35623, l= en > > > 68, bad cksum 0!) > > >=20 > > > 12:44:29.642088 0:c:6e:4e:a0:cc 0:4:e2:10:60:83 ip 60: > > > kite.gnome.co.uk.2167 > hawk.gnome.co.uk.ssh: . [tcp sum ok] 753:753(= 0) > > > ack 2099 win 64956 (DF) (ttl 128, id 44852, len 40) > > >=20 > > >=20 > > > Any ideas whats going on as the packet does not seem to be resent? > > >=20 > > You don't have hardware checksums enabled, do you? I barely > > recall they are incompatible with bpf(4). >=20 > They're not incompatible per se, but if you're sniffing outgoing packets > and the network interface is calculating the checksum on send, BPF will > see a version of the packet before the checksum is calculated. If tcpdump > later attempts to verify the checksum, it still won't be calculated in the > copy it sees, and will whine. It was unclear to me in the above e-mail if > this was a tcpdump of packets on the wire (say, the receiver), or on the > sender before they hit the wire. >=20 That's what I meant exactly. Thanks for clarifying my thoughts. ;) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBG4LuqRfpzJluFF4RAn3aAJ9oicqVISg6gPjUf/3SIYDAcJ+MVQCfcczt ugfTVw+VylL/3OYDKTbjHIQ= =Ehy7 -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 15:21:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8217B16A4CE for ; Thu, 12 Aug 2004 15:21:11 +0000 (GMT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CC9F43D31 for ; Thu, 12 Aug 2004 15:21:11 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i7CFL6SD016550; Thu, 12 Aug 2004 11:21:07 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <411AA203.1020502@elischer.org> References: <411AA203.1020502@elischer.org> Date: Thu, 12 Aug 2004 11:21:05 -0400 To: Julian Elischer , current@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: [Fwd: RFC.. defining __rangeof() in cdefs.h] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 15:21:11 -0000 At 3:47 PM -0700 8/11/04, Julian Elischer wrote: >Interresting.. not a single comment.. :-/ > >I'm considering adding: >Index: sys/cdefs.h >=================================================================== >RCS file: /home/ncvs/src/sys/sys/cdefs.h,v >retrieving revision 1.83 >diff -u -r1.83 cdefs.h >--- sys/cdefs.h 28 Jul 2004 07:03:42 -0000 1.83 >+++ sys/cdefs.h 9 Aug 2004 21:36:41 -0000 >@@ -241,6 +241,8 @@ > * require it. > */ >#define __offsetof(type, field) ((size_t)(&((type *)0)->field)) >+#define __rangeof(type, start, end) \ >+ (__offsetof(type, end) - __offsetof(type, start)) > >/* > * Compiler-dependent macros to declare that functions take printf-like > > >it is used in several places. most importantly in fork1() > >and it is defined in several files (*).. we should probably just >have one copy... I was going to look to see what this did and how it was used, but if it is already defined in several files than I figured there probably wasn't anything seriously wrong with it. I will admit that the term "rangeof" brings a different function to my mind, but I have a feeling everyone's nerves are on edge (with the code-freeze coming up), so I didn't want to make too much of a big deal about it. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 15:44:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADC1C16A4CE; Thu, 12 Aug 2004 15:44:17 +0000 (GMT) Received: from mail.imp.ch (ns1.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B180F43D2F; Thu, 12 Aug 2004 15:44:16 +0000 (GMT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.9p2/8.12.3) with ESMTP id i7CFi8pq089642; Thu, 12 Aug 2004 17:44:10 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Thu, 12 Aug 2004 17:44:08 +0200 (CEST) From: Martin Blapp To: freebsd-current@freebsd.org, Robert Watson Message-ID: <20040812174229.G31181@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checksum: eb4643e0f056813875d3ce56d5d1a8c1 X-Virus-Message-Status: No X-Virus-Status: No, scantime="0.0021 seconds" X-Spam-Status: No, hits=-4.9 required=5 scantime="3.8901 seconds" tests=BAYES_00 X-Scanned-By: MIMEDefang 2.44 Subject: Re: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 15:44:17 -0000 Here is more information: (thanks robert for the help) > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x14 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc066a1c7 > stack pointer = 0x10:0xe2626aa8 > frame pointer = 0x10:0xe2626ab8 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 27897 (mimedefang) > db> where unp_connect2(c4bb78a4,c39cc13c,0,0,0) at /usr/src/sys/kern/uipc_usrreq.c:892 unp_connect(c4bb78a4,c43d9380,c4dee9a0,c43d9380,80) at /usr/src/sys/kern/uipc_usrreq.c:865 uipc_connect(c4bb78a4,c43d9380,c4dee9a0) at /usr/src/sys/kern/uipc_usrreq.c:179 soconnect(c4bb78a4,c43d9380,c4dee9a0,0,bf1dad88) at /usr/src/sys/kern/uipc_socket.c:518 kern_connect(c4dee9a0,3,c43d9380,c43d9380,c3e958ac) at /usr/src/sys/kern/uipc_syscalls.c:477 connect(c4dee9a0,e2626d14,c,c4dee9a0,e2626d3c) at connect+0x42 syscall(2f,2f,2f,bf1dad88,bf1dad8a) at syscall+0x300 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (98, FreeBSD ELF32, connect), eip = 0x28101d23, esp = 0xbf1dad74, ebp = 0xbf1dae10 --- src/sys/kern/uipc_syscalls.c,v 1.199 src/sys/kern/uipc_usrreq.c,v 1.135 src/sys/kern/uipc_socket.c,v 1.207 (gdb) l *unp_connect2+0x2a 0x1f93 is in unp_connect2 (/usr/src/sys/kern/uipc_usrreq.c:892). 887 UNP_LOCK_ASSERT(); 888 889 if (so2->so_type != so->so_type) 890 return (EPROTOTYPE); 891 unp2 = sotounpcb(so2); 892 unp->unp_conn = unp2; 893 switch (so->so_type) { 894 895 case SOCK_DGRAM: 896 LIST_INSERT_HEAD(&unp2->unp_refs, unp, unp_reflink); (gdb) l *unp_connect+0x3d5 0x1e24 is in unp_connect (/usr/src/sys/kern/uipc_usrreq.c:865). 860 SOCK_UNLOCK(so); 861 #endif 862 863 so2 = so3; 864 } 865 error = unp_connect2(so, so2); 866 bad2: 867 UNP_UNLOCK(); 868 mtx_lock(&Giant); 869 bad: (gdb) l *uipc_connect+0x76 0x2dd is in uipc_connect (/usr/src/sys/kern/uipc_usrreq.c:179). 174 KASSERT(td == curthread, ("uipc_connect: td != curthread")); 175 176 if (unp == NULL) 177 return (EINVAL); 178 UNP_LOCK(); 179 error = unp_connect(so, nam, td); 180 UNP_UNLOCK(); 181 return (error); 182 } 183 (gdb) l *soconnect+0x54 0x100f is in soconnect (/usr/src/sys/kern/uipc_socket.c:518). 513 (error = sodisconnect(so)))) 514 error = EISCONN; 515 else 516 error = (*so->so_proto->pr_usrreqs->pru_connect)(so, nam, td); 517 return (error); 518 } 519 520 int 521 soconnect2(so1, so2) 522 struct socket *so1; (gdb) l *kern_connect+0xb 0xd5e is in kern_connect (/usr/src/sys/kern/uipc_syscalls.c:477). 472 int 473 kern_connect(td, fd, sa) 474 struct thread *td; 475 int fd; 476 struct sockaddr *sa; 477 { 478 struct socket *so; 479 int error, s; 480 int interrupted = 0; 481 From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 16:25:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDDFD16A4CE; Thu, 12 Aug 2004 16:25:48 +0000 (GMT) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 810FE43D31; Thu, 12 Aug 2004 16:25:48 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.11/8.12.11) with ESMTP id i7CGPlBc038849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2004 09:25:47 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.11/8.12.11/Submit) id i7CGPlcc007407; Thu, 12 Aug 2004 09:25:47 -0700 (PDT) (envelope-from jdp) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20040811101206.M99067@carver.gumbysoft.com> Date: Thu, 12 Aug 2004 09:25:47 -0700 (PDT) From: John Polstra To: Doug White X-Bogosity: No, tests=bogofilter, spamicity=0.094462, version=0.14.5 cc: freebsd-current@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: cvsup on amd64 just broke today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 16:25:49 -0000 On 11-Aug-2004 Doug White wrote: > Checking the commit logs, I don't think Peter ever committed the patches > to make ezm3 work under amd64 native. The port on amd64 just downloads > the same binary you were using .. the i386 version and an extra library. > ezm3 builds the runtime libs needed to compile Modula-3 apps. > > Interestingly, jdp just touched that port. I guess he doesn't have peter's > patches, or hasn't adapted them for the distro yet. There is a lot of brokenness in those patches, as Peter will be the first to admit. They're really not ready to be committed at this point. David O'Brien has done a lot of work on this, but there's still nothing ready to commit. John From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 16:39:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A48A16A4CE for ; Thu, 12 Aug 2004 16:39:51 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC79C43D31 for ; Thu, 12 Aug 2004 16:39:50 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7CGcBOX058087 for ; Thu, 12 Aug 2004 12:38:11 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7CGcBsY058084 for ; Thu, 12 Aug 2004 12:38:11 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 12 Aug 2004 12:38:11 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: panic fails to reset properly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 16:39:51 -0000 I've been working with Martin to try to debug a crash he's experiencing, and observed he's having a problem I've also observed. "reset" from ddb will generally reset without a hitch. "panic" will usually hang after dumping; what's interesting is that on a system without dump support, "panic" will still hang. Has anyone looked into this? The failure of the automatic reboot at that point is making it a bit more difficult to debug problems effectively, as well as reducing the ability of the system to recover following a panic. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 16:58:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8514016A4CE for ; Thu, 12 Aug 2004 16:58:13 +0000 (GMT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BD8243D4C for ; Thu, 12 Aug 2004 16:58:13 +0000 (GMT) (envelope-from faber@ISI.EDU) Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i7CGqTJ09311; Thu, 12 Aug 2004 09:52:29 -0700 (PDT) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.12.11/8.12.11) with ESMTP id i7CGqStY072239; Thu, 12 Aug 2004 09:52:28 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.12.11/8.12.11/Submit) id i7CGqSmC072238; Thu, 12 Aug 2004 09:52:28 -0700 (PDT) (envelope-from faber) Date: Thu, 12 Aug 2004 09:52:28 -0700 From: Ted Faber To: "M. Warner Losh" Message-ID: <20040812165228.GA71823@pun.isi.edu> References: <20040811164508.74419.qmail@web41104.mail.yahoo.com> <20040812.001443.32983963.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline In-Reply-To: <20040812.001443.32983963.imp@bsdimp.com> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: faber@isi.edu cc: current@freebsd.org cc: jmkatcher@yahoo.com Subject: Re: Can someone please commit a sane module path in loader.conf? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 16:58:13 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Aug 12, 2004 at 12:14:43AM -0600, M. Warner Losh wrote: > In message: <20040811164508.74419.qmail@web41104.mail.yahoo.com> > Jeffrey Katcher writes: > : I know I can override it in my local loader.conf, but the change to > : /boot/modules only was _really_ annoying and unexpected. FYI, it should be > : /boot/kernel for most people. > > >From UPDATING: > > 20040806: > Module loading has been fixed. Some older installations will > drop proper module_path initalization and modules will fail to > load properly. If you have a line in /boot/loader.rc that says: > "initialize drop", do (i386 only): > cp /usr/src/sys/boot/i386/loader/loader.rc /boot/loader.rc > chown root:wheel /boot/loader.rc > chmod 444 /boot/loader.rc Thanks. Boy a HEADSUP letting people know that it was fixed would have been strongly appreciated. I was affected and I've been CVSupping and rebuilding regularly and hadn't seen the fix until after I saw the curt - read UPDATING message. At that point my UPDATING still didn't have the message above despite the fact that I'd been updating once or twice a day since Monday. I know it only affected a minority, but busted kernel module loading is a big deal. Just a minor venting. Thanks for all the good work. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBG6BMaUz3f+Zf+XsRAly7AJ9dzSRYq3zL8aoLzGGPz0airmNwXgCfQnqk cflX9BlFChhn5tXbKCEY7RM= =pAKL -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 17:00:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D010416A4CE for ; Thu, 12 Aug 2004 17:00:58 +0000 (GMT) Received: from hotmail.com (bay8-f44.bay8.hotmail.com [64.4.27.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEBF343D39 for ; Thu, 12 Aug 2004 17:00:58 +0000 (GMT) (envelope-from evantd@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 12 Aug 2004 10:00:58 -0700 Received: from 67.171.32.75 by by8fd.bay8.hotmail.msn.com with HTTP; Thu, 12 Aug 2004 17:00:58 GMT X-Originating-IP: [67.171.32.75] X-Originating-Email: [evantd@hotmail.com] X-Sender: evantd@hotmail.com From: "Evan Dower" To: db@nipsi.de Date: Thu, 12 Aug 2004 10:00:58 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Aug 2004 17:00:58.0643 (UTC) FILETIME=[F0791E30:01C4808D] cc: freebsd-current@freebsd.org Subject: Re: Project Evil: TI ACX111 non-success X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 17:00:59 -0000 With ndis do you get the same "init handler failed" error message? Have you emailed Bill Paul with all the appropriate info? What have you tried? What were the results? -- Evan Dower Undergraduate, Computer Science University of Washington Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D >From: Dennis Berger >To: Evan Dower >CC: freebsd-current@freebsd.org >Subject: Re: Project Evil: TI ACX111 non-success >Date: Thu, 12 Aug 2004 09:56:15 +0200 > >I have the dlink g650+ which also has the acx111 chipset... >NDIS failed acx driver failed also. >regards, >-Dennis > >On Wed, Aug 11, 2004 at 04:40:58PM -0700, Evan Dower wrote: > > I've been trying to get the ndisulator to work for my NetGear WG311v2 so >I > > can take the ethernet cables and switches offthe floor in my hall. The > > following is the "conversation" I've had with Bill Paul. It is perhaps >best > > to read from the bottom up to get the chronology right. Also, as it >turns > > out the net/acx100 port makes no claim to support the acx111, and I was > > eventually able to build and load it, though of course it didn't work > > because it doesn't support the acx111. Any help would be greatly > > appreciated. > > > > -- > > > > I managed to get rid of the "can't re-use a leaf" messaged by deleting > > the duplicate entry in ndis_driver_data.h. For some reason, whenever I > > try to load if_ndis.ko (ndis.ko is already loaded), I get messages about > > amdpm. Perhaps ndis returning 6 and failing to load is a result of the > > same return value from trying to attach amdpm. > > > > amdpm0: port > > 0xe4e0-0xe4ff at device 7.3 on pci0 > > amdpm0: could not map i/o space > > device_attach: amdpm0 attach returned 6 > > ndis0: mem > > 0xf0800000-0xf081ffff,0xf1000000-0xf1001fff irq 17 at device 6.0 on pci2 > > ndis0: [GIANT-LOCKED] > > no match for srand > > ndis0: NDIS API version: 5.1 > > ndis0: init handler failed > > device_attach: ndis0 attach returned 6 > > > > Thanks again, > > Evan Dower > > > > El mar, 20-07-2004 a las 10:58, Evan Dower escribi?: > > >I have figured out that the "can't re-use a leaf" message is coming >from > > >trying to register a sysctl, which comes from the .inf file. This seems > > >to indicate some limitations on the complexity of .inf files that can >be > > >properly parsed and turned into a list of sysctls. Since I'm not >exactly > > >sure what those limitations are, I'm sending you a link to the .inf >file > > >(and the .sys file for good measure)? Other than that, it looks like > > >srand might just need to be plugged into one of the function tables > > >(probably the hal table, I guess). Also, if you can tell me what > > >limitations exist for the .inf file, I will gladly modify it to work >and > > >make it available to other WG311v2 owners. > > >Thanks again, > > >Evan Dower > > >Note: Much of the .inf file (anything not for XP) is commented out in >an > > >attempt to make things work. This was my doing. It didn't ship that >way. > > >Since I don't really understand the Windows registry, I didn't get too > > >adventurous. > > > > > >Files at: http://students.washington.edu/evantd/pub/evil/ > > > > > >El lun, 12-07-2004 a las 16:05, Evan Dower escribi?: > > >> I have a Netgear WG311v2. The v2 turns out to be very important as >the > > >> original (v1 you might call it now) was based on an Atheros AR5212 >and > > >> was thus supported by the ath driver. v2 is based on the the TI >AXC111 > > >> (aka TNETW1130), which should be supported by the net/acx100 port, >but > > >> if_acx.ko fails to load due to a missing __panic symbol. Following >the > > >> instructions you posted in an email, I made ndis_driver_data.h and > > >> built and loaded the if_ndis.ko module (after loading ndis.ko or > > >> compiling it into the kernel). I used the Windows XP .SYS and .INF > > >> files, though the Windows 2000 versions gave the same result, the > > >> Windows 98 files produced a module that panicked on load, and I >didn't > > >> try the Windows ME files. The following is the output from `make > > >> load`. > > >> > /sbin/kldload -v /usr/current/src/sys/modules/if_ndis/if_ndis.ko > > >> ndis0: mem > > >> 0xec800000-0xec81ffff, > > >> 0xed000000-0xed001fff irq 17 at device 6.0 on pci2 > > >> ndis0: [GIANT-LOCKED] > > >> can't re-use a leaf (dot11DesiredBSSType)! > > >> no match for srand > > >> ndis0: NDIS API version: 5.1 > > >> ndis0: init handler failed > > >> device_attach: ndis0 attach returned 6 > > >> Loaded /usr/current/src/sys/modules/if_ndis/if_ndis.ko, id=11 > > >> > Loading the module does not create /dev/ndis0 or /dev/if_ndis0 (or > > >> anything of the sort). I am running today's -CURRENT. > > >> > It seems that it requires srand, and I assume the 'can't re-use a >leaf > > >> (dot11DesiredBSSType)!' is also a show-stopper. I ordered my card >from > > >> newegg.com for about $50. > > >> > If there is anything else you might be interested in (a verbose >boot > > >> log, copies of the .SYS and .INF files, testing for patches, etc.), > > >> just let me know. I'd be happy to help (especially since the result >is > > >> a working wireless connection). > > >> > Thanks very much, > > > > -- > > Evan Dower > > Undergraduate, Computer Science > > University of Washington > > Public key: http://students.washington.edu/evantd/pgp-pub-key.txt > > Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D > > > > _________________________________________________________________ > > Don?t just search. Find. Check out the new MSN Search! > > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > > > _______________________________________________ > > 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" _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 17:09:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCBD916A4CE; Thu, 12 Aug 2004 17:09:16 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83B5A43D39; Thu, 12 Aug 2004 17:09:16 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i7CH98H8020875; Thu, 12 Aug 2004 10:09:12 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200408121709.i7CH98H8020875@gw.catspoiler.org> Date: Thu, 12 Aug 2004 10:09:08 -0700 (PDT) From: Don Lewis To: mb@imp.ch In-Reply-To: <20040812174229.G31181@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org cc: rwatson@FreeBSD.org Subject: Re: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 17:09:16 -0000 On 12 Aug, Martin Blapp wrote: > > > Here is more information: (thanks robert for the help) > >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 01 >> fault virtual address = 0x14 >> fault code = supervisor write, page not present >> instruction pointer = 0x8:0xc066a1c7 >> stack pointer = 0x10:0xe2626aa8 >> frame pointer = 0x10:0xe2626ab8 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 27897 (mimedefang) >> > > db> where > unp_connect2(c4bb78a4,c39cc13c,0,0,0) at /usr/src/sys/kern/uipc_usrreq.c:892 > unp_connect(c4bb78a4,c43d9380,c4dee9a0,c43d9380,80) at /usr/src/sys/kern/uipc_usrreq.c:865 > uipc_connect(c4bb78a4,c43d9380,c4dee9a0) at /usr/src/sys/kern/uipc_usrreq.c:179 > soconnect(c4bb78a4,c43d9380,c4dee9a0,0,bf1dad88) at /usr/src/sys/kern/uipc_socket.c:518 > kern_connect(c4dee9a0,3,c43d9380,c43d9380,c3e958ac) at /usr/src/sys/kern/uipc_syscalls.c:477 > connect(c4dee9a0,e2626d14,c,c4dee9a0,e2626d3c) at connect+0x42 > syscall(2f,2f,2f,bf1dad88,bf1dad8a) at syscall+0x300 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (98, FreeBSD ELF32, connect), eip = 0x28101d23, esp = 0xbf1dad74, ebp = 0xbf1dae10 --- > > src/sys/kern/uipc_syscalls.c,v 1.199 > src/sys/kern/uipc_usrreq.c,v 1.135 > src/sys/kern/uipc_socket.c,v 1.207 > > (gdb) l *unp_connect2+0x2a > 0x1f93 is in unp_connect2 (/usr/src/sys/kern/uipc_usrreq.c:892). > 887 UNP_LOCK_ASSERT(); > 888 > 889 if (so2->so_type != so->so_type) > 890 return (EPROTOTYPE); > 891 unp2 = sotounpcb(so2); > 892 unp->unp_conn = unp2; > 893 switch (so->so_type) { > 894 > 895 case SOCK_DGRAM: > 896 LIST_INSERT_HEAD(&unp2->unp_refs, unp, unp_reflink); Looks like unp is NULL here. My first suspicion would be the recent memory allocation changes that affected the type safety of various dynamically allocated data structures, though I'm not sure that fits the symptoms. From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 17:11:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFC0516A4CE for ; Thu, 12 Aug 2004 17:11:45 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2A1243D45 for ; Thu, 12 Aug 2004 17:11:45 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7CHBi8U028489; Thu, 12 Aug 2004 10:11:44 -0700 Message-ID: <411BA4D0.4080904@root.org> Date: Thu, 12 Aug 2004 10:11:44 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Robin P. Blanchard" , leafy7382@gmail.com References: <9B5C1FCAFB35084787C21EFFFA78DD9E612D6D@EBE1.gc.nat> In-Reply-To: <9B5C1FCAFB35084787C21EFFFA78DD9E612D6D@EBE1.gc.nat> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: HEADSUP: new pci irq routing committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 17:11:46 -0000 Robin P. Blanchard wrote: > Unforunately, your latest commits are still yielding interrupt storms and > acpi complaints...dmesg attached. Ok, I just committed some code that should fix both of your problems. It handles an edge case for DPFs. Thanks for all the testing. -Nate From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 17:13:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E08A16A4CE for ; Thu, 12 Aug 2004 17:13:07 +0000 (GMT) Received: from web20226.mail.yahoo.com (web20226.mail.yahoo.com [216.136.227.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 5169743D31 for ; Thu, 12 Aug 2004 17:13:07 +0000 (GMT) (envelope-from tonymontanadea@yahoo.com) Message-ID: <20040812171307.37174.qmail@web20226.mail.yahoo.com> Received: from [68.36.189.179] by web20226.mail.yahoo.com via HTTP; Thu, 12 Aug 2004 10:13:07 PDT Date: Thu, 12 Aug 2004 10:13:07 -0700 (PDT) From: Tony Montana To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Firewire disabled in kernel by default? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 17:13:07 -0000 I cant install 5.x on my laptop. I boot from cd and get thru the options with no problems, but when i have to select my media it says NO CD/DVD DRIVES PRESENT. I have 4.10 installed with no problems now but would love to clean install to 5.2.1 or 5.3 once its out to take advantage of the apm and acpi. My laptop connects to a media base thru firewire which is where the cd/dvd drive is, so im wondering if its a driver thing since its fine in 4.x. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 17:17:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EA4316A4CE; Thu, 12 Aug 2004 17:17:59 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D3C443D1D; Thu, 12 Aug 2004 17:17:59 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7CHGJRu059094; Thu, 12 Aug 2004 13:16:19 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7CHGJEh059091; Thu, 12 Aug 2004 13:16:19 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 12 Aug 2004 13:16:19 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Don Lewis In-Reply-To: <200408121709.i7CH98H8020875@gw.catspoiler.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@FreeBSD.org cc: mb@imp.ch Subject: Re: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 17:17:59 -0000 On Thu, 12 Aug 2004, Don Lewis wrote: > > (gdb) l *unp_connect2+0x2a > > 0x1f93 is in unp_connect2 (/usr/src/sys/kern/uipc_usrreq.c:892). > > 887 UNP_LOCK_ASSERT(); > > 888 > > 889 if (so2->so_type != so->so_type) > > 890 return (EPROTOTYPE); > > 891 unp2 = sotounpcb(so2); > > 892 unp->unp_conn = unp2; > > 893 switch (so->so_type) { > > 894 > > 895 case SOCK_DGRAM: > > 896 LIST_INSERT_HEAD(&unp2->unp_refs, unp, unp_reflink); > > Looks like unp is NULL here. > > My first suspicion would be the recent memory allocation changes that > affected the type safety of various dynamically allocated data > structures, though I'm not sure that fits the symptoms. Hmm. I thought unix domain sockets weren't affected by those changes, but could be wrong. However, it does look like a null pointer dereference, and in particular, a possible race between two threads accessesing either the same end or opposite ends of a unix domain socket. Martin's dropping a core dump, kernel, and source tree for me to look at. Some early debugging shows that the unix domain socket is a datagram oriented socket, and that the SS_NOFDREF flag is set in so->so_state, suggesting maybe we have a race between connect() and close() in the application. However, I need to sit down with the core for a bit. I would have expected a more likely race to be between two unix domain socket endpoints, since most applications don't mess up with file descriptors, I would think. In any case, more details soon. I'm guessing the race was present previously, but the move to ADAPTIVE_GIANT has caused it to trigger more frequently on Martin's system. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 17:21:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67DF616A4CF for ; Thu, 12 Aug 2004 17:21:11 +0000 (GMT) Received: from av3-1-sn3.vrr.skanova.net (av3-1-sn3.vrr.skanova.net [81.228.9.109]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC9DC43D2F for ; Thu, 12 Aug 2004 17:21:09 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av3-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 1EB803810E; Thu, 12 Aug 2004 19:21:09 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id E8A2337E62; Thu, 12 Aug 2004 19:21:08 +0200 (CEST) Received: from gadget (h130n1fls11o822.telia.com [213.64.66.130]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 9389238008; Thu, 12 Aug 2004 19:21:06 +0200 (CEST) From: "Daniel Eriksson" To: Date: Thu, 12 Aug 2004 19:21:03 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000B_01C480A1.8339F4C0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSAkL5GmtmWhetjRLKmFU1KtfXvFw== cc: =?iso-8859-1?Q?'S=F8ren_Schmidt'?= cc: 'Nate Lawson' Subject: More ATA interrupt(?) oddities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 17:21:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C480A1.8339F4C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sometime during the last 3 weeks, something has changed in the kernel that makes one of my servers barf when hit with lots of I/O on multiple filesystems (like when starting "fsck" on all the filesystems). This used to work in the past, but I have unfortunately not run this stress-test in the last 3 weeks despite upgrading the kernel multiple times (I know, regression testing is your friend, I'll be more careful in the future). The problem predates the last major commit to the ACPI subsystem, so it might not be related to that. But since it seems to be related to resources handled by ACPI, I also CC:ed Nate on this. Attached is the kernel config, the output of "acpidump -t -d" and a file containing the "boot -v" output. The "boot -v" file also contains a log of the failure plus some additional info ("vmstat -i", "atacontrol list", "shutdown -r now"). System: ------- ASUS A7V600-X (VIA KT600 based) mobo, Athlon XP2500+ CPU, 1.25GB DDR RAM Tons of discs hooked up to the onboard UDMA133 controller, the onboard SATA controller, two HighPoint RocketRAID454 controllers and an Adaptec 29160 controller. 5-CURRENT built from sources dated 2004.08.12.13.30.00 (no CFLAGS/COPTFLAGS, but I use "CPUTYPE?=athlon-xp" in make.conf) The discs are used either as single discs, striped ataraid arrays, striped gvinum arrays or mirrored gvinum arrays. The problem: ------------ * With only /, /usr, /tmp and /var mounted running in multi-user mode, I start multiple concurrent "fsck -f -t ffs /dev/somefilesystem" on the other 12 filesystems. * Almost immediately the server starts to spit out timeout errors like this: ad5: TIMEOUT - READ_DMA retrying (2 retries left) LBA=22858569 * The bootlog_plus_info.txt contains a more detailed log of the errors (it keeps resetting the ATA controller). More info: ---------- * Twice I have let the fsck processes continue despite the errors, and after about a minute the machine locked up hard (nothing on the console, no ddb). * If I abort the fsck processes, the machine seems to continue to work properly. * If I run fsck on the filesystem one after another, I get no errors at all. * It does not seem to be related to SATA, since it happens whether or not I run fsck on the SATA disc (I unhooked the second SATA disc because I've had major problems with the machine when both are connected). * I've tried this with and without "device apic" in the kernel config - it seems to make no difference. * A kernel from 2004.08.09.13.00.00 shows the same symptoms, so the bug was introduced before that date. * I will try to build a few more kernels from even older sources to see if I can more closely pinpoint the date when it was introduced. This might however take a few days. /Daniel Eriksson ------=_NextPart_000_000B_01C480A1.8339F4C0 Content-Type: text/plain; name="bootlog_plus_info.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="bootlog_plus_info.txt" OK boot -v -s /boot/kernel/acpi.ko text=3D0x46f88 data=3D0x1a84+0xd2c = syms=3D[0x4+0x6f80+0x4+0x910e] KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=3D01 base=3D0000000000000000 len=3D000000000009d000 SMAP type=3D02 base=3D000000000009d000 len=3D0000000000003000 SMAP type=3D02 base=3D00000000000f0000 len=3D0000000000010000 SMAP type=3D01 base=3D0000000000100000 len=3D000000004fefb000 SMAP type=3D03 base=3D000000004fffb000 len=3D0000000000004000 SMAP type=3D04 base=3D000000004ffff000 len=3D0000000000001000 SMAP type=3D02 base=3D00000000fec00000 len=3D0000000000001000 SMAP type=3D02 base=3D00000000fee00000 len=3D0000000000001000 SMAP type=3D02 base=3D00000000ffff0000 len=3D0000000000010000 Copyright (c) 1992-2004 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 5.2-CURRENT #0: Thu Aug 12 17:01:40 CEST 2004 daniel@...:/usr/obj/usr/src/sys/FORTIFY Preloaded elf kernel "/boot/kernel/kernel" at 0xc08b0000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc08b0254. Calibrating clock(s) ... i8254 clock: 1193206 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1999781618 Hz CPU: AMD Athlon(TM) XP 2500+ (1999.78-MHz 686-class CPU) Origin =3D "AuthenticAMD" Id =3D 0x6a0 Stepping =3D 0 = Features=3D0x383fbff AMD Features=3D0xc0400000 Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way = associative L2 internal cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 8-way = associative real memory =3D 1342156800 (1279 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009cfff, 638976 bytes (156 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c26000 - 0x000000004e94afff, 1305628672 bytes (318757 pages) avail memory =3D 1305075712 (1244 MB) Table 'FACP' at 0x4fffb0b2 Table 'BOOT' at 0x4fffb030 Table 'APIC' at 0x4fffb058 MADT: Found table at 0x4fffb058 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled ACPI APIC Table: bios32: Found BIOS32 Service Directory header at 0xc00f2000 bios32: Entry =3D 0xf1940 (c00f1940) Rev =3D 0 Len =3D 1 pcibios: PCI BIOS entry at 0xf0000+0x1970 pnpbios: Found PnP BIOS data at 0xc00f9cb0 pnpbios: Entry =3D f0000:9ce0 Rev =3D 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: intr override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: active-high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00040010 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff mem: Pentium Pro MTRR support enabled null: io: random: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [GIANT-LOCKED] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000060 pci_open(1a): mode1res=3D0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=3D060000] [hdr=3D00] is there = (id=3D31891106) pcibios: BIOS version 2.10 Found $PIR table, 11 entries at 0xc00f1f20 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs slot 1 0 12 A 0x05 3 4 5 7 9 10 11 12 slot 1 0 12 B 0x01 3 4 5 7 9 10 11 12 slot 1 0 12 C 0x02 3 4 5 7 9 10 11 12 slot 1 0 12 D 0x03 3 4 5 7 9 10 11 12 slot 2 0 13 A 0x01 3 4 5 7 9 10 11 12 slot 2 0 13 B 0x02 3 4 5 7 9 10 11 12 slot 2 0 13 C 0x03 3 4 5 7 9 10 11 12 slot 2 0 13 D 0x05 3 4 5 7 9 10 11 12 slot 3 0 14 A 0x02 3 4 5 7 9 10 11 12 slot 3 0 14 B 0x03 3 4 5 7 9 10 11 12 slot 3 0 14 C 0x05 3 4 5 7 9 10 11 12 slot 3 0 14 D 0x01 3 4 5 7 9 10 11 12 slot 4 0 19 A 0x03 3 4 5 7 9 10 11 12 slot 4 0 19 B 0x05 3 4 5 7 9 10 11 12 slot 4 0 19 C 0x01 3 4 5 7 9 10 11 12 slot 4 0 19 D 0x02 3 4 5 7 9 10 11 12 slot 5 0 11 A 0x05 3 4 5 7 9 10 11 12 slot 5 0 11 B 0x01 3 4 5 7 9 10 11 12 slot 5 0 11 C 0x02 3 4 5 7 9 10 11 12 slot 5 0 11 D 0x03 3 4 5 7 9 10 11 12 slot 6 0 10 A 0x01 3 4 5 7 9 10 11 12 slot 6 0 10 B 0x02 3 4 5 7 9 10 11 12 slot 6 0 10 C 0x03 3 4 5 7 9 10 11 12 slot 6 0 10 D 0x05 3 4 5 7 9 10 11 12 slot 7 1 0 A 0x01 3 4 5 7 9 10 11 12 slot 7 1 0 B 0x02 3 4 5 7 9 10 11 12 embedded 0 15 A 0x06 3 4 5 7 9 10 11 12 embedded 0 15 B 0x07 3 4 5 7 9 10 11 12 embedded 0 16 A 0x06 3 4 5 7 9 10 11 12 embedded 0 16 B 0x07 3 4 5 7 9 10 11 12 embedded 0 16 C 0x08 3 4 5 7 9 10 11 12 embedded 0 16 D 0x09 3 4 5 7 9 10 11 12 embedded 0 17 C 0x08 3 4 5 7 9 10 11 12 embedded 0 17 D 0x09 3 4 5 7 9 10 11 12 embedded 0 18 A 0x06 3 4 5 7 9 10 11 12 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 17 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 17 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 15 func 0 acpi0: Power Button (fixed) acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 18 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 2 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 3 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 4 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 16 func 5 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 ACPI timer looks GOOD min =3D 1, max =3D 2, width =3D 1 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 unknown: not probed (disabled) unknown: not probed (disabled) cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: pci0: on pcib0 pci0: physical bus=3D0 map[10]: type 3, range 32, base f8000000, size 26, enabled found-> vendor=3D0x1106, dev=3D0x3189, revid=3D0x80 bus=3D0, slot=3D0, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x2230, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) powerspec 2 supports D0 D3 current D0 found-> vendor=3D0x1106, dev=3D0xb198, revid=3D0x00 bus=3D0, slot=3D1, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x2230, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x08 (2000 ns), maxlat=3D0x00 = (0 ns) map[10]: type 4, range 32, base 0000d800, size 3, enabled map[14]: type 4, range 32, base 0000d400, size 2, enabled map[18]: type 4, range 32, base 0000d000, size 3, enabled map[1c]: type 4, range 32, base 0000b800, size 2, enabled map[20]: type 4, range 32, base 0000b400, size 8, enabled pcib0: matched entry for 0.10.INTA (src (unknown)) pcib0: slot 10 INTA hardwired to IRQ 16 found-> vendor=3D0x1103, dev=3D0x0008, revid=3D0x07 bus=3D0, slot=3D10, func=3D0 class=3D01-04-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0230, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x08 (2000 ns), = maxlat=3D0x08 (2000 ns) intpin=3Da, irq=3D16 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000b000, size 3, enabled map[14]: type 4, range 32, base 0000a800, size 2, enabled map[18]: type 4, range 32, base 0000a400, size 3, enabled map[1c]: type 4, range 32, base 0000a000, size 2, enabled map[20]: type 4, range 32, base 00009800, size 8, enabled pcib0: matched entry for 0.10.INTA (src (unknown)) pcib0: slot 10 INTA hardwired to IRQ 16 found-> vendor=3D0x1103, dev=3D0x0008, revid=3D0x07 bus=3D0, slot=3D10, func=3D1 class=3D01-04-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0230, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x08 (2000 ns), = maxlat=3D0x08 (2000 ns) intpin=3Da, irq=3D16 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00009400, size 8, enabled map[14]: type 1, range 64, base ed800000, size 12, enabled pcib0: matched entry for 0.12.INTA (src (unknown)) pcib0: slot 12 INTA hardwired to IRQ 19 found-> vendor=3D0x9005, dev=3D0x0080, revid=3D0x02 bus=3D0, slot=3D12, func=3D0 class=3D01-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0017, statreg=3D0x02b0, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x28 (10000 ns), = maxlat=3D0x19 (6250 ns) intpin=3Da, irq=3D19 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00009000, size 3, enabled map[14]: type 4, range 32, base 00008800, size 2, enabled map[18]: type 4, range 32, base 00008400, size 3, enabled map[1c]: type 4, range 32, base 00008000, size 2, enabled map[20]: type 4, range 32, base 00007800, size 8, enabled pcib0: matched entry for 0.14.INTA (src (unknown)) pcib0: slot 14 INTA hardwired to IRQ 17 found-> vendor=3D0x1103, dev=3D0x0008, revid=3D0x07 bus=3D0, slot=3D14, func=3D0 class=3D01-04-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0230, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x08 (2000 ns), = maxlat=3D0x08 (2000 ns) intpin=3Da, irq=3D17 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00007400, size 3, enabled map[14]: type 4, range 32, base 00007000, size 2, enabled map[18]: type 4, range 32, base 00006800, size 3, enabled map[1c]: type 4, range 32, base 00006400, size 2, enabled map[20]: type 4, range 32, base 00006000, size 8, enabled pcib0: matched entry for 0.14.INTA (src (unknown)) pcib0: slot 14 INTA hardwired to IRQ 17 found-> vendor=3D0x1103, dev=3D0x0008, revid=3D0x07 bus=3D0, slot=3D14, func=3D1 class=3D01-04-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0230, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x08 (2000 ns), = maxlat=3D0x08 (2000 ns) intpin=3Da, irq=3D17 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00005800, size 3, enabled map[14]: type 4, range 32, base 00005400, size 2, enabled map[18]: type 4, range 32, base 00005000, size 3, enabled map[1c]: type 4, range 32, base 00004800, size 2, enabled map[20]: type 4, range 32, base 00004400, size 4, enabled map[24]: type 4, range 32, base 00004000, size 8, enabled pcib0: matched entry for 0.15.INTB (src (unknown)) pcib0: slot 15 INTB hardwired to IRQ 20 found-> vendor=3D0x1106, dev=3D0x3149, revid=3D0x80 bus=3D0, slot=3D15, func=3D0 class=3D01-04-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Db, irq=3D20 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 00003800, size 4, enabled pcib0: matched entry for 0.15.INTA (src (unknown)) pcib0: slot 15 INTA hardwired to IRQ 20 found-> vendor=3D0x1106, dev=3D0x0571, revid=3D0x06 bus=3D0, slot=3D15, func=3D1 class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Da, irq=3D20 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 00003400, size 5, enabled pcib0: matched entry for 0.16.INTA (src (unknown)) pcib0: slot 16 INTA hardwired to IRQ 21 found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0x81 bus=3D0, slot=3D16, func=3D0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0017, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Da, irq=3D21 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 00003000, size 5, enabled pcib0: matched entry for 0.16.INTA (src (unknown)) pcib0: slot 16 INTA hardwired to IRQ 21 found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0x81 bus=3D0, slot=3D16, func=3D1 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0017, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Da, irq=3D21 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 00002800, size 5, enabled pcib0: matched entry for 0.16.INTB (src (unknown)) pcib0: slot 16 INTB hardwired to IRQ 21 found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0x81 bus=3D0, slot=3D16, func=3D2 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0017, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Db, irq=3D21 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 00002400, size 5, enabled pcib0: matched entry for 0.16.INTB (src (unknown)) pcib0: slot 16 INTB hardwired to IRQ 21 found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0x81 bus=3D0, slot=3D16, func=3D3 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0017, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Db, irq=3D21 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base ed000000, size 8, enabled pcib0: matched entry for 0.16.INTC (src (unknown)) pcib0: slot 16 INTC hardwired to IRQ 21 found-> vendor=3D0x1106, dev=3D0x3104, revid=3D0x86 bus=3D0, slot=3D16, func=3D4 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0017, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) intpin=3Dc, irq=3D21 powerspec 2 supports D0 D1 D2 D3 current D0 found-> vendor=3D0x1106, dev=3D0x3227, revid=3D0x00 bus=3D0, slot=3D17, func=3D0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0087, statreg=3D0x0210, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 00002000, size 8, enabled map[14]: type 1, range 32, base ec800000, size 8, enabled pcib0: matched entry for 0.18.INTA (src (unknown)) pcib0: slot 18 INTA hardwired to IRQ 23 found-> vendor=3D0x1106, dev=3D0x3065, revid=3D0x78 bus=3D0, slot=3D18, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0097, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x03 (750 ns), maxlat=3D0x08 = (2000 ns) intpin=3Da, irq=3D23 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 00001800, size 8, enabled map[14]: type 1, range 32, base ec000000, size 8, enabled pcib0: matched entry for 0.19.INTA (src (unknown)) pcib0: slot 19 INTA hardwired to IRQ 18 found-> vendor=3D0x10ec, dev=3D0x8169, revid=3D0x10 bus=3D0, slot=3D19, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0017, statreg=3D0x02b0, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x20 (8000 ns), maxlat=3D0x40 = (16000 ns) intpin=3Da, irq=3D18 powerspec 2 supports D0 D1 D2 D3 current D0 agp0: mem = 0xf8000000-0xfbffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xf8000000 agp0: allocating GATT for aperture of size 240M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xdfff pcib1: memory decode 0xee000000-0xefdfffff pcib1: prefetched decode 0xeff00000-0xf7ffffff ACPI PCI link initial configuration: pci1: on pcib1 pci1: physical bus=3D1 map[10]: type 1, range 32, base ee000000, size 24, enabled pcib1: device (null) requested decoded memory range = 0xee000000-0xeeffffff map[14]: type 3, range 32, base f0000000, size 27, enabled pcib1: device (null) requested decoded memory range = 0xf0000000-0xf7ffffff pcib1: matched entry for 1.0.INTA (src (unknown)) pcib1: slot 0 INTA hardwired to IRQ 16 found-> vendor=3D0x10de, dev=3D0x0150, revid=3D0xa3 bus=3D1, slot=3D0, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x02b0, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x05 (1250 ns), = maxlat=3D0x01 (250 ns) intpin=3Da, irq=3D16 powerspec 1 supports D0 D3 current D0 pci1: at device 0.0 (no driver attached) atapci0: port = 0xb400-0xb4ff,0xb800-0xb803,0xd000-0xd007,0xd400-0xd403,0xd800-0xd807 = irq 16 at device 10.0 on pci0 atapci0: Reserved 0x100 bytes for rid 0x20 type 4 at 0xb400 atapci0: [MPSAFE] ata2: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xd800 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xd400 ata2: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata2-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata2-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata2: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata2: [MPSAFE] ata3: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xd000 atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb800 ata3: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata3-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata3-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata3: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata3: [MPSAFE] atapci1: port = 0x9800-0x98ff,0xa000-0xa003,0xa400-0xa407,0xa800-0xa803,0xb000-0xb007 = irq 16 at device 10.1 on pci0 atapci1: Reserved 0x100 bytes for rid 0x20 type 4 at 0x9800 atapci1: [MPSAFE] ata4: channel #0 on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xb000 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xa800 ata4: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata4-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata4-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata4: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata4: [MPSAFE] ata5: channel #1 on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xa400 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xa000 ata5: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata5-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata5-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata5: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata5: [MPSAFE] ahc0: port 0x9400-0x94ff mem = 0xed800000-0xed800fff irq 19 at device 12.0 on pci0 ahc0: Defaulting to MEMIO on ahc0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xed800000 ahc0: Reading SEEPROM...done. ahc0: BIOS eeprom is present ahc0: Secondary High byte termination Enabled ahc0: Secondary Low byte termination Enabled ahc0: Primary Low Byte termination Enabled ahc0: Primary High Byte termination Enabled ahc0: Downloading Sequencer Program... 423 instructions downloaded ahc0: Features 0x1def6, Bugs 0x40, Flags 0x20485560 ahc0: [GIANT-LOCKED] aic7892: Ultra160 Wide Channel A, SCSI Id=3D7, 32/253 SCBs atapci2: port = 0x7800-0x78ff,0x8000-0x8003,0x8400-0x8407,0x8800-0x8803,0x9000-0x9007 = irq 17 at device 14.0 on pci0 atapci2: Reserved 0x100 bytes for rid 0x20 type 4 at 0x7800 atapci2: [MPSAFE] ata6: channel #0 on atapci2 atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9000 atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0x8800 ata6: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata6-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata6-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata6: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata6: [MPSAFE] ata7: channel #1 on atapci2 atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0x8400 atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0x8000 ata7: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata7-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata7-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata7: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata7: [MPSAFE] atapci3: port = 0x6000-0x60ff,0x6400-0x6403,0x6800-0x6807,0x7000-0x7003,0x7400-0x7407 = irq 17 at device 14.1 on pci0 atapci3: Reserved 0x100 bytes for rid 0x20 type 4 at 0x6000 atapci3: [MPSAFE] ata8: channel #0 on atapci3 atapci3: Reserved 0x8 bytes for rid 0x10 type 4 at 0x7400 atapci3: Reserved 0x4 bytes for rid 0x14 type 4 at 0x7000 ata8: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D01 ata8-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata8-slave: stat=3D0x01 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata8: reset tp2 stat0=3D50 stat1=3D01 devices=3D0x1 ata8: [MPSAFE] ata9: channel #1 on atapci3 atapci3: Reserved 0x8 bytes for rid 0x18 type 4 at 0x6800 atapci3: Reserved 0x4 bytes for rid 0x1c type 4 at 0x6400 ata9: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 ata9-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata9-slave: stat=3D0x00 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata9: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 ata9: [MPSAFE] atapci4: port = 0x4000-0x40ff,0x4400-0x440f,0x4800-0x4803,0x5000-0x5007,0x5400-0x5403,0x5= 800-0x5807 irq 20 at device 15.0 on pci0 atapci4: Reserved 0x10 bytes for rid 0x20 type 4 at 0x4400 atapci4: [MPSAFE] ata10: channel #0 on atapci4 atapci4: Reserved 0x8 bytes for rid 0x10 type 4 at 0x5800 atapci4: Reserved 0x4 bytes for rid 0x14 type 4 at 0x5400 ata10: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D7f ata10-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata10: reset tp2 stat0=3D50 stat1=3Dff devices=3D0x1 ata10: [MPSAFE] ata11: channel #1 on atapci4 atapci4: Reserved 0x8 bytes for rid 0x18 type 4 at 0x5000 atapci4: Reserved 0x4 bytes for rid 0x1c type 4 at 0x4800 ata11: reset tp1 mask=3D03 ostat0=3D7f ostat1=3D7f ata11-master: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-master: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-master: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-master: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-master: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-master: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-master: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-master: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11-slave: stat=3D0x7f err=3D0xff lsb=3D0xff msb=3D0xff ata11: reset tp2 stat0=3Dff stat1=3Dff devices=3D0x0 ata11: [MPSAFE] atapci5: port = 0x3800-0x380f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 20 at device 15.1 = on pci0 atapci5: Reserved 0x10 bytes for rid 0x20 type 4 at 0x3800 ata0: channel #0 on atapci5 atapci5: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci5: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata0-master: stat=3D0x90 err=3D0x90 lsb=3D0x90 msb=3D0x90 ata0-master: stat=3D0x90 err=3D0x90 lsb=3D0x90 msb=3D0x90 ata0-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata0: [MPSAFE] ata1: channel #1 on atapci5 atapci5: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci5: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata1-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata1-slave: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata1: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata1: [MPSAFE] uhci0: port 0x3400-0x341f irq 21 at device = 16.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3400 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x3000-0x301f irq 21 at device = 16.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3000 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x2800-0x281f irq 21 at device = 16.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2800 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x2400-0x241f irq 21 at device = 16.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2400 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xed000000-0xed0000ff irq 21 = at device 16.4 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xed000000 ehci0: [GIANT-LOCKED] ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 ehci_pci_attach: companion usb3 usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 vr0: port 0x2000-0x20ff mem = 0xec800000-0xec8000ff irq 23 at device 18.0 on pci0 vr0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x2000 miibus0: on vr0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: bpf attached vr0: Ethernet address: 00:0e:a6:1f:29:1e vr0: [GIANT-LOCKED] re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x1800 re0: port 0x1800-0x18ff mem = 0xec000000-0xec0000ff irq 18 at device 19.0 on pci0 miibus1: on re0 rgephy0: on miibus1 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, = 1000baseTX-FDX, auto re0: bpf attached re0: Ethernet address: 00:50:fc:f8:c6:81 re0: [GIANT-LOCKED] fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on = acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 unknown: not probed (disabled) unknown: not probed (disabled) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0xc041 0xc041 0xc041 0xc041 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console unknown: not probed (disabled) unknown: not probed (disabled) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x1d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it sio: sio0 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcafff on isa0 pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x100> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0xc041 0xc041 0xc041 0xc041 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 54 80=20 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 54 80=20 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 54 80=20 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 1999781618 Hz quality 800 Timecounters tick every 1.000 msec DUMMYNET initialized (011031) ipfw2 initialized, divert enabled, rule-based forwarding enabled, = default to accept, logging unlimited lo0: bpf attached ata0-slave: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ata0-master: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ata0-master: setting PIO4 on VIA 8237 chip ata0-master: setting UDMA100 on VIA 8237 chip ata0-slave: setting PIO4 on VIA 8237 chip ata0-slave: setting UDMA100 on VIA 8237 chip ad0: ATA-6 disk at ata0-master ad0: 114473MB (234441648 sectors), 232581 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA100 GEOM: new disk ad0 ar: FreeBSD check1 failed [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:234436482 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 32256 length 120031478784 end 120031511039 ad1: ATA-6 disk at ata0-slave ad1: 114473MB (234441648 sectors), 232581 C, 16 H, 63 S, 512 B ad1: 16 secs/int, 1 depth queue, UDMA100 ar: FreeBSD check1 failed GEOM: Configure ad0s1a, start 0 length 536870912 end 536870911 GEOM: Configure ad0s1b, start 536870912 length 536870912 end 1073741823 GEOM: Configure ad0s1c, start 0 length 120031478784 end 120031478783 GEOM: Configure ad0s1d, start 1073741824 length 536870912 end 1610612735 GEOM: Configure ad0s1e, start 1610612736 length 536870912 end 2147483647 GEOM: Configure ad0s1f, start 2147483648 length 10737418240 end = 12884901887 GEOM: Configure ad0s1g, start 12884901888 length 107146576896 end = 120031478783 GEOM: new disk ad1 ata1-slave: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ata1-master: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ata1-master: setting PIO4 on VIA 8237 chip ata1-master: setting UDMA100 on VIA 8237 chip ata1-slave: setting PIO4 on VIA 8237 chip ata1-slave: setting UDMA100 on VIA 8237 chip ad2: ATA-6 disk at ata1-master ad2: 117800MB (241254720 sectors), 239340 C, 16 H, 63 S, 512 B ad2: 16 secs/int, 1 depth queue, UDMA100 ar: FreeBSD check1 failed ad3: ATA-6 disk at ata1-slave ad3: 117800MB (241254720 sectors), 239340 C, 16 H, 63 S, 512 B ad3: 16 secs/int, 1 depth queue, UDMA100 ar: FreeBSD check1 failed ata2-slave: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ata2-master: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ata2-master: setting PIO4 on HighPoint chip [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:234436482 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad1s1, start 32256 length 120031478784 end 120031511039 ata2-master: setting UDMA100 on HighPoint chip GEOM: new disk ad2 GEOM: new disk ad3 ata2-slave: setting PIO4 on HighPoint chip GEOM: Configure ad1s1b, start 536870912 length 536870912 end 1073741823 GEOM: Configure ad1s1c, start 0 length 120031478784 end 120031478783 GEOM: Configure ad1s1d, start 0 length 536870912 end 536870911 GEOM: Configure ad1s1e, start 1073741824 length 536870912 end 1610612735 GEOM: Configure ad1s1f, start 1610612736 length 536870912 end 2147483647 GEOM: Configure ad1s1g, start 2147483648 length 10737418240 end = 12884901887 GEOM: Configure ad1s1h, start 12884901888 length 107146576896 end = 120031478783 ata2-slave: setting UDMA100 on HighPoint chip ad4: ATA-6 disk at ata2-master ad4: 238475MB (488397168 sectors), 484521 C, 16 H, 63 S, 512 B ad4: 16 secs/int, 1 depth queue, UDMA100 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:241248042 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad2s1, start 32256 length 123518997504 end 123519029759 ad5: ATA-6 disk at ata2-slave ad5: 238475MB (488397168 sectors), 484521 C, 16 H, 63 S, 512 B ad5: 16 secs/int, 1 depth queue, UDMA100 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:241248042 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad3s1, start 32256 length 123518997504 end 123519029759 ata3-slave: pio=3D0x0c wdma=3D0x22 udma=3D0x46 cable=3D80pin ata3-master: pio=3D0x0c wdma=3D0x22 udma=3D0x46 cable=3D80pin ata3-master: setting PIO4 on HighPoint chip ata3-master: setting UDMA133 on HighPoint chip ata3-slave: setting PIO4 on HighPoint chip ata3-slave: setting UDMA133 on HighPoint chip ad6: ATA-7 disk at ata3-master ad6: 239372MB (490234752 sectors), 486344 C, 16 H, 63 S, 512 B ad6: 16 secs/int, 1 depth queue, UDMA133 ad7: ATA-7 disk at ata3-slave ad7: 239372MB (490234752 sectors), 486344 C, 16 H, 63 S, 512 B ad7: 16 secs/int, 1 depth queue, UDMA133 ata4-slave: pio=3D0x0c wdma=3D0x22 udma=3D0x46 cable=3D80pin GEOM: new disk ad4 ata4-master: pio=3D0x0c wdma=3D0x22 udma=3D0x46 cable=3D80pin GEOM: Configure ad2s1c, start 0 length 123518997504 end 123518997503 GEOM: Configure ad2s1e, start 0 length 123518997504 end 123518997503 GEOM: new disk ad5 ata4-master: setting PIO4 on HighPoint chip GEOM: Configure ad3s1c, start 0 length 123518997504 end 123518997503 GEOM: Configure ad3s1e, start 0 length 123518997504 end 123518997503 GEOM: new disk ad6 GEOM: new disk ad7 ata4-master: setting UDMA133 on HighPoint chip [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:976784067 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad4s1, start 32256 length 500113442304 end 500113474559 ata4-slave: setting PIO4 on HighPoint chip ata4-slave: setting UDMA133 on HighPoint chip ad8: ATA-7 disk at ata4-master ad8: 194481MB (398297088 sectors), 395136 C, 16 H, 63 S, 512 B ad8: 16 secs/int, 1 depth queue, UDMA133 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/14/63 s:63 l:488392002 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad5s1, start 32256 length 250056705024 end 250056737279 ad9: ATA-7 disk at ata4-slave ad9: 194481MB (398297088 sectors), 395136 C, 16 H, 63 S, 512 B ad9: 16 secs/int, 1 depth queue, UDMA133 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:980462952 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad6s1, start 32256 length 501997031424 end 501997063679 ata5-slave: pio=3D0x0c wdma=3D0x22 udma=3D0x46 cable=3D80pin ata5-master: pio=3D0x0c wdma=3D0x22 udma=3D0x46 cable=3D80pin GEOM: Configure ad4s1c, start 0 length 500113442304 end 500113442303 GEOM: Configure ad4s1d, start 0 length 500113442304 end 500113442303 GEOM: new disk ad8 ata5-master: setting PIO4 on HighPoint chip ata5-master: setting UDMA133 on HighPoint chip GEOM: new disk ad9 ata5-slave: setting PIO4 on HighPoint chip GEOM: Configure ad6s1c, start 0 length 501997031424 end 501997031423 GEOM: Configure ad6s1d, start 0 length 501997031424 end 501997031423 ata5-slave: setting UDMA133 on HighPoint chip [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/7/63 s:63 l:398283417 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad8s1, start 32256 length 203921109504 end 203921141759 ad10: ATA-7 disk at ata5-master ad10: 194481MB (398297088 sectors), 395136 C, 16 H, 63 S, 512 B ad10: 16 secs/int, 1 depth queue, UDMA133 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:796582962 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad9s1, start 32256 length 407850476544 end 407850508799 ar: HighPoint check1 failed ad11: ATA-7 disk at ata5-slave ad11: 239372MB (490234752 sectors), 486344 C, 16 H, 63 S, 512 B ad11: 16 secs/int, 1 depth queue, UDMA133 GEOM: Configure ad8s1c, start 0 length 203921109504 end 203921109503 GEOM: Configure ad8s1d, start 0 length 203921109504 end 203921109503 GEOM: new disk ad10 ar: HighPoint check1 failed GEOM: Configure ad9s1c, start 0 length 407850476544 end 407850476543 GEOM: Configure ad9s1d, start 0 length 407850476544 end 407850476543 GEOM: new disk ad11 ata6-slave: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/7/63 s:63 l:398283417 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad10s1, start 32256 length 203921109504 end 203921141759 ata6-master: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ata6-master: setting PIO4 on HighPoint chip ata6-master: setting UDMA100 on HighPoint chip [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:490223412 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad11s1, start 32256 length 250994386944 end 250994419199 ata6-slave: setting PIO4 on HighPoint chip ata6-slave: setting UDMA100 on HighPoint chip GEOM: Configure ad10s1c, start 0 length 203921109504 end 203921109503 GEOM: Configure ad10s1d, start 0 length 203921109504 end 203921109503 GEOM: Configure ad11s1c, start 0 length 250994386944 end 250994386943 GEOM: Configure ad11s1d, start 0 length 250994386944 end 250994386943 ad12: ATA-6 disk at ata6-master ad12: 117800MB (241254720 sectors), 239340 C, 16 H, 63 S, 512 B ad12: 16 secs/int, 1 depth queue, UDMA100 GEOM: new disk ad12 ar: HighPoint check1 failed [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:241248042 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad12s1, start 32256 length 123518997504 end 123519029759 ad13: ATA-6 disk at ata6-slave ad13: 117800MB (241254720 sectors), 239340 C, 16 H, 63 S, 512 B ad13: 16 secs/int, 1 depth queue, UDMA100 ar: HighPoint check1 failed GEOM: Configure ad12s1c, start 0 length 123518997504 end 123518997503 GEOM: Configure ad12s1e, start 0 length 123518997504 end 123518997503 GEOM: new disk ad13 ata7-slave: pio=3D0x0c wdma=3D0x22 udma=3D0x46 cable=3D80pin [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:241248042 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad13s1, start 32256 length 123518997504 end 123519029759 ata7-master: pio=3D0x0c wdma=3D0x22 udma=3D0x46 cable=3D80pin ata7-master: setting PIO4 on HighPoint chip ata7-master: setting UDMA133 on HighPoint chip GEOM: Configure ad13s1c, start 0 length 123518997504 end 123518997503 GEOM: Configure ad13s1e, start 0 length 123518997504 end 123518997503 ata7-slave: setting PIO4 on HighPoint chip ata7-slave: setting UDMA133 on HighPoint chip ad14: ATA-7 disk at ata7-master ad14: 117246MB (240121728 sectors), 238216 C, 16 H, 63 S, 512 B ad14: 16 secs/int, 1 depth queue, UDMA133 GEOM: new disk ad14 ar: HighPoint check1 failed [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:240107427 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad14s1, start 32256 length 122935002624 end 122935034879 ad15: ATA-7 disk at ata7-slave ad15: 117246MB (240121728 sectors), 238216 C, 16 H, 63 S, 512 B ad15: 16 secs/int, 1 depth queue, UDMA133 GEOM: Configure ad14s1c, start 0 length 122935002624 end 122935002623 GEOM: Configure ad14s1e, start 0 length 122935002624 end 122935002623 GEOM: new disk ad15 ata8-master: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:468873027 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad15s1, start 32256 length 240062989824 end 240063022079 ata8-master: setting PIO4 on HighPoint chip GEOM: Configure ad15s1c, start 0 length 240062989824 end 240062989823 GEOM: Configure ad15s1d, start 0 length 240062989824 end 240062989823 ata8-master: setting UDMA100 on HighPoint chip ad16: ATA-6 disk at ata8-master ad16: 114473MB (234441648 sectors), 232581 C, 16 H, 63 S, 512 B ad16: 16 secs/int, 1 depth queue, UDMA100 GEOM: new disk ad16 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:234436482 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad16s1, start 32256 length 120031478784 end 120031511039 ata9-master: pio=3D0x0c wdma=3D0x22 udma=3D0x44 cable=3D80pin ata9-master: setting PIO4 on HighPoint chip ata9-master: setting UDMA66 on HighPoint chip ad18: ATA-5 disk at ata9-master ad18: 26059MB (53369568 sectors), 52946 C, 16 H, 63 S, 512 B ad18: 16 secs/int, 1 depth queue, UDMA66 GEOM: new disk ad18 ar: HighPoint check1 failed [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:53367867 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad18s1, start 32256 length 27324347904 end 27324380159 ata10-master: pio=3D0x0c wdma=3D0x22 udma=3D0x46 cable=3D40pin GEOM: Configure ad18s1c, start 0 length 27324347904 end 27324347903 GEOM: Configure ad18s1d, start 0 length 27324347904 end 27324347903 ad20: ATA-7 disk at ata10-master ad20: 239372MB (490234752 sectors), 486344 C, 16 H, 63 S, 512 B ad20: 16 secs/int, 1 depth queue, UDMA133 GEOM: new disk ad20 ar: FreeBSD check1 failed lun 0 magic_0 0x4100e31a magic_1 0x00000000 flags 0x40102 40102 total_disks 2 generation 0 width 2 heads 255 sectors 63 cylinders 60802 total_sectors 976794336 interleave 128 reserved 10 offset 10 disk 0: flags =3D 0x0b b ad4 sectors 488397168 disk 1: flags =3D 0x0b b ad5 sectors 488397168 ar0: 476950MB [60802/255/63] status: READY subdisks: disk0 READY on ad4 at ata2-master disk1 READY on ad5 at ata2-slave lun 1 magic_0 0x4100e31f magic_1 0x00000000 flags 0x40102 40102 total_disks 2 generation 0 width 2 heads 255 sectors 63 cylinders 61031 total_sectors 980469504 interleave 128 reserved 10 offset 10 disk 0: flags =3D 0x0b b ad6 sectors 490234752 disk 1: flags =3D 0x0b b ad7 sectors 490234752 ar1: 478744MB [61031/255/63] status: READY subdisks: disk0 READY on ad6 at ata3-master disk1 READY on ad7 at ata3-slave lun 2 magic_0 0x4100e40c magic_1 0x00000000 flags 0x40102 40102 total_disks 2 generation 0 width 2 heads 255 sectors 63 cylinders 49585 total_sectors 796594176 interleave 128 reserved 10 offset 10 disk 0: flags =3D 0x0b b ad9 sectors 398297088 disk 1: flags =3D 0x0b b ad8 sectors 398297088 ar2: 388962MB [49585/255/63] status: READY subdisks: disk0 READY on ad9 at ata4-slave disk1 READY on ad8 at ata4-master lun 3 magic_0 0x4100e468 magic_1 0x00000000 flags 0x40102 40102 total_disks 2 generation 0 width 2 heads 255 sectors 63 cylinders 29186 total_sectors 468883296 interleave 128 reserved 10 offset 10 disk 0: flags =3D 0x0b b ad15 sectors 234441648 disk 1: flags =3D 0x0b b ad16 sectors 234441648 ar3: 228946MB [29186/255/63] status: READY subdisks: disk0 READY on ad15 at ata7-slave disk1 READY on ad16 at ata8-master Waiting 5 seconds for SCSI devices to settle (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:490223412 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad20s1, start 32256 length 250994386944 end 250994419199 GEOM: new disk ar0 GEOM: new disk ar1 GEOM: new disk ar2 GEOM: new disk ar3 GEOM: Configure ad20s1c, start 0 length 250994386944 end 250994386943 GEOM: Configure ad20s1d, start 0 length 250994386944 end 250994386943 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:976784067 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ar0s1, start 32256 length 500113442304 end 500113474559 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:980462952 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ar1s1, start 32256 length 501997031424 end 501997063679 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:796582962 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ar2s1, start 32256 length 407850476544 end 407850508799 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:468873027 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ar3s1, start 32256 length 240062989824 end 240063022079 GEOM: Configure ar0s1c, start 0 length 500113442304 end 500113442303 GEOM: Configure ar0s1d, start 0 length 500113442304 end 500113442303 GEOM: Configure ar1s1c, start 0 length 501997031424 end 501997031423 GEOM: Configure ar1s1d, start 0 length 501997031424 end 501997031423 GEOM: Configure ar2s1c, start 0 length 407850476544 end 407850476543 GEOM: Configure ar2s1d, start 0 length 407850476544 end 407850476543 GEOM: Configure ar3s1c, start 0 length 240062989824 end 240062989823 GEOM: Configure ar3s1d, start 0 length 240062989824 end 240062989823 ahc0: Selection Timeout on A:0. 0 SCBs aborted ahc0: Selection Timeout on A:4. 0 SCBs aborted ahc0: Selection Timeout on A:8. 0 SCBs aborted ahc0: Selection Timeout on A:15. 0 SCBs aborted ahc0: Selection Timeout on A:1. 0 SCBs aborted ahc0: Selection Timeout on A:2. 0 SCBs aborted ahc0: Selection Timeout on A:9. 0 SCBs aborted ahc0: Selection Timeout on A:3. 0 SCBs aborted ahc0: Selection Timeout on A:6. 0 SCBs aborted ahc0: Selection Timeout on A:14. 0 SCBs aborted (ahc0:A:5:0): Sending SDTR period c, offset 7f (ahc0:A:5:0): Received SDTR period 19, offset f Filtered to period 19, offset f ahc0: target 5 synchronous at 10.0MHz, offset =3D 0xf (probe9:ahc0:0:10:0): Retrying Command (ahc0:A:5:0): Sending SDTR period 19, offset f (probe11:ahc0:0:12:0): Retrying Command (probe12:ahc0:0:13:0): Retrying Command (probe10:ahc0:0:11:0): Retrying Command (ahc0:A:5:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:10:0): Sending PPR bus_width 1, period 9, offset 7f, ppr_options = 2 (ahc0:A:10:0): Received PPR width 1, period 9, offset 3f,options 2 Filtered to width 1, period 9, offset 3f, options 2 ahc0: target 10 using 16bit transfers ahc0: target 10 synchronous at 80.0MHz DT, offset =3D 0x3f (ahc0:A:12:0): Sending PPR bus_width 1, period 9, offset 7f, ppr_options = 2 (ahc0:A:12:0): Received PPR width 1, period 9, offset 3f,options 2 Filtered to width 1, period 9, offset 3f, options 2 ahc0: target 12 using 16bit transfers ahc0: target 12 synchronous at 80.0MHz DT, offset =3D 0x3f (ahc0:A:13:0): Sending PPR bus_width 1, period 9, offset 7f, ppr_options = 2 (ahc0:A:13:0): Received PPR width 1, period 9, offset 3f,options 2 Filtered to width 1, period 9, offset 3f, options 2 ahc0: target 13 using 16bit transfers ahc0: target 13 synchronous at 80.0MHz DT, offset =3D 0x3f (ahc0:A:11:0): Sending PPR bus_width 1, period 9, offset 7f, ppr_options = 2 (ahc0:A:11:0): Received PPR width 1, period 9, offset 3f,options 2 Filtered to width 1, period 9, offset 3f, options 2 ahc0: target 11 using 16bit transfers ahc0: target 11 synchronous at 80.0MHz DT, offset =3D 0x3f pass0 at ahc0 bus 0 target 5 lun 0 pass0: Removable Sequential Access SCSI-2 = device=20 pass0: Serial Number=20 pass0: 10.000MB/s transfers (10.000MHz, offset 15) pass1 at ahc0 bus 0 target 10 lun 0 pass1: Fixed Direct Access SCSI-3 device=20 pass1: Serial Number TFF8Y198 pass1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged = Queueing Enabled pass2 at ahc0 bus 0 target 11 lun 0 pass2: Fixed Direct Access SCSI-3 device=20 pass2: Serial Number VM9B1477 pass2: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged = Queueing Enabled pass3 at ahc0 bus 0 target 12 lun 0 pass3: Fixed Direct Access SCSI-3 device=20 pass3: Serial Number TFF8X930 pass3: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged = Queueing Enabled pass4 at ahc0 bus 0 target 13 lun 0 pass4: Fixed Direct Access SCSI-3 device=20 pass4: Serial Number VFLA9712 pass4: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged = Queueing Enabled sa0 at ahc0 bus 0 target 5 lun 0 sa0: Removable Sequential Access SCSI-2 device=20 sa0: Serial Number=20 sa0: 10.000MB/s transfers (10.000MHz, offset 15) da0 at ahc0 bus 0 target 10 lun 0 da0: Fixed Direct Access SCSI-3 device=20 da0: Serial Number TFF8Y198 da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged = Queueing Enabled da0: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) da1 at ahc0 bus 0 target 11 lun 0 da1: Fixed Direct Access SCSI-3 device=20 da1: Serial Number VM9B1477 da1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged = Queueing Enabled da1: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) da2 at ahc0 bus 0 target 12 lun 0 da2: Fixed Direct Access SCSI-3 device=20 da2: Serial Number TFF8X930 da2: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged = Queueing Enabled da2: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) da3 at ahc0 bus 0 target 13 lun 0 da3: Fixed Direct Access SCSI-3 device=20 da3: Serial Number VFLA9712 da3: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged = Queueing Enabled da3: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) GEOM: new disk da0 GEOM: new disk da1 GEOM: new disk da2 GEOM: new disk da3 ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 2 (ISA IRQ 0) to cluster 0 ioapic0: routing intpin 4 (ISA IRQ 4) to cluster 0 ioapic0: routing intpin 6 (ISA IRQ 6) to cluster 0 ioapic0: routing intpin 8 (ISA IRQ 8) to cluster 0 ioapic0: routing intpin 9 (ISA IRQ 9) to cluster 0 ioapic0: routing intpin 13 (ISA IRQ 13) to cluster 0 ioapic0: routing intpin 14 (ISA IRQ 14) to cluster 0 ioapic0: routing intpin 15 (ISA IRQ 15) to cluster 0 ioapic0: routing intpin 16 (PCI IRQ 16) to cluster 0 ioapic0: routing intpin 17 (PCI IRQ 17) to cluster 0 ioapic0: routing intpin 18 (PCI IRQ 18) to cluster 0 ioapic0: routing intpin 19 (PCI IRQ 19) to cluster 0 ioapic0: routing intpin 20 (PCI IRQ 20) to cluster 0 ioapic0: routing intpin 21 (PCI IRQ 21) to cluster 0 ioapic0: routing intpin 23 (PCI IRQ 23) to cluster 0 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:71681967 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure da0s1, start 32256 length 36701167104 end 36701199359 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:71681967 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure da1s1, start 32256 length 36701167104 end 36701199359 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:71681967 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure da2s1, start 32256 length 36701167104 end 36701199359 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:71681967 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure da3s1, start 32256 length 36701167104 end 36701199359 GEOM: Configure da0s1c, start 0 length 36701167104 end 36701167103 GEOM: Configure da0s1d, start 0 length 36701167104 end 36701167103 GEOM: Configure da1s1c, start 0 length 36701167104 end 36701167103 GEOM: Configure da1s1d, start 0 length 36701167104 end 36701167103 GEOM: Configure da2s1c, start 0 length 36701167104 end 36701167103 GEOM: Configure da2s1d, start 0 length 36701167104 end 36701167103 GEOM: Configure da3s1c, start 0 length 36701167104 end 36701167103 GEOM: Configure da3s1d, start 0 length 36701167104 end 36701167103 Mounting root from ufs:/dev/ad0s1a start_init: trying /sbin/init Enter full pathname of shell or RETURN for /bin/sh:=20 # gvinum start # FOO: sd racingraid0.p0.s3 is up FOO: sd racingraid0.p0.s2 is up FOO: sd racingraid0.p0.s1 is up FOO: sd racingraid0.p0.s0 is up FOO: sd 480GB.p0.s1 is up FOO: sd 480GB.p0.s2 is up FOO: sd 480GB.p0.s0 is up FOO: sd 480GB.p0.s3 is up FOO: sd 190GB.p0.s1 is up FOO: sd usr.p1.s0 is up FOO: sd var.p1.s0 is up FOO: sd tmp.p1.s0 is up FOO: sd 190GB.p0.s0 is up FOO: sd usr.p0.s0 is up FOO: sd var.p0.s0 is up FOO: sd tmp.p0.s0 is up # mount -a # Pre-seeding PRNG: kickstart. Loading configuration files. Entropy harvesting: interrupts ethernet point_to_point kickstart. swapon: adding /dev/ad0s1b as swap device swapon: adding /dev/ad1s1b as swap device Fast boot: skipping disk checks. net.inet.tcp.sendspace: 32768 -> 262144 net.inet.tcp.recvspace: 65536 -> 262144 kern.ipc.maxsockbuf: 262144 -> 524288 kern.maxfiles: 12328 -> 16384 kern.ipc.somaxconn: 128 -> 1024 net.inet.ip.intr_queue_maxlen: 50 -> 500 kern.polling.enable: 0 -> 1 kern.polling.burst_max: 150 -> 200 kern.polling.each_burst: 5 -> 25 kern.polling.poll_in_trap: 0 -> 1 Setting hostname: fortify.satra.zapto.org. vr0: flags=3D18843 mtu = 1500 options=3D40 [...] media: Ethernet autoselect (100baseTX ) status: active re0: flags=3D18843 mtu = 1500 options=3D5b [...] media: Ethernet autoselect (none) status: no carrier lo0: flags=3D8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000=20 Flushed all rules. 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any [...] 65000 deny log ip from any to any Firewall rules loaded, starting divert daemons:. Firewall logging enabled net.inet.ip.fw.enable: 1 -> 1 Additional routing options: ignore ICMP redirect=3DYES log ICMP = redirect=3DYES. Starting devd. Mounting NFS file systems:. Starting syslogd. Aug 12 17:19:08 fortify syslogd: kernel boot file is /boot/kernel/kernel Clearing /tmp. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/X11R6/lib = /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout = /usr/X11R6/lib/aout Starting local daemons:. Updating motd. Starting ntpd. Aug 12 17:19:08 fortify ntpd[435]: no IPv6 interfaces found Configuring syscons: keymap keyrate blanktime. Starting sshd. Initial i386 initialization:. Additional ABI support: linuxLinux ELF exec handler installed . Starting cron. Local package initialization: Samba. Additional TCP options:. Starting inetd. ad5: TIMEOUT - READ_DMA retrying (2 retries left) LBA=3D22858569 ata2: reiniting channel .. ata2: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ad4: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ad5: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata2: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata2: resetting done .. ad5: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ad4: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ad4: setting PIO4 on HighPoint chip ad4: setting UDMA100 on HighPoint chip ad5: setting PIO4 on HighPoint chip ad5: setting UDMA100 on HighPoint chip ata2: device config done .. ad5: TIMEOUT - READ_DMA retrying (2 retries left) LBA=3D19375370 ata2: reiniting channel .. ata2: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ad4: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ad5: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata2: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata2: resetting done .. ad5: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ad4: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ad4: setting PIO4 on HighPoint chip ad4: setting UDMA100 on HighPoint chip ad5: setting PIO4 on HighPoint chip ad5: setting UDMA100 on HighPoint chip ata2: device config done .. ad5: TIMEOUT - READ_DMA retrying (2 retries left) LBA=3D19737994 ata2: reiniting channel .. ata2: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ad4: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ad5: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata2: reset tp2 stat0=3D50 stat1=3D50 = devices=3D0x3 ata2: resetting done .. ad5: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ad4: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ad4: setting PIO4 on HighPoint chip ad4: setting UDMA100 on HighPoint chip ad5: setting PIO4 on HighPoint chip ad5: setting UDMA100 on HighPoint chip ata2: device config done .. fortify# atacontrol list ATA channel 0: Master: ad0 ATA/ATAPI revision 6 Slave: ad1 ATA/ATAPI revision 6 ATA channel 1: Master: ad2 ATA/ATAPI revision 6 Slave: ad3 ATA/ATAPI revision 6 ATA channel 2: Master: ad4 ATA/ATAPI revision 6 Slave: ad5 ATA/ATAPI revision 6 ATA channel 3: Master: ad6 ATA/ATAPI revision 7 Slave: ad7 ATA/ATAPI revision 7 ATA channel 4: Master: ad8 ATA/ATAPI revision 7 Slave: ad9 ATA/ATAPI revision 7 ATA channel 5: Master: ad10 ATA/ATAPI revision 7 Slave: ad11 ATA/ATAPI revision 7 ATA channel 6: Master: ad12 ATA/ATAPI revision 6 Slave: ad13 ATA/ATAPI revision 6 ATA channel 7: Master: ad14 ATA/ATAPI revision 7 Slave: ad15 ATA/ATAPI revision 7 ATA channel 8: Master: ad16 ATA/ATAPI revision 6 Slave: no device present ATA channel 9: Master: ad18 ATA/ATAPI revision 5 Slave: no device present ATA channel 10: Master: ad20 Slave: no device = present ATA channel 11: Master: no device present Slave: no device present fortify# vmstat -i interrupt total rate irq0: clk 360960 1994 irq4: sio0 873 4 irq6: fdc0 6 0 irq8: rtc 23118 127 irq13: npx0 1 0 irq14: ata0 2089 11 irq15: ata1 64 0 irq16: atapci0+ 410 2 irq17: atapci2+ 305 1 irq18: re0 2 0 irq19: ahc0 840 4 irq20: atapci4 44 0 irq23: vr0 2 0 Total 388714 2147 Aug 12 17:25:00 fortify shutdown: reboot by daniel:=20 Stopping inetd. Shutting down daemon processes:. Stopping cron. Shutting down local daemons:. Writing entropy file:. Terminated . Aug 12 17:25:03 fortify syslogd: exiting on signal 15 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 2 1 0 0 done Skipping final sync, no buffers remaining Uptime: 7m45s pcib0: wake_prep disabled wake for \_SB_.PCI0 (S5) pcib1: wake_prep disabled wake for \_SB_.PCI0.PCI1 (S5) uhci0: wake_prep disabled wake for \_SB_.PCI0.USB0 (S5) uhci1: wake_prep disabled wake for \_SB_.PCI0.USB1 (S5) uhci2: wake_prep disabled wake for \_SB_.PCI0.USB2 (S5) uhci3: wake_prep disabled wake for \_SB_.PCI0.USB3 (S5) ehci0: wake_prep disabled wake for \_SB_.PCI0.SU20 (S5) unknown: wake_prep disabled wake for \_SB_.PCI0.MC97 (S5) vr0: wake_prep disabled wake for \_SB_.PCI0.SLAN (S5) Shutting down ACPI Rebooting... ------=_NextPart_000_000B_01C480A1.8339F4C0 Content-Type: application/octet-stream; name="FORTIFY" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="FORTIFY" =0A= machine i386=0A= cpu I686_CPU=0A= options CPU_ENABLE_SSE=0A= ident FORTIFY=0A= =0A= # Options for the firewall and NAT functionality=0A= options IPFIREWALL=0A= options IPDIVERT=0A= options IPFIREWALL_DEFAULT_TO_ACCEPT=0A= options IPFIREWALL_VERBOSE=0A= =0A= =0A= # To statically compile in device wiring instead of /boot/device.hints=0A= #hints "GENERIC.hints" # Default places to look for devices.=0A= =0A= makeoptions DEBUG=3D-g # Build kernel with gdb(1) debug symbols=0A= =0A= #options SCHED_ULE # ULE scheduler=0A= options SCHED_4BSD # 4BSD scheduler=0A= options INET # InterNETworking=0A= #options INET6 # IPv6 communications protocols=0A= options FFS # Berkeley Fast Filesystem=0A= options SOFTUPDATES # Enable FFS soft updates support=0A= options UFS_ACL # Support for access control lists=0A= options UFS_DIRHASH # Improve performance on big directories=0A= options MD_ROOT # MD is a potential root device=0A= options NFSCLIENT # Network Filesystem Client=0A= options NFSSERVER # Network Filesystem Server=0A= options NFS_ROOT # NFS usable as /, requires NFSCLIENT=0A= options MSDOSFS # MSDOS Filesystem=0A= options CD9660 # ISO 9660 Filesystem=0A= options PROCFS # Process filesystem (requires PSEUDOFS)=0A= options PSEUDOFS # Pseudo-filesystem framework=0A= options GEOM_GPT # GUID Partition Tables.=0A= options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!]=0A= options COMPAT_FREEBSD4 # Compatible with FreeBSD4=0A= options SCSI_DELAY=3D5000 # Delay (in ms) before probing SCSI=0A= #options KTRACE # ktrace(1) support=0A= options SYSVSHM # SYSV-style shared memory=0A= options SYSVMSG # SYSV-style message queues=0A= options SYSVSEM # SYSV-style semaphores=0A= options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time = extensions=0A= options KBD_INSTALL_CDEV # install a CDEV entry in /dev=0A= #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug = output. Adds ~128k to driver.=0A= #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug = output. Adds ~215k to driver.=0A= #options PFIL_HOOKS # pfil(9) framework=0A= =0A= =0A= # dakrer=0A= options DEVICE_POLLING=0A= options DUMMYNET=0A= options HZ=3D2000=0A= options ZERO_COPY_SOCKETS # Turn on zero copy send code=0A= =0A= # The aic7xxx driver will attempt to use memory mapped I/O for all PCI=0A= # controllers that have it configured only if this option is set. = Unfortunately,=0A= # this doesn't work on some motherboards, which prevents it from being = the=0A= # default.=0A= options AHC_ALLOW_MEMIO=0A= =0A= =0A= # BLKDEV_IOSIZE sets the default block size used in user block=0A= # device I/O. Note that this value will be overriden by the label=0A= # when specifying a block device from a label with a non-0=0A= # partition blocksize. The default is PAGE_SIZE.=0A= #=0A= #options BLKDEV_IOSIZE=3D8192=0A= =0A= # encrypted filesystem=0A= options GEOM_BDE=0A= =0A= # Set the amount of time (in seconds) the system will wait before=0A= # rebooting automatically when a kernel panic occurs. If set to (-1),=0A= # the system will wait indefinitely until a key is pressed on the=0A= # console.=0A= options PANIC_REBOOT_WAIT_TIME=3D300=0A= =0A= # netgraph(4). Enable the base netgraph code with the NETGRAPH option.=0A= # Individual node types can be enabled with the corresponding option=0A= # listed below; however, this is not strictly necessary as netgraph=0A= # will automatically load the corresponding KLD module if the node type=0A= # is not already compiled into the kernel. Each type below has a=0A= # corresponding man page, e.g., ng_async(8).=0A= options NETGRAPH #netgraph(4) system=0A= #options NETGRAPH_ASYNC=0A= #options NETGRAPH_ATMLLC=0A= #options NETGRAPH_ATM_ATMPIF=0A= #options NETGRAPH_BLUETOOTH # ng_bluetooth(4)=0A= #options NETGRAPH_BLUETOOTH_BT3C # ng_bt3c(4)=0A= #options NETGRAPH_BLUETOOTH_H4 # ng_h4(4)=0A= #options NETGRAPH_BLUETOOTH_HCI # ng_hci(4)=0A= #options NETGRAPH_BLUETOOTH_L2CAP # ng_l2cap(4)=0A= #options NETGRAPH_BLUETOOTH_SOCKET # ng_btsocket(4)=0A= #options NETGRAPH_BLUETOOTH_UBT # ng_ubt(4)=0A= #options NETGRAPH_BLUETOOTH_UBTBCMFW # ubtbcmfw(4)=0A= #options NETGRAPH_BPF=0A= #options NETGRAPH_BRIDGE=0A= #options NETGRAPH_CISCO=0A= #options NETGRAPH_ECHO=0A= #options NETGRAPH_ETHER=0A= #options NETGRAPH_FRAME_RELAY=0A= #options NETGRAPH_GIF=0A= #options NETGRAPH_GIF_DEMUX=0A= #options NETGRAPH_HOLE=0A= #options NETGRAPH_IFACE=0A= #options NETGRAPH_IP_INPUT=0A= #options NETGRAPH_KSOCKET=0A= #options NETGRAPH_L2TP=0A= #options NETGRAPH_LMI=0A= ## MPPC compression requires proprietary files (not included)=0A= ##options NETGRAPH_MPPC_COMPRESSION=0A= #options NETGRAPH_MPPC_ENCRYPTION=0A= #options NETGRAPH_ONE2MANY=0A= #options NETGRAPH_PPP=0A= #options NETGRAPH_PPPOE=0A= #options NETGRAPH_PPTPGRE=0A= #options NETGRAPH_RFC1490=0A= #options NETGRAPH_SOCKET=0A= #options NETGRAPH_SPLIT=0A= #options NETGRAPH_SPPP=0A= #options NETGRAPH_TEE=0A= #options NETGRAPH_TTY=0A= #options NETGRAPH_UI=0A= #options NETGRAPH_VJC=0A= =0A= =0A= # Debugging for use in -current=0A= options KDB # Enable the kernel debugger=0A= options DDB # Enable the kernel debugger=0A= #options INVARIANTS # Enable calls of extra sanity checking=0A= #options INVARIANT_SUPPORT # Extra sanity checks of internal = structures, required by INVARIANTS=0A= #options WITNESS # Enable checks to detect deadlocks and cycles=0A= #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed=0A= =0A= # To make an SMP kernel, the next two are needed=0A= #options SMP # Symmetric MultiProcessor Kernel=0A= device apic # I/O APIC=0A= =0A= =0A= # Bus support. Do not remove isa, even if you have no isa slots=0A= device isa=0A= #device eisa=0A= device pci=0A= =0A= # Floppy drives=0A= device fdc=0A= =0A= # ATA and ATAPI devices=0A= device ata=0A= device atadisk # ATA disk drives=0A= device ataraid # ATA RAID drives=0A= device atapicd # ATAPI CDROM drives=0A= device atapifd # ATAPI floppy drives=0A= device atapist # ATAPI tape drives=0A= options ATA_STATIC_ID # Static device numbering=0A= =0A= # SCSI Controllers=0A= #device ahb # EISA AHA1742 family=0A= device ahc # AHA2940 and onboard AIC7xxx devices=0A= device ahd # AHA39320/29320 and onboard AIC79xx devices=0A= #device amd # AMD 53C974 (Tekram DC-390(T))=0A= #device isp # Qlogic family=0A= #device mpt # LSI-Logic MPT-Fusion=0A= ##device ncr # NCR/Symbios Logic=0A= #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr')=0A= #device trm # Tekram DC395U/UW/F DC315U adapters=0A= =0A= #device adv # Advansys SCSI adapters=0A= #device adw # Advansys wide SCSI adapters=0A= #device aha # Adaptec 154x SCSI adapters=0A= #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60.=0A= #device bt # Buslogic/Mylex MultiMaster SCSI adapters=0A= =0A= #device ncv # NCR 53C500=0A= #device nsp # Workbit Ninja SCSI-3=0A= #device stg # TMC 18C30/18C50=0A= =0A= # SCSI peripherals=0A= device scbus # SCSI bus (required for SCSI)=0A= device ch # SCSI media changers=0A= device da # Direct Access (disks)=0A= device sa # Sequential Access (tape etc)=0A= device cd # CD=0A= device pass # Passthrough device (direct SCSI access)=0A= device ses # SCSI Environmental Services (and SAF-TE)=0A= =0A= # RAID controllers interfaced to the SCSI subsystem=0A= #device amr # AMI MegaRAID=0A= #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID=0A= #device ciss # Compaq Smart RAID 5*=0A= #device dpt # DPT Smartcache III, IV - See NOTES for options=0A= #device iir # Intel Integrated RAID=0A= #device ips # IBM (Adaptec) ServeRAID=0A= #device mly # Mylex AcceleRAID/eXtremeRAID=0A= #device twa # 3ware 9000 series PATA/SATA RAID=0A= =0A= # RAID controllers=0A= #device aac # Adaptec FSA RAID=0A= #device aacp # SCSI passthrough for aac (requires CAM)=0A= #device ida # Compaq Smart RAID=0A= #device mlx # Mylex DAC960 family=0A= #device pst # Promise Supertrak SX6000=0A= #device twe # 3ware ATA RAID=0A= =0A= # atkbdc0 controls both the keyboard and the PS/2 mouse=0A= device atkbdc # AT keyboard controller=0A= device atkbd # AT keyboard=0A= device psm # PS/2 mouse=0A= =0A= device vga # VGA video card driver=0A= =0A= device splash # Splash screen and screen saver support=0A= =0A= # syscons is the default console driver, resembling an SCO console=0A= device sc=0A= =0A= # Enable this for the pcvt (VT220 compatible) console driver=0A= #device vt=0A= #options XSERVER # support for X server on a vt console=0A= #options FAT_CURSOR # start with block cursor=0A= =0A= device agp # support several AGP chipsets=0A= =0A= # Floating point support - do not disable.=0A= device npx=0A= =0A= # Power management support (see NOTES for more options)=0A= #device apm=0A= # Add suspend/resume support for the i8254.=0A= device pmtimer=0A= =0A= # PCCARD (PCMCIA) support=0A= # PCMCIA and cardbus bridge support=0A= #device cbb # cardbus (yenta) bridge=0A= ##device pcic # ExCA ISA and PCI bridges=0A= #device pccard # PC Card (16-bit) bus=0A= #device cardbus # CardBus (32-bit) bus=0A= =0A= # Serial (COM) ports=0A= device sio # 8250, 16[45]50 based serial ports=0A= =0A= # Parallel port=0A= device ppc=0A= device ppbus # Parallel port bus (required)=0A= device lpt # Printer=0A= device plip # TCP/IP over parallel=0A= device ppi # Parallel port interface device=0A= #device vpo # Requires scbus and da=0A= =0A= # If you've got a "dumb" serial or parallel PCI card that is=0A= # supported by the puc(4) glue driver, uncomment the following=0A= # line to enable it (connects to the sio and/or ppc drivers):=0A= #device puc=0A= =0A= # PCI Ethernet NICs.=0A= #device de # DEC/Intel DC21x4x (``Tulip'')=0A= device em # Intel PRO/1000 adapter Gigabit Ethernet Card=0A= #device txp # 3Com 3cR990 (``Typhoon'')=0A= #device vx # 3Com 3c590, 3c595 (``Vortex'')=0A= =0A= # PCI Ethernet NICs that use the common MII bus controller code.=0A= # NOTE: Be sure to keep the 'device miibus' line in order to use these = NICs!=0A= device miibus # MII bus support=0A= #device bfe # Broadcom BCM440x 10/100 Ethernet=0A= device bge # Broadcom BCM570xx Gigabit Ethernet=0A= #device dc # DEC/Intel 21143 and various workalikes=0A= #device fxp # Intel EtherExpress PRO/100B (82557, 82558)=0A= #device pcn # AMD Am79C97x PCI 10/100 (precedence over 'lnc')=0A= device re # RealTek 8139C+/8169/8169S/8110S=0A= device rl # RealTek 8129/8139=0A= #device sf # Adaptec AIC-6915 (``Starfire'')=0A= #device sis # Silicon Integrated Systems SiS 900/SiS 7016=0A= #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet=0A= #device ste # Sundance ST201 (D-Link DFE-550TX)=0A= #device ti # Alteon Networks Tigon I/II gigabit Ethernet=0A= #device tl # Texas Instruments ThunderLAN=0A= #device tx # SMC EtherPower II (83c170 ``EPIC'')=0A= device vr # VIA Rhine, Rhine II=0A= #device wb # Winbond W89C840F=0A= device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'')=0A= =0A= # ISA Ethernet NICs. pccard NICs included.=0A= #device cs # Crystal Semiconductor CS89x0 NIC=0A= # 'device ed' requires 'device miibus'=0A= #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards=0A= #device ex # Intel EtherExpress Pro/10 and Pro/10+=0A= #device ep # Etherlink III based cards=0A= #device fe # Fujitsu MB8696x based cards=0A= #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc.=0A= #device lnc # NE2100, NE32-VL Lance Ethernet cards=0A= #device sn # SMC's 9000 series of Ethernet chips=0A= #device xe # Xircom pccard Ethernet=0A= =0A= # ISA devices that use the old ISA shims=0A= #device le=0A= =0A= # Wireless NIC cards=0A= #device wlan # 802.11 support=0A= #device an # Aironet 4500/4800 802.11 wireless NICs.=0A= #device awi # BayStack 660 and others=0A= #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs.=0A= ##device wl # Older non 802.11 Wavelan wireless NIC.=0A= =0A= # Pseudo devices - the number indicates how many units to allocate.=0A= device mem # Memory and kernel memory devices=0A= device io # I/O device=0A= device random # Entropy device=0A= device loop # Network loopback=0A= device ether # Ethernet support=0A= device sl # Kernel SLIP=0A= device ppp # Kernel PPP=0A= device tun # Packet tunnel.=0A= device pty # Pseudo-ttys (telnet etc)=0A= device md # Memory "disks"=0A= device gif # IPv6 and IPv4 tunneling=0A= device faith # IPv6-to-IPv4 relaying (translation)=0A= =0A= # The `bpf' device enables the Berkeley Packet Filter.=0A= # Be aware of the administrative consequences of enabling this!=0A= device bpf # Berkeley packet filter=0A= =0A= # USB support=0A= device uhci # UHCI PCI->USB interface=0A= device ohci # OHCI PCI->USB interface=0A= device ehci # EHCI controller=0A= device usb # USB Bus (required)=0A= #device udbp # USB Double Bulk Pipe devices=0A= device ugen # Generic=0A= device uhid # "Human Interface Devices"=0A= device ukbd # Keyboard=0A= device ulpt # Printer=0A= device umass # Disks/Mass storage - Requires scbus and da=0A= device ums # Mouse=0A= device urio # Diamond Rio 500 MP3 player=0A= device uscanner # Scanners=0A= # USB Ethernet, requires mii=0A= device aue # ADMtek USB Ethernet=0A= device axe # ASIX Electronics USB Ethernet=0A= device cue # CATC USB Ethernet=0A= device kue # Kawasaki LSI USB Ethernet=0A= device rue # RealTek RTL8150 USB Ethernet=0A= =0A= # FireWire support=0A= #device firewire # FireWire bus code=0A= #device sbp # SCSI over FireWire (Requires scbus and da)=0A= #device fwe # Ethernet over FireWire (non-standard!)=0A= =0A= ------=_NextPart_000_000B_01C480A1.8339F4C0 Content-Type: application/octet-stream; name="FORTIFY.asl" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="FORTIFY.asl" /*=0A= RSD PTR: OEM=3DASUS, ACPI_Rev=3D1.0x (0)=0A= RSDT=3D0x4fffb000, cksum=3D103=0A= */=0A= /*=0A= RSDT: Length=3D48, Revision=3D1, Checksum=3D43,=0A= OEMID=3DASUS, OEM Table ID=3DA7V600-X, OEM Revision=3D0x42302e31,=0A= Creator ID=3DMSFT, Creator Revision=3D0x31313031=0A= Entries=3D{ 0x4fffb0b2, 0x4fffb030, 0x4fffb058 }=0A= */=0A= /*=0A= FACP: Length=3D116, Revision=3D1, Checksum=3D79,=0A= OEMID=3DASUS, OEM Table ID=3DA7V600-X, OEM Revision=3D0x42302e31,=0A= Creator ID=3DMSFT, Creator Revision=3D0x31313031=0A= FACS=3D0x4ffff000, DSDT=3D0x4fffb126=0A= INT_MODEL=3DPIC=0A= Preferred_PM_Profile=3DUnspecified (0)=0A= SCI_INT=3D9=0A= SMI_CMD=3D0xe42f, ACPI_ENABLE=3D0xa1, ACPI_DISABLE=3D0xa0, = S4BIOS_REQ=3D0x0=0A= PSTATE_CNT=3D0x0=0A= PM1a_EVT_BLK=3D0xe400-0xe403=0A= PM1a_CNT_BLK=3D0xe404-0xe405=0A= PM_TMR_BLK=3D0xe408-0xe40b=0A= GPE0_BLK=3D0xe420-0xe423=0A= P_LVL2_LAT=3D190 us, P_LVL3_LAT=3D1900 us=0A= FLUSH_SIZE=3D0, FLUSH_STRIDE=3D0=0A= DUTY_OFFSET=3D0, DUTY_WIDTH=3D0=0A= DAY_ALRM=3D125, MON_ALRM=3D0, CENTURY=3D0=0A= IAPC_BOOT_ARCH=3D=0A= Flags=3D{WBINVD_FLUSH,PROC_C1,SLP_BUTTON,RTC_S4,TMR_VAL_EXT}=0A= */=0A= /*=0A= FACS: Length=3D64, HwSig=3D0x00000000, Firm_Wake_Vec=3D0x00000000=0A= Global_Lock=3D=0A= Flags=3D=0A= Version=3D0=0A= */=0A= /*=0A= DSDT: Length=3D12440, Revision=3D1, Checksum=3D245,=0A= OEMID=3DASUS, OEM Table ID=3DA7V600-X, OEM Revision=3D0x1000,=0A= Creator ID=3DMSFT, Creator Revision=3D0x100000b=0A= */=0A= /*=0A= BOOT: Length=3D40, Revision=3D1, Checksum=3D54,=0A= OEMID=3DASUS, OEM Table ID=3DA7V600-X, OEM Revision=3D0x42302e31,=0A= Creator ID=3DMSFT, Creator Revision=3D0x31313031=0A= */=0A= /*=0A= APIC: Length=3D90, Revision=3D1, Checksum=3D81,=0A= OEMID=3DASUS, OEM Table ID=3DA7V600-X, OEM Revision=3D0x42302e31,=0A= Creator ID=3DMSFT, Creator Revision=3D0x31313031=0A= Local APIC ADDR=3D0xfee00000=0A= Flags=3D{PC-AT}=0A= =0A= Type=3DIO APIC=0A= APIC ID=3D2=0A= INT BASE=3D0=0A= ADDR=3D0x00000000fec00000=0A= =0A= Type=3DINT Override=0A= BUS=3D0=0A= IRQ=3D0=0A= INTR=3D2=0A= Flags=3D{Polarity=3Dconforming, Trigger=3Dedge}=0A= =0A= Type=3DINT Override=0A= BUS=3D0=0A= IRQ=3D9=0A= INTR=3D9=0A= Flags=3D{Polarity=3Dactive-lo, Trigger=3Dlevel}=0A= =0A= Type=3DLocal NMI=0A= ACPI CPU=3D0=0A= LINT Pin=3D1=0A= Flags=3D{Polarity=3Dactive-hi, Trigger=3Dedge}=0A= =0A= Type=3DLocal APIC=0A= ACPI CPU=3D0=0A= Flags=3D{ENABLED}=0A= APIC ID=3D0=0A= */=0A= /*=0A= * Intel ACPI Component Architecture=0A= * AML Disassembler version 20040527=0A= *=0A= * Disassembly of /tmp/acpidump.H5DCDk, Thu Aug 12 18:37:07 2004=0A= */=0A= DefinitionBlock ("DSDT.aml", "DSDT", 1, "ASUS", "A7V600-X", 4096)=0A= {=0A= Scope (\_PR)=0A= {=0A= Processor (\_PR.CPU0, 0x00, 0x00000000, 0x00) {}=0A= }=0A= =0A= OperationRegion (FSEG, SystemMemory, 0x000FDF00, 0x0100)=0A= Field (FSEG, AnyAcc, NoLock, Preserve)=0A= {=0A= ACPR, 32, =0A= MMSZ, 16, =0A= NPS2, 8, =0A= STRF, 8, =0A= HCUD, 8, =0A= HCPI, 8, =0A= HDUD, 8, =0A= HDPI, 8, =0A= HEUD, 8, =0A= HEPI, 8, =0A= HFUD, 8, =0A= HFPI, 8, =0A= LPTM, 8, =0A= CM2M, 8, =0A= IRMD, 8, =0A= FLG0, 8, =0A= RTCS, 8=0A= }=0A= =0A= OperationRegion (NVSR, SystemMemory, ACPR, 0x0100)=0A= Field (NVSR, AnyAcc, NoLock, Preserve)=0A= {=0A= TRTY, 8, =0A= SLPT, 8, =0A= KPSW, 8, =0A= MPSW, 8, =0A= TRD0, 8, =0A= TRD1, 8, =0A= TRD2, 8, =0A= TRD3, 8, =0A= OSFL, 8, =0A= INFB, 8, =0A= INFO, 1600=0A= }=0A= =0A= Method (MIN, 2, NotSerialized)=0A= {=0A= If (LLess (Arg0, Arg1))=0A= {=0A= Return (Arg0)=0A= }=0A= Else=0A= {=0A= Return (Arg1)=0A= }=0A= }=0A= =0A= Method (SLEN, 1, NotSerialized)=0A= {=0A= Return (SizeOf (Arg0))=0A= }=0A= =0A= Method (S2BF, 1, Serialized)=0A= {=0A= Add (SLEN (Arg0), One, Local0)=0A= Name (BUFF, Buffer (Local0) {})=0A= Store (Arg0, BUFF)=0A= Return (BUFF)=0A= }=0A= =0A= Method (SCMP, 2, NotSerialized)=0A= {=0A= Store (S2BF (Arg0), Local0)=0A= Store (S2BF (Arg1), Local1)=0A= Store (Zero, Local4)=0A= Store (SLEN (Arg0), Local5)=0A= Store (SLEN (Arg1), Local6)=0A= Store (MIN (Local5, Local6), Local7)=0A= While (LLess (Local4, Local7))=0A= {=0A= Store (DerefOf (Index (Local0, Local4)), Local2)=0A= Store (DerefOf (Index (Local1, Local4)), Local3)=0A= If (LGreater (Local2, Local3))=0A= {=0A= Return (One)=0A= }=0A= Else=0A= {=0A= If (LLess (Local2, Local3))=0A= {=0A= Return (Ones)=0A= }=0A= }=0A= =0A= Increment (Local4)=0A= }=0A= =0A= If (LLess (Local4, Local5))=0A= {=0A= Return (One)=0A= }=0A= Else=0A= {=0A= If (LLess (Local4, Local6))=0A= {=0A= Return (Ones)=0A= }=0A= Else=0A= {=0A= Return (Zero)=0A= }=0A= }=0A= }=0A= =0A= OperationRegion (GPSC, SystemIO, 0xE42F, 0x01)=0A= Field (GPSC, ByteAcc, NoLock, Preserve)=0A= {=0A= SMCM, 8=0A= }=0A= =0A= Method (ISMI, 1, Serialized)=0A= {=0A= Store (Arg0, TRTY)=0A= Store (0xA7, SMCM)=0A= }=0A= =0A= OperationRegion (\DEBG, SystemIO, 0x80, 0x01)=0A= Field (\DEBG, ByteAcc, NoLock, Preserve)=0A= {=0A= DBG1, 8=0A= }=0A= =0A= Method (DIAG, 1, NotSerialized)=0A= {=0A= Store (Arg0, DBG1)=0A= }=0A= =0A= Method (SSLP, 1, NotSerialized)=0A= {=0A= Store (Arg0, SLPT)=0A= }=0A= =0A= Scope (\_SI)=0A= {=0A= Method (_MSG, 1, NotSerialized)=0A= {=0A= If (LEqual (Arg0, Zero))=0A= {=0A= ISMI (0x00)=0A= }=0A= Else=0A= {=0A= ISMI (0x01)=0A= }=0A= }=0A= }=0A= =0A= Mutex (PSMX, 0x00)=0A= Name (BU00, Buffer (0x08)=0A= {=0A= 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00=0A= })=0A= CreateDWordField (BU00, 0x00, AG88)=0A= CreateDWordField (BU00, 0x04, AG98)=0A= Method (\_PTS, 1, NotSerialized)=0A= {=0A= SSLP (Arg0)=0A= Store (\_SB.PCI0.AG88, \AG88)=0A= Store (\_SB.PCI0.AG98, \AG98)=0A= Or (Arg0, 0xF0, Local2)=0A= Store (Local2, DBG1)=0A= ISMI (0x3E)=0A= ISMI (0x3D)=0A= }=0A= =0A= Method (\_WAK, 1, NotSerialized)=0A= {=0A= Store (\AG88, \_SB.PCI0.AG88)=0A= Store (\AG98, \_SB.PCI0.AG98)=0A= ISMI (0x3C)=0A= ISMI (0x3F)=0A= Store (0xFF, DBG1)=0A= If (LEqual (RTCS, Zero))=0A= {=0A= Notify (\_SB.PWRB, 0x02)=0A= }=0A= }=0A= =0A= Name (\_S0, Package (0x04)=0A= {=0A= 0x00, =0A= 0x00, =0A= 0x00, =0A= 0x00=0A= })=0A= Name (\_S1, Package (0x04)=0A= {=0A= 0x07, =0A= 0x00, =0A= 0x00, =0A= 0x00=0A= })=0A= Name (\S_3, Package (0x04)=0A= {=0A= 0x07, =0A= 0x00, =0A= 0x00, =0A= 0x00=0A= })=0A= Name (\_S4, Package (0x04)=0A= {=0A= 0x07, =0A= 0x00, =0A= 0x00, =0A= 0x00=0A= })=0A= Name (\_S5, Package (0x04)=0A= {=0A= 0x07, =0A= 0x00, =0A= 0x00, =0A= 0x00=0A= })=0A= Name (\PICF, 0x00)=0A= Method (_PIC, 1, NotSerialized)=0A= {=0A= Store (Arg0, \PICF)=0A= \_SB.PCI0.PX40.SPIC ()=0A= }=0A= =0A= Scope (\_SB)=0A= {=0A= Device (PWRB)=0A= {=0A= Name (_HID, EisaId ("PNP0C0C"))=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= Return (0x0B)=0A= }=0A= }=0A= =0A= Device (MEM1)=0A= {=0A= Name (_HID, EisaId ("PNP0C01"))=0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUF1, ResourceTemplate ()=0A= {=0A= Memory32Fixed (ReadWrite, 0x00000000, 0x000A0000)=0A= Memory32Fixed (ReadOnly, 0x000F0000, 0x00010000)=0A= Memory32Fixed (ReadWrite, 0x00100000, 0x00000000)=0A= Memory32Fixed (ReadWrite, 0xFEC00000, 0x00000100)=0A= Memory32Fixed (ReadWrite, 0xFEE00000, 0x00001000)=0A= })=0A= CreateDWordField (BUF1, 0x20, EMLN)=0A= Store (MEMS (), EMLN)=0A= Decrement (EMLN)=0A= ShiftLeft (EMLN, 0x14, EMLN)=0A= Return (BUF1)=0A= }=0A= }=0A= =0A= Method (MEMS, 0, NotSerialized)=0A= {=0A= Return (MMSZ)=0A= }=0A= =0A= Device (LNKA)=0A= {=0A= Name (_HID, EisaId ("PNP0C0F"))=0A= Name (_UID, 0x01)=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= Store (\_SB.PCI0.PX40.PIRA, Local0)=0A= If (LNot (LEqual (Local0, Zero)))=0A= {=0A= Return (0x0B)=0A= }=0A= Else=0A= {=0A= Return (0x09)=0A= }=0A= }=0A= =0A= Name (_PRS, ResourceTemplate ()=0A= {=0A= IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,9,10,11,12}=0A= })=0A= Method (_DIS, 0, NotSerialized)=0A= {=0A= Store (Zero, \_SB.PCI0.PX40.PIRA)=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUFA, ResourceTemplate ()=0A= {=0A= IRQ (Level, ActiveLow, Shared) {}=0A= })=0A= CreateWordField (BUFA, 0x01, IRA)=0A= Store (\_SB.PCI0.PX40.PIRA, Local0)=0A= ShiftLeft (One, Local0, Local1)=0A= Store (Local1, IRA)=0A= Return (BUFA)=0A= }=0A= =0A= Method (_SRS, 1, NotSerialized)=0A= {=0A= CreateByteField (Arg0, 0x01, IRA1)=0A= CreateByteField (Arg0, 0x02, IRA2)=0A= ShiftLeft (IRA2, 0x08, Local0)=0A= Or (Local0, IRA1, Local0)=0A= Store (0x00, Local1)=0A= ShiftRight (Local0, 0x01, Local0)=0A= While (LGreater (Local0, 0x00))=0A= {=0A= Increment (Local1)=0A= ShiftRight (Local0, 0x01, Local0)=0A= }=0A= =0A= Store (Local1, \_SB.PCI0.PX40.PIRA)=0A= }=0A= }=0A= =0A= Device (LNKB)=0A= {=0A= Name (_HID, EisaId ("PNP0C0F"))=0A= Name (_UID, 0x02)=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= Store (\_SB.PCI0.PX40.PIRB, Local0)=0A= If (LNot (LEqual (Local0, Zero)))=0A= {=0A= Return (0x0B)=0A= }=0A= Else=0A= {=0A= Return (0x09)=0A= }=0A= }=0A= =0A= Name (_PRS, ResourceTemplate ()=0A= {=0A= IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,9,10,11,12}=0A= })=0A= Method (_DIS, 0, NotSerialized)=0A= {=0A= Store (Zero, \_SB.PCI0.PX40.PIRB)=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUFB, ResourceTemplate ()=0A= {=0A= IRQ (Level, ActiveLow, Shared) {}=0A= })=0A= CreateWordField (BUFB, 0x01, IRB)=0A= Store (\_SB.PCI0.PX40.PIRB, Local0)=0A= ShiftLeft (One, Local0, Local1)=0A= Store (Local1, IRB)=0A= Return (BUFB)=0A= }=0A= =0A= Method (_SRS, 1, NotSerialized)=0A= {=0A= CreateByteField (Arg0, 0x01, IRB1)=0A= CreateByteField (Arg0, 0x02, IRB2)=0A= ShiftLeft (IRB2, 0x08, Local0)=0A= Or (Local0, IRB1, Local0)=0A= Store (0x00, Local1)=0A= ShiftRight (Local0, 0x01, Local0)=0A= While (LGreater (Local0, 0x00))=0A= {=0A= Increment (Local1)=0A= ShiftRight (Local0, 0x01, Local0)=0A= }=0A= =0A= Store (Local1, \_SB.PCI0.PX40.PIRB)=0A= }=0A= }=0A= =0A= Device (LNKC)=0A= {=0A= Name (_HID, EisaId ("PNP0C0F"))=0A= Name (_UID, 0x03)=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= Store (\_SB.PCI0.PX40.PIRC, Local0)=0A= If (LNot (LEqual (Local0, Zero)))=0A= {=0A= Return (0x0B)=0A= }=0A= Else=0A= {=0A= Return (0x09)=0A= }=0A= }=0A= =0A= Name (_PRS, ResourceTemplate ()=0A= {=0A= IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,9,10,11,12}=0A= })=0A= Method (_DIS, 0, NotSerialized)=0A= {=0A= Store (Zero, \_SB.PCI0.PX40.PIRC)=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUFC, ResourceTemplate ()=0A= {=0A= IRQ (Level, ActiveLow, Shared) {}=0A= })=0A= CreateWordField (BUFC, 0x01, IRC)=0A= Store (\_SB.PCI0.PX40.PIRC, Local0)=0A= ShiftLeft (One, Local0, Local1)=0A= Store (Local1, IRC)=0A= Return (BUFC)=0A= }=0A= =0A= Method (_SRS, 1, NotSerialized)=0A= {=0A= CreateByteField (Arg0, 0x01, IRC1)=0A= CreateByteField (Arg0, 0x02, IRC2)=0A= ShiftLeft (IRC2, 0x08, Local0)=0A= Or (Local0, IRC1, Local0)=0A= Store (0x00, Local1)=0A= ShiftRight (Local0, 0x01, Local0)=0A= While (LGreater (Local0, 0x00))=0A= {=0A= Increment (Local1)=0A= ShiftRight (Local0, 0x01, Local0)=0A= }=0A= =0A= Store (Local1, \_SB.PCI0.PX40.PIRC)=0A= }=0A= }=0A= =0A= Device (LNKD)=0A= {=0A= Name (_HID, EisaId ("PNP0C0F"))=0A= Name (_UID, 0x04)=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= Store (\_SB.PCI0.PX40.PIRD, Local0)=0A= If (LNot (LEqual (Local0, Zero)))=0A= {=0A= Return (0x0B)=0A= }=0A= Else=0A= {=0A= Return (0x09)=0A= }=0A= }=0A= =0A= Name (_PRS, ResourceTemplate ()=0A= {=0A= IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,9,10,11,12}=0A= })=0A= Method (_DIS, 0, NotSerialized)=0A= {=0A= Store (Zero, \_SB.PCI0.PX40.PIRD)=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUFD, ResourceTemplate ()=0A= {=0A= IRQ (Level, ActiveLow, Shared) {}=0A= })=0A= CreateWordField (BUFD, 0x01, IRD)=0A= Store (\_SB.PCI0.PX40.PIRD, Local0)=0A= ShiftLeft (One, Local0, Local1)=0A= Store (Local1, IRD)=0A= Return (BUFD)=0A= }=0A= =0A= Method (_SRS, 1, NotSerialized)=0A= {=0A= CreateByteField (Arg0, 0x01, IRD1)=0A= CreateByteField (Arg0, 0x02, IRD2)=0A= ShiftLeft (IRD2, 0x08, Local0)=0A= Or (Local0, IRD1, Local0)=0A= Store (0x00, Local1)=0A= ShiftRight (Local0, 0x01, Local0)=0A= While (LGreater (Local0, 0x00))=0A= {=0A= Increment (Local1)=0A= ShiftRight (Local0, 0x01, Local0)=0A= }=0A= =0A= Store (Local1, \_SB.PCI0.PX40.PIRD)=0A= }=0A= }=0A= =0A= Device (LNKE)=0A= {=0A= Name (_HID, EisaId ("PNP0C0F"))=0A= Name (_UID, 0x05)=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= Store (Zero, Local0)=0A= If (LNot (\_SB.PCI0.PX40.UPT0))=0A= {=0A= Store (One, Local0)=0A= }=0A= =0A= If (LNot (\_SB.PCI0.PX40.UPT1))=0A= {=0A= Store (One, Local0)=0A= }=0A= =0A= If (LNot (\_SB.PCI0.PX40.SATA))=0A= {=0A= Store (One, Local0)=0A= }=0A= =0A= If (\_SB.PCI0.PX40.SLEN)=0A= {=0A= Store (One, Local0)=0A= }=0A= =0A= If (Local0)=0A= {=0A= Return (0x0B)=0A= }=0A= =0A= Return (0x09)=0A= }=0A= =0A= Name (_PRS, ResourceTemplate ()=0A= {=0A= IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,9,10,11,12}=0A= })=0A= Method (_DIS, 0, NotSerialized)=0A= {=0A= Store (Zero, \_SB.PCI0.USB0.UIRQ)=0A= Store (Zero, \_SB.PCI0.USB1.UIRQ)=0A= Store (Zero, \_SB.PCI0.SATA.UIRQ)=0A= Store (Zero, \_SB.PCI0.SLAN.PIRQ)=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUFE, ResourceTemplate ()=0A= {=0A= IRQ (Level, ActiveLow, Shared) {}=0A= })=0A= CreateWordField (BUFE, 0x01, IRE)=0A= If (LNot (\_SB.PCI0.PX40.UPT0))=0A= {=0A= Store (\_SB.PCI0.USB0.UIRQ, Local0)=0A= }=0A= =0A= If (LNot (\_SB.PCI0.PX40.UPT1))=0A= {=0A= Store (\_SB.PCI0.USB1.UIRQ, Local0)=0A= }=0A= =0A= If (LNot (\_SB.PCI0.PX40.SATA))=0A= {=0A= Store (\_SB.PCI0.SATA.UIRQ, Local0)=0A= }=0A= =0A= If (\_SB.PCI0.PX40.SLEN)=0A= {=0A= Store (\_SB.PCI0.SLAN.PIRQ, Local0)=0A= }=0A= =0A= ShiftLeft (One, Local0, Local1)=0A= Store (Local1, IRE)=0A= Return (BUFE)=0A= }=0A= =0A= Method (_SRS, 1, NotSerialized)=0A= {=0A= CreateByteField (Arg0, 0x01, IRE1)=0A= CreateByteField (Arg0, 0x02, IRE2)=0A= ShiftLeft (IRE2, 0x08, Local0)=0A= Or (Local0, IRE1, Local0)=0A= Store (0x00, Local1)=0A= ShiftRight (Local0, 0x01, Local0)=0A= While (LGreater (Local0, 0x00))=0A= {=0A= Increment (Local1)=0A= ShiftRight (Local0, 0x01, Local0)=0A= }=0A= =0A= Store (Local1, \_SB.PCI0.USB0.UIRQ)=0A= Store (Local1, \_SB.PCI0.USB1.UIRQ)=0A= Store (Local1, \_SB.PCI0.SATA.UIRQ)=0A= Store (Local1, \_SB.PCI0.SLAN.PIRQ)=0A= }=0A= }=0A= =0A= Device (LNKF)=0A= {=0A= Name (_HID, EisaId ("PNP0C0F"))=0A= Name (_UID, 0x06)=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= Store (Zero, Local0)=0A= If (LNot (\_SB.PCI0.PX40.UPT2))=0A= {=0A= Store (One, Local0)=0A= }=0A= =0A= If (LNot (\_SB.PCI0.PX40.UPT3))=0A= {=0A= Store (One, Local0)=0A= }=0A= =0A= If (Local0)=0A= {=0A= Return (0x0B)=0A= }=0A= =0A= Return (0x09)=0A= }=0A= =0A= Name (_PRS, ResourceTemplate ()=0A= {=0A= IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,9,10,11,12}=0A= })=0A= Method (_DIS, 0, NotSerialized)=0A= {=0A= Store (Zero, \_SB.PCI0.USB2.UIRQ)=0A= Store (Zero, \_SB.PCI0.USB3.UIRQ)=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUFF, ResourceTemplate ()=0A= {=0A= IRQ (Level, ActiveLow, Shared) {}=0A= })=0A= CreateWordField (BUFF, 0x01, IRF)=0A= Store (\_SB.PCI0.USB2.UIRQ, Local0)=0A= Store (\_SB.PCI0.USB3.UIRQ, Local0)=0A= ShiftLeft (One, Local0, Local1)=0A= Store (Local1, IRF)=0A= Return (BUFF)=0A= }=0A= =0A= Method (_SRS, 1, NotSerialized)=0A= {=0A= CreateByteField (Arg0, 0x01, IRF1)=0A= CreateByteField (Arg0, 0x02, IRF2)=0A= ShiftLeft (IRF2, 0x08, Local0)=0A= Or (Local0, IRF1, Local0)=0A= Store (0x00, Local1)=0A= ShiftRight (Local0, 0x01, Local0)=0A= While (LGreater (Local0, 0x00))=0A= {=0A= Increment (Local1)=0A= ShiftRight (Local0, 0x01, Local0)=0A= }=0A= =0A= Store (Local1, \_SB.PCI0.USB2.UIRQ)=0A= Store (Local1, \_SB.PCI0.USB2.UIRQ)=0A= }=0A= }=0A= =0A= Device (LNKG)=0A= {=0A= Name (_HID, EisaId ("PNP0C0F"))=0A= Name (_UID, 0x07)=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= Store (Zero, Local0)=0A= If (LNot (\_SB.PCI0.PX40.FNC5))=0A= {=0A= Store (One, Local0)=0A= }=0A= =0A= If (LNot (\_SB.PCI0.PX40.FNC6))=0A= {=0A= Store (One, Local0)=0A= }=0A= =0A= If (LNot (\_SB.PCI0.PX40.SU20))=0A= {=0A= Store (One, Local0)=0A= }=0A= =0A= If (Local0)=0A= {=0A= Return (0x0B)=0A= }=0A= =0A= Return (0x09)=0A= }=0A= =0A= Name (_PRS, ResourceTemplate ()=0A= {=0A= IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,9,10,11,12}=0A= })=0A= Method (_DIS, 0, NotSerialized)=0A= {=0A= Store (Zero, \_SB.PCI0.AC97.PIRQ)=0A= Store (Zero, \_SB.PCI0.MC97.PIRQ)=0A= Store (Zero, \_SB.PCI0.SU20.PIRQ)=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUFG, ResourceTemplate ()=0A= {=0A= IRQ (Level, ActiveLow, Shared) {}=0A= })=0A= CreateWordField (BUFG, 0x01, IRG)=0A= If (LNot (\_SB.PCI0.PX40.FNC5))=0A= {=0A= Store (\_SB.PCI0.AC97.PIRQ, Local0)=0A= }=0A= =0A= If (LNot (\_SB.PCI0.PX40.FNC6))=0A= {=0A= Store (\_SB.PCI0.MC97.PIRQ, Local0)=0A= }=0A= =0A= If (LNot (\_SB.PCI0.PX40.SU20))=0A= {=0A= Store (\_SB.PCI0.SU20.PIRQ, Local0)=0A= }=0A= =0A= ShiftLeft (One, Local0, Local1)=0A= Store (Local1, IRG)=0A= Return (BUFG)=0A= }=0A= =0A= Method (_SRS, 1, NotSerialized)=0A= {=0A= CreateByteField (Arg0, 0x01, IRG1)=0A= CreateByteField (Arg0, 0x02, IRG2)=0A= ShiftLeft (IRG2, 0x08, Local0)=0A= Or (Local0, IRG1, Local0)=0A= Store (0x00, Local1)=0A= ShiftRight (Local0, 0x01, Local0)=0A= While (LGreater (Local0, 0x00))=0A= {=0A= Increment (Local1)=0A= ShiftRight (Local0, 0x01, Local0)=0A= }=0A= =0A= Store (Local1, \_SB.PCI0.AC97.PIRQ)=0A= Store (Local1, \_SB.PCI0.MC97.PIRQ)=0A= Store (Local1, \_SB.PCI0.SU20.PIRQ)=0A= }=0A= }=0A= =0A= Device (LNKH)=0A= {=0A= Name (_HID, EisaId ("PNP0C0F"))=0A= Name (_UID, 0x08)=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= If (LNot (\_SB.PCI0.PX40.USBC))=0A= {=0A= Return (0x0B)=0A= }=0A= =0A= Return (0x09)=0A= }=0A= =0A= Name (_PRS, ResourceTemplate ()=0A= {=0A= IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,9,10,11,12}=0A= })=0A= Method (_DIS, 0, NotSerialized)=0A= {=0A= Store (Zero, \_SB.PCI0.USBC.PIRQ)=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUFH, ResourceTemplate ()=0A= {=0A= IRQ (Level, ActiveLow, Shared) {}=0A= })=0A= CreateWordField (BUFH, 0x01, IRH)=0A= Store (\_SB.PCI0.USBC.PIRQ, Local0)=0A= ShiftLeft (One, Local0, Local1)=0A= Store (Local1, IRH)=0A= Return (BUFH)=0A= }=0A= =0A= Method (_SRS, 1, NotSerialized)=0A= {=0A= CreateByteField (Arg0, 0x01, IRH1)=0A= CreateByteField (Arg0, 0x02, IRH2)=0A= ShiftLeft (IRH2, 0x08, Local0)=0A= Or (Local0, IRH1, Local0)=0A= Store (0x00, Local1)=0A= ShiftRight (Local0, 0x01, Local0)=0A= While (LGreater (Local0, 0x00))=0A= {=0A= Increment (Local1)=0A= ShiftRight (Local0, 0x01, Local0)=0A= }=0A= =0A= Store (Local1, \_SB.PCI0.USBC.PIRQ)=0A= }=0A= }=0A= =0A= Device (PCI0)=0A= {=0A= Name (_HID, EisaId ("PNP0A03"))=0A= Name (_ADR, 0x00)=0A= OperationRegion (TMP0, PCI_Config, 0x80, 0x20)=0A= Field (TMP0, ByteAcc, NoLock, Preserve)=0A= {=0A= AG80, 32, =0A= Offset (0x05), =0A= Offset (0x06), =0A= Offset (0x07), =0A= Offset (0x08), =0A= AG88, 32, =0A= Offset (0x0D), =0A= Offset (0x0E), =0A= Offset (0x0F), =0A= Offset (0x10), =0A= AG90, 32, =0A= AG94, 32, =0A= AG98, 32=0A= }=0A= =0A= Method (_INI, 0, NotSerialized)=0A= {=0A= Store (0x00, OSFL)=0A= If (LEqual (SCMP (\_OS, "Microsoft Windows NT"), Zero))=0A= {=0A= Store (0x02, OSFL)=0A= }=0A= =0A= If (LEqual (SCMP (\_OS, "Microsoft Windows"), Zero))=0A= {=0A= Store (0x01, OSFL)=0A= }=0A= =0A= If (LEqual (SCMP (\_OS, "Microsoft WindowsME: Millennium = Edition"), Zero))=0A= {=0A= Store (0x03, OSFL)=0A= }=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (CRES, ResourceTemplate ()=0A= {=0A= WordBusNumber (ResourceProducer, MinFixed, MaxFixed, = PosDecode,=0A= 0x0000,=0A= 0x0000,=0A= 0x00FF,=0A= 0x0000,=0A= 0x0100)=0A= IO (Decode16, 0x0CF8, 0x0CF8, 0x01, 0x08)=0A= WordIO (ResourceProducer, MinFixed, MaxFixed, = PosDecode, EntireRange,=0A= 0x0000,=0A= 0x0000,=0A= 0x0CF7,=0A= 0x0000,=0A= 0x0CF8)=0A= WordIO (ResourceProducer, MinFixed, MaxFixed, = PosDecode, EntireRange,=0A= 0x0000,=0A= 0x0D00,=0A= 0xFFFF,=0A= 0x0000,=0A= 0xF300)=0A= DWordMemory (ResourceProducer, PosDecode, MinFixed, = MaxFixed, Cacheable, ReadWrite,=0A= 0x00000000,=0A= 0x000A0000,=0A= 0x000BFFFF,=0A= 0x00000000,=0A= 0x00020000)=0A= DWordMemory (ResourceProducer, PosDecode, MinFixed, = MaxFixed, Cacheable, ReadWrite,=0A= 0x00000000,=0A= 0x000C8000,=0A= 0x000DFFFF,=0A= 0x00000000,=0A= 0x00018000)=0A= DWordMemory (ResourceProducer, PosDecode, MinFixed, = MaxFixed, Cacheable, ReadWrite,=0A= 0x00000000,=0A= 0x00100000,=0A= 0xFEBFFFFF,=0A= 0x00000000,=0A= 0xFEB00000)=0A= })=0A= CreateDWordField (CRES, 0x76, RAMT)=0A= CreateDWordField (CRES, 0x82, RAMR)=0A= Store (MEMS (), RAMT)=0A= ShiftLeft (RAMT, 0x14, RAMT)=0A= Subtract (0xFEBFFFFF, RAMT, RAMR)=0A= Increment (RAMR)=0A= Return (CRES)=0A= }=0A= =0A= Name (PICM, Package (0x21)=0A= {=0A= Package (0x04)=0A= {=0A= 0x000CFFFF, =0A= 0x00, =0A= \_SB.LNKD, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000CFFFF, =0A= 0x01, =0A= \_SB.LNKA, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000CFFFF, =0A= 0x02, =0A= \_SB.LNKB, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000CFFFF, =0A= 0x03, =0A= \_SB.LNKC, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000DFFFF, =0A= 0x00, =0A= \_SB.LNKA, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000DFFFF, =0A= 0x01, =0A= \_SB.LNKB, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000DFFFF, =0A= 0x02, =0A= \_SB.LNKC, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000DFFFF, =0A= 0x03, =0A= \_SB.LNKD, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000EFFFF, =0A= 0x00, =0A= \_SB.LNKB, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000EFFFF, =0A= 0x01, =0A= \_SB.LNKC, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000EFFFF, =0A= 0x02, =0A= \_SB.LNKD, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000EFFFF, =0A= 0x03, =0A= \_SB.LNKA, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0013FFFF, =0A= 0x00, =0A= \_SB.LNKC, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0013FFFF, =0A= 0x01, =0A= \_SB.LNKD, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0013FFFF, =0A= 0x02, =0A= \_SB.LNKA, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0013FFFF, =0A= 0x03, =0A= \_SB.LNKB, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000BFFFF, =0A= 0x00, =0A= \_SB.LNKD, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000BFFFF, =0A= 0x01, =0A= \_SB.LNKA, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000BFFFF, =0A= 0x02, =0A= \_SB.LNKB, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000BFFFF, =0A= 0x03, =0A= \_SB.LNKC, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000AFFFF, =0A= 0x00, =0A= \_SB.LNKA, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000AFFFF, =0A= 0x01, =0A= \_SB.LNKB, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000AFFFF, =0A= 0x02, =0A= \_SB.LNKC, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000AFFFF, =0A= 0x03, =0A= \_SB.LNKD, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000FFFFF, =0A= 0x00, =0A= \_SB.LNKE, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000FFFFF, =0A= 0x01, =0A= \_SB.LNKF, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0010FFFF, =0A= 0x00, =0A= \_SB.LNKE, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0010FFFF, =0A= 0x01, =0A= \_SB.LNKF, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0010FFFF, =0A= 0x02, =0A= \_SB.LNKG, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0010FFFF, =0A= 0x03, =0A= \_SB.LNKH, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0011FFFF, =0A= 0x02, =0A= \_SB.LNKG, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0011FFFF, =0A= 0x03, =0A= \_SB.LNKH, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0012FFFF, =0A= 0x00, =0A= \_SB.LNKE, =0A= 0x00=0A= }=0A= })=0A= Name (APIC, Package (0x21)=0A= {=0A= Package (0x04)=0A= {=0A= 0x000CFFFF, =0A= 0x00, =0A= 0x00, =0A= 0x13=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000CFFFF, =0A= 0x01, =0A= 0x00, =0A= 0x10=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000CFFFF, =0A= 0x02, =0A= 0x00, =0A= 0x11=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000CFFFF, =0A= 0x03, =0A= 0x00, =0A= 0x12=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000DFFFF, =0A= 0x00, =0A= 0x00, =0A= 0x10=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000DFFFF, =0A= 0x01, =0A= 0x00, =0A= 0x11=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000DFFFF, =0A= 0x02, =0A= 0x00, =0A= 0x12=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000DFFFF, =0A= 0x03, =0A= 0x00, =0A= 0x13=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000EFFFF, =0A= 0x00, =0A= 0x00, =0A= 0x11=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000EFFFF, =0A= 0x01, =0A= 0x00, =0A= 0x12=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000EFFFF, =0A= 0x02, =0A= 0x00, =0A= 0x13=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000EFFFF, =0A= 0x03, =0A= 0x00, =0A= 0x10=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0013FFFF, =0A= 0x00, =0A= 0x00, =0A= 0x12=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0013FFFF, =0A= 0x01, =0A= 0x00, =0A= 0x13=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0013FFFF, =0A= 0x02, =0A= 0x00, =0A= 0x10=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0013FFFF, =0A= 0x03, =0A= 0x00, =0A= 0x11=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000BFFFF, =0A= 0x00, =0A= 0x00, =0A= 0x13=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000BFFFF, =0A= 0x01, =0A= 0x00, =0A= 0x10=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000BFFFF, =0A= 0x02, =0A= 0x00, =0A= 0x11=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000BFFFF, =0A= 0x03, =0A= 0x00, =0A= 0x12=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000AFFFF, =0A= 0x00, =0A= 0x00, =0A= 0x10=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000AFFFF, =0A= 0x01, =0A= 0x00, =0A= 0x11=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000AFFFF, =0A= 0x02, =0A= 0x00, =0A= 0x12=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000AFFFF, =0A= 0x03, =0A= 0x00, =0A= 0x13=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000FFFFF, =0A= 0x00, =0A= 0x00, =0A= 0x14=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x000FFFFF, =0A= 0x01, =0A= 0x00, =0A= 0x14=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0010FFFF, =0A= 0x00, =0A= 0x00, =0A= 0x15=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0010FFFF, =0A= 0x01, =0A= 0x00, =0A= 0x15=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0010FFFF, =0A= 0x02, =0A= 0x00, =0A= 0x15=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0010FFFF, =0A= 0x03, =0A= 0x00, =0A= 0x15=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0011FFFF, =0A= 0x02, =0A= 0x00, =0A= 0x16=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0011FFFF, =0A= 0x03, =0A= 0x00, =0A= 0x16=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0x0012FFFF, =0A= 0x00, =0A= 0x00, =0A= 0x17=0A= }=0A= })=0A= Method (_PRT, 0, NotSerialized)=0A= {=0A= If (LNot (\PICF))=0A= {=0A= Return (PICM)=0A= }=0A= Else=0A= {=0A= Return (APIC)=0A= }=0A= }=0A= =0A= Device (PCI1)=0A= {=0A= Name (_ADR, 0x00010000)=0A= Method (S_3D, 0, NotSerialized)=0A= {=0A= If (LEqual (SCMP (\_OS, "Microsoft Windows NT"), = Zero))=0A= {=0A= Return (0x03)=0A= }=0A= =0A= If (LEqual (SCMP (\_OS, "Microsoft Windows"), Zero))=0A= {=0A= Return (0x03)=0A= }=0A= Else=0A= {=0A= Return (0x02)=0A= }=0A= }=0A= =0A= Method (_PRW, 0, NotSerialized)=0A= {=0A= Return (Package (0x02)=0A= {=0A= 0x0B, =0A= 0x04=0A= })=0A= }=0A= =0A= Name (PICM, Package (0x02)=0A= {=0A= Package (0x04)=0A= {=0A= 0xFFFF, =0A= 0x00, =0A= \_SB.LNKA, =0A= 0x00=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0xFFFF, =0A= 0x01, =0A= \_SB.LNKB, =0A= 0x00=0A= }=0A= })=0A= Name (APIC, Package (0x02)=0A= {=0A= Package (0x04)=0A= {=0A= 0xFFFF, =0A= 0x00, =0A= 0x00, =0A= 0x10=0A= }, =0A= =0A= Package (0x04)=0A= {=0A= 0xFFFF, =0A= 0x01, =0A= 0x00, =0A= 0x11=0A= }=0A= })=0A= Method (_PRT, 0, NotSerialized)=0A= {=0A= If (LNot (\PICF))=0A= {=0A= Return (PICM)=0A= }=0A= Else=0A= {=0A= Return (APIC)=0A= }=0A= }=0A= }=0A= =0A= Scope (\_SB)=0A= {=0A= OperationRegion (PIDE, SystemIO, 0x03F6, 0x01)=0A= Field (PIDE, ByteAcc, NoLock, Preserve)=0A= {=0A= , 3, =0A= HMMM, 1, =0A= , 3, =0A= PBSY, 1=0A= }=0A= =0A= OperationRegion (SIDE, SystemIO, 0x0376, 0x01)=0A= Field (SIDE, ByteAcc, NoLock, Preserve)=0A= {=0A= , 3, =0A= RMMM, 1, =0A= , 3, =0A= SBSY, 1=0A= }=0A= }=0A= =0A= Device (IDE0)=0A= {=0A= Name (_ADR, 0x000F0001)=0A= Name (PIOT, Package (0x05)=0A= {=0A= 0x0258, =0A= 0x017C, =0A= 0xF0, =0A= 0xB4, =0A= 0x78=0A= })=0A= Name (UDMT, Package (0x07)=0A= {=0A= 0x78, =0A= 0x50, =0A= 0x3C, =0A= 0x2D, =0A= 0x1E, =0A= 0x14, =0A= 0x0F=0A= })=0A= Method (CVDR, 3, NotSerialized)=0A= {=0A= Name (GTFB, Buffer (0x0E)=0A= {=0A= 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0xEF, 0x03, =0A= 0x00, 0x00, 0x00, 0x00, 0x00, 0xEF=0A= })=0A= CreateByteField (GTFB, 0x01, MDDM)=0A= CreateByteField (GTFB, 0x05, DRDM)=0A= CreateByteField (GTFB, 0x08, MDPI)=0A= CreateByteField (GTFB, 0x0C, DRPI)=0A= If (LNot (LEqual (Arg1, 0x0F)))=0A= {=0A= Or (Arg1, 0x40, MDDM)=0A= }=0A= Else=0A= {=0A= Store (Arg0, Local0)=0A= Subtract (Local0, 0x02, Local0)=0A= Or (Local0, 0x20, MDDM)=0A= }=0A= =0A= Store (Arg2, DRDM)=0A= Or (Arg0, 0x08, MDPI)=0A= Store (Arg2, DRPI)=0A= Return (GTFB)=0A= }=0A= =0A= Method (SUDM, 3, NotSerialized)=0A= {=0A= And (Arg2, 0x01, Local0)=0A= If (Local0)=0A= {=0A= Store (0x04, Local0)=0A= }=0A= Else=0A= {=0A= Store (0x01, Local0)=0A= }=0A= =0A= And (Arg0, Local0, Local0)=0A= If (Local0)=0A= {=0A= Store (Match (UDMT, MEQ, Arg1, MTR, 0x00, 0x00), = Local0)=0A= If (LNot (LEqual (Local0, Ones)))=0A= {=0A= Store (Arg2, TRD0)=0A= Store (Local0, TRD1)=0A= ISMI (0x08)=0A= }=0A= }=0A= Else=0A= {=0A= Store (Arg2, TRD0)=0A= Store (0xFF, TRD1)=0A= ISMI (0x08)=0A= }=0A= }=0A= =0A= Method (GTMC, 4, NotSerialized)=0A= {=0A= Name (BU00, Buffer (0x14)=0A= {=0A= 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, =0A= 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, =0A= 0x00, 0x00, 0x00, 0x00=0A= })=0A= CreateDWordField (BU00, 0x00, PIO0)=0A= CreateDWordField (BU00, 0x04, DMA0)=0A= CreateDWordField (BU00, 0x08, PIO1)=0A= CreateDWordField (BU00, 0x0C, DMA1)=0A= CreateDWordField (BU00, 0x10, FLAG)=0A= Store (0x10, FLAG)=0A= If (LNot (LEqual (Arg0, 0x0F)))=0A= {=0A= Store (DerefOf (Index (PIOT, Arg0)), PIO0)=0A= Or (FLAG, 0x02, FLAG)=0A= }=0A= =0A= If (LNot (LEqual (Arg1, 0x0F)))=0A= {=0A= Store (DerefOf (Index (UDMT, Arg1)), DMA0)=0A= Or (FLAG, 0x01, FLAG)=0A= }=0A= Else=0A= {=0A= Store (PIO0, DMA0)=0A= }=0A= =0A= If (LNot (LEqual (Arg2, 0x0F)))=0A= {=0A= Store (DerefOf (Index (PIOT, Arg2)), PIO1)=0A= Or (FLAG, 0x08, FLAG)=0A= }=0A= =0A= If (LNot (LEqual (Arg3, 0x0F)))=0A= {=0A= Store (DerefOf (Index (UDMT, Arg3)), DMA1)=0A= Or (FLAG, 0x04, FLAG)=0A= }=0A= Else=0A= {=0A= Store (PIO1, DMA1)=0A= }=0A= =0A= Return (BU00)=0A= }=0A= =0A= Device (CHN0)=0A= {=0A= Name (_ADR, 0x00)=0A= Method (_GTM, 0, NotSerialized)=0A= {=0A= Return (GTMC (HCPI, HCUD, HDPI, HDUD))=0A= }=0A= =0A= Method (_STM, 3, NotSerialized)=0A= {=0A= CreateDWordField (Arg0, 0x00, PIO0)=0A= CreateDWordField (Arg0, 0x04, DMA0)=0A= CreateDWordField (Arg0, 0x08, PIO1)=0A= CreateDWordField (Arg0, 0x0C, DMA1)=0A= CreateDWordField (Arg0, 0x10, FLAG)=0A= SUDM (FLAG, DMA0, 0x00)=0A= SUDM (FLAG, DMA1, 0x01)=0A= }=0A= =0A= Device (DRV0)=0A= {=0A= Name (_ADR, 0x00)=0A= Method (_GTF, 0, NotSerialized)=0A= {=0A= While (LOr (LEqual (\_SB.PBSY, 0x01), LEqual = (\_SB.HMMM, 0x01)))=0A= {=0A= Sleep (0x64)=0A= }=0A= =0A= Return (CVDR (HCPI, HCUD, 0xA0))=0A= }=0A= }=0A= =0A= Device (DRV1)=0A= {=0A= Name (_ADR, 0x01)=0A= Method (_GTF, 0, NotSerialized)=0A= {=0A= While (LOr (LEqual (\_SB.PBSY, 0x01), LEqual = (\_SB.HMMM, 0x01)))=0A= {=0A= Sleep (0x64)=0A= }=0A= =0A= Return (CVDR (HDPI, HDUD, 0xB0))=0A= }=0A= }=0A= }=0A= =0A= Device (CHN1)=0A= {=0A= Name (_ADR, 0x01)=0A= Method (_GTM, 0, NotSerialized)=0A= {=0A= Return (GTMC (HEPI, HEUD, HFPI, HFUD))=0A= }=0A= =0A= Method (_STM, 3, NotSerialized)=0A= {=0A= CreateDWordField (Arg0, 0x00, PIO0)=0A= CreateDWordField (Arg0, 0x04, DMA0)=0A= CreateDWordField (Arg0, 0x08, PIO1)=0A= CreateDWordField (Arg0, 0x0C, DMA1)=0A= CreateDWordField (Arg0, 0x10, FLAG)=0A= SUDM (FLAG, DMA0, 0x02)=0A= SUDM (FLAG, DMA1, 0x03)=0A= }=0A= =0A= Device (DRV0)=0A= {=0A= Name (_ADR, 0x00)=0A= Method (_GTF, 0, NotSerialized)=0A= {=0A= While (LOr (LEqual (\_SB.SBSY, 0x01), LEqual = (\_SB.RMMM, 0x01)))=0A= {=0A= Sleep (0x64)=0A= }=0A= =0A= Return (CVDR (HEPI, HEUD, 0xA0))=0A= }=0A= }=0A= =0A= Device (DRV1)=0A= {=0A= Name (_ADR, 0x01)=0A= Method (_GTF, 0, NotSerialized)=0A= {=0A= While (LOr (LEqual (\_SB.SBSY, 0x01), LEqual = (\_SB.RMMM, 0x01)))=0A= {=0A= Sleep (0x64)=0A= }=0A= =0A= Return (CVDR (HFPI, HFUD, 0xB0))=0A= }=0A= }=0A= }=0A= }=0A= =0A= Device (PX40)=0A= {=0A= Name (_ADR, 0x00110000)=0A= OperationRegion (SIRQ, PCI_Config, 0x44, 0x01)=0A= Field (SIRQ, ByteAcc, NoLock, Preserve)=0A= {=0A= RSCI, 3=0A= }=0A= =0A= OperationRegion (USBE, PCI_Config, 0x50, 0x02)=0A= Field (USBE, ByteAcc, NoLock, Preserve)=0A= {=0A= UPT3, 1, =0A= SU20, 1, =0A= UPT2, 1, =0A= SATA, 1, =0A= UPT0, 1, =0A= UPT1, 1, =0A= FNC5, 1, =0A= FNC6, 1, =0A= , 4, =0A= SLEN, 1, =0A= , 2, =0A= USBC, 1=0A= }=0A= =0A= OperationRegion (PIRQ, PCI_Config, 0x55, 0x03)=0A= Field (PIRQ, ByteAcc, NoLock, Preserve)=0A= {=0A= , 4, =0A= PIRA, 4, =0A= PIRB, 4, =0A= PIRC, 4, =0A= , 4, =0A= PIRD, 4=0A= }=0A= =0A= Method (SPIC, 0, NotSerialized)=0A= {=0A= }=0A= =0A= Device (SBIO)=0A= {=0A= Name (_HID, EisaId ("PNP0C02"))=0A= Name (_UID, 0x04)=0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUF1, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0xE400, 0xE400, 0x01, 0x80)=0A= IO (Decode16, 0xE800, 0xE800, 0x01, 0x20)=0A= Memory32Fixed (ReadOnly, 0xFFF80000, = 0x00080000)=0A= Memory32Fixed (ReadOnly, 0xFFB80000, = 0x00080000)=0A= })=0A= Return (BUF1)=0A= }=0A= }=0A= =0A= Device (SYS1)=0A= {=0A= Name (_HID, EisaId ("PNP0C02"))=0A= Name (_UID, 0x01)=0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUF1, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0x0010, 0x0010, 0x00, 0x10)=0A= IO (Decode16, 0x0022, 0x0022, 0x00, 0x0C)=0A= IO (Decode16, 0x0030, 0x0030, 0x00, 0x10)=0A= IO (Decode16, 0x0044, 0x0044, 0x00, 0x1C)=0A= IO (Decode16, 0x0062, 0x0062, 0x00, 0x02)=0A= IO (Decode16, 0x0065, 0x0065, 0x00, 0x0B)=0A= IO (Decode16, 0x0074, 0x0074, 0x00, 0x0C)=0A= IO (Decode16, 0x0091, 0x0091, 0x00, 0x03)=0A= IO (Decode16, 0x00A2, 0x00A2, 0x00, 0x1E)=0A= IO (Decode16, 0x00E0, 0x00E0, 0x00, 0x10)=0A= IO (Decode16, 0x04D0, 0x04D0, 0x00, 0x02)=0A= })=0A= Return (BUF1)=0A= }=0A= }=0A= =0A= Device (SYS3)=0A= {=0A= Name (_HID, EisaId ("PNP0C02"))=0A= Name (_UID, 0x02)=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= And (NPS2, 0x10, Local0)=0A= And (NPS2, 0x08, Local1)=0A= If (LEqual (Local1, 0x08))=0A= {=0A= If (LEqual (Local0, 0x10))=0A= {=0A= Return (0x0F)=0A= }=0A= Else=0A= {=0A= Return (0x00)=0A= }=0A= }=0A= Else=0A= {=0A= And (FLG0, 0x04, Local1)=0A= If (LEqual (Local1, 0x04))=0A= {=0A= Return (0x00)=0A= }=0A= Else=0A= {=0A= If (LEqual (Local0, 0x10))=0A= {=0A= Return (0x0F)=0A= }=0A= Else=0A= {=0A= Return (0x00)=0A= }=0A= }=0A= }=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUF1, ResourceTemplate ()=0A= {=0A= IRQ (Edge, ActiveHigh, Exclusive) {12}=0A= })=0A= Return (BUF1)=0A= }=0A= }=0A= =0A= Device (PSMR)=0A= {=0A= Name (_HID, EisaId ("PNP0C02"))=0A= Name (_UID, 0x06)=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= And (NPS2, 0x01, Local0)=0A= And (NPS2, 0x08, Local1)=0A= If (LEqual (Local0, Zero))=0A= {=0A= Return (0x00)=0A= }=0A= Else=0A= {=0A= If (LEqual (Local1, 0x00))=0A= {=0A= If (LEqual (SCMP (\_OS, "Microsoft = Windows"), Zero))=0A= {=0A= Return (0x0F)=0A= }=0A= Else=0A= {=0A= If (LEqual (SCMP (\_OS, "Microsoft = Windows NT"), Zero))=0A= {=0A= Return (0x00)=0A= }=0A= Else=0A= {=0A= Return (0x0F)=0A= }=0A= }=0A= }=0A= Else=0A= {=0A= Return (0x0F)=0A= }=0A= }=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUF1, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0x0060, 0x0060, 0x00, 0x01)=0A= IO (Decode16, 0x0064, 0x0064, 0x00, 0x01)=0A= })=0A= Return (BUF1)=0A= }=0A= }=0A= =0A= Device (PIC)=0A= {=0A= Name (_HID, EisaId ("PNP0000"))=0A= Name (_CRS, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0x0020, 0x0020, 0x01, 0x02)=0A= IO (Decode16, 0x00A0, 0x00A0, 0x01, 0x02)=0A= IRQNoFlags () {2}=0A= })=0A= }=0A= =0A= Device (DMA1)=0A= {=0A= Name (_HID, EisaId ("PNP0200"))=0A= Name (_CRS, ResourceTemplate ()=0A= {=0A= DMA (Compatibility, BusMaster, Transfer8) {4}=0A= IO (Decode16, 0x0000, 0x0000, 0x01, 0x10)=0A= IO (Decode16, 0x0080, 0x0080, 0x01, 0x11)=0A= IO (Decode16, 0x0094, 0x0094, 0x01, 0x0C)=0A= IO (Decode16, 0x00C0, 0x00C0, 0x01, 0x20)=0A= })=0A= }=0A= =0A= Device (TMR)=0A= {=0A= Name (_HID, EisaId ("PNP0100"))=0A= Name (_CRS, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0x0040, 0x0040, 0x01, 0x04)=0A= IRQNoFlags () {0}=0A= })=0A= }=0A= =0A= Device (RTC)=0A= {=0A= Name (_HID, EisaId ("PNP0B00"))=0A= Name (_CRS, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0x0070, 0x0070, 0x01, 0x04)=0A= IRQNoFlags () {8}=0A= })=0A= }=0A= =0A= Device (SPKR)=0A= {=0A= Name (_HID, EisaId ("PNP0800"))=0A= Name (_CRS, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0x0061, 0x0061, 0x01, 0x01)=0A= })=0A= }=0A= =0A= Device (COPR)=0A= {=0A= Name (_HID, EisaId ("PNP0C04"))=0A= Name (_CRS, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0x00F0, 0x00F0, 0x01, 0x10)=0A= IRQNoFlags () {13}=0A= })=0A= }=0A= =0A= Device (FDC0)=0A= {=0A= Name (_HID, EisaId ("PNP0700"))=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= ISMI (0x0A)=0A= Store (INFO, Local0)=0A= Release (PSMX)=0A= CreateByteField (Local0, 0x00, FSTA)=0A= Return (FSTA)=0A= }=0A= =0A= Method (_DIS, 0, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= ISMI (0x0B)=0A= Release (PSMX)=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUF0, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0x03F2, 0x03F2, 0x00, 0x04)=0A= IO (Decode16, 0x03F7, 0x03F7, 0x00, 0x01)=0A= IRQ (Edge, ActiveHigh, Exclusive) {6}=0A= DMA (Compatibility, NotBusMaster, Transfer8) = {2}=0A= })=0A= Return (BUF0)=0A= }=0A= =0A= Name (_PRS, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0x03F2, 0x03F2, 0x00, 0x04)=0A= IO (Decode16, 0x03F7, 0x03F7, 0x00, 0x01)=0A= IRQ (Edge, ActiveHigh, Exclusive) {6}=0A= DMA (Compatibility, NotBusMaster, Transfer8) {2}=0A= })=0A= Method (_SRS, 1, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= Store (Arg0, INFO)=0A= ISMI (0x0E)=0A= Release (PSMX)=0A= }=0A= }=0A= =0A= Device (LPT)=0A= {=0A= Name (_HID, EisaId ("PNP0400"))=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= ISMI (0x0F)=0A= Store (INFO, Local0)=0A= Release (PSMX)=0A= CreateByteField (Local0, 0x00, FSTA)=0A= Return (FSTA)=0A= }=0A= =0A= Method (_DIS, 0, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= ISMI (0x10)=0A= Release (PSMX)=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUF0, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0x0378, 0x0378, 0x00, 0x08)=0A= IRQ (Edge, ActiveHigh, Exclusive) {7}=0A= })=0A= Acquire (PSMX, 0xFFFF)=0A= Store (BUF0, INFO)=0A= ISMI (0x11)=0A= Store (INFO, Local0)=0A= Release (PSMX)=0A= Return (Local0)=0A= }=0A= =0A= Name (_PRS, ResourceTemplate ()=0A= {=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x0378, 0x0378, 0x00, 0x08)=0A= IRQ (Edge, ActiveHigh, Exclusive) {5,7}=0A= }=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x0278, 0x0278, 0x00, 0x08)=0A= IRQ (Edge, ActiveHigh, Exclusive) {5,7}=0A= }=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x03BC, 0x03BC, 0x00, 0x04)=0A= IRQ (Edge, ActiveHigh, Exclusive) {5,7}=0A= }=0A= EndDependentFn ()=0A= })=0A= Method (_SRS, 1, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= Store (Arg0, INFO)=0A= ISMI (0x13)=0A= Release (PSMX)=0A= }=0A= }=0A= =0A= Device (ECP)=0A= {=0A= Name (_HID, EisaId ("PNP0401"))=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= ISMI (0x14)=0A= Store (INFO, Local0)=0A= Release (PSMX)=0A= CreateByteField (Local0, 0x00, FSTA)=0A= Return (FSTA)=0A= }=0A= =0A= Method (_DIS, 0, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= ISMI (0x10)=0A= Release (PSMX)=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUF0, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0x0378, 0x0378, 0x00, 0x08)=0A= IO (Decode16, 0x0778, 0x0778, 0x00, 0x04)=0A= IRQ (Edge, ActiveHigh, Exclusive) {7}=0A= DMA (Compatibility, NotBusMaster, Transfer8) = {1}=0A= })=0A= Acquire (PSMX, 0xFFFF)=0A= Store (BUF0, INFO)=0A= ISMI (0x16)=0A= Store (INFO, Local0)=0A= Release (PSMX)=0A= Return (Local0)=0A= }=0A= =0A= Name (_PRS, ResourceTemplate ()=0A= {=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x0378, 0x0378, 0x00, 0x08)=0A= IO (Decode16, 0x0778, 0x0778, 0x00, 0x04)=0A= IRQ (Edge, ActiveHigh, Exclusive) {5,7}=0A= DMA (Compatibility, NotBusMaster, Transfer8) = {0,1,3}=0A= }=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x0278, 0x0278, 0x00, 0x08)=0A= IO (Decode16, 0x0678, 0x0678, 0x00, 0x04)=0A= IRQ (Edge, ActiveHigh, Exclusive) {5,7}=0A= DMA (Compatibility, NotBusMaster, Transfer8) = {0,1,3}=0A= }=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x03BC, 0x03BC, 0x00, 0x04)=0A= IO (Decode16, 0x07BC, 0x07BC, 0x00, 0x04)=0A= IRQ (Edge, ActiveHigh, Exclusive) {5,7}=0A= DMA (Compatibility, NotBusMaster, Transfer8) = {0,1,3}=0A= }=0A= EndDependentFn ()=0A= })=0A= Method (_SRS, 1, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= Store (Arg0, INFO)=0A= ISMI (0x18)=0A= Release (PSMX)=0A= }=0A= }=0A= =0A= Device (UAR1)=0A= {=0A= Name (_HID, EisaId ("PNP0501"))=0A= Name (_UID, 0x01)=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= ISMI (0x19)=0A= Store (INFO, Local0)=0A= Release (PSMX)=0A= CreateByteField (Local0, 0x00, FSTA)=0A= Return (FSTA)=0A= }=0A= =0A= Method (_DIS, 0, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= ISMI (0x1A)=0A= Release (PSMX)=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUF0, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0x03F8, 0x03F8, 0x00, 0x08)=0A= IRQ (Edge, ActiveHigh, Exclusive) {4}=0A= })=0A= Acquire (PSMX, 0xFFFF)=0A= Store (BUF0, INFO)=0A= ISMI (0x1B)=0A= Store (INFO, Local0)=0A= Release (PSMX)=0A= Return (Local0)=0A= }=0A= =0A= Name (_PRS, ResourceTemplate ()=0A= {=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x03F8, 0x03F8, 0x00, 0x08)=0A= IRQ (Edge, ActiveHigh, Exclusive) {4}=0A= }=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x02F8, 0x02F8, 0x00, 0x08)=0A= IRQ (Edge, ActiveHigh, Exclusive) {3}=0A= }=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x03E8, 0x03E8, 0x00, 0x08)=0A= IRQ (Edge, ActiveHigh, Exclusive) {4}=0A= }=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x02E8, 0x02E8, 0x00, 0x08)=0A= IRQ (Edge, ActiveHigh, Exclusive) {10}=0A= }=0A= EndDependentFn ()=0A= })=0A= Method (_SRS, 1, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= Store (Arg0, INFO)=0A= ISMI (0x1D)=0A= Release (PSMX)=0A= }=0A= }=0A= =0A= Device (UAR2)=0A= {=0A= Name (_HID, EisaId ("PNP0501"))=0A= Name (_UID, 0x02)=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= ISMI (0x1E)=0A= Store (INFO, Local0)=0A= Release (PSMX)=0A= CreateByteField (Local0, 0x00, FSTA)=0A= Return (FSTA)=0A= }=0A= =0A= Method (_DIS, 0, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= ISMI (0x1F)=0A= Release (PSMX)=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUF0, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0x02F8, 0x02F8, 0x00, 0x08)=0A= IRQ (Edge, ActiveHigh, Exclusive) {3}=0A= })=0A= Acquire (PSMX, 0xFFFF)=0A= Store (BUF0, INFO)=0A= ISMI (0x20)=0A= Store (INFO, Local0)=0A= Release (PSMX)=0A= Return (Local0)=0A= }=0A= =0A= Name (_PRS, ResourceTemplate ()=0A= {=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x02F8, 0x02F8, 0x00, 0x08)=0A= IRQ (Edge, ActiveHigh, Exclusive) {3}=0A= }=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x03F8, 0x03F8, 0x00, 0x08)=0A= IRQ (Edge, ActiveHigh, Exclusive) {4}=0A= }=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x03E8, 0x03E8, 0x00, 0x08)=0A= IRQ (Edge, ActiveHigh, Exclusive) {4}=0A= }=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x02E8, 0x02E8, 0x00, 0x08)=0A= IRQ (Edge, ActiveHigh, Exclusive) {10}=0A= }=0A= EndDependentFn ()=0A= })=0A= Method (_SRS, 1, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= Store (Arg0, INFO)=0A= ISMI (0x22)=0A= Release (PSMX)=0A= }=0A= }=0A= =0A= Device (IRDA)=0A= {=0A= Name (_HID, EisaId ("PNP0510"))=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= ISMI (0x23)=0A= Store (INFO, Local0)=0A= Release (PSMX)=0A= CreateByteField (Local0, 0x00, FSTA)=0A= Return (FSTA)=0A= }=0A= =0A= Method (_DIS, 0, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= ISMI (0x24)=0A= Release (PSMX)=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUF0, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0x02F8, 0x02F8, 0x00, 0x08)=0A= IRQ (Edge, ActiveHigh, Exclusive) {3}=0A= })=0A= Acquire (PSMX, 0xFFFF)=0A= Store (BUF0, INFO)=0A= ISMI (0x25)=0A= Store (INFO, Local0)=0A= Release (PSMX)=0A= Return (Local0)=0A= }=0A= =0A= Name (_PRS, ResourceTemplate ()=0A= {=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x02F8, 0x02F8, 0x00, 0x08)=0A= IRQ (Edge, ActiveHigh, Exclusive) {3}=0A= }=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x03F8, 0x03F8, 0x00, 0x08)=0A= IRQ (Edge, ActiveHigh, Exclusive) {4}=0A= }=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x03E8, 0x03E8, 0x00, 0x08)=0A= IRQ (Edge, ActiveHigh, Exclusive) {4}=0A= }=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x02E8, 0x02E8, 0x00, 0x08)=0A= IRQ (Edge, ActiveHigh, Exclusive) {10}=0A= }=0A= EndDependentFn ()=0A= })=0A= Method (_SRS, 1, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= Store (Arg0, INFO)=0A= ISMI (0x27)=0A= Release (PSMX)=0A= }=0A= }=0A= =0A= Device (PS2K)=0A= {=0A= Name (_HID, EisaId ("PNP0303"))=0A= Name (_CID, 0x0B03D041)=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= And (NPS2, 0x01, Local0)=0A= If (LEqual (Local0, 0x01))=0A= {=0A= Return (0x00)=0A= }=0A= Else=0A= {=0A= Return (0x0F)=0A= }=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUF0, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0x0060, 0x0060, 0x00, 0x01)=0A= IO (Decode16, 0x0064, 0x0064, 0x00, 0x01)=0A= IRQ (Edge, ActiveHigh, Exclusive) {1}=0A= })=0A= Return (BUF0)=0A= }=0A= }=0A= =0A= Device (PS2M)=0A= {=0A= Name (_HID, EisaId ("PNP0F03"))=0A= Name (_CID, 0x130FD041)=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= And (NPS2, 0x08, Local0)=0A= If (LEqual (Local0, 0x08))=0A= {=0A= Return (0x00)=0A= }=0A= =0A= And (FLG0, 0x04, Local1)=0A= If (LEqual (Local1, 0x04))=0A= {=0A= Return (0x0F)=0A= }=0A= Else=0A= {=0A= Return (0x00)=0A= }=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUF1, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0x0060, 0x0060, 0x00, 0x01)=0A= IO (Decode16, 0x0064, 0x0064, 0x00, 0x01)=0A= IRQ (Edge, ActiveHigh, Exclusive) {12}=0A= })=0A= Name (BUF2, ResourceTemplate ()=0A= {=0A= IRQ (Edge, ActiveHigh, Exclusive) {12}=0A= })=0A= And (NPS2, 0x01, Local0)=0A= If (LEqual (Local0, 0x01))=0A= {=0A= If (LEqual (SCMP (\_OS, "Microsoft = Windows"), Zero))=0A= {=0A= Return (BUF2)=0A= }=0A= Else=0A= {=0A= If (LEqual (SCMP (\_OS, "Microsoft = Windows NT"), Zero))=0A= {=0A= Return (BUF1)=0A= }=0A= Else=0A= {=0A= Return (BUF2)=0A= }=0A= }=0A= }=0A= Else=0A= {=0A= Return (BUF2)=0A= }=0A= }=0A= }=0A= =0A= Device (MIDI)=0A= {=0A= Name (_HID, EisaId ("PNPB006"))=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= ISMI (0x28)=0A= Store (INFO, Local0)=0A= Release (PSMX)=0A= CreateByteField (Local0, 0x00, FSTA)=0A= Return (FSTA)=0A= }=0A= =0A= Method (_DIS, 0, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= ISMI (0x29)=0A= Release (PSMX)=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUF0, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0x0300, 0x0300, 0x00, 0x02)=0A= IRQ (Edge, ActiveHigh, Exclusive) {5}=0A= })=0A= Acquire (PSMX, 0xFFFF)=0A= Store (BUF0, INFO)=0A= ISMI (0x2A)=0A= Store (INFO, Local0)=0A= Release (PSMX)=0A= Return (Local0)=0A= }=0A= =0A= Name (_PRS, ResourceTemplate ()=0A= {=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x0330, 0x0330, 0x00, 0x02)=0A= IRQ (Edge, ActiveHigh, Exclusive) = {3,4,5,7,10,12}=0A= }=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x0300, 0x0300, 0x00, 0x02)=0A= IRQ (Edge, ActiveHigh, Exclusive) = {3,4,5,7,10,12}=0A= }=0A= EndDependentFn ()=0A= })=0A= Method (_SRS, 1, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= Store (Arg0, INFO)=0A= ISMI (0x2C)=0A= Release (PSMX)=0A= }=0A= }=0A= =0A= Device (GAME)=0A= {=0A= Name (_HID, EisaId ("PNPB02F"))=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= ISMI (0x2D)=0A= Store (INFO, Local0)=0A= Release (PSMX)=0A= CreateByteField (Local0, 0x00, FSTA)=0A= Return (FSTA)=0A= }=0A= =0A= Method (_DIS, 0, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= ISMI (0x2E)=0A= Release (PSMX)=0A= }=0A= =0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUF0, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0x0208, 0x0208, 0x00, 0x08)=0A= })=0A= Acquire (PSMX, 0xFFFF)=0A= Store (BUF0, INFO)=0A= ISMI (0x2F)=0A= Store (INFO, Local0)=0A= Release (PSMX)=0A= Return (Local0)=0A= }=0A= =0A= Name (_PRS, ResourceTemplate ()=0A= {=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x0208, 0x0208, 0x00, 0x08)=0A= }=0A= StartDependentFn (0x01, 0x01)=0A= {=0A= IO (Decode16, 0x0200, 0x0200, 0x00, 0x08)=0A= }=0A= EndDependentFn ()=0A= })=0A= Method (_SRS, 1, NotSerialized)=0A= {=0A= Acquire (PSMX, 0xFFFF)=0A= Store (Arg0, INFO)=0A= ISMI (0x31)=0A= Release (PSMX)=0A= }=0A= }=0A= =0A= Device (SYS2)=0A= {=0A= Name (_HID, EisaId ("PNP0C02"))=0A= Name (_UID, 0x03)=0A= Method (_CRS, 0, NotSerialized)=0A= {=0A= Name (BUF0, ResourceTemplate ()=0A= {=0A= IO (Decode16, 0x002E, 0x002E, 0x00, 0x02)=0A= IO (Decode16, 0x0290, 0x0290, 0x00, 0x08)=0A= IO (Decode16, 0x0370, 0x0370, 0x00, 0x06)=0A= })=0A= Return (BUF0)=0A= }=0A= }=0A= }=0A= =0A= Device (USB0)=0A= {=0A= Name (_ADR, 0x00100000)=0A= OperationRegion (TEMP, PCI_Config, 0x3C, 0x01)=0A= Field (TEMP, ByteAcc, NoLock, Preserve)=0A= {=0A= UIRQ, 4=0A= }=0A= =0A= Method (S_3D, 0, NotSerialized)=0A= {=0A= If (LEqual (SCMP (\_OS, "Microsoft Windows NT"), = Zero))=0A= {=0A= Return (0x03)=0A= }=0A= =0A= If (LEqual (SCMP (\_OS, "Microsoft Windows"), Zero))=0A= {=0A= Return (0x03)=0A= }=0A= Else=0A= {=0A= Return (0x02)=0A= }=0A= }=0A= =0A= Method (_PRW, 0, NotSerialized)=0A= {=0A= Return (Package (0x02)=0A= {=0A= 0x0E, =0A= 0x04=0A= })=0A= }=0A= }=0A= =0A= Device (USB1)=0A= {=0A= Name (_ADR, 0x00100001)=0A= OperationRegion (PIRQ, PCI_Config, 0x3C, 0x01)=0A= Field (PIRQ, ByteAcc, NoLock, Preserve)=0A= {=0A= UIRQ, 4=0A= }=0A= =0A= Method (S_3D, 0, NotSerialized)=0A= {=0A= If (LEqual (SCMP (\_OS, "Microsoft Windows NT"), = Zero))=0A= {=0A= Return (0x03)=0A= }=0A= =0A= If (LEqual (SCMP (\_OS, "Microsoft Windows"), Zero))=0A= {=0A= Return (0x03)=0A= }=0A= Else=0A= {=0A= Return (0x02)=0A= }=0A= }=0A= =0A= Method (_PRW, 0, NotSerialized)=0A= {=0A= Return (Package (0x02)=0A= {=0A= 0x0E, =0A= 0x04=0A= })=0A= }=0A= }=0A= =0A= Device (USB2)=0A= {=0A= Name (_ADR, 0x00100002)=0A= OperationRegion (PIRQ, PCI_Config, 0x3C, 0x01)=0A= Field (PIRQ, ByteAcc, NoLock, Preserve)=0A= {=0A= UIRQ, 4=0A= }=0A= =0A= Method (S_3D, 0, NotSerialized)=0A= {=0A= If (LEqual (SCMP (\_OS, "Microsoft Windows NT"), = Zero))=0A= {=0A= Return (0x03)=0A= }=0A= =0A= If (LEqual (SCMP (\_OS, "Microsoft Windows"), Zero))=0A= {=0A= Return (0x03)=0A= }=0A= Else=0A= {=0A= Return (0x02)=0A= }=0A= }=0A= =0A= Method (_PRW, 0, NotSerialized)=0A= {=0A= Return (Package (0x02)=0A= {=0A= 0x0E, =0A= 0x04=0A= })=0A= }=0A= }=0A= =0A= Device (USB3)=0A= {=0A= Name (_ADR, 0x00100003)=0A= OperationRegion (PIRQ, PCI_Config, 0x3C, 0x01)=0A= Field (PIRQ, ByteAcc, NoLock, Preserve)=0A= {=0A= UIRQ, 4=0A= }=0A= =0A= Method (S_3D, 0, NotSerialized)=0A= {=0A= If (LEqual (SCMP (\_OS, "Microsoft Windows NT"), = Zero))=0A= {=0A= Return (0x03)=0A= }=0A= =0A= If (LEqual (SCMP (\_OS, "Microsoft Windows"), Zero))=0A= {=0A= Return (0x03)=0A= }=0A= Else=0A= {=0A= Return (0x02)=0A= }=0A= }=0A= =0A= Method (_PRW, 0, NotSerialized)=0A= {=0A= Return (Package (0x02)=0A= {=0A= 0x0E, =0A= 0x04=0A= })=0A= }=0A= }=0A= =0A= Device (SU20)=0A= {=0A= Name (_ADR, 0x00100004)=0A= OperationRegion (TEMP, PCI_Config, 0x3C, 0x01)=0A= Field (TEMP, ByteAcc, NoLock, Preserve)=0A= {=0A= PIRQ, 4=0A= }=0A= =0A= Method (S_3D, 0, NotSerialized)=0A= {=0A= If (LEqual (SCMP (\_OS, "Microsoft Windows NT"), = Zero))=0A= {=0A= Return (0x03)=0A= }=0A= =0A= If (LEqual (SCMP (\_OS, "Microsoft Windows"), Zero))=0A= {=0A= Return (0x03)=0A= }=0A= Else=0A= {=0A= Return (0x02)=0A= }=0A= }=0A= =0A= Method (_PRW, 0, NotSerialized)=0A= {=0A= Return (Package (0x02)=0A= {=0A= 0x0E, =0A= 0x04=0A= })=0A= }=0A= }=0A= =0A= Device (USBC)=0A= {=0A= Name (_ADR, 0x00100005)=0A= OperationRegion (TEMP, PCI_Config, 0x3C, 0x01)=0A= Field (TEMP, ByteAcc, NoLock, Preserve)=0A= {=0A= PIRQ, 4=0A= }=0A= }=0A= =0A= Device (SATA)=0A= {=0A= Name (_ADR, 0x000F0000)=0A= OperationRegion (SAPR, PCI_Config, 0x00, 0xC2)=0A= Field (SAPR, ByteAcc, NoLock, Preserve)=0A= {=0A= VID, 16, =0A= Offset (0x04), =0A= CMDR, 3, =0A= Offset (0x3C), =0A= UIRQ, 4, =0A= Offset (0x49), =0A= , 6, =0A= EPHY, 1=0A= }=0A= =0A= Method (_STA, 0, NotSerialized)=0A= {=0A= If (LNot (LEqual (\_SB.PCI0.SATA.VID, 0x1106)))=0A= {=0A= Return (0x00)=0A= }=0A= Else=0A= {=0A= If (LEqual (\_SB.PCI0.SATA.CMDR, 0x00))=0A= {=0A= Return (0x0D)=0A= }=0A= Else=0A= {=0A= Return (0x0F)=0A= }=0A= }=0A= }=0A= =0A= Name (REGF, 0x01)=0A= Method (_REG, 2, NotSerialized)=0A= {=0A= If (LEqual (Arg0, 0x02))=0A= {=0A= Store (Arg1, REGF)=0A= }=0A= }=0A= =0A= Name (TIM0, Package (0x04)=0A= {=0A= Package (0x05)=0A= {=0A= 0x78, =0A= 0xB4, =0A= 0xF0, =0A= 0x017F, =0A= 0x0258=0A= }, =0A= =0A= Package (0x05)=0A= {=0A= 0x20, =0A= 0x22, =0A= 0x33, =0A= 0x47, =0A= 0x5D=0A= }, =0A= =0A= Package (0x07)=0A= {=0A= 0x78, =0A= 0x50, =0A= 0x3C, =0A= 0x2D, =0A= 0x1E, =0A= 0x14, =0A= 0x0F=0A= }, =0A= =0A= Package (0x0F)=0A= {=0A= 0x06, =0A= 0x05, =0A= 0x04, =0A= 0x04, =0A= 0x03, =0A= 0x03, =0A= 0x02, =0A= 0x02, =0A= 0x01, =0A= 0x01, =0A= 0x01, =0A= 0x01, =0A= 0x01, =0A= 0x01, =0A= 0x00=0A= }=0A= })=0A= Name (TMD0, Buffer (0x14) {})=0A= CreateDWordField (TMD0, 0x00, PIO0)=0A= CreateDWordField (TMD0, 0x04, DMA0)=0A= CreateDWordField (TMD0, 0x08, PIO1)=0A= CreateDWordField (TMD0, 0x0C, DMA1)=0A= CreateDWordField (TMD0, 0x10, CHNF)=0A= Name (PMPT, 0x20)=0A= Name (PMUE, 0x07)=0A= Name (PMUT, 0x00)=0A= Name (PSPT, 0x20)=0A= Name (PSUE, 0x07)=0A= Name (PSUT, 0x00)=0A= Name (SMPT, 0x20)=0A= Name (SMUE, 0x07)=0A= Name (SMUT, 0x00)=0A= Name (SSPT, 0x20)=0A= Name (SSUE, 0x07)=0A= Name (SSUT, 0x00)=0A= Device (CHN0)=0A= {=0A= Name (_ADR, 0x00)=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= Return (0x0F)=0A= }=0A= =0A= Method (_GTM, 0, NotSerialized)=0A= {=0A= Return (GTM (PMPT, PMUE, PMUT, PSPT, PSUE, PSUT))=0A= }=0A= =0A= Method (_STM, 3, NotSerialized)=0A= {=0A= }=0A= =0A= Device (DRV0)=0A= {=0A= Name (_ADR, 0x00)=0A= Method (_GTF, 0, NotSerialized)=0A= {=0A= }=0A= }=0A= =0A= Device (DRV1)=0A= {=0A= Name (_ADR, 0x01)=0A= Method (_GTF, 0, NotSerialized)=0A= {=0A= }=0A= }=0A= }=0A= =0A= Device (CHN1)=0A= {=0A= Name (_ADR, 0x01)=0A= Method (_STA, 0, NotSerialized)=0A= {=0A= Return (0x0F)=0A= }=0A= =0A= Method (_GTM, 0, NotSerialized)=0A= {=0A= Return (GTM (SMPT, SMUE, SMUT, SSPT, SSUE, SSUT))=0A= }=0A= =0A= Method (_STM, 3, NotSerialized)=0A= {=0A= }=0A= =0A= Device (DRV0)=0A= {=0A= Name (_ADR, 0x00)=0A= Method (_GTF, 0, NotSerialized)=0A= {=0A= }=0A= }=0A= =0A= Device (DRV1)=0A= {=0A= Name (_ADR, 0x01)=0A= Method (_GTF, 0, NotSerialized)=0A= {=0A= }=0A= }=0A= }=0A= =0A= Method (GTM, 6, Serialized)=0A= {=0A= Store (Ones, PIO0)=0A= Store (Ones, PIO1)=0A= Store (Ones, DMA0)=0A= Store (Ones, DMA1)=0A= Store (0x10, CHNF)=0A= If (REGF) {}=0A= Else=0A= {=0A= Return (TMD0)=0A= }=0A= =0A= Store (Match (DerefOf (Index (TIM0, 0x01)), MEQ, = Arg0, MTR, 0x00, 0x00), Local6)=0A= Store (DerefOf (Index (DerefOf (Index (TIM0, 0x00)), = Local6)), Local7)=0A= Store (Local7, DMA0)=0A= Store (Local7, PIO0)=0A= Store (Match (DerefOf (Index (TIM0, 0x01)), MEQ, = Arg3, MTR, 0x00, 0x00), Local6)=0A= Store (DerefOf (Index (DerefOf (Index (TIM0, 0x00)), = Local6)), Local7)=0A= Store (Local7, DMA1)=0A= Store (Local7, PIO1)=0A= If (Arg1)=0A= {=0A= Store (DerefOf (Index (DerefOf (Index (TIM0, = 0x03)), Arg2)), Local5)=0A= Store (DerefOf (Index (DerefOf (Index (TIM0, = 0x02)), Local5)), DMA0)=0A= Or (CHNF, 0x01, CHNF)=0A= }=0A= =0A= If (Arg4)=0A= {=0A= Store (DerefOf (Index (DerefOf (Index (TIM0, = 0x03)), Arg5)), Local5)=0A= Store (DerefOf (Index (DerefOf (Index (TIM0, = 0x02)), Local5)), DMA1)=0A= Or (CHNF, 0x04, CHNF)=0A= }=0A= =0A= Return (TMD0)=0A= }=0A= }=0A= =0A= Device (AC97)=0A= {=0A= Name (_ADR, 0x00110005)=0A= OperationRegion (AIRQ, PCI_Config, 0x3C, 0x01)=0A= Field (AIRQ, ByteAcc, NoLock, Preserve)=0A= {=0A= PIRQ, 4=0A= }=0A= }=0A= =0A= Device (MC97)=0A= {=0A= Name (_ADR, 0x00110006)=0A= Method (S_3D, 0, NotSerialized)=0A= {=0A= If (LEqual (SCMP (\_OS, "Microsoft Windows NT"), = Zero))=0A= {=0A= Return (0x03)=0A= }=0A= =0A= If (LEqual (SCMP (\_OS, "Microsoft Windows"), Zero))=0A= {=0A= Return (0x03)=0A= }=0A= Else=0A= {=0A= Return (0x02)=0A= }=0A= }=0A= =0A= OperationRegion (MIRQ, PCI_Config, 0x3C, 0x01)=0A= Field (MIRQ, ByteAcc, NoLock, Preserve)=0A= {=0A= PIRQ, 4=0A= }=0A= =0A= Method (_PRW, 0, NotSerialized)=0A= {=0A= Return (Package (0x02)=0A= {=0A= 0x0D, =0A= 0x04=0A= })=0A= }=0A= }=0A= =0A= Device (SLAN)=0A= {=0A= Name (_ADR, 0x00120000)=0A= Method (S_3D, 0, NotSerialized)=0A= {=0A= If (LEqual (SCMP (\_OS, "Microsoft Windows NT"), = Zero))=0A= {=0A= Return (0x03)=0A= }=0A= =0A= If (LEqual (SCMP (\_OS, "Microsoft Windows"), Zero))=0A= {=0A= Return (0x03)=0A= }=0A= Else=0A= {=0A= Return (0x02)=0A= }=0A= }=0A= =0A= OperationRegion (TEMP, PCI_Config, 0x3C, 0x01)=0A= Field (TEMP, ByteAcc, NoLock, Preserve)=0A= {=0A= PIRQ, 4=0A= }=0A= =0A= Method (_PRW, 0, NotSerialized)=0A= {=0A= Return (Package (0x02)=0A= {=0A= 0x03, =0A= 0x04=0A= })=0A= }=0A= }=0A= =0A= Method (S_3D, 0, NotSerialized)=0A= {=0A= If (LEqual (SCMP (\_OS, "Microsoft Windows NT"), Zero))=0A= {=0A= Return (0x03)=0A= }=0A= =0A= If (LEqual (SCMP (\_OS, "Microsoft Windows"), Zero))=0A= {=0A= Return (0x03)=0A= }=0A= Else=0A= {=0A= Return (0x02)=0A= }=0A= }=0A= =0A= Method (_PRW, 0, NotSerialized)=0A= {=0A= Return (Package (0x02)=0A= {=0A= 0x0B, =0A= 0x04=0A= })=0A= }=0A= }=0A= }=0A= =0A= Scope (\_GPE)=0A= {=0A= Method (_L0E, 0, NotSerialized)=0A= {=0A= Notify (\_SB.PCI0.USB0, 0x02)=0A= Notify (\_SB.PCI0.USB1, 0x02)=0A= }=0A= =0A= Method (_L0B, 0, NotSerialized)=0A= {=0A= Notify (\_SB.PCI0, 0x02)=0A= }=0A= =0A= Method (_L03, 0, NotSerialized)=0A= {=0A= Notify (\_SB.PCI0.SLAN, 0x02)=0A= }=0A= =0A= Method (_L0D, 0, NotSerialized)=0A= {=0A= Notify (\_SB.PCI0.MC97, 0x02)=0A= }=0A= }=0A= }=0A= =0A= ------=_NextPart_000_000B_01C480A1.8339F4C0-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 17:21:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B242016A4DA; Thu, 12 Aug 2004 17:21:19 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 549B243D49; Thu, 12 Aug 2004 17:21:19 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7CHLH8U028736; Thu, 12 Aug 2004 10:21:17 -0700 Message-ID: <411BA70D.7010804@root.org> Date: Thu, 12 Aug 2004 10:21:17 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: ACPI mpsafe patch for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 17:21:19 -0000 I plan to commit the mpsafe patch for acpi on Friday morning. No problems so far for testers and I've run it for weeks (versions of it for months). The only change I've made is to update it against commits so it will apply cleanly. Please test if you get a chance. Again the URL: http://root.org/~nate/freebsd/acpi_mpsafe.diff.gz -Nate From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 17:23:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 466E816A4CE for ; Thu, 12 Aug 2004 17:23:02 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 852DB43D2F for ; Thu, 12 Aug 2004 17:23:01 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 205 invoked from network); 12 Aug 2004 17:16:46 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Aug 2004 17:16:46 -0000 Message-ID: <411BA773.4090204@freebsd.org> Date: Thu, 12 Aug 2004 19:22:59 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Lewis References: <200408121709.i7CH98H8020875@gw.catspoiler.org> In-Reply-To: <200408121709.i7CH98H8020875@gw.catspoiler.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@FreeBSD.org cc: mb@imp.ch cc: rwatson@FreeBSD.org Subject: Re: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 17:23:02 -0000 Don Lewis wrote: > On 12 Aug, Martin Blapp wrote: >> >>Here is more information: (thanks robert for the help) >> >>>Fatal trap 12: page fault while in kernel mode >>>cpuid = 1; apic id = 01 >>>fault virtual address = 0x14 >>>fault code = supervisor write, page not present >>>instruction pointer = 0x8:0xc066a1c7 >>>stack pointer = 0x10:0xe2626aa8 >>>frame pointer = 0x10:0xe2626ab8 >>>code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, def32 1, gran 1 >>>processor eflags = interrupt enabled, resume, IOPL = 0 >>>current process = 27897 (mimedefang) >>> >> >>db> where >>unp_connect2(c4bb78a4,c39cc13c,0,0,0) at /usr/src/sys/kern/uipc_usrreq.c:892 >>unp_connect(c4bb78a4,c43d9380,c4dee9a0,c43d9380,80) at /usr/src/sys/kern/uipc_usrreq.c:865 >>uipc_connect(c4bb78a4,c43d9380,c4dee9a0) at /usr/src/sys/kern/uipc_usrreq.c:179 >>soconnect(c4bb78a4,c43d9380,c4dee9a0,0,bf1dad88) at /usr/src/sys/kern/uipc_socket.c:518 >>kern_connect(c4dee9a0,3,c43d9380,c43d9380,c3e958ac) at /usr/src/sys/kern/uipc_syscalls.c:477 >>connect(c4dee9a0,e2626d14,c,c4dee9a0,e2626d3c) at connect+0x42 >>syscall(2f,2f,2f,bf1dad88,bf1dad8a) at syscall+0x300 >>Xint0x80_syscall() at Xint0x80_syscall+0x1f >>--- syscall (98, FreeBSD ELF32, connect), eip = 0x28101d23, esp = 0xbf1dad74, ebp = 0xbf1dae10 --- >> >>src/sys/kern/uipc_syscalls.c,v 1.199 >>src/sys/kern/uipc_usrreq.c,v 1.135 >>src/sys/kern/uipc_socket.c,v 1.207 >> >>(gdb) l *unp_connect2+0x2a >>0x1f93 is in unp_connect2 (/usr/src/sys/kern/uipc_usrreq.c:892). >>887 UNP_LOCK_ASSERT(); >>888 >>889 if (so2->so_type != so->so_type) >>890 return (EPROTOTYPE); >>891 unp2 = sotounpcb(so2); >>892 unp->unp_conn = unp2; >>893 switch (so->so_type) { >>894 >>895 case SOCK_DGRAM: >>896 LIST_INSERT_HEAD(&unp2->unp_refs, unp, unp_reflink); > > > Looks like unp is NULL here. > > My first suspicion would be the recent memory allocation changes that > affected the type safety of various dynamically allocated data > structures, though I'm not sure that fits the symptoms. I have backed out the change this morning (GMT) because of concernes of this. It looks like the code accesses free'd memory or uninitialized memory. This might have worked in the SPL days but today with SMP it's tough. You never know if the free'd memory has been allocated again already somewhere else even if it is type-stable. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 17:27:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BAFB16A4CE for ; Thu, 12 Aug 2004 17:27:45 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AD2E43D41 for ; Thu, 12 Aug 2004 17:27:45 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7CHRf8U028827; Thu, 12 Aug 2004 10:27:41 -0700 Message-ID: <411BA88D.6070000@root.org> Date: Thu, 12 Aug 2004 10:27:41 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Cox References: <411B0226.3030806@root.org> <20040812054959.GF3527@cs.rice.edu> In-Reply-To: <20040812054959.GF3527@cs.rice.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: LoR aironet/VM subsystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 17:27:45 -0000 Alan Cox wrote: > On Wed, Aug 11, 2004 at 10:37:42PM -0700, Nate Lawson wrote: > >>an0: at port >>0x2000-0x203f irq 11 function 0 config 5 on pccard1 >>an0: got RSSI <-> dBM map >>an0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps >>an0: Ethernet address: 00:40:96:42:91:c5 >>an0: [GIANT-LOCKED] >>lock order reversal >> 1st 0xc163339c an0 (network driver) @ dev/an/if_an.c:1931 >> 2nd 0xc134b164 user map (user map) @ vm/vm_map.c:2902 >>KDB: stack backtrace: >>kdb_backtrace(0,ffffffff,c0696d88,c0697a08,c066630c) at kdb_backtrace+0x29 >>witness_checkorder(c134b164,9,c06469a0,b56) at witness_checkorder+0x544 >>_sx_xlock(c134b164,c0646997,b56) at _sx_xlock+0x50 >>_vm_map_lock_read(c134b128,c0646997,b56,1b69978,c1402e4c) at >>_vm_map_lock_read+0x33 >>vm_map_lookup(d0b69a10,bfbfd000,1,d0b69a14,d0b69a04) at vm_map_lookup+0x28 >>vm_fault(c134b128,bfbfd000,1,0,c1371840) at vm_fault+0x66 >>trap_pfault(d0b69ad8,0,bfbfd000) at trap_pfault+0xd2 >>trap(c04f0018,c06b0010,c1630010,c1633df4,bfbfd000) at trap+0x311 >>calltrap() at calltrap+0x5 >>--- trap 0xc, eip = 0xc060661e, esp = 0xd0b69b18, ebp = 0xd0b69ba4 --- >>generic_copyin(c1632000,c020693a,d0b69c60,c04d4b78,c06bb8e0) at >>generic_copyin+0x32 >>ifhwioctl(c020693a,c1632000,d0b69c60,c1371840,c0698048) at ifhwioctl+0x854 >>ifioctl(c16219e0,c020693a,d0b69c60,c1371840,0) at ifioctl+0xbd >>soo_ioctl(c158f440,c020693a,d0b69c60,c133c480,c1371840) at soo_ioctl+0x2b1 >>ioctl(c1371840,d0b69d14,3,2,292) at ioctl+0x3e0 >>syscall(2f,2f,2f,3,bfbfef64) at syscall+0x217 >>Xint0x80_syscall() at Xint0x80_syscall+0x1f >>--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280d0083, esp = >>0xbfbfad7c, ebp = 0xbfbfadb8 --- >> > > This looks like a programming error in the driver. Specifically, > the driver is calling copyin() while holding a mutex. That's not > allowed because of the potential for a page fault that sleeps. It is. AN_LOCK is held over the entire contents of an_ioctl(). This function is so huge, it's unclear how to reduce the scope of this lock. -Nate From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 17:34:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D05B16A4CE for ; Thu, 12 Aug 2004 17:34:27 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 400CF43D31 for ; Thu, 12 Aug 2004 17:34:27 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 10243 invoked from network); 12 Aug 2004 17:34:26 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Aug 2004 17:34:26 -0000 Received: from hydrogen.funkthat.com (ipknwl@localhost.funkthat.com [127.0.0.1])i7CHYQuU026731 for ; Thu, 12 Aug 2004 10:34:26 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i7CHYQWj026730 for freebsd-current@FreeBSD.org; Thu, 12 Aug 2004 10:34:26 -0700 (PDT) Date: Thu, 12 Aug 2004 10:34:26 -0700 From: John-Mark Gurney To: freebsd-current@FreeBSD.org Message-ID: <20040812173415.GF991@funkthat.com> Mail-Followup-To: freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: HEADSUP: problems loading modules? solution inside X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2004 17:34:27 -0000 Sorry, as it was pointed out, I forgot to include HEADSUP in the subject line. Here it is again. Thanks to Ruslan Ermilov (ru@) for discovering the fix for the problem of loading modules. The entry from UPDATING: Module loading has been fixed. Some older installations will drop proper module_path initialization and modules will fail to load properly. If you have a line in /boot/loader.rc that says: "initialize drop", do (i386 only): cp /usr/src/sys/boot/i386/loader/loader.rc /boot/loader.rc chown root:wheel /boot/loader.rc chmod 444 /boot/loader.rc -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 17:40:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A389616A4CE for ; Thu, 12 Aug 2004 17:40:07 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9D5143D48 for ; Thu, 12 Aug 2004 17:40:06 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BvJYR-0004Ei-00; Thu, 12 Aug 2004 19:39:55 +0200 Received: from [217.83.7.130] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BvJYQ-0004w1-00; Thu, 12 Aug 2004 19:39:55 +0200 From: Max Laier To: Sangwoo Shim Date: Thu, 12 Aug 2004 19:37:51 +0200 User-Agent: KMail/1.6.2 References: <20040812171410.GA91666@neo.redjade.org> In-Reply-To: <20040812171410.GA91666@neo.redjade.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_8r6GBKvOD6flFTm"; charset="euc-kr" Content-Transfer-Encoding: 7bit Message-Id: <200408121938.04611.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: freebsd-current@freebsd.org cc: yongari@kt-is.co.kr Subject: Re: Panic in nd6_slowtimo() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 17:40:07 -0000 --Boundary-02=_8r6GBKvOD6flFTm Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline This was reported before, but I was never able to reproduce it and the=20 original reporter didn't reply anymore (iirc). Can you please turn this int= o=20 a PR so that we do not lose track this time? I will be looking into it. Thanks. On Thursday 12 August 2004 19:14, Sangwoo Shim wrote: > [ FreeBSD-current list rejects my mail. So, to pf maintainers.. ] > > I recently got this panic. 1~2 times in a day. > It seems that pflog is the culprit.. pflog0's if_afdata contains > nothing but null. I couldn't reproduce the panic with pf.ko unloaded. > option INET6 is in kernel configuration. > The machine is SMP. If you need more information, please let me know. > I'm using FreeBSD-current of Aug 12. > > panic messages: > --- > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 01 > fault virtual address =3D 0x8 > fault code =3D supervisor read, page not present > instruction pointer =3D 0x8:0xc056ec72 > stack pointer =3D 0x10:0xd53efcb8 > frame pointer =3D 0x10:0xd53efcc4 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 37 (swi5: clock sio) > Dumping 511 MB > 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 > 336 352 368 384 400 416 432 448 464 480 496 --- > #0 doadump () at pcpu.h:159 > 159 pcpu.h: No such file or directory. > in pcpu.h > doadump () at pcpu.h:159 > 159 in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:159 > #1 0xc043b83a in db_fncall (dummy1=3D0, dummy2=3D0, dummy3=3D-717292800, > dummy4=3D0xd53efae8 "\034=FB=BE=D5=A2) at /usr/src/sys/ddb/db_command= =2Ec:531 > #2 0xc043b648 in db_command (last_cmdp=3D0xc069cea4, cmd_table=3D0x0, > aux_cmd_tablep=3D0xc066cc44, aux_cmd_tablep_end=3D0xc066cc48) > at /usr/src/sys/ddb/db_command.c:349 > #3 0xc043b710 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 > #4 0xc043d289 in db_trap (type=3D12, code=3D0) at > /usr/src/sys/ddb/db_main.c:221 #5 0xc04d9020 in kdb_trap (type=3D12, cod= e=3D0, > tf=3D0xd53efc78) > at /usr/src/sys/kern/subr_kdb.c:401 > #6 0xc062795d in trap_fatal (frame=3D0xd53efc78, eva=3D8) > at /usr/src/sys/i386/i386/trap.c:807 > #7 0xc06276bb in trap_pfault (frame=3D0xd53efc78, usermode=3D0, eva=3D8) > at /usr/src/sys/i386/i386/trap.c:730 > #8 0xc06272d1 in trap (frame=3D > {tf_fs =3D -1045626856, tf_es =3D -717357040, tf_ds =3D -717357040,= tf_edi > =3D -1045585920, tf_esi =3D -1045508608, tf_ebp =3D -717292348, tf_isp =3D > -717292380, tf_ebx =3D 23040, tf_edx =3D 1474, tf_ecx =3D -1066723816, tf= _eax =3D > 0, tf_trapno =3D 12, tf_err =3D 0, tf_eip =3D -1068045198, tf_cs =3D 8, t= f_eflags =3D > 66182, tf_esp =3D 6, tf_ss =3D 4}) at /usr/src/sys/i386/i386/trap.c:417 #= 9=20 > 0xc0615b1a in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #10 > 0xc1ad0018 in ?? () > #11 0xd53e0010 in ?? () > #12 0xd53e0010 in ?? () > #13 0xc1ada000 in ?? () > #14 0xc1aece00 in ?? () > #15 0xd53efcc4 in ?? () > #16 0xd53efca4 in ?? () > #17 0x00005a00 in ?? () > #18 0x000005c2 in ?? () > #19 0xc06b1618 in arc4_sbox () > #20 0x00000000 in ?? () > #21 0x0000000c in ?? () > #22 0x00000000 in ?? () > #23 0xc056ec72 in nd6_slowtimo (ignored_arg=3D0x0) > at /usr/src/sys/netinet6/nd6.c:1800 > #24 0xc04cd05b in softclock (dummy=3D0x0) at > /usr/src/sys/kern/kern_timeout.c:259 #25 0xc04ab6bd in ithread_loop > (arg=3D0xc1977c00) > at /usr/src/sys/kern/kern_intr.c:546 > #26 0xc04aa7fd in fork_exit (callout=3D0xc04ab564 , > arg=3D0xc1977c00, frame=3D0xd53efd48) at /usr/src/sys/kern/kern_fork.= c:819 > #27 0xc0615b7c in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:209 (kgdb) up 23 > #23 0xc056ec72 in nd6_slowtimo (ignored_arg=3D0x0) > at /usr/src/sys/netinet6/nd6.c:1800 > 1800 nd6if =3D ND_IFINFO(ifp); > (kgdb) l > 1795 > 1796 callout_reset(&nd6_slowtimo_ch, ND6_SLOWTIMER_INTERVAL * > hz, 1797 nd6_slowtimo, NULL); > 1798 IFNET_RLOCK(); > 1799 for (ifp =3D TAILQ_FIRST(&ifnet); ifp; ifp =3D TAILQ_NEXT= (ifp, > if_list)) { 1800 nd6if =3D ND_IFINFO(ifp); > 1801 if (nd6if->basereachable && /* already initialized > */ 1802 (nd6if->recalctm -=3D ND6_SLOWTIMER_INTERV= AL) > <=3D 0) { 1803 /* > 1804 * Since reachable time rarely changes by > router (kgdb) p *ifp > $1 =3D {if_softc =3D 0xc1ada000, if_link =3D {tqe_next =3D 0xc1ae1800, > tqe_prev =3D 0xc1adb004}, > if_xname =3D "pflog0\000\000\000\000\000\000\000\000\000", > if_dname =3D 0xc077ee0d "pflog", if_dunit =3D 0, if_addrhead =3D { > tqh_first =3D 0xc1ae3e00, tqh_last =3D 0xc1ae3e60}, if_klist =3D { > slh_first =3D 0x0}, if_pcount =3D 0, if_carp =3D 0x0, if_bpf =3D 0x0, > if_index =3D 4, if_timer =3D 0, if_nvlans =3D 0, if_flags =3D 0, > if_capabilities =3D 0, if_capenable =3D 0, if_linkmib =3D 0x0, if_linkm= iblen =3D > 0, if_data =3D {ifi_type =3D 246 '=F6=A7, ifi_physical =3D 0 '\0', ifi_ad= drlen =3D 0 > '\0', ifi_hdrlen =3D 48 '0', ifi_link_state =3D 0 '\0', ifi_recvquota =3D= 0 '\0', > ifi_xmitquota =3D 0 '\0', ifi_mtu =3D 33208, ifi_metric =3D 0, ifi_baudra= te =3D 0, > ifi_ipackets =3D 0, ifi_ierrors =3D 0, ifi_opackets =3D 0, ifi_oerrors = =3D 0, > ifi_collisions =3D 0, ifi_ibytes =3D 0, ifi_obytes =3D 0, ifi_imcasts =3D= 0, > ifi_omcasts =3D 0, ifi_iqdrops =3D 0, ifi_noproto =3D 0, ifi_hwassist =3D= 0, > ifi_unused =3D 0, ifi_lastchange =3D {tv_sec =3D 1, tv_usec =3D 10464}}, > if_multiaddrs =3D {tqh_first =3D 0x0, tqh_last =3D 0xc1ada0a8}, if_amcoun= t =3D 0, > if_output =3D 0xc077d738, if_input =3D 0, if_start =3D 0xc077d69c, > if_ioctl =3D 0xc077d760, if_watchdog =3D 0, if_init =3D 0, if_resolvemu= lti =3D 0, > if_snd =3D {ifq_head =3D 0x0, ifq_tail =3D 0x0, ifq_len =3D 0, ifq_maxl= en =3D 50, > ifq_drops =3D 0, ifq_mtx =3D {mtx_object =3D {lo_class =3D 0xc067db3c, > lo_name =3D 0xc1ada00c "pflog0", lo_type =3D 0xc0657e7d "if send > queue", lo_flags =3D 196608, lo_list =3D {tqe_next =3D 0x0, tqe_prev =3D = 0x0}, > lo_witness =3D 0x0}, mtx_lock =3D 4, mtx_recurse =3D 0}, ifq_drv_head =3D= 0x0, > ifq_drv_tail =3D 0x0, ifq_drv_len =3D 0, ifq_drv_maxlen =3D 0, altq_type = =3D 0, > altq_flags =3D 0, altq_disc =3D 0x0, altq_ifp =3D 0xc1ada000, altq_enqueu= e =3D 0, > altq_dequeue =3D 0, altq_request =3D 0, altq_clfier =3D 0x0, altq_classif= y =3D 0, > altq_tbr =3D 0x0, altq_cdnr =3D 0x0}, if_broadcastaddr =3D 0x0, lltables = =3D 0x0, > if_label =3D 0x0, if_prefixhead =3D {tqh_first =3D 0x0, tqh_last =3D 0xc1= ada150}, > if_afdata =3D {0x0 }, if_afdata_initialized =3D 1, > if_afdata_mtx =3D {mtx_object =3D {lo_class =3D 0xc067db3c, > lo_name =3D 0xc0657e6d "if_afdata", lo_type =3D 0xc0657e6d "if_afda= ta", > lo_flags =3D 196608, lo_list =3D {tqe_next =3D 0x0, tqe_prev =3D 0x= 0}, > lo_witness =3D 0x0}, mtx_lock =3D 4, mtx_recurse =3D 0}, if_startta= sk =3D { > ta_link =3D {stqe_next =3D 0x0}, ta_pending =3D 0, ta_priority =3D 0, > ta_func =3D 0xc0527fb4 , ta_context =3D 0xc1ada000= }} > > Thanks. > - Sangwoo Shim =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_8r6GBKvOD6flFTm Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBG6r8XyyEoT62BG0RAnlHAJ9nA0IqjKtcYmG+J+7o3G2gbP1MqQCeNyxd ojDL/qKPxp3xTZwilm9tXbA= =nl83 -----END PGP SIGNATURE----- --Boundary-02=_8r6GBKvOD6flFTm-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 17:44:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A72D516A4CF for ; Thu, 12 Aug 2004 17:44:32 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAAD343D1F for ; Thu, 12 Aug 2004 17:44:31 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7CHiQNr043052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Aug 2004 20:44:26 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7CHiSGP078697 for freebsd-current@FreeBSD.org; Thu, 12 Aug 2004 20:44:28 +0300 (EEST) (envelope-from ru) Date: Thu, 12 Aug 2004 20:44:28 +0300 From: Ruslan Ermilov To: freebsd-current@FreeBSD.org Message-ID: <20040812174428.GA78676@ip.net.ua> References: <20040812173415.GF991@funkthat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline In-Reply-To: <20040812173415.GF991@funkthat.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new Subject: Re: HEADSUP: problems loading modules? solution inside X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 17:44:32 -0000 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 12, 2004 at 10:34:26AM -0700, John-Mark Gurney wrote: > Sorry, as it was pointed out, I forgot to include HEADSUP in the subject > line. Here it is again. >=20 > Thanks to Ruslan Ermilov (ru@) for discovering the fix for the problem of > loading modules. >=20 > The entry from UPDATING: > Module loading has been fixed. Some older installations will > drop proper module_path initialization and modules will fail to > load properly. If you have a line in /boot/loader.rc that says: > "initialize drop", do (i386 only): > cp /usr/src/sys/boot/i386/loader/loader.rc /boot/loader.rc > chown root:wheel /boot/loader.rc > chmod 444 /boot/loader.rc >=20 Also applies to AMD64 and PC98 users. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBG6x8qRfpzJluFF4RAgcpAKCMW4Ifds2/ciX8vDGhKcg578pOGQCfRXK7 vsWfzODwfNmTaJHr0wYHfL8= =Kx9F -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 17:51:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25C1C16A4CE for ; Thu, 12 Aug 2004 17:51:37 +0000 (GMT) Received: from green.homeunix.org (pcp04371970pcs.nrockv01.md.comcast.net [69.140.223.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DFB543D46 for ; Thu, 12 Aug 2004 17:51:36 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i7CHpY2h017110; Thu, 12 Aug 2004 13:51:34 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i7CHpUMa017109; Thu, 12 Aug 2004 13:51:30 -0400 (EDT) (envelope-from green) Date: Thu, 12 Aug 2004 13:51:30 -0400 From: Brian Fundakowski Feldman To: Nate Lawson Message-ID: <20040812175130.GD981@green.homeunix.org> References: <411B0226.3030806@root.org> <20040812054959.GF3527@cs.rice.edu> <411BA88D.6070000@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <411BA88D.6070000@root.org> User-Agent: Mutt/1.5.6i cc: Alan Cox cc: current@freebsd.org Subject: Re: LoR aironet/VM subsystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 17:51:37 -0000 On Thu, Aug 12, 2004 at 10:27:41AM -0700, Nate Lawson wrote: > Alan Cox wrote: > >On Wed, Aug 11, 2004 at 10:37:42PM -0700, Nate Lawson wrote: > > > >>an0: at port > >>0x2000-0x203f irq 11 function 0 config 5 on pccard1 > >>an0: got RSSI <-> dBM map > >>an0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > >>an0: Ethernet address: 00:40:96:42:91:c5 > >>an0: [GIANT-LOCKED] > >>lock order reversal > >>1st 0xc163339c an0 (network driver) @ dev/an/if_an.c:1931 > >>2nd 0xc134b164 user map (user map) @ vm/vm_map.c:2902 > >>KDB: stack backtrace: > >>kdb_backtrace(0,ffffffff,c0696d88,c0697a08,c066630c) at kdb_backtrace+0x29 > >>witness_checkorder(c134b164,9,c06469a0,b56) at witness_checkorder+0x544 > >>_sx_xlock(c134b164,c0646997,b56) at _sx_xlock+0x50 > >>_vm_map_lock_read(c134b128,c0646997,b56,1b69978,c1402e4c) at > >>_vm_map_lock_read+0x33 > >>vm_map_lookup(d0b69a10,bfbfd000,1,d0b69a14,d0b69a04) at vm_map_lookup+0x28 > >>vm_fault(c134b128,bfbfd000,1,0,c1371840) at vm_fault+0x66 > >>trap_pfault(d0b69ad8,0,bfbfd000) at trap_pfault+0xd2 > >>trap(c04f0018,c06b0010,c1630010,c1633df4,bfbfd000) at trap+0x311 > >>calltrap() at calltrap+0x5 > >>--- trap 0xc, eip = 0xc060661e, esp = 0xd0b69b18, ebp = 0xd0b69ba4 --- > >>generic_copyin(c1632000,c020693a,d0b69c60,c04d4b78,c06bb8e0) at > >>generic_copyin+0x32 > >>ifhwioctl(c020693a,c1632000,d0b69c60,c1371840,c0698048) at ifhwioctl+0x854 > >>ifioctl(c16219e0,c020693a,d0b69c60,c1371840,0) at ifioctl+0xbd > >>soo_ioctl(c158f440,c020693a,d0b69c60,c133c480,c1371840) at soo_ioctl+0x2b1 > >>ioctl(c1371840,d0b69d14,3,2,292) at ioctl+0x3e0 > >>syscall(2f,2f,2f,3,bfbfef64) at syscall+0x217 > >>Xint0x80_syscall() at Xint0x80_syscall+0x1f > >>--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280d0083, esp = > >>0xbfbfad7c, ebp = 0xbfbfadb8 --- > >> > > > >This looks like a programming error in the driver. Specifically, > >the driver is calling copyin() while holding a mutex. That's not > >allowed because of the potential for a page fault that sleeps. > > It is. AN_LOCK is held over the entire contents of an_ioctl(). This > function is so huge, it's unclear how to reduce the scope of this lock. It should be held over almost none of it, especially not calls to sub-ioctl() routines and ieee80211_*() ones and ones which perform no action on the an device itself (which is a lot of them). It's never going to be needed before a copyin() or copyout(). -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 18:23:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64E8716A4CE for ; Thu, 12 Aug 2004 18:23:11 +0000 (GMT) Received: from mr01.hansenet.de (mr01.hansenet.de [213.191.74.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43BF043D41 for ; Thu, 12 Aug 2004 18:23:10 +0000 (GMT) (envelope-from db@nipsi.de) Received: from mail.nipsi.de (213.39.154.86) by mr01.hansenet.de (6.7.010) id 4119D65100005D5A for freebsd-current@freebsd.org; Thu, 12 Aug 2004 20:23:09 +0200 Received: from localhost (localhost [127.0.0.1]) (uid 1001) by mail.nipsi.de with local; Thu, 12 Aug 2004 20:23:01 +0200 Date: Thu, 12 Aug 2004 20:23:01 +0200 From: Dennis Berger To: Evan Dower Message-ID: <20040812182301.GA21510@nipsi.home.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: db@nipsi.de cc: freebsd-current@freebsd.org Subject: Re: Project Evil: TI ACX111 non-success X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 18:23:11 -0000 I guess I tried everything possible... acx driver failed cause it's simply not supported "acx111". ndis driver failed also with 3 different firmware types... -------------- cardbus1: Expecting link target, got 0xcb cardbus1: Resource not specified in CIS: id=10, size=2000 cardbus1: Resource not specified in CIS: id=14, size=20000 ndis0: mem 0x88000000-0x8 801ffff,0x88020000-0x88021fff irq 11 at device 0.0 on cardbus1 ndis0: [GIANT-LOCKED] ndis0: NDIS API version: 5.1 ndis0: init handler failed device_attach: ndis0 attach returned 6 cardbus1: release_all_resource: Resource still owned by child, oops. (type=3, ri d=20, addr=88000000) cbb1: CardBus card activation failed ------------- best regards, -Dennis On Thu, Aug 12, 2004 at 10:00:58AM -0700, Evan Dower wrote: > With ndis do you get the same "init handler failed" error message? Have you > emailed Bill Paul with all the appropriate info? What have you tried? What > were the results? > > -- > Evan Dower > Undergraduate, Computer Science > University of Washington > Public key: http://students.washington.edu/evantd/pgp-pub-key.txt > Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D > > > > > > >From: Dennis Berger > >To: Evan Dower > >CC: freebsd-current@freebsd.org > >Subject: Re: Project Evil: TI ACX111 non-success > >Date: Thu, 12 Aug 2004 09:56:15 +0200 > > > >I have the dlink g650+ which also has the acx111 chipset... > >NDIS failed acx driver failed also. > >regards, > >-Dennis > > > >On Wed, Aug 11, 2004 at 04:40:58PM -0700, Evan Dower wrote: > >> I've been trying to get the ndisulator to work for my NetGear WG311v2 so > >I > >> can take the ethernet cables and switches offthe floor in my hall. The > >> following is the "conversation" I've had with Bill Paul. It is perhaps > >best > >> to read from the bottom up to get the chronology right. Also, as it > >turns > >> out the net/acx100 port makes no claim to support the acx111, and I was > >> eventually able to build and load it, though of course it didn't work > >> because it doesn't support the acx111. Any help would be greatly > >> appreciated. > >> > >> -- > >> > >> I managed to get rid of the "can't re-use a leaf" messaged by deleting > >> the duplicate entry in ndis_driver_data.h. For some reason, whenever I > >> try to load if_ndis.ko (ndis.ko is already loaded), I get messages about > >> amdpm. Perhaps ndis returning 6 and failing to load is a result of the > >> same return value from trying to attach amdpm. > >> > >> amdpm0: port > >> 0xe4e0-0xe4ff at device 7.3 on pci0 > >> amdpm0: could not map i/o space > >> device_attach: amdpm0 attach returned 6 > >> ndis0: mem > >> 0xf0800000-0xf081ffff,0xf1000000-0xf1001fff irq 17 at device 6.0 on pci2 > >> ndis0: [GIANT-LOCKED] > >> no match for srand > >> ndis0: NDIS API version: 5.1 > >> ndis0: init handler failed > >> device_attach: ndis0 attach returned 6 > >> > >> Thanks again, > >> Evan Dower > >> > >> El mar, 20-07-2004 a las 10:58, Evan Dower escribi?: > >> >I have figured out that the "can't re-use a leaf" message is coming > >from > >> >trying to register a sysctl, which comes from the .inf file. This seems > >> >to indicate some limitations on the complexity of .inf files that can > >be > >> >properly parsed and turned into a list of sysctls. Since I'm not > >exactly > >> >sure what those limitations are, I'm sending you a link to the .inf > >file > >> >(and the .sys file for good measure)? Other than that, it looks like > >> >srand might just need to be plugged into one of the function tables > >> >(probably the hal table, I guess). Also, if you can tell me what > >> >limitations exist for the .inf file, I will gladly modify it to work > >and > >> >make it available to other WG311v2 owners. > >> >Thanks again, > >> >Evan Dower > >> >Note: Much of the .inf file (anything not for XP) is commented out in > >an > >> >attempt to make things work. This was my doing. It didn't ship that > >way. > >> >Since I don't really understand the Windows registry, I didn't get too > >> >adventurous. > >> > > >> >Files at: http://students.washington.edu/evantd/pub/evil/ > >> > > >> >El lun, 12-07-2004 a las 16:05, Evan Dower escribi?: > >> >> I have a Netgear WG311v2. The v2 turns out to be very important as > >the > >> >> original (v1 you might call it now) was based on an Atheros AR5212 > >and > >> >> was thus supported by the ath driver. v2 is based on the the TI > >AXC111 > >> >> (aka TNETW1130), which should be supported by the net/acx100 port, > >but > >> >> if_acx.ko fails to load due to a missing __panic symbol. Following > >the > >> >> instructions you posted in an email, I made ndis_driver_data.h and > >> >> built and loaded the if_ndis.ko module (after loading ndis.ko or > >> >> compiling it into the kernel). I used the Windows XP .SYS and .INF > >> >> files, though the Windows 2000 versions gave the same result, the > >> >> Windows 98 files produced a module that panicked on load, and I > >didn't > >> >> try the Windows ME files. The following is the output from `make > >> >> load`. > >> >> > /sbin/kldload -v /usr/current/src/sys/modules/if_ndis/if_ndis.ko > >> >> ndis0: mem > >> >> 0xec800000-0xec81ffff, > >> >> 0xed000000-0xed001fff irq 17 at device 6.0 on pci2 > >> >> ndis0: [GIANT-LOCKED] > >> >> can't re-use a leaf (dot11DesiredBSSType)! > >> >> no match for srand > >> >> ndis0: NDIS API version: 5.1 > >> >> ndis0: init handler failed > >> >> device_attach: ndis0 attach returned 6 > >> >> Loaded /usr/current/src/sys/modules/if_ndis/if_ndis.ko, id=11 > >> >> > Loading the module does not create /dev/ndis0 or /dev/if_ndis0 (or > >> >> anything of the sort). I am running today's -CURRENT. > >> >> > It seems that it requires srand, and I assume the 'can't re-use a > >leaf > >> >> (dot11DesiredBSSType)!' is also a show-stopper. I ordered my card > >from > >> >> newegg.com for about $50. > >> >> > If there is anything else you might be interested in (a verbose > >boot > >> >> log, copies of the .SYS and .INF files, testing for patches, etc.), > >> >> just let me know. I'd be happy to help (especially since the result > >is > >> >> a working wireless connection). > >> >> > Thanks very much, > >> > >> -- > >> Evan Dower > >> Undergraduate, Computer Science > >> University of Washington > >> Public key: http://students.washington.edu/evantd/pgp-pub-key.txt > >> Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D > >> > >> _________________________________________________________________ > >> Don?t just search. Find. Check out the new MSN Search! > >> http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > >> > >> _______________________________________________ > >> 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" > > _________________________________________________________________ > On the road to retirement? Check out MSN Life Events for advice on how to > get there! http://lifeevents.msn.com/category.aspx?cid=Retirement > From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 12:49:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28E1F16A4CE for ; Thu, 12 Aug 2004 12:49:00 +0000 (GMT) Received: from mirapoint1.tis.cwru.edu (mirapoint1.TIS.CWRU.Edu [129.22.104.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5C4F43D41 for ; Thu, 12 Aug 2004 12:48:59 +0000 (GMT) (envelope-from jrh29@po.cwru.edu) Received: from [192.168.1.108] (oh-clevelandheights-cdnt1-bg1b-147.clvdoh.adelphia.net [68.170.192.147]) by mirapoint1.tis.cwru.edu (MOS 3.4.3-CR) with ESMTP id CFX50104 (AUTH jrh29); Thu, 12 Aug 2004 08:48:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v619) To: freebsd-current@freebsd.org Message-Id: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3-191096317" From: Justin Hibbits Date: Thu, 12 Aug 2004 08:48:49 -0400 Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Mailman-Approved-At: Thu, 12 Aug 2004 18:48:35 +0000 Subject: Preliminary ATI TV Wonder bktr support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 12:49:00 -0000 --Apple-Mail-3-191096317 Content-Type: multipart/mixed; boundary=Apple-Mail-2-191096309 --Apple-Mail-2-191096309 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed It's not complete (no sound yet, and no idea where to begin), but the ATI TV Wonder is now auto configured. Source merged from OpenBSD. Since I'm not a regular FreeBSD hacker, I'm posting it here. I hope it's the right list. Anyway, maybe someone can figure out how to go from here, since I'm stuck now. I'll continue working on it though. -Justin -- "And now, if you'll excuse me, I'm in the middle of 15 things, all annoying" -- Lt. Cmdr Susan Ivanova, Babylon 5 --Apple-Mail-2-191096309 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="bktr_card_c.patch" Content-Disposition: attachment; filename=bktr_card_c.patch *** bktr_card.c Thu Aug 12 08:44:41 2004 --- /local/src/sys/dev/bktr/bktr_card.c Thu Aug 12 08:40:48 2004 *************** *** 368,373 **** --- 368,385 ---- { 0x02, 0x00, 0x00, 0x00, 1 }, /* audio MUX values */ 0x18e0 }, /* GPIO mask */ + { CARD_TVWONDER, /* the card id */ + "ATI TV Wonder", /* the 'name' */ + NULL, /* the tuner */ + 0, /* the tuner i2c address */ + 0, /* dbx is optional */ + 0, + 0, + 0, /* EEProm type */ + 0, /* EEProm size */ + /* Tuner, Extern, Intern, Mute, Enabled */ + { 0x1002, 0x1002, 0x3003, 0x3003, 0x3003 }, /* audio MUX values */ + 0x300f }, /* GPIO mask */ }; struct bt848_card_sig bt848_card_signature[1]= { *************** *** 569,574 **** --- 581,587 ---- #define PCI_VENDOR_FLYVIDEO_2 0x1852 #define PCI_VENDOR_PINNACLE_ALT 0xBD11 #define PCI_VENDOR_IODATA 0x10fc + #define PCI_VENDOR_ATI 0x1002 #define MODEL_IODATA_GV_BCTV3_PCI 0x4020 *************** *** 713,718 **** --- 726,737 ---- bktr->card.eepromSize = (u_char)(256 / EEPROMBLOCKSIZE); goto checkTuner; } + if (subsystem_vendor_id == PCI_VENDOR_ATI) { + bktr->card = cards[ (card = CARD_TVWONDER) ]; + bktr->card.eepromAddr = eeprom_i2c_address; + bktr->card.eepromSize = (u_char)(256 / EEPROMBLOCKSIZE); + goto checkTuner; + } /* Vendor is unknown. We will use the standard probe code */ /* which may not give best results */ *************** *** 1131,1136 **** --- 1150,1160 ---- goto checkDBX; break; + case CARD_TVWONDER: + select_tuner( bktr, PHILIPS_NTSC ); /* ALPS_TSCH6, in fact. */ + goto checkDBX; + break; + } /* end switch(card) */ *************** *** 1274,1279 **** --- 1298,1307 ---- /* Enable PLL mode for Video Highway Xtreme users */ if (card == CARD_VIDEO_HIGHWAY_XTREME) + bktr->xtal_pll_mode = BT848_USE_PLL; + + /* Enable PLL mode for Video Highway Xtreme users */ + if (card == CARD_TVWONDER) bktr->xtal_pll_mode = BT848_USE_PLL; --Apple-Mail-2-191096309 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="bktr_card_h.patch" Content-Disposition: attachment; filename=bktr_card_h.patch *** bktr_card.h Thu Aug 12 08:44:41 2004 --- /local/src/sys/dev/bktr/bktr_card.h Thu Aug 12 08:41:55 2004 *************** *** 76,84 **** #define CARD_ASKEY_DYNALINK_MAGIC_TVIEW 14 #define CARD_LEADTEK 15 #define CARD_TERRATVPLUS 16 ! #define CARD_IO_BCTV3 17 ! #define CARD_AOPEN_VA1000 18 ! #define Bt848_MAX_CARD 19 #define CARD_IO_GV CARD_IO_BCTV2 --- 76,85 ---- #define CARD_ASKEY_DYNALINK_MAGIC_TVIEW 14 #define CARD_LEADTEK 15 #define CARD_TERRATVPLUS 16 ! #define CARD_IO_BCTV3 17 ! #define CARD_AOPEN_VA1000 18 ! #define CARD_TVWONDER 19 ! #define Bt848_MAX_CARD 20 #define CARD_IO_GV CARD_IO_BCTV2 --Apple-Mail-2-191096309-- --Apple-Mail-3-191096317 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFBG2c3qt29EJDZlM4RAlSIAJ9RyKi31JQbbuuOrt9d/6JTbaW4kQCfaj3b VDt5nDXjDl3DhqebLx3s4Js= =w60H -----END PGP SIGNATURE----- --Apple-Mail-3-191096317-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 13:32:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B8BF16A4CE; Thu, 12 Aug 2004 13:32:37 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FBF743D54; Thu, 12 Aug 2004 13:32:37 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id i7CDWZLu039839; Thu, 12 Aug 2004 09:32:35 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)i7CDWZpp039830; Thu, 12 Aug 2004 09:32:35 -0400 (EDT) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Thu, 12 Aug 2004 09:32:34 -0400 (EDT) From: Jeff Roberson To: Martin Blapp In-Reply-To: <20040812144448.F31181@cvs.imp.ch> Message-ID: <20040812093020.G7322@mail.chesapeake.net> References: <20040811200323.B31181@cvs.imp.ch> <20040812042621.O7322@mail.chesapeake.net> <20040812143133.G31181@cvs.imp.ch> <20040812144448.F31181@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Thu, 12 Aug 2004 18:48:35 +0000 cc: freebsd-current@freebsd.org cc: Robert Watson Subject: Re: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 13:32:37 -0000 On Thu, 12 Aug 2004, Martin Blapp wrote: > > > I used this small script here to load it. I've prepared a shell script which > > calls this 200 times. The mails are then rotating from sendmail to milter in > > a 26 times loop which takes almost forever ;-). > > If you use sendmail, be sure you have these set up in the .mc configuration: > > define(`confREFUSE_LA', `800') > define(`confQUEUE_LA', `600') > define(`confDELAY_LA',`500') > define(`confMAX_DAEMON_CHILDREN', `1000') > define(`confMAX_QUEUE_CHILDREN', `500') > define(`confBAD_RCPT_THROTTLE',`500')dnl > define(`confMAX_CONNECTION_RATE', `600') > define(`confBAD_RCPT_THROTTLE_TIME', `1000') > define(`confMAX_CLIENT_CONNECTION_RATE', `1000') > define(`confCONNECTION_RATE_WINDOW_SIZE', `600') > > Else sendmail will refuse connections. > > If you need an exact setup, I can prepare something for you (package) > which you can just install and then do the tests. If you wouldn't mind, I believe this would be an invaluable tool for myself and others doing performance tuning/testing. Especially if it's as easy as adding a package. I'll be away for 4 days for a wedding. Can you email me any results from tests with an updated ule along with a package or a tar of any scripts/setup you have? Then I'll be able to hack away at this when I get back. Thanks, Jeff > > Martin > From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 15:27:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7CFC16A4CE; Thu, 12 Aug 2004 15:27:06 +0000 (GMT) Received: from mirapoint1.tis.cwru.edu (mirapoint1.TIS.CWRU.Edu [129.22.104.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C51143D45; Thu, 12 Aug 2004 15:27:06 +0000 (GMT) (envelope-from jrh29@po.cwru.edu) Received: from [192.168.1.108] (oh-clevelandheights-cdnt1-bg1b-147.clvdoh.adelphia.net [68.170.192.147]) by mirapoint1.tis.cwru.edu (MOS 3.4.3-CR) with ESMTP id CFY20450 (AUTH jrh29); Thu, 12 Aug 2004 11:27:03 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v619) To: ojo@force.sk, freebsd-gnats-submit@FreeBSD.org Message-Id: <0B115D53-EC74-11D8-819F-000A95841F44@po.cwru.edu> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5-200582066" From: Justin Hibbits Date: Thu, 12 Aug 2004 11:26:55 -0400 Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Mailman-Approved-At: Thu, 12 Aug 2004 18:48:35 +0000 cc: freebsd-current@freebsd.org Subject: Re: kern/60599: [sound] No sound for ATI TV Wonder (stereo) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 15:27:06 -0000 --Apple-Mail-5-200582066 Content-Type: multipart/mixed; boundary=Apple-Mail-4-200582057 --Apple-Mail-4-200582057 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed The following patch adds ATI TV Wonder autoconfiguration. It was posted to current@ before, but I cleaned up the patch(es), making them this unified diff. Hopefully someone can figure out the audio part now, I'll keep working on it. -Justin -- "And now, if you'll excuse me, I'm in the middle of 15 things, all annoying" -- Lt. Cmdr Susan Ivanova, Babylon 5 --Apple-Mail-4-200582057 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="bktr.patch" Content-Disposition: attachment; filename=bktr.patch --- bktr_card.c Thu Aug 12 11:17:06 2004 +++ /local/src/sys/dev/bktr/bktr_card.c Thu Aug 12 09:15:58 2004 @@ -32,7 +32,7 @@ */ #include -__FBSDID("$FreeBSD: /repoman/r/ncvs/src/sys/dev/bktr/bktr_card.c,v 1.24 2004/08/08 01:23:39 sanpei Exp $"); +__FBSDID("$FreeBSD: src/sys/dev/bktr/bktr_card.c,v 1.23 2003/12/08 07:59:18 obrien Exp $"); /* * This is part of the Driver for Video Capture Cards (Frame grabbers) @@ -368,6 +368,20 @@ { 0x02, 0x00, 0x00, 0x00, 1 }, /* audio MUX values */ 0x18e0 }, /* GPIO mask */ + { CARD_TVWONDER, /* the card id */ + "ATI TV Wonder", /* the 'name' */ + NULL, /* the tuner */ + 0, /* the tuner i2c address */ + 0, /* dbx is optional */ + 0, + 0, + 0, /* EEProm type */ + 0, /* EEProm size */ + /* Tuner, Extern, Intern, Mute, Enabled */ +// { 0x1002, 0x1002, 0x3003, 0x3003, 0x3003 }, /* audio MUX values */ +// 0x300f }, /* GPIO mask */ + { 0x1002, 0x1002, 0x3003, 0x3003, 0x3003 }, /* audio MUX values */ + 0x300f }, /* GPIO mask */ }; struct bt848_card_sig bt848_card_signature[1]= { @@ -569,6 +583,7 @@ #define PCI_VENDOR_FLYVIDEO_2 0x1852 #define PCI_VENDOR_PINNACLE_ALT 0xBD11 #define PCI_VENDOR_IODATA 0x10fc +#define PCI_VENDOR_ATI 0x1002 #define MODEL_IODATA_GV_BCTV3_PCI 0x4020 @@ -713,6 +728,12 @@ bktr->card.eepromSize = (u_char)(256 / EEPROMBLOCKSIZE); goto checkTuner; } + if (subsystem_vendor_id == PCI_VENDOR_ATI) { + bktr->card = cards[ (card = CARD_TVWONDER) ]; + bktr->card.eepromAddr = eeprom_i2c_address; + bktr->card.eepromSize = (u_char)(256 / EEPROMBLOCKSIZE); + goto checkTuner; + } /* Vendor is unknown. We will use the standard probe code */ /* which may not give best results */ @@ -1131,6 +1152,11 @@ goto checkDBX; break; + case CARD_TVWONDER: + select_tuner( bktr, PHILIPS_NTSC ); /* ALPS_TSCH6, in fact. */ + goto checkDBX; + break; + } /* end switch(card) */ @@ -1274,6 +1300,10 @@ /* Enable PLL mode for Video Highway Xtreme users */ if (card == CARD_VIDEO_HIGHWAY_XTREME) + bktr->xtal_pll_mode = BT848_USE_PLL; + + /* Enable PLL mode for Video Highway Xtreme users */ + if (card == CARD_TVWONDER) bktr->xtal_pll_mode = BT848_USE_PLL; --- bktr_card.h Thu Aug 12 11:17:06 2004 +++ /local/src/sys/dev/bktr/bktr_card.h Thu Aug 12 08:41:55 2004 @@ -1,4 +1,4 @@ -/* $FreeBSD: /repoman/r/ncvs/src/sys/dev/bktr/bktr_card.h,v 1.7 2004/08/08 01:23:39 sanpei Exp $ */ +/* $FreeBSD: src/sys/dev/bktr/bktr_card.h,v 1.6 2003/02/02 17:46:00 orion Exp $ */ /* * This is part of the Driver for Video Capture Cards (Frame grabbers) @@ -76,9 +76,10 @@ #define CARD_ASKEY_DYNALINK_MAGIC_TVIEW 14 #define CARD_LEADTEK 15 #define CARD_TERRATVPLUS 16 -#define CARD_IO_BCTV3 17 -#define CARD_AOPEN_VA1000 18 -#define Bt848_MAX_CARD 19 +#define CARD_IO_BCTV3 17 +#define CARD_AOPEN_VA1000 18 +#define CARD_TVWONDER 19 +#define Bt848_MAX_CARD 20 #define CARD_IO_GV CARD_IO_BCTV2 --Apple-Mail-4-200582057-- --Apple-Mail-5-200582066 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFBG4xEqt29EJDZlM4RAoxPAJ905NY++KwRJnprYyHK5YSCpkZ/rwCdFvpf au4UmWmHpO9f64u4+ZXNW1c= =etld -----END PGP SIGNATURE----- --Apple-Mail-5-200582066-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 18:08:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9ABA816A4CE for ; Thu, 12 Aug 2004 18:08:33 +0000 (GMT) Received: from vougeot.opal.com (reston-gnap-ip-216020-27.dynamic.ziplink.net [216.8.20.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D85C43D4C for ; Thu, 12 Aug 2004 18:08:26 +0000 (GMT) (envelope-from jr@vougeot.opal.com) Received: from vougeot.opal.com (localhost [127.0.0.1]) by vougeot.opal.com (8.12.10/8.12.10) with ESMTP id i7CIBbKJ092081; Thu, 12 Aug 2004 14:11:41 -0400 (EDT) (envelope-from jr@vougeot.opal.com) Received: (from jr@localhost) by vougeot.opal.com (8.12.10/8.12.10/Submit) id i7CIBZYA092080; Thu, 12 Aug 2004 14:11:35 -0400 (EDT) (envelope-from jr) Date: Thu, 12 Aug 2004 14:11:34 -0400 From: "J.R. Oldroyd" To: anatoly@relcom.ru Message-ID: <20040812181134.GB91353@vougeot.opal.com> References: <411A7F28.6000108@relcom.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <411A7F28.6000108@relcom.ru> User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Thu, 12 Aug 2004 18:48:35 +0000 cc: freebsd-current@freebsd.org Subject: Re: boot hangs due acd init X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 18:08:33 -0000 I have the same problem with a: acd0: DVDR <_NEC DVD_RW ND-1300A> at ata1-slave PIO4 This booted fine until -current from around the end of July at which point the boot hangs during the probe of this device. I have emailed Sřren as I suspected that it may be related to the new default-to-DMA code. I noticed that if I pull the power on the DVD drive after the boot has hung, I get this: acd0: CDROM <_NEC DVD_RW ND-1300A/1.05> at ata1-slave UDMA33 and the boot continues. (Note the change from DVDR to CDROM and the change from PIO4 to UDMA33.) -jr On Aug 12, 00:18, anatoly@relcom.ru wrote: > hey folks > > i run recent current and somewhile ago i noticed that i cant boot my > fujitsu lifebook P series with this dvd-cdrw device: > acd0: CDRW at ata1-master PIO4 > it hangs on boot. I'd mention that it was working nice before. > I can provide necessary debugging information if needed. > _______________________________________________ > 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 Aug 12 18:11:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5BAB16A4CF for ; Thu, 12 Aug 2004 18:11:58 +0000 (GMT) Received: from rms06.rommon.net (rms06.rommon.net [212.54.5.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id EED5B43D49 for ; Thu, 12 Aug 2004 18:11:57 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from [193.64.42.134] (h86.vuokselantie10.fi [193.64.42.134]) by rms06.rommon.net (Postfix) with ESMTP id 0C3AE33C1B for ; Thu, 12 Aug 2004 21:11:55 +0300 (EEST) Message-ID: <411BB2EC.1020903@he.iki.fi> Date: Thu, 12 Aug 2004 21:11:56 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 12 Aug 2004 18:48:35 +0000 Subject: boot loader crashes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 18:11:58 -0000 I updated a machine with ABIT VP6 (dual S370) motherboard from -CURRENT in May to recent -CURRENT and since then the boot crashes with a message which is visible for only a fraction of a second until the BIOS message shows again. This is reproduceable with recent CD's. I´m able to boot the system using 5.2.1 release CD and then just switching over to the HD. The bootloader seems to gone through multiple changes so I couldn´t immediately locate a place which could be at fault. Any ideas or suggestions would be appreciated, I would hate to have to ditch the board. Pete From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 18:50:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4ED4516A4D0 for ; Thu, 12 Aug 2004 18:50:10 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AD7E43D45 for ; Thu, 12 Aug 2004 18:50:09 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 7A2061FFDD8 for ; Thu, 12 Aug 2004 20:50:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 982A41FFDD7; Thu, 12 Aug 2004 20:50:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 2673F15665; Thu, 12 Aug 2004 18:47:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 1BF3115391 for ; Thu, 12 Aug 2004 18:47:33 +0000 (UTC) Date: Thu, 12 Aug 2004 18:47:32 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: FreeBSD current mailing list In-Reply-To: <411B0226.3030806@root.org> Message-ID: References: <411B0226.3030806@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Subject: Re: LoR aironet/VM subsystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 18:50:10 -0000 On Wed, 11 Aug 2004, Nate Lawson wrote: > lock order reversal > 1st 0xc163339c an0 (network driver) @ dev/an/if_an.c:1931 > 2nd 0xc134b164 user map (user map) @ vm/vm_map.c:2902 for the archives: http://sources.zabbadoz.net/freebsd/lor.html#021 -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 18:52:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D37216A4CE for ; Thu, 12 Aug 2004 18:52:45 +0000 (GMT) Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD1C343D54 for ; Thu, 12 Aug 2004 18:52:44 +0000 (GMT) (envelope-from stijn@pcwin002.win.tue.nl) Received: from pcwin002.win.tue.nl (orb_rules@localhost [127.0.0.1]) by pcwin002.win.tue.nl (8.12.11/8.12.11) with ESMTP id i7CIqhNx055405; Thu, 12 Aug 2004 20:52:43 +0200 (CEST) (envelope-from stijn@pcwin002.win.tue.nl) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.12.11/8.12.11/Submit) id i7CIqg0Z055404; Thu, 12 Aug 2004 20:52:43 +0200 (CEST) (envelope-from stijn) Date: Thu, 12 Aug 2004 20:52:42 +0200 From: Stijn Hoop To: Justin Hibbits Message-ID: <20040812185242.GA53082@pcwin002.win.tue.nl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Bright-Idea: Let's abolish HTML mail! cc: freebsd-current@freebsd.org Subject: Re: Preliminary ATI TV Wonder bktr support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 18:52:45 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Aug 12, 2004 at 08:48:49AM -0400, Justin Hibbits wrote: > It's not complete (no sound yet, and no idea where to begin), but the=20 > ATI TV Wonder is now auto configured. Source merged from OpenBSD. =20 > Since I'm not a regular FreeBSD hacker, I'm posting it here. I hope=20 > it's the right list. I'm not qualified to comment on that, but if this isn't picked up by a committer you might want to consider using send-pr(1) to send this patch to the FreeBSD bug database. > Anyway, maybe someone can figure out how to go from here, since I'm=20 > stuck now. I'll continue working on it though. FWIW, I recall that most of the open source BT878 drivers don't do internal sound, and instead rely on you to feed the audio channel into your soundcar= d. At least, that's what works for me with a no-name TV tuner card; it even included a male-male minijack cable to do so. So if that's all that's missi= ng, you might be as far along as anyone has ever been. --Stijn --=20 An Orb is for life, not just for Christmas. --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBG7x6Y3r/tLQmfWcRAnBOAJ43XACQVRlt8x7GasO93ucqjYm30QCfYvJT qwtdhkYFp+ffR97YntYJNVQ= =h05H -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 18:56:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0944616A4CE; Thu, 12 Aug 2004 18:56:50 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5F1443D5C; Thu, 12 Aug 2004 18:56:49 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from dhcp50.pn.xcllnt.net (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i7CIungi087587; Thu, 12 Aug 2004 11:56:49 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp50.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp50.pn.xcllnt.net (8.13.1/8.13.1) with ESMTP id i7CIunO8030463; Thu, 12 Aug 2004 11:56:49 -0700 (PDT) (envelope-from marcel@dhcp50.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp50.pn.xcllnt.net (8.13.1/8.13.1/Submit) id i7CIunRF030462; Thu, 12 Aug 2004 11:56:49 -0700 (PDT) (envelope-from marcel) Date: Thu, 12 Aug 2004 11:56:49 -0700 From: Marcel Moolenaar To: Nate Lawson Message-ID: <20040812185649.GA30420@dhcp50.pn.xcllnt.net> References: <411BA70D.7010804@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <411BA70D.7010804@root.org> User-Agent: Mutt/1.4.2.1i cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: ACPI mpsafe patch for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 18:56:50 -0000 On Thu, Aug 12, 2004 at 10:21:17AM -0700, Nate Lawson wrote: > I plan to commit the mpsafe patch for acpi on Friday morning. No > problems so far for testers and I've run it for weeks (versions of it > for months). The only change I've made is to update it against commits > so it will apply cleanly. > > Please test if you get a chance. Again the URL: > http://root.org/~nate/freebsd/acpi_mpsafe.diff.gz ia64: pluto1.freebsd.org is running with the patch. I also performed a reboot without problems. Note that pluto1 runs an UP kernel. Are there any SMP specific MD code paths you think I should test or is it sufficient that SMP is tested on i386 (or amd64)? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 18:58:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEBC316A4CE for ; Thu, 12 Aug 2004 18:58:53 +0000 (GMT) Received: from mail08.svc.cra.dublin.eircom.net (mail08.svc.cra.dublin.eircom.net [159.134.118.24]) by mx1.FreeBSD.org (Postfix) with SMTP id 2621E43D5A for ; Thu, 12 Aug 2004 18:58:53 +0000 (GMT) (envelope-from steve@sohara.org) Received: (qmail 38185 messnum 3860460 invoked from network[159.134.254.181/159-134-254-181.as1.nas.naas.eircom.net]); 12 Aug 2004 18:58:47 -0000 Received: from 159-134-254-181.as1.nas.naas.eircom.net (HELO localhost) (159.134.254.181) by mail08.svc.cra.dublin.eircom.net (qp 38185) with SMTP; 12 Aug 2004 18:58:47 -0000 Date: Thu, 12 Aug 2004 19:58:31 +0100 From: Steve O'Hara-Smith To: Justin Hibbits Message-Id: <20040812195831.033a78af.steve@sohara.org> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i386-portbld-freebsd4.10) X-Face: %]+HVL}K`P8>+8ZcY-WGHP6j@&mxMo9JH6_WdgIgUGH)JX/usO0%jy7T~IVgqjumD^OBqX,Kv^-GM6mlw(fI^$"QRKyZ$?xx/ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: Preliminary ATI TV Wonder bktr support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 18:58:53 -0000 On Thu, 12 Aug 2004 08:48:49 -0400 Justin Hibbits wrote: > It's not complete (no sound yet, and no idea where to begin), but the > ATI TV Wonder is now auto configured. Source merged from OpenBSD. > Since I'm not a regular FreeBSD hacker, I'm posting it here. I hope > it's the right list. Is this against -current or against 4.x, if the former what are my chances of merging it to 4.x ? -- C:>WIN | Directable Mirror Arrays The computer obeys and wins. | A better way to focus the sun You lose and Bill collects. | licences available see | http://www.sohara.org/ From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 18:59:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6404C16A4CF; Thu, 12 Aug 2004 18:59:52 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3613543D53; Thu, 12 Aug 2004 18:59:52 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7CIxp8U030813; Thu, 12 Aug 2004 11:59:51 -0700 Message-ID: <411BBE25.3070404@root.org> Date: Thu, 12 Aug 2004 11:59:49 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Moolenaar References: <411BA70D.7010804@root.org> <20040812185649.GA30420@dhcp50.pn.xcllnt.net> In-Reply-To: <20040812185649.GA30420@dhcp50.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: ACPI mpsafe patch for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 18:59:52 -0000 Marcel Moolenaar wrote: > On Thu, Aug 12, 2004 at 10:21:17AM -0700, Nate Lawson wrote: > >>I plan to commit the mpsafe patch for acpi on Friday morning. No >>problems so far for testers and I've run it for weeks (versions of it >>for months). The only change I've made is to update it against commits >>so it will apply cleanly. >> >>Please test if you get a chance. Again the URL: >>http://root.org/~nate/freebsd/acpi_mpsafe.diff.gz > > > ia64: pluto1.freebsd.org is running with the patch. I also performed > a reboot without problems. > > Note that pluto1 runs an UP kernel. Are there any SMP specific MD > code paths you think I should test or is it sufficient that SMP is > tested on i386 (or amd64)? For ia64, I was most concerned about alignment issues. So anything (UP or SMP) that exercises code paths is helpful. The only SMP-specific things to test are power-off on shutdown. Run it a bunch of times to be sure that it continues to work. Note this isn't in the acpi locking path but ACPI-CA has its own locks which are now not redundantly covered by Giant. It has been running this way in Linux for a year or so. Still, it's good to have that test coverage too. -- Nate From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 19:12:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF1D216A4DD; Thu, 12 Aug 2004 19:12:40 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id B739843D49; Thu, 12 Aug 2004 19:12:40 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from dhcp50.pn.xcllnt.net (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i7CJCeEc087663; Thu, 12 Aug 2004 12:12:40 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp50.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp50.pn.xcllnt.net (8.13.1/8.13.1) with ESMTP id i7CJCe2v030529; Thu, 12 Aug 2004 12:12:40 -0700 (PDT) (envelope-from marcel@dhcp50.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp50.pn.xcllnt.net (8.13.1/8.13.1/Submit) id i7CJCeKK030528; Thu, 12 Aug 2004 12:12:40 -0700 (PDT) (envelope-from marcel) Date: Thu, 12 Aug 2004 12:12:40 -0700 From: Marcel Moolenaar To: Nate Lawson Message-ID: <20040812191240.GA30489@dhcp50.pn.xcllnt.net> References: <411BA70D.7010804@root.org> <20040812185649.GA30420@dhcp50.pn.xcllnt.net> <411BBE25.3070404@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <411BBE25.3070404@root.org> User-Agent: Mutt/1.4.2.1i cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: ACPI mpsafe patch for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 19:12:41 -0000 On Thu, Aug 12, 2004 at 11:59:49AM -0700, Nate Lawson wrote: > > For ia64, I was most concerned about alignment issues. So anything (UP > or SMP) that exercises code paths is helpful. The only SMP-specific > things to test are power-off on shutdown. Run it a bunch of times to be > sure that it continues to work. Note this isn't in the acpi locking > path but ACPI-CA has its own locks which are now not redundantly covered > by Giant. It has been running this way in Linux for a year or so. > Still, it's good to have that test coverage too. Ok, will do. I probably won't have it done by the time you planned to commit this, but given current results I suggest you don't wait... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 19:41:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A69B16A4CE for ; Thu, 12 Aug 2004 19:41:44 +0000 (GMT) Received: from lakermmtao05.cox.net (lakermmtao05.cox.net [68.230.240.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D50243D31 for ; Thu, 12 Aug 2004 19:41:44 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.71.51]) by lakermmtao05.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040812194141.HETE28993.lakermmtao05.cox.net@dolphin.local.net> for ; Thu, 12 Aug 2004 15:41:41 -0400 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with ESMTP id i7CJfgnC000963 for ; Thu, 12 Aug 2004 14:41:42 -0500 (CDT) (envelope-from conrads@dolphin.local.net) Received: (from conrads@localhost) by dolphin.local.net (8.13.1/8.13.1/Submit) id i7CJfb5A000962 for freebsd-current@freebsd.org; Thu, 12 Aug 2004 14:41:37 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 12 Aug 2004 14:41:37 -0500 (CDT) Organization: A Rag-Tag Band of Drug-Crazed Hippies From: "Conrad J. Sabatier" To: freebsd-current@freebsd.org Subject: builworld fails if debugging enabled in usr.sbin/pkg_install/lib X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conrads@cox.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2004 19:41:44 -0000 To help in debugging a problem with news/pan2, I decided to try rebuilding the port and all of its dependencies with debugging enabled. Then I decided to go ahead and do the same with the base system. The buildworld with "-g" worked fine with one exception: cc -O2 -pipe -march=athlon64 -m64 -g 1 -Wsystem-headers -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wformat=2 -Wno-format-extra-args -c /usr/src/usr.sbin/pkg_install/lib/file.c cc: 1: No such file or directory *** Error code 1 Stop in /usr/src/usr.sbin/pkg_install/lib. I can't figure out where this "1" just after the "-g" switch is coming from. Without "-g", the compile works OK: cc -O2 -pipe -march=athlon64 -m64 -Wsystem-headers -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wformat=2 -Wno-format-extra-args -c /usr/src/usr.sbin/pkg_install/lib/file.c Strange. -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 19:44:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C85116A4CE; Thu, 12 Aug 2004 19:44:47 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id A360543D1F; Thu, 12 Aug 2004 19:44:46 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i7CJib4f021202; Thu, 12 Aug 2004 12:44:41 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200408121944.i7CJib4f021202@gw.catspoiler.org> Date: Thu, 12 Aug 2004 12:44:37 -0700 (PDT) From: Don Lewis To: rwatson@FreeBSD.org In-Reply-To: <200408112123.i7BLNZfX018166@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: mb@imp.ch cc: freebsd-current@FreeBSD.org Subject: Re: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 19:44:47 -0000 On 11 Aug, To: rwatson@freebsd.org wrote: > I've noticed in fork()/exec() intensive loads like buildworld and > building ports on a UP box that ULE favors a CPU-bound but niced process > like setiathome over the software build. Even the longer c++ compile > steps seem to get less CPU time, than the niced CPU-bound process, at > least according to top. Buildworld times with ULE on my Athlon XP box > are about 145 minutes with ULE and 82 minutes with 4BSD when competing > with setiathome. Top shows setiathome consistently getting about 55% of > the CPU with ULE. Without setiathome running, buildworld takes about 65 > minutes. Here's a case where there is not much fork()/exec() activity (last pid is stable), and there doesn't appear to be much I/O, but the niced process is getting more than 50% of the CPU. I noticed this during a portupgrade of editors/openoffice-1.1. The CPU% for setiathome seems to stay right around in this range +/- a percent or so, with spikes higher when the other processes normally competing for CPU time are waiting for I/O. 57 processes: 3 running, 53 sleeping, 1 stopped CPU states: 42.8% user, 56.0% nice, 1.2% system, 0.0% interrupt, 0.0% idle Mem: 99M Active, 628M Inact, 156M Wired, 31M Cache, 111M Buf, 83M Free Swap: 2055M Total, 84K Used, 2055M Free Seconds to delay: PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 504 setiathome 139 15 17744K 16884K RUN 719:22 54.69% 54.69% setiathome 64008 root 139 0 4232K 3832K RUN 11:50 41.41% 41.41% dmake 568 dl 76 0 6084K 2324K select 5:08 0.00% 0.00% sshd 483 uucp 76 0 1336K 988K select 2:36 0.00% 0.00% newapc 16995 root 76 0 1284K 760K select 2:21 0.00% 0.00% script 12823 root -8 0 1200K 552K piperd 2:03 0.00% 0.00% tee 485 uucp 76 0 1308K 944K select 0:33 0.00% 0.00% upsd 53855 root 8 0 4956K 4212K wait 0:13 0.00% 0.00% perl 489 uucp 8 0 1316K 1012K nanslp 0:12 0.00% 0.00% upsmon 410 root 76 0 2876K 1500K select 0:10 0.00% 0.00% ntpd 59764 dl 76 0 2400K 1604K RUN 0:07 0.00% 0.00% top 437 root 76 0 3436K 2300K select 0:05 0.00% 0.00% sendmail 12822 root 8 0 21348K 20792K wait 0:02 0.00% 0.00% ruby18 490 uucp 8 0 1272K 908K nanslp 0:01 0.00% 0.00% upslog 1101 dl 76 0 6084K 2324K select 0:01 0.00% 0.00% sshd 454 root 8 0 1356K 1004K nanslp 0:01 0.00% 0.00% cron 657 root 20 0 2440K 1940K pause 0:01 0.00% 0.00% csh From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 19:46:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BB5616A4CE for ; Thu, 12 Aug 2004 19:46:20 +0000 (GMT) Received: from mail.parodius.com (mail.parodius.com [64.62.145.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7704743D39 for ; Thu, 12 Aug 2004 19:46:20 +0000 (GMT) (envelope-from jdc@pentarou.parodius.com) Received: from pentarou.parodius.com (jdc@localhost [127.0.0.1]) by mail.parodius.com (8.12.11/8.12.11) with ESMTP id i7CJkKEB065324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Aug 2004 12:46:20 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: (from jdc@localhost) by pentarou.parodius.com (8.12.11/8.12.11/Submit) id i7CJkKL6065323 for current@freebsd.org; Thu, 12 Aug 2004 12:46:20 -0700 (PDT) (envelope-from jdc) Date: Thu, 12 Aug 2004 12:46:20 -0700 From: Jeremy Chadwick To: current@freebsd.org Message-ID: <20040812194619.GA65076@parodius.com> Mail-Followup-To: current@freebsd.org References: <411BB2EC.1020903@he.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <411BB2EC.1020903@he.iki.fi> User-Agent: Mutt/1.5.6i Subject: Re: boot loader crashes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 19:46:20 -0000 This sounds related to the "boot2" madness we went through about a week ago. There's too many threads to point you to, but as it stands now, things work. I can confirm that at one time there was a problem with the loader breaking (i.e. when boot2 loaded, it would quickly panic/spit out exceptions, then immediately reboot the machine), but that was taken care of as well. I would recommend rebuilding the bootblocks and re-applying them. In addition, reinstall the boot0 blocks as well, just to be safe. A quick walkthrough: # cd /usr/src/sys/boot # make clean # make # make install # disklabel -B (i.e. "ad0s1") # boot0cfg -B (i.e. "ad0") -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | On Thu, Aug 12, 2004 at 09:11:56PM +0300, Petri Helenius wrote: > > I updated a machine with ABIT VP6 (dual S370) motherboard from -CURRENT > in May to recent -CURRENT and since then the boot crashes with a message > which is visible for only a fraction of a second until the BIOS message > shows again. This is reproduceable with recent CD's. I´m able to boot > the system using 5.2.1 release CD and then just switching over to the HD. > > The bootloader seems to gone through multiple changes so I couldn´t > immediately locate a place which could be at fault. > > Any ideas or suggestions would be appreciated, I would hate to have to > ditch the board. > > Pete > > _______________________________________________ > 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 Aug 12 19:53:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5D3C16A4CE for ; Thu, 12 Aug 2004 19:53:08 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2D8843D48 for ; Thu, 12 Aug 2004 19:53:07 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7CJqo6R054452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2004 22:52:51 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7CJqrWq079419; Thu, 12 Aug 2004 22:52:53 +0300 (EEST) (envelope-from ru) Date: Thu, 12 Aug 2004 22:52:52 +0300 From: Ruslan Ermilov To: "Conrad J. Sabatier" Message-ID: <20040812195252.GA79364@ip.net.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: freebsd-current@freebsd.org Subject: Re: builworld fails if debugging enabled in usr.sbin/pkg_install/lib X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 19:53:09 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 12, 2004 at 02:41:37PM -0500, Conrad J. Sabatier wrote: > To help in debugging a problem with news/pan2, I decided to try > rebuilding the port and all of its dependencies with debugging enabled. > Then I decided to go ahead and do the same with the base system. The > buildworld with "-g" worked fine with one exception: >=20 > cc -O2 -pipe -march=3Dathlon64 -m64 -g 1 -Wsystem-headers -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -Wformat=3D2 -Wno-format-extra-args -c > /usr/src/usr.sbin/pkg_install/lib/file.c > cc: 1: No such file or directory > *** Error code 1 >=20 > Stop in /usr/src/usr.sbin/pkg_install/lib. >=20 > I can't figure out where this "1" just after the "-g" switch is coming > from. Without "-g", the compile works OK: >=20 > cc -O2 -pipe -march=3Dathlon64 -m64 -Wsystem-headers -Wall > -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-uninitialized -Wformat=3D2 -Wno-format-extra-args -c > /usr/src/usr.sbin/pkg_install/lib/file.c >=20 > Strange. >=20 How are you building your world with -g? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBG8qUqRfpzJluFF4RAl/DAJ4wOIs+/4oZX1EEFQL2DyoOfXhcWACgj0cF 03rCFGlA8g6DRLm7FPgF/GU= =Qdqh -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 19:56:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C77E116A4CE for ; Thu, 12 Aug 2004 19:56:21 +0000 (GMT) Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3452E43D5D for ; Thu, 12 Aug 2004 19:56:21 +0000 (GMT) (envelope-from stijn@pcwin002.win.tue.nl) Received: from pcwin002.win.tue.nl (orb_rules@localhost [127.0.0.1]) by pcwin002.win.tue.nl (8.12.11/8.12.11) with ESMTP id i7CJuIwm056140; Thu, 12 Aug 2004 21:56:18 +0200 (CEST) (envelope-from stijn@pcwin002.win.tue.nl) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.12.11/8.12.11/Submit) id i7CJuHe9056139; Thu, 12 Aug 2004 21:56:17 +0200 (CEST) (envelope-from stijn) Date: Thu, 12 Aug 2004 21:56:17 +0200 From: Stijn Hoop To: Allan Fields Message-ID: <20040812195617.GB53082@pcwin002.win.tue.nl> References: <20040808211337.GB91609@pcwin002.win.tue.nl> <20040809074732.GA3155@afields.ca> <20040809075228.GC91609@pcwin002.win.tue.nl> <20040809081901.GB3155@afields.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jq0ap7NbKX2Kqbes" Content-Disposition: inline In-Reply-To: <20040809081901.GB3155@afields.ca> User-Agent: Mutt/1.4.2.1i X-Bright-Idea: Let's abolish HTML mail! cc: freebsd-current@freebsd.org Subject: Re: slice weirdness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 19:56:21 -0000 --jq0ap7NbKX2Kqbes Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Resolution: it turns out to be related to the bootmanager I used to boot off the primary slave ATA drive; or at least, if I tell it to virtually swap the drives, the system boots (I still suspect something in the interaction thou= gh; this is the first time in 5 years that Smart Bootmanager has let me down -- http://btmgr.sf.net/). Now the problem is that although the boot works, something prevents me from fdisking/relabeling ad0 -- I suspect something in GEOM gets confused by the boot from 'ad0' which turns out to be 'ad1' when the FreeBSD ata driver loo= ks at things... *sigh* I'm going to try fdisk/disklabel from a fixit floppy, and if that doesn't w= ork I'll just reinstall by hand from CD, onto an ad0/ad2 gvinum mirror (which w= as the point of this frustrating exercise). Thanks for thinking along with me :) --Stijn --=20 "I used to think I was indecisive, but now I'm not so sure." --jq0ap7NbKX2Kqbes Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBG8thY3r/tLQmfWcRAiYdAKCYl8acoCYDC/uX73xrTj1UPDxXpQCgsEtr 3ngnBVGR03k+yQxu2fI04jI= =ITlm -----END PGP SIGNATURE----- --jq0ap7NbKX2Kqbes-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 19:58:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70D0A16A4CE; Thu, 12 Aug 2004 19:58:30 +0000 (GMT) Received: from lakermmtao01.cox.net (lakermmtao01.cox.net [68.230.240.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id E210943D2F; Thu, 12 Aug 2004 19:58:29 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.71.51]) by lakermmtao01.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP <20040812195829.KCFP15539.lakermmtao01.cox.net@dolphin.local.net>; Thu, 12 Aug 2004 15:58:29 -0400 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with ESMTP id i7CJwSuQ001127; Thu, 12 Aug 2004 14:58:28 -0500 (CDT) (envelope-from conrads@dolphin.local.net) Received: (from conrads@localhost) by dolphin.local.net (8.13.1/8.13.1/Submit) id i7CJwNn3001126; Thu, 12 Aug 2004 14:58:23 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20040812195252.GA79364@ip.net.ua> Date: Thu, 12 Aug 2004 14:58:23 -0500 (CDT) Organization: A Rag-Tag Band of Drug-Crazed Hippies From: "Conrad J. Sabatier" To: Ruslan Ermilov cc: freebsd-current@freebsd.org Subject: Re: builworld fails if debugging enabled in usr.sbin/pkg_install/lib X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conrads@cox.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2004 19:58:30 -0000 On 12-Aug-2004 Ruslan Ermilov wrote: > On Thu, Aug 12, 2004 at 02:41:37PM -0500, Conrad J. Sabatier wrote: >> To help in debugging a problem with news/pan2, I decided to try >> rebuilding the port and all of its dependencies with debugging >> enabled. >> Then I decided to go ahead and do the same with the base system. >> The >> buildworld with "-g" worked fine with one exception: >> >> cc -O2 -pipe -march=athlon64 -m64 -g 1 -Wsystem-headers -Wall >> -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith -Wno-uninitialized -Wformat=2 -Wno-format-extra-args >> -c >> /usr/src/usr.sbin/pkg_install/lib/file.c >> cc: 1: No such file or directory >> *** Error code 1 >> >> Stop in /usr/src/usr.sbin/pkg_install/lib. >> >> I can't figure out where this "1" just after the "-g" switch is >> coming >> from. Without "-g", the compile works OK: >> >> cc -O2 -pipe -march=athlon64 -m64 -Wsystem-headers -Wall >> -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith -Wno-uninitialized -Wformat=2 -Wno-format-extra-args >> -c >> /usr/src/usr.sbin/pkg_install/lib/file.c >> >> Strange. >> > How are you building your world with -g? I have the following in /etc/make.conf: .if defined(DEBUG) CFLAGS+=-g .endif And then use "make -DDEBUG buildworld". -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 20:11:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB39516A4CE for ; Thu, 12 Aug 2004 20:11:51 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 385F543D49 for ; Thu, 12 Aug 2004 20:11:51 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7CKBZiN056058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2004 23:11:36 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7CKBc6P079709; Thu, 12 Aug 2004 23:11:38 +0300 (EEST) (envelope-from ru) Date: Thu, 12 Aug 2004 23:11:38 +0300 From: Ruslan Ermilov To: "Conrad J. Sabatier" Message-ID: <20040812201138.GA79664@ip.net.ua> References: <20040812195252.GA79364@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: freebsd-current@freebsd.org Subject: Re: builworld fails if debugging enabled in usr.sbin/pkg_install/lib X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 20:11:52 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 12, 2004 at 02:58:23PM -0500, Conrad J. Sabatier wrote: >=20 > On 12-Aug-2004 Ruslan Ermilov wrote: > > On Thu, Aug 12, 2004 at 02:41:37PM -0500, Conrad J. Sabatier wrote: > >> To help in debugging a problem with news/pan2, I decided to try > >> rebuilding the port and all of its dependencies with debugging > >> enabled. > >> Then I decided to go ahead and do the same with the base system.=20 > >> The > >> buildworld with "-g" worked fine with one exception: > >>=20 > >> cc -O2 -pipe -march=3Dathlon64 -m64 -g 1 -Wsystem-headers -Wall > >> -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > >> -Wpointer-arith -Wno-uninitialized -Wformat=3D2 -Wno-format-extra-args > >> -c > >> /usr/src/usr.sbin/pkg_install/lib/file.c > >> cc: 1: No such file or directory > >> *** Error code 1 > >>=20 > >> Stop in /usr/src/usr.sbin/pkg_install/lib. > >>=20 > >> I can't figure out where this "1" just after the "-g" switch is > >> coming > >> from. Without "-g", the compile works OK: > >>=20 > >> cc -O2 -pipe -march=3Dathlon64 -m64 -Wsystem-headers -Wall > >> -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes > >> -Wpointer-arith -Wno-uninitialized -Wformat=3D2 -Wno-format-extra-args > >> -c > >> /usr/src/usr.sbin/pkg_install/lib/file.c > >>=20 > >> Strange. > >>=20 > > How are you building your world with -g? >=20 > I have the following in /etc/make.conf: >=20 > .if defined(DEBUG) > CFLAGS+=3D-g > .endif >=20 > And then use "make -DDEBUG buildworld". >=20 I suspected something like this. src/usr.sbin/pkg_install/*/Makefile's added the contents of the DEBUG variable to CFLAGS. By passing the -DDEBUG to make(1), you effectively set the value of the DEBUG variable to 1 (see the make(1) manpage), so "1" was added to CFLAGS. I've "fixed" these makefiles to not add DEBUG to CFLAGS. Note that the name DEBUG is unsafe to use anyway. Also, there's an alternative and standard way to recompile your programs and libraries with -g: there's the DEBUG_FLAGS variable, so you could as well do it like this: make buildworld DEBUG_FLAGS=3D-g Passing DEBUG_FLAGS=3D-g to ``make installworld'' will also cause the binaries to *not* be stripped when installing, which is essential for having the debugger symbols in binaries. Please consider switching to this method of building world with debug infomation. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBG876qRfpzJluFF4RAsrQAJ9iLuyTpwtUqsh9Fxla4QBkTY+3gACeKXuK 0ajVk3ztUCiT+FSw3W2XjGc= =rqvP -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 19:05:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 501AB16A4CE for ; Thu, 12 Aug 2004 19:05:08 +0000 (GMT) Received: from mirapoint2.tis.cwru.edu (mirapoint2.TIS.CWRU.Edu [129.22.104.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10A6D43D39 for ; Thu, 12 Aug 2004 19:05:08 +0000 (GMT) (envelope-from jrh29@po.cwru.edu) Received: from [192.168.1.108] (oh-clevelandheights-cdnt1-bg1b-147.clvdoh.adelphia.net [68.170.192.147]) by mirapoint2.tis.cwru.edu (MOS 3.4.3-CR) with ESMTP id BVL71324 (AUTH jrh29); Thu, 12 Aug 2004 15:05:06 -0400 (EDT) In-Reply-To: <20040812195831.033a78af.steve@sohara.org> References: <20040812195831.033a78af.steve@sohara.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <803F0AA1-EC92-11D8-819F-000A95841F44@po.cwru.edu> Content-Transfer-Encoding: 7bit From: Justin Hibbits Date: Thu, 12 Aug 2004 15:04:56 -0400 To: "Steve O'Hara-Smith" X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Mailman-Approved-At: Thu, 12 Aug 2004 20:12:45 +0000 cc: freebsd-current@freebsd.org Subject: Re: Preliminary ATI TV Wonder bktr support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 19:05:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 12, 2004, at 14:58, Steve O'Hara-Smith wrote: > On Thu, 12 Aug 2004 08:48:49 -0400 > Justin Hibbits wrote: > >> It's not complete (no sound yet, and no idea where to begin), but the >> ATI TV Wonder is now auto configured. Source merged from OpenBSD. >> Since I'm not a regular FreeBSD hacker, I'm posting it here. I hope >> it's the right list. > > Is this against -current or against 4.x, if the former what are > my chances of merging it to 4.x ? > > -- > C:>WIN | Directable Mirror > Arrays > The computer obeys and wins. | A better way to focus > the sun > You lose and Bill collects. | licences available see > | http://www.sohara.org/ It's against 5-CURRENT, it might be merge-able into 4.x, since it's not a very big patch. Also, it doesn't have sound support, so if you like just watching TV, and not hearing it, it's fine. Or if you can get sound working, that'd be great :) - -Justin - -- "And now, if you'll excuse me, I'm in the middle of 15 things, all annoying" -- Lt. Cmdr Susan Ivanova, Babylon 5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFBG79dqt29EJDZlM4RAr+EAJ97mpaxVjPzZw5f6PShbuUzTGWOVQCgtIoS UDt5sh75dqc73ywI/u2ZsMw= =vWA3 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 19:07:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFBCF16A4CF for ; Thu, 12 Aug 2004 19:07:48 +0000 (GMT) Received: from mirapoint2.tis.cwru.edu (mirapoint2.TIS.CWRU.Edu [129.22.104.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7818343D3F for ; Thu, 12 Aug 2004 19:07:48 +0000 (GMT) (envelope-from jrh29@po.cwru.edu) Received: from [192.168.1.108] (oh-clevelandheights-cdnt1-bg1b-147.clvdoh.adelphia.net [68.170.192.147]) by mirapoint2.tis.cwru.edu (MOS 3.4.3-CR) with ESMTP id BVL71976 (AUTH jrh29); Thu, 12 Aug 2004 15:07:46 -0400 (EDT) In-Reply-To: <20040812185242.GA53082@pcwin002.win.tue.nl> References: <20040812185242.GA53082@pcwin002.win.tue.nl> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Justin Hibbits Date: Thu, 12 Aug 2004 15:07:36 -0400 To: Stijn Hoop X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Mailman-Approved-At: Thu, 12 Aug 2004 20:12:45 +0000 cc: freebsd-current@freebsd.org Subject: Re: Preliminary ATI TV Wonder bktr support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 19:07:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 12, 2004, at 14:52, Stijn Hoop wrote: > Hi, > > On Thu, Aug 12, 2004 at 08:48:49AM -0400, Justin Hibbits wrote: >> It's not complete (no sound yet, and no idea where to begin), but the >> ATI TV Wonder is now auto configured. Source merged from OpenBSD. >> Since I'm not a regular FreeBSD hacker, I'm posting it here. I hope >> it's the right list. > > I'm not qualified to comment on that, but if this isn't picked up by a > committer you might want to consider using send-pr(1) to send this > patch > to the FreeBSD bug database. Yeah, I sent a followup to the PR database (PR 60599), after this post. Cross-posted to current@, so you should see it soon. >> Anyway, maybe someone can figure out how to go from here, since I'm >> stuck now. I'll continue working on it though. > > FWIW, I recall that most of the open source BT878 drivers don't do > internal > sound, and instead rely on you to feed the audio channel into your > soundcard. > At least, that's what works for me with a no-name TV tuner card; it > even > included a male-male minijack cable to do so. So if that's all that's > missing, > you might be as far along as anyone has ever been. Yeah, I have audio being fed directly to the soundcard, with all mixer settings set properly. This setup works perfectly with Linux, just not FreeBSD. I sent an email to Gerd Knorr (author of the bttv driver for Linux) about my problem, hoping he can point me in the right direction to get it working. > --Stijn > > -- > An Orb is for life, not just for Christmas. - -Justin - -- "And now, if you'll excuse me, I'm in the middle of 15 things, all annoying" -- Lt. Cmdr Susan Ivanova, Babylon 5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFBG7/+qt29EJDZlM4RAsSuAKC2lYmkNWnNiFWIozM5RA+7A1psqQCgkcd3 dsG7anQxR91DsNvpmNsfuTE= =6X8S -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 20:27:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21DB016A4CE; Thu, 12 Aug 2004 20:27:04 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBF0A43D2D; Thu, 12 Aug 2004 20:27:03 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-67-115-74-195.dsl.lsan03.pacbell.net [67.115.74.195]) i7CKR0nA011071; Thu, 12 Aug 2004 16:27:01 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A78F052834; Thu, 12 Aug 2004 13:26:57 -0700 (PDT) Date: Thu, 12 Aug 2004 13:26:57 -0700 From: Kris Kennaway To: Steve Ames Message-ID: <20040812202657.GB17615@xor.obsecurity.org> References: <20040811224504.GA46960@xor.obsecurity.org> <20040812091148.GB57570@dragon.nuxi.com> <20040812134059.GA47431@energistic.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i9LlY+UWpKt15+FH" Content-Disposition: inline In-Reply-To: <20040812134059.GA47431@energistic.com> User-Agent: Mutt/1.4.2.1i cc: current@FreeBSD.org cc: David O'Brien cc: Kris Kennaway Subject: Re: gcc 3.4.2/x.org packages uploaded X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 20:27:04 -0000 --i9LlY+UWpKt15+FH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 12, 2004 at 08:40:59AM -0500, Steve Ames wrote: > On Thu, Aug 12, 2004 at 02:11:48AM -0700, David O'Brien wrote: > > On Wed, Aug 11, 2004 at 03:45:04PM -0700, Kris Kennaway wrote: > > > I've uploaded a full package set built with gcc 3.4.2 and x.org, > >=20 > > Thanks! > >=20 > > Any timeline on updated AMD64 64-bit packages? >=20 > If there are now packages missing (gatekeeper for instance) its > because they didn't compile? Yes, or something they depend on did not compile. Check the error logs on pointyhat. Kris --i9LlY+UWpKt15+FH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBG9KRWry0BWjoQKURAmjsAKCinN0kKJBIFXcIfTc7zD9UUH+G3QCdG2Zy O386/nmfe1ucL5bYC2UyhoY= =GORP -----END PGP SIGNATURE----- --i9LlY+UWpKt15+FH-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 21:04:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53C7916A4CE for ; Thu, 12 Aug 2004 21:04:11 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id F059843D5F for ; Thu, 12 Aug 2004 21:04:10 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BvMk5-0007UE-00; Thu, 12 Aug 2004 23:04:09 +0200 Received: from [217.83.7.130] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BvMk5-0001Fn-00; Thu, 12 Aug 2004 23:04:09 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Thu, 12 Aug 2004 23:02:10 +0200 User-Agent: KMail/1.6.2 References: <20040812171410.GA91666@neo.redjade.org> <200408121938.04611.max@love2party.net> In-Reply-To: <200408121938.04611.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_br9GBkIlRNeEuuD"; charset="euc-kr" Content-Transfer-Encoding: 7bit Message-Id: <200408122302.19418.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Sangwoo Shim cc: yongari@kt-is.co.kr Subject: Re: Panic in nd6_slowtimo() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 21:04:11 -0000 --Boundary-02=_br9GBkIlRNeEuuD Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 12 August 2004 19:37, Max Laier wrote: > This was reported before, but I was never able to reproduce it and the > original reporter didn't reply anymore (iirc). Can you please turn this > into a PR so that we do not lose track this time? I will be looking into > it. =46or the record, the first report of this was to freebsd-current with Message-Id: <20040427025951.F756@fw.reifenberger.com> Subject: panics using pf =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_br9GBkIlRNeEuuD Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBG9rbXyyEoT62BG0RAuNAAJ9h4kvkm8BGJPA5Z6y/4803s1emcACePueA jIDn3IvQGBxZS9XtlZPsN7g= =UFwU -----END PGP SIGNATURE----- --Boundary-02=_br9GBkIlRNeEuuD-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 21:56:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 155F216A4CE for ; Thu, 12 Aug 2004 21:56:02 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id C727043D2D for ; Thu, 12 Aug 2004 21:56:01 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from mailnull by anduin.net with spam-scanned (Exim 4.34; FreeBSD) id 1BvNYG-000Dbw-5K for current@freebsd.org; Thu, 12 Aug 2004 23:56:00 +0200 Received: from [217.8.136.185] (helo=[192.168.1.237]) by anduin.net with esmtp (Exim 4.34; FreeBSD) id 1BvNYA-000Dbj-Jz; Thu, 12 Aug 2004 23:55:55 +0200 Message-ID: <411BE765.8030100@anduin.net> Date: Thu, 12 Aug 2004 23:55:49 +0200 From: Eirik Oeverby User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer , current@freebsd.org References: <20040808222837.2E72A16A4D3@hub.freebsd.org> <41173194.6020309@elischer.org> <20040811101431.GA11809@rogue.acs-et.com> <411AA2B0.9020900@elischer.org> <411ACCDB.9060904@elischer.org> In-Reply-To: <411ACCDB.9060904@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on anduin.net X-Spam-Level: X-Spam-Status: No, hits=0.0 required=7.5 tests=none autolearn=no version=2.63 Subject: Re: Code for review.. threads vs. the scheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 21:56:02 -0000 Julian Elischer wrote: > > > Here is a version of the diff that is pretty much functionaly equivalent > to the current system (and > almost identical to patches (c) and (d) (*) but it takes it astep > further in that teh struct kse has been > removed from proc.h and made a private structure within each > scheduler. Nothing outside of the 3 files > kern/sched_4bsd, kern/sched_ule.c and kern/kern_switch.c (which is now > included into the schedulers > rather than linked with them) even knows what a struct kse looks like. > > (*) these patches were not widly distributed. > > The patch is available at: > > http://www.freebsd.org/~julian/e.diff > > At this point each scheduler can be alterred almost completely > independently of the other as long as the > fields in the kse that are referenced in the common code in > kern_switch.c are not renamed or removed. > > -where to from here.... > > The next logical step is to move the fields within the thread, and > ksegrp structures that reference kses into > the scheduler specific extensions to these structures so that not even > those references are externally visible. > This would make the queues and lists that are used to hang KSEs off > also private information for the > scheduler, allowing schedulers to have their own private queueing > architectures without having to expose them > to anything external.. > > The NEXT step after that is to move all the fields in the KSE structure > into the thread's scheduler-private > structure (td_sched) and rename it a "kse" to stop the need for massive > mechanical renaming. > Since every thread has one of these, all the KSE allocation code just > vanishes as do the restraints that they > hold on code due to locking requirements etc. sched_ule and sched_4bsd > don't change much at all. > "concurrency control " is switched to use a simple pair of counters. > (available slots and total slots (concurrency) per ksegrp. Except for > that change, even kern_switch.c > remains mostly the same and the KSE structure as we know it has > dissappeared entirely (though > its name is passed to the td_sched structure for diff-reduction > purposes.. > > when this is done we have a scheduler interface that COMPLETELY hides > within it > how and where threads are queued, or in fact if they are queued at all.. > (A Monte-Carlo scheduler may use a completely different scheme based on > probablilistic scheduling..) > > It should also be a lot more reliable and I suspect that the morphing of > the KSE structure into something > that is always a part of the thread MIGHT also fix the Preemption hang > we've been seeing. > > Sched-ule and sched-4bsd can then be experimented on a lot more freely > without worrying about > unintended changes to teh other. Especially if one of the schedulers > takes a complete copy of > kern_switch.c instead of including it.. Indeed a new scheduler can be > added with a single file, > and no other edits, allowing people to experiment with their own > schedulers much more easily. > Hi there, did anyone actually test this patch? Maybe a change of subject line might help get some attention.. I am very tempted to test it, if there is any chance that it might, in its current form, help stabilizing things on -current. Especially with the preemption issues in the back of my head.. /Eirik From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 21:59:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A4BB16A4CE for ; Thu, 12 Aug 2004 21:59:12 +0000 (GMT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3409C43D1D for ; Thu, 12 Aug 2004 21:59:11 +0000 (GMT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (blackwater.lemis.com [192.109.197.80]) by ozlabs.org (Postfix) with ESMTP id 734B42BD43 for ; Fri, 13 Aug 2004 07:59:09 +1000 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 2397551201; Fri, 13 Aug 2004 07:28:59 +0930 (CST) Date: Fri, 13 Aug 2004 07:28:59 +0930 From: Greg 'groggy' Lehey To: FreeBSD current users Message-ID: <20040812215859.GM19643@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w+ok4pmHMnU+ibn4" Content-Disposition: inline User-Agent: Mutt/1.4.1i Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Subject: Current method of dumping a processor? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 21:59:12 -0000 --w+ok4pmHMnU+ibn4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I've tried it on kernels built in January, May and yesterday. In each case, I did: dumpon /dev/ad0s2b (for appropriate values of ad0s2b). All kernels include ddb. I entered the debugger with ctrl-alt-esc and entered "panic". The kernel from January dumps just fine. The kernels from May and August hang. Am I doing something wrong? Has something else changed? Does anybody else have this problem? Greg -- Note: I discard all HTML mail unseen. Finger grog@lemis.com for PGP public key. See complete headers for address and phone numbers. --w+ok4pmHMnU+ibn4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQFBG+gjIubykFB6QiMRArYTAJ0VaG4xmTDeLKz1h5W9i+zSLxBDegCglpc4 dOKtM0ewNYr16k5yhyU38AY= =ws1Z -----END PGP SIGNATURE----- --w+ok4pmHMnU+ibn4-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 22:14:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AD5516A4CE for ; Thu, 12 Aug 2004 22:14:28 +0000 (GMT) Received: from phoenix.gargantuan.com (rrcs-se-24-73-171-238.biz.rr.com [24.73.171.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id C563243D48 for ; Thu, 12 Aug 2004 22:14:27 +0000 (GMT) (envelope-from freebsd-current@gargantuan.com) Received: from localhost (localhost.gargantuan.com [127.0.0.1]) by spamassassin-injector (Postfix) with SMTP id 427FE4DA for ; Thu, 12 Aug 2004 18:14:25 -0400 (EDT) Received: by phoenix.gargantuan.com (Postfix, from userid 1001) id 4020620D; Thu, 12 Aug 2004 18:13:48 -0400 (EDT) Date: Thu, 12 Aug 2004 18:13:48 -0400 From: "Michael W. Oliver" To: freebsd-current@freebsd.org Message-ID: <20040812221348.GA1337@gargantuan.com> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline X-WWW-Site: http://michael.gargantuan.com X-PGP-Public-Key: $X-WWW-Site/gnupg/pubkey.asc X-PGP-Fingerprint: 2694 0179 AE3F BFAE 0916 0BF5 B16B FBAB C5FA A3C9 X-Home-Phone: +1-863-816-8091 X-Mobile-Phone: +1-863-738-2334 X-Home-Address0: 8008 Apache Lane X-Home-Address1: Lakeland, FL X-Home-Address2: 33810-2172 X-Home-Address3: United States of America X-Good-Question-Guide: http://www.catb.org/~esr/faqs/smart-questions.html X-Netiquette-Guidelines: http://www.ietf.org/rfc/rfc1855.txt User-Agent: Mutt/1.5.6i X-Spam-DCC: : X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on phoenix.gargantuan.com X-Spam-Level: X-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,BAYES_00,NO_DNS_FOR_FROM autolearn=no version=2.64 Subject: pcm_chn_create failed with 2004-08-12 kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 22:14:28 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Ok, this world was cvsup'd on 2004.08.12 at 09:59:03 EDT. I removed the 'sound' and 'snd_maestro' device lines from my kernel config and decided to load them as modules (after I got the same output shown below with sound and snd_maestro compiled into the kernel). When I kldload 'sound', I get no output. After that, when I kldload 'snd_maestro', I get the following output: pcm0: port 0x1400-0x14ff irq 10 at device 8.0 o= n pci0 pcm0: pcm0: [GIANT-LOCKED] pcm0: offset 0xfffa1000 exceeds limit. pcm0: chn_init(pcm0:play:0) failed: = err =3D 19 pcm0: pcm_chn_create(aggch, 1, 0xc223e700) failed pcm0: offset 0xfffa1000 exceeds limit. pcm0: chn_init(pcm0:play:0) failed: = err =3D 19 pcm0: pcm_chn_create(aggch, 1, 0xc223e700) failed pcm0: offset 0xfffa1000 exceeds limit. pcm0: chn_init(pcm0:play:0) failed: = err =3D 19 pcm0: pcm_chn_create(aggch, 1, 0xc223e700) failed pcm0: offset 0xfffa1000 exceeds limit. pcm0: chn_init(pcm0:play:0) failed: = err =3D 19 pcm0: pcm_chn_create(aggch, 1, 0xc223e700) failed Here is the output from `cat /dev/sndstat`: FreeBSD Audio Driver (newpcm) Installed devices: pcm0: at I/O port 0x1400 irq 10 kld snd_maestro= (mixer only) I am guessing that I get "(mixer only)" because the "pcm_chn_create" failed. The latest CURRENT that I was running before this iteration was =66rom sources that were cvsup'd on 2004-07-23 at 23:46:38 EDT. Any suggestions are most welcome, thanks. kernel config ----> http://michael.gargantuan.com/cyclops.kernel.config acpidump -t -d ---> http://michael.gargantuan.com/dump.asl dmesg -a ---------> http://michael.gargantuan.com/cyclops.dmesg --=20 Mike perl -e 'print unpack("u","88V]N=3D&%C=3D\"!I;F9O(&EN(&AE861E Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E25A16A4CE; Thu, 12 Aug 2004 22:39:59 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25CCE43D2F; Thu, 12 Aug 2004 22:39:58 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i7CMddjc021563; Thu, 12 Aug 2004 15:39:44 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200408122239.i7CMddjc021563@gw.catspoiler.org> Date: Thu, 12 Aug 2004 15:39:39 -0700 (PDT) From: Don Lewis To: rwatson@FreeBSD.org In-Reply-To: <200408121944.i7CJib4f021202@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: jroberson@chesapeake.net cc: freebsd-current@FreeBSD.org Subject: nice handling in ULE (was: Re: SCHEDULE and high load situations) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 22:39:59 -0000 On 12 Aug, Don Lewis wrote: > Here's a case where there is not much fork()/exec() activity (last pid > is stable), and there doesn't appear to be much I/O, but the niced > process is getting more than 50% of the CPU. I noticed this during a > portupgrade of editors/openoffice-1.1. The CPU% for setiathome seems to > stay right around in this range +/- a percent or so, with spikes higher > when the other processes normally competing for CPU time are waiting for > I/O. > > 57 processes: 3 running, 53 sleeping, 1 stopped > CPU states: 42.8% user, 56.0% nice, 1.2% system, 0.0% interrupt, 0.0% idle > Mem: 99M Active, 628M Inact, 156M Wired, 31M Cache, 111M Buf, 83M Free > Swap: 2055M Total, 84K Used, 2055M Free > Seconds to delay: > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND > 504 setiathome 139 15 17744K 16884K RUN 719:22 54.69% 54.69% setiathome > 64008 root 139 0 4232K 3832K RUN 11:50 41.41% 41.41% dmake > 568 dl 76 0 6084K 2324K select 5:08 0.00% 0.00% sshd > 483 uucp 76 0 1336K 988K select 2:36 0.00% 0.00% newapc > 16995 root 76 0 1284K 760K select 2:21 0.00% 0.00% script > 12823 root -8 0 1200K 552K piperd 2:03 0.00% 0.00% tee > 485 uucp 76 0 1308K 944K select 0:33 0.00% 0.00% upsd > 53855 root 8 0 4956K 4212K wait 0:13 0.00% 0.00% perl > 489 uucp 8 0 1316K 1012K nanslp 0:12 0.00% 0.00% upsmon > 410 root 76 0 2876K 1500K select 0:10 0.00% 0.00% ntpd > 59764 dl 76 0 2400K 1604K RUN 0:07 0.00% 0.00% top > 437 root 76 0 3436K 2300K select 0:05 0.00% 0.00% sendmail > 12822 root 8 0 21348K 20792K wait 0:02 0.00% 0.00% ruby18 > 490 uucp 8 0 1272K 908K nanslp 0:01 0.00% 0.00% upslog > 1101 dl 76 0 6084K 2324K select 0:01 0.00% 0.00% sshd > 454 root 8 0 1356K 1004K nanslp 0:01 0.00% 0.00% cron > 657 root 20 0 2440K 1940K pause 0:01 0.00% 0.00% csh I did some experimentation, and the problem I'm seeing appears to just be related to how nice values are handled by ULE. I'm running two copies of the following program, one at nice +15, and the other not niced: hairball:~ 102>cat sponge.c int main(int argc, char **argv) { while (1) ; } The niced process was started second, but it has accumulated more CPU time and is getting a larger percentage of the CPU time according to top. last pid: 662; load averages: 2.00, 1.95, 1.45 up 0+00:22:35 15:14:27 31 processes: 3 running, 28 sleeping CPU states: 45.3% user, 53.1% nice, 1.2% system, 0.4% interrupt, 0.0% idle Mem: 22M Active, 19M Inact, 44M Wired, 28K Cache, 28M Buf, 408M Free Swap: 1024M Total, 1024M Free Seconds to delay: PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 599 dl 139 15 1180K 448K RUN 8:34 53.91% 53.91% sponge 598 dl 139 0 1180K 448K RUN 7:22 42.97% 42.97% sponge 587 dl 76 0 2288K 1580K RUN 0:03 0.00% 0.00% top 462 root 76 0 56656K 46200K select 0:02 0.00% 0.00% Xorg 519 gdm 76 0 11252K 8564K select 0:01 0.00% 0.00% gdmlogin 579 dl 76 0 6088K 2968K select 0:00 0.00% 0.00% sshd I thought it might have something to do with grouping by niceness, which would group the un-niced process with a bunch of other processes that wake up every now and then for a little bit if CPU time, so I tried the experiment again with nice +1 and nice +15. This gave a rather interesting result. Top reports the nice +15 process as getting a higher %CPU, but the nice +1 process has slowly accumulated a bit more total CPU time. The difference in total CPU time was initially seven seconds or less. last pid: 745; load averages: 2.00, 1.99, 1.84 up 0+00:43:30 15:35:22 31 processes: 3 running, 28 sleeping CPU states: 0.0% user, 99.6% nice, 0.4% system, 0.0% interrupt, 0.0% idle Mem: 22M Active, 19M Inact, 44M Wired, 28K Cache, 28M Buf, 408M Free Swap: 1024M Total, 1024M Free Seconds to delay: PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 675 dl 139 15 1180K 448K RUN 9:48 52.34% 52.34% sponge 674 dl 139 1 1180K 448K RUN 10:03 44.53% 44.53% sponge 587 dl 76 0 2288K 1580K RUN 0:06 0.00% 0.00% top 462 root 76 0 56656K 46200K select 0:03 0.00% 0.00% Xorg 519 gdm 76 0 11252K 8564K select 0:02 0.00% 0.00% gdmlogin 579 dl 76 0 6088K 2968K select 0:00 0.00% 0.00% sshd From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 22:54:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 348C316A4D0 for ; Thu, 12 Aug 2004 22:54:02 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE18943D41 for ; Thu, 12 Aug 2004 22:54:01 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i7CMrseZ021586; Thu, 12 Aug 2004 15:53:58 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200408122253.i7CMrseZ021586@gw.catspoiler.org> Date: Thu, 12 Aug 2004 15:53:54 -0700 (PDT) From: Don Lewis To: freebsd-current@gargantuan.com In-Reply-To: <20040812221348.GA1337@gargantuan.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org Subject: Re: pcm_chn_create failed with 2004-08-12 kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 22:54:02 -0000 On 12 Aug, Michael W. Oliver wrote: > Ok, this world was cvsup'd on 2004.08.12 at 09:59:03 EDT. I removed the > 'sound' and 'snd_maestro' device lines from my kernel config and decided > to load them as modules (after I got the same output shown below with > sound and snd_maestro compiled into the kernel). When I kldload > 'sound', I get no output. After that, when I kldload 'snd_maestro', I > get the following output: > > > pcm0: port 0x1400-0x14ff irq 10 at device 8.0 on pci0 > pcm0: > pcm0: [GIANT-LOCKED] > pcm0: offset 0xfffa1000 exceeds limit. pcm0: chn_init(pcm0:play:0) failed: err = 19 > pcm0: pcm_chn_create(aggch, 1, 0xc223e700) failed > pcm0: offset 0xfffa1000 exceeds limit. pcm0: chn_init(pcm0:play:0) failed: err = 19 > pcm0: pcm_chn_create(aggch, 1, 0xc223e700) failed > pcm0: offset 0xfffa1000 exceeds limit. pcm0: chn_init(pcm0:play:0) failed: err = 19 > pcm0: pcm_chn_create(aggch, 1, 0xc223e700) failed > pcm0: offset 0xfffa1000 exceeds limit. pcm0: chn_init(pcm0:play:0) failed: err = 19 > pcm0: pcm_chn_create(aggch, 1, 0xc223e700) failed It sure looks to me like physaddr is getting set to zero in aggch_init(). It also looks like the device_printf() format string is missing a newline. Try adding a device_printf() to aggch_init() to print out both physaddr and ess->baseaddr so that we can figure out where the calculation ch->offset = physaddr - ess->baseaddr; is going wrong. The source file is /usr/src/sys/dev/sound/pci/maestro.c From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 22:58:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7799B16A4CE for ; Thu, 12 Aug 2004 22:58:31 +0000 (GMT) Received: from ddardaar.mine.nu (bww254.neoplus.adsl.tpnet.pl [83.29.246.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id F366B43D53 for ; Thu, 12 Aug 2004 22:58:30 +0000 (GMT) (envelope-from radek@raadradd.com) Received: by ddardaar.mine.nu (Postfix, from userid 1001) id D088FA51A; Fri, 13 Aug 2004 00:58:38 +0200 (CEST) Date: Fri, 13 Aug 2004 00:58:38 +0200 From: Radek Kozlowski To: Nate Lawson Message-ID: <20040812225838.GB10869@werd> References: <4113EB2A.7060401@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <4113EB2A.7060401@root.org> User-Agent: Mutt/1.5.6i cc: current@freebsd.org Subject: Re: Panic on boot with today's CURRENT, ata related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 22:58:31 -0000 On Fri, Aug 06, 2004 at 01:33:46PM -0700, Nate Lawson wrote: > I took a quick look at this ATA panic. The exact same one occurs for > Ceri. A quick dissassemble shows that the testb is the check for the > DMA flag at the very end of ata_generic_transaction(). The bug appears > to be that this may be a PIO request (since the DMA check is outside the > switch() statement). The fix is to make sure it's a DMA request before > dereferencing an element of the DMA struct. Try the attached patch. Another panic on boot with fresh -CURRENT, however this time ad0 is in UDMA100 mode: ad0: 38154MB [77520/16/63] at ata0-master UDMA100 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8 :0xc0544896 stack pointer = 0x10 :0xd302db70 frame pointer = 0x10 :0xd302db70 code segment = base 0x0, limit 0xffffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 4 (g_down) [thread 100033] Stopped at rman_get_bustag+0x6: movl 0x24(%eax),%eax db> trace rman_get_bustag(0,d302db84,0,c1a33000,c8000000) at rman_get_bustag+0x6 ata_pci_dmastart(c1854200,c8,0,0,1) at ata_pci_dmastart+0x17 ata_generic_transaction(c1b3ea8c,c1b3ea8c,1f4,c0537399,0) at ata_generic_transaction+0x2e3 ata_start(c1854200,0,c1b3ea8c,c1854200,c1b42dec) at ata_start+0x279 ata_queue_request(c1b3ea8c,0,101,0,d302dc44,d302dc58,0,0,0,efd88083,2be897c,c1b42dec,c1aadd80) at ata_queue_request+0x1fc ad_start(c18542a8,c053e221,c1aaddc8,c1b42dec,c1aadd80) at ad_start+0x398 ata_start(c1854200,c1b42dec,0,0,c1b42dec) at ata_start+0xc8 adstrategy(c1b42dec,0,200,0,200) at adstrategy+0xce g_disk_start(c1b42e70,c0736028,24c,c06deea3,a) at g_disk_start+0x1b6 g_io_schedule_down(c188f000,c189e534,d302dd34,c0508650,0) at g_io_schedule_down+0x150 g_down_procbody(0,d302dd48,0,0,0) at g_down_procbody+0x1e fork_exit(c04e4f80,0,d302dd48) at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd302dd7c, ebp = 0 --- -Radek From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 23:07:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7430316A4CE; Thu, 12 Aug 2004 23:07:00 +0000 (GMT) Received: from lakermmtao09.cox.net (lakermmtao09.cox.net [68.230.240.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8BB443D1D; Thu, 12 Aug 2004 23:06:59 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.71.51]) by lakermmtao09.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040812230657.ITA16139.lakermmtao09.cox.net@dolphin.local.net>; Thu, 12 Aug 2004 19:06:57 -0400 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with ESMTP id i7CN6wOd010189; Thu, 12 Aug 2004 18:06:58 -0500 (CDT) (envelope-from conrads@dolphin.local.net) Received: (from conrads@localhost) by dolphin.local.net (8.13.1/8.13.1/Submit) id i7CN6rEf010188; Thu, 12 Aug 2004 18:06:53 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20040812201138.GA79664@ip.net.ua> Date: Thu, 12 Aug 2004 18:06:53 -0500 (CDT) Organization: A Rag-Tag Band of Drug-Crazed Hippies From: "Conrad J. Sabatier" To: Ruslan Ermilov cc: freebsd-current@freebsd.org Subject: Re: builworld fails if debugging enabled in usr.sbin/pkg_install/lib X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conrads@cox.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2004 23:07:00 -0000 On 12-Aug-2004 Ruslan Ermilov wrote: > On Thu, Aug 12, 2004 at 02:58:23PM -0500, Conrad J. Sabatier wrote: >> >> I have the following in /etc/make.conf: >> >> .if defined(DEBUG) >> CFLAGS+=-g >> .endif >> >> And then use "make -DDEBUG buildworld". >> > I suspected something like this. > src/usr.sbin/pkg_install/*/Makefile's added the contents of the > DEBUG variable to CFLAGS. By passing the -DDEBUG to make(1), you > effectively set the value of the DEBUG variable to 1 (see the make(1) > manpage), so "1" was added to CFLAGS. > > I've "fixed" these makefiles to not add DEBUG to CFLAGS. Note that > the name DEBUG is unsafe to use anyway. Also, there's an > alternative and standard way to recompile your programs and libraries > with -g: there's the DEBUG_FLAGS variable, so you could as well do it > like this: > > make buildworld DEBUG_FLAGS=-g > > Passing DEBUG_FLAGS=-g to ``make installworld'' will also cause the > binaries to *not* be stripped when installing, which is essential > for having the debugger symbols in binaries. Please consider > switching to this method of building world with debug infomation. Ah, great! I never knew about this before. Thanks! -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 23:07:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 540E316A4CE for ; Thu, 12 Aug 2004 23:07:33 +0000 (GMT) Received: from ddardaar.mine.nu (bww254.neoplus.adsl.tpnet.pl [83.29.246.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02F7143D2D for ; Thu, 12 Aug 2004 23:07:33 +0000 (GMT) (envelope-from radek@raadradd.com) Received: by ddardaar.mine.nu (Postfix, from userid 1001) id 8542AA51A; Fri, 13 Aug 2004 01:07:41 +0200 (CEST) Date: Fri, 13 Aug 2004 01:07:41 +0200 From: Radek Kozlowski To: Greg 'groggy' Lehey Message-ID: <20040812230741.GC10869@werd> References: <20040812215859.GM19643@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <20040812215859.GM19643@wantadilla.lemis.com> User-Agent: Mutt/1.5.6i cc: FreeBSD current users Subject: Re: Current method of dumping a processor? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 23:07:33 -0000 On Fri, Aug 13, 2004 at 07:28:59AM +0930, Greg 'groggy' Lehey wrote: > I've tried it on kernels built in January, May and yesterday. In each > case, I did: > > dumpon /dev/ad0s2b > > (for appropriate values of ad0s2b). All kernels include ddb. I > entered the debugger with ctrl-alt-esc and entered "panic". The > kernel from January dumps just fine. The kernels from May and August > hang. > > Am I doing something wrong? Has something else changed? Does anybody > else have this problem? I also had this problem back in June when I was trying to get a crash dump, but nobody replied (see http://lists.freebsd.org/pipermail/freebsd-current/2004-June/029434.html). I then learnt that I can use call doadump in ddb and have been using that since then. -Radek From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 23:23:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CF8B16A4CF for ; Thu, 12 Aug 2004 23:23:35 +0000 (GMT) Received: from out001.email.savvis.net (out001.apptix.savvis.net [216.91.32.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0DFA43D45 for ; Thu, 12 Aug 2004 23:23:34 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from s228130hz1ew03.apptix-01.savvis.net ([10.146.4.28]) by out001.email.savvis.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Aug 2004 18:23:35 -0500 Received: from savvis.net ([66.35.239.94]) by s228130hz1ew03.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Aug 2004 18:23:35 -0500 Message-ID: <411BFBF1.9000905@savvis.net> Date: Thu, 12 Aug 2004 16:23:29 -0700 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031207 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Aug 2004 23:23:35.0590 (UTC) FILETIME=[63E13C60:01C480C3] Subject: [RFC] virtual AT keyboard driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 23:23:35 -0000 Dear Hackers, i finally found some time and cleaned up some code i want to use in for bluetooth hid. i need an expert opinion on the following problem. basically i would like to be able to use things like wireless (bluetooth in particular) keyboard and mouse. in this case a piece of software (bluetooth hid daemon) runs on the host and talks to the wireless hid devices (keyboard, mouse etc.) the daemon receives the input from the device and passes it to the host. in the mouse case the input is cursor movements and button events. currently i'm using syscons(4) (ioctl(2) on /dev/consolectl) to feed mouse events to the host. in the keyboard case the input is usb hid reports that i can translate into AT scan codes. the problem is that i could not find the way to feed these scan codes to the host. so i wrote a little driver that pretends to be an AT keyboard, but takes its input (i.e. scan codes) from the user instead of hardware. so if there anything wrong with this approach? is there any better solution? there is still an issue with console being able to accept input from only from one keyboard. and because of this it is not possible to use wired keyboard with wireless keypads (or vice versa). another usage for this might be in a headless (or rather keyboard-less) system. please let me know what do you think. the driver source is at http://www.geocities.com/m_evmenkin/vkbd.tar.gz (~10K) if you cannot get it, please email me and i will send you a copy. thanks, max From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 23:31:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F9C616A4CE for ; Thu, 12 Aug 2004 23:31:21 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C523443D1D for ; Thu, 12 Aug 2004 23:31:20 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7CNTeck067243; Thu, 12 Aug 2004 19:29:41 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7CNTe3E067240; Thu, 12 Aug 2004 19:29:40 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 12 Aug 2004 19:29:40 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Martin Blapp In-Reply-To: <20040812174229.G31181@cvs.imp.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 23:31:21 -0000 On Thu, 12 Aug 2004, Martin Blapp wrote: > Here is more information: (thanks robert for the help) > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 1; apic id = 01 > > fault virtual address = 0x14 > > fault code = supervisor write, page not present > > instruction pointer = 0x8:0xc066a1c7 > > stack pointer = 0x10:0xe2626aa8 > > frame pointer = 0x10:0xe2626ab8 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 27897 (mimedefang) > > Ok, indeed, this appears to be an unaddressed class of race conditions in the UNIX domain socket code. I'm currently working through it, both to address in the mpsafe case and non-mpsafe case (the one you were running in). I will run some tests on it tonight and try to get you patches to try tomorrow. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research > > db> where > unp_connect2(c4bb78a4,c39cc13c,0,0,0) at /usr/src/sys/kern/uipc_usrreq.c:892 > unp_connect(c4bb78a4,c43d9380,c4dee9a0,c43d9380,80) at /usr/src/sys/kern/uipc_usrreq.c:865 > uipc_connect(c4bb78a4,c43d9380,c4dee9a0) at /usr/src/sys/kern/uipc_usrreq.c:179 > soconnect(c4bb78a4,c43d9380,c4dee9a0,0,bf1dad88) at /usr/src/sys/kern/uipc_socket.c:518 > kern_connect(c4dee9a0,3,c43d9380,c43d9380,c3e958ac) at /usr/src/sys/kern/uipc_syscalls.c:477 > connect(c4dee9a0,e2626d14,c,c4dee9a0,e2626d3c) at connect+0x42 > syscall(2f,2f,2f,bf1dad88,bf1dad8a) at syscall+0x300 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (98, FreeBSD ELF32, connect), eip = 0x28101d23, esp = 0xbf1dad74, ebp = 0xbf1dae10 --- > > src/sys/kern/uipc_syscalls.c,v 1.199 > src/sys/kern/uipc_usrreq.c,v 1.135 > src/sys/kern/uipc_socket.c,v 1.207 > > (gdb) l *unp_connect2+0x2a > 0x1f93 is in unp_connect2 (/usr/src/sys/kern/uipc_usrreq.c:892). > 887 UNP_LOCK_ASSERT(); > 888 > 889 if (so2->so_type != so->so_type) > 890 return (EPROTOTYPE); > 891 unp2 = sotounpcb(so2); > 892 unp->unp_conn = unp2; > 893 switch (so->so_type) { > 894 > 895 case SOCK_DGRAM: > 896 LIST_INSERT_HEAD(&unp2->unp_refs, unp, unp_reflink); > > (gdb) l *unp_connect+0x3d5 > 0x1e24 is in unp_connect (/usr/src/sys/kern/uipc_usrreq.c:865). > 860 SOCK_UNLOCK(so); > 861 #endif > 862 > 863 so2 = so3; > 864 } > 865 error = unp_connect2(so, so2); > 866 bad2: > 867 UNP_UNLOCK(); > 868 mtx_lock(&Giant); > 869 bad: > > (gdb) l *uipc_connect+0x76 > 0x2dd is in uipc_connect (/usr/src/sys/kern/uipc_usrreq.c:179). > 174 KASSERT(td == curthread, ("uipc_connect: td != curthread")); > 175 > 176 if (unp == NULL) > 177 return (EINVAL); > 178 UNP_LOCK(); > 179 error = unp_connect(so, nam, td); > 180 UNP_UNLOCK(); > 181 return (error); > 182 } > 183 > > (gdb) l *soconnect+0x54 > 0x100f is in soconnect (/usr/src/sys/kern/uipc_socket.c:518). > 513 (error = sodisconnect(so)))) > 514 error = EISCONN; > 515 else > 516 error = (*so->so_proto->pr_usrreqs->pru_connect)(so, nam, td); > 517 return (error); > 518 } > 519 > 520 int > 521 soconnect2(so1, so2) > 522 struct socket *so1; > > (gdb) l *kern_connect+0xb > 0xd5e is in kern_connect (/usr/src/sys/kern/uipc_syscalls.c:477). > 472 int > 473 kern_connect(td, fd, sa) > 474 struct thread *td; > 475 int fd; > 476 struct sockaddr *sa; > 477 { > 478 struct socket *so; > 479 int error, s; > 480 int interrupted = 0; > 481 > From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 23:48:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A96E516A502; Thu, 12 Aug 2004 23:48:31 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E65143D49; Thu, 12 Aug 2004 23:48:31 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-67-115-74-195.dsl.lsan03.pacbell.net [67.115.74.195]) i7CNmXnA011110; Thu, 12 Aug 2004 19:48:33 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8EC8D5126B; Thu, 12 Aug 2004 16:48:29 -0700 (PDT) Date: Thu, 12 Aug 2004 16:48:29 -0700 From: Kris Kennaway To: "David O'Brien" , Kris Kennaway , current@FreeBSD.org Message-ID: <20040812234829.GA76459@xor.obsecurity.org> References: <20040811224504.GA46960@xor.obsecurity.org> <20040812091148.GB57570@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <20040812091148.GB57570@dragon.nuxi.com> User-Agent: Mutt/1.4.2.1i Subject: Re: gcc 3.4.2/x.org packages uploaded X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 12 Aug 2004 23:48:31 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 12, 2004 at 02:11:48AM -0700, David O'Brien wrote: > On Wed, Aug 11, 2004 at 03:45:04PM -0700, Kris Kennaway wrote: > > I've uploaded a full package set built with gcc 3.4.2 and x.org, >=20 > Thanks! >=20 > Any timeline on updated AMD64 64-bit packages? They're now uploaded to ftp-master, although a bug in fetch is preventing hundreds of them from building so it's somewhat incomplete. Kris --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBHAHNWry0BWjoQKURAgdPAKDBtpQs6fn4/6qSW1fZflSfxdPV3wCfWwfc wS5BIcIPtN8x/V9om0SrUKc= =mdWz -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 13 00:02:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EBF416A4CE; Fri, 13 Aug 2004 00:02:36 +0000 (GMT) Received: from basalt.tackymt.homeip.net (YahooBB219181148048.bbtec.net [219.181.148.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id B964643D46; Fri, 13 Aug 2004 00:02:35 +0000 (GMT) (envelope-from taku@tackymt.homeip.net) Received: from localhost (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 89B981075F; Fri, 13 Aug 2004 09:02:34 +0900 (JST) Received: from maestro.tackymt.homeip.net (maestro.tackymt.homeip.net [IPv6:2001:3e0:577:0:240:26ff:fe49:1c9d]) by basalt.tackymt.homeip.net (Postfix) with ESMTP; Fri, 13 Aug 2004 09:02:33 +0900 (JST) Date: Fri, 13 Aug 2004 09:02:31 +0900 From: Taku YAMAMOTO To: Don Lewis Message-Id: <20040813090231.3c6acb13.taku@tackymt.homeip.net> In-Reply-To: <200408122253.i7CMrseZ021586@gw.catspoiler.org> References: <20040812221348.GA1337@gargantuan.com> <200408122253.i7CMrseZ021586@gw.catspoiler.org> X-Mailer: Sylpheed version 0.9.12-gtk2-20040622 (GTK+ 2.2.4; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-current@gargantuan.com cc: freebsd-current@FreeBSD.org Subject: Re: pcm_chn_create failed with 2004-08-12 kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Aug 2004 00:02:36 -0000 On Thu, 12 Aug 2004 15:53:54 -0700 (PDT) Don Lewis wrote: > On 12 Aug, Michael W. Oliver wrote: > > Ok, this world was cvsup'd on 2004.08.12 at 09:59:03 EDT. I removed the > > 'sound' and 'snd_maestro' device lines from my kernel config and decided > > to load them as modules (after I got the same output shown below with > > sound and snd_maestro compiled into the kernel). When I kldload > > 'sound', I get no output. After that, when I kldload 'snd_maestro', I > > get the following output: > > > > > > pcm0: port 0x1400-0x14ff irq 10 at device 8.0 on pci0 > > pcm0: > > pcm0: [GIANT-LOCKED] > > pcm0: offset 0xfffa1000 exceeds limit. pcm0: chn_init(pcm0:play:0) failed: err = 19 > > pcm0: pcm_chn_create(aggch, 1, 0xc223e700) failed > > pcm0: offset 0xfffa1000 exceeds limit. pcm0: chn_init(pcm0:play:0) failed: err = 19 > > pcm0: pcm_chn_create(aggch, 1, 0xc223e700) failed > > pcm0: offset 0xfffa1000 exceeds limit. pcm0: chn_init(pcm0:play:0) failed: err = 19 > > pcm0: pcm_chn_create(aggch, 1, 0xc223e700) failed > > pcm0: offset 0xfffa1000 exceeds limit. pcm0: chn_init(pcm0:play:0) failed: err = 19 > > pcm0: pcm_chn_create(aggch, 1, 0xc223e700) failed > > It sure looks to me like physaddr is getting set to zero in > aggch_init(). It also looks like the device_printf() format string is > missing a newline. > > Try adding a device_printf() to aggch_init() to print out both physaddr > and ess->baseaddr so that we can figure out where the calculation > ch->offset = physaddr - ess->baseaddr; > is going wrong. The source file is /usr/src/sys/dev/sound/pci/maestro.c This is caused by physaddr which is smaller than ess->baseaddr. It will often occur when memory is fragmented, I think. Michael, would you try the newer driver? http://www.tackymt.homeip.net/~taku/maestro-latest/ -- -|-__ YAMAMOTO, Taku | __ < Post Scriptum to the people who know me as taku@cent.saitama-u.ac.jp: My email address has been changed since April, because I've left the university. From owner-freebsd-current@FreeBSD.ORG Fri Aug 13 01:06:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A18416A4CE for ; Fri, 13 Aug 2004 01:06:26 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5773443D39 for ; Fri, 13 Aug 2004 01:06:23 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id i7D168BP056254; Fri, 13 Aug 2004 10:36:10 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Fri, 13 Aug 2004 10:36:07 +0930 User-Agent: KMail/1.6.2 References: <20040812185242.GA53082@pcwin002.win.tue.nl> In-Reply-To: <20040812185242.GA53082@pcwin002.win.tue.nl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200408131036.07828.doconnor@gsoft.com.au> X-Spam-Score: -4.9 () CARRIAGE_RETURNS,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Justin Hibbits Subject: Re: Preliminary ATI TV Wonder bktr support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Aug 2004 01:06:26 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 13 Aug 2004 04:22, Stijn Hoop wrote: > > Anyway, maybe someone can figure out how to go from here, since I'm > > stuck now. I'll continue working on it though. > > FWIW, I recall that most of the open source BT878 drivers don't do intern= al > sound, and instead rely on you to feed the audio channel into your > soundcard. At least, that's what works for me with a no-name TV tuner car= d; > it even included a male-male minijack cable to do so. So if that's all > that's missing, you might be as far along as anyone has ever been. There's a Linux driver for the 878 sound blob. http://lxr.linux.no/source/drivers/sound/btaudio.c The 878 datasheet is publically available too http://www.conexant.com/servlets/DownloadServlet/100172c.pdf?FileId=3D543 http://www.conexant.com/servlets/DownloadServlet/100600B.pdf?FileId=3D443 Basically the device is divided into 2 logical parts. Function 0 is the vid= eo=20 side, and function 1 is the audio. I believe you should be able to attach to each part independently, although= =20 maybe it would make sense to make bktr all in one. =2D --=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 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBHBP/5ZPcIHs/zowRApPkAJ9BKlxw2/R9oiSsclPaNTsLQFLSrACfaK33 8RzHA3x87OxhtEZLW9OTO8w=3D =3Dl3is =2D----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Aug 13 01:12:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FCB116A4CE for ; Fri, 13 Aug 2004 01:12:52 +0000 (GMT) Received: from hotmail.com (bay8-f27.bay8.hotmail.com [64.4.27.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFEF943D1D for ; Fri, 13 Aug 2004 01:12:51 +0000 (GMT) (envelope-from evantd@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 12 Aug 2004 18:12:51 -0700 Received: from 67.171.32.75 by by8fd.bay8.hotmail.msn.com with HTTP; Fri, 13 Aug 2004 01:12:51 GMT X-Originating-IP: [67.171.32.75] X-Originating-Email: [evantd@hotmail.com] X-Sender: evantd@hotmail.com From: "Evan Dower" To: db@nipsi.de Date: Thu, 12 Aug 2004 18:12:51 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Aug 2004 01:12:51.0833 (UTC) FILETIME=[A7B48690:01C480D2] cc: freebsd-current@freebsd.org Subject: Re: Project Evil: TI ACX111 non-success X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Aug 2004 01:12:52 -0000 I'm happy to work on this, but I start from zero code familiarity, and I've received no response from Bill Paul. I assume he's probably busy with Real Life. I've never messed with the kernel this deeply (though I have added a syscall to linux, and done a few other ugrad OS course-related exercises). If someone could point me toward some good starting documentation for this endeavor (an overview of what the ndis code is doing would be very helpful), I would really appreciate it. I can work on it in my free time and submit patches. Sadly I have only one computer (which I use daily), which might make debugging difficult. Anyway, I'll give you all a patch if somebody gives me a few pointers. Thanks very much, -- Evan Dower Undergraduate, Computer Science University of Washington Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D >From: Dennis Berger >To: Evan Dower >CC: db@nipsi.de, freebsd-current@freebsd.org >Subject: Re: Project Evil: TI ACX111 non-success >Date: Thu, 12 Aug 2004 20:23:01 +0200 > >I guess I tried everything possible... >acx driver failed cause it's simply not supported "acx111". >ndis driver failed also with 3 different firmware types... > >-------------- >cardbus1: Expecting link target, got 0xcb >cardbus1: Resource not specified in CIS: id=10, size=2000 >cardbus1: Resource not specified in CIS: id=14, size=20000 >ndis0: mem >0x88000000-0x8 >801ffff,0x88020000-0x88021fff irq 11 at device 0.0 on cardbus1 >ndis0: [GIANT-LOCKED] >ndis0: NDIS API version: 5.1 >ndis0: init handler failed >device_attach: ndis0 attach returned 6 >cardbus1: release_all_resource: Resource still owned by child, oops. >(type=3, ri >d=20, addr=88000000) >cbb1: CardBus card activation failed >------------- > >best regards, >-Dennis > >On Thu, Aug 12, 2004 at 10:00:58AM -0700, Evan Dower wrote: > > With ndis do you get the same "init handler failed" error message? Have >you > > emailed Bill Paul with all the appropriate info? What have you tried? >What > > were the results? > > > > -- > > Evan Dower > > Undergraduate, Computer Science > > University of Washington > > Public key: http://students.washington.edu/evantd/pgp-pub-key.txt > > Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D > > > > > > > > > > > > >From: Dennis Berger > > >To: Evan Dower > > >CC: freebsd-current@freebsd.org > > >Subject: Re: Project Evil: TI ACX111 non-success > > >Date: Thu, 12 Aug 2004 09:56:15 +0200 > > > > > >I have the dlink g650+ which also has the acx111 chipset... > > >NDIS failed acx driver failed also. > > >regards, > > >-Dennis > > > > > >On Wed, Aug 11, 2004 at 04:40:58PM -0700, Evan Dower wrote: > > >> I've been trying to get the ndisulator to work for my NetGear WG311v2 >so > > >I > > >> can take the ethernet cables and switches offthe floor in my hall. >The > > >> following is the "conversation" I've had with Bill Paul. It is >perhaps > > >best > > >> to read from the bottom up to get the chronology right. Also, as it > > >turns > > >> out the net/acx100 port makes no claim to support the acx111, and I >was > > >> eventually able to build and load it, though of course it didn't work > > >> because it doesn't support the acx111. Any help would be greatly > > >> appreciated. > > >> > > >> -- > > >> > > >> I managed to get rid of the "can't re-use a leaf" messaged by >deleting > > >> the duplicate entry in ndis_driver_data.h. For some reason, whenever >I > > >> try to load if_ndis.ko (ndis.ko is already loaded), I get messages >about > > >> amdpm. Perhaps ndis returning 6 and failing to load is a result of >the > > >> same return value from trying to attach amdpm. > > >> > > >> amdpm0: port > > >> 0xe4e0-0xe4ff at device 7.3 on pci0 > > >> amdpm0: could not map i/o space > > >> device_attach: amdpm0 attach returned 6 > > >> ndis0: mem > > >> 0xf0800000-0xf081ffff,0xf1000000-0xf1001fff irq 17 at device 6.0 on >pci2 > > >> ndis0: [GIANT-LOCKED] > > >> no match for srand > > >> ndis0: NDIS API version: 5.1 > > >> ndis0: init handler failed > > >> device_attach: ndis0 attach returned 6 > > >> > > >> Thanks again, > > >> Evan Dower > > >> > > >> El mar, 20-07-2004 a las 10:58, Evan Dower escribi?: > > >> >I have figured out that the "can't re-use a leaf" message is coming > > >from > > >> >trying to register a sysctl, which comes from the .inf file. This >seems > > >> >to indicate some limitations on the complexity of .inf files that >can > > >be > > >> >properly parsed and turned into a list of sysctls. Since I'm not > > >exactly > > >> >sure what those limitations are, I'm sending you a link to the .inf > > >file > > >> >(and the .sys file for good measure)? Other than that, it looks like > > >> >srand might just need to be plugged into one of the function tables > > >> >(probably the hal table, I guess). Also, if you can tell me what > > >> >limitations exist for the .inf file, I will gladly modify it to work > > >and > > >> >make it available to other WG311v2 owners. > > >> >Thanks again, > > >> >Evan Dower > > >> >Note: Much of the .inf file (anything not for XP) is commented out >in > > >an > > >> >attempt to make things work. This was my doing. It didn't ship that > > >way. > > >> >Since I don't really understand the Windows registry, I didn't get >too > > >> >adventurous. > > >> > > > >> >Files at: http://students.washington.edu/evantd/pub/evil/ > > >> > > > >> >El lun, 12-07-2004 a las 16:05, Evan Dower escribi?: > > >> >> I have a Netgear WG311v2. The v2 turns out to be very important as > > >the > > >> >> original (v1 you might call it now) was based on an Atheros AR5212 > > >and > > >> >> was thus supported by the ath driver. v2 is based on the the TI > > >AXC111 > > >> >> (aka TNETW1130), which should be supported by the net/acx100 port, > > >but > > >> >> if_acx.ko fails to load due to a missing __panic symbol. Following > > >the > > >> >> instructions you posted in an email, I made ndis_driver_data.h and > > >> >> built and loaded the if_ndis.ko module (after loading ndis.ko or > > >> >> compiling it into the kernel). I used the Windows XP .SYS and .INF > > >> >> files, though the Windows 2000 versions gave the same result, the > > >> >> Windows 98 files produced a module that panicked on load, and I > > >didn't > > >> >> try the Windows ME files. The following is the output from `make > > >> >> load`. > > >> >> > /sbin/kldload -v /usr/current/src/sys/modules/if_ndis/if_ndis.ko > > >> >> ndis0: mem > > >> >> 0xec800000-0xec81ffff, > > >> >> 0xed000000-0xed001fff irq 17 at device 6.0 on pci2 > > >> >> ndis0: [GIANT-LOCKED] > > >> >> can't re-use a leaf (dot11DesiredBSSType)! > > >> >> no match for srand > > >> >> ndis0: NDIS API version: 5.1 > > >> >> ndis0: init handler failed > > >> >> device_attach: ndis0 attach returned 6 > > >> >> Loaded /usr/current/src/sys/modules/if_ndis/if_ndis.ko, id=11 > > >> >> > Loading the module does not create /dev/ndis0 or /dev/if_ndis0 >(or > > >> >> anything of the sort). I am running today's -CURRENT. > > >> >> > It seems that it requires srand, and I assume the 'can't re-use >a > > >leaf > > >> >> (dot11DesiredBSSType)!' is also a show-stopper. I ordered my card > > >from > > >> >> newegg.com for about $50. > > >> >> > If there is anything else you might be interested in (a verbose > > >boot > > >> >> log, copies of the .SYS and .INF files, testing for patches, >etc.), > > >> >> just let me know. I'd be happy to help (especially since the >result > > >is > > >> >> a working wireless connection). > > >> >> > Thanks very much, > > >> > > >> -- > > >> Evan Dower > > >> Undergraduate, Computer Science > > >> University of Washington > > >> Public key: http://students.washington.edu/evantd/pgp-pub-key.txt > > >> Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D > > >> > > >> _________________________________________________________________ > > >> Don?t just search. Find. Check out the new MSN Search! > > >> http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > >> > > >> _______________________________________________ > > >> 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" > > > > _________________________________________________________________ > > On the road to retirement? Check out MSN Life Events for advice on how >to > > get there! http://lifeevents.msn.com/category.aspx?cid=Retirement > > _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From owner-freebsd-current@FreeBSD.ORG Fri Aug 13 01:27:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF1CA16A4CE for ; Fri, 13 Aug 2004 01:27:27 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4C3943D5A for ; Fri, 13 Aug 2004 01:27:27 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id D2A5772DD4; Thu, 12 Aug 2004 18:27:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id CD0CA72DCB; Thu, 12 Aug 2004 18:27:27 -0700 (PDT) Date: Thu, 12 Aug 2004 18:27:27 -0700 (PDT) From: Doug White To: Oleg Palij In-Reply-To: <20040811120642.503650b8@iscmpd-oleg.dp.uz.gov.ua> Message-ID: <20040812182149.T86599@carver.gumbysoft.com> References: <07759232F85A5C7FC2256EED0022A18A.00281F3542256EED@dp.uz.gov.ua> <20040811120642.503650b8@iscmpd-oleg.dp.uz.gov.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: panic with any version of smbd in 5.2.1-R X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Aug 2004 01:27:28 -0000 On Wed, 11 Aug 2004, Oleg Palij wrote: > > Panic happens with samba 2.2.8-2.2.10, 3.0.0-3.0.4. > > I can't reproduce kernel panic but it happens frequently. > > > > # uname -a > > FreeBSD iscmpd-oleg 5.2.1-RELEASE-p9 FreeBSD 5.2.1-RELEASE-p9 #0: Wed Aug 4 > > 11:59:15 EEST 2004 root@iscmpd-oleg:/usr/obj/usr/src/sys/ISCMPD-OLEG_KERNEL > > i386 Oh, this is the quota-op-on-non-qutoa-fs bug. I came across this in march, and I think a fix was committed to -current not too soon after. I can't find the relevant files right now, however; it wasn't committed to the obvious places in the msdosfs code.... I'll try to test tomorrow. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Aug 13 01:39:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5607216A4CE for ; Fri, 13 Aug 2004 01:39:03 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2316343D2D for ; Fri, 13 Aug 2004 01:39:03 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 1830A72DD4; Thu, 12 Aug 2004 18:39:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 1329E72DCB; Thu, 12 Aug 2004 18:39:03 -0700 (PDT) Date: Thu, 12 Aug 2004 18:39:03 -0700 (PDT) From: Doug White To: Michael Nottebrock In-Reply-To: <200408120429.30081.michaelnottebrock@gmx.net> Message-ID: <20040812183418.D86599@carver.gumbysoft.com> References: <200408120429.30081.michaelnottebrock@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@FreeBSD.org cc: rnejdl@ringofsaturn.com cc: Trent Nelson Subject: Re: Signal 11 compiling qt33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Aug 2004 01:39:03 -0000 On Thu, 12 Aug 2004, Michael Nottebrock wrote: > Maybe. Maybe there are some software related factors there, too (qt isn't > generally more sensitive to typical scenarios of ports-based installations > being inconsistent in a way that makes stuff break - like the mixed threads > libraries example. The difference is, qt very often just fails in a rather > undescriptive way, and as it seems, way more often in some places than others > (uic)). uic and dcopidl crashes are indicative of crossed thread libraries. I know, I went through the same problem :) If you ldd them you'll see libc_r and libpthread both getting pulled in, which is fatal. Both uic and dcopidl pull in libqt, which will usually be the lagggard since its using options saved by qmake, and doesn't get updated frequently enough for it to get rebuilt during a kde/qt upgrade. You want to rebuild stuff in this order: 1. XFree86-libraries (or the xorg equivalent) 2. qmake (everyone forgets this -- qt uses it to get compile and link options, including the thread library!) 3. qt33 4. qt dependencies (kde, etc.) It took me a week to get this straightened out on my dual 600 current builder. Really understood the problem and solutions afterward through :) You can use the libmap hack, but that will only bite you in some hidden way later when the libraries change again. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Aug 13 01:49:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A200316A4CE; Fri, 13 Aug 2004 01:49:40 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9535943D45; Fri, 13 Aug 2004 01:49:40 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 8E23C72DD8; Thu, 12 Aug 2004 18:49:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 89A5972DD5; Thu, 12 Aug 2004 18:49:40 -0700 (PDT) Date: Thu, 12 Aug 2004 18:49:40 -0700 (PDT) From: Doug White To: John Polstra In-Reply-To: Message-ID: <20040812184818.I86599@carver.gumbysoft.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: cvsup on amd64 just broke today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Aug 2004 01:49:40 -0000 On Thu, 12 Aug 2004, John Polstra wrote: > > Interestingly, jdp just touched that port. I guess he doesn't have peter's > > patches, or hasn't adapted them for the distro yet. > > There is a lot of brokenness in those patches, as Peter will be > the first to admit. They're really not ready to be committed at > this point. David O'Brien has done a lot of work on this, but > there's still nothing ready to commit. Yeah, ISTR it being a massive hack at the time. :) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Aug 13 01:54:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 755E416A4CE; Fri, 13 Aug 2004 01:54:16 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66FB843D39; Fri, 13 Aug 2004 01:54:16 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 59E6C72DD8; Thu, 12 Aug 2004 18:54:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 53DD572DD5; Thu, 12 Aug 2004 18:54:16 -0700 (PDT) Date: Thu, 12 Aug 2004 18:54:16 -0700 (PDT) From: Doug White To: Terrence Koeman In-Reply-To: <20040812000885.SM01804@manrikigusari> Message-ID: <20040812185013.T86599@carver.gumbysoft.com> References: <20040812000885.SM01804@manrikigusari> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@FreeBSD.org cc: 'John Baldwin' Subject: RE: Lock order reversal in 5.2-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Aug 2004 01:54:16 -0000 On Thu, 12 Aug 2004, Terrence Koeman wrote: > I thought so too, because multiple weird errors usually point to the hardware. > > But I have three identical systems with the only difference being the contents > of the disks. The other two systems are running 4.10-STABLE with heavy load > without any problems. I swapped the disks (only the disks) with a working > system twice now and it locks up just the same. Lets see... whats the common factor there? :-) If the problem follows the disks... A whole group of machines having problems is not unheard of. Sometimes theres bad chip revs. We have a big stack of Opterons at work that hang on heavy network I/O while virtually identical boxes bought earlier in the year work fine with the same software. We're hashing it out with the vendor right now. > I think the chance of three systems having the same hardware problem is > really small, especially because 4.10-STABLE hasn't had a single problem > on those systems in the couple of months they run. > > Maybe 5.2-CURRENT has a specific problem with the hardware in the > systems? But it's not like it is exotic hardware, they are SuperMicro 1U > barebones with a Celeron 2600, 512MB of RAM and a FastTrak TX2000. I'm not saying it isn't a but, particularly where -current is concerned, but I don't think you've proved its _not_ hardware. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Aug 13 02:23:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 369CB16A4CE for ; Fri, 13 Aug 2004 02:23:23 +0000 (GMT) Received: from bronco.gopix.net (gopix.net [38.118.153.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1599243D41 for ; Fri, 13 Aug 2004 02:23:23 +0000 (GMT) (envelope-from jhamby@anobject.com) Received: from [192.168.0.13] (ca-stmnca-cuda2-blade8b-87.stmnca.adelphia.net [68.65.226.87]) (authenticated bits=0) by bronco.gopix.net (8.12.11/8.12.11) with ESMTP id i7D2NGfS014738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2004 19:23:19 -0700 Message-ID: <411C2613.9040604@anobject.com> Date: Thu, 12 Aug 2004 19:23:15 -0700 From: Jake Hamby User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040810) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org, sam@errno.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: updated ath driver: please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Aug 2004 02:23:23 -0000 Hi all, I've just finished putting together a version of the ath driver based on a merge of the current FreeBSD version with the latest Linux madwifi driver and HAL version 0.9.11.6. I included all of the features except for those not currently supported by FreeBSD's version of net80211 (e.g. only WEP crypto is supported). Please test it out. It may be too late to get this checked in before the code freeze, but I think it's our best bet to have a version of the ath driver with a recent HAL but without disturbing the shared net80211 code. Download it here: http://anobject.com/jehamby/atheros_driver.tar.bz2 Extract into /usr/src. The two machines I've tested it on are a Fujitsu Lifebook N5010 w/ builtin Atheros a/b/g, and a Vaio desktop with D-Link DWL-G520 (H/W Ver: B2). dmesg output from the Fujitsu is: ath0: mem 0xec010000-0xec01ffff irq 18 at device 10.0 on pci0 ath0: mac 5.6 phy 4.1 5ghz radio 3.6 and the desktop is: ath0: mem 0xfeae0000-0xfeaeffff irq 22 at device 10.0 on pci2 ath0: mac 5.9 phy 4.3 5ghz radio 4.6 -- Jake Hamby From owner-freebsd-current@FreeBSD.ORG Fri Aug 13 02:28:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCD8D16A4CE for ; Fri, 13 Aug 2004 02:28:13 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FC0043D41 for ; Fri, 13 Aug 2004 02:28:13 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.90] ([66.127.85.90]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i7D2SCWi044545 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 12 Aug 2004 19:28:12 -0700 (PDT) (envelope-from sam@errno.com) In-Reply-To: <411C2613.9040604@anobject.com> References: <411C2613.9040604@anobject.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6E3F4E52-ECD0-11D8-BE69-000A95AD0668@errno.com> Content-Transfer-Encoding: 7bit From: Sam Leffler Date: Thu, 12 Aug 2004 19:28:15 -0700 To: Jake Hamby X-Mailer: Apple Mail (2.619) cc: current@freebsd.org Subject: Re: updated ath driver: please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Aug 2004 02:28:13 -0000 On Aug 12, 2004, at 7:23 PM, Jake Hamby wrote: > I've just finished putting together a version of the ath driver based > on a merge of the current FreeBSD version with the latest Linux > madwifi driver and HAL version 0.9.11.6. I included all of the > features except for those not currently supported by FreeBSD's version > of net80211 (e.g. only WEP crypto is supported). Please test it out. > It may be too late to get this checked in before the code freeze, but > I think it's our best bet to have a version of the ath driver with a > recent HAL but without disturbing the shared net80211 code. I have a full merge of the ath driver and net80211 code and have backpatched the other drivers that use net80211 to deal with the api changes. I intend to circulate the complete set of changes for test once I've tested ap operation of the wi driver. Sam From owner-freebsd-current@FreeBSD.ORG Fri Aug 13 02:30:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 763F816A4CE; Fri, 13 Aug 2004 02:30:08 +0000 (GMT) Received: from phoenix.gargantuan.com (rrcs-se-24-73-171-238.biz.rr.com [24.73.171.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BE6343D2F; Fri, 13 Aug 2004 02:30:07 +0000 (GMT) (envelope-from freebsd-current@gargantuan.com) Received: from localhost (localhost.gargantuan.com [127.0.0.1]) by spamassassin-injector (Postfix) with SMTP id 814F2A5; Thu, 12 Aug 2004 22:30:05 -0400 (EDT) Received: by phoenix.gargantuan.com (Postfix, from userid 1001) id CDE84271; Thu, 12 Aug 2004 22:29:28 -0400 (EDT) Date: Thu, 12 Aug 2004 22:29:28 -0400 From: "Michael W. Oliver" To: Taku YAMAMOTO Message-ID: <20040813022928.GE1337@gargantuan.com> Mail-Followup-To: Taku YAMAMOTO , Don Lewis , freebsd-current@gargantuan.com, freebsd-current@FreeBSD.org References: <20040812221348.GA1337@gargantuan.com> <200408122253.i7CMrseZ021586@gw.catspoiler.org> <20040813090231.3c6acb13.taku@tackymt.homeip.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pY3vCvL1qV+PayAL" Content-Disposition: inline In-Reply-To: <20040813090231.3c6acb13.taku@tackymt.homeip.net> X-WWW-Site: http://michael.gargantuan.com X-PGP-Public-Key: $X-WWW-Site/gnupg/pubkey.asc X-PGP-Fingerprint: 2694 0179 AE3F BFAE 0916 0BF5 B16B FBAB C5FA A3C9 X-Home-Phone: +1-863-816-8091 X-Mobile-Phone: +1-863-738-2334 X-Home-Address0: 8008 Apache Lane X-Home-Address1: Lakeland, FL X-Home-Address2: 33810-2172 X-Home-Address3: United States of America X-Good-Question-Guide: http://www.catb.org/~esr/faqs/smart-questions.html X-Netiquette-Guidelines: http://www.ietf.org/rfc/rfc1855.txt User-Agent: Mutt/1.5.6i X-Spam-DCC: : X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on phoenix.gargantuan.com X-Spam-Level: X-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,BAYES_00,NO_DNS_FOR_FROM autolearn=no version=2.64 cc: freebsd-current@gargantuan.com cc: Don Lewis cc: freebsd-current@FreeBSD.org Subject: Re: pcm_chn_create failed with 2004-08-12 kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Aug 2004 02:30:08 -0000 --pY3vCvL1qV+PayAL Content-Type: multipart/mixed; boundary="at6+YcpfzWZg/htY" Content-Disposition: inline --at6+YcpfzWZg/htY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004-08-13T09:02:31+0900, Taku YAMAMOTO wrote: > On Thu, 12 Aug 2004 15:53:54 -0700 (PDT) > Don Lewis wrote: > > On 12 Aug, Michael W. Oliver wrote: > > > Ok, this world was cvsup'd on 2004.08.12 at 09:59:03 EDT. I removed = the > > > 'sound' and 'snd_maestro' device lines from my kernel config and deci= ded > > > to load them as modules (after I got the same output shown below with > > > sound and snd_maestro compiled into the kernel). When I kldload > > > 'sound', I get no output. After that, when I kldload 'snd_maestro', I > > > get the following output: > > >=20 > > >=20 > > > pcm0: port 0x1400-0x14ff irq 10 at device= 8.0 on pci0 > > > pcm0: > > > pcm0: [GIANT-LOCKED] > > > pcm0: offset 0xfffa1000 exceeds limit. pcm0: chn_init(pcm0:play:0) fa= iled: err =3D 19 > > > pcm0: pcm_chn_create(aggch, 1, 0xc223e700) failed > > > pcm0: offset 0xfffa1000 exceeds limit. pcm0: chn_init(pcm0:play:0) fa= iled: err =3D 19 > > > pcm0: pcm_chn_create(aggch, 1, 0xc223e700) failed > > > pcm0: offset 0xfffa1000 exceeds limit. pcm0: chn_init(pcm0:play:0) fa= iled: err =3D 19 > > > pcm0: pcm_chn_create(aggch, 1, 0xc223e700) failed > > > pcm0: offset 0xfffa1000 exceeds limit. pcm0: chn_init(pcm0:play:0) fa= iled: err =3D 19 > > > pcm0: pcm_chn_create(aggch, 1, 0xc223e700) failed > >=20 > > It sure looks to me like physaddr is getting set to zero in > > aggch_init(). It also looks like the device_printf() format string is > > missing a newline. > >=20 > > Try adding a device_printf() to aggch_init() to print out both physaddr > > and ess->baseaddr so that we can figure out where the calculation > > ch->offset =3D physaddr - ess->baseaddr; > > is going wrong. The source file is /usr/src/sys/dev/sound/pci/maestro.c >=20 > This is caused by physaddr which is smaller than ess->baseaddr. > It will often occur when memory is fragmented, I think. >=20 > Michael, would you try the newer driver? > http://www.tackymt.homeip.net/~taku/maestro-latest/ Ok, I compiled and loaded your new driver, and aside from noise when compiling, it seems to be working ok. As an added bonus, I now have one record channel where there was none before. Whoo-hoo! The aforementioned noise from compilation is attached (note that I am using "-O2 -pipe" in /etc/make.conf - I don't know if that makes a difference). --=20 Mike perl -e 'print unpack("u","88V]N=3D&%C=3D\"!I;F9O(&EN(&AE861E sound/driver/maestro cc -O2 -pipe -march=pentium2 -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /usr/obj/usr/src/sys/CYCLOPS/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -I/usr/obj/usr/src/sys/CYCLOPS -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c: In function `agg_init': /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:567: warning: inlining failed in call to 'agg_stopclock': --param large-function-growth limit reached /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:654: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:567: warning: inlining failed in call to 'agg_stopclock': --param large-function-growth limit reached /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:656: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:567: warning: inlining failed in call to 'agg_stopclock': --param large-function-growth limit reached /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:658: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:567: warning: inlining failed in call to 'agg_stopclock': --param large-function-growth limit reached /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:660: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:567: warning: inlining failed in call to 'agg_stopclock': --param large-function-growth limit reached /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:663: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:567: warning: inlining failed in call to 'agg_stopclock': --param large-function-growth limit reached /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:664: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:567: warning: inlining failed in call to 'agg_stopclock': --param large-function-growth limit reached /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:665: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:567: warning: inlining failed in call to 'agg_stopclock': --param large-function-growth limit reached /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:666: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:567: warning: inlining failed in call to 'agg_stopclock': --param large-function-growth limit reached /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:667: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:567: warning: inlining failed in call to 'agg_stopclock': --param large-function-growth limit reached /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:668: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:567: warning: inlining failed in call to 'agg_stopclock': --param large-function-growth limit reached /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:669: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:567: warning: inlining failed in call to 'agg_stopclock': --param large-function-growth limit reached /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:672: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:567: warning: inlining failed in call to 'agg_stopclock': --param large-function-growth limit reached /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:675: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:567: warning: inlining failed in call to 'agg_stopclock': --param large-function-growth limit reached /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:676: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:567: warning: inlining failed in call to 'agg_stopclock': --param large-function-growth limit reached /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:677: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:567: warning: inlining failed in call to 'agg_stopclock': --param large-function-growth limit reached /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:678: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c: In function `aggch_start_dac': /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:479: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:480: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:481: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:482: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:483: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:484: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:485: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:488: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:490: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:479: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:480: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:481: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:482: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:483: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:484: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:485: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:488: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:490: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c: In function `aggch_start_adc': /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:479: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:480: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:481: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:482: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:483: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:484: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:485: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:488: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:490: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:479: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:480: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:481: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:482: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:483: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:484: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:485: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:488: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:490: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:479: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:480: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:481: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:482: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:483: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:484: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:485: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:488: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:490: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:479: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:480: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:481: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:482: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:483: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:484: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:485: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:488: warning: called from here /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:464: warning: inlining failed in call to 'wp_wrapu': --param large-function-growth limit reached while inlining the caller /usr/src/sys/modules/sound/driver/maestro/../../../../dev/sound/pci/maestro.c:490: warning: called from here ld -d -warn-common -r -d -o snd_maestro.kld maestro.o touch /usr/obj/usr/src/sys/CYCLOPS/modules/usr/src/sys/modules/sound/driver/maestro/export_syms awk -f /usr/src/sys/modules/sound/driver/maestro/../../../../conf/kmod_syms.awk snd_maestro.kld /usr/obj/usr/src/sys/CYCLOPS/modules/usr/src/sys/modules/sound/driver/maestro/export_syms | xargs -J% objcopy % snd_maestro.kld ld -Bshareable -d -warn-common -o snd_maestro.ko snd_maestro.kld objcopy --strip-debug snd_maestro.ko --at6+YcpfzWZg/htY-- --pY3vCvL1qV+PayAL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBHCeIsWv7q8X6o8kRAk2mAJ4pods7lISq66G0/WencpkqCI4iBgCeL18c fBZug0uUmPVuhvOL4JNvaOg= =WuNS -----END PGP SIGNATURE----- --pY3vCvL1qV+PayAL-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 13 03:31:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EFA816A4CE for ; Fri, 13 Aug 2004 03:31:24 +0000 (GMT) Received: from bronco.gopix.net (gopix.net [38.118.153.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D23E43D4C for ; Fri, 13 Aug 2004 03:31:24 +0000 (GMT) (envelope-from jhamby@anobject.com) Received: from [192.168.0.13] (ca-stmnca-cuda2-blade8b-87.stmnca.adelphia.net [68.65.226.87]) (authenticated bits=0) by bronco.gopix.net (8.12.11/8.12.11) with ESMTP id i7D3VKti016196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2004 20:31:22 -0700 Message-ID: <411C3604.6060809@anobject.com> Date: Thu, 12 Aug 2004 20:31:16 -0700 From: Jake Hamby User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040810) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Leffler References: <411C2613.9040604@anobject.com> <6E3F4E52-ECD0-11D8-BE69-000A95AD0668@errno.com> In-Reply-To: <6E3F4E52-ECD0-11D8-BE69-000A95AD0668@errno.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: updated ath driver: please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Aug 2004 03:31:24 -0000 Sam Leffler wrote: > > I have a full merge of the ath driver and net80211 code and have > backpatched the other drivers that use net80211 to deal with the api > changes. I intend to circulate the complete set of changes for test > once I've tested ap operation of the wi driver. Okay, very cool! I just wanted to provide another option (even if it is a horrible hack...) for impatient people who can't use the old HAL. -Jake From owner-freebsd-current@FreeBSD.ORG Fri Aug 13 03:55:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CE2D16A4CE for ; Fri, 13 Aug 2004 03:55:09 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 150DE43D39 for ; Fri, 13 Aug 2004 03:55:09 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i7D3t7Wi044756 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 12 Aug 2004 20:55:08 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: Jake Hamby Date: Thu, 12 Aug 2004 20:57:56 -0700 User-Agent: KMail/1.6.1 References: <411C2613.9040604@anobject.com> <6E3F4E52-ECD0-11D8-BE69-000A95AD0668@errno.com> <411C3604.6060809@anobject.com> In-Reply-To: <411C3604.6060809@anobject.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408122057.56042.sam@errno.com> cc: current@freebsd.org Subject: Re: updated ath driver: please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Aug 2004 03:55:09 -0000 On Thursday 12 August 2004 08:31 pm, Jake Hamby wrote: > Sam Leffler wrote: > > I have a full merge of the ath driver and net80211 code and have > > backpatched the other drivers that use net80211 to deal with the api > > changes. I intend to circulate the complete set of changes for test > > once I've tested ap operation of the wi driver. > > Okay, very cool! I just wanted to provide another option (even if it is > a horrible hack...) for impatient people who can't use the old HAL. Thanks. I know I've been AWOL. Sam From owner-freebsd-current@FreeBSD.ORG Fri Aug 13 04:36:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A543416A4CE for ; Fri, 13 Aug 2004 04:36:25 +0000 (GMT) Received: from mailhost.nmt.edu (mailhost.nmt.edu [129.138.4.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52C6343D2F for ; Fri, 13 Aug 2004 04:36:25 +0000 (GMT) (envelope-from wcolburn@nmt.edu) Received: from icewing.nmt.edu (icewing.nmt.edu [129.138.4.102]) by mailhost.nmt.edu (8.13.0/8.13.0) with ESMTP id i7D4aNcS031022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Aug 2004 22:36:23 -0600 Received: from icewing.nmt.edu (localhost [127.0.0.1]) by icewing.nmt.edu (8.12.8/8.12.8) with ESMTP id i7D4aN2w008544 for ; Thu, 12 Aug 2004 22:36:24 -0600 Received: (from wcolburn@localhost) by icewing.nmt.edu (8.12.8/8.12.8/Submit) id i7D4aNF1008542 for freebsd-current@freebsd.org; Thu, 12 Aug 2004 22:36:23 -0600 Date: Thu, 12 Aug 2004 22:36:23 -0600 From: "William D. Colburn (aka Schlake)" To: freebsd-current@freebsd.org Message-ID: <20040813043623.GA8513@nmt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: panic: lockmgr: locking against myself X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 13 Aug 2004 04:36:25 -0000 I was overly optimistic and tried the cutting edge kernel for my new server, but it didn't work out. Now I'm trying to run 5.2.1-RELEASE-p9, but it keeps panicing on "lockmgr: locking against myself". I did some searching, but I can't find any helpful information on how to fix this. I don't have any debug info from the crash right bow, but I do have my dmesg showing the current system and I could probably get debug info if I needed it. My kernel is a copy of GENERIC with the addition of just one option, QUOTA. Any advice (including a reminder of where the page is describing how to pull the debug info out of the kernel panic) would be appreciated. :) Copyright (c) 1992-2004 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 5.2.1-RELEASE-p9 #5: Thu Aug 12 15:24:56 MDT 2004 wcolburn@newuserhost.NMT.edu:/usr/obj/usr/src/sys/USERHOST Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a36000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a361f4. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2790.97-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 1073676288 (1023 MB) avail memory = 1033510912 (985 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs 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 4 ioapic1: Changing APIC ID to 5 ioapic2: Changing APIC ID to 6 ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard ioapic2 irqs 32-47 on motherboard Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 pcibios: BIOS version 2.10 Using $PIR table, 9 entries at 0xc00fc480 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_cpu2: on acpi0 acpi_cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: slot 15 INTA is routed to irq 5 pci0: at device 4.0 (no driver attached) pci0: at device 4.1 (no driver attached) pci0: at device 4.2 (no driver attached) pci0: at device 14.0 (no driver attached) atapci0: port 0x8b0-0x8bf,0x8d8-0x8db,0x8d0-0x8d7,0x8c8-0x8cb,0x8c0-0x8c7 at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: simplex device, DMA on primary only ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] ohci0: mem 0xfe100000-0xfe100fff irq 5 at device 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered isab0: at device 15.3 on pci0 isa0: on isab0 pcib1: on acpi0 pci4: on pcib1 pcib2: at device 8.0 on pci4 pci5: on pcib2 pci5: at device 6.0 (no driver attached) pci5: at device 6.1 (no driver attached) aac0: mem 0xf0000000-0xf7ffffff irq 30 at device 8.1 on pci4 aac0: [MPSAFE] aac0: i960RX 100MHz, 118MB cache memory, optional battery present aac0: Kernel 2.7-1, Build 3170, S/N 7041d3 aac0: Supported Options=75c pcib3: on acpi0 pci3: on pcib3 bge0: mem 0xfcd10000-0xfcd1ffff irq 28 at device 6.0 on pci3 bge0: Ethernet address: 00:0b:db:a8:86:37 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: mem 0xfcd00000-0xfcd0ffff irq 29 at device 8.0 on pci3 bge1: Ethernet address: 00:0b:db:a8:86:38 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto pcib4: on acpi0 pci2: on pcib4 pcib5: on acpi0 pci1: on pcib5 ahc0: port 0xdc00-0xdcff mem 0xfcf00000-0xfcf00fff irq 16 at device 6.0 on pci1 aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A orm0: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000058 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71908086) pcibios: BIOS version 2.10 Found $PIR table, 9 entries at 0xc00fdf30 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs slot 1 0 15 A 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 15 B 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 15 C 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 15 D 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 16 A 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 16 B 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 16 C 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 16 D 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 3 0 17 A 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 3 0 17 B 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 3 0 17 C 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 3 0 17 D 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 4 0 18 A 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 4 0 18 B 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 4 0 18 C 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 4 0 18 D 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 5 0 19 A 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 5 0 19 B 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 5 0 19 C 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 5 0 19 D 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 6 0 20 A 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 6 0 20 B 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 6 0 20 C 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 6 0 20 D 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 7 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 7 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 7 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 7 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 1 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 1 B 0x61 3 4 5 6 7 9 10 11 12 14 15 AcpiOsDerivePciId: bus 0 dev 7 func 3 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi0: Power Button (fixed) AcpiOsDerivePciId: bus 0 dev 0 func 0 ACPI timer looks BAD min = 4, max = 878, width = 874 ACPI timer looks BAD min = 4, max = 683, width = 679 ACPI timer looks BAD min = 4, max = 7842, width = 7838 ACPI timer looks BAD min = 4, max = 310, width = 306 ACPI timer looks BAD min = 4, max = 2654, width = 2650 ACPI timer looks BAD min = 4, max = 8603, width = 8599 ACPI timer looks BAD min = 4, max = 593, width = 589 ACPI timer looks BAD min = 4, max = 174, width = 170 ACPI timer looks BAD min = 4, max = 9788, width = 9784 ACPI timer looks BAD min = 4, max = 296, width = 292 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] 0+ low,level,sharable 0.15.0 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.15.1 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 14 15] 11+ low,level,sharable 0.15.2 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.15.3 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.16.0 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 14 15] 11+ low,level,sharable 0.16.1 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.16.2 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] 0+ low,level,sharable 0.16.3 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 14 15] 11+ low,level,sharable 0.17.0 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.17.1 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] 0+ low,level,sharable 0.17.2 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.17.3 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.18.0 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] 0+ low,level,sharable 0.18.1 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.18.2 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 14 15] 11+ low,level,sharable 0.18.3 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] 0+ low,level,sharable 0.19.0 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.19.1 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 14 15] 11+ low,level,sharable 0.19.2 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.19.3 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.20.0 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 14 15] 11+ low,level,sharable 0.20.1 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.20.2 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] 0+ low,level,sharable 0.20.3 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] 0+ low,level,sharable 0.7.0 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.7.1 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 14 15] 11+ low,level,sharable 0.7.2 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.7.3 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base f8000000, size 26, enabled found-> vendor=0x8086, dev=0x7190, revid=0x01 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7191, revid=0x01 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0000, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x80 (32000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7110, revid=0x08 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 00001050, size 4, port disabled found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=7, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 00001060, size 5, enabled pcib0: matched entry for 0.7.INTD (src \\_SB_.PCI0.ISA_.LNKD) pcib0: possible interrupts: 3 4 5 6 7 9 10 11 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.ISA_.LNKA (references 7, priority 86191): interrupts: 11 10 5 9 7 6 4 3 15 14 penalty: 280 280 330 560 5280 5280 5280 5280 50280 50280 \\_SB_.PCI0.ISA_.LNKB (references 7, priority 86191): interrupts: 11 10 5 9 7 6 4 3 15 14 penalty: 280 280 330 560 5280 5280 5280 5280 50280 50280 \\_SB_.PCI0.ISA_.LNKC (references 7, priority 86191): interrupts: 11 10 5 9 7 6 4 3 15 14 penalty: 280 280 330 560 5280 5280 5280 5280 50280 50280 \\_SB_.PCI0.ISA_.LNKD (references 7, priority 86191): interrupts: 11 10 5 9 7 6 4 3 15 14 penalty: 280 280 330 560 5280 5280 5280 5280 50280 50280 pcib0: slot 7 INTD routed to irq 9 via \\_SB_.PCI0.ISA_.LNKD found-> vendor=0x8086, dev=0x7112, revid=0x00 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=9 map[90]: type 4, range 32, base 00001040, size 4, enabled found-> vendor=0x8086, dev=0x7113, revid=0x08 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 00001080, size 4, enabled map[14]: type 1, range 32, base fd000000, size 24, enabled map[18]: type 1, range 32, base fc000000, size 24, enabled found-> vendor=0x15ad, dev=0x0405, revid=0x00 bus=0, slot=15, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 00001400, size 7, enabled map[14]: type 1, range 32, base fe000000, size 12, enabled pcib0: matched entry for 0.16.INTA (src \\_SB_.PCI0.ISA_.LNKB) pcib0: possible interrupts: 3 4 5 6 7 9 10 11 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.ISA_.LNKA (references 7, priority 88396): interrupts: 11 10 5 9 7 6 4 3 15 14 penalty: 560 560 610 1190 5560 5560 5560 5560 50560 50560 \\_SB_.PCI0.ISA_.LNKB (references 7, priority 88396): interrupts: 11 10 5 9 7 6 4 3 15 14 penalty: 560 560 610 1190 5560 5560 5560 5560 50560 50560 \\_SB_.PCI0.ISA_.LNKC (references 7, priority 88396): interrupts: 11 10 5 9 7 6 4 3 15 14 penalty: 560 560 610 1190 5560 5560 5560 5560 50560 50560 pcib0: slot 16 INTA routed to irq 9 via \\_SB_.PCI0.ISA_.LNKB found-> vendor=0x1000, dev=0x0030, revid=0x01 bus=0, slot=16, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x06 (1500 ns), maxlat=0xff (63750 ns) intpin=a, irq=9 map[10]: type 4, range 32, base 00001480, size 7, enabled pcib0: matched entry for 0.17.INTA (src \\_SB_.PCI0.ISA_.LNKC) pcib0: possible interrupts: 3 4 5 6 7 9 10 11 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.ISA_.LNKA (references 7, priority 90601): interrupts: 11 10 5 9 7 6 4 3 15 14 penalty: 840 840 890 1820 5840 5840 5840 5840 50840 50840 \\_SB_.PCI0.ISA_.LNKC (references 7, priority 90601): interrupts: 11 10 5 9 7 6 4 3 15 14 penalty: 840 840 890 1820 5840 5840 5840 5840 50840 50840 pcib0: slot 17 INTA routed to irq 11 via \\_SB_.PCI0.ISA_.LNKC found-> vendor=0x1022, dev=0x2000, revid=0x10 bus=0, slot=17, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x06 (1500 ns), maxlat=0xff (63750 ns) intpin=a, irq=11 pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: memory decode 0x0-0x0 pcib1: prefetched decode 0x0-0x0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND pci1: on pcib1 pci1: physical bus=1 isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 7.1 (no driver attached) uhci0: port 0x1060-0x107f irq 9 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1060 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) pci0: at device 15.0 (no driver attached) mpt0: port 0x1400-0x147f mem 0xfe000000-0xfe000fff irq 9 at device 16.0 on pci0 mpt0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xfe000000 mpt0: [GIANT-LOCKED] mpt0: soft reset lnc0: port 0x1480-0x14ff irq 11 at device 17.0 on pci0 lnc0: Attaching PCNet/PCI Ethernet adapter lnc0: Reserved 0x80 bytes for rid 0x10 type 4 at 0x1480 lnc0: [GIANT-LOCKED] lnc0: bpf attached lnc0: Ethernet address: 00:0c:29:90:ee:85 lnc0: PCnet-PCI atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0 irq 12 on acpi0 psm0: current command byte:0047 psm0: failed to get data. psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000000, packet size:4 psm0: syncmask:00, syncbits:00 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: irq maps: 0x1 0x1 0x1 0x1 sio1: probe failed test(s): 0 1 2 4 6 7 9 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) sio1: irq maps: 0x1 0x1 0x1 0x1 sio1: probe failed test(s): 0 1 2 4 6 7 9 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) atkbdc: atkbdc0 already exists; skipping it lnc: lnc0 already exists; skipping it sio: sio0 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xe4000-0xe7fff,0xdc000-0xdffff,0xca000-0xcafff,0xc0000-0xc7fff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) ata0 failed to probe at port 0x1f0 irq 14 on isa0 ata1 failed to probe at port 0x170 irq 15 on isa0 bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x1 0x1 0x1 0x1 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 05 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Timecounter "TSC" frequency 2659750808 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached Waiting 15 seconds for SCSI devices to settle cpu0: set speed to 100.0% acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% (probe0:mpt0:0:0:0): error 22 (probe0:mpt0:0:0:0): Unretryable Error (probe1:mpt0:0:1:0): error 22 (probe1:mpt0:0:1:0): Unretryable Error (probe0:mpt0:0:0:1): error 22 (probe0:mpt0:0:0:1): Unretryable Error (probe0:mpt0:0:1:1): error 22 (probe0:mpt0:0:1:1): Unretryable Error (probe1:mpt0:0:0:2): error 22 (probe1:mpt0:0:0:2): Unretryable Error (probe0:mpt0:0:1:2): error 22 (probe0:mpt0:0:1:2): Unretryable Error (probe1:mpt0:0:0:3): error 22 (probe1:mpt0:0:0:3): Unretryable Error (probe0:mpt0:0:1:3): error 22 (probe0:mpt0:0:1:3): Unretryable Error (probe1:mpt0:0:0:4): error 22 (probe1:mpt0:0:0:4): Unretryable Error (probe0:mpt0:0:1:4): error 22 (probe0:mpt0:0:1:4): Unretryable Error (probe1:mpt0:0:0:5): error 22 (probe1:mpt0:0:0:5): Unretryable Error (probe0:mpt0:0:1:5): error 22 (probe0:mpt0:0:1:5): Unretryable Error (probe1:mpt0:0:0:6): error 22 (probe1:mpt0:0:0:6): Unretryable Error (probe0:mpt0:0:1:6): error 22 (probe0:mpt0:0:1:6): Unretryable Error (probe1:mpt0:0:0:7): error 22 (probe1:mpt0:0:0:7): Unretryable Error (probe0:mpt0:0:1:7): error 22 (probe0:mpt0:0:1:7): Unretryable Error pass0 at mpt0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-2 device pass0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled pass1 at mpt0 bus 0 target 1 lun 0 pass1: Removable CD-ROM SCSI-2 device pass1: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled da0: 4096MB (8388608 512 byte sectors: 255H 63S/T 522C) cd0 at mpt0 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled cd0: cd present [121808 x 2048 byte records] GEOM: new disk da0 GEOM: new disk cd0 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):521/254/63 s:63 l:8385867 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure da0s1, start 32256 length 4293563904 end 4293596159 GEOM: Configure da0s1a, start 0 length 134217728 end 134217727 GEOM: Configure da0s1b, start 134217728 length 134217728 end 268435455 GEOM: Configure da0s1c, start 0 length 4293563904 end 4293563903 GEOM: Configure da0s1d, start 268435456 length 4025128448 end 4293563903 Mounting root from ufs:/dev/da0s1a start_init: trying /sbin/init lnc0: Device timeout -- Resetting lnc0: Device timeout -- Resetting lnc0: Device timeout -- Resetting lnc0: Device timeout -- Resetting lnc0: Device timeout -- Resetting lnc0: Device timeout -- Resetting lnc0: Missed packet -- no receive buffer lnc0: Missed packet -- no receive buffer lnc0: Missed packet -- no receive buffer lnc0: Missed packet -- no receive buffer lnc0: Missed packet -- no receive buffer lnc0: Missed packet -- no receive buffer lnc0: Missed packet -- no receive buffer lnc0: Missed packet -- no receive buffer lnc0: Missed packet -- no receive buffer lnc0: Missed packet -- no receive buffer lnc0: Missed packet -- no receive buffer lnc0: Missed packet -- no receive buffer lnc0: Missed packet -- no receive buffer umass0: USB Flash Disk, rev 2.00/2.00, addr 2 umass0:1:0:-1: Attached to scbus1 pass2 at umass-sim0 bus 0 target 0 lun 0 pass2: < USB BAR 2.00> Removable Direct Access SCSI-2 device pass2: Serial Number \^_ pass2: 1.000MB/s transfers GEOM: new disk da1 da1 at umass-sim0 bus 0 target 0 lun 0 da1: < USB BAR 2.00> Removable Direct Access SCSI-2 device da1: Serial Number \^_ da1: 1.000MB/s transfers da1: 249MB (511744 512 byte sectors: 64H 32S/T 249C) [0] f:00 typ:6 s(CHS):0/1/1 e(CHS):30/254/63 s:63 l:497952 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure da1s1, start 32256 length 254951424 end 254983679 --0-2070129494-1092482154=:82787-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 11:23:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F74716A4CE for ; Sat, 14 Aug 2004 11:23:16 +0000 (GMT) Received: from the-macgregors.org (82-33-59-105.cable.ubr06.stav.blueyonder.co.uk [82.33.59.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE79F43D41 for ; Sat, 14 Aug 2004 11:23:15 +0000 (GMT) (envelope-from freebsd.macgregor@blueyonder.co.uk) X-Urban-Legend: Mail headers contain urban legends Received: from fire (rob@fire.macgregor [192.168.32.100]) (authenticated bits=0) by the-macgregors.org (8.13.1/8.13.1) with ESMTP id i7EBNEee019926 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 14 Aug 2004 11:23:14 GMT Message-Id: <200408141123.i7EBNEee019926@the-macgregors.org> From: "Rob MacGregor" To: Date: Sat, 14 Aug 2004 12:23:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <20040814111554.90574.qmail@web13422.mail.yahoo.com> Thread-Index: AcSB8HIfRGfLBLqmSfGiL6ipL4XdsAAAHMjQ X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) Subject: RE: lnc0 in VmWare doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 11:23:16 -0000 Vitaly Markitantov [ua_vitaly@yahoo.com] danced on the keyboard and produced: > I'm running -CURRENT in VmWare virtual machine. > > Since about August 07 2004 lnc0 interface doesn't work > > I see just complains about: > > lnc0: Device timeout -- Resetting > lnc0: Missed packet -- no receive buffer [aol] Me too [/aol] I'm running the latest VMWare for Windows (4.5.2) and have exactly the same problem. I haven't tried it with an older VMWare yet. It's still possible to ping the interface's IP from the interface itself, just nothing else. -- Rob | Oh my God! They killed init! You bastards! From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 11:29:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F2AB16A4CE; Sat, 14 Aug 2004 11:29:29 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id B254B43D1D; Sat, 14 Aug 2004 11:29:26 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id 9A14950BB5; Sat, 14 Aug 2004 20:29:25 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id 350BE50B8A; Sat, 14 Aug 2004 20:29:24 +0900 (JST) Date: Sat, 14 Aug 2004 20:29:24 +0900 Message-ID: <7m1xiaez57.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: Lukas Ertl In-Reply-To: <20040814112823.E569@korben.in.tern> References: <7m3c2qf5yf.wl@black.imgsrc.co.jp> <20040814112823.E569@korben.in.tern> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 cc: Current Subject: Re: Memory modified after free (Most recently used by GEOM) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 11:29:29 -0000 At Sat, 14 Aug 2004 11:28:51 +0200 (CEST), Lukas Ertl wrote: > > ----- > > Memory modified after free 0xcac80000(508) val=56204e49 @ 0xcac80000 > > panic: Most recently used by GEOM > > Do you use any special GEOM classes? I'm starting to use geom_stripe and vinum from yesterday. Since I have not experienced this panic before, they may be suspects. :-) -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 12:52:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B799D16A4CE; Sat, 14 Aug 2004 12:52:16 +0000 (GMT) Received: from dglawrence.com (c-24-21-223-117.client.comcast.net [24.21.223.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DF6243D48; Sat, 14 Aug 2004 12:52:16 +0000 (GMT) (envelope-from dg@nexus.dglawrence.com) Received: from nexus.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.12.10/8.12.6) with ESMTP id i7ECt4nf083841; Sat, 14 Aug 2004 05:55:04 -0700 (PDT) (envelope-from dg@nexus.dglawrence.com) Received: (from dg@localhost) by nexus.dglawrence.com (8.12.10/8.12.3/Submit) id i7ECt31s083840; Sat, 14 Aug 2004 05:55:03 -0700 (PDT) Date: Sat, 14 Aug 2004 05:55:03 -0700 From: "David G. Lawrence" To: John Baldwin , freebsd-current@freebsd.org, Andrew Gallatin Message-ID: <20040814125503.GF40460@nexus.dglawrence.com> References: <16668.61707.474283.639200@grasshopper.cs.duke.edu> <200408131326.16412.jhb@FreeBSD.org> <20040814101328.GA95083@squirm.dsto.defence.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040814101328.GA95083@squirm.dsto.defence.gov.au> Subject: Re: Is the TSC timecounter safe on SMP system? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 12:52:16 -0000 > Can someone please elaborate on the acronym TSC ? > Please no comments about google etc been there done that and it wasn't useful. TSC is the Time Stamp Counter. It is a profiling counter internal to modern Pentium processors that counts core frequency clock ticks. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 TeraSolutions, Inc. - http://www.terasolutions.com - (888) 346 7175 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 13:22:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19FEC16A4CF for ; Sat, 14 Aug 2004 13:22:37 +0000 (GMT) Received: from mail.ciam.ru (mail.ciam.ru [213.147.57.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9889643D1F for ; Sat, 14 Aug 2004 13:22:36 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from ppp174-215.pppoe.mtu-net.ru ([81.195.174.215]) by mail.ciam.ru with asmtp (Exim 4.x) id 1BvyUU-000GJv-Mt for freebsd-current@freebsd.org; Sat, 14 Aug 2004 17:22:35 +0400 Message-ID: <411E122B.5020807@FreeBSD.org> Date: Sat, 14 Aug 2004 17:22:51 +0400 From: Sergey Matveychuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: lnc0 broken on 20040813 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 13:22:37 -0000 I've updated my CURRENT box to 20040813 from ~20040720 and lnc0 (VMWare adapter) stoped works with message: lnc0: Device timeout -- Resetting. When I boot 5.2.1 on the same box it works fine. % grep lnc0 /var/run/dmesg.boot lnc0: port 0x1080-0x109f mem 0xfd000000-0xfd00001f lnc0: Attaching PCNet/PCI Ethernet adapter lnc0: [GIANT-LOCKED] lnc0: Ethernet address: 00:50:56:40:00:5f lnc0: PCNet-PCI -- Sem. From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 13:47:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E87F16A4CE for ; Sat, 14 Aug 2004 13:47:56 +0000 (GMT) Received: from cpanel.ezone.ru (cpanel.ezone.ru [213.85.31.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD57E43D45 for ; Sat, 14 Aug 2004 13:47:54 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from [81.195.2.169] (ppp2-169.pppoe.mtu-net.ru [81.195.2.169]) (authenticated bits=0) by cpanel.ezone.ru (8.13.1/8.12.11) with ESMTP id i7EDlnP6003256 for ; Sat, 14 Aug 2004 17:47:49 +0400 (MSD) (envelope-from mcsi@mcsi.pp.ru) Message-ID: <411E17FB.7070603@mcsi.pp.ru> Date: Sat, 14 Aug 2004 17:47:39 +0400 From: Maxim Maximov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040810 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail3.ezone.ru Subject: module cbb already present X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 13:47:56 -0000 Hello. In todays kernel there is some message which doesn't present on Aug 9 kernel (marked with empty lines). My kernel config didn't change. /boot/loader.conf is empty. Copyright (c) 1992-2004 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 5.2-CURRENT #0: Sat Aug 14 12:05:18 MSD 2004 mcsi@ultra.domain:/usr/obj/usr/src/sys/ULTRA WARNING: WITNESS option enabled, expect reduced performance. module cbb already present! Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 536674304 (511 MB) avail memory = 514506752 (490 MB) ACPI APIC Table: Also this kernel stops after 'Pre-seeding PRNG:' message and stops until I enter DDB. I can press any keys and they are displayed at the screen. Ctrl-C doesn't work. I dont have a console at the moment, I will post output of DDB trace, show threads, show locks and ps in monday. I wonder if anyone else see this? It goes fine into single user mode. When I exit single user shell, it boots fine. Witness enabled, preemption disabled, htt enabled, SMP kernel, ACPI enabled (when disabled, it panics at boot btw), cleanworld before buildworld, debug.mpsafenet=0 or 1, it doesn't matter on this subject. -- Maxim Maximov From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 14:23:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED18C16A4CE for ; Sat, 14 Aug 2004 14:23:58 +0000 (GMT) Received: from imap.univie.ac.at (mail.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C99243D45 for ; Sat, 14 Aug 2004 14:23:58 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from [192.168.0.4] (adslle.cc.univie.ac.at [131.130.102.11]) by imap.univie.ac.at (8.12.10/8.12.10) with ESMTP id i7EENiDn192104; Sat, 14 Aug 2004 16:23:46 +0200 Date: Sat, 14 Aug 2004 16:23:45 +0200 (CEST) From: Lukas Ertl To: Robert Watson In-Reply-To: Message-ID: <20040814162252.J552@korben.in.tern> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-DCC-ZID-Univie-Metrics: mx9.univie.ac.at 4248; Body=4 Fuz1=4 Fuz2=4 cc: freebsd-current@FreeBSD.org cc: Martin Blapp Subject: Re: Deadlocks with recent SMP current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 14:23:59 -0000 On Fri, 13 Aug 2004, Robert Watson wrote: > to be delivering in this hang (er, ouch). You might want to try putting a > kdb_enter() just after the T_NMI in both switch statements in trap() in > i386/i386/trap.c. This will cause the kernel to enter the debugger before > digging into the more general NMI code, which generates log messages, etc, > that may increase the chances of a problem. Even with this change I only get a 'kernel trap 19 with interrupts disabled' when sending the NMI, but no DDB prompt. cheers, le -- Lukas Ertl http://homepage.univie.ac.at/l.ertl/ le@FreeBSD.org http://people.freebsd.org/~le/ From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 14:38:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C5DC16A4CF for ; Sat, 14 Aug 2004 14:38:25 +0000 (GMT) Received: from tethys.ringofsaturn.com (tethys.ringofsaturn.com [66.13.175.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26D7643D31 for ; Sat, 14 Aug 2004 14:38:23 +0000 (GMT) (envelope-from rnejdl@ringofsaturn.com) Received: from mail.ringofsaturn.com (localhost [127.0.0.1]) i7EEc7XX057978; Sat, 14 Aug 2004 09:38:09 -0500 (CDT) (envelope-from rnejdl@ringofsaturn.com) Received: from 66.13.175.242 (SquirrelMail authenticated user rnejdl); by mail.ringofsaturn.com with HTTP; Sat, 14 Aug 2004 09:38:21 -0500 (CDT) Message-ID: <56920.66.13.175.242.1092494301.squirrel@mail.ringofsaturn.com> In-Reply-To: <20040812183418.D86599@carver.gumbysoft.com> References: <200408120429.30081.michaelnottebrock@gmx.net> <20040812183418.D86599@carver.gumbysoft.com> Date: Sat, 14 Aug 2004 09:38:21 -0500 (CDT) From: "Rusty Nejdl" To: "Doug White" User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamd / ClamAV version 0.75, clamav-milter version 0.75 on tethys.ringofsaturn.com X-Virus-Status: Clean cc: freebsd-current@freebsd.org cc: rnejdl@ringofsaturn.com cc: Trent Nelson Subject: Re: Signal 11 compiling qt33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rnejdl@ringofsaturn.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2004 14:38:25 -0000 >> > > uic and dcopidl crashes are indicative of crossed thread libraries. I > know, I went through the same problem :) If you ldd them you'll see > libc_r and libpthread both getting pulled in, which is fatal. Both uic > and dcopidl pull in libqt, which will usually be the lagggard since its > using options saved by qmake, and doesn't get updated frequently enough > for it to get rebuilt during a kde/qt upgrade. > > You want to rebuild stuff in this order: > > > 1. XFree86-libraries (or the xorg equivalent) > 2. qmake (everyone forgets this -- qt uses it to get compile and link > options, including the thread library!) 3. qt33 > 4. qt dependencies (kde, etc.) > > Doug, The only comment about this is that this was a fresh install and no portupgrading or buildworld going on. I'm guessing, though, that I caught things in a state of flux, however, I have also run into cross threading issues within 5.2.1 for some reason. Anyways, I had to put this aside for a bit, but I will pick this back up next week with another clean snapshot and see where things are at. Rusty Nejdl From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 14:38:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82F8E16A4CF for ; Sat, 14 Aug 2004 14:38:46 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E5FB43D41 for ; Sat, 14 Aug 2004 14:38:46 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7EEawPS021208; Sat, 14 Aug 2004 10:36:58 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7EEavYh021205; Sat, 14 Aug 2004 10:36:57 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 14 Aug 2004 10:36:57 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Vitaly Markitantov In-Reply-To: <20040814111554.90574.qmail@web13422.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "George V.Neville-Neil" cc: current@freebsd.org Subject: Re: lnc0 in VmWare doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 14:38:46 -0000 On Sat, 14 Aug 2004, Vitaly Markitantov wrote: > I'm running -CURRENT in VmWare virtual machine. > > Since about August 07 2004 lnc0 interface doesn't work > > I see just complains about: > > lnc0: Device timeout -- Resetting > lnc0: Missed packet -- no receive buffer > > As workaround i use kernel from August 03 2004, which works perfectly > with lnc. > > I attached verbose dmesg from todays kernel. I was chatting with George Neville-Neil about what sounds like an identical problem last. Since you have both old and new kernels, could you try comparing the lnc probe lines in dmesg in the "before" and "after" scenarios, in particular looking for changes in interrupt assignment? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 15:20:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 875C316A4CE for ; Sat, 14 Aug 2004 15:20:12 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26ACF43D39 for ; Sat, 14 Aug 2004 15:20:10 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i7EGJqFG015207 for ; Sat, 14 Aug 2004 11:19:52 -0500 Date: Sat, 14 Aug 2004 11:19:52 -0500 (EST) From: Sam X-X-Sender: sah@athena To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: pccard/cbb problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 15:20:12 -0000 I have a ThinkPad 600E laptop on which I can't get the pcmcia network cards to appear with 5.*. Tried 5.2.1 stable, now -current, but no dice. Two card plugged, a wireless and a wired. I get some interesting pccard/cbb errors on boot. If anyone is currently working on this and is willing to look at my dmesg output and tell me what to do to debug, I'd appreciate it. FYI, the boot oddities are essentially: module cbb already exists! cbb/cardbus/pccard inits fine (apparently) interrupt storm on "irq10: cbb0 cbb1+" - throttled pccard/cbb reinits and each "card has no functions" Cheers, Sam From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 15:28:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC78716A4CE; Sat, 14 Aug 2004 15:28:36 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62A2943D3F; Sat, 14 Aug 2004 15:28:36 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7EFQpf4023774; Sat, 14 Aug 2004 11:26:51 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7EFQpvH023771; Sat, 14 Aug 2004 11:26:51 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 14 Aug 2004 11:26:51 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: markm@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@FreeBSD.org Subject: Summary of discussion of harvester/random locking and performance optimization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 15:28:37 -0000 CC'd current@ because it might be of more general interest; Mark and I did a phone call a few days ago to discuss how to improve the performance of entropy harvesting, which occurs along several critical paths for network performance. This was a followup to previous e-mail and other online discussion. Some of the ideas here are specific to entropy gathering, but others apply more generally. We discussed a few things, including: - Currently, the harvesting code uses several spin mutexes, including per source fifo mutex and a free list mutex. The result is four mutex operations per entropy event, two for the free list and two for the source fifo. I suggested exploring whether coalescing some of these mutexes would help lower locking overhead without negatively impacting contention/parallelism. In particular, possibly using per-fifo free lists, or just using a single spin mutex over all harvesting. - Currently, we gather all entropy we can find in the harvesting code in the entropy souce thread, subject to fairly high fifo bounds, and then "let the yarrow thread sort it out". Via e-mail and on the phone, we discussed ways to expose back pressure to the harvesting code to avoid paying the cost of harvesting if we have "adequate entropy" or if there's little demand for randomness. We discussed lockless approaches for exposing this so that a lockless read could be used by interrupt handlers, etc, to avoid the cost of locking when entropy wasn't required. I pointed at my modification to the harvest code to do a lockless check for a full fifo as an example of safe use of lockless reads for performance purposes. I don't have a useful opinion on how we decide if we have "enough" entropy, other than to note that on a busy system, we're probably awash in it and doing a lot of work for little incremental benefit, especially on high load network systems. - We discussed moving from a floating buffer model to a ring buffer that requires less synchronization, or even permits very week consistency synchronization. We didn't go into a lot of detail here, other than to observe that there are a variety of techniques that could be used to lower cost, lower synchronization, increase locality, etc. - Currently, the yarrow thread performs a lot of sequential lock operations as it iterates over the entropy fifos and releases buffers. While this happens only intermittently, it happens a fair amount over time, and the current code layout results in possibly excessive mutex use. I suggested moving to a model where entropy records are moved "en masse" to a thread local entropy queue or fifo from the global fifo between two lock operations to avoid grabbing and releasing the locks many times during processing. Likewise for the free list. Note that every spin mutex acquire disables interrupts... Our current queue(9) macros don't all lend themselves to an O(1) move of the contents of some list types from one head to another, but even O(n) would probably be an improvement. I pointed at som similar use of queues in the network code to avoid thrashing driver locks when processing multiple packets, amortizing the locking cost over multiple packets. - We discussed more generally when it is safe to not use locking, such as when we use pointer/integer size reads or writes and some staleness or inconsistency is acceptable. We also discussed that this might mean using a lockless read to decide if something might happen (subject to a race), and then re-checking once locks are acquired in order to perform a safe read-modify-write. I.e., a lockless check on fifo size to make sure there might be room, then acquire the mutex and re-read the value to make sure there really is room before adding the record. This is an optimistic concurrencyy/synchronization approacah since it optimizes based on the assumption we won't need to do the work, or that we don't need to do the work frequently enough to amortize the additional check cost given that it's lower than an occasional lock. - And to summarize a point previously discussed in e-mail: right now mbuf havesting in the ethernet input path is incorrectly harvesting from a free'd mbuf pointer. This means we're harvesting both kernel pointers instead of packet data, that we may harvest from an unmapped page due to the object being free'd, etc. We discussed in the phone call whether there was benefit to reaping there and you observed that the timing information was useful, and that the ethernet header information might still be useful if correctly reaped. I was unclear that the ethernet header information would be useful, although timing might well be (subject to cost). It's worth observing, though, that if you've already gathered entropy information from the interrupt, there is probably little incremental benefit to gathering in the ethernet input routines, especially since the time to perform incremental processing on each additional packet handled by an ethernet interrupt is likely fairly constant. - I provided some general guidance on locking: it's expensive. Right now we're far more concened about the cost of lock operations than the cost of contention, and so general guidance has been "err on the side of fewer locks now, it's easier to diagnose than too many". We have some reasonable tools for diagnosing lock use -- I pointed at MUTEX_PROFILING (although observed it's expensive) and KTR. I have information on using KTR at http://www.watson.org/~robert/freebsd/netperf/ktr/. The MUTEX_PROFILING man page is pretty decent and the results instructive. I noted that the reason I had chosen to focus some time on the entropy gathering code was that it showed up fairly clearly in interrupt handling traces from KTR, and that KTR was very helpful (if you're willing to invest the time to use it well) in getting a picture of how the system is behaving, and that my recent modifications to KTR provide a lot more useful context information than we used to have. As a follow-up, I re-read the harvesting code again after our conversation, in particular to learn about the cost of harvesting time information. I observed that get_cyclecounter() is very cheap on modern hardware, but that on older hardware without a TSC, it's extraordinarily expensive. In particular, the #ifdef code on i386 suggests that i486 systems may not have a TSC, and insead read the system clock (ouch!). We may want to investigate what approaches we can use to mitigate this, especially if systems like soekris boxes don't have TSC. Right now, the API for retrieving cycle counts does not allow the caller to easily distinguish those two cases, and it may be we need to teach it to do that so that we can allow the caller to decide it doesn't want to pay the higher cost. Finally, a question I raised by e-mail previously and think it's worth thinking about is how to decide what impact we're having on entropy quality. In particular, are there scores or other easily understood numerical or statistical results that can be exposed to a user or developer to allow them to measure the impact on entropy quality and availability resulting from specific configuration, optimization, etc. This would allow us to more easily say "X is or is not worth the performance cost", or at least, allow our users to make that choice and provide more information about when they should make that choice. This also paves the way for better auto-tuning. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 15:33:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DBE316A4CE for ; Sat, 14 Aug 2004 15:33:48 +0000 (GMT) Received: from web13425.mail.yahoo.com (web13425.mail.yahoo.com [216.136.175.156]) by mx1.FreeBSD.org (Postfix) with SMTP id 272BB43D3F for ; Sat, 14 Aug 2004 15:33:48 +0000 (GMT) (envelope-from ua_vitaly@yahoo.com) Message-ID: <20040814153348.20497.qmail@web13425.mail.yahoo.com> Received: from [80.255.64.192] by web13425.mail.yahoo.com via HTTP; Sat, 14 Aug 2004 08:33:48 PDT Date: Sat, 14 Aug 2004 08:33:48 -0700 (PDT) From: Vitaly Markitantov To: current@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-815198432-1092497628=:19037" cc: Robert Watson Subject: Re: lnc0 in VmWare doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 15:33:48 -0000 --0-815198432-1092497628=:19037 Content-Type: text/plain; charset=us-ascii Content-Id: Content-Disposition: inline --- Robert Watson wrote: > > On Sat, 14 Aug 2004, Vitaly Markitantov wrote: > > > I'm running -CURRENT in VmWare virtual machine. > > > > Since about August 07 2004 lnc0 interface doesn't work > > > > I see just complains about: > > > > lnc0: Device timeout -- Resetting > > lnc0: Missed packet -- no receive buffer > > > > As workaround i use kernel from August 03 2004, which works perfectly > > with lnc. > > > > I attached verbose dmesg from todays kernel. > > I was chatting with George Neville-Neil about what sounds like an > identical problem last. Since you have both old and new kernels, could > you try comparing the lnc probe lines in dmesg in the "before" and "after" > scenarios, in particular looking for changes in interrupt assignment? I don't see in dmesg any critical changes in interrupt assigment. I provide both dmesg here. ===== Vitaly Markitantov +38050-3530077 __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail --0-815198432-1092497628=:19037 Content-Type: text/plain; name="dmesg_old.txt" Content-Description: dmesg_old.txt Content-Disposition: inline; filename="dmesg_old.txt" Copyright (c) 1992-2004 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 5.2-CURRENT #0: Thu Aug 12 07:55:31 EEST 2004 vix@freedo2.umc.com.ua:/usr/obj/usr/src.lnc_ok/sys/FREEDO2 WARNING: Kernel preemption is disabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc06d5000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc06d52bc. Calibrating clock(s) ... i8254 clock: 1193072 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2659737568 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.66GHz (2659.74-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf28 Stepping = 8 Features=0x1febfbff real memory = 67108864 (64 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000826000 - 0x0000000003da7fff, 56107008 bytes (13698 pages) 0x0000000003f00000 - 0x0000000003ff7fff, 1015808 bytes (248 pages) avail memory = 60162048 (57 MB) bios32: Found BIOS32 Service Directory header at 0xc00f7040 bios32: Entry = 0xfd880 (c00fd880) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd880+0x120 pnpbios: Found PnP BIOS data at 0xc00f70a0 pnpbios: Entry = f0000:985d Rev = 1.0 Other BIOS signatures found: io: random: mem: CPU supports MTRRs but not enabled null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [GIANT-LOCKED] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000058 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71908086) pcibios: BIOS version 2.10 Found $PIR table, 9 entries at 0xc00fdf30 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs slot 1 0 15 A 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 15 B 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 15 C 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 15 D 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 16 A 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 16 B 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 16 C 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 16 D 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 3 0 17 A 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 3 0 17 B 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 3 0 17 C 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 3 0 17 D 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 4 0 18 A 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 4 0 18 B 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 4 0 18 C 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 4 0 18 D 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 5 0 19 A 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 5 0 19 B 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 5 0 19 C 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 5 0 19 D 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 6 0 20 A 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 6 0 20 B 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 6 0 20 C 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 6 0 20 D 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 7 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 7 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 7 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 7 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 1 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 1 B 0x61 3 4 5 6 7 9 10 11 12 14 15 AcpiOsDerivePciId: bus 0 dev 7 func 3 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi0: Power Button (fixed) AcpiOsDerivePciId: bus 0 dev 0 func 0 ACPI timer looks BAD min = 4, max = 1536, width = 1532 ACPI timer looks BAD min = 4, max = 643, width = 639 ACPI timer looks BAD min = 4, max = 199, width = 195 ACPI timer looks BAD min = 4, max = 8410, width = 8406 ACPI timer looks BAD min = 4, max = 1098, width = 1094 ACPI timer looks BAD min = 4, max = 272, width = 268 ACPI timer looks BAD min = 4, max = 8099, width = 8095 ACPI timer looks BAD min = 4, max = 142, width = 138 ACPI timer looks BAD min = 4, max = 852, width = 848 ACPI timer looks BAD min = 2, max = 9415, width = 9413 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.15.0 \\_SB_.PCI0.ISA_.LNKB irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.15.1 \\_SB_.PCI0.ISA_.LNKC irq 11: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.15.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.15.3 \\_SB_.PCI0.ISA_.LNKB irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.16.0 \\_SB_.PCI0.ISA_.LNKC irq 11: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.16.1 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.16.2 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.16.3 \\_SB_.PCI0.ISA_.LNKC irq 11: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.17.0 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.17.1 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.17.2 \\_SB_.PCI0.ISA_.LNKB irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.17.3 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.18.0 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.18.1 \\_SB_.PCI0.ISA_.LNKB irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.18.2 \\_SB_.PCI0.ISA_.LNKC irq 11: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.18.3 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.19.0 \\_SB_.PCI0.ISA_.LNKB irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.19.1 \\_SB_.PCI0.ISA_.LNKC irq 11: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.19.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.19.3 \\_SB_.PCI0.ISA_.LNKB irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.20.0 \\_SB_.PCI0.ISA_.LNKC irq 11: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.20.1 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.20.2 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.20.3 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.7.0 \\_SB_.PCI0.ISA_.LNKB irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.7.1 \\_SB_.PCI0.ISA_.LNKC irq 11: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.7.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.7.3 ACPI PCI link before setting link priority: \\_SB_.PCI0.ISA_.LNKA: interrupts: 3 4 5 6 7 9 10 11 14 15 penalty: 1070 1070 70 1070 1070 2170 70 770 10070 10070 references: 7 priority: 0 ACPI PCI link before fixup for boot-disabled links: \\_SB_.PCI0.ISA_.LNKA: interrupts: 3 4 5 6 7 9 10 11 14 15 penalty: 1070 1070 70 1070 1070 2170 70 770 10070 10070 references: 7 priority: 19250 ACPI PCI link after fixup for boot-disabled links: ACPI PCI link arbitrated configuration: \\_SB_.PCI0.ISA_.LNKA irq 10: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.15.0 \\_SB_.PCI0.ISA_.LNKB irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.15.1 \\_SB_.PCI0.ISA_.LNKC irq 11: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.15.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.15.3 \\_SB_.PCI0.ISA_.LNKB irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.16.0 \\_SB_.PCI0.ISA_.LNKC irq 11: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.16.1 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.16.2 \\_SB_.PCI0.ISA_.LNKA irq 10: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.16.3 \\_SB_.PCI0.ISA_.LNKC irq 11: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.17.0 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.17.1 \\_SB_.PCI0.ISA_.LNKA irq 10: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.17.2 \\_SB_.PCI0.ISA_.LNKB irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.17.3 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.18.0 \\_SB_.PCI0.ISA_.LNKA irq 10: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.18.1 \\_SB_.PCI0.ISA_.LNKB irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.18.2 \\_SB_.PCI0.ISA_.LNKC irq 11: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.18.3 \\_SB_.PCI0.ISA_.LNKA irq 10: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.19.0 \\_SB_.PCI0.ISA_.LNKB irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.19.1 \\_SB_.PCI0.ISA_.LNKC irq 11: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.19.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.19.3 \\_SB_.PCI0.ISA_.LNKB irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.20.0 \\_SB_.PCI0.ISA_.LNKC irq 11: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.20.1 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.20.2 \\_SB_.PCI0.ISA_.LNKA irq 10: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.20.3 \\_SB_.PCI0.ISA_.LNKA irq 10: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.7.0 \\_SB_.PCI0.ISA_.LNKB irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.7.1 \\_SB_.PCI0.ISA_.LNKC irq 11: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.7.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.7.3 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base f8000000, size 26, enabled found-> vendor=0x8086, dev=0x7190, revid=0x01 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7191, revid=0x01 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0000, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x80 (32000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7110, revid=0x08 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 00001050, size 4, port disabled found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=7, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 00001060, size 5, enabled pcib0: matched entry for 0.7.INTD (src \\_SB_.PCI0.ISA_.LNKD) pcib0: slot 7 INTD is routed to irq 9 found-> vendor=0x8086, dev=0x7112, revid=0x00 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=9 map[90]: type 4, range 32, base 00001040, size 4, enabled found-> vendor=0x8086, dev=0x7113, revid=0x08 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 00001080, size 4, enabled map[14]: type 1, range 32, base fd000000, size 24, enabled map[18]: type 1, range 32, base fc000000, size 24, enabled found-> vendor=0x15ad, dev=0x0405, revid=0x00 bus=0, slot=15, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 00001400, size 7, enabled map[14]: type 1, range 32, base fe000000, size 12, enabled pcib0: matched entry for 0.16.INTA (src \\_SB_.PCI0.ISA_.LNKB) pcib0: slot 16 INTA is routed to irq 9 found-> vendor=0x1000, dev=0x0030, revid=0x01 bus=0, slot=16, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x06 (1500 ns), maxlat=0xff (63750 ns) intpin=a, irq=9 map[10]: type 4, range 32, base 00001480, size 7, enabled pcib0: matched entry for 0.17.INTA (src \\_SB_.PCI0.ISA_.LNKC) pcib0: slot 17 INTA is routed to irq 11 found-> vendor=0x1022, dev=0x2000, revid=0x10 bus=0, slot=17, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x06 (1500 ns), maxlat=0xff (63750 ns) intpin=a, irq=11 pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: memory decode 0x0-0x0 pcib1: prefetched decode 0x0-0x0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND pci1: on pcib1 pci1: physical bus=1 isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 7.1 (no driver attached) uhci0: port 0x1060-0x107f irq 9 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1060 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) pci0: at device 15.0 (no driver attached) mpt0: port 0x1400-0x147f mem 0xfe000000-0xfe000fff irq 9 at device 16.0 on pci0 mpt0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xfe000000 mpt0: [GIANT-LOCKED] mpt0: soft reset lnc0: port 0x1480-0x14ff irq 11 at device 17.0 on pci0 lnc0: Attaching PCNet/PCI Ethernet adapter lnc0: Reserved 0x80 bytes for rid 0x10 type 4 at 0x1480 lnc0: [GIANT-LOCKED] lnc0: bpf attached lnc0: Ethernet address: 00:0c:29:90:ee:85 lnc0: PCnet-PCI atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0 irq 12 on acpi0 psm0: current command byte:0047 psm0: failed to get data. psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000000, packet size:4 psm0: syncmask:00, syncbits:00 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: irq maps: 0x1 0x1 0x1 0x1 sio1: probe failed test(s): 0 1 2 4 6 7 9 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) sio1: irq maps: 0x1 0x1 0x1 0x1 sio1: probe failed test(s): 0 1 2 4 6 7 9 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) atkbdc: atkbdc0 already exists; skipping it lnc: lnc0 already exists; skipping it sc: sc0 already exists; skipping it sio: sio0 already exists; skipping it vga: vga0 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xe4000-0xe7fff,0xdc000-0xdffff,0xca000-0xcafff,0xc0000-0xc7fff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 05 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) ata0 failed to probe at port 0x1f0 irq 14 on isa0 ata1 failed to probe at port 0x170 irq 15 on isa0 bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x1 0x1 0x1 0x1 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Timecounter "TSC" frequency 2659737568 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached Waiting 15 seconds for SCSI devices to settle cpu0: set speed to 100.0% acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% (probe0:mpt0:0:0:0): error 22 (probe0:mpt0:0:0:0): Unretryable Error (probe1:mpt0:0:1:0): error 22 (probe1:mpt0:0:1:0): Unretryable Error (probe0:mpt0:0:0:1): error 22 (probe0:mpt0:0:0:1): Unretryable Error (probe0:mpt0:0:1:1): error 22 (probe0:mpt0:0:1:1): Unretryable Error (probe1:mpt0:0:0:2): error 22 (probe1:mpt0:0:0:2): Unretryable Error (probe0:mpt0:0:1:2): error 22 (probe0:mpt0:0:1:2): Unretryable Error (probe1:mpt0:0:0:3): error 22 (probe1:mpt0:0:0:3): Unretryable Error (probe0:mpt0:0:1:3): error 22 (probe0:mpt0:0:1:3): Unretryable Error (probe1:mpt0:0:0:4): error 22 (probe1:mpt0:0:0:4): Unretryable Error (probe0:mpt0:0:1:4): error 22 (probe0:mpt0:0:1:4): Unretryable Error (probe1:mpt0:0:0:5): error 22 (probe1:mpt0:0:0:5): Unretryable Error (probe0:mpt0:0:1:5): error 22 (probe0:mpt0:0:1:5): Unretryable Error (probe1:mpt0:0:0:6): error 22 (probe1:mpt0:0:0:6): Unretryable Error (probe0:mpt0:0:1:6): error 22 (probe0:mpt0:0:1:6): Unretryable Error (probe1:mpt0:0:0:7): error 22 (probe1:mpt0:0:0:7): Unretryable Error (probe0:mpt0:0:1:7): error 22 (probe0:mpt0:0:1:7): Unretryable Error pass0 at mpt0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-2 device pass0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled pass1 at mpt0 bus 0 target 1 lun 0 pass1: Removable CD-ROM SCSI-2 device pass1: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled cd0 at mpt0 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled cd0: cd present [121808 x 2048 byte records] da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled da0: 4096MB (8388608 512 byte sectors: 255H 63S/T 522C) GEOM: new disk cd0 GEOM: new disk da0 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):521/254/63 s:63 l:8385867 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure da0s1, start 32256 length 4293563904 end 4293596159 GEOM: Configure da0s1a, start 0 length 134217728 end 134217727 GEOM: Configure da0s1b, start 134217728 length 134217728 end 268435455 GEOM: Configure da0s1c, start 0 length 4293563904 end 4293563903 GEOM: Configure da0s1d, start 268435456 length 4025128448 end 4293563903 Mounting root from ufs:/dev/da0s1a start_init: trying /sbin/init lnc0: Device timeout -- Resetting --0-815198432-1092497628=:19037 Content-Type: text/plain; name="dmesg_new.txt" Content-Description: dmesg_new.txt Content-Disposition: inline; filename="dmesg_new.txt" Copyright (c) 1992-2004 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 5.2-CURRENT #0: Sat Aug 14 13:25:22 EEST 2004 root@freedo2.umc.com.ua:/usr/obj/usr/src/sys/FREEDO2 Preloaded elf kernel "/boot/kernel/kernel" at 0xc06e2000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc06e22bc. Calibrating clock(s) ... i8254 clock: 1160396 Hz 1160396 Hz differs from default of 1193182 Hz by more than 1% Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2739574621 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.66GHz (2739.57-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf28 Stepping = 8 Features=0x1febfbff real memory = 67108864 (64 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000826000 - 0x0000000003da7fff, 56107008 bytes (13698 pages) 0x0000000003f00000 - 0x0000000003ff7fff, 1015808 bytes (248 pages) avail memory = 60170240 (57 MB) bios32: Found BIOS32 Service Directory header at 0xc00f7040 bios32: Entry = 0xfd880 (c00fd880) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd880+0x120 pnpbios: Found PnP BIOS data at 0xc00f70a0 pnpbios: Entry = f0000:985d Rev = 1.0 Other BIOS signatures found: null: mem: CPU supports MTRRs but not enabled random: io: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000058 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71908086) pcibios: BIOS version 2.10 Found $PIR table, 9 entries at 0xc00fdf30 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs slot 1 0 15 A 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 15 B 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 15 C 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 1 0 15 D 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 16 A 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 16 B 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 16 C 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 2 0 16 D 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 3 0 17 A 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 3 0 17 B 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 3 0 17 C 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 3 0 17 D 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 4 0 18 A 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 4 0 18 B 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 4 0 18 C 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 4 0 18 D 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 5 0 19 A 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 5 0 19 B 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 5 0 19 C 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 5 0 19 D 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 6 0 20 A 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 6 0 20 B 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 6 0 20 C 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 6 0 20 D 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 7 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 7 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 7 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 7 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 1 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 1 B 0x61 3 4 5 6 7 9 10 11 12 14 15 AcpiOsDerivePciId: bus 0 dev 7 func 3 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi0: Power Button (fixed) AcpiOsDerivePciId: bus 0 dev 0 func 0 ACPI timer looks BAD min = 2, max = 457, width = 455 ACPI timer looks BAD min = 4, max = 512, width = 508 ACPI timer looks BAD min = 4, max = 1119, width = 1115 ACPI timer looks BAD min = 1, max = 284, width = 283 ACPI timer looks BAD min = 4, max = 192, width = 188 ACPI timer looks BAD min = 4, max = 1219, width = 1215 ACPI timer looks BAD min = 4, max = 156, width = 152 ACPI timer looks BAD min = 4, max = 159, width = 155 ACPI timer looks BAD min = 4, max = 13620, width = 13616 ACPI timer looks BAD min = 4, max = 249, width = 245 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] 0+ low,level,sharable 0.15.0 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.15.1 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 14 15] 11+ low,level,sharable 0.15.2 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.15.3 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.16.0 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 14 15] 11+ low,level,sharable 0.16.1 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.16.2 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] 0+ low,level,sharable 0.16.3 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 14 15] 11+ low,level,sharable 0.17.0 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.17.1 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] 0+ low,level,sharable 0.17.2 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.17.3 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.18.0 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] 0+ low,level,sharable 0.18.1 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.18.2 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 14 15] 11+ low,level,sharable 0.18.3 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] 0+ low,level,sharable 0.19.0 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.19.1 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 14 15] 11+ low,level,sharable 0.19.2 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.19.3 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.20.0 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 14 15] 11+ low,level,sharable 0.20.1 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.20.2 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] 0+ low,level,sharable 0.20.3 \\_SB_.PCI0.ISA_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 14 15] 0+ low,level,sharable 0.7.0 \\_SB_.PCI0.ISA_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.7.1 \\_SB_.PCI0.ISA_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 14 15] 11+ low,level,sharable 0.7.2 \\_SB_.PCI0.ISA_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 14 15] 9+ low,level,sharable 0.7.3 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base f8000000, size 26, enabled found-> vendor=0x8086, dev=0x7190, revid=0x01 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7191, revid=0x01 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0000, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x80 (32000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7110, revid=0x08 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 00001050, size 4, port disabled found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=7, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 00001060, size 5, enabled pcib0: matched entry for 0.7.INTD (src \\_SB_.PCI0.ISA_.LNKD) pcib0: possible interrupts: 3 4 5 6 7 9 10 11 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.ISA_.LNKA (references 7, priority 86191): interrupts: 11 10 5 9 7 6 4 3 15 14 penalty: 280 280 330 560 5280 5280 5280 5280 50280 50280 \\_SB_.PCI0.ISA_.LNKB (references 7, priority 86191): interrupts: 11 10 5 9 7 6 4 3 15 14 penalty: 280 280 330 560 5280 5280 5280 5280 50280 50280 \\_SB_.PCI0.ISA_.LNKC (references 7, priority 86191): interrupts: 11 10 5 9 7 6 4 3 15 14 penalty: 280 280 330 560 5280 5280 5280 5280 50280 50280 \\_SB_.PCI0.ISA_.LNKD (references 7, priority 86191): interrupts: 11 10 5 9 7 6 4 3 15 14 penalty: 280 280 330 560 5280 5280 5280 5280 50280 50280 pcib0: slot 7 INTD routed to irq 9 via \\_SB_.PCI0.ISA_.LNKD found-> vendor=0x8086, dev=0x7112, revid=0x00 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=9 map[90]: type 4, range 32, base 00001040, size 4, enabled found-> vendor=0x8086, dev=0x7113, revid=0x08 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 00001080, size 4, enabled map[14]: type 1, range 32, base fd000000, size 24, enabled map[18]: type 1, range 32, base fc000000, size 24, enabled found-> vendor=0x15ad, dev=0x0405, revid=0x00 bus=0, slot=15, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 00001400, size 7, enabled map[14]: type 1, range 32, base fe000000, size 12, enabled pcib0: matched entry for 0.16.INTA (src \\_SB_.PCI0.ISA_.LNKB) pcib0: possible interrupts: 3 4 5 6 7 9 10 11 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.ISA_.LNKA (references 7, priority 88396): interrupts: 11 10 5 9 7 6 4 3 15 14 penalty: 560 560 610 1190 5560 5560 5560 5560 50560 50560 \\_SB_.PCI0.ISA_.LNKB (references 7, priority 88396): interrupts: 11 10 5 9 7 6 4 3 15 14 penalty: 560 560 610 1190 5560 5560 5560 5560 50560 50560 \\_SB_.PCI0.ISA_.LNKC (references 7, priority 88396): interrupts: 11 10 5 9 7 6 4 3 15 14 penalty: 560 560 610 1190 5560 5560 5560 5560 50560 50560 pcib0: slot 16 INTA routed to irq 9 via \\_SB_.PCI0.ISA_.LNKB found-> vendor=0x1000, dev=0x0030, revid=0x01 bus=0, slot=16, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x06 (1500 ns), maxlat=0xff (63750 ns) intpin=a, irq=9 map[10]: type 4, range 32, base 00001480, size 7, enabled pcib0: matched entry for 0.17.INTA (src \\_SB_.PCI0.ISA_.LNKC) pcib0: possible interrupts: 3 4 5 6 7 9 10 11 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.ISA_.LNKA (references 7, priority 90601): interrupts: 11 10 5 9 7 6 4 3 15 14 penalty: 840 840 890 1820 5840 5840 5840 5840 50840 50840 \\_SB_.PCI0.ISA_.LNKC (references 7, priority 90601): interrupts: 11 10 5 9 7 6 4 3 15 14 penalty: 840 840 890 1820 5840 5840 5840 5840 50840 50840 pcib0: slot 17 INTA routed to irq 11 via \\_SB_.PCI0.ISA_.LNKC found-> vendor=0x1022, dev=0x2000, revid=0x10 bus=0, slot=17, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x06 (1500 ns), maxlat=0xff (63750 ns) intpin=a, irq=11 pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: memory decode 0x0-0x0 pcib1: prefetched decode 0x0-0x0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND pci1: on pcib1 pci1: physical bus=1 isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 7.1 (no driver attached) uhci0: port 0x1060-0x107f irq 9 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1060 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) pci0: at device 15.0 (no driver attached) mpt0: port 0x1400-0x147f mem 0xfe000000-0xfe000fff irq 9 at device 16.0 on pci0 mpt0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xfe000000 mpt0: [GIANT-LOCKED] mpt0: soft reset lnc0: port 0x1480-0x14ff irq 11 at device 17.0 on pci0 lnc0: Attaching PCNet/PCI Ethernet adapter lnc0: Reserved 0x80 bytes for rid 0x10 type 4 at 0x1480 lnc0: [GIANT-LOCKED] lnc0: bpf attached lnc0: Ethernet address: 00:0c:29:90:ee:85 lnc0: PCnet-PCI atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0 irq 12 on acpi0 psm0: current command byte:0047 psm0: failed to get data. psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000000, packet size:4 psm0: syncmask:00, syncbits:00 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: irq maps: 0x1 0x1 0x1 0x1 sio1: probe failed test(s): 0 1 2 4 6 7 9 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) sio1: irq maps: 0x1 0x1 0x1 0x1 sio1: probe failed test(s): 0 1 2 4 6 7 9 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) atkbdc: atkbdc0 already exists; skipping it lnc: lnc0 already exists; skipping it sio: sio0 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xe4000-0xe7fff,0xdc000-0xdffff,0xca000-0xcafff,0xc0000-0xc7fff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) ata0 failed to probe at port 0x1f0 irq 14 on isa0 ata1 failed to probe at port 0x170 irq 15 on isa0 bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x1 0x1 0x1 0x1 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 05 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Timecounter "TSC" frequency 2739574621 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached Waiting 15 seconds for SCSI devices to settle cpu0: set speed to 100.0% acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% (probe0:mpt0:0:0:0): error 22 (probe0:mpt0:0:0:0): Unretryable Error (probe1:mpt0:0:1:0): error 22 (probe1:mpt0:0:1:0): Unretryable Error (probe0:mpt0:0:0:1): error 22 (probe0:mpt0:0:0:1): Unretryable Error (probe0:mpt0:0:1:1): error 22 (probe0:mpt0:0:1:1): Unretryable Error (probe1:mpt0:0:0:2): error 22 (probe1:mpt0:0:0:2): Unretryable Error (probe0:mpt0:0:1:2): error 22 (probe0:mpt0:0:1:2): Unretryable Error (probe1:mpt0:0:0:3): error 22 (probe1:mpt0:0:0:3): Unretryable Error (probe0:mpt0:0:1:3): error 22 (probe0:mpt0:0:1:3): Unretryable Error (probe1:mpt0:0:0:4): error 22 (probe1:mpt0:0:0:4): Unretryable Error (probe0:mpt0:0:1:4): error 22 (probe0:mpt0:0:1:4): Unretryable Error (probe1:mpt0:0:0:5): error 22 (probe1:mpt0:0:0:5): Unretryable Error (probe0:mpt0:0:1:5): error 22 (probe0:mpt0:0:1:5): Unretryable Error (probe1:mpt0:0:0:6): error 22 (probe1:mpt0:0:0:6): Unretryable Error (probe0:mpt0:0:1:6): error 22 (probe0:mpt0:0:1:6): Unretryable Error (probe1:mpt0:0:0:7): error 22 (probe1:mpt0:0:0:7): Unretryable Error (probe0:mpt0:0:1:7): error 22 (probe0:mpt0:0:1:7): Unretryable Error pass0 at mpt0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-2 device pass0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled pass1 at mpt0 bus 0 target 1 lun 0 pass1: Removable CD-ROM SCSI-2 device pass1: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled da0: 4096MB (8388608 512 byte sectors: 255H 63S/T 522C) cd0 at mpt0 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled cd0: cd present [121808 x 2048 byte records] GEOM: new disk da0 GEOM: new disk cd0 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):521/254/63 s:63 l:8385867 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure da0s1, start 32256 length 4293563904 end 4293596159 GEOM: Configure da0s1a, start 0 length 134217728 end 134217727 GEOM: Configure da0s1b, start 134217728 length 134217728 end 268435455 GEOM: Configure da0s1c, start 0 length 4293563904 end 4293563903 GEOM: Configure da0s1d, start 268435456 length 4025128448 end 4293563903 Mounting root from ufs:/dev/da0s1a start_init: trying /sbin/init lnc0: Device timeout -- Resetting lnc0: Device timeout -- Resetting lnc0: Device timeout -- Resetting --0-815198432-1092497628=:19037-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 16:11:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9544516A4CE for ; Sat, 14 Aug 2004 16:11:06 +0000 (GMT) Received: from mwinf0302.wanadoo.fr (smtp3.wanadoo.fr [193.252.22.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D66B43D1D for ; Sat, 14 Aug 2004 16:11:06 +0000 (GMT) (envelope-from dak@wanadoo.fr) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0302.wanadoo.fr (SMTP Server) with SMTP id D7DB3C0002B3; Sat, 14 Aug 2004 18:11:04 +0200 (CEST) Received: from smtp.wanadoo.fr (ca-sqy-2-32.w80-8.abo.wanadoo.fr [80.8.55.32]) by mwinf0302.wanadoo.fr (SMTP Server) with ESMTP id 9438BC00028E; Sat, 14 Aug 2004 18:11:04 +0200 (CEST) Received: from nebula.wanadoo.fr (localhost [127.0.0.1]) by smtp.wanadoo.fr (8.13.1/8.13.1) with ESMTP id i7EGB4uE001141; Sat, 14 Aug 2004 18:11:04 +0200 (CEST) (envelope-from dak@nebula.wanadoo.fr) Received: (from dak@localhost) by nebula.wanadoo.fr (8.13.1/8.13.1/Submit) id i7EGB334001140; Sat, 14 Aug 2004 18:11:03 +0200 (CEST) (envelope-from dak) Date: Sat, 14 Aug 2004 18:11:03 +0200 From: Aurelien Nephtali To: Maxim Maximov Message-ID: <20040814161103.GB984@nebula.wanadoo.fr> References: <411E17FB.7070603@mcsi.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <411E17FB.7070603@mcsi.pp.ru> User-Agent: Mutt/1.5.6i cc: current@freebsd.org Subject: Re: module cbb already present X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 16:11:06 -0000 Hi, I have the same line but my system works fine with or without WITNESS enabled. On Sat, Aug 14, 2004 at 05:47:39PM +0400, Maxim Maximov wrote: > Hello. > > In todays kernel there is some message which doesn't present on Aug > 9 kernel (marked with empty lines). My kernel config didn't change. > /boot/loader.conf is empty. > > Copyright (c) 1992-2004 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 5.2-CURRENT #0: Sat Aug 14 12:05:18 MSD 2004 > mcsi@ultra.domain:/usr/obj/usr/src/sys/ULTRA > WARNING: WITNESS option enabled, expect reduced performance. > > module cbb already present! > > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.52-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > > Features=0xbfebfbff > Hyperthreading: 2 logical CPUs > real memory = 536674304 (511 MB) > avail memory = 514506752 (490 MB) > ACPI APIC Table: > > Also this kernel stops after 'Pre-seeding PRNG:' message and stops > until I enter DDB. I can press any keys and they are displayed at the > screen. Ctrl-C doesn't work. I dont have a console at the moment, I will > post output of DDB trace, show threads, show locks and ps in monday. I > wonder if anyone else see this? > It goes fine into single user mode. When I exit single user shell, > it boots fine. > Witness enabled, preemption disabled, htt enabled, SMP kernel, ACPI > enabled (when disabled, it panics at boot btw), cleanworld before > buildworld, debug.mpsafenet=0 or 1, it doesn't matter on this subject. > > -- > Maxim Maximov > > _______________________________________________ > 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" -- NEPHTALI 'dak' Aurelien TEK1 - Promo 2008 From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 16:49:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A76D16A4CE for ; Sat, 14 Aug 2004 16:49:11 +0000 (GMT) Received: from web14824.mail.yahoo.com (web14824.mail.yahoo.com [216.136.225.195]) by mx1.FreeBSD.org (Postfix) with SMTP id 2422A43D1D for ; Sat, 14 Aug 2004 16:49:11 +0000 (GMT) (envelope-from rosti_bsd@yahoo.com) Message-ID: <20040814164911.85635.qmail@web14824.mail.yahoo.com> Received: from [212.143.154.227] by web14824.mail.yahoo.com via HTTP; Sat, 14 Aug 2004 09:49:11 PDT Date: Sat, 14 Aug 2004 09:49:11 -0700 (PDT) From: Rostislav Krasny To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Fatal trap after 'devinfo -v' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 16:49:11 -0000 Hello all. During my conversation on freebsd-arch about different subject I've found following problem at 5.2-CURRENT (copy/paste): I think I've found a bug in devinfo(8). Try following scenario on your system: 1. log in as a root and make sure that 'speaker.ko' isn't loaded automatically during boot 2. run 'kldload -v /boot/kernel/speaker.ko' 3. run 'kldunload speaker' 4. run 'devinfo -v' After the last step I've got following on the console: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc17429b7 fault code = supervisor read, page not present instruction pointer = 0x8:0xc06597f0 stack pointer = 0x10:0x857da18 frame pointer = 0x10:0x857da24 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 492 (devinfo) [thread 100059] Stopped at strlcpy+0x1c: movb 0(%edx),%al db> trace strlcpy(c857da60,c17429b7,20) at strlcpy+0x1c sysctl_devices(c084d9c0,c857dc90,2,c857dc08,c084d9c0) at sysctl_devices()+0xb8 sysctl_root(0,c857dc84,5,c857dc08,c146e580) at sysctl_root()+0x11b userland_sysctl(c146e580,c857dc84,5,bfbfeaf0,bfbfea50) at userland_sysctl()+0xec __sysctl(c146e580,c857dd14,6,9,292) at __sysctl()+0x71 syscall(2f,2f,2f,5,bfbfea50) at syscall()+0x217 Xint80_syscall() at Xint80_syscall()+0x1f --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x280c3723, esp = 0xbfbfe9dc, ebp = 0xbfbfea18 --- db> __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 16:56:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DF9D16A4CE for ; Sat, 14 Aug 2004 16:56:15 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 791A343D1D for ; Sat, 14 Aug 2004 16:56:15 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) i7EGtCr2036742; Sat, 14 Aug 2004 09:55:12 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (h234.neville-neil.com [209.157.133.234] (may be forged)) by mail.meer.net (8.12.10/8.12.2/meer) with ESMTP id i7EGtBDr041838; Sat, 14 Aug 2004 09:55:11 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Sat, 14 Aug 2004 09:55:11 -0700 Message-ID: From: "George V. Neville-Neil" To: Vitaly Markitantov In-Reply-To: <20040814153348.20497.qmail@web13425.mail.yahoo.com> References: <20040814153348.20497.qmail@web13425.mail.yahoo.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: current@freebsd.org Subject: Re: lnc0 in VmWare doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 16:56:15 -0000 At Sat, 14 Aug 2004 08:33:48 -0700 (PDT), Vitaly Markitantov wrote: > > [1 ] > --- Robert Watson wrote: > > > > > On Sat, 14 Aug 2004, Vitaly Markitantov wrote: > > > > > I'm running -CURRENT in VmWare virtual machine. > > > > > > Since about August 07 2004 lnc0 interface doesn't work > > > > > > I see just complains about: > > > > > > lnc0: Device timeout -- Resetting > > > lnc0: Missed packet -- no receive buffer > > > > > > As workaround i use kernel from August 03 2004, which works perfectly > > > with lnc. > > > > > > I attached verbose dmesg from todays kernel. > > > > I was chatting with George Neville-Neil about what sounds like an > > identical problem last. Since you have both old and new kernels, could > > you try comparing the lnc probe lines in dmesg in the "before" and "after" > > scenarios, in particular looking for changes in interrupt assignment? > > I don't see in dmesg any critical changes in interrupt assigment. > I provide both dmesg here. I do note that the ACPI stuff is MPSAFE in one of the dmesg'd and GIANT LOCKED in the other in the files you sent. I can't get any files off of my system because without lnc0 it has no network. I can only get in on the vmware console. Later, George From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 17:00:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D37A616A4CE for ; Sat, 14 Aug 2004 17:00:31 +0000 (GMT) Received: from web13424.mail.yahoo.com (web13424.mail.yahoo.com [216.136.175.155]) by mx1.FreeBSD.org (Postfix) with SMTP id A674E43D2F for ; Sat, 14 Aug 2004 17:00:31 +0000 (GMT) (envelope-from ua_vitaly@yahoo.com) Message-ID: <20040814170031.49177.qmail@web13424.mail.yahoo.com> Received: from [80.255.64.192] by web13424.mail.yahoo.com via HTTP; Sat, 14 Aug 2004 10:00:31 PDT Date: Sat, 14 Aug 2004 10:00:31 -0700 (PDT) From: Vitaly Markitantov To: current@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: lnc0 in VmWare doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 17:00:31 -0000 --- "George V. Neville-Neil" wrote: > At Sat, 14 Aug 2004 08:33:48 -0700 (PDT), > Vitaly Markitantov wrote: > > > > [1 ] > > --- Robert Watson wrote: > > > > > > > > On Sat, 14 Aug 2004, Vitaly Markitantov wrote: > > > > > > > I'm running -CURRENT in VmWare virtual machine. > > > > > > > > Since about August 07 2004 lnc0 interface doesn't work > > > > > > > > I see just complains about: > > > > > > > > lnc0: Device timeout -- Resetting > > > > lnc0: Missed packet -- no receive buffer > > > > > > > > As workaround i use kernel from August 03 2004, which works perfectly > > > > with lnc. > > > > > > > > I attached verbose dmesg from todays kernel. > > > > > > I was chatting with George Neville-Neil about what sounds like an > > > identical problem last. Since you have both old and new kernels, could > > > you try comparing the lnc probe lines in dmesg in the "before" and > "after" > > > scenarios, in particular looking for changes in interrupt assignment? > > > > I don't see in dmesg any critical changes in interrupt assigment. > > I provide both dmesg here. > > I do note that the ACPI stuff is MPSAFE in one of the dmesg'd and > GIANT LOCKED in the other in the files you sent. > > I can't get any files off of my system because without lnc0 it has no > network. I can only get in on the vmware console. I use for this purpose USB-flash drive. But turning off ACPI does nothing for this problem. lnc0 still doesn't work without ACPI too. ===== Vitaly Markitantov +38050-3530077 __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 17:30:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7ECAE16A4CE for ; Sat, 14 Aug 2004 17:30:37 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38C4143D45 for ; Sat, 14 Aug 2004 17:30:37 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7EHSqIU026809; Sat, 14 Aug 2004 13:28:52 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7EHSqoc026806; Sat, 14 Aug 2004 13:28:52 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 14 Aug 2004 13:28:52 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Vitaly Markitantov In-Reply-To: <20040814170031.49177.qmail@web13424.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: lnc0 in VmWare doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 17:30:37 -0000 On Sat, 14 Aug 2004, Vitaly Markitantov wrote: > > I can't get any files off of my system because without lnc0 it has no > > network. I can only get in on the vmware console. > > I use for this purpose USB-flash drive. > > But turning off ACPI does nothing for this problem. lnc0 still doesn't > work without ACPI too. I did make a change yesterday to add IFF_NEEDSGIANT to the ifnet flags of the interface. Theory suggests this should't be the problem (especially if you're not running with debug.mpsafenet=1), but practice is generally more relevant :-). Is it possible for you to check to see if the before/after versions of that change to see if that's the cause? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 17:57:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C4E916A4CE for ; Sat, 14 Aug 2004 17:57:25 +0000 (GMT) Received: from web13422.mail.yahoo.com (web13422.mail.yahoo.com [216.136.175.132]) by mx1.FreeBSD.org (Postfix) with SMTP id DACF943D49 for ; Sat, 14 Aug 2004 17:57:24 +0000 (GMT) (envelope-from ua_vitaly@yahoo.com) Message-ID: <20040814175724.50404.qmail@web13422.mail.yahoo.com> Received: from [80.255.64.192] by web13422.mail.yahoo.com via HTTP; Sat, 14 Aug 2004 10:57:24 PDT Date: Sat, 14 Aug 2004 10:57:24 -0700 (PDT) From: Vitaly Markitantov To: current@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: rwatson@freebsd.org Subject: Re: lnc0 in VmWare doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 17:57:25 -0000 --- Robert Watson wrote: > > On Sat, 14 Aug 2004, Vitaly Markitantov wrote: > > > > I can't get any files off of my system because without lnc0 it has no > > > network. I can only get in on the vmware console. > > > > I use for this purpose USB-flash drive. > > > > But turning off ACPI does nothing for this problem. lnc0 still doesn't > > work without ACPI too. > > I did make a change yesterday to add IFF_NEEDSGIANT to the ifnet flags of > the interface. Theory suggests this should't be the problem (especially > if you're not running with debug.mpsafenet=1), but practice is generally > more relevant :-). Is it possible for you to check to see if the > before/after versions of that change to see if that's the cause? I will try tomorrow, but i saw problem with lnc0 before yesterdays changes. I think problems appeared around August 04-07. ===== Vitaly Markitantov +38050-3530077 __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 17:59:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BBA816A4CE for ; Sat, 14 Aug 2004 17:59:14 +0000 (GMT) Received: from sasami.jurai.net (sasami.jurai.net [69.17.104.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1238C43D3F for ; Sat, 14 Aug 2004 17:59:14 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [69.17.104.113]) by sasami.jurai.net (8.12.11/8.12.11) with ESMTP id i7EHxDhg061860; Sat, 14 Aug 2004 13:59:13 -0400 (EDT) (envelope-from mdodd@FreeBSD.ORG) Date: Sat, 14 Aug 2004 13:59:13 -0400 (EDT) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: Sam In-Reply-To: Message-ID: <20040814135719.Y99160@sasami.jurai.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@FreeBSD.ORG Subject: Re: pccard/cbb problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 17:59:14 -0000 On Sat, 14 Aug 2004, Sam wrote: > I have a ThinkPad 600E laptop on which I can't get the > pcmcia network cards to appear with 5.*. Tried 5.2.1 > stable, now -current, but no dice. I've been running -CURRENT on my 600E for as long as I've owned it (2+ years). I've seen some issues with bottom card visability when the top card is installed but inserting bottom, then top allows both cards to work. I'm running without ACPI (using APM) and have: hw.cbb.start_memory="0x20000000" hw.pci.allow_unsupported_io_range="1" In my /boot/device.hints -- 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 18:08:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3A9C16A4CE for ; Sat, 14 Aug 2004 18:08:59 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 938A643D3F for ; Sat, 14 Aug 2004 18:08:59 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) i7EI83rC037594; Sat, 14 Aug 2004 11:08:07 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (h234.neville-neil.com [209.157.133.234] (may be forged)) by mail.meer.net (8.12.10/8.12.2/meer) with ESMTP id i7EI7vDr050241; Sat, 14 Aug 2004 11:07:58 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Sat, 14 Aug 2004 11:07:58 -0700 Message-ID: From: "George V. Neville-Neil" To: Vitaly Markitantov In-Reply-To: <20040814175724.50404.qmail@web13422.mail.yahoo.com> References: <20040814175724.50404.qmail@web13422.mail.yahoo.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: current@freebsd.org Subject: Re: lnc0 in VmWare doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 18:08:59 -0000 At Sat, 14 Aug 2004 10:57:24 -0700 (PDT), Vitaly Markitantov wrote: > > > --- Robert Watson wrote: > > > > > On Sat, 14 Aug 2004, Vitaly Markitantov wrote: > > > > > > I can't get any files off of my system because without lnc0 it has no > > > > network. I can only get in on the vmware console. > > > > > > I use for this purpose USB-flash drive. > > > > > > But turning off ACPI does nothing for this problem. lnc0 still doesn't > > > work without ACPI too. > > > > I did make a change yesterday to add IFF_NEEDSGIANT to the ifnet flags of > > the interface. Theory suggests this should't be the problem (especially > > if you're not running with debug.mpsafenet=1), but practice is generally > > more relevant :-). Is it possible for you to check to see if the > > before/after versions of that change to see if that's the cause? > > I will try tomorrow, but i saw problem with lnc0 before yesterdays changes. > I think problems appeared around August 04-07. I'm looking at this now, starting with adding the IFF_NEEDSGIANT flag. I'll post updates as I find things. Later, George From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 18:34:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C62FB16A4CE for ; Sat, 14 Aug 2004 18:34:16 +0000 (GMT) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0454E43D39 for ; Sat, 14 Aug 2004 18:34:16 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from ns0.nlsystems.com (ns0.nlsystems.com [80.177.232.243]) by itchy.rabson.org (8.12.11/8.12.11) with ESMTP id i7EIYCe1064955 for ; Sat, 14 Aug 2004 19:34:12 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-current@freebsd.org Date: Sat, 14 Aug 2004 19:34:24 +0100 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200408141934.24107.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on itchy.rabson.org X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on itchy.rabson.org X-Virus-Status: Clean Subject: New nvidia drivers available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 18:34:16 -0000 The latest 6113 build of the nvidia graphics drivers has just appeared on nvidia's web site. Check out http://www.nvidia.com/object/freebsd_1.0-6113.html if you are currently using the nvidia proprietary drivers. This driver works nicely on FreeBSD-current and while this version is not thread-safe, it does not conflict with libpthread or libthr's use of %gs so you don't have to map everything down to libc_r any more :-). There will be a thread-safe driver available for FreeBSD-current sometime after I commit the pthread parts of the TLS support code. From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 18:36:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F84016A4CE for ; Sat, 14 Aug 2004 18:36:04 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B9E643D1D for ; Sat, 14 Aug 2004 18:36:04 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) i7EIZDr2037897; Sat, 14 Aug 2004 11:35:13 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (h234.neville-neil.com [209.157.133.234] (may be forged)) by mail.meer.net (8.12.10/8.12.2/meer) with ESMTP id i7EIYlDr053427; Sat, 14 Aug 2004 11:34:47 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Sat, 14 Aug 2004 11:34:47 -0700 Message-ID: From: "George V. Neville-Neil" To: Vitaly Markitantov In-Reply-To: <20040814175724.50404.qmail@web13422.mail.yahoo.com> References: <20040814175724.50404.qmail@web13422.mail.yahoo.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: current@freebsd.org Subject: Re: lnc0 in VmWare doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 18:36:04 -0000 OK, I tried adding IFF_NEEDSGIANT but to no avail. I will attempt to see if adding GIANT assertions to the driver helps. Later, George From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 19:21:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53C9216A4CF for ; Sat, 14 Aug 2004 19:21:50 +0000 (GMT) Received: from endif.cjb.net (65-101-231-137.dnvr.qwest.net [65.101.231.137]) by mx1.FreeBSD.org (Postfix) with SMTP id A681D43D2F for ; Sat, 14 Aug 2004 19:21:49 +0000 (GMT) (envelope-from end@endif.cjb.net) Received: (qmail 60538 invoked by uid 0); 14 Aug 2004 19:21:49 -0000 Received: from localhost (HELO rogue) (127.0.0.1) by localhost with SMTP; 14 Aug 2004 19:21:49 -0000 Date: Sat, 14 Aug 2004 13:21:48 -0600 From: Robin Schoonover To: Robin Schoonover In-Reply-To: <20040812021308.EDA4043D2D@mx1.FreeBSD.org> References: <20040812021308.EDA4043D2D@mx1.FreeBSD.org> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20040814192149.A681D43D2F@mx1.FreeBSD.org> cc: freebsd-current@freebsd.org Subject: Re: DWL-650 RevP does not work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 19:21:50 -0000 On Wed, 11 Aug 2004 20:13:02 -0600, Robin Schoonover wrote: > (This is on a 5.2.1 laptop, but I've ported small parts like ndis and > pccarddevs from -current back to my src tree) > > I recently bought a DWL-650 revP 802.11b wireless pcmcia card with > the expectation that it would work with FreeBSD. Early revisions of > that card apparently do, but not revP. I think this is a somewhat > known problem, but I'm trying to help document my troubles so maybe > someday we'll have it working. :) > Ok. I'm willing to ship it to any developer who may want to work on it. It does no good for me (I don't plan on hacking the code to make it work), so I'm willing to even pay shipping to get it the said developer. Just drop me an email if you're interested in working on it. I'll include the driver cd, and original box (maybe some of the bubble wrap). -- Robin Schoonover (aka End) # # Behind every good computer... is a jumble of wires 'n stuff. # From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 19:23:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA01416A4CE for ; Sat, 14 Aug 2004 19:23:39 +0000 (GMT) Received: from endif.cjb.net (65-101-231-137.dnvr.qwest.net [65.101.231.137]) by mx1.FreeBSD.org (Postfix) with SMTP id 2269A43D46 for ; Sat, 14 Aug 2004 19:23:39 +0000 (GMT) (envelope-from end@endif.cjb.net) Received: (qmail 60581 invoked by uid 0); 14 Aug 2004 19:23:38 -0000 Received: from localhost (HELO rogue) (127.0.0.1) by localhost with SMTP; 14 Aug 2004 19:23:38 -0000 Date: Sat, 14 Aug 2004 13:23:38 -0600 From: Robin Schoonover To: Doug Rabson In-Reply-To: <200408141934.24107.dfr@nlsystems.com> References: <200408141934.24107.dfr@nlsystems.com> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20040814192339.2269A43D46@mx1.FreeBSD.org> cc: freebsd-current@freebsd.org Subject: Re: New nvidia drivers available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 19:23:39 -0000 On Sat, 14 Aug 2004 19:34:24 +0100, Doug Rabson wrote: > The latest 6113 build of the nvidia graphics drivers has just appeared > on nvidia's web site. Check out > http://www.nvidia.com/object/freebsd_1.0-6113.html if you are currently > using the nvidia proprietary drivers. This driver works nicely on > FreeBSD-current and while this version is not thread-safe, it does not > conflict with libpthread or libthr's use of %gs so you don't have to > map everything down to libc_r any more :-). > > There will be a thread-safe driver available for FreeBSD-current > sometime after I commit the pthread parts of the TLS support code. Excellent. I was worried 5.3 might come out first (I track 5.x, not -current). -- Robin Schoonover (aka End) # # I know on which side my bread is buttered. # -- John Heywood From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 19:50:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EE2916A4CE for ; Sat, 14 Aug 2004 19:50:08 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B76543D1D for ; Sat, 14 Aug 2004 19:50:06 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) i7EJnHr2038722; Sat, 14 Aug 2004 12:49:17 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (h234.neville-neil.com [209.157.133.234] (may be forged)) by mail.meer.net (8.12.10/8.12.2/meer) with ESMTP id i7EJn2Dr061483; Sat, 14 Aug 2004 12:49:02 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Sat, 14 Aug 2004 12:49:01 -0700 Message-ID: From: "George V. Neville-Neil" To: Vitaly Markitantov In-Reply-To: <20040814175724.50404.qmail@web13422.mail.yahoo.com> References: <20040814175724.50404.qmail@web13422.mail.yahoo.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: current@freebsd.org Subject: Re: lnc0 in VmWare doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 19:50:08 -0000 At Sat, 14 Aug 2004 10:57:24 -0700 (PDT), Vitaly Markitantov wrote: > > On Sat, 14 Aug 2004, Vitaly Markitantov wrote: > > > > > > I can't get any files off of my system because without lnc0 it has no > > > > network. I can only get in on the vmware console. > > > > > > I use for this purpose USB-flash drive. > > > > > > But turning off ACPI does nothing for this problem. lnc0 still doesn't > > > work without ACPI too. > > > > I did make a change yesterday to add IFF_NEEDSGIANT to the ifnet flags of > > the interface. Theory suggests this should't be the problem (especially > > if you're not running with debug.mpsafenet=1), but practice is generally > > more relevant :-). Is it possible for you to check to see if the > > before/after versions of that change to see if that's the cause? > > I will try tomorrow, but i saw problem with lnc0 before yesterdays changes. > I think problems appeared around August 04-07. OK, I believe this is an interrupt problem. I turned on debugging and the memory locations of the tx and rx rings look OK. THe problem is nothing is being sent/received, the rings are full but nothing else. I need to figure out how to mount a USB flash drive, under -CURRENT as the Guest and Red Hat 9 as the vmware host. Then I can send the output along. I'll look more into this tonight as my test pod is dead without this stuff and I need to test some IPv6 stuff. Later, George From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 20:02:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FF3416A4CF for ; Sat, 14 Aug 2004 20:02:21 +0000 (GMT) Received: from mail.parodius.com (mail.parodius.com [64.62.145.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0373543D46 for ; Sat, 14 Aug 2004 20:02:21 +0000 (GMT) (envelope-from jdc@pentarou.parodius.com) Received: from pentarou.parodius.com (jdc@localhost [127.0.0.1]) by mail.parodius.com (8.12.11/8.12.11) with ESMTP id i7EK2KLX058316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 14 Aug 2004 13:02:20 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: (from jdc@localhost) by pentarou.parodius.com (8.12.11/8.12.11/Submit) id i7EK2K1v058315 for current@freebsd.org; Sat, 14 Aug 2004 13:02:20 -0700 (PDT) (envelope-from jdc) Date: Sat, 14 Aug 2004 13:02:20 -0700 From: Jeremy Chadwick To: current@freebsd.org Message-ID: <20040814200220.GA58201@parodius.com> Mail-Followup-To: current@freebsd.org References: <20040814175724.50404.qmail@web13422.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Subject: Re: lnc0 in VmWare doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 20:02:21 -0000 For the USB pen drive -- make sure you have uhci or ohci support in your kernel, along with usb, umass, scbus, and da. You can load some of these as modules as well. The device will appear as a umass device, which gets translated via geom to a SCSI CAM devie. Just mount it as da0 (or whatever the kernel picks). Happy hacking! -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | On Sat, Aug 14, 2004 at 12:49:01PM -0700, George V. Neville-Neil wrote: > At Sat, 14 Aug 2004 10:57:24 -0700 (PDT), > Vitaly Markitantov wrote: > > > On Sat, 14 Aug 2004, Vitaly Markitantov wrote: > > > > > > > > I can't get any files off of my system because without lnc0 it has no > > > > > network. I can only get in on the vmware console. > > > > > > > > I use for this purpose USB-flash drive. > > > > > > > > But turning off ACPI does nothing for this problem. lnc0 still doesn't > > > > work without ACPI too. > > > > > > I did make a change yesterday to add IFF_NEEDSGIANT to the ifnet flags of > > > the interface. Theory suggests this should't be the problem (especially > > > if you're not running with debug.mpsafenet=1), but practice is generally > > > more relevant :-). Is it possible for you to check to see if the > > > before/after versions of that change to see if that's the cause? > > > > I will try tomorrow, but i saw problem with lnc0 before yesterdays changes. > > I think problems appeared around August 04-07. > > OK, I believe this is an interrupt problem. I turned on debugging and > the memory locations of the tx and rx rings look OK. THe problem is > nothing is being sent/received, the rings are full but nothing else. > > I need to figure out how to mount a USB flash drive, under -CURRENT as > the Guest and Red Hat 9 as the vmware host. Then I can send the > output along. I'll look more into this tonight as my test pod is dead > without this stuff and I need to test some IPv6 stuff. > > Later, > George > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 20:03:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C841916A4CE for ; Sat, 14 Aug 2004 20:03:50 +0000 (GMT) Received: from av5-2-sn3.vrr.skanova.net (av5-2-sn3.vrr.skanova.net [81.228.9.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D9AD43D1F for ; Sat, 14 Aug 2004 20:03:50 +0000 (GMT) (envelope-from joel@automatvapen.se) Received: by av5-2-sn3.vrr.skanova.net (Postfix, from userid 502) id A416837E6A; Sat, 14 Aug 2004 22:03:49 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av5-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 932C137E4F; Sat, 14 Aug 2004 22:03:49 +0200 (CEST) Received: from [81.225.221.190] (t10o55p70.telia.com [81.225.221.190]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id E858837E4F; Sat, 14 Aug 2004 22:03:47 +0200 (CEST) From: Joel Dahl To: Doug Rabson In-Reply-To: <200408141934.24107.dfr@nlsystems.com> References: <200408141934.24107.dfr@nlsystems.com> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1092513863.16783.4.camel@dude.automatvapen.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 14 Aug 2004 22:04:23 +0200 Content-Transfer-Encoding: 8bit cc: freebsd-current@freebsd.org Subject: Re: New nvidia drivers available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 20:03:50 -0000 Lör 2004-08-14 klockan 20.34 skrev Doug Rabson: > The latest 6113 build of the nvidia graphics drivers has just appeared > on nvidia's web site. Check out > http://www.nvidia.com/object/freebsd_1.0-6113.html if you are currently > using the nvidia proprietary drivers. This driver works nicely on > FreeBSD-current and while this version is not thread-safe, it does not > conflict with libpthread or libthr's use of %gs so you don't have to > map everything down to libc_r any more :-). > > There will be a thread-safe driver available for FreeBSD-current > sometime after I commit the pthread parts of the TLS support code. This is very good news! :-) Thanks for all your work with TLS Doug, and thanks Nvidia! I'm very much looking forward to test these drivers with some of my new Nvidia cards. From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 20:50:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1761F16A4CE for ; Sat, 14 Aug 2004 20:50:45 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65EC543D46 for ; Sat, 14 Aug 2004 20:50:44 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7EKodhD058342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Aug 2004 23:50:40 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i7EKogQe099808; Sat, 14 Aug 2004 23:50:42 +0300 (EEST) (envelope-from ru) Date: Sat, 14 Aug 2004 23:50:42 +0300 From: Ruslan Ermilov To: Doug Rabson Message-ID: <20040814205042.GC99697@ip.net.ua> References: <200408141934.24107.dfr@nlsystems.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m51xatjYGsM+13rf" Content-Disposition: inline In-Reply-To: <200408141934.24107.dfr@nlsystems.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: freebsd-current@freebsd.org Subject: Re: New nvidia drivers available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 20:50:45 -0000 --m51xatjYGsM+13rf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 14, 2004 at 07:34:24PM +0100, Doug Rabson wrote: > The latest 6113 build of the nvidia graphics drivers has just appeared=20 > on nvidia's web site. Check out=20 > http://www.nvidia.com/object/freebsd_1.0-6113.html if you are currently= =20 > using the nvidia proprietary drivers. This driver works nicely on=20 > FreeBSD-current and while this version is not thread-safe, it does not=20 > conflict with libpthread or libthr's use of %gs so you don't have to=20 > map everything down to libc_r any more :-). >=20 > There will be a thread-safe driver available for FreeBSD-current=20 > sometime after I commit the pthread parts of the TLS support code. >=20 Are you the author of this driver's code? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --m51xatjYGsM+13rf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBHnsiqRfpzJluFF4RAmuZAJ42ZBkIihxeBEN+bYtfPUlru1VK8ACfSK24 VOd0tx4XHPeRYqFrv5W6+tI= =bgdL -----END PGP SIGNATURE----- --m51xatjYGsM+13rf-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 21:23:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CC7D16A4CE; Sat, 14 Aug 2004 21:23:44 +0000 (GMT) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13FB143D41; Sat, 14 Aug 2004 21:23:43 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from ns0.nlsystems.com (ns0.nlsystems.com [80.177.232.243]) by itchy.rabson.org (8.12.11/8.12.11) with ESMTP id i7ELNdBK065986; Sat, 14 Aug 2004 22:23:39 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Ruslan Ermilov Date: Sat, 14 Aug 2004 22:23:51 +0100 User-Agent: KMail/1.6.2 References: <200408141934.24107.dfr@nlsystems.com> <20040814205042.GC99697@ip.net.ua> In-Reply-To: <20040814205042.GC99697@ip.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408142223.51786.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on itchy.rabson.org X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on itchy.rabson.org X-Virus-Status: Clean cc: freebsd-current@freebsd.org Subject: Re: New nvidia drivers available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 21:23:44 -0000 On Saturday 14 August 2004 21:50, Ruslan Ermilov wrote: > On Sat, Aug 14, 2004 at 07:34:24PM +0100, Doug Rabson wrote: > > The latest 6113 build of the nvidia graphics drivers has just > > appeared on nvidia's web site. Check out > > http://www.nvidia.com/object/freebsd_1.0-6113.html if you are > > currently using the nvidia proprietary drivers. This driver works > > nicely on FreeBSD-current and while this version is not > > thread-safe, it does not conflict with libpthread or libthr's use > > of %gs so you don't have to map everything down to libc_r any more > > :-). > > > > There will be a thread-safe driver available for FreeBSD-current > > sometime after I commit the pthread parts of the TLS support code. > > Are you the author of this driver's code? Not at all - I've just been testing pre-release versions of it :-) From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 21:42:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D10516A4CE; Sat, 14 Aug 2004 21:42:35 +0000 (GMT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id D084F43D1D; Sat, 14 Aug 2004 21:42:34 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-68-124-233-133.dsl.snfc21.pacbell.net [68.124.233.133])i7ELgWfA018048; Sat, 14 Aug 2004 17:42:33 -0400 Message-ID: <411E8748.3000801@elischer.org> Date: Sat, 14 Aug 2004 14:42:32 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: Doug Rabson References: <200408141934.24107.dfr@nlsystems.com> <20040814205042.GC99697@ip.net.ua> <200408142223.51786.dfr@nlsystems.com> In-Reply-To: <200408142223.51786.dfr@nlsystems.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: New nvidia drivers available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 21:42:35 -0000 Doug Rabson wrote: > On Saturday 14 August 2004 21:50, Ruslan Ermilov wrote: > >>On Sat, Aug 14, 2004 at 07:34:24PM +0100, Doug Rabson wrote: >> >>>The latest 6113 build of the nvidia graphics drivers has just >>>appeared on nvidia's web site. Check out >>>http://www.nvidia.com/object/freebsd_1.0-6113.html if you are >>>currently using the nvidia proprietary drivers. This driver works >>>nicely on FreeBSD-current and while this version is not >>>thread-safe, it does not conflict with libpthread or libthr's use >>>of %gs so you don't have to map everything down to libc_r any more >>>:-). umm if it's not thread safe, how can you link it with libthread? >>> >>>There will be a thread-safe driver available for FreeBSD-current >>>sometime after I commit the pthread parts of the TLS support code. >> >>Are you the author of this driver's code? > > > Not at all - I've just been testing pre-release versions of it :-) > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 21:54:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7E2D16A4CF for ; Sat, 14 Aug 2004 21:54:24 +0000 (GMT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DB7043D2D for ; Sat, 14 Aug 2004 21:54:24 +0000 (GMT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (blackwater.lemis.com [192.109.197.80]) by ozlabs.org (Postfix) with ESMTP id E448E2BD68 for ; Sun, 15 Aug 2004 07:54:21 +1000 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 0952651202; Sun, 15 Aug 2004 07:24:20 +0930 (CST) Date: Sun, 15 Aug 2004 07:24:19 +0930 From: Greg 'groggy' Lehey To: Eirik =?iso-8859-1?Q?=D8verby?= Message-ID: <20040814215419.GF19643@wantadilla.lemis.com> References: <26ECE35D-EDDB-11D8-945B-000D9335BCEC@anduin.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zEb7RLSLB1wmPVHT" Content-Disposition: inline In-Reply-To: <26ECE35D-EDDB-11D8-945B-000D9335BCEC@anduin.net> User-Agent: Mutt/1.4.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: current@freebsd.org Subject: Re: How to find the cause of a hang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 21:54:24 -0000 --zEb7RLSLB1wmPVHT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Saturday, 14 August 2004 at 12:17:31 +0200, Eirik verby wrote: > Hi all, > > I'm currently experiencing frequent (about once per week) hangs of a > server that is about 1500 kilometers away from me. I have a serial > cable on the box, and using minicom on the neighbor box I am now in the > kernel debugger - but I'm at a complete loss as to what to do to figure > out what is, in fact, wrong. > > Calling panic or boot doesn't work - it just stops at "syncing > disks..." and never actually reboots. I suspect something fishy going > on with disk I/O, but I can't be certain of that. > The box responds to ping - until I call panic or boot - but no other > services are working. > > What can I do? I'm now at the db> prompt ... Help :) Well, one possibility would be to debug online. But dumping seems to be broken on recent versions of -CURRENT--see my message on the topic yesterday. Try 'call doadump' instead of 'panic'. Greg -- Note: I discard all HTML mail unseen. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. --zEb7RLSLB1wmPVHT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQFBHooLIubykFB6QiMRAgKLAKCyS+PPJTJkZ4Rp9q9PQbdrSjECFgCffG53 rzhh9MLfh7fTrItgLAO4Z4s= =caJD -----END PGP SIGNATURE----- --zEb7RLSLB1wmPVHT-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 22:22:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 980E416A4CE for ; Sat, 14 Aug 2004 22:22:29 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD51743D46 for ; Sat, 14 Aug 2004 22:22:28 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7EMJsHV037775; Sat, 14 Aug 2004 16:19:54 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 14 Aug 2004 16:20:10 -0600 (MDT) Message-Id: <20040814.162010.04877596.imp@bsdimp.com> To: sah@softcardsystems.com From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: pccard/cbb problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 22:22:29 -0000 In message: Sam writes: : module cbb already exists! That's odd. I've never seen this. How do you create it? Warner From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 22:25:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C30716A4CF; Sat, 14 Aug 2004 22:25:29 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8EA743D31; Sat, 14 Aug 2004 22:25:28 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7EMNJ27037807; Sat, 14 Aug 2004 16:23:19 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 14 Aug 2004 16:23:36 -0600 (MDT) Message-Id: <20040814.162336.17745165.imp@bsdimp.com> To: mdodd@freebsd.org From: "M. Warner Losh" In-Reply-To: <20040814135719.Y99160@sasami.jurai.net> References: <20040814135719.Y99160@sasami.jurai.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: sah@softcardsystems.com cc: freebsd-current@freebsd.org Subject: Re: pccard/cbb problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 22:25:29 -0000 In message: <20040814135719.Y99160@sasami.jurai.net> "Matthew N. Dodd" writes: : On Sat, 14 Aug 2004, Sam wrote: : > I have a ThinkPad 600E laptop on which I can't get the : > pcmcia network cards to appear with 5.*. Tried 5.2.1 : > stable, now -current, but no dice. : : I've been running -CURRENT on my 600E for as long as I've owned it (2+ : years). : : I've seen some issues with bottom card visability when the top card is : installed but inserting bottom, then top allows both cards to work. : : I'm running without ACPI (using APM) and have: : : hw.cbb.start_memory="0x20000000" : hw.pci.allow_unsupported_io_range="1" I know that the second one is never used. I believe the former is no longer used. Warner From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 22:35:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7874016A4CE for ; Sat, 14 Aug 2004 22:35:17 +0000 (GMT) Received: from smtp005.bizmail.sc5.yahoo.com (smtp005.bizmail.sc5.yahoo.com [66.163.175.82]) by mx1.FreeBSD.org (Postfix) with SMTP id 5B03143D39 for ; Sat, 14 Aug 2004 22:35:17 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noackjr@supercrime.org@70.240.234.183 with login) by smtp005.bizmail.sc5.yahoo.com with SMTP; 14 Aug 2004 22:35:17 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id D640861E1; Sat, 14 Aug 2004 17:35:15 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05077-08; Sat, 14 Aug 2004 17:35:11 -0500 (CDT) Received: from compgeek.noacks.org (compgeek [192.168.1.10]) by optimator.noacks.org (Postfix) with ESMTP id AD2B361D9; Sat, 14 Aug 2004 17:35:10 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by compgeek.noacks.org (8.13.1/8.13.1) with ESMTP id i7EMZ51K003324; Sat, 14 Aug 2004 17:35:08 -0500 (CDT) (envelope-from noackjr@alumni.rice.edu) Message-ID: <411E9399.3050200@alumni.rice.edu> Date: Sat, 14 Aug 2004 17:35:05 -0500 From: Jon Noack User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040806) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <20040813121208.M31181@cvs.imp.ch> <20040813102922.E93695@carver.gumbysoft.com> <411D20DF.2000503@samsco.org> In-Reply-To: <411D20DF.2000503@samsco.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at noacks.org cc: Martin Blapp cc: freebsd-current@freebsd.org Subject: Re: Deadlocks with recent SMP current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2004 22:35:17 -0000 On 08/13/04 15:13, Scott Long wrote: > Doug White wrote: >> On Fri, 13 Aug 2004, Martin Blapp wrote: >>> Since yesterday I'm getting complete deadlocks. This time >>> unrelated the servers are nor loaded at all, the just freeze >>> after a while. No break into DDB possible at all. >> >> Welcome to the club; I've been having them on my -curent builder >> since Aug 4. I'm going to set up a duplicate box and start >> binary-searching for the offending commit(s). >> >> Preemption is the default, disabled. >> > > My box is a dual-600MHz P3 with 1GB RAM and running kde. A make -j3 >> buildworld will lock it up 75% of the time. It'll survive a >> nonparallel build, and it'll survive a kernel build. >> >> Haven't tried WITNESS+INVARIANTS yet since it really dogs the >> machine. :) > > Can you try the patch below? It's really only a band-aid, but might > make things usable for now. Also, are more lockups being seen under > ULE or under 4BSD. There was a recent change to ULE (rev 1.120 of > sched_ule.c) that seems to have aggrivated the scheduler problems on > my test systems. > > Scott > > Index: kern_switch.c > =================================================================== > RCS file: /usr/ncvs/src/sys/kern/kern_switch.c,v > retrieving revision 1.78 > diff -u -r1.78 kern_switch.c > --- kern_switch.c 10 Aug 2004 00:26:25 -0000 1.78 > +++ kern_switch.c 13 Aug 2004 20:11:27 -0000 > @@ -345,6 +345,8 @@ > return; > } > > + critical_enter(); > + > tda = kg->kg_last_assigned; > if ((ke = td->td_kse) == NULL) { > if (kg->kg_idle_kses) { > @@ -441,6 +443,7 @@ > CTR3(KTR_RUNQ, "setrunqueue: held: td%p kg%p pid%d", > td, td->td_ksegrp, td->td_proc->p_pid); > } > + critical_exit(); > } > > /* Here's a data point: My dual Pentium3 system has been up for 20+ hours with this patch. Previously, it wouldn't survive for more than an hour or so (regardless of load). Jon From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 23:42:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D15A516A4CE for ; Sat, 14 Aug 2004 23:42:20 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FAE843D39 for ; Sat, 14 Aug 2004 23:42:20 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7ENeYHs035629; Sat, 14 Aug 2004 19:40:34 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7ENeXV3035626; Sat, 14 Aug 2004 19:40:33 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 14 Aug 2004 19:40:33 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Jon Noack In-Reply-To: <411E9399.3050200@alumni.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Martin Blapp cc: freebsd-current@freebsd.org Subject: Re: Deadlocks with recent SMP current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 23:42:20 -0000 On Sat, 14 Aug 2004, Jon Noack wrote: > Here's a data point: My dual Pentium3 system has been up for 20+ hours > with this patch. Previously, it wouldn't survive for more than an hour > or so (regardless of load). Unfortunately, I'm running a box with the same patch and did get a hang. The patch appears to correct some known stability issues associated with threaded processes, but the build I was using to trigger the hang doesn't use threads, so... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Sat Aug 14 23:43:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CFAF16A4CE; Sat, 14 Aug 2004 23:43:10 +0000 (GMT) Received: from out003.verizon.net (out003pub.verizon.net [206.46.170.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8BA443D2D; Sat, 14 Aug 2004 23:43:09 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.100] ([68.161.136.200]) by out003.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040814234309.SCZI26805.out003.verizon.net@[192.168.1.100]>; Sat, 14 Aug 2004 18:43:09 -0500 Message-ID: <411EA389.2050305@mac.com> Date: Sat, 14 Aug 2004 19:43:05 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [68.161.136.200] at Sat, 14 Aug 2004 18:43:09 -0500 cc: markm@FreeBSD.org cc: current@FreeBSD.org Subject: Re: Summary of discussion of harvester/random locking andperformance optimization X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 14 Aug 2004 23:43:10 -0000 Robert Watson wrote: [ ...yay! much stuff about S = k log W... ] > Finally, a question I raised by e-mail previously and think it's worth > thinking about is how to decide what impact we're having on entropy > quality. In particular, are there scores or other easily understood > numerical or statistical results that can be exposed to a user or > developer to allow them to measure the impact on entropy quality and > availability resulting from specific configuration, optimization, etc. I think what you're asking about is something like: http://csrc.nist.gov/rng/ ...which have a fairly straightforward set of descriptions on a link off of that page, as well as source code and datasets. The code compiles with minimal changes-- use gmake and #ifdef 0 two sections of code involving definitions for INFINITY and NAN which already exist in the system header files. There's something about the way these tests abstract away the results into the "distribution of P-values" which is not entirely easy to understand, unfortunately, although some experimentation reveals that the stats from using data from /dev/random are fairly distiguishable from those of feeding the output of random() or rand() (or /usr/share/dict/*) into a file. -- -Chuck