From owner-freebsd-current Sun Mar 3 0:21: 3 2002 Delivered-To: freebsd-current@freebsd.org Received: from herbelot.dyndns.org (d211.dhcp212-26.cybercable.fr [212.198.26.211]) by hub.freebsd.org (Postfix) with ESMTP id C6FC237B400 for ; Sun, 3 Mar 2002 00:20:58 -0800 (PST) Received: from herbelot.com (tulipe.herbelot.nom [192.168.1.5]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id JAA65454; Sun, 3 Mar 2002 09:20:47 +0100 (CET) (envelope-from thierry@herbelot.com) Message-ID: <3C81DCDE.C95E4213@herbelot.com> Date: Sun, 03 Mar 2002 09:20:46 +0100 From: Thierry Herbelot X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Philip M. Gollucci" Cc: current@FreeBSD.ORG Subject: Re: 5.0-CURRENT makebuild world fails References: <20020303023045.E93659-100000@sduwebship.student.umd.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Philip M. Gollucci" wrote: > > For about the past 2 weeks or so, I've gotten the below error and I don't > know what to do about it. > This is on a FBSD4.5-RELEASE system w/ custom kernel. > Hello, with must be a local error : I've built a -Current world+kernel last week, without any problem (but this was from a very recent 4.5-Stable world+kernel : that is update a -Stable machine up to the very latest sources, then upgrade to -Current) > cc: Internal compiler error: program cc1 got fatal signal 11 a signal 11 is generally linked to bad memory chips TfH To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 0:45:21 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.dada.it (mail3.dada.it [195.110.96.70]) by hub.freebsd.org (Postfix) with SMTP id 9B24437B402 for ; Sun, 3 Mar 2002 00:45:12 -0800 (PST) Received: (qmail 17538 invoked from network); 3 Mar 2002 08:45:01 -0000 Received: from unknown (HELO torrini.org) (195.110.114.101) by mail.dada.it with SMTP; 3 Mar 2002 08:45:01 -0000 Received: from trudy.home.torrini.org (localhost.home.torrini.org [127.0.0.1]) by torrini.org (8.12.2/8.12.2) with ESMTP id g238ilPV002763; Sun, 3 Mar 2002 09:44:47 +0100 (CET) (envelope-from riccardo@trudy.home.torrini.org) Received: (from riccardo@localhost) by trudy.home.torrini.org (8.12.2/8.12.2/Submit) id g238ia5a002762; Sun, 3 Mar 2002 09:44:36 +0100 (CET) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3C81DCDE.C95E4213@herbelot.com> Date: Sun, 03 Mar 2002 09:44:36 +0100 (CET) From: Riccardo Torrini To: Thierry Herbelot Subject: Re: 5.0-CURRENT makebuild world fails Cc: current@FreeBSD.ORG, "Philip M. Gollucci" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 03-Mar-2002 (08:20:46/GMT) Thierry Herbelot wrote: >> cc: Internal compiler error: program cc1 got fatal signal 11 > a signal 11 is generally linked to bad memory chips ...and/or overclocked CPU :) Riccardo. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 2:37:31 2002 Delivered-To: freebsd-current@freebsd.org Received: from sduwebship.student.umd.edu (sduwebship.student.umd.edu [129.2.156.15]) by hub.freebsd.org (Postfix) with ESMTP id 70D3937B400; Sun, 3 Mar 2002 02:37:22 -0800 (PST) Received: from localhost (philip@localhost) by sduwebship.student.umd.edu (8.11.6/8.11.6) with ESMTP id g235eXw94649; Sun, 3 Mar 2002 05:40:34 GMT (envelope-from philip@sduwebship.student.umd.edu) Date: Sun, 3 Mar 2002 05:40:32 +0000 (GMT) From: "Philip M. Gollucci" To: Cc: Subject: RE: 5.0-CURRENT makebuild world fails In-Reply-To: <79DD1BC58DD7AC418EC0D1D5B169ACB824117E@mail.ushustech.com> Message-ID: <20020303053843.H93697-100000@sduwebship.student.umd.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've verified it on an an additional 3 machines. 5.0-CURRENT 4.5-STABLE 4.4-RELEASE that doesn't include the original 4.5-RELEASE I highly doubt its cpu or memory at this point ? Any other great ideas ? Thanks for the help. END ------------------------------------------------------------------------------ Philip M. Gollucci (p6m7g8) philip@p6m7g8.com 301.314.3118 Science, Discovery, & the Universe (UMCP) Webmaster & Webship Teacher URL: http://www.sdu.umd.edu EJPress.com Database/PERL Programmer & System Admin URL : http://www.ejournalpress.com Resume : http://p6m7g8.com/Work/index.html On Sun, 3 Mar 2002, Manoj K S wrote: > I too have got the same error after a make depend. > but it is on FreeBSD4.4 . > If i am able to come out of it, i will help you too. > > > -----Original Message----- > From: Philip M. Gollucci [mailto:philip@sduwebship.student.umd.edu] > Sent: Sunday, March 03, 2002 8:09 AM > To: freebsd-questions@FreeBSD.ORG > Cc: current@FreeBSD.ORG > Subject: 5.0-CURRENT makebuild world fails > > > For about the past 2 weeks or so, I've gotten the below error and I don't > know what to do about it. > This is on a FBSD4.5-RELEASE system w/ custom kernel. > > > -------------------------------------------------------------- > >>> stage 4: building libraries > -------------------------------------------------------------- > cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 > OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec > PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.0 > GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin > GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font > GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac > DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/install.sh" > PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/u > sr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > make -f Makefile.inc1 -DNOHTML -DNOINFO -DNOMAN -DNOFSCHG libraries > cd /usr/src/lib/csu/i386-elf; make depend; make all; make install > rm -f .depend > mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common > /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S > mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common > /usr/src/lib/csu/i386-elf/crt1.c > cd /usr/src/lib/csu/i386-elf; make _EXTRADEPEND > cc -O2 -Wall -pipe -pedantic -ansi -march=pentiumpro -elf -Wall > -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -c > /usr/src/lib/csu/i386-elf/crt1.c -o crt1.o > /usr/src/lib/csu/i386-elf/crt1.c: In function `_start': > /usr/src/lib/csu/i386-elf/crt1.c:70: warning: ANSI C forbids braced-groups > within expressions > cc: Internal compiler error: program cc1 got fatal signal 11 > *** Error code 1 > > Stop in /usr/src/lib/csu/i386-elf. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > > END > ---------------------------------------------------------------------------- > -- > Philip M. Gollucci (p6m7g8) philip@p6m7g8.com 301.314.3118 > > Science, Discovery, & the Universe (UMCP) > Webmaster & Webship Teacher > URL: http://www.sdu.umd.edu > > EJPress.com > Database/PERL Programmer & System Admin > URL : http://www.ejournalpress.com > > Resume : http://p6m7g8.com/Work/index.html > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 4: 0:51 2002 Delivered-To: freebsd-current@freebsd.org Received: from vbook.express.ru (vbook.nc.express.ru [212.24.37.35]) by hub.freebsd.org (Postfix) with ESMTP id 5AD4937B400 for ; Sun, 3 Mar 2002 04:00:26 -0800 (PST) Received: from localhost ([127.0.0.1]) by vbook.express.ru with esmtp (Exim 3.33 #1) id 16hUCn-0000TW-00; Sun, 03 Mar 2002 14:31:05 +0300 Subject: Re: ACPI issues and questions (Dell Inspiron 3700) From: "Vladimir B. " Grebenschikov To: "Jose M. Alcaide" Cc: Takanori Watanabe , current@FreeBSD.ORG In-Reply-To: <20020225173158.A230@v-ger.we.lc.ehu.es> References: <20020225162414.B241@v-ger.we.lc.ehu.es> <200202251532.AAA91449@shidahara1.planet.sci.kobe-u.ac.jp> <20020225173158.A230@v-ger.we.lc.ehu.es> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 03 Mar 2002 14:31:05 +0300 Message-Id: <1015155065.1775.2.camel@vbook.express.ru> Mime-Version: 1.0 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 2002-02-25 at 19:31, Jose M. Alcaide wrote: > On Tue, Feb 26, 2002 at 12:32:47AM +0900, Takanori Watanabe wrote: > > In message <20020225162414.B241@v-ger.we.lc.ehu.es>, "Jose M. Alcaide" wrote: > > >1. The sio1 port (IrDA) is not detected. I had to add > > > > > > hint.sio.1.at="isa" > > > hint.sio.1.port="0x2F8" > > > hint.sio.1.irq="3" > > > > > > to /boot/device.hints in order to get it probed at boot. I think that > > > this is a fault of the ACPI BIOS. > > >From acpidump. > > > > > Device(IRDA) { > > > Name(_HID, 0x10f0a34d) > > > > So try adding > > {0x10f0a34d, NULL} > > to sio_ids in /sys/dev/sio/sio_isa.c > > It works: > > sio0 port 0x3f8-0x3ff irq 4 on acpi0 > sio0: type 16550A > sio1 port 0x280-0x287,0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A I have tried this patch for Sony VAIO PCG-Z505S And it works ! Corresponding part of acpidump: Device(FIR_) { Name(_HID, 0x10f0a34d) (exactly same number) sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x140-0x147,0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A May be it is time to commit this line ? -- TSB "Russian Express", Moscow Vladimir B. Grebenschikov, vova@express.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 5:49:52 2002 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 821) id DC45F37B400; Sun, 3 Mar 2002 05:49:48 -0800 (PST) Date: Sun, 3 Mar 2002 05:49:48 -0800 From: John To: Current List Subject: ftpd ESTALE patch Message-ID: <20020303054948.A29473@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I've had the following patch installed for some time now. Basically, we ran into a situation where files being generated/stored to a fileserver from client A and then handed by out by ftp from a different client host was failing. The following patch handles the recoverable ESTALE situation. Trace/debug output is done when the logging level is 2 or more as is done elsewhere. It is also worth noting that ESTALE is not documented as a valid errno return from open(). Thanks, John The patch can also be found online at: http://people.freebsd.org/~jwd/ftpd.estale.patch Index: ftpd.c =================================================================== RCS file: /home/ncvs/src/libexec/ftpd/ftpd.c,v retrieving revision 1.99 diff -u -r1.99 ftpd.c --- ftpd.c 25 Feb 2002 16:39:34 -0000 1.99 +++ ftpd.c 3 Mar 2002 13:25:00 -0000 @@ -1478,7 +1478,15 @@ time_t start; if (cmd == 0) { - fin = fopen(name, "r"), closefunc = fclose; + int try = 0; + while ((fin = fopen(name,"r")) == NULL && errno == ESTALE && try < 3 ) { + sleep(++try); + if (logging > 1) + syslog(LOG_INFO,"get fopen(\"%s\"): %m: attempting retry",name); + } + if (fin == NULL && logging > 1) + syslog(LOG_INFO,"get fopen(\"%s\"): %m",name); + closefunc = fclose; st.st_size = 0; } else { char line[BUFSIZ]; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 6:25: 9 2002 Delivered-To: freebsd-current@freebsd.org Received: from encontacto.net (adsl-64-173-182-158.dsl.mtry01.pacbell.net [64.173.182.158]) by hub.freebsd.org (Postfix) with ESMTP id 45AEC37B419; Sun, 3 Mar 2002 06:24:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) (uid 0) by encontacto.net with local; Sun, 03 Mar 2002 06:24:35 -0800 Received: from 64.173.182.155 ( [64.173.182.155]) as user eculp@mexcomusa.net@mail.mexcomusa.net by Mail.MexComUSA.Net with HTTP; Sun, 3 Mar 2002 06:24:35 -0800 Message-ID: <1015165475.3c82322315fdf@Mail.MexComUSA.Net> Date: Sun, 3 Mar 2002 06:24:35 -0800 From: Edwin Culp To: "Philip M. Gollucci" Cc: freebsd-questions@FreeBSD.ORG, current@FreeBSD.ORG Subject: RE: 5.0-CURRENT makebuild world fails References: <20020303053843.H93697-100000@sduwebship.student.umd.edu> In-Reply-To: <20020303053843.H93697-100000@sduwebship.student.umd.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 64.173.182.155 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've cvsuped and built world and new kernels on 6 machines this morning. Two are SMP PIII's, 3 PIII servers, and my laptop, with no problems. I did the same yesterday morning. All cvsups at 3-5 am PST. All seperate builds and in seperate locations. This probably doesn't help but hopefully you will be able to dig a bit deeper and find the solution. It sure is strange. BTW, I can only speak about current boxes. ed Quoting "Philip M. Gollucci" : > I've verified it on an an additional 3 machines. > > 5.0-CURRENT > 4.5-STABLE > 4.4-RELEASE > > that doesn't include the original > 4.5-RELEASE > > I highly doubt its cpu or memory at this point ? > > Any other great ideas ? > > Thanks for the help. > > > END > ------------------------------------------------------------------------------ > Philip M. Gollucci (p6m7g8) philip@p6m7g8.com 301.314.3118 > > Science, Discovery, & the Universe (UMCP) > Webmaster & Webship Teacher > URL: http://www.sdu.umd.edu > > EJPress.com > Database/PERL Programmer & System Admin > URL : http://www.ejournalpress.com > > Resume : http://p6m7g8.com/Work/index.html > > > On Sun, 3 Mar 2002, Manoj K S wrote: > > > I too have got the same error after a make depend. > > but it is on FreeBSD4.4 . > > If i am able to come out of it, i will help you too. > > > > > > -----Original Message----- > > From: Philip M. Gollucci [mailto:philip@sduwebship.student.umd.edu] > > Sent: Sunday, March 03, 2002 8:09 AM > > To: freebsd-questions@FreeBSD.ORG > > Cc: current@FreeBSD.ORG > > Subject: 5.0-CURRENT makebuild world fails > > > > > > For about the past 2 weeks or so, I've gotten the below error and I don't > > know what to do about it. > > This is on a FBSD4.5-RELEASE system w/ custom kernel. > > > > > > -------------------------------------------------------------- > > >>> stage 4: building libraries > > -------------------------------------------------------------- > > cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 > > OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec > > PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.0 > > GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin > > GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font > > GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac > > DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/install.sh" > > > PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/u > > sr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > > make -f Makefile.inc1 -DNOHTML -DNOINFO -DNOMAN -DNOFSCHG libraries > > cd /usr/src/lib/csu/i386-elf; make depend; make all; make install > > rm -f .depend > > mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common > > /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S > > mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common > > /usr/src/lib/csu/i386-elf/crt1.c > > cd /usr/src/lib/csu/i386-elf; make _EXTRADEPEND > > cc -O2 -Wall -pipe -pedantic -ansi -march=pentiumpro -elf -Wall > > -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -c > > /usr/src/lib/csu/i386-elf/crt1.c -o crt1.o > > /usr/src/lib/csu/i386-elf/crt1.c: In function `_start': > > /usr/src/lib/csu/i386-elf/crt1.c:70: warning: ANSI C forbids > braced-groups > > within expressions > > cc: Internal compiler error: program cc1 got fatal signal 11 > > *** Error code 1 > > > > Stop in /usr/src/lib/csu/i386-elf. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > > > > > END > > > ---------------------------------------------------------------------------- > > -- > > Philip M. Gollucci (p6m7g8) philip@p6m7g8.com 301.314.3118 > > > > Science, Discovery, & the Universe (UMCP) > > Webmaster & Webship Teacher > > URL: http://www.sdu.umd.edu > > > > EJPress.com > > Database/PERL Programmer & System Admin > > URL : http://www.ejournalpress.com > > > > Resume : http://p6m7g8.com/Work/index.html > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-questions" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > ------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 6:25: 5 2002 Delivered-To: freebsd-current@freebsd.org Received: from encontacto.net (adsl-64-173-182-158.dsl.mtry01.pacbell.net [64.173.182.158]) by hub.freebsd.org (Postfix) with ESMTP id D177437B417; Sun, 3 Mar 2002 06:24:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) (uid 0) by encontacto.net with local; Sun, 03 Mar 2002 06:24:35 -0800 Received: from 64.173.182.155 ( [64.173.182.155]) as user eculp@mexcomusa.net@mail.mexcomusa.net by Mail.MexComUSA.Net with HTTP; Sun, 3 Mar 2002 06:24:35 -0800 Message-ID: <1015165475.3c8232237a16f@Mail.MexComUSA.Net> Date: Sun, 3 Mar 2002 06:24:35 -0800 From: Edwin Culp To: "Philip M. Gollucci" Cc: freebsd-questions@FreeBSD.ORG, current@FreeBSD.ORG Subject: RE: 5.0-CURRENT makebuild world fails References: <20020303053843.H93697-100000@sduwebship.student.umd.edu> In-Reply-To: <20020303053843.H93697-100000@sduwebship.student.umd.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 64.173.182.155 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've cvsuped and built world and new kernels on 6 machines this morning. Two are SMP PIII's, 3 PIII servers, and my laptop, with no problems. I did the same yesterday morning. All cvsups at 3-5 am PST. All seperate builds and in seperate locations. This probably doesn't help but hopefully you will be able to dig a bit deeper and find the solution. It sure is strange. BTW, I can only speak about current boxes. ed Quoting "Philip M. Gollucci" : > I've verified it on an an additional 3 machines. > > 5.0-CURRENT > 4.5-STABLE > 4.4-RELEASE > > that doesn't include the original > 4.5-RELEASE > > I highly doubt its cpu or memory at this point ? > > Any other great ideas ? > > Thanks for the help. > > > END > ------------------------------------------------------------------------------ > Philip M. Gollucci (p6m7g8) philip@p6m7g8.com 301.314.3118 > > Science, Discovery, & the Universe (UMCP) > Webmaster & Webship Teacher > URL: http://www.sdu.umd.edu > > EJPress.com > Database/PERL Programmer & System Admin > URL : http://www.ejournalpress.com > > Resume : http://p6m7g8.com/Work/index.html > > > On Sun, 3 Mar 2002, Manoj K S wrote: > > > I too have got the same error after a make depend. > > but it is on FreeBSD4.4 . > > If i am able to come out of it, i will help you too. > > > > > > -----Original Message----- > > From: Philip M. Gollucci [mailto:philip@sduwebship.student.umd.edu] > > Sent: Sunday, March 03, 2002 8:09 AM > > To: freebsd-questions@FreeBSD.ORG > > Cc: current@FreeBSD.ORG > > Subject: 5.0-CURRENT makebuild world fails > > > > > > For about the past 2 weeks or so, I've gotten the below error and I don't > > know what to do about it. > > This is on a FBSD4.5-RELEASE system w/ custom kernel. > > > > > > -------------------------------------------------------------- > > >>> stage 4: building libraries > > -------------------------------------------------------------- > > cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 > > OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec > > PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.0 > > GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin > > GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font > > GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac > > DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/install.sh" > > > PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/u > > sr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > > make -f Makefile.inc1 -DNOHTML -DNOINFO -DNOMAN -DNOFSCHG libraries > > cd /usr/src/lib/csu/i386-elf; make depend; make all; make install > > rm -f .depend > > mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common > > /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S > > mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common > > /usr/src/lib/csu/i386-elf/crt1.c > > cd /usr/src/lib/csu/i386-elf; make _EXTRADEPEND > > cc -O2 -Wall -pipe -pedantic -ansi -march=pentiumpro -elf -Wall > > -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -c > > /usr/src/lib/csu/i386-elf/crt1.c -o crt1.o > > /usr/src/lib/csu/i386-elf/crt1.c: In function `_start': > > /usr/src/lib/csu/i386-elf/crt1.c:70: warning: ANSI C forbids > braced-groups > > within expressions > > cc: Internal compiler error: program cc1 got fatal signal 11 > > *** Error code 1 > > > > Stop in /usr/src/lib/csu/i386-elf. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > > > > > END > > > ---------------------------------------------------------------------------- > > -- > > Philip M. Gollucci (p6m7g8) philip@p6m7g8.com 301.314.3118 > > > > Science, Discovery, & the Universe (UMCP) > > Webmaster & Webship Teacher > > URL: http://www.sdu.umd.edu > > > > EJPress.com > > Database/PERL Programmer & System Admin > > URL : http://www.ejournalpress.com > > > > Resume : http://p6m7g8.com/Work/index.html > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-questions" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > ------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 6:53:38 2002 Delivered-To: freebsd-current@freebsd.org Received: from sonic.kks.net (sonic.kks.net [213.161.0.18]) by hub.freebsd.org (Postfix) with ESMTP id 5435637B402 for ; Sun, 3 Mar 2002 06:53:35 -0800 (PST) Received: from voyager.kksonline.com (5-51.ro.cable.kks.net [213.161.5.51]) by sonic.kks.net (Postfix) with ESMTP id A704A14B for ; Sun, 3 Mar 2002 15:53:41 +0100 (CET) Message-Id: <5.0.2.1.0.20020303154638.02ad1ab0@164.8.8.5> X-Sender: rozmanal@164.8.8.5 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 03 Mar 2002 15:49:23 +0100 To: freebsd-current@FreeBSD.ORG From: Aleksander Rozman - Andy Subject: Build broken and not building modules Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi ! I am trying to compile in my code for kernel, but every time I start compile (even without my code) it stops in modules. It seems that latest commits have a lot of modules errors. Is there a way to override building modules. To build kernel I usually go to i386/compile/NAME directory and issue make command. Is there a switch I can use to stop building of modules (I have everything I need builtin in kernel, what I need). Andy ************************************************************************** * Aleksander Rozman - Andy * Fandoms: E2:EA, SAABer, Trekkie, Earthie * * andy@kksonline.com * Sentinel, BH 90210, True's Trooper, * * andy@atechnet.dhs.org * Heller's Angel, Questie, Legacy, PO5, * * Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender * * ICQ-UIC: 4911125 ********************************************* * PGP key available * http://www.atechnet.dhs.org/~andy/ * ************************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 7:37:49 2002 Delivered-To: freebsd-current@freebsd.org Received: from mta05.onebox.com (mta05.onebox.com [64.68.77.148]) by hub.freebsd.org (Postfix) with ESMTP id DBD3E37B400 for ; Sun, 3 Mar 2002 07:37:45 -0800 (PST) Received: from onebox.com ([10.1.101.8]) by mta05.onebox.com (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020303153745.GELH27009.mta05.onebox.com@onebox.com>; Sun, 3 Mar 2002 07:37:45 -0800 Received: from [63.49.209.107] by onebox.com with HTTP; Sun, 03 Mar 2002 07:37:45 -0800 Date: Sun, 03 Mar 2002 07:37:45 -0800 Subject: Re: Build broken and not building modules From: "Glenn Gombert" To: Aleksander Rozman - Andy Cc: freebsd-current@FreeBSD.ORG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Message-Id: <20020303153745.GELH27009.mta05.onebox.com@onebox.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG try "make -DNO_WERROR kernel" it overrides the complier warning messages being generated at the moment (that are treated as errors) ..... ---- Aleksander Rozman - Andy wrote: > > Hi ! > > I am trying to compile in my code for kernel, but every time I start > > compile (even without my code) it stops in modules. It seems that latest > > commits have a lot of modules errors. Is there a way to override building > > modules. To build kernel I usually go to i386/compile/NAME directory > and > issue make command. Is there a switch I can use to stop building of > modules > (I have everything I need builtin in kernel, what I need). > > Andy > > > ************************************************************************** > * Aleksander Rozman - Andy * Fandoms: E2:EA, SAABer, Trekkie, Earthie > * > * andy@kksonline.com * Sentinel, BH 90210, True's Trooper, > * > * andy@atechnet.dhs.org * Heller's Angel, Questie, Legacy, PO5, > * > * Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender > * > * ICQ-UIC: 4911125 ********************************************* > * PGP key available * http://www.atechnet.dhs.org/~andy/ > * > ************************************************************************** > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > __________________________________________________ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 8:31:40 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 3366A37B400 for ; Sun, 3 Mar 2002 08:31:38 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020303163137.FIZQ1214.rwcrmhc54.attbi.com@blossom.cjclark.org> for ; Sun, 3 Mar 2002 16:31:37 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g23GVav84880 for current@freebsd.org; Sun, 3 Mar 2002 08:31:36 -0800 (PST) (envelope-from cjc) Date: Sun, 3 Mar 2002 08:31:36 -0800 From: "Crist J. Clark" To: current@freebsd.org Subject: devfs(5) Permissions Message-ID: <20020303083136.A84637@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've checked the manpages, the files in /etc, and Googled, and I can't find the answer. I am begining to worry there isn't one. How does one change the permissions on dynamically created devices? That is, when the node comes into existence, it has the permissions I want, and not necessarily the defaults. My example is the bpf(4) device. The node only comes into existence the first time you try to use it. I want to give a certain group read permission to the device. There are terrible, terrible, ugly ways to work around this (some kind of script run at startup to create 'n' bpf(4) devices and which then modifies the permissions), but it would be much easier to be able to tell the system what the default permissions are. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 8:36:24 2002 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 2C7AF37B419 for ; Sun, 3 Mar 2002 08:36:18 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g23Ga4Lv079391; Sun, 3 Mar 2002 17:36:04 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: cjclark@alum.mit.edu Cc: current@FreeBSD.ORG Subject: Re: devfs(5) Permissions In-Reply-To: Your message of "Sun, 03 Mar 2002 08:31:36 PST." <20020303083136.A84637@blossom.cjclark.org> Date: Sun, 03 Mar 2002 17:36:04 +0100 Message-ID: <79390.1015173364@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020303083136.A84637@blossom.cjclark.org>, "Crist J. Clark" writes : >I've checked the manpages, the files in /etc, and Googled, and I can't >find the answer. I am begining to worry there isn't one. How does one >change the permissions on dynamically created devices? That is, when >the node comes into existence, it has the permissions I want, and not >necessarily the defaults. The overall plan is that it will be possible to push a ruleset into the kernel which changes the defaults. ETA: this summer (If I have to do it, if somebody wants to help code it it can probably be done faster). -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 8:43: 9 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.dada.it (mail5.dada.it [195.110.96.37]) by hub.freebsd.org (Postfix) with SMTP id 705A537B68C for ; Sun, 3 Mar 2002 08:42:47 -0800 (PST) Received: (qmail 20199 invoked from network); 3 Mar 2002 16:42:09 -0000 Received: from unknown (HELO torrini.org) (195.110.114.101) by mail.dada.it with SMTP; 3 Mar 2002 16:42:09 -0000 Received: from trudy.home.torrini.org (localhost.home.torrini.org [127.0.0.1]) by torrini.org (8.12.2/8.12.2) with ESMTP id g23GgBPV004487; Sun, 3 Mar 2002 17:42:11 +0100 (CET) (envelope-from riccardo@trudy.home.torrini.org) Received: (from riccardo@localhost) by trudy.home.torrini.org (8.12.2/8.12.2/Submit) id g23GgAOB004486; Sun, 3 Mar 2002 17:42:10 +0100 (CET) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020303083136.A84637@blossom.cjclark.org> Date: Sun, 03 Mar 2002 17:42:10 +0100 (CET) From: Riccardo Torrini To: cjclark@alum.mit.edu Subject: RE: devfs(5) Permissions Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 03-Mar-2002 (16:31:36/GMT) Crist J. Clark wrote: > How does one change the permissions on dynamically created > devices? That is, when the node comes into existence, it has > the permissions I want, and not necessarily the defaults. You can (must?) use /etc/rc.devfs [...] # Setup DEVFS, ie permissions, links etc. [...] Riccardo. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 9: 2:39 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id E4C9937B404 for ; Sun, 3 Mar 2002 09:02:36 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020303170236.FBRF2626.rwcrmhc51.attbi.com@blossom.cjclark.org>; Sun, 3 Mar 2002 17:02:36 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g23H2ZO84972; Sun, 3 Mar 2002 09:02:35 -0800 (PST) (envelope-from cjc) Date: Sun, 3 Mar 2002 09:02:35 -0800 From: "Crist J. Clark" To: Riccardo Torrini Cc: current@FreeBSD.ORG Subject: Re: devfs(5) Permissions Message-ID: <20020303090235.C84637@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20020303083136.A84637@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from riccardo@torrini.org on Sun, Mar 03, 2002 at 05:42:10PM +0100 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Mar 03, 2002 at 05:42:10PM +0100, Riccardo Torrini wrote: > On 03-Mar-2002 (16:31:36/GMT) Crist J. Clark wrote: > > > How does one change the permissions on dynamically created > > devices? That is, when the node comes into existence, it has > > the permissions I want, and not necessarily the defaults. > > You can (must?) use /etc/rc.devfs > > [...] > # Setup DEVFS, ie permissions, links etc. > [...] I think some people missed the point of the earlier question. My problem is with devices that are created dynamically as they get used. I can put, chmod 640 /dev/bpf{0,1,2,3} In rc.devfs, and I will have joy for the first four bpf(4) devices. That command creates them and gives them the permissions I want. However, once someone tries to use /dev/bpf4, a new device is dynamically created with the default permissions, not the permissions I want. But creating 'n' devices at boot will do for now (especially since we used to be restricted to 'n' bpf(4) devices in the kernel configuration, so it almost resembles historic behavior). -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 9:18:17 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.dada.it (mail3.dada.it [195.110.96.70]) by hub.freebsd.org (Postfix) with SMTP id 1D42837B404 for ; Sun, 3 Mar 2002 09:18:14 -0800 (PST) Received: (qmail 15160 invoked from network); 3 Mar 2002 17:18:04 -0000 Received: from unknown (HELO torrini.org) (195.110.114.101) by mail.dada.it with SMTP; 3 Mar 2002 17:18:04 -0000 Received: from trudy.home.torrini.org (localhost.home.torrini.org [127.0.0.1]) by torrini.org (8.12.2/8.12.2) with ESMTP id g23HI3PV004578; Sun, 3 Mar 2002 18:18:03 +0100 (CET) (envelope-from riccardo@trudy.home.torrini.org) Received: (from riccardo@localhost) by trudy.home.torrini.org (8.12.2/8.12.2/Submit) id g23HI2ms004577; Sun, 3 Mar 2002 18:18:02 +0100 (CET) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020303090235.C84637@blossom.cjclark.org> Date: Sun, 03 Mar 2002 18:18:02 +0100 (CET) From: Riccardo Torrini To: cjclark@alum.mit.edu Subject: Re: devfs(5) Permissions Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 03-Mar-2002 (17:02:35/GMT) Crist J. Clark wrote: > I think some people missed the point of the earlier question. I'm really sorry :( Next time I'll double read the messages. Riccardo. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 10:41:39 2002 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 433D737B417 for ; Sun, 3 Mar 2002 10:41:34 -0800 (PST) Received: (from sos@localhost) by freebsd.dk (8.11.6/8.11.6) id g23IfXB31877 for current@freebsd.org; Sun, 3 Mar 2002 19:41:33 +0100 (CET) (envelope-from sos) From: Søren Schmidt Message-Id: <200203031841.g23IfXB31877@freebsd.dk> Subject: Request for testers of ATA RAID support To: current@freebsd.org Date: Sun, 3 Mar 2002 19:41:33 +0100 (CET) Reply-To: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As some might have noticed I've done some significant work on the ATA RAID support (for Promise & Highpoint controllers) all thanks to Advanis which has made this possible. The code as it is now in -current allows for RAID1's (mirrors) to be properly handled when a disk dies, that means the system continues on the good disk and logs the loss of mirror to the console. The hotswap part of the ATA driver has been extended with functions to enable the bad disk to be detached with atacontrol and if it is in a removeable enclosure, it can be swapped with a new good disk even while the system is running. When the new disk is attached again with atacontrol, the ATA driver will mark it as a SPARE disk if its located where the failed disk was before. Now the really interesting part is the new rebuild command in atacontrol, that will bring the SPARE disk up to date, and when done will set the RAID to fully functional again. All the above is properly written to the config sectors on the disks, so that the BIOS will pick up any changes that happend when the ATA driver was in control. If you have Promise SuperSwap enclosures, the state of the disks will be shown by the LEDs, red for broken disk, orange for rebuilding and green for online. All this said I need testers to really give this new functionality a run for its money, so please, if you have the HW needed for this (Promise Fasttrak or a Highpoint controller with ATA disks) please give it a whirl and let me know how it works out. Thanks! -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 10:50:10 2002 Delivered-To: freebsd-current@freebsd.org Received: from out008.verizon.net (out008pub.verizon.net [206.46.170.108]) by hub.freebsd.org (Postfix) with ESMTP id 2F8B737B405 for ; Sun, 3 Mar 2002 10:50:07 -0800 (PST) Received: from verizon.net ([207.175.241.198]) by out008.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020303185006.RCIR12982.out008.verizon.net@verizon.net> for ; Sun, 3 Mar 2002 12:50:06 -0600 Message-ID: <3C827021.A7FA73A4@verizon.net> Date: Sun, 03 Mar 2002 10:49:05 -0800 From: Maksim Yevmenkin X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Netgraph, device drivers and mutexes Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hackers, i have some (probably stupid) questions about Netgraph, device drivers and mutexes. i'm using -current as of this weekend. i have written draft version of the driver for 3com/HP Bluetooth Card (PC-Card). the driver is a pure Netgraph node, i.e. no device nor network interface registered at all. the only interface is Netgraph. the dirver is very simple - it detects and attaches the card, allocates resources, registers interrupt service routine (for now at NET level, but it probably shouldn't) and creates Negraph node. it sort of works, but i'm trying to figure out what kind of locking i need (if i need any). the same locking questions goes for the other Netgraph nodes that connected to the driver node. i want very simple locks to do the following: 1) handle timeouts with timeout(9)/untimeout(9) - my _biggest_ concern. all i could find in -current is everyone use splXXX/splx :( is it broken on SMP? 2) modify node's internal data structure in a safe way. i'm talking about things like linked lists, queues etc. since splXXX(9) functions are no longer relevant in -current (please correct me if i wrong), i was looking at mutex(9). i have noticed several device drivers that also use Netgraph (if_ar, if_sr, if_lmc and udbp), and they use MTX_DEF mutexes and splXXX(9) functions. is that OK with Netgraph? the man page says that MTX_DEF mutexes _will_ context switch when they are already held. can/should i use MTX_SPIN mutexes? i have tried to use them, but WITNESS code gets very upset (panic) unless i modify "order_lists" in kern/subr_wintess.c. i would rather not do it, since i'm not fully aware of what's going on. any other ways to handle that? i had crazy idea to write a Netgraph "timeout" node, that does nothing but accepts requests to set/remove timeout and send message back when timeout has expired. it won't solve timeout problem, but put it into one place. thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 11: 2:54 2002 Delivered-To: freebsd-current@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id D47BC37B426 for ; Sun, 3 Mar 2002 11:02:47 -0800 (PST) Received: from pool0389.cvx21-bradley.dialup.earthlink.net ([209.179.193.134] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16hbAr-0002Wi-00; Sun, 03 Mar 2002 10:57:34 -0800 Message-ID: <3C82720F.7D64079D@mindspring.com> Date: Sun, 03 Mar 2002 10:57:19 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Riccardo Torrini Cc: Thierry Herbelot , current@FreeBSD.ORG, "Philip M. Gollucci" Subject: Re: 5.0-CURRENT makebuild world fails References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Riccardo Torrini wrote: > On 03-Mar-2002 (08:20:46/GMT) Thierry Herbelot wrote: > >> cc: Internal compiler error: program cc1 got fatal signal 11 > > > a signal 11 is generally linked to bad memory chips > > ...and/or overclocked CPU :) And/or a pmap code bug. At boot time, try setting kern.maxfile to 50000 or more in the loader, and then booting normally. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 12:10:24 2002 Delivered-To: freebsd-current@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 21B5F37B400 for ; Sun, 3 Mar 2002 12:10:19 -0800 (PST) Received: from hamilton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 3 Mar 2002 20:10:18 +0000 (GMT) Date: Sun, 3 Mar 2002 20:10:18 +0000 From: David Malone To: Poul-Henning Kamp Cc: cjclark@alum.mit.edu, current@FreeBSD.ORG Subject: Re: devfs(5) Permissions Message-ID: <20020303201018.GA88366@hamilton.maths.tcd.ie> References: <20020303083136.A84637@blossom.cjclark.org> <79390.1015173364@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79390.1015173364@critter.freebsd.dk> User-Agent: Mutt/1.3.25i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Mar 03, 2002 at 05:36:04PM +0100, Poul-Henning Kamp wrote: > In message <20020303083136.A84637@blossom.cjclark.org>, "Crist J. Clark" writes > : > >I've checked the manpages, the files in /etc, and Googled, and I can't > >find the answer. I am begining to worry there isn't one. How does one > >change the permissions on dynamically created devices? That is, when > >the node comes into existence, it has the permissions I want, and not > >necessarily the defaults. > > The overall plan is that it will be possible to push a ruleset into > the kernel which changes the defaults. ETA: this summer (If I have to > do it, if somebody wants to help code it it can probably be done faster). I have a very similar problem trying to sync my Handspring Visor as a regular user 'cos the devices only come into existance when you press the sync button. Do you have any designs for this ruleset stuff? From what you said at BSDconEurope it will have to be fairly complicated to achieve the your aim of being better than a static permission for a given device. Otherwise, one option would just be to have devfs check for a file in the /dev directory it is mounted over and then use that files permissions as a default. That would at least get us back the features of the old /dev which we're missing now. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 12:17:17 2002 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 7123337B400 for ; Sun, 3 Mar 2002 12:17:13 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g23KGxLv025569; Sun, 3 Mar 2002 21:17:00 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: David Malone Cc: cjclark@alum.mit.edu, current@FreeBSD.ORG Subject: Re: devfs(5) Permissions In-Reply-To: Your message of "Sun, 03 Mar 2002 20:10:18 GMT." <20020303201018.GA88366@hamilton.maths.tcd.ie> Date: Sun, 03 Mar 2002 21:16:59 +0100 Message-ID: <25568.1015186619@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020303201018.GA88366@hamilton.maths.tcd.ie>, David Malone writes: >On Sun, Mar 03, 2002 at 05:36:04PM +0100, Poul-Henning Kamp wrote: >> In message <20020303083136.A84637@blossom.cjclark.org>, "Crist J. Clark" writes >> : >> >I've checked the manpages, the files in /etc, and Googled, and I can't >> >find the answer. I am begining to worry there isn't one. How does one >> >change the permissions on dynamically created devices? That is, when >> >the node comes into existence, it has the permissions I want, and not >> >necessarily the defaults. >> >> The overall plan is that it will be possible to push a ruleset into >> the kernel which changes the defaults. ETA: this summer (If I have to >> do it, if somebody wants to help code it it can probably be done faster). > >I have a very similar problem trying to sync my Handspring Visor >as a regular user 'cos the devices only come into existance when >you press the sync button. > >Do you have any designs for this ruleset stuff? From what you said >at BSDconEurope it will have to be fairly complicated to achieve >the your aim of being better than a static permission for a given >device. Not really, the basic idea is just a linked list of rules: name=="/dev/uscanner*" -> chmod 0644 driver=="bpf" -> chown user It's not too much work, I just havn't had the time for it yet. (Junior Kernel Hackers can apply here :-) >Otherwise, one option would just be to have devfs check for a file >in the /dev directory it is mounted over and then use that files >permissions as a default. That would at least get us back the >features of the old /dev which we're missing now. This is much harder than you think... -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 12:19:55 2002 Delivered-To: freebsd-current@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id 0DD4B37B426; Sun, 3 Mar 2002 12:18:42 -0800 (PST) Received: from elischer.org ([64.170.121.0]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GSE0020RZ33GZ@mta6.snfc21.pbi.net>; Sun, 03 Mar 2002 12:18:40 -0800 (PST) Date: Sun, 03 Mar 2002 12:17:27 -0800 From: Julian Elischer Subject: Re: Netgraph, device drivers and mutexes To: Maksim Yevmenkin Cc: freebsd-current@freebsd.org, archie@freebsd.org Message-id: <3C8284D7.C5A8A893@elischer.org> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) Content-type: text/plain; charset=iso-8859-2 Content-transfer-encoding: 7BIT X-Accept-Language: en, hu References: <3C827021.A7FA73A4@verizon.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maksim Yevmenkin wrote: > > Hackers, Ah here we have teh one part of -curretn netgraph that is not yet fully implemented.. Netgraph has it's own locking, using a spinlock in the worst case but trying like crazy to avoid havong to use it. It implememts a reader-writer (shared/exclusive) locking scheme where a failure to gain the lock does not result in a blocking action but rather, results an in element being queued for later processing. All "message" type requests are by default trying to get "write" (exclusive) locks, and data is by default trying to get "read" (shared) locks. (These default behaviours can be over-ridden by the node if it knows for example that it's data operations need to change some state that means that they must have exclusive access to the node state or someo other resource). This is all build in to the system so if you are communicating with the node only by using messages (the suggested method) then there is no more locking that you need to do. The problem come however when external code wants ot interact with netgraph nodes. In this situation you should use the following technique. You specify a function that will do the work that you require. It should be of the form typedef void ng_item_fn(node_p node, hook_p hook, void *arg1, int arg2); (though you shouldn't use the typedef) external code can call int ng_send_fn(node_p node, hook_p hook, ng_item_fn *fn, void *arg1, int arg2); If it can gain the lock it will immediatly run function, but if it can NOT gain the lock, it will queue it to be run as soon as the lock is released. If you wish to use a timeout then your actual timeout code should call this function to do the work you wish to be done. Note there is a little more to it.. While the timeout is valid you MUST hold a reference on the node using NG_NODE_REF() and IF you supply a hook argument (it's optional) you MUST hold a reference on that too using NG_HOOK_REF(). When your timeout function is called, you can drop these references using NG_NODE_UNREF() and NG_HOOK_UNREF() AFTER you have called ng_send_fn(). This is to ensure that the timeout code doesnot try to access a node that has been freed. (or a hook). In the case where ng_send_fn() needs to queue the request it will take out its own references so you cna then drop yours. (if however you are about to set another timeout() you may just save time and keep them, howeer if you do you need to check the validity of the node using NG_NODE_IS_VALID() and the same for the hook. This is to ensure that you are not seting a timeout on a node that has been shut down and is just waiting for your last reference to be released before being freed. This is actually the way that any code that was called from outside the netgraph framework should interract with netgraph nodes. E.g. device drivers that are run from interrupt context should do this to pass the data to their own netgraph parts, and the ng_socket node should do this to pass the data into the netgraph part of the module in a SMP situation. This has not yet been done, so you will find only a small number of usages of ng_send_fn() in the code as it stands but my next netgraph 'push' will be to do this.. I will also implement a couple of helper functions to allow this to be dome more conveniently. I hope that this helps you! in 4.x of course the whole thing is under the BGL so you can ignore it entirely. Please let me know immediatly if you have problems. Also be aware that there is an Ng_device node on the horizon that creates a device in the devfs. You may want to use this to provide an interface to the bluetooth devices that you can expose to userland. Packets receieved from netgraph are buffered and availabel for 'read()' and data passed by write() is bufferedup and passed out through the netgraph hooks. Mark Santcroos is writing it if you want an early version to play with. My first use of it will be to make a 'pipe' device using a tcp ksocket and ng_device on two differnt machines, so that anything that is written to /dev/xyz on one machine is readable by 'cat' on teh other machine :-) > > i have some (probably stupid) questions about Netgraph, > device drivers and mutexes. i'm using -current as of this > weekend. > > i have written draft version of the driver for 3com/HP > Bluetooth Card (PC-Card). the driver is a pure Netgraph > node, i.e. no device nor network interface registered at > all. the only interface is Netgraph. > > the dirver is very simple - it detects and attaches the > card, allocates resources, registers interrupt service > routine (for now at NET level, but it probably shouldn't) > and creates Negraph node. it sort of works, but i'm trying > to figure out what kind of locking i need (if i need any). > > the same locking questions goes for the other Netgraph > nodes that connected to the driver node. i want very > simple locks to do the following: > > 1) handle timeouts with timeout(9)/untimeout(9) - > my _biggest_ concern. all i could find in -current is > everyone use splXXX/splx :( is it broken on SMP? yes see above... I assume you are running on -current? > > 2) modify node's internal data structure in a safe way. > i'm talking about things like linked lists, queues > etc. if you are going to modify a node you need to take out a write lock on the device. There are various ways to do this: 1/ the node (or someone else) uses NG_NODE_FORCE_WRITER(node); this means that ALL incoming requests to this node are assumed to change state, even if they are just data, and so they will always get exclusive locks. 2/use NG_HOOK_FORCE_WRITER(hook) on a particular hook. Any daa arriving via this hook will insist on getting an exclusive lock. 3/ ng_send_fn() will always assume it has to get an exclusive lock. So making changes via a queued function is always safe. 4/ arriveing control messages will assume they need an exclusive lock. So making changes via a control message is always safe. 5/ any arriving item with the NGQF_WRITER bit set in item->el_flags will be treated as a writer, regardless of whether it is data or control or function. Actually it is a negative bit. item->el_flags &= ~NGQF_READER; is how that is achieved. (maybe I should fix/change that) > > since splXXX(9) functions are no longer relevant in > -current (please correct me if i wrong), i was looking > at mutex(9). i have noticed several device drivers that > also use Netgraph (if_ar, if_sr, if_lmc and udbp), and > they use MTX_DEF mutexes and splXXX(9) functions. is that > OK with Netgraph? the man page says that MTX_DEF mutexes > _will_ context switch when they are already held. try not use these. they shoould work but might stall the netgraph system. > > can/should i use MTX_SPIN mutexes? i have tried to use > them, but WITNESS code gets very upset (panic) unless i > modify "order_lists" in kern/subr_wintess.c. i would > rather not do it, since i'm not fully aware of what's > going on. No, use the built in locking. > > any other ways to handle that? i had crazy idea to write > a Netgraph "timeout" node, that does nothing but accepts > requests to set/remove timeout and send message back when > timeout has expired. it won't solve timeout problem, but > put it into one place. Use the ng_send_fn() call. ng_timeout(node, args...) { NG_NODE_REF(node); NG_NODE_PRIVATE(node)->priv_callout_handle = timeout(my_timeout_fn, node, time); } void my_timeout(void *nd) { struct ng_node *node = nd; if (NG_NODE_IS_VALID(node) ng_send_fn(node, NULL, &my_real_timeout, NULL, 0); NG_NODE_UNREF(node); } void my_real_timeout(node_p node, hook_p hook, void *arg1, int arg2) { do_timeout_things(node); } This is GUARANTEED to be run with an exclusive writer lock on that node. Please let me know how this all works out. p.s. Netgraph question shouldalso be sent to -net > > thanks, > max > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 12:23:36 2002 Delivered-To: freebsd-current@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id BAB1337B41A for ; Sun, 3 Mar 2002 12:23:22 -0800 (PST) Received: from hamilton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 3 Mar 2002 20:23:22 +0000 (GMT) To: Poul-Henning Kamp Cc: cjclark@alum.mit.edu, current@FreeBSD.ORG Subject: Re: devfs(5) Permissions In-reply-to: Your message of "Sun, 03 Mar 2002 21:16:59 +0100." <25568.1015186619@critter.freebsd.dk> X-Request-Do: Date: Sun, 03 Mar 2002 20:23:21 +0000 From: David Malone Message-ID: <200203032023.aa92755@salmon.maths.tcd.ie> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > >Do you have any designs for this ruleset stuff? From what you said > >at BSDconEurope it will have to be fairly complicated to achieve > >the your aim of being better than a static permission for a given > >device. > Not really, the basic idea is just a linked list of rules: > name=="/dev/uscanner*" -> chmod 0644 > driver=="bpf" -> chown user > It's not too much work, I just havn't had the time for it yet. > (Junior Kernel Hackers can apply here :-) OK - I thought you had something much more complex in mind after your example: "plugging the nuclear reactor into the serial port where you had a a modem plugged in yesterday". I presume you'd push the rules in using sysclt or did you have something more filesystem like in mind? > >Otherwise, one option would just be to have devfs check for a file > >in the /dev directory it is mounted over and then use that files > >permissions as a default. That would at least get us back the > >features of the old /dev which we're missing now. > This is much harder than you think... I didn't for a moment think it might be easy ;-) David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 12:26:25 2002 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 674B637B405 for ; Sun, 3 Mar 2002 12:26:23 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g23KQBLv027343; Sun, 3 Mar 2002 21:26:11 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: David Malone Cc: cjclark@alum.mit.edu, current@FreeBSD.ORG Subject: Re: devfs(5) Permissions In-Reply-To: Your message of "Sun, 03 Mar 2002 20:23:21 GMT." <200203032023.aa92755@salmon.maths.tcd.ie> Date: Sun, 03 Mar 2002 21:26:11 +0100 Message-ID: <27342.1015187171@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200203032023.aa92755@salmon.maths.tcd.ie>, David Malone writes: >> Not really, the basic idea is just a linked list of rules: > >> name=="/dev/uscanner*" -> chmod 0644 >> driver=="bpf" -> chown user > >> It's not too much work, I just havn't had the time for it yet. >> (Junior Kernel Hackers can apply here :-) > >OK - I thought you had something much more complex in mind after >your example: "plugging the nuclear reactor into the serial port >where you had a a modem plugged in yesterday". No, that was to show why "persistence" is a bad idea. >I presume you'd push the rules in using sysclt or did you have >something more filesystem like in mind? Nope, just a sysctl. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 12:39:54 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.datanet.hu (mx1.datanet.hu [194.149.13.160]) by hub.freebsd.org (Postfix) with ESMTP id F129237B400 for ; Sun, 3 Mar 2002 12:39:49 -0800 (PST) Received: from fonix.adamsfamily.xx (nilus-922.adsl.datanet.hu [195.56.95.153]) by mx1.datanet.hu (DataNet) with ESMTP id 40438F85D for ; Sun, 3 Mar 2002 21:39:48 +0100 (CET) Received: from fonix.adamsfamily.xx (localhost [127.0.0.1]) by fonix.adamsfamily.xx (8.12.2/8.12.2) with ESMTP id g23KdmLb065749 for ; Sun, 3 Mar 2002 21:39:48 +0100 (CET) (envelope-from sziszi@bsd.hu) Received: (from cc@localhost) by fonix.adamsfamily.xx (8.12.2/8.12.2/Submit) id g23Kdmhj065748 for current@FreeBSD.ORG; Sun, 3 Mar 2002 21:39:48 +0100 (CET) X-Authentication-Warning: fonix.adamsfamily.xx: cc set sender to sziszi@bsd.hu using -f Date: Sun, 3 Mar 2002 21:39:48 +0100 From: Szilveszter Adam To: current@FreeBSD.ORG Subject: Re: devfs(5) Permissions Message-ID: <20020303203947.GC433@fonix.adamsfamily.xx> Mail-Followup-To: Szilveszter Adam , current@FreeBSD.ORG References: <200203032023.aa92755@salmon.maths.tcd.ie> <27342.1015187171@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27342.1015187171@critter.freebsd.dk> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Mar 03, 2002 at 09:26:11PM +0100, Poul-Henning Kamp wrote: > >OK - I thought you had something much more complex in mind after > >your example: "plugging the nuclear reactor into the serial port > >where you had a a modem plugged in yesterday". > > No, that was to show why "persistence" is a bad idea. Fortune(6), anyone?:-) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 12:48:24 2002 Delivered-To: freebsd-current@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id 38B3537B402 for ; Sun, 3 Mar 2002 12:48:19 -0800 (PST) Received: from elischer.org ([64.170.121.0]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GSF002GB0GIH7@mta6.snfc21.pbi.net> for current@FreeBSD.ORG; Sun, 03 Mar 2002 12:48:19 -0800 (PST) Date: Sun, 03 Mar 2002 12:47:03 -0800 From: Julian Elischer Subject: Re: devfs(5) Permissions To: Poul-Henning Kamp Cc: David Malone , cjclark@alum.mit.edu, current@FreeBSD.ORG Message-id: <3C828BC7.22A80633@elischer.org> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) Content-type: text/plain; charset=iso-8859-2 Content-transfer-encoding: 7BIT X-Accept-Language: en, hu References: <25568.1015186619@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > In message <20020303201018.GA88366@hamilton.maths.tcd.ie>, David Malone writes: > >On Sun, Mar 03, 2002 at 05:36:04PM +0100, Poul-Henning Kamp wrote: > >> In message <20020303083136.A84637@blossom.cjclark.org>, "Crist J. Clark" writes > >> : > >> >I've checked the manpages, the files in /etc, and Googled, and I can't > >> >find the answer. I am begining to worry there isn't one. How does one > >> >change the permissions on dynamically created devices? That is, when > >> >the node comes into existence, it has the permissions I want, and not > >> >necessarily the defaults. > >> > >> The overall plan is that it will be possible to push a ruleset into > >> the kernel which changes the defaults. ETA: this summer (If I have to > >> do it, if somebody wants to help code it it can probably be done faster). > > > >I have a very similar problem trying to sync my Handspring Visor > >as a regular user 'cos the devices only come into existance when > >you press the sync button. > > > >Do you have any designs for this ruleset stuff? From what you said > >at BSDconEurope it will have to be fairly complicated to achieve > >the your aim of being better than a static permission for a given > >device. > > Not really, the basic idea is just a linked list of rules: > > name=="/dev/uscanner*" -> chmod 0644 > driver=="bpf" -> chown user In the mean while they could temporarily hack their kernels to add the following code to tty_pty.c. (not tested) static int pty_default_owner_uid; static int pty_default_owner(SYSCTL_HANDLER_ARGS) { int error; int val; val = pty_default_owner_uid; error = sysctl_handle_int(oidp, &val, sizeof(int), req); if (error != 0 || req->newptr == NULL) return (error); if (your_favoutite_sanity_check(val)) { pty_default_owner_uid = val; } return (0); } SYSCTL_PROC(_kern, OID_AUTO, pty_default_owner, CTLTYPE_INT | CTLFLAG_RW, 0, sizeof(int), pty_set_owner_uid, "I", "owner for newly created ptys"); and then use pty_default_owner_uid in the make_dev() call. > > It's not too much work, I just havn't had the time for it yet. > (Junior Kernel Hackers can apply here :-) > > >Otherwise, one option would just be to have devfs check for a file > >in the /dev directory it is mounted over and then use that files > >permissions as a default. That would at least get us back the > >features of the old /dev which we're missing now. > > This is much harder than you think... > > -- > 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. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 13: 7:55 2002 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id CBB5737B400 for ; Sun, 3 Mar 2002 13:07:50 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g23L7I000782; Sun, 3 Mar 2002 13:07:19 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200203032107.g23L7I000782@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Vladimir B. " Grebenschikov Cc: current@FreeBSD.ORG Subject: Re: ACPI issues and questions (Dell Inspiron 3700) In-reply-to: Your message of "03 Mar 2002 14:31:05 +0300." <1015155065.1775.2.camel@vbook.express.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 03 Mar 2002 13:07:18 -0800 From: Michael Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > So try adding > > > {0x10f0a34d, NULL} > > > to sio_ids in /sys/dev/sio/sio_isa.c > > > > It works: > > > > sio0 port 0x3f8-0x3ff irq 4 on acpi0 > > sio0: type 16550A > > sio1 port 0x280-0x287,0x2f8-0x2ff irq 3 on acpi0 > > sio1: type 16550A > > I have tried this patch for Sony VAIO PCG-Z505S > And it works ! > > Corresponding part of acpidump: > > Device(FIR_) { > Name(_HID, 0x10f0a34d) > > (exactly same number) > > sio0 port 0x3f8-0x3ff irq 4 on acpi0 > sio0: type 16550A > sio1 port 0x140-0x147,0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > > May be it is time to commit this line ? No. This would mean that sio(4) will attach to any IrDa port and preclude an IrDa-specific driver from doing so. If any variation of this patch is committed, at the very least sio(4) should return a lower preference than 0 for it's match. -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 13:19:36 2002 Delivered-To: freebsd-current@freebsd.org Received: from sduwebship.student.umd.edu (sduwebship.student.umd.edu [129.2.156.15]) by hub.freebsd.org (Postfix) with ESMTP id A643C37B405 for ; Sun, 3 Mar 2002 13:19:27 -0800 (PST) Received: from localhost (philip@localhost) by sduwebship.student.umd.edu (8.11.6/8.11.6) with ESMTP id g23GMIc96279; Sun, 3 Mar 2002 16:22:18 GMT (envelope-from philip@sduwebship.student.umd.edu) Date: Sun, 3 Mar 2002 16:22:17 +0000 (GMT) From: "Philip M. Gollucci" To: Terry Lambert Cc: Riccardo Torrini , Thierry Herbelot , Subject: Re: 5.0-CURRENT makebuild world fails In-Reply-To: <3C82720F.7D64079D@mindspring.com> Message-ID: <20020303162024.E96218-100000@sduwebship.student.umd.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I took your advice. sysctl -w kern.maxfiles=50000 cd /usr/src make buildworld same file, same place, same error. I did notice that If I do that one compile manually... that file works... But the same fix _does not_ work for the next one. Thanks again. kern.maxvnodes: 49149 kern.maxproc: 1044 kern.maxfiles: 50000 kern.argmax: 65536 kern.maxfilesperproc: 1879 kern.maxprocperuid: 939 kern.ipc.maxsockbuf: 262144 kern.ipc.somaxconn: 128 kern.ipc.max_linkhdr: 16 kern.ipc.max_protohdr: 40 kern.ipc.max_hdr: 56 kern.ipc.max_datalen: 156 kern.ipc.shmmax: 33554432 kern.ipc.maxsockets: 2088 kern.kq_calloutmax: 4096 kern.maxusers: 64 >>> stage 4: building libraries -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.0 GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/install.sh" PATH=/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 -DNOHTML -DNOINFO -DNOMAN -DNOFSCHG libraries cd /usr/src/lib/csu/i386-elf; make depend; make all; make install rm -f .depend mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common /usr/src/lib/csu/i386-elf/crt1.c cd /usr/src/lib/csu/i386-elf; make _EXTRADEPEND cc -O2 -Wall -pipe -pedantic -ansi -march=pentiumpro -elf -Wall -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -c /usr/src/lib/csu/i386-elf/crt1.c -o crt1.o /usr/src/lib/csu/i386-elf/crt1.c: In function `_start': /usr/src/lib/csu/i386-elf/crt1.c:70: warning: ANSI C forbids braced-groups within expressions cc: Internal compiler error: program cc1 got fatal signal 11 *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 END ------------------------------------------------------------------------------ Philip M. Gollucci (p6m7g8) philip@p6m7g8.com 301.314.3118 Science, Discovery, & the Universe (UMCP) Webmaster & Webship Teacher URL: http://www.sdu.umd.edu EJPress.com Database/PERL Programmer & System Admin URL : http://www.ejournalpress.com Resume : http://p6m7g8.com/Work/index.html On Sun, 3 Mar 2002, Terry Lambert wrote: > Riccardo Torrini wrote: > > On 03-Mar-2002 (08:20:46/GMT) Thierry Herbelot wrote: > > >> cc: Internal compiler error: program cc1 got fatal signal 11 > > > > > a signal 11 is generally linked to bad memory chips > > > > ...and/or overclocked CPU :) > > And/or a pmap code bug. > > At boot time, try setting kern.maxfile to 50000 or more in > the loader, and then booting normally. > > -- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 13:31:27 2002 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 99D4637B404; Sun, 3 Mar 2002 13:31:22 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g23LVLi66701; Sun, 3 Mar 2002 14:31:21 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g23LVKL64461; Sun, 3 Mar 2002 14:31:20 -0700 (MST) (envelope-from imp@village.org) Date: Sun, 03 Mar 2002 14:30:27 -0700 (MST) Message-Id: <20020303.143027.105075680.imp@village.org> To: philip@sduwebship.student.umd.edu Cc: freebsd-questions@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: 5.0-CURRENT makebuild world fails From: "M. Warner Losh" In-Reply-To: <20020303023045.E93659-100000@sduwebship.student.umd.edu> References: <20020303023045.E93659-100000@sduwebship.student.umd.edu> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020303023045.E93659-100000@sduwebship.student.umd.edu> "Philip M. Gollucci" writes: : cc -O2 -Wall -pipe -pedantic -ansi -march=pentiumpro -elf -Wall : -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -c : /usr/src/lib/csu/i386-elf/crt1.c:70: warning: ANSI C forbids braced-groups : within expressions : cc: Internal compiler error: program cc1 got fatal signal 11 Looks like the C compiler really didn't like the braced-groups within expressions. #define get_rtld_cleanup() \ ({ fptr __value; \ __asm__("movl %%edx,%0" : "=rm"(__value)); \ __value; }) ... rtld_cleanup = get_rtld_cleanup(); yet both of these parts of this file hasn't been changed since 1998! appears to be the real reason since this file is compiled -ansi -pedantic. And it would appear on the surface to still be a problem. However, it looks like my version isn't compiling it -ansi -pedantic: cc -O -pipe -elf -Wall -fkeep-inline-functions -I/dell/imp/FreeBSD/src/lib/csu/i386-elf/../common -DGCRT -c -o gcrt1.o /dell/imp/FreeBSD/src/lib/csu/i386-elf/crt1.c So something really strange is going on, but I'm not sure what. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 13:36:21 2002 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 07E0D37B404; Sun, 3 Mar 2002 13:36:19 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g23LaHi66724; Sun, 3 Mar 2002 14:36:18 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g23LaHL64481; Sun, 3 Mar 2002 14:36:17 -0700 (MST) (envelope-from imp@village.org) Date: Sun, 03 Mar 2002 14:35:24 -0700 (MST) Message-Id: <20020303.143524.04493774.imp@village.org> To: msmith@FreeBSD.ORG Cc: vova@express.ru, current@FreeBSD.ORG Subject: Re: ACPI issues and questions (Dell Inspiron 3700) From: "M. Warner Losh" In-Reply-To: <200203032107.g23L7I000782@mass.dis.org> References: <1015155065.1775.2.camel@vbook.express.ru> <200203032107.g23L7I000782@mass.dis.org> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <200203032107.g23L7I000782@mass.dis.org> Michael Smith writes: : No. This would mean that sio(4) will attach to any IrDa port and : preclude an IrDa-specific driver from doing so. : : If any variation of this patch is committed, at the very least sio(4) : should return a lower preference than 0 for it's match. But would an IrDA specific driver do anything differently than sio would? SIR is effectively an 16550 UART from what I've seen so far. Maybe I'm missing something? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 13:43: 5 2002 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (dhcp45-21.dis.org [216.240.45.21]) by hub.freebsd.org (Postfix) with ESMTP id 0AD3237B402; Sun, 3 Mar 2002 13:43:02 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.6) with ESMTP id g23LgV001032; Sun, 3 Mar 2002 13:42:31 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200203032142.g23LgV001032@mass.dis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "M. Warner Losh" Cc: msmith@FreeBSD.ORG, vova@express.ru, current@FreeBSD.ORG Subject: Re: ACPI issues and questions (Dell Inspiron 3700) In-reply-to: Your message of "Sun, 03 Mar 2002 14:35:24 MST." <20020303.143524.04493774.imp@village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 03 Mar 2002 13:42:31 -0800 From: Michael Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > In message: <200203032107.g23L7I000782@mass.dis.org> > Michael Smith writes: > : No. This would mean that sio(4) will attach to any IrDa port and > : preclude an IrDa-specific driver from doing so. > : > : If any variation of this patch is committed, at the very least sio(4) > : should return a lower preference than 0 for it's match. > > But would an IrDA specific driver do anything differently than sio > would? SIR is effectively an 16550 UART from what I've seen so far. > Maybe I'm missing something? Well, except that it has no flow control, is only half-duplex, and you might want to attach an IrDa stack to the device. If all the IrDa stack work is being done in userland, then this probably makes sense. If not, then at the very least, sio(4) needs to behave differently in the case of a SIR port. -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 13:49:43 2002 Delivered-To: freebsd-current@freebsd.org Received: from sduwebship.student.umd.edu (sduwebship.student.umd.edu [129.2.156.15]) by hub.freebsd.org (Postfix) with ESMTP id 21C9837B400; Sun, 3 Mar 2002 13:49:36 -0800 (PST) Received: from localhost (philip@localhost) by sduwebship.student.umd.edu (8.11.6/8.11.6) with ESMTP id g23GqaE96370; Sun, 3 Mar 2002 16:52:36 GMT (envelope-from philip@sduwebship.student.umd.edu) Date: Sun, 3 Mar 2002 16:52:35 +0000 (GMT) From: "Philip M. Gollucci" To: "M. Warner Losh" Cc: , Subject: Re: 5.0-CURRENT makebuild world fails In-Reply-To: <20020303.143027.105075680.imp@village.org> Message-ID: <20020303164954.Q96218-100000@sduwebship.student.umd.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I remembered a while back, I added BDECFLAGS= -W -Wall -ansi -pedantic -Wbad-function-cast -Wcast-align \ -Wcast-qual -Wchar-subscripts -Winline \ -Wmissing-prototypes -Wnested-externs -Wpointer-arith \ -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings to my CFLAGS so I could try and fix all the damn warnings. After removing that so my CFLAGS are the default CFLAGS= -O2 -Wall -pipe cd /usr/src makebuild world Heres the line now. cc -O2 -Wall -pipe -march=pentiumpro -elf -Wall -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -DGCRT -c -o gcrt1.o /usr/src/lib/csu/i386-elf/crt1.c Still get the signal 11. Same file. Same place. Only no warnings about the braces this time. END ------------------------------------------------------------------------------ Philip M. Gollucci (p6m7g8) philip@p6m7g8.com 301.314.3118 Science, Discovery, & the Universe (UMCP) Webmaster & Webship Teacher URL: http://www.sdu.umd.edu EJPress.com Database/PERL Programmer & System Admin URL : http://www.ejournalpress.com Resume : http://p6m7g8.com/Work/index.html On Sun, 3 Mar 2002, M. Warner Losh wrote: > In message: <20020303023045.E93659-100000@sduwebship.student.umd.edu> > "Philip M. Gollucci" writes: > : cc -O2 -Wall -pipe -pedantic -ansi -march=pentiumpro -elf -Wall > : -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -c > : /usr/src/lib/csu/i386-elf/crt1.c:70: warning: ANSI C forbids braced-groups > : within expressions > : cc: Internal compiler error: program cc1 got fatal signal 11 > > Looks like the C compiler really didn't like the braced-groups within > expressions. > > #define get_rtld_cleanup() \ > ({ fptr __value; \ > __asm__("movl %%edx,%0" : "=rm"(__value)); \ > __value; }) > ... > rtld_cleanup = get_rtld_cleanup(); > yet both of these parts of this file hasn't been changed since 1998! > > appears to be the real reason since this file is compiled -ansi > -pedantic. And it would appear on the surface to still be a problem. > However, it looks like my version isn't compiling it -ansi -pedantic: > > cc -O -pipe -elf -Wall -fkeep-inline-functions > -I/dell/imp/FreeBSD/src/lib/csu/i386-elf/../common -DGCRT -c -o > gcrt1.o /dell/imp/FreeBSD/src/lib/csu/i386-elf/crt1.c > > So something really strange is going on, but I'm not sure what. > > Warner > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 13:51:25 2002 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 8081137B405; Sun, 3 Mar 2002 13:51:13 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g23LpCi66887; Sun, 3 Mar 2002 14:51:12 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g23LpBL64651; Sun, 3 Mar 2002 14:51:11 -0700 (MST) (envelope-from imp@village.org) Date: Sun, 03 Mar 2002 14:50:19 -0700 (MST) Message-Id: <20020303.145019.16784935.imp@village.org> To: philip@sduwebship.student.umd.edu Cc: freebsd-questions@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: 5.0-CURRENT makebuild world fails From: "M. Warner Losh" In-Reply-To: <20020303164954.Q96218-100000@sduwebship.student.umd.edu> References: <20020303.143027.105075680.imp@village.org> <20020303164954.Q96218-100000@sduwebship.student.umd.edu> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020303164954.Q96218-100000@sduwebship.student.umd.edu> "Philip M. Gollucci" writes: : Still get the signal 11. Same file. Same place. : Only no warnings about the braces this time. What happens if you cd to src/lib/csu/i386-elf and do a make? You make need to do that as root... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 13:55:32 2002 Delivered-To: freebsd-current@freebsd.org Received: from vbook.express.ru (vbook.nc.express.ru [212.24.37.35]) by hub.freebsd.org (Postfix) with ESMTP id CB5D537B405 for ; Sun, 3 Mar 2002 13:55:27 -0800 (PST) Received: from localhost ([127.0.0.1]) by vbook.express.ru with esmtp (Exim 3.33 #1) id 16hdx5-000ELK-00; Mon, 04 Mar 2002 00:55:31 +0300 Subject: Re: ACPI issues and questions (Dell Inspiron 3700) From: "Vladimir B. " Grebenschikov To: current@FreeBSD.ORG Cc: imp@village.org In-Reply-To: <200203032142.g23LgV001032@mass.dis.org> References: <200203032142.g23LgV001032@mass.dis.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 04 Mar 2002 00:55:31 +0300 Message-Id: <1015192531.994.5.camel@vbook.express.ru> Mime-Version: 1.0 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 2002-03-04 at 00:42, Michael Smith wrote: > > But would an IrDA specific driver do anything differently than sio > > would? SIR is effectively an 16550 UART from what I've seen so far. > > Maybe I'm missing something? > > Well, except that it has no flow control, is only half-duplex, and you > might want to attach an IrDa stack to the device. > > If all the IrDa stack work is being done in userland, then this probably > makes sense. If not, then at the very least, sio(4) needs to behave > differently in the case of a SIR port. The only implementation of IrDA stack for FreeBSD I know (not finished) uses netgraph interface of sio driver. I am use Infra-red port to access my HP200LX via IR (no IrDA) with lxtools package And Linux use /dev/ttyS? to refer infra-red ports. -- TSB "Russian Express", Moscow Vladimir B. Grebenschikov, vova@express.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 13:57:24 2002 Delivered-To: freebsd-current@freebsd.org Received: from sduwebship.student.umd.edu (sduwebship.student.umd.edu [129.2.156.15]) by hub.freebsd.org (Postfix) with ESMTP id 371BE37B405; Sun, 3 Mar 2002 13:57:16 -0800 (PST) Received: from localhost (philip@localhost) by sduwebship.student.umd.edu (8.11.6/8.11.6) with ESMTP id g23H0Ot96411; Sun, 3 Mar 2002 17:00:24 GMT (envelope-from philip@sduwebship.student.umd.edu) Date: Sun, 3 Mar 2002 17:00:23 +0000 (GMT) From: "Philip M. Gollucci" To: "M. Warner Losh" Cc: , Subject: Re: 5.0-CURRENT makebuild world fails In-Reply-To: <20020303.145019.16784935.imp@village.org> Message-ID: <20020303165726.J96218-100000@sduwebship.student.umd.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG VERY INTERESTING but then if I go back to /usr/src and try to complete the build make buildworld -DNOCLEAN I get the same error cc -O2 -Wall -pipe -march=pentiumpro -I/usr/src/gnu/lib/csu/../../../contrib/gcc.295/config -I. -DIN_GCC -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-omit-frame-pointer -g0 -DCRT_END -c -o crtend.o /usr/src/gnu/lib/csu/../../../contrib/gcc.295/crtstuff.c cc: Internal compiler error: program cc1 got fatal signal 11 *** Error code 1 p6m7g8# cd /usr/src/lib/csu/i386-elf p6m7g8# make clean rm -f a.out crt1.o crti.o crtn.o gcrt1.o crt1.o crti.o crtn.o crt1.o.tmp crti.o.tmp crtn.o.tmp gcrt1.o.tmp crt1.o.tmp crti.o.tmp crtn.o.tmp rm -f lib.a # llib-l.ln rm -f crt1.po crti.po crtn.po gcrt1.po crt1.po crti.po crtn.po crt1.po.tmp crti.po.tmp crtn.po.tmp gcrt1.po.tmp crt1.po.tmp crti.po.tmp crtn.po.tmp lib_p.a rm -f crt1.So crti.So crtn.So gcrt1.So crt1.So crti.So crtn.So crt1.so crti.so crtn.so gcrt1.so crt1.so crti.so crtn.so crt1.So.tmp crti.So.tmp crtn.So.tmp gcrt1.So.tmp crt1.So.tmp crti.So.tmp crtn.So.tmp lib.so.* lib.so lib_pic.a p6m7g8# make cc -O2 -Wall -pipe -march=pentiumpro -elf -Wall -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -c /usr/src/lib/csu/i386-elf/crt1.c -o crt1.o cc -I/usr/src/lib/csu/i386-elf/../common -c /usr/src/lib/csu/i386-elf/crti.S -o crti.o cc -I/usr/src/lib/csu/i386-elf/../common -c /usr/src/lib/csu/i386-elf/crtn.S -o crtn.o cc -O2 -Wall -pipe -march=pentiumpro -elf -Wall -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -DGCRT -c -o gcrt1.o /usr/src/lib/csu/i386-elf/crt1.c p6m7g8# END ------------------------------------------------------------------------------ Philip M. Gollucci (p6m7g8) philip@p6m7g8.com 301.314.3118 Science, Discovery, & the Universe (UMCP) Webmaster & Webship Teacher URL: http://www.sdu.umd.edu EJPress.com Database/PERL Programmer & System Admin URL : http://www.ejournalpress.com Resume : http://p6m7g8.com/Work/index.html On Sun, 3 Mar 2002, M. Warner Losh wrote: > In message: <20020303164954.Q96218-100000@sduwebship.student.umd.edu> > "Philip M. Gollucci" writes: > : Still get the signal 11. Same file. Same place. > : Only no warnings about the braces this time. > > What happens if you cd to src/lib/csu/i386-elf and do a make? You > make need to do that as root... > > Warner > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 14:28:45 2002 Delivered-To: freebsd-current@freebsd.org Received: from hilfy.ece.cmu.edu (HILFY.ECE.CMU.EDU [128.2.136.133]) by hub.freebsd.org (Postfix) with ESMTP id 56B4C37B404; Sun, 3 Mar 2002 14:28:40 -0800 (PST) Received: from rushlight.kf8nh.apk.net (root@VPN58.ECE.CMU.EDU [128.2.138.58]) by hilfy.ece.cmu.edu (8.11.0/8.8.8) with ESMTP id g23MRwT05828; Sun, 3 Mar 2002 17:27:58 -0500 (EST) Received: (from allbery@localhost) by rushlight.kf8nh.apk.net (8.11.6/8.11.6) id g23MS0a38974; Sun, 3 Mar 2002 17:28:00 -0500 (EST) (envelope-from allbery@ece.cmu.edu) X-Authentication-Warning: rushlight.kf8nh.apk.net: allbery set sender to allbery@ece.cmu.edu using -f Subject: Re: ACPI issues and questions (Dell Inspiron 3700) From: "Brandon S. Allbery " KF8NH To: Michael Smith Cc: "M. Warner Losh" , vova@express.ru, current@FreeBSD.ORG In-Reply-To: <200203032142.g23LgV001032@mass.dis.org> References: <200203032142.g23LgV001032@mass.dis.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 03 Mar 2002 17:28:00 -0500 Message-Id: <1015194480.33938.2.camel@rushlight.kf8nh.apk.net> Mime-Version: 1.0 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 2002-03-03 at 16:42, Michael Smith wrote: > Well, except that it has no flow control, is only half-duplex, and you > might want to attach an IrDa stack to the device. > > If all the IrDa stack work is being done in userland, then this probably > makes sense. If not, then at the very least, sio(4) needs to behave > differently in the case of a SIR port. While IrDA support is in userland at the moment (comms/birda port), someone is working on a netgraph interface for IrDA. I'm under the impression that this will include FIR device drivers; but since it's also based on birda, it will likely use sio for SIR devices. (Although the person(s) doing the ng work should probably speak up and correct me now....) -- brandon s. allbery [linux][solaris][japh][freebsd] allbery@kf8nh.apk.net system administrator [openafs][heimdal][too many hats] allbery@ece.cmu.edu electrical and computer engineering KF8NH carnegie mellon university ["better check the oblivious first" -ke6sls] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 16: 9:24 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 8EB3C37B402 for ; Sun, 3 Mar 2002 16:09:19 -0800 (PST) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by mail.imp.ch (8.11.6/8.11.6) with ESMTP id g2409Va08080 for ; Mon, 4 Mar 2002 01:09:31 +0100 (CET) Date: Mon, 4 Mar 2002 01:10:58 +0100 (CET) From: Martin Blapp To: Subject: help needed: freebsd gcc bug breaks STLport and OpenOffice Message-ID: <20020304010901.J46469-100000@levais.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, It looks like our modified FreeBSD GCC breaks the STLport tests, as it breaks OpenOffice too. If one uses a normal unmodified stock gcc version (gcc 2.95.2 or 2.95.3), and compiles it on STABLE or CURRENT, the coredump goes away. Note that there are no special flags, only c++ -pthread -Wall -g -O where specified. STLport-4.5.3/test/eh# gmake -f gcc-freebsd.mak LD_LIBRARY_PATH="../../lib:" ././eh_test -s 100 ././eh_test : Exception handling testsuite. Setting 100 as base for random sizes. iteration #0 EH test : algobase [algobase] :testing uninitialized_copy() (weak) ... 101 try successful [algobase] :testing uninitialized_fill() (weak) ... 101 try successful [algobase] :testing uninitialized_fill_n() (weak) ... 101 try successful EH test : algo EH test : testing algo.h [algo] :testing inplace_merge #1() (weak) ... 350 try successful [algo] :testing inplace_merge() #2 (weak) ... 350 try successful [algo] :testing stable_sort() #1 (weak) ... 1336 try successful [algo] :testing stable_sort() #2 (weak) ... 1336 try successful [algo] :testing stable_partition() (weak) ... 345 try successful EH test : vector [vector] :testing n-size constructor (const) ... 95 try successful [vector] :testing pointer range constructor (const) ... Bus error - core dumped gmake: *** [eh_test.out] Error 138 Thank you for any help Martin Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 16:39:51 2002 Delivered-To: freebsd-current@freebsd.org Received: from ns.sshel.com (ns.sshel.com [211.115.209.7]) by hub.freebsd.org (Postfix) with ESMTP id 23E8137B404 for ; Sun, 3 Mar 2002 16:39:38 -0800 (PST) Received: from saturn (gaia.sds.co.kr [210.97.227.110]) (authenticated) by ns.sshel.com (8.11.3/8.11.2) with ESMTP id g240dbo08593 for ; Mon, 4 Mar 2002 09:39:37 +0900 From: "syous" To: Subject: unsubscribe Date: Mon, 4 Mar 2002 09:38:17 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3.0.6.32.20020301191351.00daaf48@imatowns.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG dW5zdWJzY3JpYmUNCm1haWxpbmctYXJjaGlldmVAc3lvdXMuY29t To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 17: 4:59 2002 Delivered-To: freebsd-current@freebsd.org Received: from shidahara1.planet.sci.kobe-u.ac.jp (shidahara1.planet.sci.kobe-u.ac.jp [133.30.68.253]) by hub.freebsd.org (Postfix) with ESMTP id 81E4737B404 for ; Sun, 3 Mar 2002 17:04:57 -0800 (PST) Received: from shidahara1.planet.sci.kobe-u.ac.jp (localhost [127.0.0.1]) by shidahara1.planet.sci.kobe-u.ac.jp (8.9.3/8.9.3) with ESMTP id KAA34309 for ; Mon, 4 Mar 2002 10:04:17 +0900 (JST) (envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp) Message-Id: <200203040104.KAA34309@shidahara1.planet.sci.kobe-u.ac.jp> To: current@freebsd.org Subject: Re: ACPI issues and questions (Dell Inspiron 3700) In-reply-to: Your message of "Sun, 03 Mar 2002 13:07:18 PST." <200203032107.g23L7I000782@mass.dis.org> Date: Mon, 04 Mar 2002 10:04:17 +0900 From: Takanori Watanabe Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200203032107.g23L7I000782@mass.dis.org>, Michael Smith wrote: > >No. This would mean that sio(4) will attach to any IrDa port and >preclude an IrDa-specific driver from doing so. I think so too. But .... >If any variation of this patch is committed, at the very least sio(4) >should return a lower preference than 0 for it's match. Sorry, I've been committed the code, because some IrDA controller(generic one) already there, there are no such driver *NOW* and some people may become happy with /usr/ports/comm/birda port. Takanori Watanabe Public Key Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 17:16:14 2002 Delivered-To: freebsd-current@freebsd.org Received: from nebula.anchoragerescue.org (cable-115-7-237-24.anchorageak.net [24.237.7.115]) by hub.freebsd.org (Postfix) with ESMTP id 03AA237B404; Sun, 3 Mar 2002 17:16:08 -0800 (PST) Received: from there (galaxy.anchoragerescue.org [24.237.7.95]) by nebula.anchoragerescue.org (Postfix) with SMTP id 8CD4FB2ED; Sun, 3 Mar 2002 16:16:00 -0900 (AKST) Content-Type: text/plain; charset="iso-8859-1" From: Beech Rintoul To: "M. Warner Losh" , philip@sduwebship.student.umd.edu Subject: Re: 5.0-CURRENT makebuild world fails Date: Sun, 3 Mar 2002 16:16:00 -0900 X-Mailer: KMail [version 1.3] Cc: freebsd-questions@FreeBSD.ORG, current@FreeBSD.ORG References: <20020303023045.E93659-100000@sduwebship.student.umd.edu> <20020303.143027.105075680.imp@village.org> In-Reply-To: <20020303.143027.105075680.imp@village.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020304011600.8CD4FB2ED@nebula.anchoragerescue.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday 03 March 2002 12:30 pm, M. Warner Losh wrote: > In message: <20020303023045.E93659-100000@sduwebship.student.umd.edu> > > "Philip M. Gollucci" writes: > : cc -O2 -Wall -pipe -pedantic -ansi -march=pentiumpro -elf -Wall > : -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -c > : /usr/src/lib/csu/i386-elf/crt1.c:70: warning: ANSI C forbids > : braced-groups within expressions > : cc: Internal compiler error: program cc1 got fatal signal 11 > > Looks like the C compiler really didn't like the braced-groups within > expressions. > > #define get_rtld_cleanup() \ > ({ fptr __value; \ > __asm__("movl %%edx,%0" : "=rm"(__value)); \ > __value; }) > ... > rtld_cleanup = get_rtld_cleanup(); > yet both of these parts of this file hasn't been changed since 1998! > > appears to be the real reason since this file is compiled -ansi > -pedantic. And it would appear on the surface to still be a problem. > However, it looks like my version isn't compiling it -ansi -pedantic: > > cc -O -pipe -elf -Wall -fkeep-inline-functions > -I/dell/imp/FreeBSD/src/lib/csu/i386-elf/../common -DGCRT -c -o > gcrt1.o /dell/imp/FreeBSD/src/lib/csu/i386-elf/crt1.c > > So something really strange is going on, but I'm not sure what. > > Warner > FWIW, I just did a make world & kernel with no probs. Box is a 500MHz Celeron. uname -a: FreeBSD nova.anchoragerescue.org 5.0-CURRENT FreeBSD 5.0-CURRENT #7: Sun Mar 3 13:59:51 AKST 2002 akbeech@nova.anchoragerescue.org:/usr/obj/usr/src/sys/NOVA i386 Beech -- ------------------------------------------------------------------- Beech Rintoul - IT Manager - Instructor - akbeech@anchoragerescue.org /"\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ ----------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 17:52:18 2002 Delivered-To: freebsd-current@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 8C98437B402 for ; Sun, 3 Mar 2002 17:52:12 -0800 (PST) Received: from pool0165.cvx40-bradley.dialup.earthlink.net ([216.244.42.165] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16hhdq-0002zi-00; Sun, 03 Mar 2002 17:51:54 -0800 Message-ID: <3C82D32B.1E1A6E9A@mindspring.com> Date: Sun, 03 Mar 2002 17:51:39 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Poul-Henning Kamp , David Malone , cjclark@alum.mit.edu, current@FreeBSD.ORG Subject: Re: devfs(5) Permissions References: <25568.1015186619@critter.freebsd.dk> <3C828BC7.22A80633@elischer.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've often thought that owner, group, and mode should be defaulted in the registration process for the device. This would let defaults be set in the source code, so in the worst case, you can rebuild the kernel to get them. This would also allow low granularity persistance to be handled in teh same way that kernel visual configuration handles it, or by minimally permitting modification of the data section of the kernel binary. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 17:54:37 2002 Delivered-To: freebsd-current@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id BDF7B37B400; Sun, 3 Mar 2002 17:54:32 -0800 (PST) Received: from pool0165.cvx40-bradley.dialup.earthlink.net ([216.244.42.165] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16hhgN-0006Ag-00; Sun, 03 Mar 2002 17:54:32 -0800 Message-ID: <3C82D3C9.C7631074@mindspring.com> Date: Sun, 03 Mar 2002 17:54:17 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Smith Cc: "Vladimir B. Grebenschikov" , current@FreeBSD.ORG Subject: Re: ACPI issues and questions (Dell Inspiron 3700) References: <200203032107.g23L7I000782@mass.dis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Michael Smith wrote: > > May be it is time to commit this line ? > > No. This would mean that sio(4) will attach to any IrDa port and > preclude an IrDa-specific driver from doing so. I'd be happy to have one of these, if you have an IrDa driver lying around for FreeBSD, and haven't committed it yet. > If any variation of this patch is committed, at the very least sio(4) > should return a lower preference than 0 for it's match. This makes sense; then if anyone ever writes an IrDa driver for FreeBSD some time in the next six years, it will displace the serial driver, which at least will work today -- with this patch. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 17:57:21 2002 Delivered-To: freebsd-current@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 42F1A37B400; Sun, 3 Mar 2002 17:57:20 -0800 (PST) Received: from pool0165.cvx40-bradley.dialup.earthlink.net ([216.244.42.165] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16hhj4-0001h6-00; Sun, 03 Mar 2002 17:57:18 -0800 Message-ID: <3C82D470.8043DE47@mindspring.com> Date: Sun, 03 Mar 2002 17:57:04 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "M. Warner Losh" Cc: msmith@FreeBSD.ORG, vova@express.ru, current@FreeBSD.ORG Subject: Re: ACPI issues and questions (Dell Inspiron 3700) References: <1015155065.1775.2.camel@vbook.express.ru> <200203032107.g23L7I000782@mass.dis.org> <20020303.143524.04493774.imp@village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "M. Warner Losh" wrote: > But would an IrDA specific driver do anything differently than sio > would? SIR is effectively an 16550 UART from what I've seen so far. > Maybe I'm missing something? Yes; it would allow remote control protocols, and some IrDa self-clocking protocols that aren't possible if you treat the thing as an internally clocked 16550 with no special capabilities. It's like a parallel port that supports mode 1, 2, and 3, instead of just mode 1. Not that there's a driver for it that should prevent the SIO patch going in so we can at least use printers and PPP over IR, if we want. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 18:19:10 2002 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id D986F37B400 for ; Sun, 3 Mar 2002 18:19:05 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g242J4i67771; Sun, 3 Mar 2002 19:19:04 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g242J3L65626; Sun, 3 Mar 2002 19:19:04 -0700 (MST) (envelope-from imp@village.org) Date: Sun, 03 Mar 2002 19:17:56 -0700 (MST) Message-Id: <20020303.191756.45649942.imp@village.org> To: takawata@shidahara1.planet.sci.kobe-u.ac.jp Cc: current@FreeBSD.ORG Subject: Re: ACPI issues and questions (Dell Inspiron 3700) From: "M. Warner Losh" In-Reply-To: <200203040104.KAA34309@shidahara1.planet.sci.kobe-u.ac.jp> References: <200203032107.g23L7I000782@mass.dis.org> <200203040104.KAA34309@shidahara1.planet.sci.kobe-u.ac.jp> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <200203040104.KAA34309@shidahara1.planet.sci.kobe-u.ac.jp> Takanori Watanabe writes: : Sorry, I've been committed the code, because some IrDA : controller(generic one) already there, there are no such driver : *NOW* and some people may become happy with /usr/ports/comm/birda : port. Traditionally, FreeBSD has done this. Allowed a driver to claim a device and when a new device is written that wants to use it, then the original driver is modified to not claim it, or claim it at a lower priority. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Mar 3 20:29:34 2002 Delivered-To: freebsd-current@freebsd.org Received: from smtp.sw.oz.au (smtp.sw.oz.au [203.31.96.1]) by hub.freebsd.org (Postfix) with ESMTP id 22D2337B404 for ; Sun, 3 Mar 2002 20:29:31 -0800 (PST) Received: from swag.sw.oz.au (swag.sw.oz.au [192.41.203.35]) by smtp.sw.oz.au (8.8.8+Sun/8.8.8) with ESMTP id PAA12697; Mon, 4 Mar 2002 15:29:00 +1100 (EST) Received: (from vance@localhost) by swag.sw.oz.au (8.8.8+Sun/8.8.8) id PAA12692; Mon, 4 Mar 2002 15:28:59 +1100 (EST) Date: Mon, 4 Mar 2002 15:28:59 +1100 From: Christopher Vance To: Thierry Herbelot Cc: "Philip M. Gollucci" , current@FreeBSD.ORG Subject: Re: 5.0-CURRENT makebuild world fails Message-ID: <20020304152859.A4355@aurema.com> References: <20020303023045.E93659-100000@sduwebship.student.umd.edu> <3C81DCDE.C95E4213@herbelot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C81DCDE.C95E4213@herbelot.com>; from thierry@herbelot.com on Sun, Mar 03, 2002 at 09:20:46AM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I had a consistent death-of-compiler in 4.5-STABLE a week or so back which looked like the compiler was knotted. I didn't see anything on the lists about it, and assumed it was something I did. So I saved my /etc, reinstalled bindist from 4.4 CD, restored /etc, and successfully did make world to catch up again. Can't help you with current, because I haven't tried compiling it for quite a while now... -- Christopher Vance To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Mar 4 2:10:28 2002 Delivered-To: freebsd-current@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id C1AD737B402 for ; Mon, 4 Mar 2002 02:10:21 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 4 Mar 2002 10:10:20 +0000 (GMT) Date: Mon, 4 Mar 2002 10:10:20 +0000 From: David Malone To: Poul-Henning Kamp Cc: cjclark@alum.mit.edu, current@FreeBSD.ORG Subject: Re: devfs(5) Permissions Message-ID: <20020304101020.GA61840@walton.maths.tcd.ie> References: <200203032023.aa92755@salmon.maths.tcd.ie> <27342.1015187171@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27342.1015187171@critter.freebsd.dk> User-Agent: Mutt/1.3.25i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Mar 03, 2002 at 09:26:11PM +0100, Poul-Henning Kamp wrote: > >I presume you'd push the rules in using sysclt or did you have > >something more filesystem like in mind? > > Nope, just a sysctl. I guess then you just need a sysctl which lets you read the rules for a given devfs mount point and another which lets you set the rules for a given defvs mount point. I don't know if we also need a global ruleset which is applied if the mount point speficic rules fail to match. The rules should be able to chmod and chown the nodes. Should it also be able to prevent the creation matching nodes also? You mentioned matching on the names drivers and nodes. Are there any other sorts of matching we are likely to need? David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Mar 4 2:16:32 2002 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 722C837B419 for ; Mon, 4 Mar 2002 02:16:21 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g24AG6Lv081594; Mon, 4 Mar 2002 11:16:06 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: David Malone Cc: cjclark@alum.mit.edu, current@FreeBSD.ORG Subject: Re: devfs(5) Permissions In-Reply-To: Your message of "Mon, 04 Mar 2002 10:10:20 GMT." <20020304101020.GA61840@walton.maths.tcd.ie> Date: Mon, 04 Mar 2002 11:16:06 +0100 Message-ID: <81593.1015236966@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020304101020.GA61840@walton.maths.tcd.ie>, David Malone writes: >On Sun, Mar 03, 2002 at 09:26:11PM +0100, Poul-Henning Kamp wrote: >> >I presume you'd push the rules in using sysclt or did you have >> >something more filesystem like in mind? >> >> Nope, just a sysctl. > >I guess then you just need a sysctl which lets you read the rules >for a given devfs mount point and another which lets you set the >rules for a given defvs mount point. I don't know if we also need >a global ruleset which is applied if the mount point speficic rules >fail to match. True, forgot that. In that case lets make them a mount option using mux@ new nmount(2) systemcall. >The rules should be able to chmod and chown the nodes. Should it >also be able to prevent the creation matching nodes also? Yes. >You mentioned matching on the names drivers and nodes. Are there >any other sorts of matching we are likely to need? Ideally I would want to match on names, driver names and types, ie: name=="ttyd0", driver=="sio" and type=="tty", but I think the important thing here is to make it exensible in the future. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Mar 4 4:13:25 2002 Delivered-To: freebsd-current@freebsd.org Received: from hotmail.com (oe22.pav0.hotmail.com [64.4.32.102]) by hub.freebsd.org (Postfix) with ESMTP id 28E8B37B400 for ; Mon, 4 Mar 2002 04:13:18 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 4 Mar 2002 04:13:18 -0800 X-Originating-IP: [61.183.69.23] From: "ouyang kai" To: Subject: simplelock to lock_class? Date: Mon, 4 Mar 2002 20:13:22 +0800 MIME-Version: 1.0 X-Mailer: MSN Explorer 7.00.0021.1700 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0000_01C1C3B9.08A03E10" Message-ID: X-OriginalArrivalTime: 04 Mar 2002 12:13:18.0131 (UTC) FILETIME=[F7EF0030:01C1C375] Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ------=_NextPart_001_0000_01C1C3B9.08A03E10 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, eveyone, I found the FreeBSD4.x defined the simplelock in the sys/sys/lock.= h. But, it doesn't exist in FreeBSD5.0, why? If I want use the FreeBSD4.x si= mplelock function, =20 how and what can I use in FreeBSD5.0? Thank you! Best Regards, Ouyang KaiGet more from the Web. FREE MSN Explorer download : http://exp= lorer.msn.com ------=_NextPart_001_0000_01C1C3B9.08A03E10 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi, eveyone,
       I found the FreeBSD4.x defined the = simplelock in the sys/sys/lock.h.
But, it doesn't exist in FreeBSD5.0, why? If I want use the FreeBSD4.x simplelock function,
how= and what can I use in FreeBSD5.0?
    Thank you!
Best Regards,
Ou= yang Kai



Get = more from the Web. FREE MSN Explorer download : http://explorer.msn.com

------=_NextPart_001_0000_01C1C3B9.08A03E10-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Mar 4 9:11:19 2002 Delivered-To: freebsd-current@freebsd.org Received: from web14610.mail.yahoo.com (web14610.mail.yahoo.com [216.136.224.242]) by hub.freebsd.org (Postfix) with SMTP id 6400C37B405 for ; Mon, 4 Mar 2002 09:11:16 -0800 (PST) Message-ID: <20020304171101.89963.qmail@web14610.mail.yahoo.com> Received: from [4.40.33.130] by web14610.mail.yahoo.com via HTTP; Mon, 04 Mar 2002 09:11:01 PST Date: Mon, 4 Mar 2002 09:11:01 -0800 (PST) From: Kyle Taylor To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG subscribe larryluv49@yahoo.com ===== "To be poor is hard, but to be a poor race in a land of dollars is the very bottom of hardships." --W.E.B. DuBois __________________________________________________ Do You Yahoo!? Yahoo! Sports - sign up for Fantasy Baseball http://sports.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Mar 4 10: 6:59 2002 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id D43F737B402; Mon, 4 Mar 2002 10:06:51 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g24I6nb69758; Mon, 4 Mar 2002 10:06:49 -0800 (PST) (envelope-from dillon) Date: Mon, 4 Mar 2002 10:06:49 -0800 (PST) From: Matthew Dillon Message-Id: <200203041806.g24I6nb69758@apollo.backplane.com> To: "M. Warner Losh" Cc: philip@sduwebship.student.umd.edu, freebsd-questions@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: 5.0-CURRENT makebuild world fails References: <20020303023045.E93659-100000@sduwebship.student.umd.edu> <20020303.143027.105075680.imp@village.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :In message: <20020303023045.E93659-100000@sduwebship.student.umd.edu> : "Philip M. Gollucci" writes: :: cc -O2 -Wall -pipe -pedantic -ansi -march=pentiumpro -elf -Wall :: -fkeep-inline-functions -I/usr/src/lib/csu/i386-elf/../common -c :: /usr/src/lib/csu/i386-elf/crt1.c:70: warning: ANSI C forbids braced-groups :: within expressions :: cc: Internal compiler error: program cc1 got fatal signal 11 : :Looks like the C compiler really didn't like the braced-groups within :expressions. : :#define get_rtld_cleanup() \ : ({ fptr __value; \ : __asm__("movl %%edx,%0" : "=rm"(__value)); \ : __value; }) :... : rtld_cleanup = get_rtld_cleanup(); :yet both of these parts of this file hasn't been changed since 1998! : :appears to be the real reason since this file is compiled -ansi :-pedantic. And it would appear on the surface to still be a problem. :However, it looks like my version isn't compiling it -ansi -pedantic: : :cc -O -pipe -elf -Wall -fkeep-inline-functions :-I/dell/imp/FreeBSD/src/lib/csu/i386-elf/../common -DGCRT -c -o :gcrt1.o /dell/imp/FreeBSD/src/lib/csu/i386-elf/crt1.c : :So something really strange is going on, but I'm not sure what. : :Warner I always like to say that these things are "Illegal everywhere except in GCC on a sunny Sunday". This is a misfeature in GCC. Like dynamically sized arrays declared on the stack (which to my horror I actually use sometimes) or dynamic braced auto initializers (which I don't). It would be best to cleanup instances of these when we come across them. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Mar 4 10:13:17 2002 Delivered-To: freebsd-current@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id 7C49737B416; Mon, 4 Mar 2002 10:13:04 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id g24ID3s02303; Mon, 4 Mar 2002 19:13:03 +0100 (CET) (envelope-from wkb) Date: Mon, 4 Mar 2002 19:13:03 +0100 From: Wilko Bulte To: freebsd-current@freebsd.org, freebsd-alpha@freebsd.org Cc: murray@freebsd.org Subject: blockable sleep panic on Alpha / current Message-ID: <20020304191303.A2288@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-OS: FreeBSD 4.5-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG During a make release I just got a panic. The build progressed until: gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxabs.3 > imaxabs.3.gz gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxdiv.3 > imaxdiv.3.gz gzip -cn /usr/src/lib/libc/../libc/stdlib/labs.3 > labs.3.gz The running system is a -current as of today. The panic: login: FreeBSD/alpha (ds10.wbnet) (ttyd0) login: panic: blockable sleep lock (sleep mutex) Giant @ ../../../alpha/alpha/tr ap.c:482 cpuid = 0; panic Stopped at Debugger+0x34: zapnot v0,#0xf,a0 db> db> trace Debugger() at Debugger+0x34 panic() at panic+0x188 witness_lock() at witness_lock+0xb4 _mtx_lock_flags() at _mtx_lock_flags+0xd8 trap() at trap+0x4c8 XentMM() at XentMM+0x2c --- memory management fault (from ipl 7) --- statclock_process() at statclock_process+0x1d4 statclock() at statclock+0x78 alpha_clock_interrupt() at alpha_clock_interrupt+0xac interrupt() at interrupt+0xb8 XentInt() at XentInt+0x28 --- interrupt (from ipl 4) --- critical_exit() at critical_exit+0x1c _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0xd4 witness_lock() at witness_lock+0x408 _mtx_lock_flags() at _mtx_lock_flags+0xd8 lockmgr() at lockmgr+0x70 vm_map_lock_read() at vm_map_lock_read+0x28 vm_map_lookup() at vm_map_lookup+0x78 vm_fault1() at vm_fault1+0xa8 vm_fault() at vm_fault+0x64 trap() at trap+0x6d8 XentMM() at XentMM+0x2c --- memory management fault --- ithread_schedule() at ithread_schedule+0xa4 alpha_dispatch_intr() at alpha_dispatch_intr+0x130 interrupt() at interrupt+0x138 XentInt() at XentInt+0x28 --- interrupt (from ipl 0) --- critical_exit() at critical_exit+0x1c _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0xd4 vm_fault1() at vm_fault1+0x110c vm_fault() at vm_fault+0x64 trap() at trap+0x6d8 XentMM() at XentMM+0x2c --- memory management fault --- pmap_enter_quick() at pmap_enter_quick+0x1d4 pmap_object_init_pt() at pmap_object_init_pt+0x1a4 vm_map_insert() at vm_map_insert+0x35c elf_load_section() at elf_load_section+0x190 exec_elf_imgact() at exec_elf_imgact+0x278 execve() at execve+0x324 syscall() at syscall+0x338 XentSys() at XentSys+0x64 --- syscall (59, FreeBSD ELF, execve) --- --- user mode --- db> -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Mar 4 10:35:45 2002 Delivered-To: freebsd-current@freebsd.org Received: from owa1.digisle.com (ex-owa-sj.digisle.com [165.193.27.217]) by hub.freebsd.org (Postfix) with ESMTP id EB46737B405; Mon, 4 Mar 2002 10:35:40 -0800 (PST) Received: from digisle.net ([206.220.227.145] RDNS failed) by owa1.digisle.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 4 Mar 2002 10:35:40 -0800 Message-ID: <3C83BE7B.24087755@digisle.net> Date: Mon, 04 Mar 2002 10:35:39 -0800 From: Maksim Yevmenkin Organization: Digital Island X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: freebsd-current@FreeBSD.ORG, archie@FreeBSD.ORG Subject: Re: Netgraph, device drivers and mutexes References: <3C827021.A7FA73A4@verizon.net> <3C8284D7.C5A8A893@elischer.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2002 18:35:40.0720 (UTC) FILETIME=[62C84300:01C1C3AB] Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian, thank you very much for a such detailed answer :) [...] > I hope that this helps you! yes it did help :) i changed my code and it seems to work just fine. i wish i had SMP laptop to test it :) thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Mar 4 11:20:57 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 3F84F37B402; Mon, 4 Mar 2002 11:20:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020304192009.QCLZ1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Mon, 4 Mar 2002 19:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA26906; Mon, 4 Mar 2002 11:18:08 -0800 (PST) Date: Mon, 4 Mar 2002 11:18:08 -0800 (PST) From: Julian Elischer To: Maksim Yevmenkin Cc: freebsd-current@FreeBSD.ORG, archie@FreeBSD.ORG Subject: Re: Netgraph, device drivers and mutexes In-Reply-To: <3C83BE7B.24087755@digisle.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 4 Mar 2002, Maksim Yevmenkin wrote: > Julian, > > thank you very much for a such detailed answer :) > > [...] > > > I hope that this helps you! > > yes it did help :) i changed my code and it seems to work just fine. > i wish i had SMP laptop to test it :) Well it aint exactly SMP safe YET, until I make those changes through teh REST of the system. There are still direct timeout() calls in several modules that I need to change to follow my own suggestions and there are many nodes that need to be changed to gain a lock when they first try insert data into the graph. e.g. ng_tty, ng_ether, (actually those two always do queueing but there are others..) I need to sit down with Archie and go through the nodes with an eye to locking. > > thanks, > max > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Mar 4 11:30:15 2002 Delivered-To: freebsd-current@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id 635E437B419; Mon, 4 Mar 2002 11:29:56 -0800 (PST) Received: from pool0193.cvx40-bradley.dialup.earthlink.net ([216.244.42.193] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16hy9e-0001i3-00; Mon, 04 Mar 2002 11:29:50 -0800 Message-ID: <3C83CB1E.A289BC49@mindspring.com> Date: Mon, 04 Mar 2002 11:29:34 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: "M. Warner Losh" , philip@sduwebship.student.umd.edu, freebsd-questions@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: 5.0-CURRENT makebuild world fails References: <20020303023045.E93659-100000@sduwebship.student.umd.edu> <20020303.143027.105075680.imp@village.org> <200203041806.g24I6nb69758@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > I always like to say that these things are "Illegal everywhere except > in GCC on a sunny Sunday". > > This is a misfeature in GCC. Like dynamically sized arrays declared > on the stack (which to my horror I actually use sometimes) or dynamic > braced auto initializers (which I don't). > > It would be best to cleanup instances of these when we come across them. Don't forget the varradic macros with the "..." in their parameter lists. Since this original thread started because some poor fool was using Flexilint, probably in the vain hope that code that lints clean is somehow immune to logic errors (this is where I've seen Flexolint used in the past), it should be noted that there is no dead chicken you can wave over the options to make varradic macros legal... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Mar 4 12: 0:16 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by hub.freebsd.org (Postfix) with ESMTP id BF90637B416 for ; Mon, 4 Mar 2002 12:00:10 -0800 (PST) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by mail.imp.ch (8.11.6/8.11.6) with ESMTP id g24K0Ma13340 for ; Mon, 4 Mar 2002 21:00:22 +0100 (CET) Date: Mon, 4 Mar 2002 21:01:50 +0100 (CET) From: Martin Blapp To: Subject: gcc -O broken in CURRENT Message-ID: <20020304205513.Q56102-100000@levais.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi all, Unfortunatly I have a example from the ports, needed by OpenOffice port (work in progress) cd /usr/ports/devel/stlport/ && make install cd /usr/ports/devel/stlport/work/STLport-4.5.3/test/eh gmake -f gcc-freebsd.mak [vector] :testing n-size constructor (const) ... 95 try successful [vector] :testing pointer range constructor (const) ... Bus error - core dumped Then remove the three -O from gcc-freebsd.mak and run it again. You will see that all tests are successfully done. [...] [hash_multiset] :testing default constructor (const) ... 2 try successful [hash_multiset] :testing iterator range n-size constructor (const) ... 127 try successful [hash_multiset] :testing copy constructor (const) ... 54 try successful [hash_multiset] :testing assignment operator (weak) ... 53 try successful [...] [string] :testing copy constructor (const) ... 2 try successful [string] :testing assignment operator (weak) ... 1 try successful EH test : Done Martin Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Mar 4 13:48:17 2002 Delivered-To: freebsd-current@freebsd.org Received: from owa1.digisle.com (ex-owa-sj.digisle.com [165.193.27.217]) by hub.freebsd.org (Postfix) with ESMTP id A2A4F37B432; Mon, 4 Mar 2002 13:47:28 -0800 (PST) Received: from digisle.net ([206.220.227.145] RDNS failed) by owa1.digisle.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 4 Mar 2002 13:47:28 -0800 Message-ID: <3C83EB6D.CFE8016C@digisle.net> Date: Mon, 04 Mar 2002 13:47:25 -0800 From: Maksim Yevmenkin Organization: Digital Island X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: freebsd-current@FreeBSD.ORG, archie@FreeBSD.ORG Subject: Re: Netgraph, device drivers and mutexes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2002 21:47:28.0099 (UTC) FILETIME=[2DB6F330:01C1C3C6] Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian, [...] > > > I hope that this helps you! > > > > yes it did help :) i changed my code and it seems to work just fine. > > i wish i had SMP laptop to test it :) > > Well it aint exactly SMP safe YET, until I make those changes through teh > REST of the system. There are still direct timeout() calls in several > modules that I need to change to follow my own suggestions and there are > many nodes that need to be changed to gain a lock when they first > try insert data into the graph. e.g. ng_tty, ng_ether, speaking of ng_tty... it is clear to me how to inject data into Netgraph in a safe way, but it is not yet clear how Netgraph can inject data into other subsystems. you see, the Bluetooth spec defines several Host (PC) to Host Controller (Bluetooth unit) communication protocols. one of them is UART transport layer (AKA H4). i have implemented H4 line discipline that also a Netgraph node. (i called it ng_sio in my report but it was wrong). it works now, and i can talk to Xircom card, but it should be changed later. any hints? thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Mar 4 16:40:27 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 03B4637B405; Mon, 4 Mar 2002 16:40:17 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020305004016.RZZA2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 5 Mar 2002 00:40:16 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA28021; Mon, 4 Mar 2002 16:29:30 -0800 (PST) Date: Mon, 4 Mar 2002 16:29:29 -0800 (PST) From: Julian Elischer To: Maksim Yevmenkin Cc: freebsd-current@FreeBSD.ORG, archie@FreeBSD.ORG Subject: Re: Netgraph, device drivers and mutexes In-Reply-To: <3C83EB6D.CFE8016C@digisle.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 4 Mar 2002, Maksim Yevmenkin wrote: > Julian, [...] > > speaking of ng_tty... it is clear to me how to inject data into Netgraph > in a safe way, but it is not yet clear how Netgraph can inject data into > other subsystems. > > you see, the Bluetooth spec defines several Host (PC) to Host Controller > (Bluetooth unit) communication protocols. one of them is UART transport > layer (AKA H4). i have implemented H4 line discipline that also a > Netgraph > node. (i called it ng_sio in my report but it was wrong). it works now, > and i can talk to Xircom card, but it should be changed later. any > hints? Netgraph will have to aquire whatever lock is required for that module. Most subsystems have no locks yet so it's a bit early to say how it will work :-) > > thanks, > max > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Mar 4 23: 8:22 2002 Delivered-To: freebsd-current@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id 61BF837B402; Mon, 4 Mar 2002 23:08:02 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id g25781405283; Tue, 5 Mar 2002 08:08:01 +0100 (CET) (envelope-from wkb) Date: Tue, 5 Mar 2002 08:08:01 +0100 From: Wilko Bulte To: freebsd-current@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: blockable sleep panic on Alpha / current Message-ID: <20020305080801.D5099@freebie.xs4all.nl> References: <20020304191303.A2288@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020304191303.A2288@freebie.xs4all.nl>; from wkb@freebie.xs4all.nl on Mon, Mar 04, 2002 at 07:13:03PM +0100 X-OS: FreeBSD 4.5-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Mar 04, 2002 at 07:13:03PM +0100, Wilko Bulte wrote: Another one, appears to be identical. No dump, no kernel debugger unfortunately. The kernel has WITNESS enabled too. I'll try to catch a dump if that is helpful to someone? Wilko FreeBSD/alpha (ds10.wbnet) (ttyd0) login: panic: blockable sleep lock (sleep mutex) Giant @ ../../../alpha/alpha/tr ap.c:482 cpuid = 0; panic Stopped at fatal kernel trap: trap entry = 0x2 (memory management fault) cpuid = 0 faulting va = 0x60 type = access violation cause = load instructon pc = 0xfffffc000050b220 ra = 0xfffffc000050b218 sp = 0xfffffe000e22c450 usp = 0x11fff0a8 curthread = 0xfffffe000e107d00 pid = 44138, comm = cc Stopped at fatal kernel trap: trap entry = 0x2 (memory management fault) cpuid = 0 faulting va = 0x60 type = access violation cause = load instructon pc = 0xfffffc000050b220 ra = 0xfffffc000050b218 sp = 0xfffffe000e22b9c8 usp = 0x11fff0a8 curthread = 0xfffffe000e107d00 pid = 44138, comm = cc Stopped at fatal kernel trap: trap entry = 0x2 (memory management fault) cpuid = 0 faulting va = 0x60 type = access violation cause = load instructon pc = 0xfffffc000050b220 ra = 0xfffffc000050b218 sp = 0xfffffe000e22af40 usp = 0x11fff0a8 curthread = 0xfffffe000e107d00 pid = 44138, comm = cc Stopped at halted CPU 0 halt code = 2 kernel stack not valid halt PC = fffffc00004231ec >>> > During a make release I just got a panic. The build progressed until: > > gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxabs.3 > imaxabs.3.gz > gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxdiv.3 > imaxdiv.3.gz > gzip -cn /usr/src/lib/libc/../libc/stdlib/labs.3 > labs.3.gz > > The running system is a -current as of today. > > The panic: > > login: > FreeBSD/alpha (ds10.wbnet) (ttyd0) > > login: panic: blockable sleep lock (sleep mutex) Giant @ > ../../../alpha/alpha/tr > ap.c:482 > cpuid = 0; panic > Stopped at Debugger+0x34: zapnot v0,#0xf,a0 > db> > db> trace > Debugger() at Debugger+0x34 > panic() at panic+0x188 > witness_lock() at witness_lock+0xb4 > _mtx_lock_flags() at _mtx_lock_flags+0xd8 > trap() at trap+0x4c8 > XentMM() at XentMM+0x2c > --- memory management fault (from ipl 7) --- > statclock_process() at statclock_process+0x1d4 > statclock() at statclock+0x78 > alpha_clock_interrupt() at alpha_clock_interrupt+0xac > interrupt() at interrupt+0xb8 > XentInt() at XentInt+0x28 > --- interrupt (from ipl 4) --- > critical_exit() at critical_exit+0x1c > _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0xd4 > witness_lock() at witness_lock+0x408 > _mtx_lock_flags() at _mtx_lock_flags+0xd8 > lockmgr() at lockmgr+0x70 > vm_map_lock_read() at vm_map_lock_read+0x28 > vm_map_lookup() at vm_map_lookup+0x78 > vm_fault1() at vm_fault1+0xa8 > vm_fault() at vm_fault+0x64 > trap() at trap+0x6d8 > XentMM() at XentMM+0x2c > --- memory management fault --- > ithread_schedule() at ithread_schedule+0xa4 > alpha_dispatch_intr() at alpha_dispatch_intr+0x130 > interrupt() at interrupt+0x138 > XentInt() at XentInt+0x28 > --- interrupt (from ipl 0) --- > critical_exit() at critical_exit+0x1c > _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0xd4 > vm_fault1() at vm_fault1+0x110c > vm_fault() at vm_fault+0x64 > trap() at trap+0x6d8 > XentMM() at XentMM+0x2c > --- memory management fault --- > pmap_enter_quick() at pmap_enter_quick+0x1d4 > pmap_object_init_pt() at pmap_object_init_pt+0x1a4 > vm_map_insert() at vm_map_insert+0x35c > elf_load_section() at elf_load_section+0x190 > exec_elf_imgact() at exec_elf_imgact+0x278 > execve() at execve+0x324 > syscall() at syscall+0x338 > XentSys() at XentSys+0x64 > --- syscall (59, FreeBSD ELF, execve) --- > --- user mode --- > db> > > > -- > | / o / /_ _ wilko@FreeBSD.org > |/|/ / / /( (_) Bulte Arnhem, the Netherlands > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message ---end of quoted text--- -- | / o / /_ _ FreeBSD core team secretary |/|/ / / /( (_) Bulte wilko@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 4:38:42 2002 Delivered-To: freebsd-current@freebsd.org Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by hub.freebsd.org (Postfix) with ESMTP id D487037B402 for ; Tue, 5 Mar 2002 04:38:38 -0800 (PST) Received: from list1.xs4all.nl (list1.xs4all.nl [194.109.6.52]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g25CcbGk048151 for ; Tue, 5 Mar 2002 13:38:37 +0100 (CET) Received: (from root@localhost) by list1.xs4all.nl (8.9.3/8.9.3) id NAA22308; Tue, 5 Mar 2002 13:38:37 +0100 (CET) From: micheloo@xs4all.nl (Michel Oosterhof) To: freebsd-current@freebsd.org X-Via: imploder /usr/local/lib/mail/news2mail/news2mail at list1.xs4all.nl Subject: Build fails on usr.bin/uuencode/uuencode.c Date: 5 Mar 2002 13:38:30 +0100 Organization: XS4ALL, Networking for the masses Message-ID: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Building -CURRENT just failed on my machine, on src/usr.bin/uuencode/uuencode.c Probalby due to the last change (1.8 to 1.9, 9 hours ago from now) which changed just the line that gives the error: FILE *output = stdout; Perhaps this change should be reversed? regards, Michel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 4:53:48 2002 Delivered-To: freebsd-current@freebsd.org Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by hub.freebsd.org (Postfix) with ESMTP id B8DEF37B402 for ; Tue, 5 Mar 2002 04:53:43 -0800 (PST) Received: from list1.xs4all.nl (list1.xs4all.nl [194.109.6.52]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g25CrgOE052730 for ; Tue, 5 Mar 2002 13:53:42 +0100 (CET) Received: (from root@localhost) by list1.xs4all.nl (8.9.3/8.9.3) id NAA01428; Tue, 5 Mar 2002 13:53:41 +0100 (CET) From: micheloo@xs4all.nl (Michel Oosterhof) To: freebsd-current@freebsd.org X-Via: imploder /usr/local/lib/mail/news2mail/news2mail at list1.xs4all.nl Subject: Re: Build fails on usr.bin/uuencode/uuencode.c Date: 5 Mar 2002 13:53:27 +0100 Organization: XS4ALL, Networking for the masses Message-ID: In-Reply-To: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG micheloo@xs4all.NL (Michel Oosterhof) writes: >Building -CURRENT just failed on my machine, on src/usr.bin/uuencode/uuencode.c >Probalby due to the last change (1.8 to 1.9, 9 hours ago from now) which changed >just the line that gives the error: Just ignore this post, it was fixed in the cvsup of a few minutes ago. michel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 5:34:20 2002 Delivered-To: freebsd-current@freebsd.org Received: from tomts14-srv.bellnexxia.net (tomts14.bellnexxia.net [209.226.175.35]) by hub.freebsd.org (Postfix) with ESMTP id 1AFC637B400 for ; Tue, 5 Mar 2002 05:31:36 -0800 (PST) Received: from yahoo.com ([64.229.184.12]) by tomts14-srv.bellnexxia.net (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020305133027.PZMJ21875.tomts14-srv.bellnexxia.net@yahoo.com> for ; Tue, 5 Mar 2002 08:30:27 -0500 Message-ID: <002c01c1c260$bf91b1d0$0cb8e540@sympatico.ca> Reply-To: "Dr Guihua Li" From: "Dr Guihua Li" To: freebsd-current@freebsd.org Subject: Invitation letter from the Organisation Committee of the First World Congress of Future Science and Culture Date: Sat, 2 Mar 2002 22:08:52 -0500 Organization: Organisation Committee of First World Congress of Future Science and Culture MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0028_01C1C236.D6894F30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C1C236.D6894F30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0029_01C1C236.D6894F30" ------=_NextPart_001_0029_01C1C236.D6894F30 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear Sir/Madam, = =20 =20 Many of us who came to work in the sciences or similar areas did so = because we wanted to explore the unknown and gain more knowledge and = ultimately make this world a better place. It is undoubtedly true that = modern science has brought immense benefits to humanity but also = encountered many unsolved questions and problems including environmental = pollution.=20 =20 Perhaps it is now time for a different approach: Falun Dafa takes a = holistic view of life and the universe. It builds on the insights of = modern science and combines them with the insights from ancient Chinese = science and culture. We, scientists who understand Falun Dafa, invite = you to participate in the First World Congress of Future Science and = Culture that will be held at Cambridge on March 9th and 10th of 2002. = This congress will see state of the art research in this field and serve = as a forum for discussing how these new ideas could exert a profound = influence on the future science and culture of humankind. =20 Renowned specialists and professors in diverse academic disciplines from = many different parts of the world will be participating. A schedule for = March 9th is attached. On March 10 we will be holding an informal = discussion session at which participants at the conference can raise = issues with the speakers.=20 =20 We do hope that you will be able to find the time to attend. Please let = us know if you have any questions. =20 Yours sincerely, =20 =20 =20 Dr Guihua Li Organisation Committee of First World Congress of Future Science and = Culture fsc_congress@hotmail.com http://www.fsc-congress.org ------=_NextPart_001_0029_01C1C236.D6894F30 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear Sir/Madam,               &nbs= p;        =20            &nbs= p;        =20            &nbs= p; =20

 

Many=20 of us who came to work in the sciences or similar areas did so because = we wanted=20 to explore the unknown and gain more knowledge and ultimately make this = world a=20 better place.  It is = undoubtedly=20 true that modern science has brought immense benefits to humanity but = also=20 encountered many unsolved questions and problems including environmental = pollution.

 

Perhaps it is now time for a different = approach:  Falun Dafa takes a holistic = view of life=20 and the universe. It builds on the insights of modern science and = combines them=20 with the insights from ancient Chinese science and culture. We, = scientists who=20 understand Falun Dafa, invite you to participate in the First World = Congress of=20 Future Science and Culture that will be held at Cambridge on March=20 9th and 10th of 2002. This congress will see state = of the=20 art research in this field and serve as a forum for discussing how these = new=20 ideas could exert a profound influence on the future science and culture = of=20 humankind.

 

Renowned specialists and professors in diverse = academic=20 disciplines from many different parts of the world will be = participating.  A schedule for March 9th is = attached. On=20 March 10 we will be holding an informal discussion session at which = participants=20 at the conference can raise issues with the speakers.=20

 

We do hope that = you will be=20 able to find the time to attend.=20 Please let us know if you have any = questions.

 

Yours sincerely,

 

 


 

Dr Guihua Li

Organisation Committee of First World Congress = of Future=20 Science and Culture

fsc_congress@hotmail.com

http://www.fsc-congress.org

------=_NextPart_001_0029_01C1C236.D6894F30-- ------=_NextPart_000_0028_01C1C236.D6894F30 Content-Type: application/msword; name="Invitation-Peter2.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Invitation-Peter2.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAWgAAAAAAAAAA EAAAXQAAAAEAAAD+////AAAAAFkAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAWyAJBAAA+BK/AAAAAAAAEAAAAAAABAAASiMAAA4AYmpiauIA4gAAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIkIAAIBqAQCAagEAwhMAAAAAAAAeAAAAAAAAAAAAAAAAAAAABQAAAGQAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAANoDAAAAAAAA2gMAANoD AAAAAAAA2gMAAAAAAAAKBQAAAAAAAAoFAAAAAAAACgUAABQAAAAAAAAAAAAAAB4FAAAAAAAABhIA AAAAAAAGEgAAAAAAAAYSAAA4AAAAPhIAACQAAABiEgAAPAAAAB4FAAAAAAAAtTMAALQBAACqEgAA OgAAAOQSAAAoAAAADBMAAAAAAAAMEwAAAAAAANgTAAAAAAAAQBcAAAAAAABAFwAAAAAAAEAXAAAA AAAApDIAAAIAAACmMgAAAAAAAKYyAAAAAAAApjIAAAAAAACmMgAAAAAAAKYyAAAAAAAApjIAACQA AABpNQAAIAIAAIk3AABiAAAAyjIAAKUAAAAAAAAAAAAAAAAAAAAAAAAACgUAAAAAAABAFwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAaFwAABAAAAB4XAAAiAAAAQBcAAAAAAABAFwAAAAAAAMoyAAAAAAAA JBsAAAAAAADaAwAAAAAAANoDAAAAAAAADBMAAAAAAAAAAAAAAAAAANgTAABCAwAAbzMAABYAAAAk GwAAAAAAACQbAAAAAAAAJBsAAAAAAABAFwAA7AIAANoDAACGAAAADBMAAAAAAACWBAAAUgAAANgT AAAAAAAApDIAAAAAAAAAAAAAAAAAACQbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAQBcAAAAAAACkMgAAAAAAACQbAAAmBAAAJBsAAAAAAABKHwAA xgAAACAxAACQAAAAYAQAADYAAADoBAAAIgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2DEAAAAAAAAMEwAAzAAAAJ4SAAAMAAAAEF5I95K/ wQEeBQAA6AwAAAYSAAAAAAAALBoAAL4AAACwMQAAFAAAAAAAAAAAAAAA2DEAAMwAAACFMwAAMAAA ALUzAAAAAAAAxDEAABQAAADrNwAAAAAAAOoaAAA6AAAA6zcAAAAAAADYMQAAAAAAACQbAAAAAAAA HgUAAAAAAAAeBQAAAAAAANoDAAAAAAAA2gMAAAAAAADaAwAAAAAAANoDAAAAAAAAAgDZAAAADQ0N CQkJCQkJCQkJMjYgRmVicnVhcnkgMjAwMg0NoA1EZWFyIFNpci9NYWRhbSwgCQkJCQkJCQkJDaAN TWFueSBvZiB1cyB3aG8gY2FtZSB0byB3b3JrIGluIHRoZSBzY2llbmNlcyBvciBzaW1pbGFyIGFy ZWFzIGRpZCBzbyBiZWNhdXNlIHdlIHdhbnRlZCB0byBleHBsb3JlIHRoZSB1bmtub3duIGFuZCBn YWluIG1vcmUga25vd2xlZGdlIGFuZCB1bHRpbWF0ZWx5IG1ha2UgdGhpcyB3b3JsZCBhIGJldHRl ciBwbGFjZS4gIEl0IGlzIHVuZG91YnRlZGx5IHRydWUgdGhhdCBtb2Rlcm4gc2NpZW5jZSBoYXMg YnJvdWdodCBpbW1lbnNlIGJlbmVmaXRzIHRvIGh1bWFuaXR5IGJ1dCBhbHNvIGVuY291bnRlcmVk IG1hbnkgdW5zb2x2ZWQgcXVlc3Rpb25zIGFuZCBwcm9ibGVtcyBpbmNsdWRpbmcgZW52aXJvbm1l bnRhbCBwb2xsdXRpb24uIA2gDVBlcmhhcHMgaXQgaXMgbm93IHRpbWUgZm9yIGEgZGlmZmVyZW50 IGFwcHJvYWNoOiAgRmFsdW4gRGFmYSB0YWtlcyBhIGhvbGlzdGljIHZpZXcgb2YgbGlmZSBhbmQg dGhlIHVuaXZlcnNlLiBJdCBidWlsZHMgb24gdGhlIGluc2lnaHRzIG9mIG1vZGVybiBzY2llbmNl IGFuZCBjb21iaW5lcyB0aGVtIHdpdGggdGhlIGluc2lnaHRzIGZyb20gYW5jaWVudCBDaGluZXNl IHNjaWVuY2UgYW5kIGN1bHR1cmUuIFdlLCBzY2llbnRpc3RzIHdobyB1bmRlcnN0YW5kIEZhbHVu IERhZmEsIGludml0ZSB5b3UgdG8gcGFydGljaXBhdGUgaW4gdGhlIEZpcnN0IFdvcmxkIENvbmdy ZXNzIG9mIEZ1dHVyZSBTY2llbmNlIGFuZCBDdWx0dXJlIHRoYXQgd2lsbCBiZSBoZWxkIGF0IENh bWJyaWRnZSBvbiBNYXJjaCA5dGggYW5kIDEwdGggb2YgMjAwMi4gVGhpcyBjb25ncmVzcyB3aWxs IHNlZSBzdGF0ZSBvZiB0aGUgYXJ0IHJlc2VhcmNoIGluIHRoaXMgZmllbGQgYW5kIHNlcnZlIGFz IGEgZm9ydW0gZm9yIGRpc2N1c3NpbmcgaG93IHRoZXNlIG5ldyBpZGVhcyBjb3VsZCBleGVydCBh IHByb2ZvdW5kIGluZmx1ZW5jZSBvbiB0aGUgZnV0dXJlIHNjaWVuY2UgYW5kIGN1bHR1cmUgb2Yg aHVtYW5raW5kLg0NUmVub3duZWQgc3BlY2lhbGlzdHMgYW5kIHByb2Zlc3NvcnMgaW4gZGl2ZXJz ZSBhY2FkZW1pYyBkaXNjaXBsaW5lcyBmcm9tIG1hbnkgZGlmZmVyZW50IHBhcnRzIG9mIHRoZSB3 b3JsZCB3aWxsIGJlIHBhcnRpY2lwYXRpbmcuICBBIHNjaGVkdWxlIGZvciBNYXJjaCA5dGggaXMg YXR0YWNoZWQuIE9uIE1hcmNoIDEwIHdlIHdpbGwgYmUgaG9sZGluZyBhbiBpbmZvcm1hbCBkaXNj dXNzaW9uIHNlc3Npb24gYXQgd2hpY2ggcGFydGljaXBhbnRzIGF0IHRoZSBjb25mZXJlbmNlIGNh biByYWlzZSBpc3N1ZXMgd2l0aCB0aGUgc3BlYWtlcnMuIA0NV2UgZG8gaG9wZSB0aGF0IHlvdSB3 aWxsIGJlIGFibGUgdG8gZmluZCB0aGUgdGltZSB0byBhdHRlbmQuIFBsZWFzZSBsZXQgdXMga25v dyBpZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zLg2gDVlvdXJzIHNpbmNlcmVseSwNDQ0LIA1EciBH dWlodWEgTGkNT3JnYW5pc2F0aW9uIENvbW1pdHRlZSBvZiBGaXJzdCBXb3JsZCBDb25ncgBlAHMA cwAgAG8AZgAgAEYAdQB0AHUAcgBlACAAUwBjAGkAZQBuAGMAZQAgAGEAbgBkACAAQwB1AGwAdAB1 AHIAZQANABMAIABIAFkAUABFAFIATABJAE4ASwAgACIAbQBhAGkAbAB0AG8AOgBmAHMAYwBfAGMA bwBuAGcAcgBlAHMAcwBAAGgAbwB0AG0AYQBpAGwALgBjAG8AbQANACIAIAABABQAZgBzAGMAXwBj AG8AbgBnAHIAZQBzAHMAQABoAG8AdABtAGEAaQBsAC4AYwBvAG0ADQAVABMAIABIAFkAUABFAFIA TABJAE4ASwAgACIAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGYAcwBjAC0AYwBvAG4AZwByAGUAcwBz AC4AbwByAGcAIgAgAAEAFABoAHQAdABwADoALwAvAHcAdwB3AC4AZgBzAGMALQBjAG8AbgBnAHIA ZQBzAHMALgBvAHIAZwAVAA0ACwANAAwADQANAA0AQwBvAG4AZwByAGUAcwBzACAAUwBjAGgAZQBk AHUAbABlAA0ADQBNAGEAcgBjAGgAIAA5ACwAIAAyADAAMAAyAA0ADQA5ABr/MAAwACAAYQBtACAA CQBPAHAAZQBuAGkAbgBnACAAUgBlAG0AYQByAGsAcwANAA0AQgBpAG8AbABvAGcAeQAgAGEAbgBk ACAATQBlAGQAaQBjAGkAbgBlAA0ADQBDAGgAYQBpAHIAOgAgAEQAaQBhAG4AbgBhACAAUgBvAGIA ZQByAHQAcwAsACAAUABoAC4ARAAuACwAIABVAG4AaQB2AC4AIABvAGYAIABUAGUAeABhAHMAIABN AC4AIABEAC4AIABBAG4AZABlAHIAcwBvAG4AIABDAGEAbgBjAGUAcgAgAEMAZQBuAHQAZQByACwA IABIAG8AdQBzAHQAbwBuACwAIABVAFMAQQANAA0AOQAa/zEANQAgAGEAbQAgAAkATABpAGwAaQAg AEYAZQBuAGcALAAgAE0ARAAsACAARABlAHAAYQByAHQAbQBlAG4AdAAgAG8AZgAgAE0AZQBkAGkA YwBpAG4AZQAsACAAQgBhAHkAbABvAHIAIABDAG8AbABsAGUAZwBlACAAbwBmACAATQBlAGQAaQBj AGkAbgBlACwAIABIAG8AdQBzAHQAbwBuACwAIABUAGUAeABhAHMALAAgAFUAUwBBACAAIAAgABwg RwBlAG4AbwBtAGUALQB3AGkAZABlACAAcAByAG8AZgBpAGwAZQBzACAAbwBmACAAZwBlAG4AZQAg AGUAeABwAHIAZQBzAHMAaQBvAG4AIABpAG4AIABuAGUAdQB0AHIAbwBwAGgAaQBsAHMAIABmAHIA bwBtACAARgBhAGwAdQBuACAARwBvAG4AZwAgAHAAcgBhAGMAdABpAHQAaQBvAG4AZQByAHMAIABh AG4AZAAgAG4AbwByAG0AYQBsACAAaABlAGEAbAB0AGgAeQAgAGMAbwBuAHQAcgBvAGwAcwAdIA0A DQA5ABr/NQAwACAAYQBtACAACQBXAGkAbABsAGkAYQBtACAARgByAGEAbgBrAGwAaQBuACAATQBj AEMAbwB5ACwAIABNAC4ARAAuACwAIABIAG8AbQBlAG8AcABhAHQAaABpAGMAIABwAGgAeQBzAGkA YwBpAGEAbgAsACAAHCBNAGUAZABpAGMAYQBsACAAUAByAGEAYwB0AGkAYwBlACAAaQBuACAAdABo AGUAIABOAGUAdwAgAEUAcgBhAB0gDQANADEAMAAa/zEAMAAgAGEAbQAJAE0AYQBpACAASABlACwA IABNAEQALAAgAFAAaABEACwAIABEAGUAcABhAHIAdABtAGUAbgB0ACAAbwBmACAAUwB1AHIAZwBl AHIAeQAsACAATgBlAHcAIABKAGUAcgBzAGUAeQAgAE0AZQBkAGkAYwBhAGwAIABTAGMAaABvAG8A bAAsACAATgBlAHcAYQByAGsALAAgAE4ASgAsACAAVQBTAEEALAAgACAAHCBIAGUAYQBsAHQAaAAg AHMAdQByAHYAZQB5ACAAbwBmACAARgBhAGwAdQBuACAARwBvAG4AZwAgAHAAcgBhAGMAdABpAHQA aQBvAG4AZQByAHMAHSAgAA0ADQAxADAAGv8gADMAMAAgAGEAbQAJAFgAaQBhAG8AZABvAG4AZwAg AFMAaABhAG8ALAAgAE0ARAAsACAAHCBXAGUAcwB0AGUAcgBuACAATQBlAGQAaQBjAGkAbgBlACwA IABDAGgAaQBuAGUAcwBlACAATQBlAGQAaQBjAGkAbgBlACwAIABBAGMAdQBwAHUAbgBjAHQAdQBy AGUALAAgAFEAaQBnAG8AbgBnACAAYQBuAGQAIABDAHUAbAB0AGkAdgBhAHQAaQBvAG4AIABQAHIA YQBjAHQAaQBjAGUAHSANAA0AMQAwABr/NQAwACAAYQBtAAkAQgByAGUAYQBrAA0ADQBOAGUAdwAg AEMAbwBuAGMAZQBwAHQAcwAgAGkAbgAgAFMAYwBpAGUAbgBjAGUADQANAEMAaABhAGkAcgA6ACAA UwBoAGkAeQB1ACAAWgBoAG8AdQAsACAAUABoAC4ARAAsACAAVQBuAGkAdgBlAHIAcwBpAHQAeQAg AG8AZgAgAFAAZQBuAG4AcwB5AGwAdgBhAG4AaQBhACwAIABQAGgAaQBsAGEAZABlAGwAcABoAGkA YQAsACAAVQBTAEEADQANADEAMQAa/zAAMAAgAGEAbQAJAEQAYQBuAGkAZQBsACAASAB1AGEAbgBn AAz/HCBTAGMAaQBlAG4AYwBlABkgcwAgAFcAYQB5ACAATwB1AHQAHSANAA0AMQAxABr/MgAwACAA YQBtAAkAUwBoAGkAeQB1ACAAWgBoAG8AdQAsACAAUABoAC4ARAAuACwAIABVAG4AaQB2AGUAcgBz AGkAdAB5ACAAbwBmACAAUABlAG4AbgBzAHkAbAB2AGEAbgBpAGEALAAgAFAAaABpAGwAYQBkAGUA bABwAGgAaQBhACwAIABVAFMAQQAsACAAHCAgAFAAcgBvAHAAaABlAGMAeQAsACAAVABpAG0AZQAg AGEAbgBkACAAUwBwAGEAYwBlAB0gDQANADEAMQAa/zQAMAAgAGEAbQAJAE4AYQB0AGEAbAB5ACAA VABlAHAAbABpAHQAcwBrAHkALAAgAFAAaAAuAEQALgAsACAATgB1AGMAbABlAGEAcgAgAE0AZQBk AGkAYwBpAG4AZQAgAFQAZQBjAGgAbgBvAGwAbwBnAGkAcwB0ACwAIABSAGUAdAAuACAAHCBCAHIA ZQBhAGsAaQBuAGcAIABUAGgAcgBvAHUAZwBoACAAdABoAGUAIABDAG8AbgB2AGUAbgB0AGkAbwBu AGEAbAAgAFMAYwBpAGUAbgB0AGkAZgBpAGMAIABQAGEAcgBhAGQAaQBnAG0AHSANAA0AMQAyADoA MAAwACAAbgBvAG8AbgAJAEQAcgAuACAAUgBhAGkAbQB1AG4AZAAgAEsAaQByAG4AZQByACwAIAAc IEYAYQBsAHUAbgAgAEQAYQBmAGEAIABhAG4AZAAgAE0AbwBkAGUAcgBuACAAUwBjAGkAZQBuAGMA ZQAdIA0ADQANAA0ADQANAA0AMQAyADoAMgAwACAAcABtAC0AMgA6ADAAMAAgAHAAbQAgAAkAIABM AHUAbgBjAGgAIABCAHIAZQBhAGsADQANAFMAbwBjAGkAYQBsACAAYQBuAGQAIABFAG4AdgBpAHIA bwBuAG0AZQBuAHQAYQBsACAAUwBjAGkAZQBuAGMAZQAgAA0ADQBDAGgAYQBpAHIAOgAgAEoAaQBu AGgAdQBhACAAWgBoAGEAbgBnACwAIABQAGgALgBEAC4ALAAgAFAAcgBvAGYAZQBzAHMAbwByACAA bwBmACAATgBlAHcAcwAgAGEAbgBkACAATQBlAGQAaQBhACwAIABUAGEAaQB3AGEAbgAgAFUAbgBp AHYAZQByAHMAaQB0AHkADQANADIAGv8wADAAIABwAG0ACQBEAHIALgAgAEgAdQBpAGwAaQBuACAA VwB1AAz/UAByAG8AZgBlAHMAcwBvAHIAIABvAGYAIABFAGMAbwBuAG8AbQBpAGMAcwAsACAAQwBo AGkAbgBlAHMAZQAgAEUAYwBvAG4AbwBtAGkAYwBzACAAUgBlAHMAZQBhAHIAYwBoACAASQBuAHMA dABpAHQAdQB0AGUALAAgAFQAYQBpAHcAYQBuACwAIAAcIFQAaABlACAASwBlAHkAIAB0AG8AIABD AG8AbgBzAHQAYQBuAHQAIABHAHIAbwB3AHQAaAAgAG8AZgAgAEUAYwBvAG4AbwBtAHkAIABMAGkA ZQBzACAAaQBuACAAdABoAGUAIABSAGUAbgBhAGkAcwBzAGEAbgBjAGUAIABvAGYAIABNAG8AcgBh AGwAaQB0AHkAHSANAA0AMgAa/zIAMAAgAHAAbQAJAFkAYQBoAHUAaQAgAEMAYQBpACwAIABQAGgA LgBEAC4AIABDAGEAbgBkAGkAZABhAHQAZQAsACAARABlAHAAYQByAHQAbQBlAG4AdAAgAG8AZgAg AFMAcABhAHQAaQBhAGwAIABQAGwAYQBuAG4AaQBuAGcALAAgAFUAbgBpAHYAZQByAHMAaQB0AHkA IABvAGYAIABEAG8AcgB0AG0AdQBuAGQALAAgAEcAZQByAG0AYQBuAHkALAAgABwgVABoAGUAIABM AGkAdgBpAG4AZwAgAFMAcABhAGMAZQAgAG8AZgAgAEgAdQBtAGEAbgAgAEIAZQBpAG4AZwBzACAA EyAgAFUAbgBpAHEAdQBlACAAQwBvAG4AYwBlAHAAdABzACAAaQBuACAAVAByAGEAZABpAHQAaQBv AG4AYQBsACAAQwBoAGkAbgBlAHMAZQAgAEMAaQB0AGkAZQBzACAAYQBuAGQAIABUAG8AdwBuAHMA GSAgAEQAZQBzAGkAZwBuAHMAHSAgAA0ADQAyABr/NAAwACAAcABtAAkARgBlAG4AZwB5AGkAIABH AGEAbwAsACAAUABoAC4ARAAgAEMAYQBuAGQAaQBkAGEAdABlACwAIABUAG8AawB5AG8AIABJAG4A ZAB1AHMAdAByAGkAYQBsACAAVQBuAGkAdgBlAHIAcwBpAHQAeQAsACAAHCBBACAATgBlAHcAIABB AHAAcAByAG8AYQBjAGgAIAB0AG8AIABFAG4AdgBpAHIAbwBuAG0AZQBuAHQAIABQAHIAbwB0AGUA YwB0AGkAbwBuAC0AIABJAG0AcAByAG8AdgBpAG4AZwAgAHQAaABlACAATQBvAHIAYQBsACAAUwB0 AGEAbgBkAGEAcgBkAB0gIAANAA0AMwAa/zAAMAAgAHAAbQAJAEsAZQBhAG4AIABXAG8AbgBnACwA IABEAGkAcgBlAGMAdABvAHIAIABvAGYAIABaAFMAUgAgAEMAbwBuAHMAdQBsAHQAaQBuAGcAIABG AGkAcgBtACwAIABBAHUAcwB0AHIAYQBsAGkAYQAsACAAQwBoAGkAbgBhABkgcwAgAEUAYwBvAG4A bwBtAGkAYwAgAGEAbgBkACAAUwBvAGMAaQBhAGwAIABSAGUAbgBhAGkAcwBzAGEAbgBjAGUAOgAg AEYAYQBsAHUAbgAgAEcAbwBuAGcAIABhAG4AZAAgAHQAaABlACAAcgBpAHMAZQAgAG8AZgAgAFQA cgB1AHQAaAAtAEMAbwBtAHAAYQBzAHMAaQBvAG4ALQAgAEYAbwByAGIAZQBhAHIAYQBuAGMAZQAN AA0AMwAa/zIAMAAgAHAAbQAJAEIAcgBlAGEAawANAA0AQQByAHQAcwAgAGEAbgBkACAAQwB1AGwA dAB1AHIAZQBzAA0ADQBDAGgAYQBpAHIAIABEAGEAbgBhACAAQwBoAGUAbgBnACwAIABQAGgALgBE AA0ADQAzABr/MwAwACAAcABtAAkAQwBoAHUAbgBtAGEAbgAgAEcAYQBvAAz/UAByAG8AZgBlAHMA cwBvAHIAIABvAGYAIABDAGgAZQBtAGkAYwBhAGwAIABFAG4AZwBpAG4AZQBlAHIAaQBuAGcALAAg AFQAcwBpAG4AZwBoAHUAYQAgAFUAbgBpAHYAZQByAHMAaQB0AHkALAAgAEIAZQBpAGoAaQBuAGcA LAAgAEMAaABpAG4AYQAsACAAHCBFAGQAdQBjAGEAdABpAG8AbgAgAGkAbgAgAEYAdQB0AHUAcgBl AB0gKABDAGgAaQBuAGUAcwBlACwAIABjAGEAbgAgAGIAZQAgAHIAZQBwAGwAYQBjAGUAZAAgAGkA ZgAgAHQAaABlAHIAZQAgAGkAcwAgAGEAIABiAGUAdAB0AGUAcgAgAG8AbgBlACkADQANADMAGv81 ADAAIABwAG0ACQAgAEwAbwByAHIAYQBpAG4AZQAgAEsAYQBiAGEAYwBpAG4AcwBrAGkALAAgAE0A LgAgAFMALgAsACAASABvAGwAaQBzAHQAaQBjACAASABlAGEAbAB0AGgAIABQAHIAYQBjAHQAaQB0 AGkAbwBuAGUAcgAsACAAHCBLAGEAcgBtAGEAGSBzACAAUgBvAGwAZQAgAGkAbgAgAEkAbABsAG4A ZQBzAHMAIABhAG4AZAAgAEMAbwBuAHQAZQBtAHAAbwByAGEAcgB5ACAAUABhAHIAYQBkAGkAZwBt AHMAIABmAG8AcgAgAEEAdAB0AGEAaQBuAGkAbgBnACAATwBwAHQAaQBtAHUAbQAgAEgAZQBhAGwA dABoAB0gDQANADQAGv8xADAAIABwAG0ACQBDAHUAaQB5AGkAbgBnACAAWgBoAGEAbgBnAAz/QQBy AHQAaQBzAHQALAAgAEEAdQBzAHQAcgBhAGwAaQBhACwAIAAcIEEAcgB0ACAAbwBmACAAQwBoAGkA bgBlAHMAZQAgAFAAYQBpAG4AdABpAG4AZwAgAGEAbgBkACAAQwB1AGwAdABpAHYAYQB0AGkAbwBu AB0gDQANADQAIAA6ACAAMwAwACAAcABtAAkAQwBsAG8AcwBpAG4AZwAgAFIAZQBtAGEAcgBrAHMA DQAMAA0ADQANAA0ADQAxAHMAdAAgAFcAbwByAGwAZAAgAEMAbwBuAGcAcgBlAHMAcwAgAG8AZgAg AEYAdQB0AHUAcgBlACAAUwBjAGkAZQBuAGMAZQAgAGEAbgBkACAAQwB1AGwAdAB1AHIAZQANACAA DQBSAGUAZwBpAHMAdAByAGEAdABpAG8AbgAgAEYAbwByAG0ADQAoAFQAaABlAHIAZQAgAGkAcwAg AG4AbwAgAHIAZQBnAGkAcwB0AHIAYQB0AGkAbwBuACAAZgBlAGUAIABmAG8AcgAgAHQAaABlACAA YwBvAG4AZgBlAHIAZQBuAGMAZQAgAGIAdQB0ACAAYQBsAGwAIABwAGFydGljaXBhbnRzIGFyZSBy ZXNwb25zaWJsZSBmb3IgdGhlaXIgb3duIHRyYXZlbCwgbG9kZ2luZywgYW5kIGluY2lkZW50YWwg ZXhwZW5zZXMuKQ0gDVRvcCBvZiBGb3JtIDENE1BSSVZBVEUBFUZpcnN0IE5hbWUHTGFzdCBuYW1l B1RpdGxlIChNci4sIE1zLiwgRHIuLCBQcm9mKSAHBwcHBwcNWW91ciBhZmZpbGlhdGlvbiAob3B0 aW9uYWwpOg0LDRNQUklWQVRFARVDaXR5B1Byb3ZpbmNlB0NvdW50cnkgBwcTUFJJVkFURQEVBwcH Bw1FbWFpbDoNUGhvbmUgKE9wdGlvbmFsKToNRmF4IChPcHRpb25hbCk6DVBvc3RhbCBhZGRyZXNz IChPcHRpb25hbCk6DQ0NSWYgeW91IG5lZWQgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhYm91dCB0 aGUgY29uZmVyZW5jZSwgcGxlYXNlIHdyaXRlIGRvd24geW91ciByZXF1ZXN0IGFuZCBzZW5kIGl0 IGFsb25nIHdpdGggdGhlIHJlZ2lzdHJhdGlvbiBmb3JtIHRvOiANDUZpcnN0IFdvcmxkIENvbmdy ZXNzIG9mIEZ1dHVyZSBTY2llbmNlIGFuZCBDdWx0dXJlDTEgTWFnZGFsZW5lIENsb3NlLCBMb25n c3RhbnRvbiwgQ2FtYnJpZGdlIENCNCA1RUcsIFVuaXRlZCBLaW5nZG9tDQ1BbHRlcm5hdGl2ZWx5 LCB5b3UgY2FuIHJlZ2lzdGVyIGJ5IHNlbmRpbmcgYW4gZW1haWwgdG86IBMgSFlQRVJMSU5LICJt YWlsdG86ZnNjX2NvbmdyZXNzQGhvdG1haWwuY29tIiABFGZzY19jb25ncmVzc0Bob3RtYWlsLmNv bRUuDQ0IDQ0TUEFHRSAgFDEVDQ0NE1BBR0UgIBQxFQ0NDQ0NDQ0NDUZpcnN0IFdvcmxkIENvbmdy ZXNzIG9mIEZ1dHVyZSBTY2llbmNlIGFuZCBDdWx0dXJlDU1hcmNoIDktMTAsIDIwMDIsIENhbWJy aWRnZSwgVW5pdGVkIEtpbmdkb20NDQENDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAQQAAAIEAAADBAAAPAQAAKMF AAAzBwAANQcAADwHAAA+BwAAgQkAAMYJAADHCQAARgoAAEgKAACeCgAAoAoAAKQKAACmCgAAqAoA ANgKAADaCgAA3goAADALAAAyCwAANAsAAGoLAABsCwAAcAsAAHILAAB6CwAAngsAAKALAAC8CwAA vgsAAMALAADCCwAA8AsAAPILAAAcDAAA0gwAANQMAAB+DgAAgA4AADwPAAD06uTh2uHW4dbh0crR v8rRyrG/qKG/ypO/qL/K4QCQAIkAh32HAIcAdQB1AAAAAAAAAAAAAAAPUEoEAG1ICQhvKAFzSAkI EjUIgVBKBABtSAkIbygBc0gJCAADNQiBDUIqAENKGABwaAAAAP8EUEoDAAAbAgiBA2rpAAAABggB Q0oUAE9KAgBRSgIAVQgBDDBKDwBDShYAUEoEAAAQMEoPAENKFABPSgIAUUoCAAAbAgiBA2oAAAAA BggBQ0oUAE9KAgBRSgIAVQgBFQNqAAAAAENKFABPSgIAUUoCAFUIAQxDShQAT0oCAFFKAgAACENK FgBQSgQAAAdDShYASCoBDENKFgBPSgAAUUoAAAAEQ0oWAAALNQiBT0oDAFFKAwATNQiBT0oDAFFK AwBtSAkIc0gJCBY1CIFPSgMAUUoDAG1ICQhvKAFzSAkILAAEAAABBAAAAgQAAAMEAAAdBAAAHgQA ACAEAAA6BAAAPAQAAKMFAAClBQAAEAgAABEIAABFCQAARgkAALEJAACzCQAAxAkAAMUJAADGCQAA yQkAANYJAABGCgAAoAoAANoKAABuCwAAcgsAAHYLAAB4CwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA +AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAA AAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAA AAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgA AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABEQAAAQAAAAQAAAMkAWEkAQAcAAQAAMIiAADgIgAA5SIAAEkjAAD+/v7+ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBAQR4CwAAegsAAJ4LAACgCwAAvAsAAL4LAADw CwAA8gsAABwMAAAeDAAAzgwAANAMAAB6DgAAfA4AADwPAAA+DwAAVBAAAFYQAAA2EQAAOBEAAFYR AABYEQAAiBEAAIoRAAAYEgAAGhIAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADz AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA6QAAAAAA AAAAAAAAAPMAAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAANsAAAAAAAAAAAAA AADzAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAA AAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAA AAAAAAAAAAAAAAAAAAAOAAAPhKAFEYRg+jckADgkAEgkAF6EoAVghGD6AAkAAA+EoAURhGD6XoSg BWCEYPoGAAA3JAA4JABIJAAAAQEAAAECAAABAAAAGTwPAABCDwAARA8AAFAPAABWEAAAWhAAAFwQ AACEEAAAiBAAAJAQAAA8EQAAPhEAAFgRAACKEQAAHhIAACASAABEEgAARhIAAFYSAABYEgAAdBIA AHYSAABEEwAARhMAAFITAAC8FAAAzBQAANAUAADcFAAA4BQAAAgVAABIFQAA6BUAAOoVAAAQFgAA EhYAAJwWAAA6FwAAPBcAAEYYAABIGAAA1BgAANYYAAD6GAAAUhkAAOwZAADuGQAAMBsAADIbAABM GwAAchsAAHwbAAB+GwAAnhsAAKAbAACkGwAAphsAAMgbAADKGwAAWhwAAPAcAADyHAAAAB0AABYe AAAYHgAAHB4AAB4eAABEHgAARh4AAGweAAD2HgAA/h4AAAIfAABkHwAAZh8AAGgfAAD67foA+u36 5N367frW+u367frd+u367foA+t363frW+u367d367frd+u363frt+u361vrW+tb67frt3frt+gDR +u367d36AMrGwr8AAAAEQ0oWAAAHNQiBQ0oWAAc1CIFDShwADENKFgBtSAkIc0gJCAAJQioCcGgA AP8ADDUIgUIqAXBoAAAAAAANQioBUEoEAHBoAAAAABBCKgFQSgQAbygBcGgAAAAAABhCKgFQSgQA bUgJCG8oAXBoAAAAAHNICQgACUIqAXBoAAAAAABLGhIAAG4SAABwEgAAPhMAAEATAAA8FAAAPhQA ALwUAAC+FAAAwBQAAMIUAADEFAAAxhQAAMgUAAAGFQAACBUAAEwVAABOFQAA5BUAAOYVAAA2FwAA OBcAANAYAADSGAAA6BkAAOoZAAAsGwAALhsAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA6wAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADrAAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAAAAAAOAAAPhKAFEYRg+jck ADgkAEgkAF6EoAVghGD6BgAANyQAOCQASCQAABsuGwAAShsAAEwbAABwGwAAchsAAKAbAACiGwAA 7BwAAO4cAAAYHgAAGh4AAMAeAADCHgAA9h4AAPoeAAD8HgAA/h4AAAAfAAACHwAAZB8AAGgfAACM HwAAVSAAAFcgAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA AN0AAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA2wAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAA2wAAAAAAAAAA AAAAANsAAAAAAAAAAAAAAADWAAAAAAAAAAAAAAAA1gAAAAAAAAAAAAAAANQAAAAAAAAAAAAAAADS AAAAAAAAAAAAAAAA1gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARcAAAEE AAAEAAADJAFhJAEAAQAADgAAD4RkBRGEnPo3JAA4JABIJABehGQFYISc+g4AAA+EoAURhGD6NyQA OCQASCQAXoSgBWCEYPoGAAA3JAA4JABIJAAAF2gfAACgHwAAxh8AAFUgAABWIAAAVyAAAGUgAABm IAAAbSAAAG4gAABvIAAAoiAAAKMgAADGIAAAxyAAAM4gAADPIAAA0CAAAOggAADpIAAA8CAAAPEg AADyIAAAyCEAAD4iAAB1IgAAdiIAAHciAACkIgAApSIAAKYiAAC+IgAAvyIAAMEiAADCIgAAwyIA AMUiAADGIgAAzCIAAM0iAADOIgAAzyIAANAiAADSIgAA0yIAANkiAADaIgAA2yIAANwiAADdIgAA 5SIAABgjAABFIwAAAP0A+fbv5uLY5vbi9ubizub25uLE5vbCAMK7wrG7rbvC9qIAm5ibkJuYAJuY m5CbmACHAAAAAAAAABA1CIFCKg9DShwAcGiAgIAAAA8wShQAbUgABG5IAAR1CAEEMEoUAAANA2oA AAAAMEoUAFUIARQDagAAAABVCAFtSAAEbkgABHUIAQAHMEoPADUIgRICCIEDarYGAAAGCAE1CIFV CAEADANqAAAAADUIgVUIAQADNQiBEwIIgQNqFAUAAAYIAUNKFgBVCAETAgiBA2pyAwAABggBQ0oW AFUIARMCCIEDatABAAAGCAFDShYAVQgBBwIIgUNKFgAQAgiBA2oAAAAAQ0oWAFUIAQAMQ0oWAE9K AABRSgAAAARDShYAAAc1CIFDShYABENKGAA0VyAAAGUgAAB6IAAAhCAAAKEgAACiIAAAoyAAAKQg AAClIAAApiAAAKcgAADEIAAAxiAAANUgAADeIAAA5yAAAOggAADzIAAA9CAAAPkAAAAAAAAAAAAA AADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAACkEAAAAAAAAAAAAAAA8wAA AAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAApAAAAAAAAAAAAAAAAKIAAAAAAAAA AAAAAACiAAAAAAAAAAAAAAAAogAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA 8wAAAAAAAAAAAAAAAKQ4AAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAE8AABYkARckAUlmAQAAAAjWRgADCAArCkATJh6ABiMKAAAAAAAAAAAAAAAA AAAAAIAGFQkAAAAAAAAAAAAAAAAAAAAAgAbmCgAAAAAAAAAAAAAAAAAAAAAU9gEAABrWDAAAAP8A AAD/AAAA/xvWDAAAAP8AAAD/AAAA/xzWDAAAAP8AAAD/AAAA/x3WDAAAAP8AAAD/AAAA/2H2AxAA BgAAFiQBSWYBAAAAAAUWABOkZAAUpGQAABL0IAAA9SAAAPYgAAD3IAAA/iAAABAhAAAgIQAAOyEA ADwhAAA9IQAAxyEAAMghAAD7IQAAPSIAAD4iAADBIgAAwiIAAMQiAADFIgAA+QAAAAAAAAAAAAAA AKoAAAAAAAAAAAAAAACoAAAAAAAAAAAAAAAAqAAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAACoAAAA AAAAAAAAAAAAqAAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAACoAAAAAAAAAAAAAAAAqAAAAAAAAAAA AAAAAKgAAAAAAAAAAAAAAACiAAAAAAAAAAAAAAAAogAAAAAAAAAAAAAAAKIAAAAAAAAAAAAAAACi AAAAAAAAAAAAAAAAogAAAAAAAAAAAAAAAKAAAAAAAAAAAAAAAACoAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAABEgAGEgANxgYC4BDAIQAAAQAATwAAFiQBFyQBSWYBAAAACNZGAAMIACsKQBMmHoAGIwoA AAAAAAAAAAAAAAAAAAAAgAYVCQAAAAAAAAAAAAAAAAAAAACABuYKAAAAAAAAAAAAAAAAAAAAABT2 AQAAGtYMAAAA/wAAAP8AAAD/G9YMAAAA/wAAAP8AAAD/HNYMAAAA/wAAAP8AAAD/HdYMAAAA/wAA AP8AAAD/YfYDEAAGAAAWJAFJZgEAAAAAEsUiAADQIgAA0SIAANIiAADdIgAA3iIAAN8iAADgIgAA 4SIAAOIiAADjIgAA5CIAAOUiAAAYIwAARCMAAEUjAABHIwAASCMAAEkjAABKIwAA9gAAAAAAAAAA AAAAAPAAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADu AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA7gAAAAAA AAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOQAAAAAAAAAAAAA AADuAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA3gAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAYSAA3GBgLgEMAhAAAEAQADJAFhJAEABAAAAyQBYSQBAAEAAAAFEwAOhGgB XYRoAQAIEwAYhPj/GYQBABsmYCMkAgATRSMAAEYjAABJIwAASiMAAPcA9AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE Q0oWAAAPA2qdBwAANQiBPioBVQgBAAMgADGQaAEfsNAvILDgPSGwCAcisAgHI5CgBSSQoAUlsAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAOkAAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAFwAA ABoAAABmAHMAYwBfAGMAbwBuAGcAcgBlAHMAcwBAAGgAbwB0AG0AYQBpAGwALgBjAG8AbQANAAAA 4Mnqefm6zhGMggCqAEupC0AAAABtAGEAaQBsAHQAbwA6AGYAcwBjAF8AYwBvAG4AZwByAGUAcwBz AEAAaABvAHQAbQBhAGkAbAAuAGMAbwBtAAAA5wAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIA AAAXAAAAHAAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBmAHMAYwAtAGMAbwBuAGcAcgBlAHMAcwAu AG8AcgBnAAAA4Mnqefm6zhGMggCqAEupCzoAAABoAHQAdABwADoALwAvAHcAdwB3AC4AZgBzAGMA LQBjAG8AbgBnAHIAZQBzAHMALgBvAHIAZwAvAAAAogEAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgMAGgIAAAAAAU4BAAAA AAAAAAIAAgACAAEAAAAAAPAeAQAAABoAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAwiQOAAMlDgAbAAAAKyUOABwAAAAjCgAAIwoAAIwAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAcAQAAFQkAABUJAACMAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAIAAOYK AADmCgAAjAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABsBAACoJQ4AHAMAACMKAAAjCgAA1AYA AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwEAAAVCQAAFQkAANQGAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAcBQAA5goAAOYKAADUBgAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKIBAABEAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAgIDABoCAAAAAAFOAQAAAAAAAAACAAIAAgABAAAAAADwHgEAAAAaAQAAAAAAAAAAAAAAAAAA AAAAAAEAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPwmDgAfJw4AGwIAAD0nDgAcBgAAIwoAACMK AACMAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAcAABUJAAAVCQAAjAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABwIAADmCgAA5goAAIwAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbAwAA sCcOABwJAAAjCgAAIwoAANQGAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcCgAAFQkAABUJAADU BgAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAsAAOYKAADmCgAA1AYAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACiAQAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAwAaAgAAAAABTgEAAAAAAAAAAgACAAIAAQAAAAAA8B4B AAAAGgEAAAAAAAAAAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAD8Jg4AHycO ABsCAAA9Jw4AHAYAACMKAAAjCgAAjAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwHAAAVCQAA FQkAAIwAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcCAAA5goAAOYKAACMAAAAAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAGwMAALAnDgAcCQAAIwoAACMKAADUBgAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAHAoAABUJAAAVCQAA1AYAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwLAADmCgAA5goA ANQGAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5wAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEup CwIAAAAXAAAAGQAAAGYAcwBjAF8AYwBvAG4AZwByAGUAcwBzAEAAaABvAHQAbQBhAGkAbAAuAGMA bwBtAAAA4Mnqefm6zhGMggCqAEupC0AAAABtAGEAaQBsAHQAbwA6AGYAcwBjAF8AYwBvAG4AZwBy AGUAcwBzAEAAaABvAHQAbQBhAGkAbAAuAGMAbwBtAAAAuwwAAEQAZACAAD4AAAAAAAAAAAAAAAAA AAAAAIAHogNpA2kDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwVAAAALIECvAI AAAAAQQAAAAKAABjAAvwMAAAAARBAQAAAAXBDAAAAAYBAgAAAIEBEQAAEL8BAAAQAP8BAAAIAGwA bwBnAG8AMQAAAAAAEPAEAAAAAAAAwmIAB/ATDAAABgaGdSvcXhwaajwGQxOK+Yt1/wDvCwAAAQAA AOEHAAAAAKkCAG4e8OcLAACGdSvcXhwaajwGQxOK+Yt1/4lQTkcNChoKAAAADUlIRFIAAACAAAAA PggDAAAA1CDj/AAAAwBQTFRFAAAAMwAAZgAAmQAAzAAA/wAAADMAMzMAZjMAmTMAzDMA/zMAAGYA M2YAZmYAmWYAzGYA/2YAAJkAM5kAZpkAmZkAzJkA/5kAAMwAM8wAZswAmcwAzMwA/8wAAP8AM/8A Zv8Amf8AzP8A//8AAAAzMwAzZgAzmQAzzAAz/wAzADMzMzMzZjMzmTMzzDMz/zMzAGYzM2YzZmYz mWYzzGYz/2YzAJkzM5kzZpkzmZkzzJkz/5kzAMwzM8wzZswzmcwzzMwz/8wzAP8zM/8zZv8zmf8z zP8z//8zAABmMwBmZgBmmQBmzABm/wBmADNmMzNmZjNmmTNmzDNm/zNmAGZmM2ZmZmZmmWZmzGZm /2ZmAJlmM5lmZplmmZlmzJlm/5lmAMxmM8xmZsxmmcxmzMxm/8xmAP9mM/9mZv9mmf9mzP9m//9m AACZMwCZZgCZmQCZzACZ/wCZADOZMzOZZjOZmTOZzDOZ/zOZAGaZM2aZZmaZmWaZzGaZ/2aZAJmZ M5mZZpmZmZmZzJmZ/5mZAMyZM8yZZsyZmcyZzMyZ/8yZAP+ZM/+ZZv+Zmf+ZzP+Z//+ZAADMMwDM ZgDMmQDMzADM/wDMADPMMzPMZjPMmTPMzDPM/zPMAGbMM2bMZmbMmWbMzGbM/2bMAJnMM5nMZpnM mZnMzJnM/5nMAMzMM8zMZszMmczMzMzM/8zMAP/MM//MZv/Mmf/MzP/M///MAAD/MwD/ZgD/mQD/ zAD//wD/ADP/MzP/ZjP/mTP/zDP//zP/AGb/M2b/Zmb/mWb/zGb//2b/AJn/M5n/Zpn/mZn/zJn/ /5n/AMz/M8z/Zsz/mcz/zMz//8z/AP//M///Zv//mf//zP//////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3jnFswAAAAFiS0dE 15CyWj8AAAiESURBVHiczZk9b+JYF8dHClNRpQkNNE+Dmx03W+02IAHTeIo4xeCG0UjLY4+2D8Xa W/hCgSjmMywjxUSaW1lKpACPggZRZJpQ+es855zra18bQ5jsy+zlJY65vud3/ufFl+RF9J3Hi2de t338+rBOHg+P2+0/B/C4Xi9vC8Zy/fAMim8E2D4ktm9uFzficbOAXxKIvxHg8SExvlgs5nKs5vMF Phbxh9/GcDyA9B18BqN39zA29Izf5vcAshBSrI+PxbEAsfM3YPte2NzgUww6Jo671VwwLI9FOA7g IRZ+viLX0eh082l6DY/hpxm8z+D3jVACI4IMX77+ZQDS/OpuFRu/Ho5Gk/9ObDkm9mg0HM2mqAZG YyUQjlHhaYDtMnZeuD6djSbvbdtpOW0cH+i93XIc27Eno+G1gLhbUU4ekY5PApD7mPNofgq+g3G0 3el0GvCodRqv8WenA+cc0GI4EsG4o0A8nQpPAKTuC+Undgt87jSa1UatUq3IAceNJmCAIqADyYDJ cIwIhwEehXkSfzoa2g56Xq3VKpXTcrn8Eh/0Vi6fnlYAqFkFBqdlj4afEGGOCF/+BMCa5BfiD0dk vlFtVsB04SifVmpnjdedNqoAGXm/uSMRDobhEMA6Mb/5fQLmIeq1ymlsTWcW4xye8GLM0hMGiEYH GSgX7qlBPj4PYBnLv9l8GjpOC7SvVMh33WIF0zkTEGVICcwGqIkZIiDBgUTYD5DID4WH7jcqFeE5 378as2QoGiTCDCtyfpBgL8AXNL+i5Ju02p1mlcwX+p5liBGqTRDBHmJXQIK9ebAPYI19HxvfdGK3 2xB7FN864LyCgKGAXAARPmAmYEHuz4M9AJh/ZH82QvVrmHp6xnwoXsoPBQFVgGxEguE11eNeDYoB 0P8Fph+WPiQfuq+Kn5rNHsnBrUQEm1JxvljefgPAQ2yfwi/k17PmE7thjkQVoUwiOO+R4G5xuzwa YEu3PgAYUvqdZtzPuRzmBEgZRCaQBkPMg8Xt+lgArD/0/9p2oPjQvox+mLzCyFNkD3NMNEQYUAMq x/lNYTEWACxl/aP/tUom+8LEaugNAqFXBi5UNGBEUGu0RUMoTsRdAEwAtH/93mlD8yml4Q+l/GRj 4HoAZrxhbo4uTBBYGgWoRijGgjTYAcAb4Gq+uZ9OwD51H656mK7veV7gXnjem4EUyB2E8ac7USCC eVEa7ACIAGw2I7vVaSr2YwdT9wIcAwjEFROCsIDFyZBGQRA0oB+IYtztR3kAEQBqAKL+1e6jrAz6 BsFVEHiIcRW5IEdwtU0mJRMt7MuQBg6VwuLmf08BiA64maL9n8tK/Qnfw7Cu1TVNMzQjuOIB53/w Ledbb+AGfLvlsg5SUK5jP6BExKa82KmEHMBaBGA6sqEAoACtxH78ZpimZ5oXhmeygI8D7vPoM+cg /9eLS89LrScIgqDagaZMlZDPwyzANm6Bw0mbEkDpf5RfsGzJdV3P1UqejzsR2I+EIQ+9PwLX0y5l MwrVYuQyDSZYCTt5mAXAe/Ad3oFa7eZZLgHkMOuez5imXQTj3sfxL7/2+x/HASTgpWcYpquIJQeL 08BGAmhHhwBIAKyAXACEU3FoTQ2Sz4AGMO7j49f+R8b8wGOXhmFo9Vc4L3tvioPQnohmkM2CDMBD nAHUgsuZG5A63Isrpplds0/m+/1fgMBl7sB8gwTbKMr0Q9mPsCWjBLksyABgCQgBXlfKmRuwqgAQ mAE3PQ8I+h2MQb/HIAcM7VIzfOUemQyLKgEkGO4WggogBZi0qAXkBEgXPdGMV5oBafCu3zsp/QhC jF3fM0yoED+dqRDIPBT9MPtNQQVYowBQAvaHRi3fglJV355AHzBNc+Ca2kmpbho/jftd5g8wBlfK dHVYL0uiFDELsmmoAsge4PwnV4LxqhSCt/VSXTNMz33nD0AH89z7qfdu7FpQnL/xZF7WfiKBI3qB GgMFALswNMFrKIGzSnYLprYXv35i/GC4XT4eXxqvzAsGjQkao1YvvY3knFzXTgrBoUpcqK1AAUgi 0G5iCu4IEEnPAOGkdFKv++zcMMY933K7l6apmerE3KBCaFbb9nU+BgqAEECkoNoDpEfqTeaz7+N2 xO+N/XG37vpd85wnE3cFiCLaIjY6zpDSUIlBCrAVXZBS8DQfgXTtzMqu7/dYr6vsmCK1XJVBaVgr iEEKgEWITQD3QQURKNhyQVN0fbd3bn5W5uQbcTxkM5r8Tnv0IgCRArgRqhXVQCQbjFriptl16+65 Yj4skJ8GxuCsCa1gs4EtehHAUqQA1MDPxREgG7ke5/9mdv10z1TovBi6aAUOAMC+JN2dpgCiC4zs D9U9KRCl+sp+i2Mr8/6gAJAE2stKs9GyZ9lOoAKgAsN9KZDzMsyAFH45yg5KgjPYns6wEAsAHulG BFshvA/oF4fsqzJkvpPstR5hMyyVMAtt2pmlWfic/xcUfBcLD1s/MJ73D4s0DlH4pO9/B8AuzncF +FPjXwDAdBhxL+HFf3+zkr9N6VbBhMJhUS+FS+W1XGdF6yOAxXB/H8FLt8QBPpWlmCUJmVytaMPO lQs5AXBdt+DyeHHGdLazPgIwAADXcC6+wCL8ilaFMnCScVyL5kQoWASOwSHOYHiC/nxG88Ed+JhU Fexoi6ZyWpHFx2J9K1bAigHETJqASyGxCAGsBmc4TrPwNBeqoEOM5nGah2LiEz+zBACPAydmI24M INdHAI5a5QAsoQwCWHQMZ8gXiwSLZ6GW4oRwF61zFrspFUi8VgGYXD8B0C2SF+DBXwSAF4ulxTMW RUf4Z0kAvEjOI3ViALpEZIJO6tGajC6Xx/F1L0A5oR8oiCpGyEXnuBCAfnLMP3jHJ6NJkZjO6HMe ySU4/Qk9Ysq1YgYTp3lyHH/23fvA/wFDaXstvvCcBwAAAABJRU5ErkJgggAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAUABgACgABAGkADwADAAAAAwAAAAAAPAAAQPH/AgA8AAwABgBOAG8AcgBtAGEA bAAAAAIAAAAcAENKGABfSAEEYUoYAG1ICQRuSAQIc0gJBHRIBAhAAAFAAQACAEAADAAJAEgAZQBh AGQAaQBuAGcAIAAxAAAACAABAAYkAUAmABMANQiBQioPQ0oSAFwIgXBomZmZAAA2AAJAAQACADYA DAAJAEgAZQBhAGQAaQBuAGcAIAAyAAAACAACAAYkAUAmAQoANQiBUEoAAHUIADQAAwABAAIANAAM AAkASABlAGEAZABpAG4AZwAgADMAAAAIAAMABiQBQCYCBwA1CIFDShYAADYABEABAAIANgAMAAkA SABlAGEAZABpAG4AZwAgADQAAAAOAAQAAyQBBiQBQCYDYSQBAwA1CIEAAAAAAAAAAAAAADwAQUDy /6EAPAAMARYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAA AAAAAAAAAAAuAFVAogDxAC4ADAAJAEgAeQBwAGUAcgBsAGkAbgBrAAAADAA+KgFCKgJwaAAA/wBE AEMAAQACAUQADAAQAEIAbwBkAHkAIABUAGUAeAB0ACAASQBuAGQAZQBuAHQAAAAKABAAEYTQAmCE 0AIIAE9KAwBRSgMAegD+TwEAEgF6AAwACgBIAFQATQBMACAAhJhIUTxoD18WUwAANwARAA3GMgAQ lAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAABwAQ0oUAE9K BQBQSgUAUUoFAF5KBQBhShQAdEgJBCwAH0ABACIBLAAMAAYASABlAGEAZABlAHIAAAANABIADcYI AALgEMAhAQIAAAAsACBAAQAyASwADAAGAEYAbwBvAHQAZQByAAAADQATAA3GCAAC4BDAIQECAAAA JgApQKIAQQEmAAwACwBQAGEAZwBlACAATgB1AG0AYgBlAHIAAAAAAFIA/g/x/wIAUgAOAAYAegAt AJd6U0+VXuiQAAAOABUAAyQBJGQCAwEAYSQBJgA8CIFDShAAT0oCAFBKAABRSgIAX0gBBGgIAG1I CQRzSAkEdEgJBFIA/k/x/wIAUgAOAAYAegAtAJd6U092mOiQAAAOABYAAyQBJmQCAwEAYSQBJgA8 CIFDShAAT0oCAFBKAABRSgIAX0gBBGgIAG1ICQRzSAkEdEgJBC4AQkABAHIBLgAMAAkAQgBvAGQA eQAgAFQAZQB4AHQAAAACABcABwA1CIFDShYAAAAAAAABAAAAAgAAAAMAAAAEAAAAShQAAP////8A AAAAAQD/////AAAAAAAAAAAAAAAAAQAAAAEA/////wAAAAAAAAAAAQAAAAIAAAABAP////8AAAAA AAAAAAIAAAADAAAAAQD/////AAAAAAAAAAADAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAC AAAAAwAAAAQAAAAHAAAAAAAAAAAIAQAAAAAIAgAAAAAIAwAAAAAI//8AAAAAAAAAAGAAAABjAAAA ShQAAAEAAAAAAAAAAAD/////CgQAAAAAAAABAAAAAAAAAAAA/////wkEAAAAAAAA/////wAAAAAA AAAAAAAAAAAAAAAAAAAAAABgAAAAYwAAAGYAAAAAAAAAAAgBAAAAAAj//wAAAAAAAAAAShQAAAUA AEIAAAAA/////wAAAAABAAAAAgAAAAMAAAAdAAAAHgAAACAAAAA6AAAAPAAAAKMBAAClAQAAEAQA ABEEAABFBQAARgUAALEFAACzBQAAxAUAAMUFAADGBQAAyQUAANYFAAAjBgAAUAYAAG0GAAC3BgAA uQYAALsGAAD4BgAA+QYAAA4HAAAPBwAAZwcAAGgHAAA9CAAAPggAAJ4IAACfCAAAKgkAACsJAACb CQAAnAkAAKsJAACsCQAAxAkAAMUJAAAMCgAADQoAADcKAAA4CgAAnwoAAKAKAAAeCwAAHwsAAF4L AABfCwAAYAsAAGELAABiCwAAYwsAAGQLAACDCwAAhAsAAKYLAACnCwAA8gsAAPMLAACbDAAAnAwA AGgNAABpDQAA9A0AAPUNAACWDgAAlw4AAKUOAACmDgAAuA4AALkOAADQDgAA0Q4AAHYPAAB3DwAA DBAAAA0QAABgEAAAYRAAAHsQAAB9EAAAfhAAAH8QAACAEAAAgRAAALIQAAC0EAAAxhAAAFURAABX EQAAZREAAHoRAACEEQAAoREAAKIRAACjEQAApBEAAKURAACmEQAApxEAAMQRAADGEQAA1REAAN4R AADnEQAA6BEAAPMRAAD0EQAA9REAAPYRAAD3EQAA/hEAABASAAAgEgAAOxIAADwSAAA9EgAAxxIA AMgSAAD7EgAAPRMAAD4TAADBEwAAwhMAAMQTAADFEwAA0BMAANETAADSEwAA3RMAAN4TAADgEwAA 4RMAAOITAADjEwAA5BMAAOUTAAAYFAAARBQAAEUUAABHFAAASBQAAEsUAACYAAAAAAAAAAAAAAAA gAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAA AICYAAAAAAAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICaAAAAADAAAAAAAAAAgAAAAICY AAAAAAAAAAAAAAAAgAAAAICYAAAAEQAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAA AAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAA AAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAA AAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAA gAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAA AICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICeAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgKIGAACYAAAA AAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAA AAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAA AAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAA gKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIG AACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACY AAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAA AAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAA AAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAA AAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAA gKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIG AACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACY AAAAAAAAAAAAAAAAgKIGAACYQAAAAAAAAAAAAAAAgKIGAACYAAAAADAAAAAAAAAAgAAAAICYQAAA AAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYQAAAAAAAAAAAAAAAgKIGAACYAAAAAAAA AAAAAAAAgKIGAACYQAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYQAAAAAAAAAAA AAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYQAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAA gKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYQAAAAAAAAAAAAAAAgKIG AACYAAAAAAAAAAAAAAAAgKIGAACYQAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACY QAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYQAAAAAAAAAAAAAAAgKIGAACYAAAA AAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAA AAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAACYAAAAAAAAAAAA AAAAgKIGAACYAAAAAAAAAAAAAAAAgKIGAAA4AAAABAAAAAAAAAAAgKIGAACYAAAAFwAAAAAAAAAA gIYQAACYAAAAAAAAAAAAAAAAgIYQAACYAAAAFgAAAAAAAAAAgIYQAACpAAAAAAAAAAAAAAAAgIYQ AACpAAAAAAAAAAAAAAAAgIYQAACpAAAAAAAAAAAAAAAAgIYQAACcAAAAAAAAAAAAAAAAgAAAAICp AAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICZAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgIYQAACYAAAAAAAA AAAAAAAAgIYQAACpAAAAAAAAAAAAAAAAgIYQAACpAAAAAAAAAAAAAAAAgIYQAACpAAAAAAAAAAAA AAAAgIYQAACcAAAAAAAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAA gAAAAICpAAAAADAAAAAAAAAAgAAAAICZAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAAAAAAAAAAAAAgIYQAACYAAAAAAAAAAAAAAAAgIYQAACYAAAAAAAAAAAAAAAAgIYQAACY AAAAAAAAAAAAAAAAgIYQAACYAAAAAAAAAAAAAAAAgIYQAACYAAAAAAAAAAAAAAAAgIYQAACYAAAA AAAAAAAAAAAAgIYQAACYAAAAAAAAAAAAAAAAgIYQAACYAAAAEgAAAAAAAAAAgIYQAACYAAAAEgAA AAAAAAAAgIYQAACYAAAAEgAAAAAAAAAAgAAAAICYAAAAEgAAAAAAAAAAgAAAAICYAAAAEjAAAAAA AAAAgAAAAICYAAAAEgAAAAAAAAAAgAAAAICYQAAAAAAAAAAAAAAAgAAAAICYQAAAEwAAAAAAAAAA gAAAAICYQAAAEwAAAAAAAAAAgAAAAICYQAAAAAAAAAAAAAAAgAAAAICaQAAAEzAAAAAAAAAAgAAA AICYQAAAEzAAAAAAAAAAgAAAAIAKAAAAAAAAAAAAAAAAAAAAAACYAAAAAAAAAAAAAAAAgAAAAICY AAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAA AAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAIAIAAAAAQAAAAAAAAAAgAAAAICYAAAAAAAA AAAAAAAAgDMAAACYAAAAAAAAAAAAAAAAgDMAAACYAAAAAAAAAAAAAAAAgDMAAACaAAAAAAAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAQAAAAHQAAAB0AAAAd AAAAIAAAAAAEAAA8DwAAaB8AAEUjAABKIwAAFQAAABkAAAAcAAAAIAAAAAAEAAB4CwAAGhIAAC4b AABXIAAA9CAAAMUiAABKIwAAFgAAABgAAAAaAAAAGwAAAB0AAAAeAAAAHwAAAAAEAABJIwAAFwAA ACMGAABTBgAAbQYAAG4GAACZBgAAtQYAAHYTAAClEwAAvhMAAEoUAAATWBT/FYATWBT/FYATWBT/ FYQDAAAACgAAAAwAAAAQAAAAFwAAABkAAAAgAAAAEyF0/5WAEyF0/5WACgAAAP//////////AAAA AAAAAAAAAAAA//////////8AAAAAAAAAAAAAAAD//////////wAAAAAAAAAAAAAAAP////////// AAAAAAAAAAAAAAAA//////////8AAAAAAAAAAAAAAAD//////////wAAAAAAAAAAAAAAAP////// ////AAAAAAAAAAAAAAAA//////////8AAAAAAAAAAAAAAAD//////////wAAAAAAAAAAAAAAAP// ////////AAAAAAAAAAAAAAAADwAA8EAAAAAAAAbwIAAAAAIMAAADAAAAIQAAAAIAAAABAAAADAAA AAIAAAAWAAAAQAAe8RAAAAD/////lpaWAICAgAD3AAAQAA8AAvCSAAAAIAAI8AgAAAABAAAAFQgA AA8AA/AwAAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAIAAAFAAAA DwAE8EIAAAASAArwCAAAAAEIAAAADgAAUwAL8B4AAAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/ AwEAAQAAABHwBAAAAAEAAAABDwAC8FYCAAAQAAjwCAAAAAYAAAALBAAADwAD8D4CAAAPAATwKAAA AAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAAPwBgIAAA8ABPBoAAAA AQAJ8BAAAAAIBwAAhAMAAHwpAAC8BwAAAgAK8AgAAAAHBAAAAQIAABMAC/AGAAAAiAMAAAAAMwAi 8RIAAACQAwIAAACSAwIAAAC/AwAAAIAAABDwBAAAAAAAAAAAABHwBAAAAAEAAAAPAAPwJgEAAA8A BPBaAAAAAQAJ8BAAAAC8BwAAhAMAAMgoAAC8BwAAAgAK8AgAAAAIBAAAAwIAABMAC/AGAAAAiAMA AAAAAAAP8BAAAAC8BwAAhAMAAMgoAAC8BwAAAAAR8AQAAAABAAAADwAE8FoAAACiDArwCAAAAAkE AAACCgAAMwAL8BIAAACAAAAAAgC/AQAAEAD/AQAACAAAAA/wEAAAALwHAACEAwAAdw8AAE4HAAAA ABHwBAAAAAEAAAAAAA3wBAAAAAAAAgAPAATwWgAAAKIMCvAIAAAACgQAAAIKAAAzAAvwEgAAAIAA AAABAL8BAAAQAP8BAAAIAAAAD/AQAAAAxA4AADgEAADIKAAAvAcAAAAAEfAEAAAAAQAAAAAADfAE AAAAAAABAA8ABPBgAAAAQgEK8AgAAAALBAAAAgoAAGMAC/AkAAAARAEEAAAAfwEAAAEAvwEAABAA wAGWlpYAywFqSgAA/wEYABgAAAAP8BAAAAAIBwAAvAcAAHwpAAC8BwAAAAAR8AQAAAABAAAAShQA AAAAAAAgAAAABwQAAAAAAAC0AAAAdCIAAOwEAAB0AAAAAAAAAAAA1wEAANwBAADdAQAA4QEAAKoC AACvAgAAsAIAALQCAADMBQAA0gUAANYFAADiBQAA4AYAAOEGAABpBwAAagcAAHEHAAB1BwAAdgcA AHoHAAD2BwAAAQgAAAcIAAAMCAAAPwgAAEAIAAChCAAAoggAAA8JAAAUCQAALQkAAC4JAAA1CQAA PQkAAD4JAABCCQAAngkAAJ8JAADMCQAA0QkAANIJAADWCQAA2AkAANwJAAAPCgAAEAoAACIKAAAj CgAAOgoAADsKAABBCgAARgoAAEcKAABLCgAAogoAAKMKAACpCgAArwoAALAKAAC5CgAALgsAADUL AAA2CwAAPAsAAD8LAABECwAARQsAAEkLAACuCwAAtAsAAPQLAAD1CwAA/wsAAAUMAAAIDAAACQwA AJ0MAACeDAAApAwAAKkMAACqDAAArQwAAGoNAABrDQAAcQ0AAHcNAAB4DQAAew0AAH0NAACBDQAA 9g0AAPcNAAD9DQAAAQ4AAF0OAABiDgAAmA4AAJkOAADLDgAAzw4AANIOAADTDgAA2Q4AAOAOAADh DgAA5A4AAOUOAAAIDwAAEA8AAHgPAAB5DwAAiQ8AAJMPAAAOEAAADxAAABUQAAAcEAAAIhAAACMQ AADCEwAA3xMAAOATAADlEwAASxQAAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABQAHAAUABwAc AAcAHAAHABwABwAcAAcABQAHAAUABwAcAAcABQAHABwABwAcAAcABQAHABwABwAcAAcAHAAHAAUA BwAFAAcABQAHABwABwAcAAcABQAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAFAAcAHAAH AAUABwAFAAcAHAAHABwABwAFAAcAHAAHABwABwAcAAcABQAHABwABwAcAAcABQAHABwABwAFAAcA HAAHABwABQAHABwABwAFAAcAHAAHAAUABwAcAAcABQAHAAcAAgAHAAcAAAAAAOMDAADmAwAA5AYA AOYGAABjBwAAZgcAAG0HAABvBwAAQwgAAEUIAAClCAAApwgAAKIJAACkCQAACAoAAAsKAAATCgAA FQoAAD4KAABACgAApgoAAKgKAAB4DQAAew0AAGEQAABkEAAAwhMAAN8TAADgEwAA5RMAAEsUAAAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAHAAIA BwAHAAAAAAAeAAAAHgAAACgAAAAuAAAAwRMAAMITAADSEwAA3BMAAEsUAAADAAQAAwAEAAMABwAC AAcAAgD//xQAAAABAC4AAAAGAGwAYQB6AGwAaQBzAAAAAQAuADoAQwA6AFwAUAByAG8AZwByAGEA bQAgAEYAaQBsAGUAcwBcAEEATwBMACAANwAuADAAYQBcAGQAbwB3AG4AbABvAGEAZABcAEkAbgB2 AGkAdABhAHQAaQBvAG4ARgBTAEMAQwBmAGkAbgBhAGwALgBkAG8AYwABAC4AVwBDADoAXABXAEkA TgBEAE8AVwBTAFwAQQBwAHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBz AG8AZgB0AFwAVwBvAHIAZABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8A ZgAgAEkAbgB2AGkAdABhAHQAaQBvAG4ARgBTAEMAQwBmAGkAbgBhAGwALgBhAHMAZAABAC4AOgBD ADoAXABQAHIAbwBnAHIAYQBtACAARgBpAGwAZQBzAFwAQQBPAEwAIAA3AC4AMABhAFwAZABvAHcA bgBsAG8AYQBkAFwASQBuAHYAaQB0AGEAdABpAG8AbgBGAFMAQwBDAGYAaQBuAGEAbAAuAGQAbwBj AAEALgA6AEMAOgBcAFAAcgBvAGcAcgBhAG0AIABGAGkAbABlAHMAXABBAE8ATAAgADcALgAwAGEA XABkAG8AdwBuAGwAbwBhAGQAXABJAG4AdgBpAHQAYQB0AGkAbwBuAEYAUwBDAEMAZgBpAG4AYQBs AC4AZABvAGMAAQAuADoAQwA6AFwAUAByAG8AZwByAGEAbQAgAEYAaQBsAGUAcwBcAEEATwBMACAA NwAuADAAYQBcAGQAbwB3AG4AbABvAGEAZABcAEkAbgB2AGkAdABhAHQAaQBvAG4ARgBTAEMAQwBm AGkAbgBhAGwALgBkAG8AYwAGAHQAaQBuAGEAZAB1ACIARAA6AFwAQQBBAEEALQBEAE8AQwBcAEkA bgB2AGkAdABhAHQAaQBvAG4ARgBTAEMAQwBmAGkAbgBhAGwALgBkAG8AYwAHAG0AagBrAHgAdABz AGwATgBcAFwAVQBLAC0AQQBDAC0AVQBNAEkAUwBUAC0ARgBTADUAXABWAE8ATAAyAFwAVQBTAEUA UgBTAFwAQwBFAFwATQBKAEsAUABJAFoAVwBYAFwARgB1AHQAdQByAGUAIABjAG8AbgBnAHIAZQBz AHMAXABJAG4AdgBpAHQAYQB0AGkAbwBuAC0AUABlAHQAZQByADIALgBkAG8AYwAMAGQAZQBmAGEA dQBsAHQAIAB1AHMAZQByACgAUAA6AFwARgB1AHQAdQByAGUAIABjAG8AbgBnAHIAZQBzAHMAXABJ AG4AdgBpAHQAYQB0AGkAbwBuAC0AUABlAHQAZQByADIALgBkAG8AYwAHAMNrwyGsIpTo/w//D/8P /w//D/8P/w//D/8PAAAmE/0slEdCDv8P/w//D/8P/w//D/8P/w//DxAAXn89Mnq1xj7/D/8P/w// D/8P/w//D/8P/w8AAK9TIEfyPPpW/w//D/8P/w//D/8P/w//D/8PEABFUNFPgJFkbv8P/w//D/8P /w//D/8P/w//DwAAr0JbVZRHQg7/D/8P/w//D/8P/w//D/8P/w8QAKB6gF/y6Ppg/w//D/8P/w// D/8P/w//D/8PAAAMAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4SUAhGEbP0VxgUAAZQCBl6E lAJghGz9bygAAwAAAC4AMAABAAAAFgABAwAAAAAAAAAAAAAAAAAAAAADGAAAD4RkBRGEbP0VxgUA AWQFBl6EZAVghGz9bygAAwAAAC4AAQABAAAAAAABAwUAAAAAAAAAAAAAAAAAAAADGAAAD4RwCBGE MP0VxgUAAXAIBl6EcAhghDD9bygABQAAAC4AAQAuAAIAAQAAAAAAAQMFBwAAAAAAAAAAAAAAAAAA AxgAAA+EQAsRhDD9FcYFAAFACwZehEALYIQw/W8oAAcAAAAuAAEALgACAC4AAwABAAAAAAABAwUH CQAAAAAAAAAAAAAAAAADGAAAD4R4DxGEyPsVxgUAAXgPBl6EeA9ghMj7bygACQAAAC4AAQAuAAIA LgADAC4ABAABAAAAAAABAwUHCQsAAAAAAAAAAAAAAAADGAAAD4RIEhGEyPsVxgUAAUgSBl6ESBJg hMj7bygACwAAAC4AAQAuAAIALgADAC4ABAAuAAUAAQAAAAAAAQMFBwkLDQAAAAAAAAAAAAAAAxgA AA+EgBYRhGD6FcYFAAGAFgZehIAWYIRg+m8oAA0AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAB AAAAAAABAwUHCQsNDwAAAAAAAAAAAAADGAAAD4RQGRGEYPoVxgUAAVAZBl6EUBlghGD6bygADwAA AC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwABAAAAAAABAwUHCQsNDxEAAAAAAAAAAAADGAAA D4SIHRGE+PgVxgUAAYgdBl6EiB1ghPj4bygAEQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4A BwAuAAgAAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY /k9KAQBRSgEAbygAAQC38AEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhKAFEYSY/hXGBQAB oAUGXoSgBWCEmP4CAAEALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RwCBGETP8VxgUA AXAIBl6EcAhghEz/AgACAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EQAsRhJj+FcYF AAFACwZehEALYISY/gIAAwAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhBAOEYSY/hXG BQABEA4GXoQQDmCEmP4CAAQALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4TgEBGETP8V xgUAAeAQBl6E4BBghEz/AgAFAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EsBMRhJj+ FcYFAAGwEwZehLATYISY/gIABgAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhIAWEYSY /hXGBQABgBYGXoSAFmCEmP4CAAcALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RQGRGE TP8VxgUAAVAZBl6EUBlghEz/AgAIAC4ACQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E0AIR hDD9FcYFAAHQAgZehNACYIQw/W8oAAEAAAAeAAAAAAABAwAAAAAAAAAAAAAAAAAAAAADGAAAD4TQ AhGEMP0VxgUAAdACBl6E0AJghDD9bygAAwAAAC4AAQABAAAAAAABAwUAAAAAAAAAAAAAAAAAAAAD GAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9bygABQAAAC4AAQAuAAIAAQAAAAAAAQMFBwAAAAAA AAAAAAAAAAAAAxgAAA+E0AIRhDD9FcYFAAHQAgZehNACYIQw/W8oAAcAAAAuAAEALgACAC4AAwAB AAAAAAABAwUHCQAAAAAAAAAAAAAAAAADGAAAD4Q4BBGEyPsVxgUAATgEBl6EOARghMj7bygACQAA AC4AAQAuAAIALgADAC4ABAABAAAAAAABAwUHCQsAAAAAAAAAAAAAAAADGAAAD4Q4BBGEyPsVxgUA ATgEBl6EOARghMj7bygACwAAAC4AAQAuAAIALgADAC4ABAAuAAUAAQAAAAAAAQMFBwkLDQAAAAAA AAAAAAAAAxgAAA+EoAURhGD6FcYFAAGgBQZehKAFYIRg+m8oAA0AAAAuAAEALgACAC4AAwAuAAQA LgAFAC4ABgABAAAAAAABAwUHCQsNDwAAAAAAAAAAAAADGAAAD4SgBRGEYPoVxgUAAaAFBl6EoAVg hGD6bygADwAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwABAAAAAAABAwUHCQsNDxEAAAAA AAAAAAADGAAAD4QIBxGE+PgVxgUAAQgHBl6ECAdghPj4bygAEQAAAC4AAQAuAAIALgADAC4ABAAu AAUALgAGAC4ABwAuAAgAAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E0AIRhJj+FcYFAAHQ AgZehNACYISY/k9KAQBRSgEAbygAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhKAF EYSY/hXGBQABoAUGXoSgBWCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAA AAALGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+T0oGAFFKBgBvKAABAKfwAQAAABeQAAAAAAAA AAAAAGgBAAAAAAAACxgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/k9KAQBRSgEAbygAAQC38AEA AAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP5PSgUAUUoF AG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBg hJj+T0oGAFFKBgBvKAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EsBMRhJj+FcYF AAGwEwZehLATYISY/k9KAQBRSgEAbygAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAP hIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEA AAAAAAALGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+T0oGAFFKBgBvKAABAKfwDQAAAAAAAQAA AAAAAAAAAAAAAAAAAAAAAxgAAA+ElAIRhGz9FcYFAAGUAgZehJQCYIRs/W8oAAMAAAAuADAAAQAA ABYAAQMAAAAAAAAAAAAAAAAAAAAAAxgAAA+EZAURhGz9FcYFAAFkBQZehGQFYIRs/W8oAAMAAAAu AAEAAQAAAAAAAQMFAAAAAAAAAAAAAAAAAAAAAxgAAA+EcAgRhDD9FcYFAAFwCAZehHAIYIQw/W8o AAUAAAAuAAEALgACAAEAAAAAAAEDBQcAAAAAAAAAAAAAAAAAAAMYAAAPhEALEYQw/RXGBQABQAsG XoRAC2CEMP1vKAAHAAAALgABAC4AAgAuAAMAAQAAAAAAAQMFBwkAAAAAAAAAAAAAAAAAAxgAAA+E eA8RhMj7FcYFAAF4DwZehHgPYITI+28oAAkAAAAuAAEALgACAC4AAwAuAAQAAQAAAAAAAQMFBwkL AAAAAAAAAAAAAAAAAxgAAA+ESBIRhMj7FcYFAAFIEgZehEgSYITI+28oAAsAAAAuAAEALgACAC4A AwAuAAQALgAFAAEAAAAAAAEDBQcJCw0AAAAAAAAAAAAAAAMYAAAPhIAWEYRg+hXGBQABgBYGXoSA FmCEYPpvKAANAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYAAQAAAAAAAQMFBwkLDQ8AAAAAAAAA AAAAAxgAAA+EUBkRhGD6FcYFAAFQGQZehFAZYIRg+m8oAA8AAAAuAAEALgACAC4AAwAuAAQALgAF AC4ABgAuAAcAAQAAAAAAAQMFBwkLDQ8RAAAAAAAAAAAAAxgAAA+EiB0RhPj4FcYFAAGIHQZehIgd YIT4+G8oABEAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAAEAAAAAEAEAAAAAAAAA AABoAQAAAAAAAAAYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP4CAAAALgABAAAABJABAAAAAAAA AAAAaAEAAAAAAAAAGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+AgABAC4AAQAAAAKSAQAAAAAA AAAAAGgBAAAAAAAAABgAAA+EcAgRhEz/FcYFAAFwCAZehHAIYIRM/wIAAgAuAAEAAAAAkAEAAAAA AAAAAABoAQAAAAAAAAAYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP4CAAMALgABAAAABJABAAAA AAAAAAAAaAEAAAAAAAAAGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+AgAEAC4AAQAAAAKSAQAA AAAAAAAAAGgBAAAAAAAAABgAAA+E4BARhEz/FcYFAAHgEAZehOAQYIRM/wIABQAuAAEAAAAAkAEA AAAAAAAAAABoAQAAAAAAAAAYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP4CAAYALgABAAAABJAB AAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+AgAHAC4AAQAAAAKS AQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EUBkRhEz/FcYFAAFQGQZehFAZYIRM/wIACAAuAAoAAAAA AAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYQw/RXGBQAB0AIGXoTQAmCEMP1vKAADAAAALgAw AAEAAAAWAAEDAAAAAAAAAAAAAAAAAAAAAAMYAAAPhKAFEYQw/RXGBQABoAUGXoSgBWCEMP1vKAAD AAAALgABAAEAAAAAAAEDBQAAAAAAAAAAAAAAAAAAAAMYAAAPhHAIEYQw/RXGBQABcAgGXoRwCGCE MP1vKAAFAAAALgABAC4AAgABAAAAAAABAwUHAAAAAAAAAAAAAAAAAAADGAAAD4RACxGEMP0VxgUA AUALBl6EQAtghDD9bygABwAAAC4AAQAuAAIALgADAAEAAAAAAAEDBQcJAAAAAAAAAAAAAAAAAAMY AAAPhHgPEYTI+xXGBQABeA8GXoR4D2CEyPtvKAAJAAAALgABAC4AAgAuAAMALgAEAAEAAAAAAAED BQcJCwAAAAAAAAAAAAAAAAMYAAAPhEgSEYTI+xXGBQABSBIGXoRIEmCEyPtvKAALAAAALgABAC4A AgAuAAMALgAEAC4ABQABAAAAAAABAwUHCQsNAAAAAAAAAAAAAAADGAAAD4SAFhGEYPoVxgUAAYAW Bl6EgBZghGD6bygADQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAAEAAAAAAAEDBQcJCw0PAAAA AAAAAAAAAAMYAAAPhFAZEYRg+hXGBQABUBkGXoRQGWCEYPpvKAAPAAAALgABAC4AAgAuAAMALgAE AC4ABQAuAAYALgAHAAEAAAAAAAEDBQcJCw0PEQAAAAAAAAAAAAMYAAAPhIgdEYT4+BXGBQABiB0G XoSIHWCE+PhvKAARAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAAHAAAAr0JbVQAA AAAAAAAAAAAAACYT/SwAAAAAAAAAAAAAAACvUyBHAAAAAAAAAAAAAAAAXn89MgAAAAAAAAAAAAAA AKB6gF8AAAAAAAAAAAAAAADDa8MhAAAAAAAAAAAAAAAARVDRTwAAAAAAAAAAAAAAAP////////// /////////////////////////////wcAAAAAAAAAAAAAAAAAAAAAAP//BwAAAAAAAAAAAAAAAAAA AAAAAAAAAFcRAABlEQAAehEAAIQRAAChEQAAohEAAKMRAACkEQAApREAAKYRAADEEQAAxhEAANUR AADeEQAA5xEAAOgRAADzEQAA9BEAAPURAAD2EQAAwhMAAN8TAADgEwAA5RMAAEsUAAABAAAAAQAA AAgAAAACAQAAAgEAAAIBAACeAQABAgEAAAIBAAACAQAAlgEAAQEAAAAIAAAAAgEAAAIBAAACAQAA ngEAAQIBAAACAQAAAgEAAJYBAAEAAAAAAQAAAAEAAAABAAAA/0ABgAEAiAEAAIgBAACczXQAAQAB AIgBAAAAAAAAiAEAAAAAAAACoAAAAAAAAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0A AAAOAAAADwAAABAAAAARAABKFAAAUAAACABAAABQAAAKAAAAAFAAAAwAAAAAUAAADgAAAABQAAAQ AAAAAFAAABIAAAAAUAAAFAAAAABQAAAWAAAAAFAAABgAAAAAUAAAGgAAAABQAAAcAAAAAFAAAB4A AAAAUAAAQABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAAAAAAAAAAAP//AQAAAAAA //8AAAIA//8AAAAA//8AAAIA//8AAAAABwAAAEcWkAEAAAICBgMFBAUCAwSHOgAgAAAAAAAAAAAA AAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYC BQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgSH OgAgAAAAAAAAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAAA7BpABhgcCAQYAAwEBAQEBAwAAAAAA DggQAAAAAAAAAAEABAAAAAAAUwBpAG0AUwB1AG4AAACLW1NPAABFNZABhggCAQYJAwEBAQEBAQAA AAAADggQAAAAAAAAAAAABAAAAAAATQBTACAAUwBvAG4AZwAAAFMAaQBtAFMAdQBuAAAAPzWQAQAA AgcDCQICBQIEBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAA ADsGkAECAAUAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkAbgBnAGQAaQBuAGcA cwAAACIABABxCIgYAPDQAgAAaAEAAAAA3tpiZl7bYmbz1WJGAwACAAAA2wIAAEoQAAABAAgAAAAE AAMQIgAAAL8BAAD3CQAAAQAFAAAAFQAAAAAAAAAhAwDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAIB6AFtAC0AIGBMjAAABAAGQBkAAAAGQAAAAEUAAC2CwAAAAAAANVTDLUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAygxEA 8BAA3wMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAABwD0gdF5ZltMdQxU wU4a/wAAAAAAAAkAUwBoAHUAIABHAHUAaQBjAGUADABkAGUAZgBhAHUAbAB0ACAAdQBzAGUAcgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAA AAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAJwBAAASAAAAAQAAAJgAAAACAAAAoAAAAAMA AADAAAAABAAAAMwAAAAFAAAA4AAAAAYAAADsAAAABwAAAPgAAAAIAAAADAEAAAkAAAAkAQAAEgAA ADABAAAKAAAATAEAAAsAAABYAQAADAAAAGQBAAANAAAAcAEAAA4AAAB8AQAADwAAAIQBAAAQAAAA jAEAABMAAACUAQAAAgAAAOn9AAAeAAAAFgAAAOiHtOenkeWtpueVjOWQjOS7ge+8mgBlAB4AAAAB AAAAAIe05x4AAAAKAAAAU2h1IEd1aWNlAJWMHgAAAAEAAAAAaHUgHgAAAAEAAAAAaHUgHgAAAAsA AABOb3JtYWwuZG90AIweAAAADQAAAGRlZmF1bHQgdXNlcgCQjOQeAAAAAgAAADMAZmEeAAAAEwAA AE1pY3Jvc29mdCBXb3JkIDkuMAC8QAAAAACMhkcAAAAAQAAAAADKEnEgv8EBQAAAAADsQheCv8EB QAAAAAC8y9qSv8EBAwAAAAEAAAADAAAA2wIAAAMAAABKEAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQACAAAAAAAAAAAAAAAAAAAAAAAC AAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuVAEAABABAAAMAAAAAQAAAGgA AAAPAAAAcAAAAAUAAACQAAAABgAAAJgAAAARAAAAoAAAABcAAACoAAAACwAAALAAAAAQAAAAuAAA ABMAAADAAAAAFgAAAMgAAAANAAAA0AAAAAwAAADyAAAAAgAAAOn9AAAeAAAAFgAAAENvbXBhcSBD b21wdXRlciBDb3JwLgAgAAMAAAAiAAAAAwAAAAgAAAADAAAAARQAAAMAAAAyEQkACwAAAAAAAAAL AAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAABYAAADoh7Tnp5HlrabnlYzlkIzku4HvvJoA DBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAA5AEAAAMAAAAAAAAAIAAAAAEAAAA4AAAAAgAA AEAAAAABAAAAAgAAAAwAAABfUElEX0hMSU5LUwACAAAA6f0AAEEAAACcAQAAGAAAAAMAAAAKAAEA AwAAAAYAAAADAAAAAAAAAAMAAAAFAAAAHwAAACAAAABtAGEAaQBsAHQAbwA6AGYAcwBjAF8AYwBv AG4AZwByAGUAcwBzAEAAaABvAHQAbQBhAGkAbAAuAGMAbwBtAAAAHwAAAAEAAAAAAAAAAwAAABgA UQADAAAAAwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAHQAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBm AHMAYwAtAGMAbwBuAGcAcgBlAHMAcwAuAG8AcgBnAC8AAAAAAB8AAAABAAAAAAAAAAMAAAAKAAEA AwAAAAAAAAADAAAAAAAAAAMAAAAFAAAAHwAAACAAAABtAGEAaQBsAHQAbwA6AGYAcwBjAF8AYwBv AG4AZwByAGUAcwBzAEAAaABvAHQAbQBhAGkAbAAuAGMAbwBtAAAAHwAAAAEAAAAAAAAAAwAAAAsA AAADAAAARSMAAAMAAAABBAAAAwAAAAEAAAAfAAAABgAAAGwAbwBnAG8AMQAAAB8AAAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJ AAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcA AAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAA/v///yMAAAAkAAAAJQAA ACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAD+////LgAAAC8AAAAwAAAAMQAAADIAAAAzAAAA NAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABC AAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAA/v///0oAAABLAAAATAAAAE0AAABOAAAATwAAAFAA AAD+////UgAAAFMAAABUAAAAVQAAAFYAAABXAAAAWAAAAP7////9////WwAAAFwAAABqAAAA/v// /18AAABgAAAAYQAAAGIAAABjAAAAZAAAAGUAAABmAAAAZwAAAGgAAABpAAAA/v////7///////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAA AAAAAEYAAAAAAAAAAAAAAADw8Uz3kr/BAV4AAABAFwAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB//////////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAAAFgUAAAAAAAAMQBUAGEA YgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA4AAgEBAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtAAAA 6zcAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAGgACAQYAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAiQgAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBv AG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASQAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1 AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABRAAAAABAAAAAAAABNAGEAYwBy AG8AcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA DgABAAIAAAAOAAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkENC95K/wQEQXkj3kr/BAQAAAAAA AAAAAAAAAFYAQgBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAIAAEB//////////8JAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQQ0L3kr/B AXDXRveSv8EBAAAAAAAAAAAAAAAAZABpAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAgD///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtgIAAAAAAABUAGgAaQBzAEQAbwBjAHUAbQBlAG4A dAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQgAAAAKAAAA//// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAAAB0BgAAAAAAAF8AVgBCAEEA XwBQAFIATwBKAEUAQwBUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAa AAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJQAAAHEL AAAAAAAAUABSAE8ASgBFAEMAVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABAAAgEHAAAADAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABTAAAAZwEAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAK AAAA/v///wwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgA AAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAD+////JgAA ACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAA NQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABD AAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEA AABSAAAA/v///1QAAABVAAAAVgAAAFcAAABYAAAA/v////7////+////XAAAAP7///////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////wGysoABAAQAAAABADAqAgKQCQBwFAZIAwCCAgBk5AQEAAcAHABQ cm9qZWN0BVEAKAAAQAIUBgIUPa0CCgcCbAEUCAYSCQISgEwtVTwCAAwCShI8AgoWAAFyc3RkEG9s ZT4CGXMAdAAAZABvAGwAZVAADQBoACVeAAMqAFxHezAwMDIwsDQzMC0ACAQEQwAKAwIOARIwMDQ2 fSMAMi4wIzAjQzoAXFdJTkRPV1MAXFN5c3RlbTMAMlxTdGRPbGUAMi5UbGIjT0wARSBBdXRvbWGw dGlvbgBgAAIWAm4ATVNGb3Jtcz4EAA4ACU0AUwBGAQBGcgBtAHMALzQAfIAJcoABAUc4OQBCNDA1 MzEtNgAzNUQtMTFEMiAtQjg0QwBHQTAAQzlBMEUwMEMDGUcENC5UV0QjTQBpY3Jvc29mdIogAj4g AGIgT2IBsgAgTGlicmFyeeMAOgABMACMgAKBVwKIADkzN0JEMzUtKDEzRIJANoBAOTIBlUBURU1Q XFdvQHJkOC4wXIU+RQJYpz7hLkUNj+AAGhCFLgJgjE1EC7TBhBYAD0AkVIBlbXBsYXRlRIYYPgAe AQVAcG0AcAVAcmHAdGUAUAByFYBSakAFY8ADDgAghcAICcAAKlxDToBcBGFsCgPDp5o4AYIAw4dP ZmZpY8SHiE8AZkAAaQBjwBEoDQCQwA+GwhBHe0AyREY4RDBAYDUAQkZBLTEwMUKgLUJERTWBQ0HA hho0wAIyCGTAKmdyYQBtIEZpbGVzXAtHYAMbXIQBTVNPOWA3LkRMTMhogwYgi4BREmkPAssBABPC AQiIKBnCtVRoaXMARG9jdW1lbnSiGk4EMgAYQDFUwLuKaQCaRMBJYwB1AJ0oZQBuwEocwAYAAKpI QgExQtLjAN8eQgJFAQUsQhqKKCJCCCsFQgEQQgEAAAAAAAAAAAAAARYBAAC2AP//AQEAAAAA//// /wAAAAD///////8AADq9NwndE9YRuJIAoMmg4AwpvTcJ3RPWEbiSAKDJoOAMAAAAAAAAAAAAAAAA AAAAAAAAEAAAAAMAAAAFAAAABwAAAP//////////AQEIAAAA/////3gAAADeAAAAcwUAAAkCAAD/ ////AAAAAAEAAACIKIooAAD//6MAAACIAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA//8AAI8FAADWAAAA1gAAAOMFAAAAAP////8AAAAA3wD//wAAAAAMAP////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// UAAAAAIAUyL/////AAABAFMQ/////wAAAQBTIv////8AAAAAAjwQAP//AAAAAAI8FAD//wAAAAAC PBgA//8AAAAAAjwcAP//AAAAAAI8/////wAA//8BAQAAAAABADoAMQBUAGUAbQBwAGwAYQB0AGUA UAByAG8AagBlAGMAdAAuAFQAaABpAHMARABvAGMAdQBtAGUAbgB0AAAAAAAAAN8IAAAAMAAAAAEB 6AIAAAKB/v///////////ygAAAAAAP//AAAAAAAAAAD//////////wAAAAAdAAAAJAAAAGgBAACg AAAAKoAdAiAAAAA4AIQDMAAAAAMAAAA4AARAAAAAAP//////////AAAAAB0ADAAAAAAAKoAfAiAA AABAAJADYAAAAAMAAQBAAARAAQAAAP//////////uAkAAB0ADAAAAAAAKoAhAiAAAABIAJwDkAAA AAMAAgBIAARAAgAAAP//////////qAwAAGgBAAAQAAAA/////zgAAABoAAAAwAAAAAKD/v////// CAD//wABAAAAAP///////wAAAAD//////////yAAAAAdABAAJAAAAIKgEAL//////v///zABAAAC AP///v///wAAAAD//////////yAAAAAdABAAJAAAAAKD/v//////CAD//2ABAAAAAP///////wAA AAD//////////yAAAAAdABAAJAAAAP/////gAAAABgAAAP//////////gAAAAOACAADIAAAAKoAr AiAAAABcAMADgAEAAAMABwBcAARABwAAAP//////////AAABgB0ADAAAAAAAKoAtAiAAAABkAMwD sAEAAAMACABkAARACAAAAP//////////+AAAAB0ADAAAAAAAKoAvAiAAAABsANgD4AEAAAMACQBs AARACQAAAP//////////KAEAAOACAAA4AAAAuAEAAOgBAAD///////////////////////////// //84AAAAaAAAAJgAAADIAAAA+AAAACgBAAACg/7//////wgA//94AgAAAAD///////8AAAAA//// //////8EAAAAHQAQACQAAACCoBAC//////7///+oAgAAAgD///7///8AAAAA//////////8AAAAA HQAQACQAAAACg/7//////wgA///YAgAAAAD///////8AAAAA//////////8AAAAAHQAQACQAAAD/ ////GAEAAAAAAAAAAAEAAAAAAAAA////////////////AAAAAP////////////////////8AAAAA //////////8IAQAAOAEAAAAAAAAAAAAAWAAEAAAAAACoA4QD//////////////////////////// /wgABQD/////TUUAAP///////wAAAAD//wAAAAD//wEBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7KAQAAAP////8BAQgAAAD/ ////eAAAAAGNsABBdHRyaWJ1dABlIFZCX05hbQBlID0gIlRoaQBzRG9jdW1lbhB0Ig0KCoxCYXMB AowxVGVtcGxhAHRlUHJvamVjBHQuGWhDcmVhdAhhYmwBckZhbHMCZQyoUHJlZGVjJGxhAAZJZACB VHICdQ0iRXhwb3NlgxQcBYtEZXJpdhUkAEN1c3RvbWl6AwSHA2MAAAAAAAAAAAAAAADMYV4AAAEA /wkEAAAJBAAA5AQBAAAAAAAAAAAAAQAGAAIAFgEqAFwARwB7ADAAMAAwADIAMAA0AEUARgAtADAA MAAwADAALQAwADAAMAAwAC0AQwAwADAAMAAtADAAMAAwADAAMAAwADAAMAAwADAANAA2AH0AIwAz AC4AMAAjADkAIwBDADoAXABQAHIAbwBnAHIAYQBtACAARgBpAGwAZQBzAFwAQwBvAG0AbQBvAG4A IABGAGkAbABlAHMAXABNAGkAYwByAG8AcwBvAGYAdAAgAFMAaABhAHIAZQBkAFwAVgBCAEEAXABW AEIAQQAzADMAMgAuAGQAbABsACMAVgBpAHMAdQBhAGwAIABCAGEAcwBpAGMAIABGAG8AcgAgAEEA cABwAGwAaQBjAGEAdABpAG8AbgBzAAAAAAAAAAAAAAAAABABKgBcAEcAewAwADAAMAAyADAAOQAw ADUALQAwADAAMAAwAC0AMAAwADAAMAAtAEMAMAAwADAALQAwADAAMAAwADAAMAAwADAAMAAwADQA NgB9ACMAOAAuADAAIwA0ADAAOQAjAEMAOgBcAFAAcgBvAGcAcgBhAG0AIABGAGkAbABlAHMAXABN AGkAYwByAG8AcwBvAGYAdAAgAE8AZgBmAGkAYwBlAFwATwBmAGYAaQBjAGUAXABNAFMAVwBPAFIA RAA4AC4ATwBMAEIAIwBNAGkAYwByAG8AcwBvAGYAdAAgAFcAbwByAGQAIAA4AC4AMAAgAE8AYgBq AGUAYwB0ACAATABpAGIAcgBhAHIAeQAAAAAAAAAAAAAAAAC8ACoAXABHAHsAMAAwADAAMgAwADQA MwAwAC0AMAAwADAAMAAtADAAMAAwADAALQBDADAAMAAwAC0AMAAwADAAMAAwADAAMAAwADAAMAA0 ADYAfQAjADIALgAwACMAMAAjAEMAOgBcAFcASQBOAEQATwBXAFMAXABTAHkAcwB0AGUAbQAzADIA XABTAHQAZABPAGwAZQAyAC4AVABsAGIAIwBPAEwARQAgAEEAdQB0AG8AbQBhAHQAaQBvAG4AAAAA AAAAAAAAAAAA5AAqAFwARwB7ADgAOQBCADQAMAA1ADMAMQAtADYAMwA1AEQALQAxADEARAAyAC0A QgA4ADQAQwAtADAAMABBADAAQwA5AEEAMABFADAAMABDAH0AIwAyAC4AMAAjADAAIwBDADoAXABX AEkATgBEAE8AVwBTAFwAUwB5AHMAdABlAG0AMwAyAFwATQBTAEYAbwByAG0AcwAuAFQAVwBEACMA TQBpAGMAcgBvAHMAbwBmAHQAIABGAG8AcgBtAHMAIAAyAC4AMAAgAE8AYgBqAGUAYwB0ACAATABp AGIAcgBhAHIAeQAAAAAAAAAAAAAAAQDcACoAXABHAHsAMAA5ADMANwBCAEQAMwA1AC0AMQAzAEQA RAAtADEAMQBEADYALQBCADgAOQAyAC0AMAAwAEEAMABDADkAQQAwAEUAMAAwAEMAfQAjADIALgAw ACMAMAAjAEMAOgBcAFQARQBNAFAAXABXAG8AcgBkADgALgAwAFwATQBTAEYAbwByAG0AcwAuAEUA WABEACMATQBpAGMAcgBvAHMAbwBmAHQAIABGAG8AcgBtAHMAIAAyAC4AMAAgAE8AYgBqAGUAYwB0 ACAATABpAGIAcgBhAHIAeQAAAAAAAAAAAAAAAgAAAOEuRQ2P4BoQhS4CYIxNC7QAABIAKgBcAEMA TgBvAHIAbQBhAGwAEgAqAFwAQwBOAG8AcgBtAGEAbADDp5o4AQAAAAAAAAAMASoAXABHAHsAMgBE AEYAOABEADAANABDAC0ANQBCAEYAQQAtADEAMAAxAEIALQBCAEQARQA1AC0AMAAwAEEAQQAwADAA NAA0AEQARQA1ADIAfQAjADIALgAwACMAMAAjAEMAOgBcAFAAcgBvAGcAcgBhAG0AIABGAGkAbABl AHMAXABNAGkAYwByAG8AcwBvAGYAdAAgAE8AZgBmAGkAYwBlAFwATwBmAGYAaQBjAGUAXABNAFMA TwA5ADcALgBEAEwATAAjAE0AaQBjAHIAbwBzAG8AZgB0ACAATwBmAGYAaQBjAGUAIAA4AC4AMAAg AE8AYgBqAGUAYwB0ACAATABpAGIAcgBhAHIAeQAAAAAAAAAAAAAAAAABAAIAAwAEAgAABgIBAAgC AAAYAv///////wAAAAD//wAATC1VPAIA//////////////////////////////////////////// //////////////8AAP///////////////////////wEAAAAAAAAAAAAAAAAAAAAAAAAAiCgBABgA VABoAGkAcwBEAG8AYwB1AG0AZQBuAHQACgAxNzNjNTUzZGQyAwAqRAERAv//iigAAAAAAAAAAgAA AOMFAAD///////8BASACAAD//////////////////////////wACAAD///////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////yi9NwndE9YRuJIAoMmg4Az/////AQAAAP////9gAAAAgAAAAAAAFwEY AP8AhCcAAAQEV29yZLVrEAADBFZCQffiEAAFBFdpbjE2wX4QAAUEV2luMzIHfxAAAwRNYWOzshAA KwRJbnZpdGF0aW9ubGV0dGVyX0NoaW5lc2VfZmluYWxfd2l0aCBoZWFkZXIyQ+IQAAYEc3Rkb2xl k2AQAAcATVNGb3Jtc0MPEAAMBFRoaXNEb2N1bWVudDyeEAAJgAAA/wMEAF9FdmFsdWF0ZRjZEAAP AFRlbXBsYXRlUHJvamVjdIFFEAAGhAgA/wMEAE9mZmljZRV1EAAHBFByb2plY3QtrhAACIQIAP8D AQBEb2N1bWVudGrTEAAJBEhUTUxUZXh0McpbEAAJBEhUTUxUZXh0MstbEAAJBEhUTUxUZXh0M8xb EAAJBEhUTUxUZXh0NM1bEAAJBEhUTUxUZXh0Nc5bEAAJBEhUTUxUZXh0Ns9bEAAJBEhUTUxUZXh0 N9BbEAAJBEhUTUxUZXh0ONFbEAAJBEhUTUxUZXh0OdJbEAAKBEhUTUxUZXh0MTAvQRAAAv//AQFg AAAAAAIBAP//AgIAAP//////////////////////////////////DAICAP//DgIDAP//EQIAAAgA ////////FAIEAP//FgIFAP//GAL/////////////////////////////CAAQAAAAAQASAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASUQ9InswOTM3QkQzQy0xM0RELTExRDYtQjg5 Mi0wMEEwQzlBMEUwMEN9Ig0KRG9jdW1lbnQ9VGhpc0RvY3VtZW50LyZIMDAwMDAwMDANCk5hbWU9 IlByb2plY3QiDQpIZWxwQ29udGV4dElEPSIwIg0KQ01HPSJGQ0ZFMzIzMEQyMjhENjI4RDYyOEQ2 MjhENiINCkRQQj0iRjhGQTM2QzkzN0M5MzdDOSINCkdDPSJGNEY2M0EzOENBMzVDQjM1Q0JDQSIN Cg0KW0hvc3QgRXh0ZW5kZXIgSW5mb10NCiZIMDAwMDAwMDE9ezM4MzJENjQwLUNGOTAtMTFDRi04 RTQzLTAwQTBDOTExMDA1QX07VkJFOyZIMDAwMDAwMDANCiZIMDAwMDAwMDI9ezAwMDIwOUYyLTAw MDAtMDAwMC1DMDAwLTAwMDAwMDAwMDA0Nn07V29yZDguMDsmSDAwMDAwMDAwDQoAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQABAAAAGtESVcZczxGNZwCqAL3OHQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAFRoaXNEb2N1bWVudABUAGgAaQBzAEQAbwBjAHUAbQBlAG4A dAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABG GAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1l bnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAFAAUgBPAEoARQBDAFQAbABrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAUAAIB/////w0AAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAWQAAAB4AAAAAAAAAUABSAE8ASgBFAEMAVAB3AG0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAgD///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABaAAAAKQAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAf////8PAAAA//// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFsAAABqAAAAAAAAAE8AYgBqAGUA YwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAW AAEA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAADw8Uz3kr/BAfDxTPeSv8EBAAAAAAAA AAAAAAAA ------=_NextPart_000_0028_01C1C236.D6894F30-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 7: 0:57 2002 Delivered-To: freebsd-current@freebsd.org Received: from mharnois.mdharnois.net (customer-mpls-23.cpinternet.com [209.240.253.23]) by hub.freebsd.org (Postfix) with ESMTP id 64DB337B400 for ; Tue, 5 Mar 2002 07:00:51 -0800 (PST) Received: by mharnois.mdharnois.net (Postfix, from userid 1000) id 989EB3C99; Tue, 5 Mar 2002 09:00:47 -0600 (CST) To: freebsd-current@freebsd.org Subject: bktr now fails From: "Michael D. Harnois" Date: 05 Mar 2002 09:00:45 -0600 Message-ID: <87664bawkh.fsf@mharnois.mdharnois.net> Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (bamboo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I used to be able to use my Brooktree card with no problem. However, a month or so ago, I started getting this at boot: bktr0: mem 0xf5000000-0xf5000fff irq 9 at device 12.0 on pci2 bktr0: could not map memory device_probe_and_attach: bktr0 attach returned 6 pci2: at device 12.1 (no driver attached) Any ideas? -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran Church Washburn, Iowa 1L, UST School of Law Minneapolis, Minnesota "Times are bad. Children no longer obey their parents, and everyone is writing a book." -- Marcus Tullius Cicero To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 7:53: 5 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 7659337B421 for ; Tue, 5 Mar 2002 07:52:16 -0800 (PST) Received: (qmail 15890 invoked from network); 5 Mar 2002 15:52:10 -0000 Received: from unknown (HELO server.baldwin.cx) ([65.91.137.49]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 Mar 2002 15:52:10 -0000 Received: from laptop.baldwin.cx (john@laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g25Fq3G57130; Tue, 5 Mar 2002 10:52:03 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3C827021.A7FA73A4@verizon.net> Date: Tue, 05 Mar 2002 10:51:51 -0500 (EST) From: John Baldwin To: Maksim Yevmenkin Subject: RE: Netgraph, device drivers and mutexes Cc: freebsd-current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 03-Mar-02 Maksim Yevmenkin wrote: > the same locking questions goes for the other Netgraph > nodes that connected to the driver node. i want very > simple locks to do the following: > > 1) handle timeouts with timeout(9)/untimeout(9) - > my _biggest_ concern. all i could find in -current is > everyone use splXXX/splx :( is it broken on SMP? > > 2) modify node's internal data structure in a safe way. > i'm talking about things like linked lists, queues > etc. > > since splXXX(9) functions are no longer relevant in > -current (please correct me if i wrong), i was looking > at mutex(9). i have noticed several device drivers that > also use Netgraph (if_ar, if_sr, if_lmc and udbp), and > they use MTX_DEF mutexes and splXXX(9) functions. is that > OK with Netgraph? the man page says that MTX_DEF mutexes > _will_ context switch when they are already held. For now, I would not use any mutexes in your device driver code. The network stack hasn't been locked so we still don't know what actual locks will be needed in the device drivers themselves. Netgraph has some custom reader/writer locks that you may need to interface with. Julian should be able to help you with that. > can/should i use MTX_SPIN mutexes? i have tried to use > them, but WITNESS code gets very upset (panic) unless i > modify "order_lists" in kern/subr_wintess.c. i would > rather not do it, since i'm not fully aware of what's > going on. For now, avoid MTX_SPIN mutexes unless you have a fast interrupt handler (INTR_FAST) (which you probably don't). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 7:53: 5 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 44F3E37B417 for ; Tue, 5 Mar 2002 07:52:16 -0800 (PST) Received: (qmail 15852 invoked from network); 5 Mar 2002 15:52:07 -0000 Received: from unknown (HELO server.baldwin.cx) ([65.91.137.49]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 Mar 2002 15:52:07 -0000 Received: from laptop.baldwin.cx (john@laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g25Fq4G57134; Tue, 5 Mar 2002 10:52:04 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 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: Tue, 05 Mar 2002 10:51:51 -0500 (EST) From: John Baldwin To: ouyang kai Subject: RE: simplelock to lock_class? Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 04-Mar-02 ouyang kai wrote: > Hi, eveyone, > I found the FreeBSD4.x defined the simplelock in the sys/sys/lock.h. > But, it doesn't exist in FreeBSD5.0, why? If I want use the FreeBSD4.x > simplelock function, > how and what can I use in FreeBSD5.0? 5.0 has different locking primitives than 4.x. What are you using a simplelock for on 4.x? That will help decide which locking primitive you would need to use in 5.0 to obtain similar semantics/behavior. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 7:55:42 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 296F637B43F for ; Tue, 5 Mar 2002 07:52:38 -0800 (PST) Received: (qmail 16140 invoked from network); 5 Mar 2002 15:52:31 -0000 Received: from unknown (HELO server.baldwin.cx) ([65.91.137.49]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 Mar 2002 15:52:31 -0000 Received: from laptop.baldwin.cx (john@laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g25Fq2G57114; Tue, 5 Mar 2002 10:52:02 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200203010309.g2139DI40526@apollo.backplane.com> Date: Tue, 05 Mar 2002 10:51:50 -0500 (EST) From: John Baldwin To: Matthew Dillon Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Cc: Julian Elischer Cc: Julian Elischer , FreeBSD current users , Seigo Tanimura , Bosko Milekic , Alfred Perlstein , Terry Lambert , Bruce Evans Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 01-Mar-02 Matthew Dillon wrote: > >: >: >:On 28-Feb-02 Matthew Dillon wrote: >:> Not to put too fine a point on it, but, I don't see how this can >:> possibly justify preventing me from committing my critical_*() stuff. >:> You've just stated publically that your preemption stuff is unusable >:> as it currently stands. Why am I supposed to wait an arbitrary period >:> of time for you to fix, test, and commit it? >:> >:> I would REALLY like to commit my critical_*() stuff, and for the record >:> this will also include the stage-2 stuff described in the original >:> commit >:> comments that will be made a few days after the current commit. >: >:Because the critical_* changes you are doing don't match up to the overall >:design. See my mail to -arch for more on that though. At some point in the >:future I think that this work can fit in rather well to the cpu_critical_foo >:stuff (which can be split out from critical_enter/exit now). However, at >:this >:stage I would rather avoid complex optimizations of APIs that may change in >:the >:future. There is more to be gained from locking subsystems. >:... >:John Baldwin <>< http://www.FreeBSD.org/~jhb/ >:"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > I strongly disagree. I have yet to see any technical description of > this so-called overall design that shows any incompatibility, and what > I decide to do with my time is my business. I don't really care > whether you are ready for 'optimizations' or not. I seem to recall > that you had similar objections when I started pushing Giant into the > system calls, yet that work is in hind sight an obvious enabler for > other work people have been doing and committing. No, I actually requested that Giant be pushed down into the syscalls and Maxime Henrion is working on finishing that work right now. > I decided to address a serious issue that I've had with those routines > for months because you consistently refused to even entertain the > notion that you may have constructed the API wrong. Frankly, I feel > that these changes both optimize and properly abstract the critical_*() > code. I strongly believe that the abstraction you have in there now is > improper. My patches have been tested, they work, and they ARE going to > be committed as soon as I am able to do so. I believe you are > overstepping your bounds as a committer by attempting to scrap them > and I also believe that you do not fully understand the implications > of the code, because you are blinded by the notion that I am making > adjustments to your API. But I do, BDE does, Julian does, as do others. > > To me these changes are essential, and they must go in now before > even more hacks are committed to the codebase to get around existing > limitations. There are already hacks in the trampoline/fork_exit > and ast code that seriously pollutes the MD/MI boundry, all of which > you've flicked off your shoulder and explained away as being allowed > by your API, and Peter added a third hack with his pmap commit (which > got backed-out when he backed out the commit). These hacks make it > crystal clear to me that you critical_*()/cpu_critical*() API is > seriously flawed. I am addressing the issue and cleaning up the hacks > to create a proper MD/MI separation of the code. Actually, I responded saying that I was willing to talk about how to properly abstract CRITICAL_FORK (which is gross I admit). If you will read the design doc, you will see that actually critical_foo and cpu_critical_foo can now be safely split up and made independent of each other. To this extent td_critnest would still stay MI, but td_savecrit could end up going away if the MD code fully handles the saving/restoring the state for whatever cpu_critical_* become. > It makes no sense whatsoever to me to be told not to commit something > due to stale code that may not be quite compatible sitting in P4 that > you can't make work in any reasonable time frame. You should stop > trying to screw over my work and instead look to your own. You have > so many balls in the air constructed in a fine mesh that you can't seem > to accept a single change to your perfectly meshing subsystems, half > of which are going stale in P4. This is greatly restricting your > ability to consider deviation. *sigh* The only reason I'm not spending my cycles tracking down the preemption bugs so that preemption can go in is that I have decided that at the moment there is more gain to be found by doing actual locking work. This means that preemption will eventually go in, just Not Right Now. To that extent, I don't think premature optimizations based on observations of a kernel locked entirely by Giant that alter the API's preemption will change (and that were originally introduced when I committed all the bits of the preemption code that I could w/o breaking the kernel) should go in. > I will repeat, if you want to discuss specific technical issues related > to these commits after I put them in, I am all ears. I will repeat, I > see nothing in this code that prevents you from accomplishing anything > that you've brought up to date (which so far as just been the non-working > preemption code you have sitting in P4). > > -Matt > Matthew Dillon > -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 7:55:58 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id D64B037B435 for ; Tue, 5 Mar 2002 07:52:29 -0800 (PST) Received: (qmail 25757 invoked from network); 5 Mar 2002 15:52:22 -0000 Received: from unknown (HELO server.baldwin.cx) ([65.91.137.49]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 Mar 2002 15:52:22 -0000 Received: from laptop.baldwin.cx (john@laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g25Fq5G57150; Tue, 5 Mar 2002 10:52:05 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020304191303.A2288@freebie.xs4all.nl> Date: Tue, 05 Mar 2002 10:51:53 -0500 (EST) From: John Baldwin To: Wilko Bulte Subject: RE: blockable sleep panic on Alpha / current Cc: murray@freebsd.org, freebsd-alpha@freebsd.org, freebsd-current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 04-Mar-02 Wilko Bulte wrote: > During a make release I just got a panic. The build progressed until: > > gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxabs.3 > imaxabs.3.gz > gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxdiv.3 > imaxdiv.3.gz > gzip -cn /usr/src/lib/libc/../libc/stdlib/labs.3 > labs.3.gz > > The running system is a -current as of today. > > The panic: > > login: > FreeBSD/alpha (ds10.wbnet) (ttyd0) > > login: panic: blockable sleep lock (sleep mutex) Giant @ > ../../../alpha/alpha/tr > ap.c:482 > cpuid = 0; panic > Stopped at Debugger+0x34: zapnot v0,#0xf,a0 > db> > db> trace > Debugger() at Debugger+0x34 > panic() at panic+0x188 > witness_lock() at witness_lock+0xb4 > _mtx_lock_flags() at _mtx_lock_flags+0xd8 > trap() at trap+0x4c8 > XentMM() at XentMM+0x2c > --- memory management fault (from ipl 7) --- > statclock_process() at statclock_process+0x1d4 We did something stupid like dereference a NULL pointer here. Can you pull up gdb on kernel.debug and do 'l *statclock_process+0x1d4'? > XentMM() at XentMM+0x2c > --- memory management fault --- > ithread_schedule() at ithread_schedule+0xa4 Eww, we have another one here. > alpha_dispatch_intr() at alpha_dispatch_intr+0x130 > interrupt() at interrupt+0x138 > XentInt() at XentInt+0x28 > --- interrupt (from ipl 0) --- > critical_exit() at critical_exit+0x1c > _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0xd4 > vm_fault1() at vm_fault1+0x110c > vm_fault() at vm_fault+0x64 > trap() at trap+0x6d8 > XentMM() at XentMM+0x2c > --- memory management fault --- > pmap_enter_quick() at pmap_enter_quick+0x1d4 Ugh, this is probably the real bug. :( Can you do a list on this address? > pmap_object_init_pt() at pmap_object_init_pt+0x1a4 > vm_map_insert() at vm_map_insert+0x35c > elf_load_section() at elf_load_section+0x190 > exec_elf_imgact() at exec_elf_imgact+0x278 > execve() at execve+0x324 > syscall() at syscall+0x338 > XentSys() at XentSys+0x64 > --- syscall (59, FreeBSD ELF, execve) --- > --- user mode --- > db> > > > -- >| / o / /_ _ wilko@FreeBSD.org >|/|/ / / /( (_) Bulte Arnhem, the Netherlands > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 8:57:25 2002 Delivered-To: freebsd-current@freebsd.org Received: from ns1.dotdebug.com (ns1.dotdebug.COM [63.196.101.33]) by hub.freebsd.org (Postfix) with SMTP id 0D3E437B436 for ; Tue, 5 Mar 2002 08:57:05 -0800 (PST) Received: (qmail 2165 invoked by uid 1001); 5 Mar 2002 16:57:08 -0000 Date: Tue, 5 Mar 2002 08:57:07 -0800 From: Adam Webb To: freebsd-current@freebsd.org Subject: aliases Message-ID: <20020305085637.A2148@ns1.dotdebug.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Operating-System: Dumb Header OS v6.9 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Is there a known bug or particular reason I can't add network aliases in -current? -- Adam Webb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 8:57:38 2002 Delivered-To: freebsd-current@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id B273137B43A; Tue, 5 Mar 2002 08:57:03 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id g25Gv1107090; Tue, 5 Mar 2002 17:57:01 +0100 (CET) (envelope-from wkb) Date: Tue, 5 Mar 2002 17:57:01 +0100 From: Wilko Bulte To: John Baldwin Cc: murray@FreeBSD.org, freebsd-alpha@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: blockable sleep panic on Alpha / current Message-ID: <20020305175701.A7059@freebie.xs4all.nl> References: <20020304191303.A2288@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Tue, Mar 05, 2002 at 10:51:53AM -0500 X-OS: FreeBSD 4.5-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Mar 05, 2002 at 10:51:53AM -0500, John Baldwin wrote: > > On 04-Mar-02 Wilko Bulte wrote: > > During a make release I just got a panic. The build progressed until: > > > > gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxabs.3 > imaxabs.3.gz > > gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxdiv.3 > imaxdiv.3.gz > > gzip -cn /usr/src/lib/libc/../libc/stdlib/labs.3 > labs.3.gz > > > > The running system is a -current as of today. > > > > The panic: > > > > login: > > FreeBSD/alpha (ds10.wbnet) (ttyd0) > > > > login: panic: blockable sleep lock (sleep mutex) Giant @ > > ../../../alpha/alpha/tr > > ap.c:482 > > cpuid = 0; panic > > Stopped at Debugger+0x34: zapnot v0,#0xf,a0 > > db> > > db> trace > > Debugger() at Debugger+0x34 > > panic() at panic+0x188 > > witness_lock() at witness_lock+0xb4 > > _mtx_lock_flags() at _mtx_lock_flags+0xd8 > > trap() at trap+0x4c8 > > XentMM() at XentMM+0x2c > > --- memory management fault (from ipl 7) --- > > statclock_process() at statclock_process+0x1d4 > > We did something stupid like dereference a NULL pointer here. Can you pull up > gdb on kernel.debug and do 'l *statclock_process+0x1d4'? Is gdb broken on Alpha, or is it just me? ds10#gdb ^C ds10#gdb -k ^C ds10# In short, gdb just sits there (??). On x86/stable I get: wb ~: gdb GNU gdb 4.18 Copyright 1998 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". (gdb) wb ~: wb ~: etc I'll to reproduce the problem again. -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 9: 2: 3 2002 Delivered-To: freebsd-current@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 694D637B402 for ; Tue, 5 Mar 2002 09:01:58 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g25H1iD61847; Tue, 5 Mar 2002 12:01:48 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 5 Mar 2002 12:01:43 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Adam Webb Cc: freebsd-current@freebsd.org Subject: Re: aliases In-Reply-To: <20020305085637.A2148@ns1.dotdebug.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 5 Mar 2002, Adam Webb wrote: > Is there a known bug or particular reason I can't add network aliases in > -current? > -- > Adam Webb None that I know of, although there does seem to be at least one bug relating to removable interfaces and dhclient. It might be useful to include some sample output relating to adding aliases to demonstrate how it's not working for you. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 9: 3:39 2002 Delivered-To: freebsd-current@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id DA3AB37B405; Tue, 5 Mar 2002 09:03:27 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id MAA21426; Tue, 5 Mar 2002 12:03:27 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g25H2vg26297; Tue, 5 Mar 2002 12:02:57 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15492.64065.158524.377561@grasshopper.cs.duke.edu> Date: Tue, 5 Mar 2002 12:02:57 -0500 (EST) To: Wilko Bulte Cc: John Baldwin , murray@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: blockable sleep panic on Alpha / current In-Reply-To: <20020305175701.A7059@freebie.xs4all.nl> References: <20020304191303.A2288@freebie.xs4all.nl> <20020305175701.A7059@freebie.xs4all.nl> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Wilko Bulte writes: > Is gdb broken on Alpha, or is it just me? > > ds10#gdb > ^C > ds10#gdb -k > > ^C > ds10# > > In short, gdb just sits there (??). Yes, David's new binutils import broke it. I have a workaround, but it causes buildworld breakage. Sigh. You can just use a /usr/libexec/elf/gdb from -stable. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 9:16: 1 2002 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id A3F4E37B400; Tue, 5 Mar 2002 09:15:55 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g25HFsk60359; Tue, 5 Mar 2002 09:15:54 -0800 (PST) (envelope-from dillon) Date: Tue, 5 Mar 2002 09:15:54 -0800 (PST) From: Matthew Dillon Message-Id: <200203051715.g25HFsk60359@apollo.backplane.com> To: John Baldwin Cc: Julian Elischer , FreeBSD current users , Seigo Tanimura , Bosko Milekic , Alfred Perlstein , Terry Lambert , Bruce Evans Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> It makes no sense whatsoever to me to be told not to commit something :> due to stale code that may not be quite compatible sitting in P4 that :> you can't make work in any reasonable time frame. You should stop :> trying to screw over my work and instead look to your own. You have :> so many balls in the air constructed in a fine mesh that you can't seem :> to accept a single change to your perfectly meshing subsystems, half :> of which are going stale in P4. This is greatly restricting your :> ability to consider deviation. : :*sigh* The only reason I'm not spending my cycles tracking down the preemption :bugs so that preemption can go in is that I have decided that at the moment :there is more gain to be found by doing actual locking work. This means that :preemption will eventually go in, just Not Right Now. To that extent, I don't :think premature optimizations based on observations of a kernel locked entirely :by Giant that alter the API's preemption will change (and that were originally :introduced when I committed all the bits of the preemption code that I could :w/o breaking the kernel) should go in. Those are your cycles, not mine. Why should I be forced to sit on my heals for an unknown period of time (but so far 3 weeks waiting for the ucred changes and 2 weeks waiting for critical_*()), twiddling my thumbs wasting MY cycles just because of your own scheduling issues? That's really the crux of this whole situation. I don't think it is appropriate for you to impose your development methodology on me or anyone else, and I most especially do not think it is appropriate for you to arbitrarily hold off the hard work that I have done in order to fit it into your schedule. I have said very clearly what I intend these critical_*() patches to do. I have said, repeatedly, that I do not believe they would intefere with your work in any significant manner. You have yet to explain in any detail why you think they would. I have said, repeatedly, that I am perfectly willing to work with you later on when you ARE ready to move forward on your own work. That's the crux of the situation, John. I do not believe you have the right to hold this work off, at least not based on any of the explanations you have given so far. -Matt Matthew Dillon :-- : :John Baldwin <>< http://www.FreeBSD.org/~jhb/ :"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-current" in the body of the message : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 9:29:42 2002 Delivered-To: freebsd-current@freebsd.org Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by hub.freebsd.org (Postfix) with SMTP id EF9E837B402 for ; Tue, 5 Mar 2002 09:29:38 -0800 (PST) Received: from gbalis (AUTH poptime) at host217-39-11-157.in-addr.btopenworld.com (HELO stormbringer) (217.39.11.157) by smtp.mail.vip.sc5.yahoo.com with SMTP; 5 Mar 2002 17:15:24 -0000 From: "George V. Balis" To: Subject: Damn slow startup Date: Tue, 5 Mar 2002 17:15:16 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-reply-to: <20020305175701.A7059@freebie.xs4all.nl> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Disposition-Notification-To: "George V. Balis" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi everybody I recently updated through cvsup a 4.5 stable FreeBSD running on Vmware. I followed the instructions from the handbook building both the world and the GENERIC kernel. When I finally rebooted, It takes almost 2-3 hours to boot being extremely slow. I never really let it finish booting and started doing it all over again. Does this have smth to do with the WITNESS kernel option? If no do you have any idea as to what might be wrong. George _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 9:30:54 2002 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 02DFE37B400; Tue, 5 Mar 2002 09:30:50 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g25HU8Lv029310; Tue, 5 Mar 2002 18:30:09 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: John Baldwin , Julian Elischer , FreeBSD current users , Seigo Tanimura , Bosko Milekic , Alfred Perlstein , Terry Lambert , Bruce Evans Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem In-Reply-To: Your message of "Tue, 05 Mar 2002 09:15:54 PST." <200203051715.g25HFsk60359@apollo.backplane.com> Date: Tue, 05 Mar 2002 18:30:08 +0100 Message-ID: <29309.1015349408@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200203051715.g25HFsk60359@apollo.backplane.com>, Matthew Dillon wri tes: > That's the crux of the situation, John. I do not believe you have > the right to hold this work off, at least not based on any of the > explanations you have given so far. Why don't you for a change, just stop being so ego-centered and instead head to the page at http://www.freebsd.org/smp/ and find yourself a task which is free for grabs, rather than insist that you have a right to bully the only person who have consistently chugged away at the SMPng project when practically everybody else (you included) defected. One could point at such a gem as: "add locking to NFS" which I am sure John and the rest of us would love to see you tackle... Give us peace Matt... -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 9:43:40 2002 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 15E0B37B417; Tue, 5 Mar 2002 09:43:35 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g25HhTa69019; Tue, 5 Mar 2002 09:43:29 -0800 (PST) (envelope-from dillon) Date: Tue, 5 Mar 2002 09:43:29 -0800 (PST) From: Matthew Dillon Message-Id: <200203051743.g25HhTa69019@apollo.backplane.com> To: Poul-Henning Kamp Cc: John Baldwin , Julian Elischer , FreeBSD current users , Seigo Tanimura , Bosko Milekic , Alfred Perlstein , Terry Lambert , Bruce Evans Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem References: <29309.1015349408@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :In message <200203051715.g25HFsk60359@apollo.backplane.com>, Matthew Dillon wri :tes: : :> That's the crux of the situation, John. I do not believe you have :> the right to hold this work off, at least not based on any of the :> explanations you have given so far. : :Why don't you for a change, just stop being so ego-centered and :instead head to the page at http://www.freebsd.org/smp/ and find :.. Stay out of it, Poul, you have no pull with me and you know it. What I choose to do with my time is my business, not yours. :you have a right to bully the only person who have consistently :chugged away at the SMPng project when practically everybody else :(you included) defected. This is an extreme misrepresentation of the facts. I stated very clearly at the original Yahoo SMP summit that I would soon not be available. I did what work I could before I became unavailable, and then I was, SURPRISE! Unavailable for 2 years! I did not abandon anyone. I wrote that code that is the basis for allowing us to remove Giant from syscalls, I wrote the original idle process code including all the hard assembly stuff. I cleaned up the pre-SMPng SPL masks (cpl and cml). I did what I could in the time I had. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 9:43:57 2002 Delivered-To: freebsd-current@freebsd.org Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by hub.freebsd.org (Postfix) with ESMTP id C512637B435; Tue, 5 Mar 2002 09:43:41 -0800 (PST) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.2/8.12.1) with ESMTP id g25Hh8AX034826; Tue, 5 Mar 2002 12:43:08 -0500 (EST) Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.2/8.12.1/Submit) id g25Hh8AQ034825; Tue, 5 Mar 2002 12:43:08 -0500 (EST) (envelope-from bmilekic) Date: Tue, 5 Mar 2002 12:43:08 -0500 From: Bosko Milekic To: Poul-Henning Kamp Cc: Matthew Dillon , John Baldwin , Julian Elischer , FreeBSD current users , Seigo Tanimura , Alfred Perlstein , Terry Lambert , Bruce Evans Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Message-ID: <20020305124308.A34718@unixdaemons.com> References: <200203051715.g25HFsk60359@apollo.backplane.com> <29309.1015349408@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <29309.1015349408@critter.freebsd.dk>; from phk@critter.freebsd.dk on Tue, Mar 05, 2002 at 06:30:08PM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Mar 05, 2002 at 06:30:08PM +0100, Poul-Henning Kamp wrote: > In message <200203051715.g25HFsk60359@apollo.backplane.com>, Matthew Dillon wri > tes: > > > That's the crux of the situation, John. I do not believe you have > > the right to hold this work off, at least not based on any of the > > explanations you have given so far. > > Why don't you for a change, just stop being so ego-centered and > instead head to the page at http://www.freebsd.org/smp/ and find > yourself a task which is free for grabs, rather than insist that > you have a right to bully the only person who have consistently > chugged away at the SMPng project when practically everybody else > (you included) defected. > > One could point at such a gem as: "add locking to NFS" which I am > sure John and the rest of us would love to see you tackle... Hey, that's not fair. Instead of occasionally throwing in the "do what John tells you" argument, why don't you either present a real technical argument as to why Matt's stuff is bad (I'm not saying there isn't one) or, for that matter, "add locking to NFS" yourself? > Give us peace Matt... > > -- > 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. -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 9:57: 6 2002 Delivered-To: freebsd-current@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 991ED37B416 for ; Tue, 5 Mar 2002 09:56:57 -0800 (PST) Received: from pool0452.cvx40-bradley.dialup.earthlink.net ([216.244.43.197] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16iJBG-0002fh-00; Tue, 05 Mar 2002 09:56:55 -0800 Message-ID: <3C8506D8.BBB9CE3F@mindspring.com> Date: Tue, 05 Mar 2002 09:56:40 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "George V. Balis" Cc: freebsd-current@freebsd.org Subject: Re: Damn slow startup References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Run -stable. VMWare takes a very long time to emulate certain locking primitives, for some reason. -- Terry "George V. Balis" wrote: > > Hi everybody > > I recently updated through cvsup a 4.5 stable FreeBSD running on Vmware. > I followed the instructions from the handbook building both the world > and the GENERIC kernel. When I finally rebooted, It takes almost 2-3 > hours to boot being extremely slow. I never really let it finish booting > and started doing it all over again. Does this have smth to do with the > WITNESS kernel option? If no do you have any idea as to what might be > wrong. > > George > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 10:11: 1 2002 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id F415237B402 for ; Tue, 5 Mar 2002 10:10:55 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g25IAsi78305; Tue, 5 Mar 2002 11:10:55 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g25IArL77377; Tue, 5 Mar 2002 11:10:53 -0700 (MST) (envelope-from imp@village.org) Date: Tue, 05 Mar 2002 11:10:42 -0700 (MST) Message-Id: <20020305.111042.53236945.imp@village.org> To: mharnois@cpinternet.com Cc: freebsd-current@FreeBSD.ORG Subject: Re: bktr now fails From: "M. Warner Losh" In-Reply-To: <87664bawkh.fsf@mharnois.mdharnois.net> References: <87664bawkh.fsf@mharnois.mdharnois.net> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <87664bawkh.fsf@mharnois.mdharnois.net> "Michael D. Harnois" writes: : I used to be able to use my Brooktree card with no problem. However, a : month or so ago, I started getting this at boot: : : bktr0: mem 0xf5000000-0xf5000fff irq 9 at device 12.0 on pci2 : bktr0: could not map memory : device_probe_and_attach: bktr0 attach returned 6 : pci2: at device 12.1 (no driver attached) : : Any ideas? Humor me and compile PCI_ALLOW_UNSUPPORTED_IO_RANGE Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 10:20:47 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id F173A37B41F for ; Tue, 5 Mar 2002 10:20:24 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020305182024.NPHG2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 5 Mar 2002 18:20:24 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA31786; Tue, 5 Mar 2002 10:12:09 -0800 (PST) Date: Tue, 5 Mar 2002 10:12:08 -0800 (PST) From: Julian Elischer To: Terry Lambert Cc: "George V. Balis" , freebsd-current@freebsd.org Subject: Re: Damn slow startup In-Reply-To: <3C8506D8.BBB9CE3F@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG or tell teh config it is a 386 cpu as well as a '686 that will force it to emulate those very slowly done instructins so that they are actually done faster :-) On Tue, 5 Mar 2002, Terry Lambert wrote: > Run -stable. VMWare takes a very long time to emulate > certain locking primitives, for some reason. > > -- Terry > > "George V. Balis" wrote: > > > > Hi everybody > > > > I recently updated through cvsup a 4.5 stable FreeBSD running on Vmware. > > I followed the instructions from the handbook building both the world > > and the GENERIC kernel. When I finally rebooted, It takes almost 2-3 > > hours to boot being extremely slow. I never really let it finish booting > > and started doing it all over again. Does this have smth to do with the > > WITNESS kernel option? If no do you have any idea as to what might be > > wrong. > > > > George > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 10:21:25 2002 Delivered-To: freebsd-current@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id C482037B417; Tue, 5 Mar 2002 10:20:43 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id g25IKgn07447; Tue, 5 Mar 2002 19:20:42 +0100 (CET) (envelope-from wkb) Date: Tue, 5 Mar 2002 19:20:42 +0100 From: Wilko Bulte To: John Baldwin Cc: freebsd-alpha@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: blockable sleep panic on Alpha / current Message-ID: <20020305192042.A7375@freebie.xs4all.nl> References: <20020304191303.A2288@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Tue, Mar 05, 2002 at 10:51:53AM -0500 X-OS: FreeBSD 4.5-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Mar 05, 2002 at 10:51:53AM -0500, John Baldwin wrote: Hi John, > On 04-Mar-02 Wilko Bulte wrote: > > During a make release I just got a panic. The build progressed until: > > > > gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxabs.3 > imaxabs.3.gz > > gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxdiv.3 > imaxdiv.3.gz > > gzip -cn /usr/src/lib/libc/../libc/stdlib/labs.3 > labs.3.gz > > > > The running system is a -current as of today. > > > > The panic: > > > > login: > > FreeBSD/alpha (ds10.wbnet) (ttyd0) > > > > login: panic: blockable sleep lock (sleep mutex) Giant @ > > ../../../alpha/alpha/tr > > ap.c:482 > > cpuid = 0; panic > > Stopped at Debugger+0x34: zapnot v0,#0xf,a0 > > db> > > db> trace > > Debugger() at Debugger+0x34 > > panic() at panic+0x188 > > witness_lock() at witness_lock+0xb4 > > _mtx_lock_flags() at _mtx_lock_flags+0xd8 > > trap() at trap+0x4c8 > > XentMM() at XentMM+0x2c > > --- memory management fault (from ipl 7) --- > > statclock_process() at statclock_process+0x1d4 > > We did something stupid like dereference a NULL pointer here. Can you pull up > gdb on kernel.debug and do 'l *statclock_process+0x1d4'? Thanks to Drew for confirming that -current's gdb is hosed. Using the -stable gdb I get better results. Anyway: (kgdb) l *statclock_process+0x1d4 0xfffffc00003d1ed4 is in statclock_process (../../../kern/kern_clock.c:447). 442 443 /* Update resource usage integrals and maximums. */ 444 if ((pstats = p->p_stats) != NULL && 445 (ru = &pstats->p_ru) != NULL && 446 (vm = p->p_vmspace) != NULL) { 447 ru->ru_ixrss += pgtok(vm->vm_tsize); 448 ru->ru_idrss += pgtok(vm->vm_dsize); 449 ru->ru_isrss += pgtok(vm->vm_ssize); 450 rss = pgtok(vmspace_resident_count(vm)); 451 if (ru->ru_maxrss < rss) (kgdb) > > > XentMM() at XentMM+0x2c > > --- memory management fault --- > > ithread_schedule() at ithread_schedule+0xa4 > > Eww, we have another one here. (kgdb) l *ithread_schedule+0xa4 0xfffffc00003e2924 is in ithread_schedule (../../../kern/kern_intr.c:375). 370 random_harvest(&entropy, sizeof(entropy), 2, 0, 371 RANDOM_INTERRUPT); 372 } 373 374 td = ithread->it_td; 375 p = td->td_proc; 376 KASSERT(p != NULL, ("ithread %s has no process", ithread->it_name)); 377 CTR4(KTR_INTR, "%s: pid %d: (%s) need = %d", __func__, p->p_pid, p->p_comm, 378 ithread->it_need); 379 (kgdb) > > alpha_dispatch_intr() at alpha_dispatch_intr+0x130 > > interrupt() at interrupt+0x138 > > XentInt() at XentInt+0x28 > > --- interrupt (from ipl 0) --- > > critical_exit() at critical_exit+0x1c > > _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0xd4 > > vm_fault1() at vm_fault1+0x110c > > vm_fault() at vm_fault+0x64 > > trap() at trap+0x6d8 > > XentMM() at XentMM+0x2c > > --- memory management fault --- > > pmap_enter_quick() at pmap_enter_quick+0x1d4 > > Ugh, this is probably the real bug. :( Can you do a list on this address? (kgdb) l *pmap_enter_quick+0x1d4 0xfffffc000052c314 is in pmap_enter_quick (../../../alpha/alpha/pmap.c:2422). 2417 pmap_insert_entry(pmap, va, mpte, m); 2418 2419 /* 2420 * Increment counters 2421 */ 2422 pmap->pm_stats.resident_count++; 2423 2424 /* 2425 * Now validate mapping with RO protection 2426 */ (kgdb) I hope this makes sense. I still hope to catch a dump. Or alternatively I hope it get's caught by ddb. W/ -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 11:34:42 2002 Delivered-To: freebsd-current@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 6C4E137B41B; Tue, 5 Mar 2002 11:34:37 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g25JYTZ35946; Tue, 5 Mar 2002 11:34:29 -0800 (PST) (envelope-from obrien) Date: Tue, 5 Mar 2002 11:32:36 -0800 From: "David O'Brien" To: Wilko Bulte Cc: John Baldwin , murray@FreeBSD.org, freebsd-alpha@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: blockable sleep panic on Alpha / current Message-ID: <20020305113236.B35834@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <20020304191303.A2288@freebie.xs4all.nl> <20020305175701.A7059@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020305175701.A7059@freebie.xs4all.nl>; from wkb@freebie.xs4all.nl on Tue, Mar 05, 2002 at 05:57:01PM +0100 X-Operating-System: FreeBSD 5.0-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 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Mar 05, 2002 at 05:57:01PM +0100, Wilko Bulte wrote: > Is gdb broken on Alpha, or is it just me? > > ds10#gdb > ^C > ds10#gdb -k Can you give the gdb51 port a try? We really need to see how usable that is on Alpha. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 13: 0:32 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 56B5037B400; Tue, 5 Mar 2002 13:00:19 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020305210019.SKEE2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 5 Mar 2002 21:00:19 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA32405; Tue, 5 Mar 2002 12:46:39 -0800 (PST) Date: Tue, 5 Mar 2002 12:46:38 -0800 (PST) From: Julian Elischer To: Maksim Yevmenkin Cc: freebsd-current@FreeBSD.ORG, archie@FreeBSD.ORG Subject: Re: Netgraph, device drivers and mutexes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 4 Mar 2002, Julian Elischer wrote: > > > On Mon, 4 Mar 2002, Maksim Yevmenkin wrote: > > > Julian, > > > > thank you very much for a such detailed answer :) > > > > [...] > > I just checked in some generic timeout routines into ng_base.c in -current. have a look and see if they make sense to you.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 13: 7:39 2002 Delivered-To: freebsd-current@freebsd.org Received: from mharnois.mdharnois.net (customer-mpls-23.cpinternet.com [209.240.253.23]) by hub.freebsd.org (Postfix) with ESMTP id EC01F37B402 for ; Tue, 5 Mar 2002 13:07:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mharnois.mdharnois.net (Postfix) with ESMTP id 07EA53CB6; Tue, 5 Mar 2002 15:07:36 -0600 (CST) Subject: Re: bktr now fails From: "Michael D. Harnois" To: "M. Warner Losh" Cc: "freebsd-current@FreeBSD. " ORG In-Reply-To: <20020305.111042.53236945.imp@village.org> References: <87664bawkh.fsf@mharnois.mdharnois.net> <20020305.111042.53236945.imp@village.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 05 Mar 2002 15:07:35 -0600 Message-Id: <1015362456.1876.8.camel@mharnois.mdharnois.net> Mime-Version: 1.0 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 2002-03-05 at 12:10, M. Warner Losh wrote: > Humor me and compile PCI_ALLOW_UNSUPPORTED_IO_RANGE You da man. Thanks! -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran Church Washburn, Iowa 1L, UST School of Law Minneapolis, Minnesota If you want to follow Jesus, you better look good on wood. --Daniel Berrigan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 13:17:49 2002 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 46A3237B402 for ; Tue, 5 Mar 2002 13:17:47 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g25LHji79318; Tue, 5 Mar 2002 14:17:45 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g25LHiL78612; Tue, 5 Mar 2002 14:17:44 -0700 (MST) (envelope-from imp@village.org) Date: Tue, 05 Mar 2002 14:17:37 -0700 (MST) Message-Id: <20020305.141737.62341503.imp@village.org> To: mharnois@cpinternet.com Cc: freebsd-current@FreeBSD.ORG Subject: Re: bktr now fails From: "M. Warner Losh" In-Reply-To: <1015362456.1876.8.camel@mharnois.mdharnois.net> References: <87664bawkh.fsf@mharnois.mdharnois.net> <20020305.111042.53236945.imp@village.org> <1015362456.1876.8.camel@mharnois.mdharnois.net> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <1015362456.1876.8.camel@mharnois.mdharnois.net> "Michael D. Harnois" writes: : On Tue, 2002-03-05 at 12:10, M. Warner Losh wrote: : : > Humor me and compile PCI_ALLOW_UNSUPPORTED_IO_RANGE : : You da man. Thanks! You should never need to define that option, so it means that the range clipping is (still) bogus :-(. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 14:33:23 2002 Delivered-To: freebsd-current@freebsd.org Received: from viruswall.ccf.swri.edu (viruswall.ccf.swri.edu [129.162.252.34]) by hub.freebsd.org (Postfix) with ESMTP id 97A5737B405 for ; Tue, 5 Mar 2002 14:33:16 -0800 (PST) Received: from overhere.datasys.swri.edu (localhost [127.0.0.1]) by viruswall.ccf.swri.edu (8.10.2+Sun/8.10.2) with ESMTP id g25MXDm18571 for ; Tue, 5 Mar 2002 16:33:15 -0600 (CST) Received: from JFFLORES1 (JFFLORES1 [129.162.100.44] (may be forged)) by overhere.datasys.swri.edu (Build 101 8.9.3/NT-8.9.3) with SMTP id QAA05161 for ; Tue, 05 Mar 2002 16:33:13 -0600 From: "Jesus Flores" To: Subject: subscribe Date: Tue, 5 Mar 2002 16:30:41 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 14:50: 3 2002 Delivered-To: freebsd-current@freebsd.org Received: from owa1.digisle.com (ex-owa-sj.digisle.com [165.193.27.217]) by hub.freebsd.org (Postfix) with ESMTP id DAE9B37B404; Tue, 5 Mar 2002 14:49:56 -0800 (PST) Received: from digisle.net ([206.220.227.145] RDNS failed) by owa1.digisle.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 5 Mar 2002 14:49:56 -0800 Message-ID: <3C854B94.7F8AB086@digisle.net> Date: Tue, 05 Mar 2002 14:49:56 -0800 From: Maksim Yevmenkin Organization: Digital Island X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: freebsd-current@FreeBSD.ORG, archie@FreeBSD.ORG Subject: Re: Netgraph, device drivers and mutexes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Mar 2002 22:49:56.0694 (UTC) FILETIME=[1276E760:01C1C498] Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian, > On Mon, 4 Mar 2002, Julian Elischer wrote: > > > > > > > On Mon, 4 Mar 2002, Maksim Yevmenkin wrote: > > > > > Julian, > > > > > > thank you very much for a such detailed answer :) > > > > > > [...] > > > > > I just checked in some generic timeout routines into ng_base.c > in -current. > > have a look and see if they make sense to you.... than you, i just checked them via CVS web. looks mighty handy to me :) i will cvsup later and try them out. thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 16:11:26 2002 Delivered-To: freebsd-current@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by hub.freebsd.org (Postfix) with ESMTP id 7C21537B405 for ; Tue, 5 Mar 2002 16:11:20 -0800 (PST) Received: from sasami.jurai.net (sasami.jurai.net [66.92.160.223]) by sasami.jurai.net (8.11.6/8.11.6) with ESMTP id g260BCu16973; Tue, 5 Mar 2002 19:11:12 -0500 (EST) (envelope-from winter@jurai.net) Date: Tue, 5 Mar 2002 19:11:12 -0500 (EST) From: "Matthew N. Dodd" To: "M. Warner Losh" Cc: mharnois@cpinternet.com, Subject: Re: bktr now fails In-Reply-To: <20020305.141737.62341503.imp@village.org> Message-ID: <20020305191045.D82146-100000@sasami.jurai.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 5 Mar 2002, M. Warner Losh wrote: > You should never need to define that option, so it means that the range > clipping is (still) bogus :-(. Yes, the code is probably still not checking both acceptable ranges against the request. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 16:16:26 2002 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id DA0BA37B402 for ; Tue, 5 Mar 2002 16:16:23 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g260GMi80644; Tue, 5 Mar 2002 17:16:22 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g260GLL80271; Tue, 5 Mar 2002 17:16:21 -0700 (MST) (envelope-from imp@village.org) Date: Tue, 05 Mar 2002 17:16:13 -0700 (MST) Message-Id: <20020305.171613.79012169.imp@village.org> To: winter@jurai.net Cc: mharnois@cpinternet.com, freebsd-current@FreeBSD.ORG Subject: Re: bktr now fails From: "M. Warner Losh" In-Reply-To: <20020305191045.D82146-100000@sasami.jurai.net> References: <20020305.141737.62341503.imp@village.org> <20020305191045.D82146-100000@sasami.jurai.net> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020305191045.D82146-100000@sasami.jurai.net> "Matthew N. Dodd" writes: : On Tue, 5 Mar 2002, M. Warner Losh wrote: : > You should never need to define that option, so it means that the range : > clipping is (still) bogus :-(. : : Yes, the code is probably still not checking both acceptable ranges : against the request. That's exactly what is wrong. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 17:42:46 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail009.syd.optusnet.com.au (mail009.syd.optusnet.com.au [203.2.75.170]) by hub.freebsd.org (Postfix) with ESMTP id E4C1237B405 for ; Tue, 5 Mar 2002 17:42:41 -0800 (PST) Received: from webmail02.syd.optusnet.com.au (webmail02.syd.optusnet.com.au [203.2.75.235]) by mail009.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id g261gen08110 for ; Wed, 6 Mar 2002 12:42:40 +1100 Message-Id: <200203060142.g261gen08110@mail009.syd.optusnet.com.au> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) Received: from [203.13.126.19] as user satare@optusnet.com.au by webmail.optusnet.com.au with HTTP; From: Michael Ross To: current@freebsd.org Date: Wed, 06 Mar 2002 12:42:40 +1100 Subject: problems with shutting machine now Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I used portupgrade for the first time a few nights ago. I got through doing a few ports before having to shut the machine down. Now every time I issue the halt command I get the following message Synching discs.. 18 18 18 18 18 18 18 18 18 then something about giving up on the last two buffers (apologies for not being specific, am currently at work away from the machine) Since I have never seen this before I was wondering if one of the ports I upgraded could have broken it. I was going to try and finishing the portupgrade -ra then do a buildworld (will be my first attempt at one) to correct it. I was wondering though if anybody on the list had any other ideas? thanks, Michael Ross satare@optusnet.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 19: 0:53 2002 Delivered-To: freebsd-current@freebsd.org Received: from outboundx.mv.meer.net (outboundx.mv.meer.net [209.157.152.12]) by hub.freebsd.org (Postfix) with ESMTP id DF8D537B405 for ; Tue, 5 Mar 2002 19:00:50 -0800 (PST) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outboundx.mv.meer.net (8.11.6/8.11.6) with ESMTP id g2630js45283 for ; Tue, 5 Mar 2002 19:00:45 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from neville-neil.com ([209.157.133.226]) by mail.meer.net (8.12.1/8.12.1/meer) with ESMTP id g2630icI000177 for ; Tue, 5 Mar 2002 19:00:50 -0800 (PST) Message-Id: <200203060300.g2630icI000177@mail.meer.net> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: freebsd-current@freebsd.org Subject: gtags? htags? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Mar 2002 19:00:45 -0800 From: "George V. Neville-Neil" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Are these supposed to be part of the base install of FreeBSD? I can't find them anywhere and they're not in ports. They're needed for the tags: target in the kernel makefiles and since I'd like to be able to browse code... Thanks for any pointers, George -- George V. Neville-Neil gnn@neville-neil.com NIC:GN82 "Those who would trade liberty for temporary security deserve neither" - Benjamin Franklin -- George V. Neville-Neil gnn@neville-neil.com NIC:GN82 "Those who would trade liberty for temporary security deserve neither" - Benjamin Franklin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 21:45:14 2002 Delivered-To: freebsd-current@freebsd.org Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143]) by hub.freebsd.org (Postfix) with ESMTP id B0E2A37B405 for ; Tue, 5 Mar 2002 21:45:12 -0800 (PST) Received: from localhost qhwt@smtp-send.myrealbox.com [211.18.232.49] by smtp-send.myrealbox.com with Novell NIMS $Revision: 2.88 $ on Novell NetWare; Tue, 05 Mar 2002 22:45:09 -0700 Date: Wed, 6 Mar 2002 14:45:15 +0900 From: qhwt@myrealbox.com Cc: current@freebsd.org Subject: Won't boot after the commits to timecounter code Message-ID: <20020306054514.GA395@gzl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.0i X-Dispatcher: imput version 20000228(IM140) Lines: 18 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello. After upgrading to the kernel as of 2002-03-03 00:00:00(UTC), it stopped booting just after the message: Timecounter "i8254" frequency 1193182 Hz With some debugging printf()'s inserted, I found it was tc->tc_get_timecount() called from tco_delta() called just after the bcopy() in tc_windup(). So maybe the next place I have to look at is i8254_get_timecount(), which is in /sys/i386/isa/clock.c, but the last (effective) commit to this file is revision 1.180(at the end of January). I couldn't even drop into DDB; no response other than to power button. The last bootable(and stable so far) kernel is from 2002-02-24. I don't think this is caused by some leftover in the work directory since I always build kernels in a new empty directory under /usr/obj. Any (clue|fix)\? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 22:26:28 2002 Delivered-To: freebsd-current@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id 50FA437B404 for ; Tue, 5 Mar 2002 22:26:25 -0800 (PST) Received: (qmail 3122 invoked by uid 1000); 6 Mar 2002 06:26:46 -0000 Date: Tue, 5 Mar 2002 22:26:24 -0800 From: Jos Backus To: freebsd-current@freebsd.org Subject: Re: gtags? htags? Message-ID: <20020306062646.GA98174@lizzy.bugworks.com> Reply-To: Jos Backus Mail-Followup-To: freebsd-current@freebsd.org References: <200203060300.g2630icI000177@mail.meer.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203060300.g2630icI000177@mail.meer.net> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Mar 05, 2002 at 07:00:45PM -0800, George V. Neville-Neil wrote: > Are these supposed to be part of the base install of FreeBSD? > I can't find them anywhere and they're not in ports. > > They're needed for the tags: target in the kernel makefiles and since > I'd like to be able to browse code... /usr/ports/devel/global -- Jos Backus _/ _/_/_/ Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 22:33:22 2002 Delivered-To: freebsd-current@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 8398C37B417 for ; Tue, 5 Mar 2002 22:33:19 -0800 (PST) Received: from dan.emsphone.com (dan@localhost [127.0.0.1]) by dan.emsphone.com (8.12.2/8.12.2) with ESMTP id g266XIAl007811; Wed, 6 Mar 2002 00:33:18 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.2/8.12.2/Submit) id g266XIos007810; Wed, 6 Mar 2002 00:33:18 -0600 (CST) Date: Wed, 6 Mar 2002 00:33:17 -0600 From: Dan Nelson To: "George V. Neville-Neil" Cc: freebsd-current@FreeBSD.ORG Subject: Re: gtags? htags? Message-ID: <20020306063317.GB2142@dan.emsphone.com> References: <200203060300.g2630icI000177@mail.meer.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203060300.g2630icI000177@mail.meer.net> User-Agent: Mutt/1.3.27i X-OS: FreeBSD 5.0-CURRENT X-message-flag: Outlook Error Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In the last episode (Mar 05), George V. Neville-Neil said: > Are these supposed to be part of the base install of FreeBSD? > I can't find them anywhere and they're not in ports. They are part of the 'global' port/package. It used to be part of the base system, but the author changed the license to GPL and it was decided that we could easily enough live with it as a port. > They're needed for the tags: target in the kernel makefiles and since > I'd like to be able to browse code... -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 22:42:39 2002 Delivered-To: freebsd-current@freebsd.org Received: from outboundx.mv.meer.net (outboundx.mv.meer.net [209.157.152.12]) by hub.freebsd.org (Postfix) with ESMTP id 4F9D937B404 for ; Tue, 5 Mar 2002 22:42:35 -0800 (PST) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outboundx.mv.meer.net (8.11.6/8.11.6) with ESMTP id g266gUs48502; Tue, 5 Mar 2002 22:42:30 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from neville-neil.com ([209.157.133.226]) by mail.meer.net (8.12.1/8.12.1/meer) with ESMTP id g266gYcI025881; Tue, 5 Mar 2002 22:42:34 -0800 (PST) Message-Id: <200203060642.g266gYcI025881@mail.meer.net> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Dan Nelson Cc: freebsd-current@FreeBSD.ORG Subject: Re: gtags? htags? In-Reply-To: Message from Dan Nelson of "Wed, 06 Mar 2002 00:33:17 CST." <20020306063317.GB2142@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Mar 2002 22:42:34 -0800 From: "George V. Neville-Neil" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > They are part of the 'global' port/package. It used to be part of the > base system, but the author changed the license to GPL and it was > decided that we could easily enough live with it as a port. > Thanks much! Later, George -- George V. Neville-Neil gnn@neville-neil.com NIC:GN82 "Those who would trade liberty for temporary security deserve neither" - Benjamin Franklin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Mar 5 23:49:40 2002 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 5C2ED37B404 for ; Tue, 5 Mar 2002 23:49:33 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g267nILv091592; Wed, 6 Mar 2002 08:49:18 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: qhwt@myrealbox.com Cc: current@FreeBSD.ORG Subject: Re: Won't boot after the commits to timecounter code In-Reply-To: Your message of "Wed, 06 Mar 2002 14:45:15 +0900." <20020306054514.GA395@gzl> Date: Wed, 06 Mar 2002 08:49:18 +0100 Message-ID: <91591.1015400958@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The only thing I know off right now is this thing from BDE which I havn't been able to verify yet: ============================================================================ From: Bruce Evans Subject: dummy_timecounter broken; breaks booting with -d To: Message-Id: <20020305075815.D2623-100000@gamplex.bde.org> Date: Tue, 05 Mar 2002 08:09:26 +1100 %%% Index: kern_tc.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v retrieving revision 1.116 diff -u -2 -r1.116 kern_tc.c --- kern_tc.c 26 Feb 2002 09:16:27 -0000 1.116 +++ kern_tc.c 4 Mar 2002 21:08:03 -0000 @@ -192,4 +252,14 @@ gen = tc->tc_generation; bintime2timeval(&tc->tc_offset, tvp); + /* + * XXX dummy_timecounter is now broken. Its tc_get_timecount + * needs to be called before it works, and that doesn't + * always happen naturally. In particular, we spin forever + * here after booting with -d unless we do an unnatural call + * here, since the screen timeout code is always run on entry + * to ddb, and it calls here. + */ + if (gen == 0 && timecounter == &dummy_timecounter) + (void)tc->tc_get_timecount(tc); } while (gen == 0 || gen != tc->tc_generation); } %%% Bruce In message <20020306054514.GA395@gzl>, qhwt@myrealbox.com writes: >Hello. >After upgrading to the kernel as of 2002-03-03 00:00:00(UTC), it stopped >booting just after the message: > >Timecounter "i8254" frequency 1193182 Hz > >With some debugging printf()'s inserted, I found it was tc->tc_get_timecount() >called from tco_delta() called just after the bcopy() in tc_windup(). >So maybe the next place I have to look at is i8254_get_timecount(), which is in >/sys/i386/isa/clock.c, but the last (effective) commit to this file is >revision 1.180(at the end of January). > >I couldn't even drop into DDB; no response other than to power button. >The last bootable(and stable so far) kernel is from 2002-02-24. >I don't think this is caused by some leftover in the work directory >since I always build kernels in a new empty directory under /usr/obj. > >Any (clue|fix)\? > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-current" in the body of the message > -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 0: 1:15 2002 Delivered-To: freebsd-current@freebsd.org Received: from ldc.ro (ppp028.mediasat.ro [193.231.170.156]) by hub.freebsd.org (Postfix) with SMTP id 96A7037B402 for ; Wed, 6 Mar 2002 00:00:30 -0800 (PST) Received: (qmail 264 invoked by uid 1000); 6 Mar 2002 08:00:19 -0000 Date: Wed, 6 Mar 2002 10:00:19 +0200 From: Alex Popa To: freebsd-current@freebsd.org Subject: Should 4.5-STABLE -> 5.0-CURRENT work? Message-ID: <20020306100019.A208@ldc.ro> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello. I have had a small problem last night going from a 4.5-STABLE system (FreeBSD wabbit.ldc.ro 4.5-STABLE FreeBSD 4.5-STABLE #0: Sun Feb 17 08:58:11 EET 2002 root@wabbit.ldc.ro:/usr/src/sys/compile/WABBIT i386) to current. Last cvsup for current was Mar 5, 22:50 UTC, from cvsup5.freebsd.org. The fail seems to happen in "one true awk". However, I seem to remember a 4.5-RELEASE to 5.0-CURRENT working perfectly around March 2nd. Attached are last 200 lines of buildworld output, and current supfile. Thank you Alex ------------+------------------------------------------ Alex Popa, | "Artificial Intelligence is razor@ldc.ro| no match for Natural Stupidity" ------------+------------------------------------------ "It took the computing power of three C-64s to fly to the Moon. It takes a 486 to run Windows 95. Something is wrong here." --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bw.log" Content-Transfer-Encoding: quoted-printable cd /usr/src/secure/usr.bin/ssh; make _EXTRADEPEND echo ssh: /usr/obj/usr/src/i386/usr/lib/libc.a /usr/obj/usr/src/i386/usr/li= b/libssh.a /usr/obj/usr/src/i386/usr/lib/libcrypto.a /usr/obj/usr/src/i386/= usr/lib/libutil.a /usr/obj/usr/src/i386/usr/lib/libz.a >> .depend =3D=3D=3D> secure/usr.bin/ssh-add rm -f .depend mkdep -f .depend -a -DNO_IDEA /usr/src/secure/usr.bin/ssh-add/../../../= crypto/openssh/ssh-add.c cd /usr/src/secure/usr.bin/ssh-add; make _EXTRADEPEND echo ssh-add: /usr/obj/usr/src/i386/usr/lib/libc.a /usr/obj/usr/src/i386/us= r/lib/libssh.a /usr/obj/usr/src/i386/usr/lib/libcrypto.a >> .depend =3D=3D=3D> secure/usr.bin/ssh-agent rm -f .depend mkdep -f .depend -a -DNO_IDEA /usr/src/secure/usr.bin/ssh-agent/../../.= ./crypto/openssh/ssh-agent.c cd /usr/src/secure/usr.bin/ssh-agent; make _EXTRADEPEND echo ssh-agent: /usr/obj/usr/src/i386/usr/lib/libc.a /usr/obj/usr/src/i386/= usr/lib/libssh.a /usr/obj/usr/src/i386/usr/lib/libcrypto.a >> .depend =3D=3D=3D> secure/usr.bin/ssh-keygen rm -f .depend mkdep -f .depend -a -DNO_IDEA /usr/src/secure/usr.bin/ssh-keygen/../../= ../crypto/openssh/ssh-keygen.c cd /usr/src/secure/usr.bin/ssh-keygen; make _EXTRADEPEND echo ssh-keygen: /usr/obj/usr/src/i386/usr/lib/libc.a /usr/obj/usr/src/i386= /usr/lib/libssh.a /usr/obj/usr/src/i386/usr/lib/libcrypto.a >> .depend =3D=3D=3D> secure/usr.bin/ssh-keyscan rm -f .depend mkdep -f .depend -a -DNO_IDEA /usr/src/secure/usr.bin/ssh-keyscan/../..= /../crypto/openssh/ssh-keyscan.c cd /usr/src/secure/usr.bin/ssh-keyscan; make _EXTRADEPEND echo ssh-keyscan: /usr/obj/usr/src/i386/usr/lib/libc.a /usr/obj/usr/src/i38= 6/usr/lib/libssh.a /usr/obj/usr/src/i386/usr/lib/libcrypto.a >> .depend =3D=3D=3D> secure/usr.sbin =3D=3D=3D> secure/usr.sbin/sshd rm -f .depend mkdep -f .depend -a -DLIBWRAP -DHAVE_LOGIN_CAP -DLOGIN_ACCESS -I/usr/src= /secure/usr.sbin/sshd/../../../usr.bin/login -DUSE_PAM -DHAVE_PAM_GETENVLIS= T -DSKEY -DXAUTH_PATH=3D\"/usr/X11R6/bin/xauth\" -DNO_IDEA /usr/src/secure= /usr.sbin/sshd/../../../crypto/openssh/sshd.c /usr/src/secure/usr.sbin/sshd= /../../../crypto/openssh/auth-rhosts.c /usr/src/secure/usr.sbin/sshd/../../= ../crypto/openssh/auth-passwd.c /usr/src/secure/usr.sbin/sshd/../../../cryp= to/openssh/auth-rsa.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh= /auth-rh-rsa.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshpty= .c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshlogin.c /usr/sr= c/secure/usr.sbin/sshd/../../../crypto/openssh/servconf.c /usr/src/secure/u= sr.sbin/sshd/../../../crypto/openssh/serverloop.c /usr/src/secure/usr.sbin/= sshd/../../../crypto/openssh/auth.c /usr/src/secure/usr.sbin/sshd/../../../= crypto/openssh/auth1.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openss= h/auth2.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-option= s.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c /usr/sr= c/secure/usr.sbin/sshd/../../../crypto/openssh/auth-chall.c /usr/src/secure= /usr.sbin/sshd/../../../crypto/openssh/auth2-chall.c /usr/src/secure/usr.sb= in/sshd/../../../crypto/openssh/auth-pam.c /usr/src/secure/usr.sbin/sshd/..= /../../usr.bin/login/login_access.c /usr/src/secure/usr.sbin/sshd/../../../= crypto/openssh/groupaccess.c cd /usr/src/secure/usr.sbin/sshd; make _EXTRADEPEND echo sshd: /usr/obj/usr/src/i386/usr/lib/libc.a /usr/obj/usr/src/i386/usr/l= ib/libopie.a /usr/obj/usr/src/i386/usr/lib/libmd.a /usr/obj/usr/src/i386/us= r/lib/libssh.a /usr/obj/usr/src/i386/usr/lib/libcrypt.a /usr/obj/usr/src/i3= 86/usr/lib/libcrypto.a /usr/obj/usr/src/i386/usr/lib/libutil.a /usr/obj/usr= /src/i386/usr/lib/libz.a /usr/obj/usr/src/i386/usr/lib/libwrap.a /usr/obj/u= sr/src/i386/usr/lib/libpam.a >> .depend =3D=3D=3D> share =3D=3D=3D> share/colldef =3D=3D=3D> share/dict =3D=3D=3D> share/examples =3D=3D=3D> share/man =3D=3D=3D> share/man/man1 =3D=3D=3D> share/man/man3 =3D=3D=3D> share/man/man4 =3D=3D=3D> share/man/man4/man4.i386 =3D=3D=3D> share/man/man5 =3D=3D=3D> share/man/man6 =3D=3D=3D> share/man/man7 =3D=3D=3D> share/man/man8 =3D=3D=3D> share/man/man8/man8.i386 =3D=3D=3D> share/man/man9 =3D=3D=3D> share/me =3D=3D=3D> share/misc =3D=3D=3D> share/mk =3D=3D=3D> share/mklocale =3D=3D=3D> share/monetdef =3D=3D=3D> share/msgdef =3D=3D=3D> share/numericdef =3D=3D=3D> share/skel =3D=3D=3D> share/syscons =3D=3D=3D> share/syscons/fonts =3D=3D=3D> share/syscons/keymaps =3D=3D=3D> share/syscons/scrnmaps =3D=3D=3D> share/tabset =3D=3D=3D> share/termcap =3D=3D=3D> share/timedef =3D=3D=3D> share/zoneinfo =3D=3D=3D> share/doc =3D=3D=3D> share/doc/psd =3D=3D=3D> share/doc/psd/title =3D=3D=3D> share/doc/psd/contents =3D=3D=3D> share/doc/psd/05.sysman =3D=3D=3D> share/doc/psd/12.make =3D=3D=3D> share/doc/psd/13.rcs =3D=3D=3D> share/doc/psd/13.rcs/rcs =3D=3D=3D> share/doc/psd/13.rcs/rcs_func =3D=3D=3D> share/doc/psd/18.gprof =3D=3D=3D> share/doc/psd/20.ipctut =3D=3D=3D> share/doc/psd/21.ipc =3D=3D=3D> share/doc/psd/22.rpcgen =3D=3D=3D> share/doc/psd/23.rpc =3D=3D=3D> share/doc/psd/24.xdr =3D=3D=3D> share/doc/psd/25.xdrrfc =3D=3D=3D> share/doc/psd/26.rpcrfc =3D=3D=3D> share/doc/psd/27.nfsrpc =3D=3D=3D> share/doc/psd/28.cvs =3D=3D=3D> share/doc/smm =3D=3D=3D> share/doc/smm/title =3D=3D=3D> share/doc/smm/contents =3D=3D=3D> share/doc/smm/01.setup =3D=3D=3D> share/doc/smm/02.config =3D=3D=3D> share/doc/smm/03.fsck =3D=3D=3D> share/doc/smm/04.quotas =3D=3D=3D> share/doc/smm/05.fastfs =3D=3D=3D> share/doc/smm/06.nfs =3D=3D=3D> share/doc/smm/10.named =3D=3D=3D> share/doc/smm/11.timedop =3D=3D=3D> share/doc/smm/12.timed =3D=3D=3D> share/doc/smm/18.net =3D=3D=3D> share/doc/usd =3D=3D=3D> share/doc/usd/title =3D=3D=3D> share/doc/usd/contents =3D=3D=3D> share/doc/usd/04.csh =3D=3D=3D> share/doc/usd/07.mail =3D=3D=3D> share/doc/usd/10.exref =3D=3D=3D> share/doc/usd/10.exref/exref =3D=3D=3D> share/doc/usd/10.exref/summary =3D=3D=3D> share/doc/usd/11.vitut =3D=3D=3D> share/doc/usd/12.vi =3D=3D=3D> share/doc/usd/12.vi/vi =3D=3D=3D> share/doc/usd/12.vi/viapwh =3D=3D=3D> share/doc/usd/12.vi/summary =3D=3D=3D> share/doc/usd/13.viref =3D=3D=3D> share/doc/usd/18.msdiffs =3D=3D=3D> share/doc/usd/19.memacros =3D=3D=3D> share/doc/usd/20.meref =3D=3D=3D> share/doc/usd/30.rogue =3D=3D=3D> share/doc/usd/31.trek =3D=3D=3D> share/doc/papers =3D=3D=3D> share/doc/papers/beyond4.3 =3D=3D=3D> share/doc/papers/bufbio =3D=3D=3D> share/doc/papers/diskperf =3D=3D=3D> share/doc/papers/fsinterface =3D=3D=3D> share/doc/papers/jail =3D=3D=3D> share/doc/papers/kernmalloc =3D=3D=3D> share/doc/papers/kerntune =3D=3D=3D> share/doc/papers/malloc =3D=3D=3D> share/doc/papers/newvm =3D=3D=3D> share/doc/papers/nqnfs =3D=3D=3D> share/doc/papers/px =3D=3D=3D> share/doc/papers/relengr =3D=3D=3D> share/doc/papers/sysperf =3D=3D=3D> share/doc/papers/devfs =3D=3D=3D> share/doc/papers/contents =3D=3D=3D> share/doc/IPv6 =3D=3D=3D> share/isdn =3D=3D=3D> sys =3D=3D=3D> sys/boot =3D=3D=3D> sys/boot/ficl (cd /usr/src/sys/boot/ficl/softwords; cat softcore.fr jhlocal.fr marker.fr = freebsd.fr ficllocal.fr ifbrack.fr | awk -f softcore.awk -v datestamp=3D"= `LC_ALL=3DC date`") > softcore.c rm -f .depend mkdep -f .depend -a -I/usr/src/sys/boot/ficl -I/usr/src/sys/boot/ficl/i3= 86 -I/usr/src/sys/boot/ficl/../common /usr/src/sys/boot/ficl/dict.c /usr/s= rc/sys/boot/ficl/ficl.c /usr/src/sys/boot/ficl/math64.c /usr/src/sys/boot/f= icl/search.c /usr/src/sys/boot/ficl/stack.c /usr/src/sys/boot/ficl/tools.c = /usr/src/sys/boot/ficl/prefix.c /usr/src/sys/boot/ficl/loader.c /usr/src/sy= s/boot/ficl/vm.c /usr/src/sys/boot/ficl/words.c /usr/src/sys/boot/ficl/i386= /sysdep.c softcore.c cd /usr/src/sys/boot/ficl; make _EXTRADEPEND =3D=3D=3D> sys/boot/i386 =3D=3D=3D> sys/boot/i386/mbr =3D=3D=3D> sys/boot/i386/boot0 =3D=3D=3D> sys/boot/i386/btx =3D=3D=3D> sys/boot/i386/btx/btx =3D=3D=3D> sys/boot/i386/btx/btxldr =3D=3D=3D> sys/boot/i386/btx/lib =3D=3D=3D> sys/boot/i386/boot2 =3D=3D=3D> sys/boot/i386/cdboot =3D=3D=3D> sys/boot/i386/kgzldr rm -f .depend mkdep -f .depend -a -DKZIP /usr/src/sys/boot/i386/kgzldr/start.s /usr= /src/sys/boot/i386/kgzldr/crt.s /usr/src/sys/boot/i386/kgzldr/sio.s mkdep -f .depend -a -DKZIP /usr/src/sys/boot/i386/kgzldr/boot.c /usr/sr= c/sys/boot/i386/kgzldr/../../../kern/inflate.c /usr/src/sys/boot/i386/kgzld= r/lib.c cd /usr/src/sys/boot/i386/kgzldr; make _EXTRADEPEND echo kgzldr.o: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend =3D=3D=3D> sys/boot/i386/libi386 ln -sf /usr/src/sys/boot/i386/libi386/../../../i386/include machine rm -f .depend mkdep -f .depend -a -I/usr/src/sys/boot/i386/libi386/../../common -I/usr= /src/sys/boot/i386/libi386/../btx/lib -I/usr/src/sys/boot/i386/libi386/../.= ./../contrib/dev/acpica -I/usr/src/sys/boot/i386/libi386/../../.. -I. -DCOM= PORT=3D0x3f8 -DCOMSPEED=3D9600 -I/usr/src/sys/boot/i386/libi386/../../../..= /lib/libstand/ -DTERM_EMU /usr/src/sys/boot/i386/libi386/pxetramp.s mkdep -f .depend -a -I/usr/src/sys/boot/i386/libi386/../../common -I/usr= /src/sys/boot/i386/libi386/../btx/lib -I/usr/src/sys/boot/i386/libi386/../.= ./../contrib/dev/acpica -I/usr/src/sys/boot/i386/libi386/../../.. -I. -DCOM= PORT=3D0x3f8 -DCOMSPEED=3D9600 -I/usr/src/sys/boot/i386/libi386/../../../..= /lib/libstand/ -DTERM_EMU /usr/src/sys/boot/i386/libi386/aout_freebsd.c /u= sr/src/sys/boot/i386/libi386/biosacpi.c /usr/src/sys/boot/i386/libi386/bios= cd.c /usr/src/sys/boot/i386/libi386/biosdisk.c /usr/src/sys/boot/i386/libi3= 86/biosmem.c /usr/src/sys/boot/i386/libi386/biospnp.c /usr/src/sys/boot/i38= 6/libi386/biospci.c /usr/src/sys/boot/i386/libi386/bootinfo.c /usr/src/sys/= boot/i386/libi386/comconsole.c /usr/src/sys/boot/i386/libi386/devicename.c = /usr/src/sys/boot/i386/libi386/elf_freebsd.c /usr/src/sys/boot/i386/libi386= /gatea20.c /usr/src/sys/boot/i386/libi386/i386_copy.c /usr/src/sys/boot/i38= 6/libi386/i386_module.c /usr/src/sys/boot/i386/libi386/nullconsole.c /usr/s= rc/sys/boot/i386/libi386/pxe.c /usr/src/sys/boot/i386/libi386/time.c /usr/s= rc/sys/boot/i386/libi386/vidconsole.c cd /usr/src/sys/boot/i386/libi386; make _EXTRADEPEND =3D=3D=3D> sys/boot/i386/loader ln -sf /usr/src/sys/boot/i386/loader/../../../i386/include machine rm -f .depend mkdep -f .depend -a -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/usr/src/sys/boo= t/i386/loader/../../ficl -I/usr/src/sys/boot/i386/loader/../../ficl/i386 -D= LOADER_GZIP_SUPPORT -I/usr/src/sys/boot/i386/loader/../../common -I/usr/src= /sys/boot/i386/loader/../../.. -I. -I/usr/src/sys/boot/i386/loader/.. -I/us= r/src/sys/boot/i386/loader/../../../../lib/libstand/ -I/usr/src/sys/boot/i3= 86/loader/../btx/lib /usr/src/sys/boot/i386/loader/main.c /usr/src/sys/boo= t/i386/loader/conf.c /usr/src/sys/boot/i386/loader/../../common/bcache.c /u= sr/src/sys/boot/i386/loader/../../common/boot.c /usr/src/sys/boot/i386/load= er/../../common/commands.c /usr/src/sys/boot/i386/loader/../../common/conso= le.c /usr/src/sys/boot/i386/loader/../../common/devopen.c /usr/src/sys/boot= /i386/loader/../../common/interp.c /usr/src/sys/boot/i386/loader/../../comm= on/interp_backslash.c /usr/src/sys/boot/i386/loader/../../common/interp_par= se.c /usr/src/sys/boot/i386/loader/../../common/load_aout.c /usr/src/sys/bo= ot/i386/loader/../../common/load_elf.c /usr/src/sys/boot/i386/loader/../../= common/ls.c /usr/src/sys/boot/i386/loader/../../common/misc.c /usr/src/sys/= boot/i386/loader/../../common/module.c /usr/src/sys/boot/i386/loader/../../= common/panic.c /usr/src/sys/boot/i386/loader/../../common/isapnp.c /usr/src= /sys/boot/i386/loader/../../common/pnp.c /usr/src/sys/boot/i386/loader/../.= ./common/interp_forth.c cd /usr/src/sys/boot/i386/loader; make _EXTRADEPEND echo loader: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend =3D=3D=3D> sys/boot/i386/pxeldr =3D=3D=3D> sys/boot/i386/liloldr =3D=3D=3D> usr.bin =3D=3D=3D> usr.bin/apply rm -f .depend mkdep -f .depend -a /usr/src/usr.bin/apply/apply.c cd /usr/src/usr.bin/apply; make _EXTRADEPEND echo apply: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend =3D=3D=3D> usr.bin/at rm -f .depend mkdep -f .depend -a -DATJOB_DIR=3D\"/var/at/jobs/\" -DLFILE=3D\"/var/at/= jobs/.lockfile\" -DLOADAVG_MX=3D1.5 -DATSPOOL_DIR=3D\"/var/at/spool\" -DVER= SION=3D\"2.9\" -DDAEMON_UID=3D1 -DDAEMON_GID=3D1 -DDEFAULT_BATCH_QUEUE=3D\'= E\' -DDEFAULT_AT_QUEUE=3D\'c\' -DPERM_PATH=3D\"/var/at/\" /usr/src/usr.bin= /at/at.c /usr/src/usr.bin/at/panic.c /usr/src/usr.bin/at/parsetime.c /usr/s= rc/usr.bin/at/perm.c cd /usr/src/usr.bin/at; make _EXTRADEPEND echo at: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend =3D=3D=3D> usr.bin/awk Expect 42 reduce/shift conflicts and 83 reduce/reduce conflicts yacc -d /usr/src/usr.bin/awk/../../contrib/one-true-awk/awkgram.y yacc: 43 shift/reduce conflicts yacc: 85 reduce/reduce conflicts mv -f y.tab.c ytab.c mv -f y.tab.h ytab.h cc -O -pipe -march=3Dpentiumpro -funsigned-char -I. -I/usr/src/usr.bin/awk/= ../../contrib/one-true-awk /usr/src/usr.bin/awk/../../contrib/one-true-a= wk/maketab.c -o maketab =2E/maketab > proctab.c /usr/libexec/ld-elf.so.1: Shared object "libc.so.5" not found *** Error code 1 Stop in /usr/src/usr.bin/awk. *** Error code 1 Stop in /usr/src/usr.bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=current-supfile *default host=cvsup.ro.freebsd.org *default base=/usr *default prefix=/usr *default release=cvs tag=. *default delete use-rel-suffix *default compress src-all --oyUTqETQ0mS9luUI-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 0:16: 5 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by hub.freebsd.org (Postfix) with ESMTP id 55D8B37B400 for ; Wed, 6 Mar 2002 00:16:01 -0800 (PST) Received: from fwd07.sul.t-online.de by mailout09.sul.t-online.com with smtp id 16iWad-0001bJ-02; Wed, 06 Mar 2002 09:15:59 +0100 Received: from twoflower (320072111332-0001@[217.80.127.21]) by fmrl07.sul.t-online.com with smtp id 16iWaL-1CLnsmC; Wed, 6 Mar 2002 09:15:41 +0100 Reply-To: From: "Jan Stocker" To: "Martin Blapp" , Subject: RE: gcc -O broken in CURRENT Date: Wed, 6 Mar 2002 09:14:31 +0100 Message-ID: <000101c1c4e6$f19e7360$fe02010a@twoflower.liebende.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20020304205513.Q56102-100000@levais.imp.ch> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Sender: 320072111332-0001@t-dialin.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This can be reproduced on my system and it may be a big problem. I installed everthing from source with -O set in make.conf and some proggys running fine under 4.4 wont unter -current. Recompiling the proggys without -O dont fix it but maybe it is caused by some libs... Is anyone examining this problem? Jan > -----Original Message----- > From: owner-freebsd-current@FreeBSD.ORG > [mailto:owner-freebsd-current@FreeBSD.ORG]On Behalf Of Martin Blapp > Sent: Monday, March 04, 2002 9:02 PM > To: current@FreeBSD.ORG > Subject: gcc -O broken in CURRENT > > > > Hi all, > > Unfortunatly I have a example from the ports, needed > by OpenOffice port (work in progress) > > cd /usr/ports/devel/stlport/ && make install > cd /usr/ports/devel/stlport/work/STLport-4.5.3/test/eh > gmake -f gcc-freebsd.mak > > [vector] :testing n-size constructor (const) ... 95 try successful > [vector] :testing pointer range constructor (const) ... > Bus error - core dumped > > Then > > remove the three -O from gcc-freebsd.mak and run it again. > > You will see that all tests are successfully done. > > [...] > [hash_multiset] :testing default constructor (const) ... 2 try successful > [hash_multiset] :testing iterator range n-size constructor > (const) ... 127 try > successful > [hash_multiset] :testing copy constructor (const) ... 54 try successful > [hash_multiset] :testing assignment operator (weak) ... 53 try successful > [...] > [string] :testing copy constructor (const) ... 2 try successful > [string] :testing assignment operator (weak) ... 1 try successful > EH test : Done > > Martin > > Martin Blapp, > ------------------------------------------------------------------ > ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH > Phone: +41 061 826 93 00: +41 61 826 93 01 > PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E > ------------------------------------------------------------------ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 0:38:45 2002 Delivered-To: freebsd-current@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 3BD1C37B404 for ; Wed, 6 Mar 2002 00:38:43 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g268cZP06897; Wed, 6 Mar 2002 00:38:35 -0800 (PST) (envelope-from obrien) Date: Wed, 6 Mar 2002 00:36:28 -0800 From: "David O'Brien" To: Alex Popa Cc: freebsd-current@freebsd.org Subject: Re: Should 4.5-STABLE -> 5.0-CURRENT work? Message-ID: <20020306003628.A6868@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20020306100019.A208@ldc.ro> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020306100019.A208@ldc.ro>; from razor@ldc.ro on Wed, Mar 06, 2002 at 10:00:19AM +0200 X-Operating-System: FreeBSD 5.0-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 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 06, 2002 at 10:00:19AM +0200, Alex Popa wrote: > cc -O -pipe -march=pentiumpro -funsigned-char -I. -I/usr/src/usr.bin/awk/../../contrib/one-true-awk /usr/src/usr.bin/awk/../../contrib/one-true-awk/maketab.c -o maketab > ./maketab > proctab.c > /usr/libexec/ld-elf.so.1: Shared object "libc.so.5" not found > *** Error code 1 > > Stop in /usr/src/usr.bin/awk. > *** Error code 1 (*sigh*) Fixed. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 0:59:52 2002 Delivered-To: freebsd-current@freebsd.org Received: from castle.jp.FreeBSD.org (castle.jp.FreeBSD.org [210.226.20.15]) by hub.freebsd.org (Postfix) with ESMTP id 1AE8237B400 for ; Wed, 6 Mar 2002 00:59:49 -0800 (PST) Received: from localhost (localhost [::1]) by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet6 id g268xjP26337; Wed, 6 Mar 2002 17:59:45 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Cc: current@FreeBSD.org In-Reply-To: <200203060300.g2630icI000177@mail.meer.net> References: <200203060300.g2630icI000177@mail.meer.net> X-User-Agent: Mew/1.94.2 XEmacs/21.5 (bamboo) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 9 From: Makoto Matsushita To: gnn@neville-neil.com Subject: Re: gtags? htags? Date: Wed, 06 Mar 2002 17:59:42 +0900 Message-Id: <20020306175942D.matusita@jp.FreeBSD.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG gnn> They're needed for the tags: target in the kernel makefiles and gnn> since I'd like to be able to browse code... Feel free to check . Both 5-current and 4-stable code are HTMLed with GLOBAL daily. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 3:28: 3 2002 Delivered-To: freebsd-current@freebsd.org Received: from skaarup.org (skaarup.org [130.228.230.140]) by hub.freebsd.org (Postfix) with SMTP id E8AD237B417 for ; Wed, 6 Mar 2002 03:27:57 -0800 (PST) Received: (qmail 28429 invoked by uid 0); 6 Mar 2002 11:27:57 -0000 Received: from localhost (HELO skaarup.org) (127.0.0.1) by localhost with SMTP; 6 Mar 2002 11:27:55 -0000 Received: (qmail 28421 invoked by uid 1039); 6 Mar 2002 11:27:55 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Mar 2002 11:27:55 -0000 Date: Wed, 6 Mar 2002 12:27:55 +0100 (CET) From: Rasmus Skaarup To: freebsd-current@freebsd.org Subject: 5-CURRENT, make buildworld break? Message-ID: <20020306122443.D28351-100000@skaarup.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 @skaarup.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, I upgraded frem 4.5-STABLE to 5.0-CURRENT three days ago, and it worked fine. But since I cvsupped yesterday, a 'make buildworld' results in: ** snip snip ** cc -pg -O -pipe -I/usr/src/lib/libpam/libpam -I/usr/src/lib/libpam/libpam/../.. /../contrib/openpam/include -DLIB_MAJ=2 -Werror -Wall -W -Wstrict-prototypes -Wm issing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wsw itch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/lib/libpam/libpam/pam _std_option.c -o pam_std_option.po make: don't know how to make openpam_static_modules.po. Stop *** Error code 2 Stop in /usr/src/lib/libpam. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 ** snip snip ** I've tried several times, each time with a clean /usr/obj. Best regards, Rasmus Skaarup To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 3:46:32 2002 Delivered-To: freebsd-current@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id DD07F37B41B; Wed, 6 Mar 2002 03:46:25 -0800 (PST) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.6/8.11.6) id g26Bk7e43417; Wed, 6 Mar 2002 13:46:07 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200203061146.g26Bk7e43417@zibbi.icomtek.csir.co.za> Subject: Re: 5-CURRENT, make buildworld break? In-Reply-To: <20020306122443.D28351-100000@skaarup.org> from Rasmus Skaarup at "Mar 6, 2002 12:27:55 pm" To: mfbsd@skaarup.org (Rasmus Skaarup) Date: Wed, 6 Mar 2002 13:46:07 +0200 (SAT) Cc: freebsd-current@FreeBSD.ORG, des@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I see that here too. Maybe des missed something during his openpam upgrade? John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org > I upgraded frem 4.5-STABLE to 5.0-CURRENT three days ago, and it worked > fine. But since I cvsupped yesterday, a 'make buildworld' results in: > > ** snip snip ** > > cc -pg -O -pipe -I/usr/src/lib/libpam/libpam > -I/usr/src/lib/libpam/libpam/../.. /../contrib/openpam/include -DLIB_MAJ=2 > -Werror -Wall -W -Wstrict-prototypes -Wm issing-prototypes -Wpointer-arith > -Wreturn-type -Wcast-qual -Wwrite-strings -Wsw itch -Wshadow -Wcast-align > -Wno-uninitialized -c /usr/src/lib/libpam/libpam/pam _std_option.c -o > pam_std_option.po > make: don't know how to make openpam_static_modules.po. > Stop *** Error code 2 > > Stop in /usr/src/lib/libpam. > *** Error code 1 > > Stop in /usr/src/lib. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > ** snip snip ** > > I've tried several times, each time with a clean /usr/obj. > > > Best regards, > Rasmus Skaarup To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 3:52:59 2002 Delivered-To: freebsd-current@freebsd.org Received: from sbk-gw.sibnet.ru (sbk-gw.sibnet.ru [217.70.96.146]) by hub.freebsd.org (Postfix) with ESMTP id 8EB8137B402 for ; Wed, 6 Mar 2002 03:52:49 -0800 (PST) Received: from localhost (stranger@localhost) by sbk-gw.sibnet.ru (8.11.6/8.11.6) with ESMTP id g26BqpX86374 for ; Wed, 6 Mar 2002 17:52:51 +0600 (NOVT) (envelope-from stranger@sberbank.sibnet.ru) Date: Wed, 6 Mar 2002 17:52:50 +0600 (NOVT) From: "Maxim M. Kazachek" X-X-Sender: stranger@sbk-gw.sibnet.ru To: freebsd-current@freebsd.org Subject: Re: 5-CURRENT, make buildworld break? In-Reply-To: <20020306122443.D28351-100000@skaarup.org> Message-ID: <20020306175114.T86365-100000@sbk-gw.sibnet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It dies on the depend stage, if -DNOPROFILE is used... It needs pam_misc.h on usr.bin/su then. Sincerely, Maxim M. Kazachek mailto:stranger@sberbank.sibnet.ru mailto:stranger@fpm.ami.nstu.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 4: 1:24 2002 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id EA16A37B417 for ; Wed, 6 Mar 2002 04:01:20 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id D293E5347; Wed, 6 Mar 2002 13:01:19 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: John Hay Cc: mfbsd@skaarup.org (Rasmus Skaarup), freebsd-current@FreeBSD.ORG Subject: Re: 5-CURRENT, make buildworld break? References: <200203061146.g26Bk7e43417@zibbi.icomtek.csir.co.za> From: Dag-Erling Smorgrav Date: 06 Mar 2002 13:01:19 +0100 In-Reply-To: <200203061146.g26Bk7e43417@zibbi.icomtek.csir.co.za> Message-ID: Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Hay writes: > I see that here too. Maybe des missed something during his openpam upgrade? Ah, yes - src/lib/libpam/libpam/Makefile should have NOPROFILE=YES. I didn't notice because I have it in my make.conf. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 4:17:34 2002 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id B784937B404; Wed, 6 Mar 2002 04:17:31 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 023D85347; Wed, 6 Mar 2002 13:17:29 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Ruslan Ermilov Cc: John Hay , Rasmus Skaarup , freebsd-current@FreeBSD.ORG Subject: Re: 5-CURRENT, make buildworld break? References: <200203061146.g26Bk7e43417@zibbi.icomtek.csir.co.za> <20020306121412.GD20782@sunbay.com> From: Dag-Erling Smorgrav Date: 06 Mar 2002 13:17:28 +0100 In-Reply-To: <20020306121412.GD20782@sunbay.com> Message-ID: Lines: 10 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ruslan Ermilov writes: > That's why it's always a good idea to test changes with "make release", > in a pristine environment. Last I checked, 'make release' checks the sources out from CVS, and is therefore useless to test changes that haven't yet been committed. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 4:21:28 2002 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 2768A37B405 for ; Wed, 6 Mar 2002 04:21:17 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g26CKGs25943; Wed, 6 Mar 2002 14:20:16 +0200 (EET) (envelope-from ru) Date: Wed, 6 Mar 2002 14:20:16 +0200 From: Ruslan Ermilov To: Dag-Erling Smorgrav Cc: John Hay , Rasmus Skaarup , freebsd-current@FreeBSD.ORG Subject: Re: 5-CURRENT, make buildworld break? Message-ID: <20020306122016.GF20782@sunbay.com> References: <200203061146.g26Bk7e43417@zibbi.icomtek.csir.co.za> <20020306121412.GD20782@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 06, 2002 at 01:17:28PM +0100, Dag-Erling Smorgrav wrote: > Ruslan Ermilov writes: > > That's why it's always a good idea to test changes with "make release", > > in a pristine environment. > > Last I checked, 'make release' checks the sources out from CVS, and is > therefore useless to test changes that haven't yet been committed. > There's such a thing as LOCAL_PATCHES since at least 1996. Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 4:21:39 2002 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id B823737B402 for ; Wed, 6 Mar 2002 04:21:22 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g26CECe25263; Wed, 6 Mar 2002 14:14:12 +0200 (EET) (envelope-from ru) Date: Wed, 6 Mar 2002 14:14:12 +0200 From: Ruslan Ermilov To: Dag-Erling Smorgrav Cc: John Hay , Rasmus Skaarup , freebsd-current@FreeBSD.ORG Subject: Re: 5-CURRENT, make buildworld break? Message-ID: <20020306121412.GD20782@sunbay.com> References: <200203061146.g26Bk7e43417@zibbi.icomtek.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 06, 2002 at 01:01:19PM +0100, Dag-Erling Smorgrav wrote: > John Hay writes: > > I see that here too. Maybe des missed something during his openpam upgrade? > > Ah, yes - src/lib/libpam/libpam/Makefile should have NOPROFILE=YES. I > didn't notice because I have it in my make.conf. > That's why it's always a good idea to test changes with "make release", in a pristine environment. Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 4:25: 7 2002 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 85CBB37B402; Wed, 6 Mar 2002 04:25:04 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id DCA2F5348; Wed, 6 Mar 2002 13:25:02 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Ruslan Ermilov Cc: John Hay , Rasmus Skaarup , freebsd-current@FreeBSD.ORG Subject: Re: 5-CURRENT, make buildworld break? References: <200203061146.g26Bk7e43417@zibbi.icomtek.csir.co.za> <20020306121412.GD20782@sunbay.com> <20020306122016.GF20782@sunbay.com> From: Dag-Erling Smorgrav Date: 06 Mar 2002 13:25:01 +0100 In-Reply-To: <20020306122016.GF20782@sunbay.com> Message-ID: Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ruslan Ermilov writes: > On Wed, Mar 06, 2002 at 01:17:28PM +0100, Dag-Erling Smorgrav wrote: > > Last I checked, 'make release' checks the sources out from CVS, and is > > therefore useless to test changes that haven't yet been committed. > There's such a thing as LOCAL_PATCHES since at least 1996. Great! Now if only that was *documented* somewhere... DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 4:30:18 2002 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 72AD437B416 for ; Wed, 6 Mar 2002 04:30:08 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g26CT3o27109; Wed, 6 Mar 2002 14:29:03 +0200 (EET) (envelope-from ru) Date: Wed, 6 Mar 2002 14:29:03 +0200 From: Ruslan Ermilov To: Dag-Erling Smorgrav Cc: John Hay , Rasmus Skaarup , freebsd-current@FreeBSD.ORG Subject: Re: 5-CURRENT, make buildworld break? Message-ID: <20020306122903.GG20782@sunbay.com> References: <200203061146.g26Bk7e43417@zibbi.icomtek.csir.co.za> <20020306121412.GD20782@sunbay.com> <20020306122016.GF20782@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 06, 2002 at 01:25:01PM +0100, Dag-Erling Smorgrav wrote: > Ruslan Ermilov writes: > > On Wed, Mar 06, 2002 at 01:17:28PM +0100, Dag-Erling Smorgrav wrote: > > > Last I checked, 'make release' checks the sources out from CVS, and is > > > therefore useless to test changes that haven't yet been committed. > > There's such a thing as LOCAL_PATCHES since at least 1996. > > Great! Now if only that was *documented* somewhere... > We have a "make release" guy now, please blame him! :-) On Fri, Oct 26, 2001 at 08:28:25PM +0900, Makoto MATSUSHITA wrote: > > Dear Committers, > > Today I've joined the FreeBSD developers' team with lots of helps of > Kuriyama-san (he is my mentor). I'll work in the area of > src/release (boot floppies, release procedures), and I'll be a member > of make-buildworld/installworld/release-breaker busters. Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 5:47:50 2002 Delivered-To: freebsd-current@freebsd.org Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143]) by hub.freebsd.org (Postfix) with ESMTP id 15D3B37B402 for ; Wed, 6 Mar 2002 05:47:47 -0800 (PST) Received: from localhost qhwt@smtp-send.myrealbox.com [61.198.248.224] by smtp-send.myrealbox.com with Novell NIMS $Revision: 2.88 $ on Novell NetWare; Wed, 06 Mar 2002 06:47:41 -0700 Date: Wed, 6 Mar 2002 22:47:47 +0900 From: qhwt@myrealbox.com To: current@FreeBSD.ORG Subject: Re: Won't boot after the commits to timecounter code Message-ID: <20020306134746.GA342@gzl> References: <20020306054514.GA395@gzl> <91591.1015400958@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91591.1015400958@critter.freebsd.dk> User-Agent: Mutt/1.5.0i X-Dispatcher: imput version 20000228(IM140) Lines: 73 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 06, 2002 at 08:49:18AM +0100, Poul-Henning Kamp wrote: > > In message <20020306054514.GA395@gzl>, qhwt@myrealbox.com writes: > > >Hello. > > >After upgrading to the kernel as of 2002-03-03 00:00:00(UTC), it stopped > > >booting just after the message: > > > > > >Timecounter "i8254" frequency 1193182 Hz > > > > > >With some debugging printf()'s inserted, I found it was tc->tc_get_timecount() > > >called from tco_delta() called just after the bcopy() in tc_windup(). > > >So maybe the next place I have to look at is i8254_get_timecount(), which is in > > >/sys/i386/isa/clock.c, but the last (effective) commit to this file is > > >revision 1.180(at the end of January). > > > > > >I couldn't even drop into DDB; no response other than to power button. > > >The last bootable(and stable so far) kernel is from 2002-02-24. > > >I don't think this is caused by some leftover in the work directory > > >since I always build kernels in a new empty directory under /usr/obj. > > > > > >Any (clue|fix)\? > > The only thing I know off right now is this thing from BDE which > I havn't been able to verify yet: > > > > ============================================================================ > From: Bruce Evans > Subject: dummy_timecounter broken; breaks booting with -d > To: > Message-Id: <20020305075815.D2623-100000@gamplex.bde.org> > Date: Tue, 05 Mar 2002 08:09:26 +1100 > > %%% > Index: kern_tc.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v > retrieving revision 1.116 > diff -u -2 -r1.116 kern_tc.c > --- kern_tc.c 26 Feb 2002 09:16:27 -0000 1.116 > +++ kern_tc.c 4 Mar 2002 21:08:03 -0000 > @@ -192,4 +252,14 @@ > gen = tc->tc_generation; > bintime2timeval(&tc->tc_offset, tvp); > + /* > + * XXX dummy_timecounter is now broken. Its tc_get_timecount > + * needs to be called before it works, and that doesn't > + * always happen naturally. In particular, we spin forever > + * here after booting with -d unless we do an unnatural call > + * here, since the screen timeout code is always run on entry > + * to ddb, and it calls here. > + */ > + if (gen == 0 && timecounter == &dummy_timecounter) > + (void)tc->tc_get_timecount(tc); > } while (gen == 0 || gen != tc->tc_generation); > } > %%% > > Bruce Hmm, this doesn't seem to change the situation. I tried reverting the following files: /sys/sys/timetc.h: 1.46 -> 1.45 /sys/kern/kern_tc.c: 1.116 -> 1.114 and managed to get into the single-user mode, but this of course doesn't solve the problem. I inserted a pair of printf() inside mtx_lock_spin/mtx_unlock_spin in i8254_get_timecount() and it kept printing the message while tc_init() was blocked, so I think it's blocked at mtx_lock_spin in i8254_get_timecount() when called from tc_init(), but not when called from somewhere else. (maybe an interrupt handler?) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 8:24: 2 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id AC56637B416 for ; Wed, 6 Mar 2002 08:23:02 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id DAA02466; Thu, 7 Mar 2002 03:22:51 +1100 Date: Thu, 7 Mar 2002 03:23:47 +1100 (EST) From: Bruce Evans X-X-Sender: To: Poul-Henning Kamp Cc: , Subject: Re: Won't boot after the commits to timecounter code In-Reply-To: <91591.1015400958@critter.freebsd.dk> Message-ID: <20020307031019.X9539-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Mar 2002, Poul-Henning Kamp wrote: > The only thing I know off right now is this thing from BDE which > I havn't been able to verify yet: I got the hang for all boots, but it was a local problem. I had added a nanouptime() call the tc_windup(), and this spins forever when tc_windup() is called from tc_init() or switch_timecounter() (because timecounter->generation is 0). At least one of these calls is made unconditionally at boot time, but there is normally no problem, at least if WITNESS and KTR are not enabled (my default) because the functions that spin on the generation update are not called. But interrupt activity might result in them being called, and WITNESS and/or KTR call them if a lock is witnessed. The following patch is the result of attempting to debug this. I first had to debug the debugger, since it has the same problem. > ============================================================================ > From: Bruce Evans > Subject: dummy_timecounter broken; breaks booting with -d > To: > Message-Id: <20020305075815.D2623-100000@gamplex.bde.org> > Date: Tue, 05 Mar 2002 08:09:26 +1100 > > %%% > Index: kern_tc.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v > retrieving revision 1.116 > diff -u -2 -r1.116 kern_tc.c > --- kern_tc.c 26 Feb 2002 09:16:27 -0000 1.116 > +++ kern_tc.c 4 Mar 2002 21:08:03 -0000 > @@ -192,4 +252,14 @@ > gen = tc->tc_generation; > bintime2timeval(&tc->tc_offset, tvp); > + /* > + * XXX dummy_timecounter is now broken. Its tc_get_timecount > + * needs to be called before it works, and that doesn't > + * always happen naturally. In particular, we spin forever > + * here after booting with -d unless we do an unnatural call > + * here, since the screen timeout code is always run on entry > + * to ddb, and it calls here. > + */ > + if (gen == 0 && timecounter == &dummy_timecounter) > + (void)tc->tc_get_timecount(tc); > } while (gen == 0 || gen != tc->tc_generation); > } > %%% > > Bruce > > > In message <20020306054514.GA395@gzl>, qhwt@myrealbox.com writes: > >Hello. > >After upgrading to the kernel as of 2002-03-03 00:00:00(UTC), it stopped > >booting just after the message: > > > >Timecounter "i8254" frequency 1193182 Hz > > > >With some debugging printf()'s inserted, I found it was tc->tc_get_timecount() > >called from tco_delta() called just after the bcopy() in tc_windup(). > >So maybe the next place I have to look at is i8254_get_timecount(), which is in > >/sys/i386/isa/clock.c, but the last (effective) commit to this file is > >revision 1.180(at the end of January). > > > >I couldn't even drop into DDB; no response other than to power button. > >The last bootable(and stable so far) kernel is from 2002-02-24. > >I don't think this is caused by some leftover in the work directory > >since I always build kernels in a new empty directory under /usr/obj. > > > >Any (clue|fix)\? > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-current" in the body of the message > > > > -- > 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. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 9:33:15 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 46CE437B402 for ; Wed, 6 Mar 2002 09:33:09 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id EAA05919; Thu, 7 Mar 2002 04:33:05 +1100 Date: Thu, 7 Mar 2002 04:34:00 +1100 (EST) From: Bruce Evans X-X-Sender: To: Cc: Subject: Re: Won't boot after the commits to timecounter code In-Reply-To: <20020306134746.GA342@gzl> Message-ID: <20020307040247.T9712-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Mar 2002 qhwt@myrealbox.com wrote: > I inserted a pair of printf() inside mtx_lock_spin/mtx_unlock_spin in > i8254_get_timecount() and it kept printing the message while tc_init() > was blocked, so I think it's blocked at mtx_lock_spin in i8254_get_timecount() > when called from tc_init(), but not when called from somewhere else. > (maybe an interrupt handler?) Apparently you have KTR enabled (not the default in GENERIC). I think WITNESS+KTR already caused nasty recursion from the mtx_lock_spin, and we now get an endless loop when nanotime() is called with an invalid timecounter in the following call chain: tc_init -> tc_windup -> tco_delta -> i8254_get_timecount -> mtx_foo -> witness_foo -> ktr_foo -> nanotime, just after nanotime has somehow recursed back into i8254_get_timecounter without causing endless recursion! Try setting MTX_NOWITNESS in the initialization of clock_lock in i386/machdep.c. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 10:26:47 2002 Delivered-To: freebsd-current@freebsd.org Received: from scotch.ucf.ics.uci.edu (scotch.ucf.ics.uci.edu [128.195.23.4]) by hub.freebsd.org (Postfix) with ESMTP id 4059837B404 for ; Wed, 6 Mar 2002 10:26:44 -0800 (PST) Received: from whiskey.ucf.ics.uci.edu (whiskey.ucf.ics.uci.edu [128.195.23.9]) by scotch.ucf.ics.uci.edu (Postfix) with ESMTP id E27FF14D87 for ; Wed, 6 Mar 2002 10:26:43 -0800 (PST) Received: from whiskey.ucf.ics.uci.edu (localhost [127.0.0.1]) by whiskey.ucf.ics.uci.edu (8.10.2+Sun/8.10.2) with ESMTP id g26IQh111777 for ; Wed, 6 Mar 2002 10:26:43 -0800 (PST) Message-Id: <200203061826.g26IQh111777@whiskey.ucf.ics.uci.edu> To: freebsd-current@FreeBSD.ORG Reply-To: sjh@ucf.ics.uci.edu X-Message-Flag: Microsoft sucks, switch to UNIX Subject: smbfs in -current? Date: Wed, 06 Mar 2002 10:26:43 -0800 From: Seth Hettich Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The NOTES has no real info, and I don't see a man page... how is this supposed to work? I'm getting lots of: smbfs_smb.o: In function `smbfs_smb_lockandx': /usr/src/sys/i386/compile/SJH/../../../fs/smbfs/smbfs_smb.c(.text+0x90): undefin ed reference to `mb_put_uint8' I have both: options SMBFS options NETSMB in my config. Perhaps someone could give a little explanation, and add it to NOTES? -Seth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 10:44:48 2002 Delivered-To: freebsd-current@freebsd.org Received: from web14106.mail.yahoo.com (web14106.mail.yahoo.com [216.136.172.136]) by hub.freebsd.org (Postfix) with SMTP id 69F4737B404 for ; Wed, 6 Mar 2002 10:44:43 -0800 (PST) Message-ID: <20020306184443.14419.qmail@web14106.mail.yahoo.com> Received: from [68.6.92.237] by web14106.mail.yahoo.com via HTTP; Wed, 06 Mar 2002 10:44:43 PST Date: Wed, 6 Mar 2002 10:44:43 -0800 (PST) From: Galen Sampson Subject: SIGHUP during local package initialization To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello all, I have recently experienced some interesting behavior. During the boot process multiple programs seem to be receiving a SIGHUP. I have the stable version of samba installed from ports, and this causes nmbd to core dump during the machine startup. I have talked with the samba people about this and donated the core file to them. They did feel that it was strange that nmbd would be getting a signal during startup though. This problem was hard to track down. It seems that it programs only receive this SIGHUP sometimes. My only thought to the intermitant occurance is that something is SIGHUPing all of the processes, but sometimes local initialization starts before this happens. My /var/log/messages showed that samba and cyrus (my only programs started during init that were not part of the base system) both caught this signal. This should be a trivial task for me to track down. Unfortunately I'm having problems. My main method of searching was performing grep for "kill" in the /etc directory. This did not yield anything promising. I was wondering if someone could give me hints about tracking this problem down. regards, Galen __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 11:40:21 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id C2A3237B404 for ; Wed, 6 Mar 2002 11:40:15 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020306194015.NSVJ1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Wed, 6 Mar 2002 19:40:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA37595; Wed, 6 Mar 2002 11:37:15 -0800 (PST) Date: Wed, 6 Mar 2002 11:37:14 -0800 (PST) From: Julian Elischer To: Makoto Matsushita Cc: gnn@neville-neil.com, current@FreeBSD.org Subject: Re: gtags? htags? In-Reply-To: <20020306175942D.matusita@jp.FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It might be an idea if the kernel were kept separate because I find that the cross-reference is good but having kernel and userspace mixed up is a bit confusing.. On Wed, 6 Mar 2002, Makoto Matsushita wrote: > > gnn> They're needed for the tags: target in the kernel makefiles and > gnn> since I'd like to be able to browse code... > > Feel free to check . Both > 5-current and 4-stable code are HTMLed with GLOBAL daily. > > -- - > Makoto `MAR' Matsushita > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 13:15:36 2002 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0A0EC37B404 for ; Wed, 6 Mar 2002 13:15:21 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g26LFLm58298; Wed, 6 Mar 2002 13:15:21 -0800 (PST) (envelope-from dillon) Date: Wed, 6 Mar 2002 13:15:21 -0800 (PST) From: Matthew Dillon Message-Id: <200203062115.g26LFLm58298@apollo.backplane.com> To: current@freebsd.org Subject: buildworld problems, undefined reference to '__ntohl' and '__htonl' Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This has been broken for several days now, maybe longer. It would be nice if whoever broke it would fix it. -Matt Matthew Dillon cc -nostdlib -static -Ttext 0x0 -o loader.sym /usr/obj/FreeBSD/FreeBSD-current/src/sys/boot/i386/loader/../btx/lib/crt0.o main.o conf.o bcache.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o interp_parse.o load_aout.o load_elf.o ls.o misc.o module.o panic.o isapnp.o pnp.o interp_forth.o vers.o /usr/obj/FreeBSD/FreeBSD-current/src/sys/boot/i386/loader/../../ficl/libficl.a /usr/obj/FreeBSD/FreeBSD-current/src/sys/boot/i386/loader/../libi386/libi386.a /usr/obj/FreeBSD/FreeBSD-current/src/sys/boot/i386/loader/../../../../lib/libstand/libstand.a load_aout.o: In function `aout_loadfile': load_aout.o(.text+0x7c): undefined reference to `__ntohl' load_aout.o(.text+0x8d): undefined reference to `__ntohl' load_aout.o(.text+0x9e): undefined reference to `__ntohl' load_aout.o(.text+0xaf): undefined reference to `__ntohl' load_aout.o(.text+0xcf): undefined reference to `__ntohl' load_aout.o(.text+0xe0): more undefined references to `__ntohl' follow /usr/obj/FreeBSD/FreeBSD-current/src/sys/boot/i386/loader/../libi386/libi386.a(pxe.o): In function `pxe_enable': pxe.o(.text+0x4e1): undefined reference to `__htonl' pxe.o(.text+0x4f5): undefined reference to `__htonl' pxe.o(.text+0x50c): undefined reference to `__htonl' pxe.o(.text+0x523): undefined reference to `__htonl' /usr/obj/FreeBSD/FreeBSD-current/src/sys/boot/i386/loader/../../../../lib/libstand/libstand.a(nfs.o): In function `nfs_getrootfh': nfs.o(.text+0x4f): undefined reference to `__htonl' nfs.o(.text+0xd5): undefined reference to `__ntohl' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 14:15:23 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 8B16F37B493 for ; Wed, 6 Mar 2002 14:15:08 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g26MF2OJ085092; Wed, 6 Mar 2002 17:15:02 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200203062115.g26LFLm58298@apollo.backplane.com> References: <200203062115.g26LFLm58298@apollo.backplane.com> Date: Wed, 6 Mar 2002 17:15:01 -0500 To: Matthew Dillon , current@FreeBSD.ORG From: Garance A Drosihn Subject: Re: buildworld problems, undefined reference to '__ntohl' and '__htonl' Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 1:15 PM -0800 3/6/02, Matthew Dillon wrote: > This has been broken for several days now, maybe longer. It > would be nice if whoever broke it would fix it. Is this in a 'make buildworld' step? I just did one buildworld on i386, and it completed fine (src is cvsup'ed as of about noon). I'm doing a second buildworld right now (after having applied a patch I am trying to test), but I haven't gotten to the buildkernel or installkernel steps. So, if it's the buildworld step, then I can say that it's working fine for me at the moment. (with my kernel options, make options, etc..) -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 14:43:47 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 3864D37B405 for ; Wed, 6 Mar 2002 14:43:19 -0800 (PST) Received: (qmail 2591 invoked from network); 6 Mar 2002 22:43:17 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 6 Mar 2002 22:43:17 -0000 Received: from laptop.baldwin.cx (john@laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g26Mhdv03281; Wed, 6 Mar 2002 17:43:39 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200203051715.g25HFsk60359@apollo.backplane.com> Date: Wed, 06 Mar 2002 17:43:19 -0500 (EST) From: John Baldwin To: Matthew Dillon Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Cc: Bruce Evans , Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , FreeBSD current users , Julian Elischer Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 05-Mar-02 Matthew Dillon wrote: > >:> It makes no sense whatsoever to me to be told not to commit something >:> due to stale code that may not be quite compatible sitting in P4 that >:> you can't make work in any reasonable time frame. You should stop >:> trying to screw over my work and instead look to your own. You have >:> so many balls in the air constructed in a fine mesh that you can't seem >:> to accept a single change to your perfectly meshing subsystems, half >:> of which are going stale in P4. This is greatly restricting your >:> ability to consider deviation. >: >:*sigh* The only reason I'm not spending my cycles tracking down the >:preemption >:bugs so that preemption can go in is that I have decided that at the moment >:there is more gain to be found by doing actual locking work. This means that >:preemption will eventually go in, just Not Right Now. To that extent, I >:don't >:think premature optimizations based on observations of a kernel locked >:entirely >:by Giant that alter the API's preemption will change (and that were >:originally >:introduced when I committed all the bits of the preemption code that I could >:w/o breaking the kernel) should go in. > > Those are your cycles, not mine. Why should I be forced to sit on my > heals > for an unknown period of time (but so far 3 weeks waiting for the ucred > changes and 2 weeks waiting for critical_*()), twiddling my thumbs > wasting > MY cycles just because of your own scheduling issues? > > That's really the crux of this whole situation. I don't think it is > appropriate for you to impose your development methodology on me or > anyone else, and I most especially do not think it is appropriate for > you to arbitrarily hold off the hard work that I have done in order > to fit it into your schedule. > > I have said very clearly what I intend these critical_*() patches to > do. I have said, repeatedly, that I do not believe they would > intefere with your work in any significant manner. You have yet to > explain in any detail why you think they would. I have said, > repeatedly, that I am perfectly willing to work with you later on > when you ARE ready to move forward on your own work. > > That's the crux of the situation, John. I do not believe you have > the right to hold this work off, at least not based on any of the > explanations you have given so far. Have you read the paper I posted to arch? It quite clearly (I thought) explained the role of the critical_* and the cpu_critical_* in the preemption code. It should be rather obvious from that why I don't want the critical_* stuff to change from their current model. I also think that just as it is too early to optimize to light weight ithread switches (sparc64 is going to optimize all kthread switches, not just ithreads by using a more general approach, and we may do that on other arch's as well) it is too early to optimize and add complexity for certain API's when we aren't sure what effect they will really have on the final product. For example, right now Giant blocks almost all of the kernel so we are going to contest it on almost every case. Contesting involves grabbing the sched_lock which can result in executing the critical section implementation more than we will end up doing later. I would rather wait on optimizations until the system is farther along and we can judge what things really need optimization and which ones don't. Optimizations are usually a tradeoff as far as increased complexity vs. performance and I personally at least would like to keep things simple for the time being. However, I would not be opposed to the code if it fit into the design in the document I posted to arch. A couple of notes though based on a quick preliminary glance at the code: - The swi code has been changed to not be limited to a bitfield so that it can support an arbtirary number of swi's. Right now we still support a small number but we may end up with several netisr's for example. We also may move away from scheduling netisr's via swi_sched anyways and using a semaphore or some such instead. Presently your patch goes back to assuming a fixed number of SWI's. - More of a minor niglet that is easy to be fixed: you added MD fields to the MI pcpu bits of struct pcpu. MD fields belong in the PCPU_MD_FIELDS macro in sys/i386/include/pcpu.h. If you intend for the fields to be MI, then that is more of a problem as it assumes too much about interrupts for different platforms. Alpha interrupts will not easily fit into a simple bitmask for example. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 15:16:50 2002 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3D1FE37B404; Wed, 6 Mar 2002 15:16:41 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g26NGeF59131; Wed, 6 Mar 2002 15:16:40 -0800 (PST) (envelope-from dillon) Date: Wed, 6 Mar 2002 15:16:40 -0800 (PST) From: Matthew Dillon Message-Id: <200203062316.g26NGeF59131@apollo.backplane.com> To: John Baldwin Cc: Bruce Evans , Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , FreeBSD current users , Julian Elischer Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Have you read the paper I posted to arch? It quite clearly (I thought) :explained the role of the critical_* and the cpu_critical_* in the preemption :code. It should be rather obvious from that why I don't want the critical_* I'm sorry John, I have no idea what you are refering to here. You have given no reference that I can lookup... you have hundreds of postings on arch. Why don't you just post the reasoning? Nothing I have seen anywhere so far would create an issue. I've heard you repeatedly reference documents but I have no idea which documents you are talking about or which portion of said documents you are refering to. So instead of continuing to post ghost references why don't you just lay the problem out as you see it in this thread and explain why you do not believe the critical section work I am doing would work with it. :stuff to change from their current model. I also think that just as it is too :early to optimize to light weight ithread switches (sparc64 is going to :optimize all kthread switches, not just ithreads by using a more general We have very different development models, and different priorities. I'm not sure why you are attempting to impose your development model and priorities on me. This is the work I want to do. It's my time here, not yours, and if you believe that the work will make your job harder in some future unspecified commit then you have only to bring up the issue down the road when you are actually ready to work on that future unspecified commit and we can work it out. But I don't think it's appropriate for you to impose such a strict set of requirements based on work that does not exist in -current anywhere as far as I can tell. :approach, and we may do that on other arch's as well) it is too early to :optimize and add complexity for certain API's when we aren't sure what effect :they will really have on the final product. For example, right now Giant :blocks almost all of the kernel so we are going to contest it on almost every :case. Contesting involves grabbing the sched_lock which can result in :executing the critical section implementation more than we will end up doing :later. I would rather wait on optimizations until the system is farther along :and we can judge what things really need optimization and which ones don't. Again, different development models. I see a set of APIs being severely misused by commits, the most recent being Peter's-that-he-backed-out, and I see a considerable need down the road for an efficient critical section API. You may not be interested in doing the work on these now but you != me. This work is my interest. Again, I don't understand why you are trying to impose your personal tastes on me. :A couple of notes though based on a quick preliminary glance at the code: : :- The swi code has been changed to not be limited to a bitfield so that it can : support an arbtirary number of swi's. Right now we still support a small : number but we may end up with several netisr's for example. We also may move : away from scheduling netisr's via swi_sched anyways and using a semaphore or : some such instead. Presently your patch goes back to assuming a fixed number : of SWI's. I see an swi scheduler, which has nothing to do with the critical section work I have done. If there is other SWI stuff I don't see it in the -current tree. Nor does the work I have done in any way prevent the use of or in any way make it more difficult to use a list-based SWI queueing system instead of a bitmap. The bitmap stuff in my critical section patch only applies to i386... it's a specific implementation for soft and statclock IPI forwarding for the deferred case, nothing more. I didn't even bother to integrate AST (saving that for later work). It does not in any way prevent one from redoing that bit of code or even simply keeping the code and adding an SWI queue feature - something that could in fact be done either MD or MI depending on the needs of the architectures. If you believe there to be a problem here, perhaps explaining the SWI mechanism you are refering to would help. I am confident that it would not impose anything incompatible with the work I've done. :- More of a minor niglet that is easy to be fixed: you added MD fields to the MI : pcpu bits of struct pcpu. MD fields belong in the PCPU_MD_FIELDS macro in : sys/i386/include/pcpu.h. If you intend for the fields to be MI, then that is : more of a problem as it assumes too much about interrupts for different : platforms. Alpha interrupts will not easily fit into a simple bitmask for : example. : :-- : :John Baldwin <>< http://www.FreeBSD.org/~jhb/ These fields do in fact belong in MD PCPU_MD_FIELDS. I didn't notice it, perhaps because there is not a single line of comment in sys/pcpu.h explaining what PCPU_MD_FIELDS was. There is in the i386 specific pcpu.h, but not in the main sys/pcpu.h header file and there should have been. This is about a 10 second change. I don't consider it all that significant and I will be happy to do it in the stage-2 commit. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 15:22:57 2002 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 9F58A37B405 for ; Wed, 6 Mar 2002 15:22:51 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g26NMhK59220; Wed, 6 Mar 2002 15:22:43 -0800 (PST) (envelope-from dillon) Date: Wed, 6 Mar 2002 15:22:43 -0800 (PST) From: Matthew Dillon Message-Id: <200203062322.g26NMhK59220@apollo.backplane.com> To: Garance A Drosihn Cc: current@FreeBSD.ORG Subject: Re: buildworld problems, undefined reference to '__ntohl' and '__htonl' References: <200203062115.g26LFLm58298@apollo.backplane.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I think it may just be my-bad. The kernel source got out of sync with the main tree. I just cvs updated the whole smelly pot and buildworld works just fine. Sorry for the false alarm! -Matt : :At 1:15 PM -0800 3/6/02, Matthew Dillon wrote: :> This has been broken for several days now, maybe longer. It :> would be nice if whoever broke it would fix it. : :Is this in a 'make buildworld' step? I just did one buildworld :on i386, and it completed fine (src is cvsup'ed as of about noon). :I'm doing a second buildworld right now (after having applied a :patch I am trying to test), but I haven't gotten to the buildkernel :or installkernel steps. : :So, if it's the buildworld step, then I can say that it's working :fine for me at the moment. (with my kernel options, make options, :etc..) : :-- :Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 15:36:35 2002 Delivered-To: freebsd-current@freebsd.org Received: from ldc.ro (ldc-gw.rdsnet.ro [213.157.163.8]) by hub.freebsd.org (Postfix) with SMTP id 9455A37B417 for ; Wed, 6 Mar 2002 15:36:23 -0800 (PST) Received: (qmail 54337 invoked by uid 666); 6 Mar 2002 23:36:20 -0000 Date: Thu, 7 Mar 2002 01:36:20 +0200 From: Alex Popa To: David O'Brien Cc: freebsd-current@freebsd.org Subject: Re: Should 4.5-STABLE -> 5.0-CURRENT work? Message-ID: <20020307013620.A47627@ldc.ro> References: <20020306100019.A208@ldc.ro> <20020306003628.A6868@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020306003628.A6868@dragon.nuxi.com>; from obrien@freebsd.org on Wed, Mar 06, 2002 at 12:36:28AM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Mar 06, 2002 at 12:36:28AM -0800, David O'Brien wrote: > On Wed, Mar 06, 2002 at 10:00:19AM +0200, Alex Popa wrote: > > cc -O -pipe -march=pentiumpro -funsigned-char -I. -I/usr/src/usr.bin/awk/../../contrib/one-true-awk /usr/src/usr.bin/awk/../../contrib/one-true-awk/maketab.c -o maketab > > ./maketab > proctab.c > > /usr/libexec/ld-elf.so.1: Shared object "libc.so.5" not found > > *** Error code 1 > > > > Stop in /usr/src/usr.bin/awk. > > *** Error code 1 > > (*sigh*) Fixed. Thank you, that worked for me! There were some problems during installworld, with sh getting killed during installworld, in chpass on: [ ! -e /usr/bin/chpass ] || chflags noschg /usr/bin/chpass || true sh was getting killed w/ signal 10 or 11, I cannot remember. However, I just removed the setuid binaries in /usr/bin and /usr/sbin, then everything worked. Also got some problems with sh at kernel "make", just before the linking part. Solved by replacing /bin/sh with /usr/local/bin/bash during kernel build and install. This was with the old kernel I mentioned in my first message, so world and kernel were out of sync. All seems to work OK w/ the -release kernel and world (until now, at least, built two other kernels, and used X w/ no apparent problems). Thank you, everybody! You are doing a great job! Alex (now a happy 5.0-CURRENT user) ------------+------------------------------------------ Alex Popa, | "Artificial Intelligence is razor@ldc.ro| no match for Natural Stupidity" ------------+------------------------------------------ "It took the computing power of three C-64s to fly to the Moon. It takes a 486 to run Windows 95. Something is wrong here." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 15:41: 0 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.dmz.davidcoulson.net (technoir.demon.co.uk [194.222.178.203]) by hub.freebsd.org (Postfix) with SMTP id 359AA37B43B for ; Wed, 6 Mar 2002 15:40:32 -0800 (PST) Received: (qmail 29233 invoked by uid 507); 6 Mar 2002 23:40:32 -0000 Date: Wed, 6 Mar 2002 23:40:31 +0000 From: Michael McGoldrick To: current@freebsd.org Subject: binutils Message-ID: <20020306234031.A28557@linuxdriven.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I recently rebuilt Mozilla and kdebase on my (very up to date) current box. Since then, both moz and most KDE apps have been very crashy. I think this is probably something to do with binutils, but is there any way I can check? and are there any workarounds? Additional info: x86 machine, world/kernel last built from sources cvsupped on 6 March 16:34:35 GMT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 16:40:23 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 411BA37B41B for ; Wed, 6 Mar 2002 16:40:09 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020307004008.YGNL1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 7 Mar 2002 00:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA38766; Wed, 6 Mar 2002 16:21:11 -0800 (PST) Date: Wed, 6 Mar 2002 16:21:09 -0800 (PST) From: Julian Elischer To: FreeBSD current users Cc: Mckusick@mckusick.com Subject: Contemplating THIS change to signals. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maybe this should be in -arch.. I couldn;t make my mind up, but.. There is some behaviour in signals which seems 1/ un-neccesary 2/ potentially dangerous. in addition it is 3/ Definitly incompatible with KSEs. I am hoping that someone can give me a good reason why it is done, and failing that, I'm hoping people can give comments on my thoughts. The behavious in question was inherrited from BSD4.4-LITE2 When the sleep code (tsleep,msleep, cv{stuff}) checks to see if there is a pending signal that might cause the sleep to abort, it calls CURSIG() which calls issignal, which in turn might decide to actually suspend the process. (if the user hit ^Z for example) This is fine when CURSIG is called from userret(), because we are on the user boundary, however calling it from the sleep() call seems a rather UN-NICE thing to do. One could argue that it is safe because you are not allowed to sleep while holding resources (um is it not possible to sleep while holding a vnode?) but it seems that it is possible to hit ^Z at teh right moment while something is holding some resource (during what it expects to be a very short term sleep,) and end up blocking the whole system. I would argue that a process can be considered to be suspended even while it is running in kernel space. My definition of a suspended process would be one that id not running any user code. it is not making any headway on the userland program. This I put it to the group that it is sufficient to only suspend a process when it is crossing the user boundary. (returning to user space) My suggestion is to remove teh code in issignal() that perfoms the blocking actions and create a separate function that does that action. I would then call that function from userret() immediatly after the call to issignal(). The result would be that suspended processes would still not reach userland, but processes would not have to option of suspending indefinitly at sleep(). The signal would still cut short the sleep, but the process would be allowed to proceed to the user boundary, at which point it would be suspended as before. If anyone has any reasons they think this is a bad idea, then please speak up. Neithe Matt (Dillon) nor I can see that stopping in msleep is required, and both of us are in fact un-easy with it. In a THREADED world it gets even more complicated, because the SUSPENDED state is a PER_PROCESS state, which means that you are not suspented until ALL THERADS have left userland and been counted as 'suspended'. Having some threads stopped 'near' msleep and others stopped at the userland boundary is asking for trouble in my opinion. I can not think of any downside to making the suspension (whether from ptrace, or a signal) only occur at the user boundary. If I hear NO arguments I'll take it that no-one can think of any reasons to not change the code. If yuo have a reason PLEASE speak up so that we can discuss it and try figure out whether it is real or can be gotten around in some manner. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 17: 0:27 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 17FC037B41D; Wed, 6 Mar 2002 17:00:17 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020307010016.VHUA2626.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 7 Mar 2002 01:00:16 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA38859; Wed, 6 Mar 2002 16:51:05 -0800 (PST) Date: Wed, 6 Mar 2002 16:51:04 -0800 (PST) From: Julian Elischer To: "Jeroen C.van Gelderen" Cc: Matthew Dillon , John Baldwin , Bruce Evans , Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , FreeBSD current users Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Mar 2002, Jeroen C.van Gelderen wrote: > > Search for "paper John Baldwin" and find link 6: A good start though incomplete. Unfortunate that it took such a fight to get it to be written. Hopefully it's existance can prevent soem further bloodshed. Is it possible for other people to add to this or is it a closed document? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 17:40: 6 2002 Delivered-To: freebsd-current@freebsd.org Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143]) by hub.freebsd.org (Postfix) with ESMTP id D2FF337B402 for ; Wed, 6 Mar 2002 17:40:03 -0800 (PST) Received: from localhost qhwt@smtp-send.myrealbox.com [61.198.168.193] by smtp-send.myrealbox.com with Novell NIMS $Revision: 2.88 $ on Novell NetWare; Wed, 06 Mar 2002 18:40:01 -0700 Date: Thu, 7 Mar 2002 10:40:07 +0900 From: qhwt@myrealbox.com To: current@FreeBSD.ORG Subject: Re: Won't boot after the commits to timecounter code Message-ID: <20020307014007.GA622@gzl> References: <20020306134746.GA342@gzl> <20020307040247.T9712-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020307040247.T9712-100000@gamplex.bde.org> User-Agent: Mutt/1.5.0i X-Dispatcher: imput version 20000228(IM140) Lines: 38 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Mar 07, 2002 at 04:34:00AM +1100, Bruce Evans wrote: > On Wed, 6 Mar 2002 qhwt@myrealbox.com wrote: > > > I inserted a pair of printf() inside mtx_lock_spin/mtx_unlock_spin in > > i8254_get_timecount() and it kept printing the message while tc_init() > > was blocked, so I think it's blocked at mtx_lock_spin in i8254_get_timecount() > > when called from tc_init(), but not when called from somewhere else. > > (maybe an interrupt handler?) > > Apparently you have KTR enabled (not the default in GENERIC). I think > WITNESS+KTR already caused nasty recursion from the mtx_lock_spin, and > we now get an endless loop when nanotime() is called with an invalid > timecounter in the following call chain: > > tc_init -> tc_windup -> tco_delta -> i8254_get_timecount -> mtx_foo -> > witness_foo -> ktr_foo -> nanotime, > > just after nanotime has somehow recursed back into i8254_get_timecounter > without causing endless recursion! Yes, I have the following KTR options enabled (I think I brought this from NOTES about a year before): options KTR options KTR_EXTEND options KTR_ENTRIES=1024 options KTR_COMPILE=0x3fffff options KTR_MASK=0x201208 options KTR_CPUMASK=0x3 but WITNESS is commented out. > Try setting MTX_NOWITNESS in the initialization of clock_lock in > i386/machdep.c. O.k., I'll try this(but does it affect a kernel without WITNESS?), then try a kernel without KTR options. Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 18: 1:54 2002 Delivered-To: freebsd-current@freebsd.org Received: from castle.jp.FreeBSD.org (castle.jp.FreeBSD.org [210.226.20.15]) by hub.freebsd.org (Postfix) with ESMTP id C93AC37B400 for ; Wed, 6 Mar 2002 18:01:51 -0800 (PST) Received: from localhost (localhost [::1]) by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet6 id g2721eP61167; Thu, 7 Mar 2002 11:01:40 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Cc: gnn@neville-neil.com, current@FreeBSD.org In-Reply-To: References: <20020306175942D.matusita@jp.FreeBSD.org> X-User-Agent: Mew/1.94.2 XEmacs/21.5 (bamboo) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 10 From: Makoto Matsushita To: julian@elischer.org Subject: Re: gtags? htags? Date: Thu, 07 Mar 2002 11:01:37 +0900 Message-Id: <20020307110137U.matusita@jp.FreeBSD.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG julian> It might be an idea if the kernel were kept separate because julian> I find that the cross-reference is good but having kernel and userspace julian> mixed up is a bit confusing.. Hmm, maybe it's a good idea about userland/kernel separation. I'll try it later (maybe this evening or this weekend). -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 19:18:48 2002 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3D6ED37B400; Wed, 6 Mar 2002 19:18:45 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g273IBB60433; Wed, 6 Mar 2002 19:18:11 -0800 (PST) (envelope-from dillon) Date: Wed, 6 Mar 2002 19:18:11 -0800 (PST) From: Matthew Dillon Message-Id: <200203070318.g273IBB60433@apollo.backplane.com> To: "Jeroen C.van Gelderen" Cc: John Baldwin , Bruce Evans , Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , FreeBSD current users , Julian Elischer Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Search for "paper John Baldwin" and find link 6: : :http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=199282+204026+/usr/local/www/db/ :text/2002/freebsd-arch/20020303.freebsd-arch : :The actual paper is at: : http://www.FreeBSD.org/~jhb/smpng/design/article.{ps,pdf} : :-J :-- :Jeroen C. van Gelderen - jeroen@vangelderen.org Ok... I've read it. The sections on interrupts and critical sections are fully compatible with my patch. The one section... basically the last sentence of the last paragraph, is exactly the piece that my patch cleans up and makes more flexible. Instead of requiring that cpu_critical_*() always be used for the initial critical_enter() my patch makes it optional, and for I386 I use that flexibility to allow critical_*() to NOT have to call cpu_critical_*(). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 20:28:26 2002 Delivered-To: freebsd-current@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 39BB437B400; Wed, 6 Mar 2002 20:28:23 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.6/8.11.5) with ESMTP id g274TlI51515; Wed, 6 Mar 2002 21:29:47 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200203070429.g274TlI51515@aslan.scsiguy.com> To: Matthew Dillon Cc: John Baldwin , Bruce Evans , Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , FreeBSD current users , Julian Elischer Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem In-Reply-To: Your message of "Wed, 06 Mar 2002 15:16:40 PST." <200203062316.g26NGeF59131@apollo.backplane.com> Date: Wed, 06 Mar 2002 21:29:47 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >:stuff to change from their current model. I also think that just as it >:is too early to optimize to light weight ithread switches (sparc64 is >:going to optimize all kthread switches, not just ithreads by using a more >:general > > We have very different development models, and different priorities. [...] This same issue came up at the BSDCon developers conference in regard to ithreads. Is it better to optimize some bit of code because it is the fun and interesting thing to do, or to build a simple, yet stable and easily verified foundation, that we can later optimize in a controlled manner? This is not about whether these particular changes are correct. The concern is that they may contain a subtle bug that makes it difficult to verify other portions of the system. I don't think anyone believes that we are at a point in current where we can convince ourselves that the system does work, no matter how slowly, in all cases. If we start to optimize before we reach such a point, how will we ever determine the robustness of the system? An optimization put in place today may have a bug or may expose a bug somewhere else in the system. In the current situation it is difficult to know which scenario is true (bug or side-effect) because we don't have a solid, verified, foundation. My 2 cents? Work with John to get the APIs that affect this particular code stable. That means discussion and perhaps that discussion will take some time (if this blow-up hadn't occurred the discussion would already be over now ;-). Once the APIs are in place, commit your code in a format that makes it completely optional, just like your Giant lock optimizations. This means that those interested in validating and determining the impact of your code can easily do so by flipping a switch. Those who would rather debug their own subsystem problems in a slower, but simpler, environment can do so too. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 20:39:58 2002 Delivered-To: freebsd-current@freebsd.org Received: from ss14.estore.co.jp (ss14.estore.co.jp [210.239.44.49]) by hub.freebsd.org (Postfix) with SMTP id 270AE37B416 for ; Wed, 6 Mar 2002 20:39:51 -0800 (PST) Received: (qmail 27071 invoked by alias); 7 Mar 2002 13:39:48 +0900 Received: (qmail 26583 invoked from network); 7 Mar 2002 13:39:22 +0900 Received: from unknown (HELO localhost) (218.217.3.232) by 0 with SMTP; 7 Mar 2002 13:39:22 +0900 From: sales@likefinance.com To: freebsd-current@freebsd.org Subject: =?ISO-2022-JP?B?GyRCOS05cCEqISpBNDlxPzY5fk07O3E8QjtcQ2YhKhsoQg==?= =?ISO-2022-JP?B?GyRCISobKEI=?= Date: Fri, 07 Mar 2003 13:35:43 +0900 X-Sender: opt0459-sales@mail.likefinance.com Message-Id: <20030307044045260.00000.0.opt0459-sales@ap.mail.likefinance.com> X-Mailer: Douhou@Mail version 1.0.0.1/1.0.0.1 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG $B9-9p!*(B $BFMA3$9$_$^$;$s!#(B $B5^$J=PHq$G$*:$$j$NJ}$*NO$K$J$j$^$9!#(B $B%i%$%/%U%!%$%J%s%9!!ET!J(B1$B!K(B22433 $B#2#4;~4V$5$l$J$$J}$O(B $B$3$A$i$^$G$*4j$$CW$7$^$9!#(B $BO"Mm@h(B office@likefinance.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 21:30:57 2002 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0B0E937B417; Wed, 6 Mar 2002 21:30:53 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g275UHi64046; Wed, 6 Mar 2002 21:30:17 -0800 (PST) (envelope-from dillon) Date: Wed, 6 Mar 2002 21:30:17 -0800 (PST) From: Matthew Dillon Message-Id: <200203070530.g275UHi64046@apollo.backplane.com> To: "Justin T. Gibbs" Cc: John Baldwin , Bruce Evans , Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , FreeBSD current users , Julian Elischer Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem References: <200203070429.g274TlI51515@aslan.scsiguy.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :This same issue came up at the BSDCon developers conference in :regard to ithreads. Is it better to optimize some bit of code :because it is the fun and interesting thing to do, or to build a simple, :yet stable and easily verified foundation, that we can later optimize :in a controlled manner? This is not about whether these particular :changes are correct. The concern is that they may contain a subtle :bug that makes it difficult to verify other portions of the system. :... :-- :Justin Well now hold on a second here Justin. Did you even look at the patch? Or are you just making a generalization that is totally unrelated to the patch? Perhaps you are unaware of the sysctl instrumentation that allows the interrupts-enabled-during-critical-section mechanism to be turned on and off on a whim? Perhaps you are unaware that this patch is not JUST an optmization. Far from it, it solves a number of what I consider to be critical issues. For example, it solves the IPI deadlock problem, and it allows us to cleanup some fairly aweful hacks in the code, e.g. in fork_exit(). I'm all for a discussion, but I would prefer it if the discussion were based on the actual work that I am trying to get committed and not some incorrect generalization that is being used to justify some other approach. None of this is secret. I've stated these facts very clearly a half dozen times now AND in the commit message. Don't ignore it or assume that I am some beginner who's just throwing random commits in and destabilizing the tree. I have gone to great lengths to do the precise opposite of that. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Mar 6 21:34:30 2002 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 8F71037B429; Wed, 6 Mar 2002 21:34:17 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g275Xii64069; Wed, 6 Mar 2002 21:33:44 -0800 (PST) (envelope-from dillon) Date: Wed, 6 Mar 2002 21:33:44 -0800 (PST) From: Matthew Dillon Message-Id: <200203070533.g275Xii64069@apollo.backplane.com> To: "Justin T. Gibbs" Cc: John Baldwin , Bruce Evans , Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , FreeBSD current users , Julian Elischer Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem References: <200203070429.g274TlI51515@aslan.scsiguy.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :My 2 cents? Work with John to get the APIs that affect this particular :code stable. That means discussion and perhaps that discussion will :take some time (if this blow-up hadn't occurred the discussion :would already be over now ;-). Once the APIs are in place, commit your :code in a format that makes it completely optional, just like your Giant :lock optimizations. This means that those interested in validating :and determining the impact of your code can easily do so by flipping :a switch. Those who would rather debug their own subsystem problems :in a slower, but simpler, environment can do so too. : :-- :Justin The API is intended for the stage-2 commit. The stage-1 commit is intended to do all the 'hard stuff' in as straightforward a manner as possible. The sysctl / option you talk about here existed in my patch set 2 and a half weeks ago. I really wish you people would at least read the patch and commit message before you comment on it. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Mar 7 0:35:37 2002 Delivered-To: freebsd-current@freebsd.org Received: from gate.soum.co.jp (gate.soum.co.jp [202.221.40.2]) by hub.freebsd.org (Postfix) with ESMTP id 9711337B404; Thu, 7 Mar 2002 00:35:27 -0800 (PST) Received: from force.soum.co.jp (force.soum.co.jp [IPv6:3ffe:501:80a:1:a00:20ff:fef0:4c9c]) by gate.soum.co.jp (8.12.2/8.12.2) with ESMTP id g278ZQO0006032; Thu, 7 Mar 2002 17:35:26 +0900 (JST) (envelope-from fujita@soum.co.jp) Received: from vanilla.soum.co.jp (vanilla.soum.co.jp [3ffe:501:80a:1:202:b3ff:fe98:8115]) by force.soum.co.jp (8.11.6/3.7W-2001122804) with ESMTP id g278ZPS18952; Thu, 7 Mar 2002 17:35:25 +0900 (JST) Received: from localhost (localhost [::1]) by vanilla.soum.co.jp (Postfix) with ESMTP id 2CB273F58; Thu, 7 Mar 2002 17:35:25 +0900 (JST) Date: Thu, 07 Mar 2002 17:35:24 +0900 (JST) Message-Id: <20020307.173524.71090447.fujita@soum.co.jp> To: freebsd-current@FreeBSD.ORG Cc: freebsd-mobile@FreeBSD.ORG Subject: bus_alloc_resouce() failure for OPTi 82C861 From: FUJITA Kazutoshi X-PGP-PublicKey: http://www.soum.co.jp/~fujita/fujita-GnuPG-publickey.txt X-PGP-FingerPrint: 9956 2ECE 7E7D B425 EC2D D49E FEBB 3C5F 2C34 1ECA Organization: SOUM Corporation, JAPAN X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 =?iso-2022-jp?B?KBskQjgtTFobKEIp?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi there, I installed -CURRENT on my old PC(ThinkPad235 aka Chandra2), but its USB device doesn't work. (it works on Windows environment) [boot message] ohci0: irq 10 at device 5.0 on pci0 ohci0: Could not map memory device_probe_and_attach: ohci0 attach returned 6 in source code, sys/pci/ohci_pci.c rid = PCI_CBMEM; sc->io_res = bus_alloc_resource(self, SYS_RES_MEMORY, &rid, 0, ~0, 1, RF_ACTIVE); if (!sc->io_res) { device_printf(self, "Could not map memory\n"); return ENXIO; } It seems the function bus_alloc_resource() returns NULL. How can I avoid this failure? TIA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Mar 7 0:37:32 2002 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 3B0C037B402; Thu, 7 Mar 2002 00:37:25 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g278bOi90443; Thu, 7 Mar 2002 01:37:24 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g278bNL91517; Thu, 7 Mar 2002 01:37:23 -0700 (MST) (envelope-from imp@village.org) Date: Thu, 07 Mar 2002 01:37:13 -0700 (MST) Message-Id: <20020307.013713.112719491.imp@village.org> To: fujita@soum.co.jp Cc: freebsd-current@FreeBSD.ORG, freebsd-mobile@FreeBSD.ORG Subject: Re: bus_alloc_resouce() failure for OPTi 82C861 From: "M. Warner Losh" In-Reply-To: <20020307.173524.71090447.fujita@soum.co.jp> References: <20020307.173524.71090447.fujita@soum.co.jp> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020307.173524.71090447.fujita@soum.co.jp> FUJITA Kazutoshi writes: : Hi there, : : I installed -CURRENT on my old PC(ThinkPad235 aka Chandra2), : but its USB device doesn't work. : (it works on Windows environment) : : [boot message] : ohci0: irq 10 at device 5.0 on pci0 : ohci0: Could not map memory : device_probe_and_attach: ohci0 attach returned 6 : : : in source code, sys/pci/ohci_pci.c : : rid = PCI_CBMEM; : sc->io_res = bus_alloc_resource(self, SYS_RES_MEMORY, &rid, : 0, ~0, 1, RF_ACTIVE); : if (!sc->io_res) { : device_printf(self, "Could not map memory\n"); : return ENXIO; : } : : It seems the function bus_alloc_resource() returns NULL. : : How can I avoid this failure? You can't. However, you can work around it like the pccbb driver does. It would be better if these things were handled in the pci bus layer, but someone would need to implement that. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Mar 7 0:52:22 2002 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id A6C9937B431 for ; Thu, 7 Mar 2002 00:52:12 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g278qBi90533 for ; Thu, 7 Mar 2002 01:52:11 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g278qAL91624 for ; Thu, 7 Mar 2002 01:52:10 -0700 (MST) (envelope-from imp@village.org) Date: Thu, 07 Mar 2002 01:52:00 -0700 (MST) Message-Id: <20020307.015200.35223772.imp@village.org> To: current@FreeBSD.ORG Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem From: "M. Warner Losh" In-Reply-To: <200203062316.g26NGeF59131@apollo.backplane.com> References: <200203062316.g26NGeF59131@apollo.backplane.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <200203062316.g26NGeF59131@apollo.backplane.com> Matthew Dillon writes: : We have very different development models, and different priorities. : I'm not sure why you are attempting to impose your development model : and priorities on me. This is the work I want to do. It's my time : here, not yours, and if you believe that the work will make your job : harder in some future unspecified commit then you have only to bring : up the issue down the road when you are actually ready to work on : that future unspecified commit and we can work it out. But I don't : think it's appropriate for you to impose such a strict set of requirements : based on work that does not exist in -current anywhere as far as I can : tell. While your time is your time, it isn't your tree. It isn't my tree. The tree is a shared resource that we all must respect. There are times that it is reasonable to have restrictions on what can go into the tree. Since smpng is being coordinated amoung several developers in the tree, there are some restrictions that may come with that. I think that such restrictions are reasonable and the price of doing business in a shared resource. I think that's a fundamental decision about the tree that has been made that your development model is at odds with and the source of much of the current dispute over commit or not to commit the changes. In the past there have been a number of restrictions on what can and can't go into the tree. I needn't enumerate them here, but I will add that there have been times where special restrictions were in place that weren't in place at other times. We're entering the glide path to 5.0, so I would expect there to be more such restrictions coming from the release engineer and maybe others as we move towards that release. I'm not saying that your patches necessarily fall under these restrictions, but I am saying that to assert that your time is yours and therefore anything that you do can go into the tree is a false premise. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Mar 7 1:36:53 2002 Delivered-To: freebsd-current@freebsd.org Received: from wint.itfs.nsk.su (wint.itfs.nsk.su [212.20.32.43]) by hub.freebsd.org (Postfix) with ESMTP id 92BE437B431 for ; Thu, 7 Mar 2002 01:36:34 -0800 (PST) Received: from wint.itfs.nsk.su (localhost [127.0.0.1]) by wint.itfs.nsk.su (8.12.2/8.12.2) with ESMTP id g279aRHv000688 for ; Thu, 7 Mar 2002 15:36:27 +0600 (NOVT) (envelope-from nnd@wint.itfs.nsk.su) Received: (from nnd@localhost) by wint.itfs.nsk.su (8.12.2/8.12.2/Submit) id g279aRut000687; Thu, 7 Mar 2002 15:36:27 +0600 (NOVT) Date: Thu, 7 Mar 2002 15:36:27 +0600 (NOVT) Message-Id: <200203070936.g279aRut000687@wint.itfs.nsk.su> From: nnd@mail.nsk.ru (Nickolay Dudorov) To: current@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libcrypt crypt-md5.c crypt.c crypt.h misc.c src/secure/lib/libcrypt blowfish.c blowfish.h crypt-blowfish.c crypt-des.c In-Reply-To: <200203061718.g26HI9060426@freefall.freebsd.org> User-Agent: tin/1.5.11-20011225 ("Darkcell") (UNIX) (FreeBSD/5.0-CURRENT (i386)) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <200203061718.g26HI9060426@freefall.freebsd.org> Mark Murray wrote: > markm 2002/03/06 09:18:09 PST > > Modified files: > lib/libcrypt crypt-md5.c crypt.c crypt.h misc.c > secure/lib/libcrypt blowfish.c blowfish.h crypt-blowfish.c > crypt-des.c > Log: > No functional change, but big code cleanup. WARNS, lint(1) and style(9). This comment is false. On my -CURRENT system with this commit in place 'passwd' and 'login'/'su' commands loops forever computing MD5 password. After reverting crypt-md5.c to rev. 1.8 all thouse commands work as always. Was this cleanup tested ? N.Dudorov > > Revision Changes Path > 1.9 +47 -47 src/lib/libcrypt/crypt-md5.c > 1.22 +9 -7 src/lib/libcrypt/crypt.c > 1.7 +2 -2 src/lib/libcrypt/crypt.h > 1.3 +6 -5 src/lib/libcrypt/misc.c > 1.3 +13 -110 src/secure/lib/libcrypt/blowfish.c > 1.2 +13 -13 src/secure/lib/libcrypt/blowfish.h > 1.3 +26 -59 src/secure/lib/libcrypt/crypt-blowfish.c > 1.16 +40 -34 src/secure/lib/libcrypt/crypt-des.c > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Mar 7 2: 5:29 2002 Delivered-To: freebsd-current@freebsd.org Received: from sunic.sunet.se (sunic.sunet.se [192.36.125.2]) by hub.freebsd.org (Postfix) with ESMTP id D51DA37B402 for ; Thu, 7 Mar 2002 02:05:22 -0800 (PST) Received: from irfu.se (sol.irfu.se [130.238.30.6]) by sunic.sunet.se (8.9.3/8.9.3) with SMTP id LAA20695 for ; Thu, 7 Mar 2002 11:05:21 +0100 (MET) Received: from jet.irfu.se by irfu.se (SMI-8.6/SMI-SVR4) id LAA07463; Thu, 7 Mar 2002 11:04:26 +0100 Received: from jet (localhost [::1]) by jet.irfu.se (8.11.6+Sun/8.11.6) with ESMTP id g27A5Iu18167 for ; Thu, 7 Mar 2002 11:05:19 +0100 (MET) Content-Type: text/plain; charset="us-ascii" From: Yuri Khotyaintsev Organization: Swedish Institute of Space Physics To: freebsd-current@FreeBSD.ORG Subject: cardbus problem Date: Thu, 7 Mar 2002 11:05:17 +0100 X-Mailer: KMail [version 1.3.99] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200203071105.17725.yuri@irfu.se> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi! I have xl0: watchdog timeout on my 3Com cardbus card after updating kernel recently. Everything seems to be OK during boot, but xl0: watchdog timeout starts directly after ifconfig, and makes network incredibly slow. boot -v will not boot at all, it stops somewhere around cardbus_attach_card. It seems the problem is in recent changes to sys/dev/cardbus, because taking the August version of sys/dev/cardbus/* files resolved the problem. Further investigation is needed. I attach dmesg output below. -- Yuri Khotyaintsev Swedish Institute of Space Physics, Uppsala Division, Box 537, S-75121 Uppsala Copyright (c) 1992-2002 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.0-CURRENT #0: Mon Mar 4 23:11:04 CET 2002 root@jazz.student.uu.se:/usr/src/sys/i386/compile/JAZZ Preloaded elf kernel "/boot//kernel/kernel" at 0xc0454000. Preloaded elf module "/boot//kernel/acpi.ko" at 0xc04540ac. Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x66a Stepping = 10 Features=0x183f9ff real memory = 100597760 (98240K bytes) avail memory = 93360128 (91172K bytes) Pentium Pro MTRR support enabled Using $PIR table, 9 entries at 0xc00fdf30 ACPI-0567: *** Warning: Reference BAT0 at AML 1276 not found ACPI-0567: *** Warning: Reference BAT1 at AML 127a not found apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface acpi0: Other PM system enabled. pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pcm0: port 0xf800-0xf8ff irq 5 at device 6.0 on pci0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xfcd0-0xfcdf at device 7.1 on pci0 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) pccbb0: irq 11 at device 10.0 on pci0 cardbus0: on pccbb0 pccbb1: irq 11 at device 10.1 on pci0 cardbus1: on pccbb1 orm0: