From owner-freebsd-current Sun Jan 13 0:18:16 2002 Delivered-To: freebsd-current@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id EC93637B41C; Sun, 13 Jan 2002 00:18:10 -0800 (PST) Received: (from ache@localhost) by nagual.pp.ru (8.11.6/8.11.6) id g0D8I9J24212; Sun, 13 Jan 2002 11:18:09 +0300 (MSK) (envelope-from ache) Date: Sun, 13 Jan 2002 11:18:08 +0300 From: "Andrey A. Chernov" To: current@freebsd.org, peter@freebsd.org Subject: WARNING: I plan to commit & MFC this ncurses patch in anycase Message-ID: <20020113081808.GA24180@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.24i 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 differences between our lib_baudrate and official variant, fixed at summer 2001. I constantly ask our ncurses maintainer (Peter) to commit this since summer 2001, but nothing happens, so I plan to do it in anycase even taking this file out of vendor branch since the bug must be fixed before 4.5. --- lib_baudrate.c Thu May 17 12:21:05 2001 +++ /tmp/lib_baudrate.c Sun Jan 13 11:06:34 2002 @@ -40,7 +40,42 @@ #include /* cur_term, pad_char */ #include /* ospeed */ -MODULE_ID("$Id: lib_baudrate.c,v 1.19 2000/12/10 02:55:07 tom Exp $") +/* + * These systems use similar header files, which define B1200 as 1200, etc., + * but can be overridden by defining USE_OLD_TTY so B1200 is 9, which makes all + * of the indices up to B115200 fit nicely in a 'short', allowing us to retain + * ospeed's type for compatibility. + */ +#if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__) +#undef B0 +#undef B50 +#undef B75 +#undef B110 +#undef B134 +#undef B150 +#undef B200 +#undef B300 +#undef B600 +#undef B1200 +#undef B1800 +#undef B2400 +#undef B4800 +#undef B9600 +#undef B19200 +#undef EXTA +#undef B38400 +#undef EXTB +#undef B57600 +#undef B115200 +#undef B230400 +#undef B460800 +#define USE_OLD_TTY +#include +#else +#undef USE_OLD_TTY +#endif /* USE_OLD_TTY */ + +MODULE_ID("$Id: lib_baudrate.c,v 1.21 2001/06/30 22:59:22 tom Exp $") /* * int @@ -162,15 +197,20 @@ ret = 9600; ospeed = _nc_ospeed(ret); returnCode(ret); - } else + } #endif +#ifdef USE_OLD_TTY + result = cfgetospeed(&cur_term->Nttyb); + ospeed = _nc_ospeed(result); +#else #ifdef TERMIOS ospeed = cfgetospeed(&cur_term->Nttyb); #else ospeed = cur_term->Nttyb.sg_ospeed; #endif result = _nc_baudrate(ospeed); +#endif /* __FreeBSD__ */ if (cur_term != 0) cur_term->_baudrate = result; -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 13 2:35:45 2002 Delivered-To: freebsd-current@freebsd.org Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by hub.freebsd.org (Postfix) with ESMTP id 427AE37B416 for ; Sun, 13 Jan 2002 02:35:42 -0800 (PST) Received: from blackbox.pacbell.net ([64.166.86.21]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GPV0071X57JIW@mta5.snfc21.pbi.net> for current@freebsd.org; Sat, 12 Jan 2002 22:11:44 -0800 (PST) Received: (from mikem@localhost) by blackbox.pacbell.net (8.11.6/8.11.6) id g0D6C8D44546; Sat, 12 Jan 2002 22:12:08 -0800 (PST envelope-from mikem) Date: Sat, 12 Jan 2002 22:12:08 -0800 From: Mike Makonnen Subject: Re: new module-references compile error In-reply-to: <20020112132026.W23343-100000@pc-micha.mc.hp.com> To: Michael Class Cc: current@freebsd.org Message-id: <200201130612.g0D6C8D44546@blackbox.pacbell.net> MIME-version: 1.0 X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd5.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <20020112132026.W23343-100000@pc-micha.mc.hp.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 On Sat, 12 Jan 2002 13:22:47 +0100 (MET) Michael Class wrote: > pc-micha:/sys/i386/compile/MCSMP2# make > linking kernel.debug > linprocfs.o: In function `linprocfs_donetdev': > /sys/i386/compile/MCSMP2/../../../compat/linprocfs/linprocfs.c(.text+0xfe9): undefined reference to `linux_ifname' > *** Error code 1 > A few days ago changes were made to sys/compat/linux/linux_ioctl.c (rev. 1.79, I believe) that removed linux_ifname(). Just checkout rev. 1.78 and use that instead. cheers, mike makonnen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 13 3:37: 4 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 67B5C37B417 for ; Sun, 13 Jan 2002 03:36:59 -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 WAA07042; Sun, 13 Jan 2002 22:36:47 +1100 Date: Sun, 13 Jan 2002 22:37:35 +1100 (EST) From: Bruce Evans X-X-Sender: To: Michael Reifenberger Cc: FreeBSD-Current Subject: Re: panic during fdisk'ing a md(4) device In-Reply-To: <20020112130202.F451-100000@nihil> Message-ID: <20020113222214.X598-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 Sat, 12 Jan 2002, Michael Reifenberger wrote: > Hi, > more input: > The panic occurs in dsname() while dereferencing devsw(dev)->d_name. > devsw(dev) gives NULL. This was fairly clear from the panic message (the low fault address is almost certainly for a null pointer + offset, and it's fairly clear how dsname() gets a null pointer). Sorry I didn't reply earlier and save you the work debugging this. > The call to dsname() occurs from dkmodminor() defined in disklabel.h > I've seen two calls to dsname, only the second one panics. > Any thoughts? dkmodminor() is supposed to modify a minor device that already has a devswitch. Since dsname() in it panics, the problem is earlier when the minor device is created without giving it a devswitch. Minor devices are supposed to be created in a hierarchial order so that this doesn't happen. E.g., ad0 in disk_create() (only ?) ad0s1 now in dsopen() ad0s2 ad0s2a now in dsopen() ... I suggest adding printfs to make_dev() and makedev() to track the order. The problem occurs when makedev() is called without a corresponding make_dev(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 13 14:30:38 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 1A87E37B416 for ; Sun, 13 Jan 2002 14:30:24 -0800 (PST) Received: (from uucp@localhost) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) id g0DMU1A13437; Sun, 13 Jan 2002 23:30:01 +0100 (MET) >Received: (from andreas@localhost) by klemm.gtn.com (8.11.6/8.11.3) id g0DMP4B86240; Sun, 13 Jan 2002 23:25:04 +0100 (CET) (envelope-from andreas) Date: Sun, 13 Jan 2002 23:25:04 +0100 From: Andreas Klemm To: John Hay Cc: gaspeak@va.prestige.net, Beech Rintoul , freebsd-current@FreeBSD.ORG, apsfilter-help@apsfilter.org Subject: Re: ghostscript-gnu build broken Message-ID: <20020113222504.GA85380@titan.klemm.gtn.com> References: <20020112111111.E400637B41B@hub.freebsd.org> <200201121125.g0CBPtL16976@zibbi.icomtek.csir.co.za> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <200201121125.g0CBPtL16976@zibbi.icomtek.csir.co.za> User-Agent: Mutt/1.3.23.1i X-Operating-System: FreeBSD 4.5-RC X-Disclaimer: A free society is one where it is safe to be unpopular Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" 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 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 12, 2002 at 01:25:55PM +0200, John Hay wrote: > It is not a -current problem. It is if you use the latest automake port, > which is using v1.5. I tried that command manually with automake14 and > then I didn't get that error. John, what steps did you do exactly ? Do you think its possible to put "that logic" into the port ? Andreas /// --=20 Andreas Klemm - Powered by FreeBSD Need a magic printfilter today ? http://www.apsfilter.org/ Songs from our band >> 64Bits << http://www.64bits.de Inofficial band pages with add-on stuff http://www.apsfilter.org/64bits.ht= ml --SUOF0GtieIMvvwua Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8Qgk/d3o+lGxvbLoRAnh6AJ96XLO7jA11bUlaz0vzX48XvCcx9ACgoVqM sxDc7UV8HfSUHAG6vwlNb+E= =WEH1 -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 13 21:25:55 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 8B2D037B405; Sun, 13 Jan 2002 21:25:50 -0800 (PST) Received: (from nnd@localhost) by wint.itfs.nsk.su (8.11.6/8.11.4) id g0E5PlQ50217; Mon, 14 Jan 2002 11:25:47 +0600 (NOVT) (envelope-from nnd) Date: Mon, 14 Jan 2002 11:25:47 +0600 (NOVT) Message-Id: <200201140525.g0E5PlQ50217@wint.itfs.nsk.su> From: nnd@mail.nsk.ru (Nickolay Dudorov) To: current@freebsd.org Cc: marcel@freebsd.org Subject: Re: new module-references compile error In-Reply-To: <200201130612.g0D6C8D44546@blackbox.pacbell.net> 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 <200201130612.g0D6C8D44546@blackbox.pacbell.net> Mike Makonnen wrote: > On Sat, 12 Jan 2002 13:22:47 +0100 (MET) > Michael Class wrote: > >> pc-micha:/sys/i386/compile/MCSMP2# make >> linking kernel.debug >> linprocfs.o: In function `linprocfs_donetdev': >> /sys/i386/compile/MCSMP2/../../../compat/linprocfs/linprocfs.c(.text+0xfe9): undefined reference to `linux_ifname' >> *** Error code 1 >> > > A few days ago changes were made to sys/compat/linux/linux_ioctl.c (rev. 1.79, I believe) that removed linux_ifname(). Just checkout rev. 1.78 and use that instead. $ And now linux_ioctl.c has rev. 1.81 and you can not simply revert it to the rev 1.78 or 1.77. Is there any intentions to unbroke current after removing linux_ifname() and not change linprocfs.c which needs it ? N.Dudorov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 13 21:37:49 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 6993637B400 for ; Sun, 13 Jan 2002 21:37:45 -0800 (PST) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.6/8.11.6) id g0E5bId88237; Mon, 14 Jan 2002 07:37:18 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200201140537.g0E5bId88237@zibbi.icomtek.csir.co.za> Subject: Re: make release broken In-Reply-To: <20020113131222Y.matusita@jp.FreeBSD.org> from Makoto Matsushita at "Jan 13, 2002 01:12:22 pm" To: matusita@jp.FreeBSD.org (Makoto Matsushita) Date: Mon, 14 Jan 2002 07:37:18 +0200 (SAT) Cc: current@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 > > jhay> The last one that worked here was on 20020108. The one on the > jhay> next day broke. The release builds are started from cron at > jhay> midnight SAST which is 2 hours ahead of UTC. > > FYI: 5.0-CURRENT-20020113-JPSNAP builds goes fine here. I dunno what > change fixes this :-) Yes, mine also started working again. John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@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 Jan 13 22:17:58 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 6E5A537B416; Sun, 13 Jan 2002 22:17:51 -0800 (PST) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.6/8.11.6) id g0E6HdY89334; Mon, 14 Jan 2002 08:17:39 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200201140617.g0E6HdY89334@zibbi.icomtek.csir.co.za> Subject: Re: ghostscript-gnu build broken In-Reply-To: <20020113222504.GA85380@titan.klemm.gtn.com> from Andreas Klemm at "Jan 13, 2002 11:25:04 pm" To: andreas@FreeBSD.ORG (Andreas Klemm) Date: Mon, 14 Jan 2002 08:17:39 +0200 (SAT) Cc: jhay@icomtek.csir.co.za (John Hay), gaspeak@va.prestige.net, akbeech@anchoragerescue.org (Beech Rintoul), freebsd-current@FreeBSD.ORG, apsfilter-help@apsfilter.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 > On Sat, Jan 12, 2002 at 01:25:55PM +0200, John Hay wrote: > > It is not a -current problem. It is if you use the latest automake port, > > which is using v1.5. I tried that command manually with automake14 and > > then I didn't get that error. > > John, what steps did you do exactly ? Something like this: ########################### cd /usr/ports/print/ghostscript-gnu make (fill in the form and wait until it breaks) cd work/ghostscript-6.52/hpijs-1.0 aclocal14 automake14 --foreign --include-deps Makefile cd ../../.. make make install ########################### > Do you think its possible to put "that logic" into the port ? I looked into it a bit. I think it is better if automake don't have to be run. What about removeing files/patch-hpijs-1.0:configure.in and patch the port Makefile with the appened patch? It seems to work here. John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org Index: Makefile =================================================================== RCS file: /home/ncvs/ports/print/ghostscript-gnu/Makefile,v retrieving revision 1.63 diff -u -r1.63 Makefile --- Makefile 11 Jan 2002 21:47:33 -0000 1.63 +++ Makefile 14 Jan 2002 06:06:18 -0000 @@ -165,8 +165,10 @@ ${PERL} -pi -e 's|^DEVICE_DEVS|#DEVICE_DEVS|g' \ ${WRKSRC}/src/unix-gcc.mak # for HPinkjet driver - ${PERL} -pi -e 's|CFLAGS="-O2 -Wall"||g ; \ - s|CXXFLAGS="-O2 -Wall"||g' ${WRKSRC}/${HPIJS_NAME}/configure + # XXX The HPinkjet driver should not be compiled with optimization + ${PERL} -pi -e 's|CFLAGS="-O2 -Wall"|CFLAGS="-pipe -Wall"|g ; \ + s|CXXFLAGS="-O2 -Wall"|CXXFLAGS="-pipe -Wall"|g' \ + ${WRKSRC}/${HPIJS_NAME}/configure find ${WRKSRC}/${HPIJS_NAME} -name '*.h' | xargs ${PERL} -pi -e \ 's|#include ||g' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 13 23:40:34 2002 Delivered-To: freebsd-current@freebsd.org Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by hub.freebsd.org (Postfix) with ESMTP id A25DB37B404 for ; Sun, 13 Jan 2002 23:40:31 -0800 (PST) Received: from blackbox.pacbell.net ([64.166.86.21]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GPX0069R3ZJ2L@mta5.snfc21.pbi.net> for current@freebsd.org; Sun, 13 Jan 2002 23:40:31 -0800 (PST) Received: (from mikem@localhost) by blackbox.pacbell.net (8.11.6/8.11.6) id g0E7emO51146; Sun, 13 Jan 2002 23:40:48 -0800 (PST envelope-from mikem) Date: Sun, 13 Jan 2002 23:40:48 -0800 From: Mike Makonnen Subject: Re: new module-references compile error In-reply-to: <200201140525.g0E5PlQ50217@wint.itfs.nsk.su> To: nnd@mail.nsk.ru (Nickolay Dudorov) Cc: current@freebsd.org Message-id: <200201140740.g0E7emO51146@blackbox.pacbell.net> MIME-version: 1.0 X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd5.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200201130612.g0D6C8D44546@blackbox.pacbell.net> <200201140525.g0E5PlQ50217@wint.itfs.nsk.su> 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, 14 Jan 2002 11:25:47 +0600 (NOVT) nnd@mail.nsk.ru (Nickolay Dudorov) wrote: > And now linux_ioctl.c has rev. 1.81 and you can not simply revert > it to the rev 1.78 or 1.77. The commits after 1.79 touch a different part of the file. Just reverse diff 1.79 and patch it onto 1.81. Everything except the ident string should succeed. cheers, mike makonnen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 0:50:52 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id 54D1537B404; Mon, 14 Jan 2002 00:50:42 -0800 (PST) Received: (from uucp@localhost) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) id g0E8o6p22595; Mon, 14 Jan 2002 09:50:06 +0100 (MET) >Received: (from andreas@localhost) by klemm.gtn.com (8.11.6/8.11.3) id g0E8aRA01960; Mon, 14 Jan 2002 09:36:27 +0100 (CET) (envelope-from andreas) Date: Mon, 14 Jan 2002 09:36:27 +0100 From: Andreas Klemm To: John Hay Cc: Andreas Klemm , gaspeak@va.prestige.net, Beech Rintoul , freebsd-current@FreeBSD.ORG, apsfilter-help@apsfilter.org Subject: Re: ghostscript-gnu build broken Message-ID: <20020114083627.GA1929@titan.klemm.gtn.com> References: <20020113222504.GA85380@titan.klemm.gtn.com> <200201140617.g0E6HdY89334@zibbi.icomtek.csir.co.za> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <200201140617.g0E6HdY89334@zibbi.icomtek.csir.co.za> User-Agent: Mutt/1.3.23.1i X-Operating-System: FreeBSD 4.5-RC X-Disclaimer: A free society is one where it is safe to be unpopular Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" 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 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 14, 2002 at 08:17:39AM +0200, John Hay wrote: > > Do you think its possible to put "that logic" into the port ? >=20 > I looked into it a bit. I think it is better if automake don't have to > be run. What about removeing files/patch-hpijs-1.0:configure.in and > patch the port Makefile with the appened patch? It seems to work here. This could really work bettern, since my patch doesn't work anymore since I updated my autconf and automake environment. So I trapped into the same as you ... Astonishing is, that after changing autoconf version, my patch doesn't work anymore, and -O is again in the CFLAGS :-/ > RCS file: /home/ncvs/ports/print/ghostscript-gnu/Makefile,v > retrieving revision 1.63 > diff -u -r1.63 Makefile > --- Makefile 11 Jan 2002 21:47:33 -0000 1.63 > +++ Makefile 14 Jan 2002 06:06:18 -0000 > @@ -165,8 +165,10 @@ > ${PERL} -pi -e 's|^DEVICE_DEVS|#DEVICE_DEVS|g' \ > ${WRKSRC}/src/unix-gcc.mak > # for HPinkjet driver > - ${PERL} -pi -e 's|CFLAGS=3D"-O2 -Wall"||g ; \ > - s|CXXFLAGS=3D"-O2 -Wall"||g' ${WRKSRC}/${HPIJS_NAME}/configure > + # XXX The HPinkjet driver should not be compiled with optimization > + ${PERL} -pi -e 's|CFLAGS=3D"-O2 -Wall"|CFLAGS=3D"-pipe -Wall"|g ; \ > + s|CXXFLAGS=3D"-O2 -Wall"|CXXFLAGS=3D"-pipe -Wall"|g' \ > + ${WRKSRC}/${HPIJS_NAME}/configure > find ${WRKSRC}/${HPIJS_NAME} -name '*.h' | xargs ${PERL} -pi -e \ > 's|#include ||g' Can you commit it please ? I'm busy today (have a recert termin soon, in 3 hours ;-) Andreas /// --=20 Andreas Klemm Apsfilter Homepage http://www.apsfilter.org Support over mailing-lists (only!) http://www.apsfilter.org/support Mailing-list archive http://www.apsfilter.org/Lists-Arc= hives Songs from our band >> 64Bits << http://www.64bits.de Inofficial band pages with add-on stuff http://www.apsfilter.org/64bits.ht= ml --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8QpiKd3o+lGxvbLoRAqEOAJ4+wb+zO98tp74DMoGj8fz1TjhL5gCfajCK qqt+EyWyV1Rt0b6ZnKIaBJQ= =KFta -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 2:32:42 2002 Delivered-To: freebsd-current@freebsd.org Received: from ns.plaut.de (ns.plaut.de [194.99.75.166]) by hub.freebsd.org (Postfix) with ESMTP id A241537B405 for ; Mon, 14 Jan 2002 02:32:39 -0800 (PST) Received: (from uucp@localhost) by ns.plaut.de (8.9.3/8.9.3) with UUCP id LAA62219; Mon, 14 Jan 2002 11:31:19 +0100 (CET) (envelope-from root@nihil.plaut.de) Received: from localhost (root@localhost) by nihil.plaut.de (8.11.3/8.8.8) with ESMTP id g0EAUhx00581; Mon, 14 Jan 2002 11:30:43 +0100 (CET) (envelope-from root@nihil) Date: Mon, 14 Jan 2002 11:30:43 +0100 (CET) From: Michael Reifenberger To: Bruce Evans Cc: FreeBSD-Current Subject: Re: panic during fdisk'ing a md(4) device In-Reply-To: <20020112130202.F451-100000@nihil> Message-ID: <20020114111946.K569-100000@nihil> 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, more food: The kernel startup is: ... vga: ... makedev(116,65538) make_dev(maj=116,min=65538,name=ad0) ad0: ... makedev(116,65546) make_dev(maj=116,min=65546,name=ad1) ad1: ... acd0: ... Mounting root from ufs:/dev/ad0s3a makedev(116,65538) (?!?!? Why, where) makedev(116,262144) make_dev(maj=116,min=262144,name=ad0s3a) makedev(116,262146) dkmodminor() dsname() makedev(116,262146) make_dev(maj=116,min=262146,name=ad0s3 dkmodminor() dsname() PENG What else to debug? BTW: sys/types.h defines another makedev() as kern_conf.c Bye! ---- Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 5:30:22 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 E8C0F37B405 for ; Mon, 14 Jan 2002 05:29:53 -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 AAA00137; Tue, 15 Jan 2002 00:29:45 +1100 Date: Tue, 15 Jan 2002 00:30:50 +1100 (EST) From: Bruce Evans X-X-Sender: To: Michael Reifenberger Cc: FreeBSD-Current Subject: Re: panic during fdisk'ing a md(4) device In-Reply-To: <20020114111946.K569-100000@nihil> Message-ID: <20020114235843.S5601-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 Mon, 14 Jan 2002, Michael Reifenberger wrote: > Hi, > more food: > The kernel startup is: > ... > vga: ... > makedev(116,65538) > make_dev(maj=116,min=65538,name=ad0) > ad0: ... > makedev(116,65546) > make_dev(maj=116,min=65546,name=ad1) > ad1: ... > acd0: ... > Mounting root from ufs:/dev/ad0s3a > makedev(116,65538) (?!?!? Why, where) This just looks up ad0. A previous make_dev() created the complete device struct for ad0. > makedev(116,262144) > make_dev(maj=116,min=262144,name=ad0s3a) > makedev(116,262146) > dkmodminor() > dsname() > makedev(116,262146) > make_dev(maj=116,min=262146,name=ad0s3 I think it actually wants ad0s3c here. I was wrong about ad0s3 getting created before ad0s3[a-h]. The order is actually ad0s3a..ad0s3h, but bugs prevented proper creation of ad0s3c. > dkmodminor() > dsname() > PENG > > What else to debug? I think I found the bug. It manifests as a panic for accessing the 'c' partition which doesn't get created properly. There was only a problem for partitions on slices (s1-s30), but I use ad0[a-h] for filesystems and ad0s4 for swap so I didn't see it. > BTW: sys/types.h defines another makedev() as kern_conf.c Yes, it is a bit confusing. sys/types.h gives the userland version. Try this version. Only disklabel.h has many changes. The code for avoiding creation of bogus 'c' partitions didn't work at all. Index: kern/subr_disk.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_disk.c,v retrieving revision 1.50 diff -u -2 -r1.50 subr_disk.c --- kern/subr_disk.c 4 Nov 2001 11:56:22 -0000 1.50 +++ kern/subr_disk.c 14 Jan 2002 11:42:38 -0000 @@ -301,5 +301,5 @@ error = 0; - pdev = dkmodpart(dkmodslice(dev, WHOLE_DISK_SLICE), RAW_PART); + pdev = dkmodslice(dkmodpart(dev, -RAW_PART), WHOLE_DISK_SLICE); dp = pdev->si_disk; @@ -349,5 +349,5 @@ error = 0; - pdev = dkmodpart(dkmodslice(dev, WHOLE_DISK_SLICE), RAW_PART); + pdev = dkmodslice(dkmodpart(dev, -RAW_PART), WHOLE_DISK_SLICE); dp = pdev->si_disk; if (!dp) @@ -365,5 +365,5 @@ struct disk *dp; - pdev = dkmodpart(dkmodslice(bp->bio_dev, WHOLE_DISK_SLICE), RAW_PART); + pdev = dkmodslice(dkmodpart(bp->bio_dev, -RAW_PART), WHOLE_DISK_SLICE); dp = pdev->si_disk; bp->bio_resid = bp->bio_bcount; @@ -400,5 +400,5 @@ dev_t pdev; - pdev = dkmodpart(dkmodslice(dev, WHOLE_DISK_SLICE), RAW_PART); + pdev = dkmodslice(dkmodpart(dev, -RAW_PART), WHOLE_DISK_SLICE); dp = pdev->si_disk; if (!dp) @@ -416,5 +416,5 @@ dev_t pdev; - pdev = dkmodpart(dkmodslice(dev, WHOLE_DISK_SLICE), RAW_PART); + pdev = dkmodslice(dkmodpart(dev, -RAW_PART), WHOLE_DISK_SLICE); dp = pdev->si_disk; if (!dp) Index: kern/subr_diskmbr.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_diskmbr.c,v retrieving revision 1.54 diff -u -2 -r1.54 subr_diskmbr.c --- kern/subr_diskmbr.c 11 Dec 2001 05:35:43 -0000 1.54 +++ kern/subr_diskmbr.c 9 Jan 2002 10:34:30 -0000 @@ -209,5 +209,5 @@ /* Read master boot record. */ bp = geteblk((int)lp->d_secsize); - bp->b_dev = dkmodpart(dkmodslice(dev, WHOLE_DISK_SLICE), RAW_PART); + bp->b_dev = dkmodslice(dkmodpart(dev, -RAW_PART), WHOLE_DISK_SLICE); bp->b_blkno = mbr_offset; bp->b_bcount = lp->d_secsize; Index: kern/subr_diskslice.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_diskslice.c,v retrieving revision 1.96 diff -u -2 -r1.96 subr_diskslice.c --- kern/subr_diskslice.c 12 Sep 2001 08:37:45 -0000 1.96 +++ kern/subr_diskslice.c 14 Jan 2002 12:49:02 -0000 @@ -77,4 +77,5 @@ struct disklabel *lp)); static void set_ds_labeldevs __P((dev_t dev, struct diskslices *ssp)); +static void set_ds_labeldevs_unaliased __P((dev_t dev, struct diskslices *ssp)); static void set_ds_wlabel __P((struct diskslices *ssp, int slice, int wlabel)); @@ -649,4 +650,5 @@ char *msg; u_char mask; + char *oldsname; int part; char partname[2]; @@ -728,11 +730,29 @@ ) continue; - dev1 = dkmodslice(dkmodpart(dev, RAW_PART), slice); -#if 0 - sname = dsname(dev, unit, slice, RAW_PART, partname); -#else - *partname='\0'; - sname = dev1->si_name; -#endif + dev1 = dkmodslice(dkmodpart(dev, -RAW_PART), slice); + if (dev1->si_devsw == NULL) { + Debugger("dsopen: no devsw (can't happen)"); + dev1->si_devsw = dev->si_devsw; + } + /* + * XXX we want a device name without any partition letter + * in it for use in error messages. dev1->si_name doesn't + * give this for the compatibility slice since there is no + * alias for the raw partiton on that slice. + * + * XXX dsname() is only used for the regression check; + * partname is only used to throw away the partition name + * in the regression check. + */ + if (slice == COMPATIBILITY_SLICE) + sname = dkmodslice(dkmodpart(dev, -RAW_PART), + WHOLE_DISK_SLICE)->si_name; + else + sname = dev1->si_name; + oldsname = dsname(dev, unit, slice, RAW_PART, partname); + if (strcmp(sname, oldsname) != 0) + printf( + "dsopen: dsname = '%s', partname = '%s', sname = '%s'\n", + oldsname, partname, sname); /* * XXX this should probably only be done for the need_init @@ -969,6 +989,55 @@ struct diskslices *ssp; { + int slice; + + set_ds_labeldevs_unaliased(dev, ssp); + if (ssp->dss_first_bsd_slice == COMPATIBILITY_SLICE) + return; + slice = dkslice(dev); + if (slice == COMPATIBILITY_SLICE) + set_ds_labeldevs_unaliased( + dkmodslice(dev, ssp->dss_first_bsd_slice), ssp); + else if (slice == ssp->dss_first_bsd_slice) + set_ds_labeldevs_unaliased( + dkmodslice(dev, COMPATIBILITY_SLICE), ssp); } +static void +set_ds_labeldevs_unaliased(dev, ssp) + dev_t dev; + struct diskslices *ssp; +{ + struct disklabel *lp; + int part; + struct partition *pp; + int slice; + struct diskslice *sp; + + slice = dkslice(dev); + sp = &ssp->dss_slices[slice]; + if (sp->ds_size == 0) + return; + lp = sp->ds_label; + for (part = 0; part < lp->d_npartitions; part++) { + pp = &lp->d_partitions[part]; + if (pp->p_size == 0) + continue; + /* + * Just dkmod'ing to a partition creates all the necessary + * device entries for it. This is a bit weird, but it + * corresponds to userland stat'ing of nonexistent devfs + * directory entries creating them, and at least we avoid + * creating entries for nonexistent empty devices here. + * + * XXX userland can even exploit bugs to create invalid + * devices, e.g., ones with slice numbers larger than the + * max. Such slice numbers leak into the unit number + * or so-called "spare" bitfields. + */ + if (dev->si_flags & SI_ALIAS) + Debugger("unexpeced dk alias"); + (void)dkmodpart(dev, part); + } +} static void Index: sys/disklabel.h =================================================================== RCS file: /home/ncvs/src/sys/sys/disklabel.h,v retrieving revision 1.63 diff -u -2 -r1.63 disklabel.h --- sys/disklabel.h 4 Nov 2001 09:01:02 -0000 1.63 +++ sys/disklabel.h 14 Jan 2002 12:42:24 -0000 @@ -438,16 +438,4 @@ (((slice) << 16) | (((unit) & 0x1e0) << 16) | \ (((unit) & 0x1f) << 3) | (part)) -static __inline dev_t -dkmodpart(dev_t dev, int part) -{ - return (makedev(major(dev), (minor(dev) & ~7) | part)); -} - -static __inline dev_t -dkmodslice(dev_t dev, int slice) -{ - return (makedev(major(dev), (minor(dev) & ~0x1f0000) | (slice << 16))); -} - #define dkpart(dev) (minor(dev) & 7) #define dkslice(dev) ((minor(dev) >> 16) & 0x1f) @@ -478,4 +466,101 @@ void alpha_fix_srm_checksum __P((struct buf *bp)); #endif + +#include /* XXX */ +#include /* XXX */ + +/* + * XXX should be able to share more code between disk_dev_synth(), + * disk_clone() and here. + * XXX using dsname() only slightly insulates us from complications. + */ +static __inline dev_t +dkmodminor(dev_t dev, int mynor, int slicehint) +{ + dev_t newdev, newdev_alias; + const char *sname; + char partname[2]; + + newdev = makedev(major(dev), mynor); + if ((dev->si_flags & SI_NAMED) == 0) + return (newdev); /* XXX should panic. */ + if (newdev->si_flags & SI_NAMED) { + /* We have found a device, but may want an alias. */ + if (slicehint) + return (newdev); + + /* We do want an alias. There can be only one. XXX. */ + newdev_alias = LIST_FIRST(&newdev->si_children); + if (newdev_alias != NULL) + return (newdev_alias); + sname = dsname(dev, dkunit(newdev), dkslice(newdev), + dkpart(newdev), partname); + return (make_dev_alias(newdev, "%s%s", sname, partname)); + } + sname = dsname(dev, dkunit(newdev), dkslice(newdev), dkpart(newdev), + partname); + if (dkslice(newdev) == WHOLE_DISK_SLICE && dkpart(newdev) != RAW_PART) { + printf("bad disk name, sname = '%s', partname = '%s'\n", + sname, partname); + Debugger("dkmod"); + } + if (dkslice(newdev) == COMPATIBILITY_SLICE || + dkpart(newdev) != RAW_PART) + return (make_dev(dev->si_devsw, mynor, dev->si_uid, + dev->si_gid, dev->si_mode, "%s%s", sname, partname)); + newdev = make_dev(dev->si_devsw, mynor, dev->si_uid, + dev->si_gid, dev->si_mode, "%s", sname); + if (dkslice(newdev) == WHOLE_DISK_SLICE) + return (newdev); +#if 0 + newdev_alias = make_dev_alias(newdev, "%s%s", sname, partname); +#else + /* + * Don't blindly create the alias. since it is bogus if the slice + * is unlabeled. Passing another hint to tell use when to do this + * would be too messy even for this prototype version. Now there + * are problems getting the alias created if the label is discovered + * later (these are fixed here but not in subr_disk.c). + */ + if (slicehint) + newdev_alias = NULL; + else + newdev_alias = make_dev_alias(newdev, "%s%s", sname, partname); +#endif + return (slicehint ? newdev : newdev_alias); +} + +static __inline dev_t +dkmodpart(dev_t dev, int part) +{ + int slicehint; + + /* + * XXX temporary hack: callers pass part == -RAW_PART instead of + * part == RAW_PART as a hint that they want a device whose name + * doesn't contain the partition letter for RAW_PART, if possible. + * This is possible unless the slice is COMPATIBILITY_SLICE. This + * is non-optional if the slice is WHOLE_DISK_SLICE. + */ + if (part == -RAW_PART) { + slicehint = 1; + part = RAW_PART; + } else + slicehint = 0; + return (dkmodminor(dev, (minor(dev) & ~7) | part, slicehint)); +} + +static __inline dev_t +dkmodslice(dev_t dev, int slice) +{ + /* + * Here we hint that we don't want a partition letter unless we + * don't already have one, our partition is RAW_PART, and our slice + * is not COMPATIBILITY_SLICE. These cases are distinguished by + * SI_ALIAS being set. The hint is not used in other cases. + */ + return (dkmodminor(dev, (minor(dev) & ~0x1f0000) | (slice << 16), + (dev->si_flags & SI_ALIAS) == 0)); +} #endif /* _KERNEL */ %%% Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 6:57:33 2002 Delivered-To: freebsd-current@freebsd.org Received: from ns.plaut.de (ns.plaut.de [194.99.75.166]) by hub.freebsd.org (Postfix) with ESMTP id 0462A37B416 for ; Mon, 14 Jan 2002 06:57:14 -0800 (PST) Received: (from uucp@localhost) by ns.plaut.de (8.9.3/8.9.3) with UUCP id PAA65795; Mon, 14 Jan 2002 15:55:56 +0100 (CET) (envelope-from root@nihil.plaut.de) Received: from localhost (root@localhost) by nihil.plaut.de (8.11.3/8.8.8) with ESMTP id g0EEjPP00445; Mon, 14 Jan 2002 15:45:25 +0100 (CET) (envelope-from root@nihil) Date: Mon, 14 Jan 2002 15:45:24 +0100 (CET) From: Michael Reifenberger To: Bruce Evans Cc: FreeBSD-Current Subject: Re: panic during fdisk'ing a md(4) device In-Reply-To: <20020114235843.S5601-100000@gamplex.bde.org> Message-ID: <20020114152940.W429-200000@nihil> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-275960608-1011019524=:429" 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-275960608-1011019524=:429 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 15 Jan 2002, Bruce Evans wrote: ... > Yes, it is a bit confusing. sys/types.h gives the userland version. Only as confusing as the rest of the dk* code :-) > > Try this version. Only disklabel.h has many changes. The code for > avoiding creation of bogus 'c' partitions didn't work at all. This works during startup but the following commands cases a panic while executing newfs (BT is attached): mdconfig -a -t swap -s 128M -o reserve -u 10 disklabel -r -w md10 auto (When looking into /dev now I see two! md10c devices!) newfs -f 4096 /dev/md10c tunefs -n enable /dev/md10c mount /dev/md10c /tmp Bye! ---- Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS --0-275960608-1011019524=:429 Content-Type: TEXT/plain; name="BT.txt" Content-Transfer-Encoding: BASE64 Content-ID: <20020114154524.F429@nihil> Content-Description: Content-Disposition: attachment; filename="BT.txt" R05VIGdkYiA0LjE4DQpDb3B5cmlnaHQgMTk5OCBGcmVlIFNvZnR3YXJlIEZv dW5kYXRpb24sIEluYy4NCkdEQiBpcyBmcmVlIHNvZnR3YXJlLCBjb3ZlcmVk IGJ5IHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwgYW5kIHlvdSBh cmUNCndlbGNvbWUgdG8gY2hhbmdlIGl0IGFuZC9vciBkaXN0cmlidXRlIGNv cGllcyBvZiBpdCB1bmRlciBjZXJ0YWluIGNvbmRpdGlvbnMuDQpUeXBlICJz aG93IGNvcHlpbmciIHRvIHNlZSB0aGUgY29uZGl0aW9ucy4NClRoZXJlIGlz IGFic29sdXRlbHkgbm8gd2FycmFudHkgZm9yIEdEQi4gIFR5cGUgInNob3cg d2FycmFudHkiIGZvciBkZXRhaWxzLg0KVGhpcyBHREIgd2FzIGNvbmZpZ3Vy ZWQgYXMgImkzODYtdW5rbm93bi1mcmVlYnNkIi4uLg0KSWRsZVBURCBhdCBw aHN5aWNhbCBhZGRyZXNzIDB4MDA0MTIwMDANCmluaXRpYWwgcGNiIGF0IHBo eXNpY2FsIGFkZHJlc3MgMHgwMDI4NGNhMA0KcGFuaWNzdHI6IGJkd3JpdGU6 IGJ1ZmZlciBpcyBub3QgYnVzeQ0KcGFuaWMgbWVzc2FnZXM6DQotLS0NCkZh dGFsIHRyYXAgMTI6IHBhZ2UgZmF1bHQgd2hpbGUgaW4ga2VybmVsIG1vZGUN CmZhdWx0IHZpcnR1YWwgYWRkcmVzcwk9IDB4MWMNCmZhdWx0IGNvZGUJCT0g c3VwZXJ2aXNvciByZWFkLCBwYWdlIG5vdCBwcmVzZW50DQppbnN0cnVjdGlv biBwb2ludGVyCT0gMHg4OjB4YzAxNzg2NDcNCnN0YWNrIHBvaW50ZXIJICAg ICAgICA9IDB4MTA6MHhjYTNkMGFiMA0KZnJhbWUgcG9pbnRlcgkgICAgICAg ID0gMHgxMDoweGNhM2QwYWNjDQpjb2RlIHNlZ21lbnQJCT0gYmFzZSAweDAs IGxpbWl0IDB4ZmZmZmYsIHR5cGUgMHgxYg0KCQkJPSBEUEwgMCwgcHJlcyAx LCBkZWYzMiAxLCBncmFuIDENCnByb2Nlc3NvciBlZmxhZ3MJPSBpbnRlcnJ1 cHQgZW5hYmxlZCwgcmVzdW1lLCBJT1BMID0gMA0KY3VycmVudCBwcm9jZXNz CQk9IDM2NCAobmV3ZnMpDQp0cmFwIG51bWJlcgkJPSAxMg0KcGFuaWM6IHBh Z2UgZmF1bHQNCg0Kc3luY2luZyBkaXNrcy4uLiBwYW5pYzogYmR3cml0ZTog YnVmZmVyIGlzIG5vdCBidXN5DQpVcHRpbWU6IDlzDQpwZnNfdm5jYWNoZV91 bmxvYWQoKTogMSBlbnRyaWVzIHJlbWFpbmluZw0KDQpkdW1waW5nIHRvIGRl diBhZDBzM2IsIG9mZnNldCAzOTMzNDQwDQpkdW1wIGF0YTA6IHJlc2V0dGlu ZyBkZXZpY2VzIC4uIGRvbmUNCjEyNyAxMjYgMTI1IDEyNCAxMjMgMTIyIDEy MSAxMjAgMTE5IDExOCAxMTcgMTE2IDExNSAxMTQgMTEzIDExMiAxMTEgMTEw IDEwOSAxMDggMTA3IDEwNiAxMDUgMTA0IDEwMyAxMDIgMTAxIDEwMCA5OSA5 OCA5NyA5NiA5NSA5NCA5MyA5MiA5MSA5MCA4OSA4OCA4NyA4NiA4NSA4NCA4 MyA4MiA4MSA4MCA3OSA3OCA3NyA3NiA3NSA3NCA3MyA3MiA3MSA3MCA2OSA2 OCA2NyA2NiA2NSA2NCA2MyA2MiA2MSA2MCA1OSA1OCA1NyA1NiA1NSA1NCA1 MyA1MiA1MSA1MCA0OSA0OCA0NyA0NiA0NSA0NCA0MyA0MiA0MSA0MCAzOSAz OCAzNyAzNiAzNSAzNCAzMyAzMiAzMSAzMCAyOSAyOCAyNyAyNiAyNSAyNCAy MyAyMiAyMSAyMCAxOSAxOCAxNyAxNiAxNSAxNCAxMyAxMiAxMSAxMCA5IDgg NyA2IDUgNCAzIDIgMSAwIA0KLS0tDQojMCAgZHVtcHN5cyAoKSBhdCAuLi8u Li8uLi9rZXJuL2tlcm5fc2h1dGRvd24uYzo0OTINCjQ5MgkJaWYgKCFkb2R1 bXApDQpDYW5ub3QgYWNjZXNzIG1lbW9yeSBhdCBhZGRyZXNzIDB4MTguDQoo a2dkYikgIzAgIGR1bXBzeXMgKCkgYXQgLi4vLi4vLi4va2Vybi9rZXJuX3No dXRkb3duLmM6NDkyDQojMSAgMHhjMDE2NjRjOCBpbiBib290IChob3d0bz0w eDEwNCkgYXQgLi4vLi4vLi4va2Vybi9rZXJuX3NodXRkb3duLmM6MzM1DQoj MiAgMHhjMDE2NjkxNyBpbiBwYW5pYyAoZm10PTB4YzAyM2IyMDEgImJkd3Jp dGU6IGJ1ZmZlciBpcyBub3QgYnVzeSIpIGF0IC4uLy4uLy4uL2tlcm4va2Vy bl9zaHV0ZG93bi5jOjYzNA0KIzMgIDB4YzAxOTkzMmIgaW4gYmR3cml0ZSAo YnA9MHhjNGIyODZjOCkgYXQgLi4vLi4vLi4va2Vybi92ZnNfYmlvLmM6ODU2 DQojNCAgMHhjMDFkMmM1ZSBpbiBmZnNfdXBkYXRlICh2cD0weGM5ZTdkZGUw LCB3YWl0Zm9yPTB4MCkgYXQgLi4vLi4vLi4vdWZzL2Zmcy9mZnNfaW5vZGUu YzoxMjANCiM1ICAweGMwMWUwMGQ2IGluIGZmc19mc3luYyAoYXA9MHhjYTNk MDk2YykgYXQgLi4vLi4vLi4vdWZzL2Zmcy9mZnNfdm5vcHMuYzoyOTINCiM2 ICAweGMwMWRlNjU2IGluIGZmc19zeW5jIChtcD0weGMxMzljMDAwLCB3YWl0 Zm9yPTB4MiwgY3JlZD0weGMwYjQ0ZjAwLCB0ZD0weGMwMjU5ZjI0KSBhdCB2 bm9kZV9pZi5oOjQ0MQ0KIzcgIDB4YzAxYTYyZDYgaW4gc3luYyAodGQ9MHhj MDI1OWYyNCwgdWFwPTB4MCkgYXQgLi4vLi4vLi4va2Vybi92ZnNfc3lzY2Fs bHMuYzo2NjkNCiM4ICAweGMwMTY2MTI5IGluIGJvb3QgKGhvd3RvPTB4MTAw KSBhdCAuLi8uLi8uLi9rZXJuL2tlcm5fc2h1dGRvd24uYzoyNDQNCiM5ICAw eGMwMTY2OTE3IGluIHBhbmljIChmbXQ9MHhjMDI0ZGZmZSAiJXMiKSBhdCAu Li8uLi8uLi9rZXJuL2tlcm5fc2h1dGRvd24uYzo2MzQNCiMxMCAweGMwMjFh MDcwIGluIHRyYXBfZmF0YWwgKGZyYW1lPTB4Y2EzZDBhNzAsIGV2YT0weDFj KSBhdCAuLi8uLi8uLi9pMzg2L2kzODYvdHJhcC5jOjg0Mg0KIzExIDB4YzAy MTlkOTkgaW4gdHJhcF9wZmF1bHQgKGZyYW1lPTB4Y2EzZDBhNzAsIHVzZXJt b2RlPTB4MCwgZXZhPTB4MWMpIGF0IC4uLy4uLy4uL2kzODYvaTM4Ni90cmFw LmM6NzU2DQojMTIgMHhjMDIxOTdhMyBpbiB0cmFwIChmcmFtZT17dGZfZnMg PSAweDE4LCB0Zl9lcyA9IDB4MTAsIHRmX2RzID0gMHhjYTNkMDAxMCwgdGZf ZWRpID0gMHgyLCB0Zl9lc2kgPSAweGMxNTFkYzAwLCANCiAgICAgIHRmX2Vi cCA9IDB4Y2EzZDBhY2MsIHRmX2lzcCA9IDB4Y2EzZDBhOWMsIHRmX2VieCA9 IDB4YzRiNDU0ZTQsIHRmX2VkeCA9IDB4MCwgdGZfZWN4ID0gMHhjMGI0MzU2 MCwgdGZfZWF4ID0gMHgwLCANCiAgICAgIHRmX3RyYXBubyA9IDB4YywgdGZf ZXJyID0gMHgwLCB0Zl9laXAgPSAweGMwMTc4NjQ3LCB0Zl9jcyA9IDB4OCwg dGZfZWZsYWdzID0gMHgxMDI0NiwgdGZfZXNwID0gMHhjNGI0NTRlNCwgDQog ICAgICB0Zl9zcyA9IDB4YzE1MWRiMDB9KSBhdCAuLi8uLi8uLi9pMzg2L2kz ODYvdHJhcC5jOjQyNg0KIzEzIDB4YzAxNzg2NDcgaW4gd3JpdGVkaXNrbGFi ZWwgKGRldj0weGMxNTFkYzAwLCBscD0weGMxMzUxNDAwKSBhdCAuLi8uLi8u Li9rZXJuL3N1YnJfZGlza2xhYmVsLmM6MzIzDQojMTQgMHhjMDE3OTcwMyBp biBkc2lvY3RsIChkZXY9MHhjMTUxZGMwMCwgY21kPTB4ODExNDY0NjcsIGRh dGE9MHhjMTM1MTYwMCAiV0VWXDIwMiIsIGZsYWdzPTB4Miwgc3NwcD0weGMx NTE5MGQ0KQ0KICAgIGF0IC4uLy4uLy4uL2tlcm4vc3Vicl9kaXNrc2xpY2Uu Yzo1MjANCiMxNSAweGMwMTc3YTYxIGluIGRpc2tpb2N0bCAoZGV2PTB4YzE1 MWRjMDAsIGNtZD0weDgxMTQ2NDY3LCBkYXRhPTB4YzEzNTE2MDAgIldFVlwy MDIiLCBmZmxhZz0weDIsIHRkPTB4Yzk4YWQ0MDQpDQogICAgYXQgLi4vLi4v Li4va2Vybi9zdWJyX2Rpc2suYzo0MDYNCiMxNiAweGMwMTQyNDRjIGluIHNw ZWNfaW9jdGwgKGFwPTB4Y2EzZDBiYTQpIGF0IC4uLy4uLy4uL2ZzL3NwZWNm cy9zcGVjX3Zub3BzLmM6MzIwDQojMTcgMHhjMDE0MjBjZCBpbiBzcGVjX3Zu b3BlcmF0ZSAoYXA9MHhjYTNkMGJhNCkgYXQgLi4vLi4vLi4vZnMvc3BlY2Zz L3NwZWNfdm5vcHMuYzoxMTkNCiMxOCAweGMwMWFjZWI3IGluIHZuX2lvY3Rs IChmcD0weGMxNTE4MTAwLCBjb209MHg4MTE0NjQ2NywgZGF0YT0weGMxMzUx NjAwICJXRVZcMjAyIiwgdGQ9MHhjOThhZDQwNCkgYXQgdm5vZGVfaWYuaDoz NTcNCiMxOSAweGMwMTgzYjAzIGluIGlvY3RsICh0ZD0weGM5OGFkNDA0LCB1 YXA9MHhjYTNkMGQyMCkgYXQgLi4vLi4vLi4vc3lzL2ZpbGUuaDoyMDANCiMy MCAweGMwMjFhNTAwIGluIHN5c2NhbGwgKGZyYW1lPXt0Zl9mcyA9IDB4MmYs IHRmX2VzID0gMHgyZiwgdGZfZHMgPSAweDJmLCB0Zl9lZGkgPSAweGJmYmZm ZTY3LCB0Zl9lc2kgPSAweDgwNmRhZTAsIA0KICAgICAgdGZfZWJwID0gMHhi ZmJmZjZmOCwgdGZfaXNwID0gMHhjYTNkMGQ3NCwgdGZfZWJ4ID0gMHhjMDIs IHRmX2VkeCA9IDB4ODA2ZGJmNCwgdGZfZWN4ID0gMHg4MDZkYWUwLCB0Zl9l YXggPSAweDM2LCANCiAgICAgIHRmX3RyYXBubyA9IDB4YywgdGZfZXJyID0g MHgyLCB0Zl9laXAgPSAweDgwNGU1MDAsIHRmX2NzID0gMHgxZiwgdGZfZWZs YWdzID0gMHgyODMsIHRmX2VzcCA9IDB4YmZiZmY2Y2MsIA0KICAgICAgdGZf c3MgPSAweDJmfSkgYXQgLi4vLi4vLi4vaTM4Ni9pMzg2L3RyYXAuYzoxMDM0 DQojMjEgMHhjMDIwZTA1ZCBpbiBzeXNjYWxsX3dpdGhfZXJyX3B1c2hlZCAo KQ0KIzIyIDB4ODA0OTI4OCBpbiA/PyAoKQ0KIzIzIDB4ODA0ODEzNSBpbiA/ PyAoKQ0KKGtnZGIpIA== --0-275960608-1011019524=:429-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 7: 4:13 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 576FD37B417; Mon, 14 Jan 2002 07:03:52 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g0EF3gt45879; Mon, 14 Jan 2002 17:03:42 +0200 (EET) (envelope-from ru) Date: Mon, 14 Jan 2002 17:03:42 +0200 From: Ruslan Ermilov To: current@FreeBSD.org Cc: ume@FreeBSD.org Subject: Re: cvs commit: src/sbin/ping ping.c Message-ID: <20020114170342.E21333@sunbay.com> References: <200201141433.g0EEXZV12841@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201141433.g0EEXZV12841@freefall.freebsd.org> User-Agent: Mutt/1.3.23i 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, Jan 14, 2002 at 06:33:35AM -0800, Ruslan Ermilov wrote: > ru 2002/01/14 06:33:35 PST > > Modified files: > sbin/ping ping.c > Log: > Fixed two bugs with the "-l preload" option: > > - first ping after a preload was sent undelayed > - we could send more than -c packets in preload > > PR: bin/32354 > > Revision Changes Path > 1.61 +10 -6 src/sbin/ping/ping.c > Here's a patch for ping6(8). ping6 is not vulnerable to the second problem. Index: ping6.c =================================================================== RCS file: /cvs/FreeBSD/src/sbin/ping6/ping6.c,v retrieving revision 1.14 diff -u -p -u -p -6 -r1.14 ping6.c --- ping6.c 11 Dec 2001 18:36:29 -0000 1.14 +++ ping6.c 14 Jan 2002 14:55:48 -0000 @@ -969,26 +969,29 @@ main(argc, argv) printf("PING6(%lu=40+8+%lu bytes) ", (unsigned long)(40 + pingerlen()), (unsigned long)(pingerlen() - 8)); printf("%s --> ", pr_addr((struct sockaddr *)&src, sizeof(src))); printf("%s\n", pr_addr((struct sockaddr *)&dst, sizeof(dst))); - while (preload--) /* Fire off them quickies. */ - (void)pinger(); + if (preload == 0) + (void)pinger(); /* Send the first packet. */ + else { + while (preload--) /* Fire off them quickies. */ + (void)pinger(); + } (void)signal(SIGINT, onsignal); #ifdef SIGINFO (void)signal(SIGINFO, onsignal); #endif if ((options & F_FLOOD) == 0) { (void)signal(SIGALRM, onsignal); itimer.it_interval = interval; itimer.it_value = interval; (void)setitimer(ITIMER_REAL, &itimer, NULL); - retransmit(); } fdmasks = howmany(s + 1, NFDBITS) * sizeof(fd_mask); if ((fdmaskp = malloc(fdmasks)) == NULL) err(1, "malloc"); -- Ruslan Ermilov Oracle Developer/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 Mon Jan 14 8:47:31 2002 Delivered-To: freebsd-current@freebsd.org Received: from etek.chalmers.se (quarl0.etek.chalmers.se [129.16.32.20]) by hub.freebsd.org (Postfix) with ESMTP id 2CA5737B41A for ; Mon, 14 Jan 2002 08:47:22 -0800 (PST) Received: from downy.etek.chalmers.se (_7-268@downy.etek.chalmers.se [129.16.32.207]) by etek.chalmers.se (8.10.0/8.8.8) with ESMTP id g0EGlKO25259 for ; Mon, 14 Jan 2002 17:47:20 +0100 (MET) Received: from localhost (b@localhost) by downy.etek.chalmers.se (8.10.0/8.10.0) with ESMTP id g0EGlKi10398 for ; Mon, 14 Jan 2002 17:47:20 +0100 (MET) Date: Mon, 14 Jan 2002 17:47:20 +0100 (MET) From: Magnus B{ckstr|m To: current@freebsd.org Subject: ACPI messages. 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 I put CURRENT on a new Dell Inspiron 4100 laptop this weekend. Works fine, but I keep getting these messages: ACPI-0294: *** Error: Method execution failed, AE_AML_OPERAND_TYPE The messages are logged once every few seconds, and every time I e g remove or insert a battery. I'm not sure what the message means, but then I haven't delved into it beyond searching the mailing list archives (nothing much turned up). Is it A) something to worry about? B) something related to some part of the laptop hardware being unknown, and thus C) something that I ought to endeavour to fix, having the hardware? Advice and pointers sought. Magnus To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 8:51:15 2002 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id DE30C37B400 for ; Mon, 14 Jan 2002 08:51:13 -0800 (PST) Received: (from david@localhost) by bunrab.catwhisker.org (8.11.6/8.11.6) id g0EGpDZ04459; Mon, 14 Jan 2002 08:51:13 -0800 (PST) (envelope-from david) Date: Mon, 14 Jan 2002 08:51:13 -0800 (PST) From: David Wolfskill Message-Id: <200201141651.g0EGpDZ04459@bunrab.catwhisker.org> To: current@freebsd.org Subject: panic "mutex filedesc structure not owned at /usr/src/sys/kern/kern_mutex.c:223" Cc: additional@bunrab.catwhisker.org, Doing@bunrab.catwhisker.org, network@bunrab.catwhisker.org, ntpd@bunrab.catwhisker.org, ntpdate@bunrab.catwhisker.org, rpcbind.@bunrab.catwhisker.org, setup:@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 CVSup done just before 4 AM (US/Pacific) form cvsup14. Got this during attempted multi-user boot: Routing daemons:. Additional daemons: syslogdJan 14 08:47:51 freebeast syslogd: kernel boot file is /boot/kernel/kernel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 8:57: 6 2002 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id DB6E737B402 for ; Mon, 14 Jan 2002 08:57:00 -0800 (PST) Received: (from david@localhost) by bunrab.catwhisker.org (8.11.6/8.11.6) id g0EGv0x04495 for current@freebsd.org; Mon, 14 Jan 2002 08:57:00 -0800 (PST) (envelope-from david) Date: Mon, 14 Jan 2002 08:57:00 -0800 (PST) From: David Wolfskill Message-Id: <200201141657.g0EGv0x04495@bunrab.catwhisker.org> To: current@freebsd.org Subject: Panic "mutex filedesc structure not owned at /usr/src/sys/kern/kern_mutex.c:223" 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 Once more, with feeling (sorry, gang... :-(). CVSupped this morning (just before 4 AM, US/Pacific (8 hrs. west of GMT) from cvsup14. Booting yielded: Routing daemons:. Additional daemons: syslogdJan 14 08:47:51 freebeast syslogd: kernel boot file is /boot/kernel/kernel . Doing additional network setup: ntpdate ntpd rpcbind. Starting final network daemons: mountd nfsdpanic: mutex filedesc structure not owned at /usr/src/sys/kern/kern_mutex.c:223 cpuid = 0; lapic.id = 00000000 Debugger("panic") Stopped at Debugger+0x45: pushl %ebx db> trace Debugger(c02d93b9) at Debugger+0x45 panic(c02d82e8,c02d5c5b,c02d80c0,df,c689d834) at panic+0xd8 _mtx_assert(c689d834,1,c02d80c0,df,c1475320) at _mtx_assert+0x59 _mtx_unlock_flags(c689d834,0,c02df800,436,c1475300) at _mtx_unlock_flags+0x46 unp_externalize(c1475300,c1471a00,0,e0361c8c,e0361ccc) at unp_externalize+0x2cc soreceive(dc84dfc0,e0361c18,e0361c44,0,e0361c1c) at soreceive+0x3aa recvit(def83f04,b,e0361ccc,0,def84014) at recvit+0x116 recvmsg(def83f04,e0361d20,2811f208,bfbfd550,2328) at recvmsg+0xb6 syscall(2f,2f,2f,2328,bfbfd550) at syscall+0x280 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (27, FreeBSD ELF, recvmsg), eip = 0x280bf92f, esp = 0xbfbfd500, ebp = 0xbfbfd5cc --- db> I'm logged in to the machine that's providing console services to the machine (though both are remote from where I am physically right now); if there's anything I can do to help identify the problem, please let me know. Access to BIOS stuff isn't feasible, but other stuff should be. This is my "build machine," so it doesn't have a critical task to be done for another 18 hrs. or so. Cheers, david -- David H. Wolfskill david@catwhisker.org I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 9:18:53 2002 Delivered-To: freebsd-current@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id E8E2237B41E for ; Mon, 14 Jan 2002 09:18:49 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id C14FD10DE00; Mon, 14 Jan 2002 09:18:49 -0800 (PST) Date: Mon, 14 Jan 2002 09:18:49 -0800 From: Alfred Perlstein To: David Wolfskill Cc: current@freebsd.org Subject: Re: Panic "mutex filedesc structure not owned at /usr/src/sys/kern/kern_mutex.c:223" Message-ID: <20020114091849.D26067@elvis.mu.org> References: <200201141657.g0EGv0x04495@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201141657.g0EGv0x04495@bunrab.catwhisker.org>; from david@catwhisker.org on Mon, Jan 14, 2002 at 08:57:00AM -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 * David Wolfskill [020114 08:57] wrote: > Once more, with feeling (sorry, gang... :-(). CVSupped this morning > (just before 4 AM, US/Pacific (8 hrs. west of GMT) from cvsup14. > Booting yielded: Seigo Tanimura has a patch for this, just remove the extranious FILEDESC_UNLOCK from the bottom of the unp_externalize function. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 11: 3: 5 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by hub.freebsd.org (Postfix) with ESMTP id 85EC137B425 for ; Mon, 14 Jan 2002 11:02:24 -0800 (PST) Received: from fwd06.sul.t-online.de by mailout03.sul.t-online.com with smtp id 16QCND-0002aa-0B; Mon, 14 Jan 2002 20:02:23 +0100 Received: from twoflower.liebende.de (320072111332-0001@[217.80.127.15]) by fwd06.sul.t-online.com with esmtp id 16QCN1-06HvLkC; Mon, 14 Jan 2002 20:02:11 +0100 Subject: Where to put errors for ports only in current? From: Jan.Stocker@t-online.de (Jan Stocker) To: current@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 14 Jan 2002 20:01:27 +0100 Message-Id: <1011034894.7907.2.camel@twoflower> Mime-Version: 1.0 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 Hi, where i've to post a error regarding an installed software from ports, which only occurs on current? Jan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 11: 7:40 2002 Delivered-To: freebsd-current@freebsd.org Received: from clink.schulte.org (clink.schulte.org [209.134.156.193]) by hub.freebsd.org (Postfix) with ESMTP id 2228D37B419 for ; Mon, 14 Jan 2002 11:07:37 -0800 (PST) Received: from schulte-laptop.nospam.schulte.org (nb-65.netbriefings.com [209.134.134.65]) by clink.schulte.org (Postfix) with ESMTP id 84038243C1; Mon, 14 Jan 2002 13:07:29 -0600 (CST) Message-Id: <5.1.0.14.0.20020114130541.035ff668@pop3s.schulte.org> X-Sender: X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 14 Jan 2002 13:06:52 -0600 To: Jan.Stocker@t-online.de (Jan Stocker), current@freebsd.org From: Christopher Schulte Subject: Re: Where to put errors for ports only in current? In-Reply-To: <1011034894.7907.2.camel@twoflower> 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 -ports and -current would be appropriate, I'd think. At 08:01 PM 1/14/2002 +0100, Jan Stocker wrote: >Hi, >where i've to post a error regarding an installed software from ports, >which only occurs on current? > >Jan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 11:22:38 2002 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 7E3E837B404 for ; Mon, 14 Jan 2002 11:22:31 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16QCid-000ON3-00; Mon, 14 Jan 2002 21:24:31 +0200 From: Sheldon Hearn To: Christopher Schulte Cc: Jan.Stocker@t-online.de (Jan Stocker), current@freebsd.org Subject: Re: Where to put errors for ports only in current? In-reply-to: Your message of "Mon, 14 Jan 2002 13:06:52 CST." <5.1.0.14.0.20020114130541.035ff668@pop3s.schulte.org> Date: Mon, 14 Jan 2002 21:24:31 +0200 Message-ID: <93684.1011036271@axl.seasidesoftware.co.za> 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, 14 Jan 2002 13:06:52 CST, Christopher Schulte wrote: > -ports and -current would be appropriate, I'd think. No! Cross-posting should not be encouraged. Either -ports or -current, depending on what the problem is. If you're not sure, try -current, since the fact that it works in -stable is something to go on. Actually, this assumes that you are the maintainer of the port, or the maintainer can't help you. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 11:46:11 2002 Delivered-To: freebsd-current@freebsd.org Received: from ns.plaut.de (ns.plaut.de [194.99.75.166]) by hub.freebsd.org (Postfix) with ESMTP id 12D2137B41F for ; Mon, 14 Jan 2002 11:45:43 -0800 (PST) Received: (from uucp@localhost) by ns.plaut.de (8.9.3/8.9.3) with UUCP id UAA68867 for current@freebsd.org; Mon, 14 Jan 2002 20:44:35 +0100 (CET) (envelope-from root@nihil.plaut.de) Received: from localhost (root@localhost) by nihil.plaut.de (8.11.3/8.8.8) with ESMTP id g0EJhB400444 for ; Mon, 14 Jan 2002 20:43:11 +0100 (CET) (envelope-from root@nihil) Date: Mon, 14 Jan 2002 20:43:11 +0100 (CET) From: Michael Reifenberger To: FreeBSD-Current Subject: new panic under -current Message-ID: <20020114204117.I442-100000@nihil> 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, a new panic while surfing under X: 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"... IdlePTD at phsyical address 0x00412000 initial pcb at physical address 0x00284ca0 panicstr: bwrite: buffer is not busy??? panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x80 fault code = supervisor write, page not present instruction pointer = 0x8:0xc01a3418 stack pointer = 0x10:0xca6efb84 frame pointer = 0x10:0xca6efb9c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 995 (kdeinit) trap number = 12 panic: page fault syncing disks... panic: bwrite: buffer is not busy??? Uptime: 4h47m36s pfs_vncache_unload(): 1 entries remaining dumping to dev ad0s3b, offset 3933440 dump ata0: resetting devices .. done 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 dumpsys () at ../../../kern/kern_shutdown.c:492 492 if (!dodump) Cannot access memory at address 0x18. (kgdb) #0 dumpsys () at ../../../kern/kern_shutdown.c:492 #1 0xc01664c8 in boot (howto=0x104) at ../../../kern/kern_shutdown.c:335 #2 0xc0166917 in panic (fmt=0xc023b158 "bwrite: buffer is not busy???") at ../../../kern/kern_shutdown.c:634 #3 0xc0198f33 in bwrite (bp=0xc4b5d4cc) at ../../../kern/vfs_bio.c:676 #4 0xc01994ea in bawrite (bp=0xc4b5d4cc) at ../../../kern/vfs_bio.c:989 #5 0xc0142606 in spec_fsync (ap=0xca6efa40) at ../../../fs/specfs/spec_vnops.c:409 #6 0xc01420cd in spec_vnoperate (ap=0xca6efa40) at ../../../fs/specfs/spec_vnops.c:119 #7 0xc01de870 in ffs_sync (mp=0xc139c000, waitfor=0x2, cred=0xc0b44f00, td=0xc0259f24) at vnode_if.h:441 #8 0xc01a62d6 in sync (td=0xc0259f24, uap=0x0) at ../../../kern/vfs_syscalls.c:669 #9 0xc0166129 in boot (howto=0x100) at ../../../kern/kern_shutdown.c:244 #10 0xc0166917 in panic (fmt=0xc024dffe "%s") at ../../../kern/kern_shutdown.c:634 #11 0xc021a070 in trap_fatal (frame=0xca6efb44, eva=0x80) at ../../../i386/i386/trap.c:842 #12 0xc0219d99 in trap_pfault (frame=0xca6efb44, usermode=0x0, eva=0x80) at ../../../i386/i386/trap.c:756 #13 0xc02197a3 in trap (frame={tf_fs = 0x1000018, tf_es = 0x100010, tf_ds = 0xca540010, tf_edi = 0xca671804, tf_esi = 0xca671804, tf_ebp = 0xca6efb9c, tf_isp = 0xca6efb70, tf_ebx = 0x0, tf_edx = 0x4, tf_ecx = 0xca671804, tf_eax = 0x4, tf_trapno = 0xc, tf_err = 0x2, tf_eip = 0xc01a3418, tf_cs = 0x8, tf_eflags = 0x10282, tf_esp = 0xc186ae50, tf_ss = 0xca54db60}) at ../../../i386/i386/trap.c:426 #14 0xc01a3418 in vput (vp=0x0) at machine/atomic.h:144 #15 0xc14f045a in ?? () #16 0xc01a33db in vrele (vp=0xca54db60) at vnode_if.h:654 #17 0xc01ac5fc in vn_close (vp=0xca54db60, flags=0x1, cred=0xc1843600, td=0xca671804) at ../../../kern/vfs_vnops.c:260 #18 0xc01ad076 in vn_closefile (fp=0xc16f7400, td=0xca671804) at ../../../kern/vfs_vnops.c:730 #19 0xc0150f52 in fdrop_locked (fp=0xc16f7400, td=0xca671804) at ../../../sys/file.h:229 #20 0xc015049a in fdrop (fp=0xc16f7400, td=0xca671804) at ../../../kern/kern_descrip.c:1464 #21 0xc015044c in closef (fp=0xc16f7400, td=0xca671804) at ../../../kern/kern_descrip.c:1450 #22 0xc014eede in close (td=0xca671804, uap=0xca6efd20) at ../../../kern/kern_descrip.c:709 #23 0xc021a500 in syscall (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi = 0x0, tf_esi = 0x38e092a0, tf_ebp = 0xbfbfe8dc, tf_isp = 0xca6efd74, tf_ebx = 0x38df67dc, tf_edx = 0xbfbfe944, tf_ecx = 0xbfbfe9dc, tf_eax = 0x6, tf_trapno = 0xc, tf_err = 0x2, tf_eip = 0x38d95e1c, tf_cs = 0x1f, tf_eflags = 0x287, tf_esp = 0xbfbfe8b0, tf_ss = 0x2f}) at ../../../i386/i386/trap.c:1034 #24 0xc020e05d in syscall_with_err_pushed () #25 0x38dd66b8 in ?? () #26 0x387eb4c1 in ?? () #27 0x385cdda4 in ?? () #28 0x385be68a in ?? () #29 0x385c2707 in ?? () #30 0x385bfd69 in ?? () #31 0x38654cf6 in ?? () #32 0x385f740e in ?? () #33 0x386063b2 in ?? () #34 0x3864ff52 in ?? () #35 0x38f510d1 in ?? () #36 0x804cb36 in ?? () #37 0x804d7f3 in ?? () #38 0x804dd4c in ?? () #39 0x804eedc in ?? () #40 0x804adf1 in ?? () (kgdb) What to look for? Bye! ---- Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 11:55:36 2002 Delivered-To: freebsd-current@freebsd.org Received: from www.contentmedia.de (www.contentmedia.de [213.61.138.91]) by hub.freebsd.org (Postfix) with SMTP id 0280737B41A for ; Mon, 14 Jan 2002 11:55:34 -0800 (PST) Received: (qmail 19669 invoked from network); 14 Jan 2002 19:50:11 -0000 Received: from unknown (HELO leeloo.intern.geht.de) (217.227.202.172) by www.contentmedia.de with SMTP; 14 Jan 2002 19:50:11 -0000 Subject: Re: Where to put errors for ports only in current? From: Marc Recht To: Jan Stocker Cc: current@freebsd.org In-Reply-To: <1011034894.7907.2.camel@twoflower> References: <1011034894.7907.2.camel@twoflower> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 14 Jan 2002 20:55:49 +0100 Message-Id: <1011038150.17607.1.camel@leeloo> 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 > where i've to post a error regarding an installed software from ports, > which only occurs on current? > How about writing the port maintainer ? Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 12: 0:31 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 8991037B437 for ; Mon, 14 Jan 2002 12:00:14 -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 g0EK0Dl10167 for ; Mon, 14 Jan 2002 13:00:13 -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 g0EK0Cx74690 for ; Mon, 14 Jan 2002 13:00:12 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 14 Jan 2002 13:00:00 -0700 (MST) Message-Id: <20020114.130000.59110530.imp@village.org> To: current@freebsd.org Subject: sudo busted after recent upgrade to -current From: "M. Warner Losh" 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 OK. I did a make buildworld/installworld. I did a mergemaster and made sure that /etc/pam.d was there. I also rebuilt sudo 1.6.4 via the ports system (I changed the version number there from the old one to this). However, now when I type sudo it says, after getting my password: sudo: pam_setcred: Permission denied. It also whines on the console if I remove /etc/pam.conf. Ideas? This is from Saturday's current at about 4am MST. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 12: 2:10 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id C735537B405 for ; Mon, 14 Jan 2002 12:01:51 -0800 (PST) Received: (qmail 19612 invoked from network); 14 Jan 2002 20:01:51 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 14 Jan 2002 20:01:51 -0000 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: <20020114091849.D26067@elvis.mu.org> Date: Mon, 14 Jan 2002 12:01:12 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: Re: Panic "mutex filedesc structure not owned at /usr/src/sys/ke Cc: current@freebsd.org, David Wolfskill 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 14-Jan-02 Alfred Perlstein wrote: > * David Wolfskill [020114 08:57] wrote: >> Once more, with feeling (sorry, gang... :-(). CVSupped this morning >> (just before 4 AM, US/Pacific (8 hrs. west of GMT) from cvsup14. >> Booting yielded: > > Seigo Tanimura has a patch for this, just remove the extranious > FILEDESC_UNLOCK from the bottom of the unp_externalize function. You could commit it then if it fixes a bug. :) > -Alfred -- 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 Mon Jan 14 12: 8:19 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id BBC6F37B417 for ; Mon, 14 Jan 2002 12:08:15 -0800 (PST) Received: (qmail 27791 invoked from network); 14 Jan 2002 20:08:14 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 14 Jan 2002 20:08:14 -0000 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: <20020114.130000.59110530.imp@village.org> Date: Mon, 14 Jan 2002 12:07:35 -0800 (PST) From: John Baldwin To: "M. Warner Losh" Subject: RE: sudo busted after recent upgrade to -current 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 14-Jan-02 M. Warner Losh wrote: > OK. I did a make buildworld/installworld. I did a mergemaster and > made sure that /etc/pam.d was there. I also rebuilt sudo 1.6.4 via > the ports system (I changed the version number there from the old one > to this). However, now when I type sudo it says, after getting my > password: > sudo: pam_setcred: Permission denied. > It also whines on the console if I remove /etc/pam.conf. > > Ideas? This is from Saturday's current at about 4am MST. Do you have a /etc/pam.d/other? > Warner -- 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 Mon Jan 14 12:19:17 2002 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 9F2B137B41C for ; Mon, 14 Jan 2002 12:19:12 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16QDbY-000OWR-00; Mon, 14 Jan 2002 22:21:16 +0200 From: Sheldon Hearn To: Michael Reifenberger Cc: FreeBSD-Current Subject: Re: new panic under -current In-reply-to: Your message of "Mon, 14 Jan 2002 20:43:11 +0100." <20020114204117.I442-100000@nihil> Date: Mon, 14 Jan 2002 22:21:16 +0200 Message-ID: <94266.1011039676@axl.seasidesoftware.co.za> 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, 14 Jan 2002 20:43:11 +0100, Michael Reifenberger wrote: > syncing disks... panic: bwrite: buffer is not busy??? > Uptime: 4h47m36s I can get these pretty easily by using modules that are out of sync with the kernel. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 12:37:53 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 39CA737B419; Mon, 14 Jan 2002 12:37:48 -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 g0EKbll10448; Mon, 14 Jan 2002 13:37:47 -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 g0EKbjx74956; Mon, 14 Jan 2002 13:37:46 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 14 Jan 2002 13:37:35 -0700 (MST) Message-Id: <20020114.133735.51274681.imp@village.org> To: jhb@FreeBSD.org Cc: current@FreeBSD.org Subject: Re: sudo busted after recent upgrade to -current From: "M. Warner Losh" In-Reply-To: References: <20020114.130000.59110530.imp@village.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: John Baldwin writes: : : On 14-Jan-02 M. Warner Losh wrote: : > OK. I did a make buildworld/installworld. I did a mergemaster and : > made sure that /etc/pam.d was there. I also rebuilt sudo 1.6.4 via : > the ports system (I changed the version number there from the old one : > to this). However, now when I type sudo it says, after getting my : > password: : > sudo: pam_setcred: Permission denied. : > It also whines on the console if I remove /etc/pam.conf. : > : > Ideas? This is from Saturday's current at about 4am MST. : : Do you have a /etc/pam.d/other? YES. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 12:38:11 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id 5921A37B427 for ; Mon, 14 Jan 2002 12:37:57 -0800 (PST) Received: (qmail 24588 invoked from network); 14 Jan 2002 20:37:55 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 14 Jan 2002 20:37:55 -0000 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: <94266.1011039676@axl.seasidesoftware.co.za> Date: Mon, 14 Jan 2002 12:37:16 -0800 (PST) From: John Baldwin To: Sheldon Hearn Subject: Re: new panic under -current Cc: FreeBSD-Current , Cc: FreeBSD-Current , Michael Reifenberger 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 14-Jan-02 Sheldon Hearn wrote: > > > On Mon, 14 Jan 2002 20:43:11 +0100, Michael Reifenberger wrote: > >> syncing disks... panic: bwrite: buffer is not busy??? >> Uptime: 4h47m36s > > I can get these pretty easily by using modules that are out of sync with > the kernel. That wasn't his real panic. If you read teh whole log, a vrele() called from fdrop_locked() did a vput(0x0), i.e. vput(NULL) which resulted in a page fault panic. -- 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 Mon Jan 14 12:40: 7 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 70FFB37B41F for ; Mon, 14 Jan 2002 12:40:03 -0800 (PST) Received: (qmail 4485 invoked from network); 14 Jan 2002 20:40:02 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 14 Jan 2002 20:40:02 -0000 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: <20020114.133735.51274681.imp@village.org> Date: Mon, 14 Jan 2002 12:39:22 -0800 (PST) From: John Baldwin To: "M. Warner Losh" Subject: Re: sudo busted after recent upgrade to -current 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 14-Jan-02 M. Warner Losh wrote: > In message: > John Baldwin writes: >: >: On 14-Jan-02 M. Warner Losh wrote: >: > OK. I did a make buildworld/installworld. I did a mergemaster and >: > made sure that /etc/pam.d was there. I also rebuilt sudo 1.6.4 via >: > the ports system (I changed the version number there from the old one >: > to this). However, now when I type sudo it says, after getting my >: > password: >: > sudo: pam_setcred: Permission denied. >: > It also whines on the console if I remove /etc/pam.conf. >: > >: > Ideas? This is from Saturday's current at about 4am MST. >: >: Do you have a /etc/pam.d/other? > > YES. Sheesh, ok. :) I had a problem with sudo a while back due to pam not falling back to other in pam.conf properly when the pam.d dir existed. Have you tried copying /etc/pam.d/other to /etc/pam.d/sudo? > Warner -- 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 Mon Jan 14 12:51: 7 2002 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id 6F41737B41A for ; Mon, 14 Jan 2002 12:51:03 -0800 (PST) Received: (from david@localhost) by bunrab.catwhisker.org (8.11.6/8.11.6) id g0EKotH05043 for current@freebsd.org; Mon, 14 Jan 2002 12:50:55 -0800 (PST) (envelope-from david) Date: Mon, 14 Jan 2002 12:50:55 -0800 (PST) From: David Wolfskill Message-Id: <200201142050.g0EKotH05043@bunrab.catwhisker.org> To: current@freebsd.org Subject: Re: Panic "mutex filedesc structure not owned at /usr/src/sys/ke 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 >Date: Mon, 14 Jan 2002 12:01:12 -0800 (PST) >From: John Baldwin >> Seigo Tanimura has a patch for this, just remove the extranious >> FILEDESC_UNLOCK from the bottom of the unp_externalize function. >You could commit it then if it fixes a bug. :) That fix seems to do the trick for me, FWIW. Cheers, david -- David H. Wolfskill david@catwhisker.org I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 12:55:24 2002 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id AC6F637B400; Mon, 14 Jan 2002 12:55:20 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16QEAm-000ObS-00; Mon, 14 Jan 2002 22:57:40 +0200 From: Sheldon Hearn To: John Baldwin Cc: FreeBSD-Current , Michael Reifenberger Subject: Re: new panic under -current In-reply-to: Your message of "Mon, 14 Jan 2002 12:37:16 PST." Date: Mon, 14 Jan 2002 22:57:40 +0200 Message-ID: <94577.1011041860@axl.seasidesoftware.co.za> 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, 14 Jan 2002 12:37:16 PST, John Baldwin wrote: > > I can get these pretty easily by using modules that are out of sync with > > the kernel. > > That wasn't his real panic. If you read teh whole log, a vrele() called from > fdrop_locked() did a vput(0x0), i.e. vput(NULL) which resulted in a page fault > panic. Oops, sorry. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 13:23:20 2002 Delivered-To: freebsd-current@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 3BEFB37B417; Mon, 14 Jan 2002 13:23:17 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 165F510DE00; Mon, 14 Jan 2002 13:23:17 -0800 (PST) Date: Mon, 14 Jan 2002 13:23:17 -0800 From: Alfred Perlstein To: John Baldwin Cc: current@freebsd.org, David Wolfskill Subject: Re: Panic "mutex filedesc structure not owned at /usr/src/sys/ke Message-ID: <20020114132317.F26067@elvis.mu.org> References: <20020114091849.D26067@elvis.mu.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 jhb@FreeBSD.org on Mon, Jan 14, 2002 at 12:01:12PM -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 * John Baldwin [020114 12:02] wrote: > > On 14-Jan-02 Alfred Perlstein wrote: > > * David Wolfskill [020114 08:57] wrote: > >> Once more, with feeling (sorry, gang... :-(). CVSupped this morning > >> (just before 4 AM, US/Pacific (8 hrs. west of GMT) from cvsup14. > >> Booting yielded: > > > > Seigo Tanimura has a patch for this, just remove the extranious > > FILEDESC_UNLOCK from the bottom of the unp_externalize function. > > You could commit it then if it fixes a bug. :) Well, the email gave the impression that he wanted to commit it, I emailed him to do so, but I haven't heard back yet so I just did commit it a couple of hours ago. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 13:24:19 2002 Delivered-To: freebsd-current@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id A228D37B416 for ; Mon, 14 Jan 2002 13:24:12 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 83F1D10DE00; Mon, 14 Jan 2002 13:24:12 -0800 (PST) Date: Mon, 14 Jan 2002 13:24:12 -0800 From: Alfred Perlstein To: Michael Reifenberger Cc: FreeBSD-Current Subject: Re: new panic under -current Message-ID: <20020114132412.G26067@elvis.mu.org> References: <20020114204117.I442-100000@nihil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020114204117.I442-100000@nihil>; from root@nihil.plaut.de on Mon, Jan 14, 2002 at 08:43:11PM +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 * Michael Reifenberger [020114 11:47] wrote: > Hi, > a new panic while surfing under X: Can you cvsup and try to reproduce this? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 13:54: 1 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.i.davidcoulson.net (technoir.demon.co.uk [194.222.178.203]) by hub.freebsd.org (Postfix) with SMTP id 69FBE37B41D for ; Mon, 14 Jan 2002 13:53:36 -0800 (PST) Received: (qmail 16058 invoked by uid 507); 14 Jan 2002 21:53:35 -0000 Date: Mon, 14 Jan 2002 21:53:35 +0000 From: Michael McGoldrick To: current@freebsd.org Subject: rpcbind panic Message-ID: <20020114215335.A15798@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 Kernel and world built with sources cvsupped as of Mon Jan 14 18:44:04 GMT from cvsup.freebsd.org. The panic message is hand copied. Please send me a mail if other details (eg dme sg) are required. Kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x28 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01d9f07 stack pointer = 0x10:0xcb5b8b4c frame pointer = 0x10:0xcb5b8b5c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 178 (rpcbind) kernel: type 12 trap, code = 0 stopped at _mtx_unlock_sleep+0x9f : cmpl $0,0x28(%ebx) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 14: 5:28 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 A522337B416 for ; Mon, 14 Jan 2002 14:05:19 -0800 (PST) Received: (qmail 4629 invoked from network); 14 Jan 2002 22:05:19 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 14 Jan 2002 22:05:19 -0000 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: <20020114215335.A15798@linuxdriven.net> Date: Mon, 14 Jan 2002 14:04:39 -0800 (PST) From: John Baldwin To: Michael McGoldrick Subject: RE: rpcbind panic 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 14-Jan-02 Michael McGoldrick wrote: > Kernel and world built with sources cvsupped as of Mon Jan 14 18:44:04 GMT > from > cvsup.freebsd.org. > The panic message is hand copied. Please send me a mail if other details (eg > dme > sg) are required. A traceback would be most useful. Type 't' in ddb. And just give the list of function names and the first arg for each function please. > Kernel trap 12 with interrupts disabled > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x28 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc01d9f07 > stack pointer = 0x10:0xcb5b8b4c > frame pointer = 0x10:0xcb5b8b5c > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 178 (rpcbind) > kernel: type 12 trap, code = 0 > stopped at _mtx_unlock_sleep+0x9f : cmpl $0,0x28(%ebx) > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" 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 Mon Jan 14 14:18:13 2002 Delivered-To: freebsd-current@freebsd.org Received: from ns.plaut.de (ns.plaut.de [194.99.75.166]) by hub.freebsd.org (Postfix) with ESMTP id 5B38B37B417 for ; Mon, 14 Jan 2002 14:18:05 -0800 (PST) Received: (from uucp@localhost) by ns.plaut.de (8.9.3/8.9.3) with UUCP id XAA69867; Mon, 14 Jan 2002 23:16:54 +0100 (CET) (envelope-from root@nihil.plaut.de) Received: from localhost (root@localhost) by nihil.plaut.de (8.11.3/8.8.8) with ESMTP id g0EMGQD00751; Mon, 14 Jan 2002 23:16:26 +0100 (CET) (envelope-from root@nihil) Date: Mon, 14 Jan 2002 23:16:26 +0100 (CET) From: Michael Reifenberger To: Alfred Perlstein Cc: FreeBSD-Current Subject: Re: new panic under -current In-Reply-To: <20020114132412.G26067@elvis.mu.org> Message-ID: <20020114230841.A533-100000@nihil> 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, 14 Jan 2002, Alfred Perlstein wrote: ... > Can you cvsup and try to reproduce this? Do you have some new -current patches in mind which could affect the problem? My -current is as of today (with some local patches from bde regarding slice-handling which shouldn't be related here). I've seen this type of panic a few times in the past but not reproducable and somewhat infrequently. See a previous post of mine with a few backtraces. Bye! ---- Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 14:18:15 2002 Delivered-To: freebsd-current@freebsd.org Received: from ns.plaut.de (ns.plaut.de [194.99.75.166]) by hub.freebsd.org (Postfix) with ESMTP id 6185B37B416; Mon, 14 Jan 2002 14:18:09 -0800 (PST) Received: (from uucp@localhost) by ns.plaut.de (8.9.3/8.9.3) with UUCP id XAA69868; Mon, 14 Jan 2002 23:17:01 +0100 (CET) (envelope-from root@nihil.plaut.de) Received: from localhost (root@localhost) by nihil.plaut.de (8.11.3/8.8.8) with ESMTP id g0EM8Ta00737; Mon, 14 Jan 2002 23:08:29 +0100 (CET) (envelope-from root@nihil) Date: Mon, 14 Jan 2002 23:08:29 +0100 (CET) From: Michael Reifenberger To: John Baldwin Cc: "M. Warner Losh" , FreeBSD-Current Subject: Re: sudo busted after recent upgrade to -current In-Reply-To: Message-ID: <20020114230618.I533-100000@nihil> 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, 14 Jan 2002, John Baldwin wrote: ... > Sheesh, ok. :) I had a problem with sudo a while back due to pam not falling > back to other in pam.conf properly when the pam.d dir existed. Have you tried > copying /etc/pam.d/other to /etc/pam.d/sudo? I see this too when I do `su - pgsql`. I have /etc/pam.d/[su|other]. Bye! ---- Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 14:55: 2 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.i.davidcoulson.net (technoir.demon.co.uk [194.222.178.203]) by hub.freebsd.org (Postfix) with SMTP id 0D8A537B41E for ; Mon, 14 Jan 2002 14:54:57 -0800 (PST) Received: (qmail 25897 invoked by uid 507); 14 Jan 2002 22:54:56 -0000 Date: Mon, 14 Jan 2002 22:54:56 +0000 From: Michael McGoldrick To: current@freebsd.org Cc: jhb@freebsd.org Subject: Trace for rpcbind panic Message-ID: <20020114225456.A25590@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 The trace was short, so I wrote the whole thing down. _mtx_unlock_sleep(c232c834,0,0,0) at _mtx_unlock_sleep+0x9f unp_externalize(c0b6ab00,c0b6ac00,cb5d3ccc,cb5d3c8c,cb5d3ccc) at unp_externalize +0x38e soreceive(ca29d420,cb5d3c18,cb5d3c44,0,cb5d3c1c) at soreceive+0x376 recvit(ca284304,b,cb5d3ccc,0,ca284200) at recvit+0x121 recvmsg(ca284304,cb5d3d20,281221c8,bfbfd550,2328) at recvmsg+0xdb syscall(2f,2f,2f,2328,bfbfd550) at syscall+0x2d4 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall(27, FreeBSD ELF, recvmsg), eip=0x280c0657, esp=0xbfbfd500, ebp=0xbfb fd5cc --- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 14:56: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 7395937B425 for ; Mon, 14 Jan 2002 14:56:44 -0800 (PST) Received: (qmail 11660 invoked from network); 14 Jan 2002 22:56:43 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 14 Jan 2002 22:56:43 -0000 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: <20020114225456.A25590@linuxdriven.net> Date: Mon, 14 Jan 2002 14:56:04 -0800 (PST) From: John Baldwin To: Michael McGoldrick Subject: RE: Trace for rpcbind panic 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 14-Jan-02 Michael McGoldrick wrote: > The trace was short, so I wrote the whole thing down. That one is fixed already, re-cvsup. Also, you should probably be running with INVARIANTS turned on in -current as that would give more useful error messages. > _mtx_unlock_sleep(c232c834,0,0,0) at _mtx_unlock_sleep+0x9f > unp_externalize(c0b6ab00,c0b6ac00,cb5d3ccc,cb5d3c8c,cb5d3ccc) at > unp_externalize > +0x38e > soreceive(ca29d420,cb5d3c18,cb5d3c44,0,cb5d3c1c) at soreceive+0x376 > recvit(ca284304,b,cb5d3ccc,0,ca284200) at recvit+0x121 > recvmsg(ca284304,cb5d3d20,281221c8,bfbfd550,2328) at recvmsg+0xdb > syscall(2f,2f,2f,2328,bfbfd550) at syscall+0x2d4 > syscall_with_err_pushed() at syscall_with_err_pushed+0x1b > --- syscall(27, FreeBSD ELF, recvmsg), eip=0x280c0657, esp=0xbfbfd500, > ebp=0xbfb > fd5cc --- -- 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 Mon Jan 14 18:12:53 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 5945E37B416; Mon, 14 Jan 2002 18:12:50 -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 g0F2Cml12061; Mon, 14 Jan 2002 19:12:49 -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 g0F2Ckx77227; Mon, 14 Jan 2002 19:12:47 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 14 Jan 2002 19:12:30 -0700 (MST) Message-Id: <20020114.191230.94080449.imp@village.org> To: jhb@FreeBSD.org Cc: current@FreeBSD.org Subject: Re: sudo busted after recent upgrade to -current From: "M. Warner Losh" In-Reply-To: References: <20020114.133735.51274681.imp@village.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: John Baldwin writes: : Sheesh, ok. :) I had a problem with sudo a while back due to pam not falling : back to other in pam.conf properly when the pam.d dir existed. Have you tried : copying /etc/pam.d/other to /etc/pam.d/sudo? No. I haven't.... but it doesn't matter. Same thing. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 14 19:55:31 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 A8B5D37B402 for ; Mon, 14 Jan 2002 19:55:20 -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 MAA19675; Tue, 15 Jan 2002 12:37:20 +0900 (JST) (envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp) Message-Id: <200201150337.MAA19675@shidahara1.planet.sci.kobe-u.ac.jp> To: b@etek.chalmers.se Cc: current@freebsd.org Subject: Re: ACPI messages. In-reply-to: Your message of "Mon, 14 Jan 2002 17:47:20 +0100." Date: Tue, 15 Jan 2002 12:37:20 +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 , M agnus B{ckstr|m wrote: >I put CURRENT on a new Dell Inspiron 4100 laptop this weekend. Works fine, >but I keep getting these messages: > > ACPI-0294: *** Error: Method execution failed, AE_AML_OPERAND_TYPE > >The messages are logged once every few seconds, and every time I e g remove >or insert a battery. > >I'm not sure what the message means, but then I haven't delved into it >beyond searching the mailing list archives (nothing much turned up). > >Is it > A) something to worry about? > B) something related to some part of the laptop hardware being unknown, > and thus > C) something that I ought to endeavour to fix, having the hardware? This may be AML(bytecode) bug made by vendor, which is not appeared in Microsoft implementation. Possible fix you can do now is AML overriding. 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 Mon Jan 14 20:26:31 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 2BB1F37B421 for ; Mon, 14 Jan 2002 20:26:24 -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 g0F4QMl12729 for ; Mon, 14 Jan 2002 21:26: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 g0F4QLx78175 for ; Mon, 14 Jan 2002 21:26:21 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 14 Jan 2002 21:26:02 -0700 (MST) Message-Id: <20020114.212602.69432904.imp@village.org> To: current@freebsd.org Subject: sudo redu From: "M. Warner Losh" 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 OK. This looks like a problem in 1.6.4p1 of sudo. It isn't a problem with 1.6.3p7_2. 1.6.4 works on -stable, but not -current. It apparently added a call to pam_setcred: 453) Now call pam_setcreds() to setup creds for the target user when PAM is in use. On Linux this often sets resource limits. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 3: 8:59 2002 Delivered-To: freebsd-current@freebsd.org Received: from web11401.mail.yahoo.com (web11401.mail.yahoo.com [216.136.131.231]) by hub.freebsd.org (Postfix) with SMTP id 7294237B41C for ; Tue, 15 Jan 2002 03:08:53 -0800 (PST) Message-ID: <20020115110853.2273.qmail@web11401.mail.yahoo.com> Received: from [202.167.61.228] by web11401.mail.yahoo.com via HTTP; Tue, 15 Jan 2002 03:08:53 PST Date: Tue, 15 Jan 2002 03:08:53 -0800 (PST) From: Shizuka Kudo Subject: Melco LPC4-CLX-CB support in 5.0-Current NEWCARD To: freebsd-current@freebsd.org, freebsd-mobile@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 Dear all, Does anyone have tested whether this card works with current 5.0 NEWCARD? I tried it on a Thinkpad 600X with current 5.0 cvsupped yestersday and received a kernel: pccbb0: card inserted: event=0x00000000, state=30000920 kernel: pccbb0: pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44] kernel: pccbb0: pccbb_power: CARD_VCC_3V and CARD_VPP_VCC [11] kernel: found-> vendor=0x10ec, dev=0x8138, revid=0x10 kernel: class=02-00-00, hrdtype=0x00, mfdev=0 kernel: cmdreg=0x0000, statreg=0x0290, cachelnsz=0 (dwords) kernel: lattimer=0xa8 (5040 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) kernel: intpin=a, irq=128 kernel: cardbus0: Expecting link target, got 0xff kernel: cardbus0: Resource not specified in CIS: id=10, size=100 kernel: cardbus0: Resource not specified in CIS: id=14, size=200 kernel: cardbus0: Non-prefetchable memory at 84000000-840001ff kernel: cardbus0: Non-prefetable memory rid=14 at 84000000-840001ff (200) kernel: cardbus0: IO port at 1000-10ff kernel: cardbus0: IO port rid=10 at 1000-10ff kernel: cardbus0: (vendor=0x10ec, dev=0x8138) at 0.0 irq 11. kernel: pccbb0: pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44] Any idea on how I can move forward? __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 4:36:41 2002 Delivered-To: freebsd-current@freebsd.org Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by hub.freebsd.org (Postfix) with ESMTP id 1957E37B405; Tue, 15 Jan 2002 04:36:35 -0800 (PST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id VAA27234; Tue, 15 Jan 2002 21:36:32 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id VAA03687; Tue, 15 Jan 2002 21:36:32 +0900 (JST) Received: from localhost (shigeru@mercury.iij.ad.jp [192.168.4.89]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id VAA20941; Tue, 15 Jan 2002 21:36:31 +0900 (JST) Date: Tue, 15 Jan 2002 21:36:31 +0900 (JST) Message-Id: <20020115.213631.39033142.shigeru@iij.ad.jp> To: shizukakudo_99@yahoo.com Cc: freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: Melco LPC4-CLX-CB support in 5.0-Current NEWCARD From: YAMAMOTO Shigeru In-Reply-To: <20020115110853.2273.qmail@web11401.mail.yahoo.com> References: <20020115110853.2273.qmail@web11401.mail.yahoo.com> X-Mailer: Mew version 2.0 pre1 on Emacs 20.7 / Mule 4.0 (HANANOEN) 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 >>>>> "Shizuka" == Shizuka Kudo writes: Shizuka> Does anyone have tested whether this card works with current 5.0 Shizuka> NEWCARD? I already tested it on NEWCARD. Melco LPC4-CLX-CB is using Realtek's chip. So, we need to add vendor/device ID to rl driver if we want to use Melco LPC4-CLX-CB. #but rl driver is hang up when I testing it. does rl driver have bugs? Thanks, ------- YAMAMOTO Shigeru Internet Initiative Japan Inc. Network Engineering Div. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 4:37:58 2002 Delivered-To: freebsd-current@freebsd.org Received: from dhcp-1.cent.saitama-u.ac.jp (dhcp-1.cent.saitama-u.ac.jp [133.38.4.27]) by hub.freebsd.org (Postfix) with ESMTP id 6DBA537B404; Tue, 15 Jan 2002 04:37:53 -0800 (PST) Received: from dhcp-1.cent.saitama-u.ac.jp (localhost [127.0.0.1]) by dhcp-1.cent.saitama-u.ac.jp (8.11.6/8.11.6) with ESMTP id g0FCbiq07643; Tue, 15 Jan 2002 21:37:44 +0900 (JST) (envelope-from taku@cent.saitama-u.ac.jp) Date: Tue, 15 Jan 2002 21:37:39 +0900 Message-ID: From: Taku YAMAMOTO To: Shizuka Kudo Cc: freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: Melco LPC4-CLX-CB support in 5.0-Current NEWCARD In-Reply-To: <20020115110853.2273.qmail@web11401.mail.yahoo.com> References: <20020115110853.2273.qmail@web11401.mail.yahoo.com> User-Agent: Wanderlust/2.4.0 (Rio) WEMI/1.13.7 (Shimada) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 12) (Channel Islands) (i386--freebsd) Organization: Advanced Computer and Communication Enginerring Studies Society MIME-Version: 1.0 (generated by WEMI 1.13.7 - "Shimada") 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 At Tue, 15 Jan 2002 03:08:53 -0800 (PST), Shizuka Kudo wrote: > > Dear all, > > Does anyone have tested whether this card works with > current 5.0 NEWCARD? I tried it on a Thinkpad 600X > with current 5.0 cvsupped yestersday and received a > > kernel: found-> vendor=0x10ec, dev=0x8138, > revid=0x10 (snip) It may work with device rl. (see /sys/pci/if_rlreg.h) -- YAMAMOTO, Taku Member of Advanced Computer and Communication Studies Society (ACCESS for short), Information Processing Center, Saitama Univ. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 5:12: 7 2002 Delivered-To: freebsd-current@freebsd.org Received: from router.hackerheaven.org (qn-213-73-194-22.quicknet.nl [213.73.194.22]) by hub.freebsd.org (Postfix) with ESMTP id D821737B400 for ; Tue, 15 Jan 2002 05:11:21 -0800 (PST) Received: by router.hackerheaven.org (Postfix, from userid 1000) id BD1B71C14; Tue, 15 Jan 2002 14:10:45 +0100 (CET) Date: Tue, 15 Jan 2002 14:10:45 +0100 From: Emiel Kollof To: freebsd-current@freebsd.org Subject: World broken again? Message-ID: <20020115131045.GA1838@laptop.hackerheaven.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline User-Agent: Mutt/1.3.25i X-Mailer: Mutt 1.3.23i (2001-10-09) X-Editor: Vim http://www.vim.org/ X-Info: http://www.hackerheaven.org/ X-Info2: http://www.cmdline.org/ X-Info3: http://www.coolvibe.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 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi guys, Yet again, building the world is broken again for me. I am using freshly cvsupped sources as of yesterday evening (CET that is) For good measure, output from uname: FreeBSD azazel.ipv6.hackerheaven.org 5.0-CURRENT FreeBSD 5.0-CURRENT #17: Mon Jan 7 16:28:34 CET 2002 root@azazel.ipv6.hackerheaven.org:/usr/obj/usr/src/sys/AZAZEL i386 I am also having other problems rebooting the machine. Somehow my /usr filesystem has a bad superblock, drops to single user, where I do a fsck -y and when I reboot the same thing happens again. I would like to capture it to the serial port, can anyone point me to some docs on how to do that? Furthermore, I made a script(1) of a 'make buildworld', which is attached to this mail. Cheers, Emiel -- "I'd love to go out with you, but I'm attending the opening of my garage door." --mP3DRpeJDSE+ciuQ Content-Type: application/x-gunzip Content-Disposition: attachment; filename="typescript.gz" Content-Transfer-Encoding: base64 H4sICJYpRDwAA3R5cGVzY3JpcHQAvJ17k9s2ksD/3qnyd8B5U6ndbEnyOB4na5dd5fiRzK5f NUmucreXUyASlOAhCQYgxZGv7rtfAyQlaoZ4zKAvqXhEEY1fN4BGEwBB6sdE8qomqqayZikR JfmpYeQftCSnZ+T06ydnp08efEMePnjw8IR+pp9Z/uc/FfSSEV5CljxvhczTe/dOisuUSzKr yKIuqkWfOP+++fekfvXm872TTEhSSbGGfORfhLaXJKE1STZZTtcKPguRwl/RliSlNSMMjglb S1aRjJcpMUckL4nRrf+0G1pzRTq9RS0ZnN6SismcyIIoKIraELVTSZ0TUjNVk1pCwZqSFoy0 CfnMk6ckFYQkFfmt3fBkQ77QBv42XYKnBIRLdu8kScmiUXKhJOR/9+Kfrz98949X5xcfL16/ Of/lmUkSq08Ekl7+cP7+9fLFxcsfnvGvv328P9V/e/nh3cfzt68vlh9f/PTDPuPAXmgh8yXn K3bFkid2iRXUKXl7/t3Fi4v/CKA5SJBKCBTozYeLdy9+CrQMivLm7Yvvf3x2f1YKVae8TMjs A/gCrxi5D6m//HL+/uXbn1+9Hov87W867ePri7dnYLpbC7gEXeimXZzNH88fEPL9xYc3b5bf nb/3mWiqppN+8+G9t0RqQyVbrKXIsmUmynrI+xM0XVjeuqBQIT5RMMvdno7UNTiwejLppF3v mGXkHXxmPGdzqOhTIlkveO9kFvXfvZPnz59rOC/XZMOZpDLZ7OKpR31qugwjbSPpBauTp3/q AlLKVS35agbxQN07UawmM/KbiRv3//tfdPb5xew/f71/lHORi4SCgpRVkkE4Yulv0M0hFuQM YtQXfyazdU0ekF+J6fyE6Bimow341KjFOwgZnypz1X83iYezPciEoxkU44v/Ad7/ki+/JMn+ 29Mh/S25/8XD+zoRAtpMZubrkPpf/9YJnBqBATh8h0hoDvscOnLBh9rwrH46fPTxrAuds5T9 THStH9WPSVt89+OruRSinusaNiE+NNeWykMm+HLvBLwWwjwt1yy9d/KnegcRgl1VLNGXHl21 mWgg2ue8vLx3Mjc+vuVzaByxZRDluVLa8/4CkpBFyB0pBVxEJNNt94S80Q3HrkCh+muoiXD2 YCJ8Cc0HTpk3KevyDpkX/dk4yM2At4Cgsukc/6lxBiDCpe2pviDOFBngcEpf8UY9xPhdQcsF K+fnP3749tuzv89O+2wZmc912ldkPpFDu0tIFwLROc05Ve6us/fgU+2PndnGu/szk655bFTX z0Lt6rv2H2Na17OD7ALR/zejcML7eXet0B2NQa/b1Rs4nM//kCi/v049e/bsOekql5eZ6E/s uxfPoNZmm6NOt0hoQX59SuoNK8nQS66lQ1Vl3JK9hOZzZYd0T3botPmlj2GEvCB3SToRD2Qt abXxYYyQB8QDaob7a0eLPA7hPPaBqisvprryQC7ZzgcBEQ+kDGio0t9SJUxBfJSk8kGUl6E8 CFWsfAwQcUIyjxWZ24ZMJTlnpcfdBikPSjGpRw0eVCflQlVJQmXq5HQiTohQ/OqRG2JEXBB9 gXcRzJjAnn3rdtat009Ttl3wxAnoRHyQqlo17mLspXyoRrkdtpfxYVrupbTcB6GlF2JGVVZI prSQpwMNQh5QljKV+FG9mA/GMxHAMlIeVKFSofysXswDK2s/Scv4ME2eB4CMlA/VBoBaL6YS EgYJftQg58NJEeALnZQHBeHfTzJCHlBT0MpP6qR8qJIL33XnIOaCcQUevEjSvz9+/MCJGwu6 gI3uFx7TehkfpgnANG6MnkTC+MqJ6WV6jG0WO0jDBPJWs+Lxys2I0V22+rE/mb0kM0H0ggNM imCKxBicK8ijR48IjOAXX8035Ma4Ph4NY5sJNJxFQZtB/zTfJCEpmaqdLgFFgZksTKswSShK uLUlOFZrmEmGXcdjHCXVlUVFdYWiAKYn0wogAUVBaXWoEsujYFpj0ZBUOAqUha9Q8HCpm+ZD AoKCbNL6DMP2YQ41raBLQ1HTza+m1XRp8Wq66deEji4BQYGZmk0pMAnxCkBwgn68mHtH9Haq E28R+q++GqtE8elLskmKV9LNKSdUdAk4Csxk06LDpOGogamoRQmk4Khop1qjS8BRQEuLAlrG KxhmtxMqhiQUJf28d1pNn4ijyEyKLXpMGoqafr48radPRFGkp9PTWnQKjgoz0bYoMWk4alqr khZJxTA9n1YzpOKoMpN3iyKThqLGzOyntZgkFCXdpH9aS5eGo6ZbD7Do6RLjFY1XCiZUjZPj lfVLCRN6+hQcFY1VReNWsUhEqbdoLHiV8byGUeHhzlGA7jtNCheKJY3k9W6Ri4ImYZqMqNZm DriY31yHd+o0e3X6c3ctW78Sc+/kcLPeFEdvkNCD2us29fJjget5P4mdqnlyact6SJ8sXVhJ CJ2LpgYVVOo/eoyvv614rbfnlGs4TkRR5exKH+kdIPCZrnT59baOUgunXF3WtDuXZ0kJByzP ur8zMLVW+lhqBVlZ0DrZ6CPVZ8lM8joX+ttaVvrchikudJ1tuKpZyrUWzhjLdCrPaJpKnQnQ 2iJzqMTjR4/hIKflWt+DNv7AV2umzcl5wY0avVVFf3TbDTakgOoR2ncKVgi50wdCL8F0h5UQ ueaU6aqAT0iALpHxdXdsaqHMl4MJZQ7G6k+lWt4VUqw+ZUJCkTWlovVGy1X1RjKaHo6WpS5W 1epTRFLgaLJOqaBBqo2kipkTa9MK5rMyB0rkW33QlKz/6FuIKKa3X8GRYvWnQkurNVSWSeLr kupy9S2goCRdQeEoZVl3YLoRfHbGgDNsqNqY7INfdAd9obsvunjguuyqq+3aOFXNC9Z/mFYj YEfnOBC3QYM+6GWa2pi65VquTTYmfzu4nX91ksqKBvp9VhtfghrTTaY36TF5OFpqpzfNVrO8 k6m7HEddUeubtgQu47VIRB4YqEnaFBW0Zy2kaUnok0xXjGw3ph/oVce0r8QbsWSv695JiCqT 92ivYs8RSrJc7+e9Ht32kUmHJXozwJpTR0LQ28sbYv3JI0EIF3V+XbA/eSSoey60izJtcSQ9 TjnKUon8Bro7dyRmNrjeoA5nj0V3KhfrieuLOXskCtfLggt1XXZ/+ki40ZdadnXDiMP5vfgQ /bNc0Bvy/clpYeiflZgo6bXEG5mhJqi8Wej+7A3xLZWQcKPg+9P7DP0qTfF7w5rr3Xt/9rq0 SjY3O0B/8oYsg/HnputRx/KHhOOtSgtZJWqb3KIfjftPl3mxq5a6Rw5KJyWSvHQJQFxcmsuL S6Cmh1qeFulit1UCon5dQbMUnb1XVsFLtvOK5F5KAUMdVzqM4H2I0q9FwjXSkVo2Sl+FHBK/ N6KmLgHwDKcBrd7jbU9XxRL6GVxsHCKVpDtH+q7SAwMYL7hEnIlXmXTnbip9IfC2B3dVpXbS BKIC88jAtYglHjUAyvMVhdGuXSyRu0pjyN5fN2Tvl3pk15hOt/czPWTbp8pubNX7hx6IdY4A 50yD62sxNdeTfQPCoWmoDdk3iD7Umfsa1l/HNQkazdDmUDPDcV84yHqtV8Ko2xTr+oTjFpFq VB03GDfj392D34I29cYSkUzaEgZ8VzYBR0g0aUtlBuqO9JpaATCEGw8irydXcD1YugwwAo6o 3gnIwpouaWtNqqzlgn/LQq0dySun2fCPOVP1ONeWDO7lSFq6GlunO5pLJ6fWUg3zqcnEq1Q6 PSy1Z3UnLYduZmfDKNN6Pe3aog+X5PDF3uXg4nw4WiSqMesQM5gzj3pgYu+BiaxP56KjG4L5 HpyXX8vLb5G3vJa3DM27vm70erB6XxHwD3xyCXOF44nVcZp+aiZoXmXJr5d+4P9hhWs42386 55p/mCGSrzfXB+th1UwO/DndV/at8y4ra27lABypV2L+cMToB+g2gcVRQpDBg/jX8/Xno6e6 9HM08O/rSd9apOJwoZvp9SIym/3ecKb3Qc1SlikYkXBRPrv/UYo1XIwL/YDFl/qeGstFVehN z7WAKff8fp8Bzsjds/tfjcr2hPylP/rrnPT/vSAvRVGIkryWUkjyiinzQC+oIm/5CqZIO/Pc 2s/vz3/R6KF0xsJR4fT3RcplYJcdUXQ1XQNdqyEdB2/hKyZs3snLdM47+tgsgznfemSA3c9u Ji9Gp8N8zAg7PGziZDcaXa5ZveyXAE3+2fMpwuKgwQVTt4eNW/by+jaCw/ngMAaydw5JOu9d HAXyxYQirdbqHjcSF/uTQQZqUYdjhBG0l3hiWDhIP56lcFC5oCndrnFg+sYmkl2qpZWJZfG0 btE+niMqViJgzI2BWwaavlKoXG+dYeFGOzhxrNyi4ZJcKOaF7avQDtIiI/+Og7WS136r9i0y iqWFasqgafJRpNW5zBeI35ubS+yh0fBuMTQqgjri50T0DI6dNBGxAUEjNrEMxWO7rkZEm1HT aDMA8RCBEVuUhPE8FhHtGgiewWQWS7iqIgkZXcXWRJYLETu4yArhvDAFIDa7SsReavUmAATE Ur+BI5Lz6UEkIF/DtJJGQsy1JA4h9W2/OER8BEUIoOp3GVuO+BDsi55Twwx9EcucA5H9ldIO 2PgJGxcCGsBDGBrZDvDZsG9kCwIqz0MYGsgO8NmwbyA74qEf8dA1V4ern5uwvz5aAD53cHuD 3xk8vgCXvcSZf7guWrO71XuzJ1H5r6ri1J2/vyhP59dbOaJynz6IzF9F5K9EG5EbUj1V78se VXiTP9KA4jQGANUfkx1qP1J7XPmN98QA9GjTnX8/HrUA9FjTQ9gPRy0IGGp6CMNg1BIA90Nm S/7DSNQOcFvgI5j0OEQiqp3equmE7MfDbobbEg8k46VvoSSIEGUEB9deRQOiTCjZVU0zvfED AxJlimQF5WUaZ8oeEmWKSmi+inLSjhBlRJBzHCZ9dojfCh/FlAaHgmAM9H2e8YSWKSYr3rBP 7hFaP7e25HV7mzPvzj08ceeNsHnnGZW4M0cU+JNnPOHOHGP1J0+X9rRTVH1FZB4tyliyj9Zt LIHECLht8EIwGHplx43Yr/3Y+rynKt1rAv4lAc+KQLKS7lvd+zUfe36PAW6ATo4CeJc03Csa /gWN0XrG+F5/kU7e6i/S4Dv9RfowZB/UrYiP0IlnyETJK1Zcf8AgFgpNdudNE2DMne73pVE3 /FLHHb904pZfGnrPT3uVcee7r3iDF8USziIJvZfEQbRXOAhTnf3dq4fnMJVyBoShhq2En82G 9DjGG64fIYxCvPaMSQNsyKNLkbOXm6a8jMO8orV7xOAjPApo1EduQlCjehghjepB+BvVa4O3 UQMIIY3qwQQ0qptwFtCoZ25CUKN6GCGN6kH4G9Vrg7dRAwghjerBBDSqi3Bx/vH1u1enjx8s vW07ukL4WAGtfAuav71vAfPW1y1YPi+6VRk9/nRLlt+zvMAff3jhd4rhim9HBPiCH+J3AT/D 11ohVngaKQzhbxs/x+vGXsQpQuOeorTuKUbznsa37ylCA59itfDpbZp4PE0uk0YqpsI2lBlR 80oIWfQfCa3MeyySWuY3t3ROzBp7hdce+xnO9jnJ+KURdoP6XMs0n9A99fr8oQT9dO5QIptY 6GxzyHKXmepQiojp6qAe5qVnk3PWSYHFUULvW8PjIUN5Zs+PyncsNXhAgJh+FN8jVuxqs6nd RwsR2hfrmtj1cg4lCBLUZfAKDqXwE8PERt5xJKjPTJYlVBQ+QkT78gRRXYIhe8d0XDmzrAic BSNMvcZj5t9YEN8ER8slTdMkejPxHqTq2F2sAwuLVONwVozFbhPuOJfr2EWpjiPk/t5yHCnJ GcUBiTx6D7MBpSzHcUkAMf1yKAwWu6pZidJ0a1bjFE8/ZoXj3UDaXWGAYICCUjTNQSqb3tii EiSUqOrohx46ksKqKIVWT0igSyZLFv1wiSYVolGxzxL0oC0KRzQ1lgfo39/M6Q4DVbkfSAzG IDxlcAC1GCTJMsminxEyKJXQEsUmiCVL/SpAJJZ+2R0GKb/EwOhRpR4yobj4MHNBQiE8Ttyx RIMTe2tJE5Sw0tTxD+NpTsvLVMQ6ecoy2uR1N5yL9QOA8ZLBJSE20AFhpd/DG48RsR1lmAbH USCu8c/MzOLiQG1HclGmFtvGhbCsx40LankU5zB5tD3HcjzHtDwTkGyEeZNsNKnYIplUbFsk EhoHr5ZM+mG450UNkg4aFqxvQDTjeh4ersW2r0U1ENk8XONAJNgyLwkHZPwDySjDwkK1mHa1 aIYhmoVn1McX5xfL9z+/++71RQCtdnsWJOv1EByQ8DxnGQ5ybzAP5iikkmEVDKlcGMVKNmvf W7tCKHrYjFLNxRbHIuj+OCAYipYp89yVDgbp37SIBbVovbVF664tVn9t0Tpsi9VjW6Qu22L1 WSTPbvF6bYvWS1q0bnK4eeWC7KWmIVlOVcA0xkM53P9yQgYpOySorTwcCBwo9rR4FIxije8N OjEHORvoCoGyyXnp3oUUxim2eKQtGqnFM6rFsgqL06J5ElotodXR6La3i3MQs2FkLVYioNMG kZhwbxsMIjHza1TRmBapilq8OmrxKqlFqqWXH95+uFjqGWgAa79DwuICtFwmG1qu2XgzRRTR jGvMTxSVIfXvwW2oOrovEMPS9+WximlYFeUIKE3BqzAYwkm0Uo72xbgwBzHbhQYN1CKRsDjH G348pIOkzakUSOHBmKyRYC1qOVvUgraoJe3uQC23TCoeMu8c7dKaBjaK9UIsXZpfEkSAjnZ0 uTgHMXt03d8pjQEVWySLoIcjkZoSCYRlEKSHrWOPdtlZSTgg02xIRhkWFqrFtKtFMwzRLDyj 9JoCW+8CJs6HTZdWUkGvkEgVlUgkDMxhm6iLspeyuRISpkXh4FB0cphPj7fI2llIqK6usQzr aGiwFte2FtE4VNMwDYOxl0okYwFjqvEGasuCQ5m2HIV0tFk7EqXwzCpZe9ipFYfSPxCExUpW klH3c5k9ab9r2dKAyUYgYDY0z8CxaMAQ1sviZS2zvAm55eBlwaB6v0c6ClQwzyOsYZhSoLVc KbAqvBRIXlCK3zlWy5VC/yonBkf/LHvQvTQvC690OGXDK5n+WU+6YShdpcUza/SwjJujvONF JFCLRMLiQHroIEP5xowKB2RqG8kow8JCtZh2tWiGIZqFZxQvg03yeRUGRvsBHgkJ1OLZ1CIZ hWYSlkFGKGhrw+jhQdvEJdM/27xeFjDyQeKpDctzLKBeIQpZI/GCSloVAavTXo5kes6BWWcd EbXWDLIOGMf6SbwSWRa2S8ALU3SLZJbCcgu9LCiakFvXBzFLwNHp+im2LGDYHwSDSRuTW8+r j8JxBVUBcyQfytx6QKqylpX+X8oMIyHX/jbIpq3HJASK2TAhAtpt/DC1ZdiQJligHAlUFCzF QUE1bRkOqgzocAEUgcPpHmrGKZmOmomUzP17T4GwFpWmf7glaHlx/KT/NOroXQDxKP+v5gbC StYGrZtV1HV3vAp/cNEDKqFVjl4JEMFC4qhmhVBFRTJ6+YIT4/k1gGI7fvmCl9S6pyNoLDTQ tl0istBQeKRUNP43UBrU2IFtY+pU0jYoRoXAAvuLH9Xeqh8H8LqChmw5CoKhGVZsR28dcaEO Yta+iERCwkA/RCMhgfBqaPx+FzdpJGmHcd9raW8DA4+rhQwID4G8oEWZMFbA4HH0vhvX2BEB 1GIZlF+O3iHoRPVv4HFzwh4xDGUFRLxAVJgfBLEQS4hXQKTyBT4SEQAK2xLuBwVGFy8npysW 0mG8oFtd3P04VFRo7PSikNxp9Cqqu4NWtIHhT8iQ8fjtXpatIPqxmLDZWghO72nmCSIrwEdD WJc8z/FKmYtyrTeT49CuvYQNA4dr3P6lbj7YIGhBrVnYUzZhqCynAQs7YayyCdigFYYKuoEW ghJ1wEJxAKhq6kDPcoNSli9BNGwz29EL/GyTHJBEIUEJAx3UA9JXDCprtCLq22aYVabvmSGy mgqNVvNb9cgQWnCfDIEF90ofrKJYNRbeLz2kLU/DpixhLDS7uFrq27Jm0MMC1kwPoyMrr+Ul Gs6kh903DkIFLbz5SE2Jx2q7EiKQzJ5TfY+kCtngt3+96TQs47nvF9uDMHpTJi8DAr8HBNEh qLo9mEu2Cxt1eThQxRjm9D+AE43Rz0+W22gOeFBQqUavtLWBJBKoqXBA+vlqJJvMljAETsnC bgN4Qer/qvvTJrltLF0cf307or9DxtyI2Toq0yotVvfE3AhZkm1NS7KuSu72nd+L/DNJMBMq biLAzCp9+j8OQIIANwAESu7paJeSB895cLDvQHMIRHRfWK3tG4kuAGNkjUXBN5MBE4OECOEl mFURIU2O9lMXM8/wTkDni7Mvr/MTWkkZ7040z9ze0LqCEyHlliuqxgGbfCPsoW05RfHtscEJ MtihPmBWRwlupm0TTvYvX0cJPPC09p1q4duqF8CEqs8DYK3npNw+Uij697+m3Heq3MrYXoFn 46lMbHc7tyBhuSVdeqdJS+YqJufYIUo5fl1qcFWv1BCez74gPuW+U+V62GkUV9lMHm/drDM5 w/tk8ta7VfHa6vpEbOf9bD6fBOw0B9uc3mn4ZfWOxSWvQ+duMrHBwTqlW/woqb15yyMu9uLd x3WZiJu1JgeBok/24R6zrPF4Mu+MXXe91C7XQNR4ZhgRvVFDfR/REERye7UPjzxo5kNyod6v ulQhAtNm3iA8Ges8hkkmnHu/eSGYvB/g2BPE+lloX0XeWbBpWOVXxr4WVXVZodo77QOUqRpF 2akktJ96CEK1J5FvM1PjPCnzyLv6SauI9bG9H/UTNaGp0bNNNBPP5MSOyDQYwVYywx5SLYMZ 6dIaLc872dPd71NsuMvYggziCC6FMR0NkQVgZnNzhYrKcBqnWjQkLetbPwZRh8HtUlC1Hsxz fHqFvkRqPlliz9UZGI6uIagOTMlgpnUYV74Mk+UZaSdCQu8ND6i72gfNaFBC06qYc4LIt6QC ER5Kw3WtToR9mx+E7RIyRxMW3vq+omnunwVJW+DgItI7KzoZkFlCDgnPiIozrssiN23lcGOt ESmbOjbcz2jHyXsM+8zGvL6bO7PmWDAemxJnRRTMIJtYsmIKQcRbezasM8zva6OBBSbogwai 4neShKGKTyi+LUplQL1IaOjZCErDSxZWTE2z7wc0M0TaqGeRZk/v0uUG2o6rKQIahWonk9SJ K3JoUvvZHECvmgYCRZ9pIO7x7OTs2HXXS5XwxmXOmsuRoP3nyd0WP37+zHaykU8Gi0m7eF8r H9DilWI6E75RgqmYo4IvNjDI+i9CshYoDR/ZyP6LMhxNzyVzF+t5QI5ePQcotNekPtf0SX7h NY/iqfSfcN4pYtsUFfiFUbSWJjSfThGau8z3Mvj6BGG6q5KD5l6JwbydLYojx50U6vF3YKPo geTrtWLJfLQNY5zpDdYyD19xdc3+imWTlbHLaFfFLtPziV3wdnatZOS4k0I9Lh2W3datuK1d bLtKSXw6bmQF+nQynAOnXStyMg87B+xA5TTR6lm05OD7fHFygFkdT5JT5P1IfF7JcarHjGlc eD9RXiPWDbye4bi24oDDDdXRk4TgYxXBrSPeNAQusia3/kRnFHuSsDE/DCew7zviLEh1480S ZZH3899RHT+p4Z04X6JDxEby/qsGcYDlFJhNlxOD61n4lmTfNEoilJe+9VOCzgGiNsGsgqFl 7bvMxHhCWJNFSeKbRkkG2aU/w+hBFKAZkQPL9Qx3rIryXN/KKZ9b8KUp8kg+lLGepUZ3vivR KfVe8U2p79IzPMvA5CnOfPM9MPWT5D40/ov8QHLxreEYSYLJrbqU5cVVwiJvGK6UyEllH5pj HYimbJQFJh+qQEv0jCkroyQ6H/2J8oLK8zteREWwCC8Pn9MSjqT6U1XREYUptZX/jhpgQahG 3p0TIKrLY5icVF2CJBql90F4YPmLXzHqT3VOSaja7RykSsrKgycFdJl4feSbFzFhpd6TI0v8 ewnQD/S1Iy8TbwpyjKlvlmMk8k16H5I6PvuTkMK3lilw7FtyigDNppiN8OQIMEqoCGY1rm8e qS5xxPr5vjNOEfaOE5g9ePLce+orSqBlrE79s7rryWCb1p6e+m1x6ydqYhY67DusI4h+9t4b DNNg8rJsHxbW5McUU++RDDnl+wDlgRUHfu9z3VS+RTxIyRIzjqV3y0gyhLzTnNa4OAao/BgR hWvNo6N3sO4J363qz+LdTjKSrPQdutAY+q7H2jepaAwPhinvMnkx0f4GBj+eECHD3j3fELv/ geNrWXibQkN05elX4t1Da0LM3zcBAtMUZ+ybOk2I6q4JkNXOEcwJ+5J4x0deFnx93XtRMIZX tbwHaVEmN/p6sVQn34McjIXEGHuzHLKo8K1pMYkLeauFB0vCujC+tQFm47Wo8p1wx6xFvCDf lgMT5T5xHxa4NcSbhVSR9wASk6aqAsTLXYikzg91492O5U1G8eGe+g+t96wkHQPM3QYIFIEJ 6TjyHprQMkQlQ8sQhYmWIbIeauLtkxmGJ5aNa3rtSQErttchYhbybVkn/rFCT6gOMJ0OAQuz egErM6Emi3EKdgUIHq7gnddQZgFLsKWeIHP9VV3SMggTQfXZn+iECC59p55wusdFgu5oGSDZ 4N68ABT7MDTP9mVFcVnsgzTtnLCmp6QOwpfh4jbA1pSC9QqZOf57KOo4981KQOG9wxFOVGVn 7yo7ZlHSH1T1oYHi6s8SYAYzin2HEIxhz/LcvkL+G/oYFetBxfv+9Ts/LriynhvmG9mcrazu 96yC9d6ExslgrysKRpegDHl3p3uiwHaFyhtJ4ztLAyyp/95vQVPm+/48qReX/5JpyxIs4YCL F5xglgHbvgiRgMD2pYkynGLvKr3jo9FxH2C2CugCbOkEmjAxT4KmIwkc8yRszNMyVIE8szD6 9lz89zgyBvXZFT8e3np5R46k8p9jAyr/Gh1YAtTogiZMjQ5cUKf0d8B7U8G6dwCqAFUT0JBw gSPhAhem9DOGAOuXVUnw3SP/a6iO6M6bY99uJP1+hud7K540xMgnRXVd+sZtyq879yWB/cPe 93EFGMalAQZxaf9OwXqOADuOUoKQ93mHpggQI3A6wHeR4pYi/0sRYS3Kd8MJS13fwNSof+B8 /QpHHPlvnkEULmvw3RGUYN8pXJpXReS/gyFARosOZe3dZz14z3DA1gPfBfKINcD+gx9a+mYQ RuG7zMMofGfGDoR13b3nUBPsuxM6QJrw58p87YBjLd77JKHJbQ7+PCcxA+c7gZ9Hd/5lD1j8 kznzNyQLYEUIMwLYkUcB9lLlrNn0nk77Qvzrd7iU/y4Ij/eRiCAn7uGC3QB3GBNap/5H1PkG Y+/d9kDivSsYSJoAe4tZ19W3fxSk8YoD7IqERA5DUwXaDnzNh/e+RF/5iWy/G5gPsfcQ5QDT ed49Hb7Z35flK6p9u/Vp6t0Yw8YF/3Yjjr1jFVhOvrMlQOKdR4AkRHACDEIZi/9aRh0ikVme j+HBaP/TUUAU4JSMf2YBkiDBKb3PLgOLd5YDElIF6B/4r1MwkhCTn0EqWkaSBYnczP8EHa1D nAxkbfuh9p16ZCxhyhAJcXguSL71v0qKd0kDxOxd6r0FhFwi37sDLkHaVLg8li/L4ZLvbPG7 mE2yZYnv7Xec6pw/fxaCB5bmLgE2Ae75/JOfQVEcoyoECSH+JN52JJ/5QMSTBZf7OCpilAUg Ek2TPw9fRApBQ5u6CEBEGlKhIoRJlwhTuLGZ77MLQFdjbx64WNeXova9mzI+wR0DvhzidLcv C+tJeHPAC7i+HCD2JeFX0MOdQv41hVi59+QoiwJ513zQjfZjgFsGz76Bafd4iE06MAnjR5fG BfWthNMTX/X2JOEXkHpylN5VQgrPP/vfVgt3fsIt38i3YgAuGh0ycQuaN1d6CsBBGMq3NMG9 fNi3xusu9wsQyRjqKt+2gN/rBw+LeNPAPXP8+JE/E1xE4c8SIq2qGpes63Dvz1RnOPfulwNP Q6JjgEgmIaKHsAowTJoDU+k95Ggb8DJNogBJ1nhHkXhI3pOjjL2bO0zglS//2utzhH1NgRvj fSmyJPXvi3OWmlD/XixjgrtR/VkK2E/rzRKgqQOWe9+JFkYCjzH5Rwyt4aimJ8mXBjW+JHDe 05uCUO+OZ8Y3fvpx5FFyxt7jlBwXcVkHYDmh2rt1zG/9x8b5bYpT3yo7vy28K5U8wOAizyPf jhRcdOpf1zKWAHUbYwlQt+VlU3hzwDUC/uPzPMDILW8K/1QuoqIUt3J58rCB1tk3RAFG5rDX iV896EmDK9+qrSq9uzssr6Xe3a4qRCP6pSlp5N8bDTBrDRQBWuMaHfznDmsUn70pAoyianQu b71JAkxI1bl/O1zzobfvQ04o86+kCcr9szwjgUPn3iSlbw1N/JdngCLANC4JNBPGby71HtnC M1soEA3xnzjgPEFo/Od5SIiZEHLKvXtujCNASTyFKImnhib+S1cEH1lzissQPBllMO8RAzzF x4o37HnyJ6rLOMxrfEHWp+Gy7jAxFGaVG2Y8/TMiJ6ki7/Y2wMAKKFLv2vwSVf7l4T4P0DkM MDgj94Tv6vdmiSPvYQStmyKOvHdBNAGKdFO0Fyj50gRI5UZcOO5Hcg7Qa4YdL74UAXa5kPiE kvYSDLH2tc+juyCk0FOL6sh3XlmS8R9N5r0GKgjvMcq89/fgImH9v3Plf3QsQWTPX7z3P8BZ IAqTITjA020FJKH3OTJYxqziILdwMp4Akc1Y/Bn2xPsAJLDEWUH3UeMdyZIL2g7fUzo9WYhj vDyyznEwyzhXSMP8n2ftmNigMgDTnfcdo4yF71/0Y/G3o2oOGWZ9Vt/TEDx+UdzU3kke4JBi Hyi/44VQDfkx9FW9H48hoSeEu+SQi9vTZOG5+j9T2gDk7ks08u6j1RzqFZ3rSXAtb69eTaKc Q1rNkSJ5MGA9B+x2kCVvNQ0s5Pmz9JcOraYgtKz9EtigLG2c1ifiCvfu4sIZmqOGmmWqjwYe wDQLLNc7go+HftF4koaD4HW4bgw3y9SP8tYTPd6xwe8TcYEB3FmsXmUwE8peYSG6FFYWsctF y4owpqjOcbJfpmpRSzxQbyUGi2CfbUy7ey5msiau0+XsYMNS8qk8f2tgsS0gjyGa7ZgurDMT wibYSROChyK4RSVAymcWjV9mqJmSzKLNMZPAFjAvCmYFP9bW34g0w9R1GZZp+KKTF03sp37n oX42dYvM6j7Wn33Nv0T1coNtoe8VACDwCYGvAZ4R4Gs+nMTJlvUZwkRgKD8WDJUvg6EmMBOc vQm8wpBSso9POEtqQw82bS8JXaAxVvVmDmNH2kzRX0W6mkLeEbKKAd5Vldd3z/ejO8gCiTFC rWjkzKQPCR9u+dPkkWnkZ0VTyKuavVia5R6BFYkpr9iR0OXW1Iqk8WZhgItx/BdfDIM/NjqJ cNG/3TRPNUDO1HFFkhKLPNyDZgOXEmOny5aIVGi5+bUl6l8vWE9EVIgHD4vqY23B04NmA3Y0 TgHY8siLdtfzEBXiy1M2VRgqmEixKSUabjbhCsswFmbbWJEEUAAmMkB5s1V1ebSJMw03G2fV xcKwHjSbSauLRSa14mnMhcbEw9eliU11YMMUIoY4j03NayJiSUbpvYVFCmo2ssV76N5M8Ahy lDUVAwbgKjjKm4hoGB8mFuUNQTU5oWx5vMY7ICpw1rKgfMy+s1Xbd7ZojRnmcG/TIBvJiIbx YWIAeNs6SuAOghBs/Ayjd2Rl5aF/OGeOiIGWc3u0PNjDBLdvBiwwpF4UlXmQVZlWTmhNMGtt lvNzpWBmeO7ZyBMf4UxlGCZjQ2lm4t0d8baRqT9XXeIoPi21uFCeBZepmTNz7WEZ5MnzRRYF MjMpHIIEhSD5HIIki8vi6E0SwpI8BEkRgoQg5M8RwpAoq05Rfwn73LpoHMlFrpmMn7FE/pwv Ty+x5qeDzLAoiNUkQSxpSUzrCQ48hqUiIxPUwSFCJtaUvWlg1kxecjpPIjEzxpxYrSt2GC8S nZTNDLPBipLENO0lAl9WSxOlDJOgLBATyit6H4iLjVVCmYVJjvIDMmRJGy7+UPIyDb/eV/Yf ZnlSuXXOl8jUA7Ql6p8W9CFK+UWAtDTNg/JbaQV4uRMV0+xwb+xFCaCRCXhomePlfTpGMt5f zcqjiaWDzG+m8CYh/Lat/rnttTxnBbGahMasN4eXxxM0htOehxpFt4tMaVZeAhHJxwa9mGJ4 LBCTinVmjGz9C5QLXGUorjy6ZR1gc2yZmUjAEJKAIYSjGUGoKCzS9M+DejBhEplmicTs1lKP gCFYkVqudi1YvjJzL5FhMoejlofQTXHGZJGkRyyTLO9LsGAxGWJDsGzEMkNewpbmmjbLPUcG YwM+WpdLzQUmRWPsf8Ac5hEvz0ye0J0V052JKj/ky01gfmDpuJTnGEAiPEgyw1aDvMkoPtzT ZRbW37jEy/nFjgh4vGmYKayPcfC35xIDjzdNyu94NKSVIaXggVpvDv7Ypi8LNFEFf909ABMg 4NVMw6yuiShEsAJEsAgJq4+W9zPxLqMM88xMCYkxvoYd1otUALjm2AWuEy2L5aYJMnBZJ2ip vQWW5SJlw1LQ8uRvC7D424LoCdX7iJaGTYAAW2qqBA+sUAeiyrAhH1rysGiKAvFA6PyoYJwM 2RWbjt9AB1HFzcwIRXivvwjkRcfGHxBEi8UqgB1MPUKJM5ZgZ0bAXYekDBXmk1Va2FHZpqwV GwkbTsjIOIWEXa6CYLSqwGbTAFdFmSC7rNJhLUy0DLIlo9hcY7eFxbjEzDB2wbUms9kOYyQj GsaHCbbV1CUtbfaNqLj5TTGAsgumG6F5NGNHSQYoPzYWfwTVZwsyFTYbWADZRZ4DXWVaxrKi IzrIiwunezG/qrzNODdETfccxDosy+W+5QzLCNVTYFZjbcK6VMvb/RDdhyExdQJtSLIiKg17 OixYYF4ySJjYfwHMYf9dynp5ntyKx9SttSRZnlmyIak80zpAjISJDNsI2VuSWUWMBdmzfVnB bXr7qH+LfoFRwkkFV+Paclf87reHITeuM66nNi4Yrqc2ni1ZQV3TU1Ib129VrAtvO8x7KO5+ oTQ0uWUquhNnEWEDGnOZXsNdozMb7S93p9ZyE3TMWUcnXGzDhg9z2w4oCVogMla4FkS4hm2A 5XLFX8f50iGjjmNPls0x0IDzPlpu3E0U+v1oniS+xvjHbFLs4Z3KZQpEyuy8OL3IaNBdFRmq fwsiBjHXEpY8ObyaUi8vm1pSBSMiiN+oGYTJP7ZZspFbXBlHixZUBYGm49GzMDyPl2f97Hiq Jow9jMffnijO2kud2D+p+TKIHm9HCoT7YrkgO3MmwRiPNhdgtEAbquWs70JkE0Qzl9UFHy3Q hsocPlsim/CZufgiqHUm42g7Riv7THxxVO35c51LRACKy+p+3/X3Z+bj2udeoVLkva09Lfdi O+IifatnwSzIgFb64clco6NFK35sJ6BmOeTVET4cxqUMCxLjPlPV2JksYXOXX9pbO7O4gAxz QWYGVmSK5UVAM0fV1EfDTRv9zsP5udxlBomYMSIx39Vh2EnOktWbgzXGhnBIxIwR4prpRQp5 pcj8JpeqNJjBH7lb4AB3Q74wU/ibQU3nMq0Y/AIi7kPzs6I256ymMOXPSwgSuDJjkUMCZktq zCSeFMs7dA36+W1CkaE9yW8lZI6EBCMx7G8zsUSkYk0uXa7KFchcNRyAhBRBWEKQnMNEyzlI vJyDkISJ3XOg7NIYKgIJmG3qjBWBmWK5IjDop3A+cTkeesRMVvWnOAcw4xyCIkBsIHpo0tR0 Poyjlmlg41wH8uE5e5NA5Wu6WYP2kBmSvDKOn40kES0NvRlALJcXZNjRyi9YOy/HqTdHU4Rg OSWIjTXL5YnLk/L0wAyNxaSlBQuKKuNx6C8SMdMdQGwg5M0CZ7cN1/jW3Vz2TBrXxrluC4IE LSewgQPmyeHVKsNQ2XR9NGzLCcBicT22LYlNvCzzwIFPQ00gMCaSLwE4MLxA5E/T2ASoMdNY BMmCxSpMizyxeZ9D3kNmZxQMx4JMDKza8jejJVluR40s1OLRB6rUxTMsxl0YFhyXKFteVjRz RCTu3yaZm5KViJn1KZym3iTH3JuCH2HxZmHDVF8KcD4uV7ImCu5ufCvAMj48eUTSeJK0Gc2T pSoJvrs2JhAArjl2uYYs4oig2HQVCK1V2BKZ8baEDrJAYmGN2ZJquTcJJNXSCwE2F7aoByJm TLkn8DCN8eosS6rCeBuNBU8LMeRDO6bMIsWz5YjmDfCt2RpaLs2rtlnU4oYNsrhCBXnHm+SS o9yUiznmZGQxZGM7lrw8L9cWdjSmm2csWGJiyjB2JKflFLIj8U8hRuKfQIyEVMuz+VYsxrJo yRIiRKYj7FYkxubEkiVEOhsbFCuW6mDYWG7FUgfJ/kHynKmqNJFc7/Dj58/4DhBcsiY3X3wM i2OPOtbAmiXUjrIDzkxhACzO6v3F+E6A9LqHTtuIojhGhCyap0CmScihXn5ArHOfVk/jU9I9 aj5D0CNmKcRG7GWSHjNLk5eJgaRDTFNk/hTMivJSGCg6xKwVvhQxvC8HubJGhmjtgHw8YCIk Cs6XMWmq60UiBlhQl1uMuu1oS1Qd+KiCl3mVzYahqdttfYFZyYOwyv2RgYlD0aUnmNFdZEtP fB+DiSNdLihGFnj0gx9wWGIBEIa3AGqMluoyWPCAW4kNXB1kpmZHFEMhXI7so4aa3WWRlUdc LI6xriVs2aYe4sED+5IsIqg61kuVCCAqCxZTNFc1LmtM741EKm6WjQ32c7ycp48aapaJsKq4 rIxUKmyWC/JImSaRMZA6cD5/N+aIbxYjHtV1US73zeAOsQWGW8QPXy9RwMmKZqkGypvC+Jhr LhEzHGWS8sN5iyRlIjHTNE2Rl40hPD1ipjKsInqCp6kXWTTQNFHFtxYukUjANAE4n/0I4jPc yW7giM8GjpwcfSjg+IqJgh9xWaagy1ndyNDXhfMUfZ06XzkhYqp3BWq57B41jD9TCJuIRaNL TJUSsajZbEj8DTnlhpErQ0SLVYGxayUBMwMZX4LUomOmQKZJ9nu4eRju8VykUTAzxsBNcjFs H1ji0UAzRA00kcuhUiAzcRuC5BJh+niRAhAGgie+BKYemIGiEtvcFxkkYsYKcF9ua0wUJD6h hI9Yuk7ePjd0c6dUojujH7UYGLG+DarPkSFXr/MCuqpRHS23nAJKVKiBk/9oMsOARPLq8OmR yQEXiTxjbDgzrWKXdwkViELvBi+fgzoOgbODJwmzu4bKSCnu7QpnYhHvLVYr7clIODaRGtDf tGCTsKVoC8MF3Y4qtrt/igGN108JMquLu4x0LJwKxoeJaBgfpqihp73NLk3GtI+zgu5Bw0BY lAXaK/sxQ3DCKvmDUcKJ6KjJDIf+Lak5JjZdUC7ZALn4uDOAKjGoDktoOibpREiCm2hTW1kz cmCwNAHgoS6jJI4M+z/WUcJdFgFjEjYpwopDOEaYKDLsWHEjVO+VNzOatnoPUUEZ92dkuIzU kdap+rWjrATMpQBZ8ZKHIk6OD5BedXR5AFaa4YdgrR6A9ByHJSWMkKUUKuBp0P7BxCViUDHV AIBBd6Y7dxzI+PXXteEOMRdCuPAsMF+NvsDNR7nh7r4VrJXp5IE7p2mHmCtjFQPS0Ke2Jd3v W1rByXJxEi6lIDJDhr5uwqU3TC7XqMrMTYcto20zTPSaZYHQrvqx5rNvJ+wpLZtfa8I0CW6j Q0tmzenQjtlzWrdi1pThMxHrvPRjOBNh181dZEtQbHow04mvKKvacCTInW95SsqJD9isesHW jGwsTlFuM6awpryg6DZQMgOqRnYR2OEWCnMwpqYIx8VngsLQ3VU1BQhmaWqXoBZ8PKyhGGFa D3oMeWS42QOAePEQbEdlvPPUnsp4CMiSqs6pzZyHDZVFF8iGhh8r9ySCjNoU+M66WVg88zhg s54JXGaFaGcoXxYYlNnPM5nJXLoRRjIa2zf2RrJwCcrZkmp/aNKgfEHIYMkv56+xwO5vP66K VV62dZgllfleYTsqy4rHhspq7GWmsap4DERd++NfsPmMSzeR5sklRhy+OaBl8Y4jbSQegMu+ zTdSuXQgTGQOQzwTFdR8AemCVfGMK1gND8EMWCW3sRbGtruEjWdYFRGIxngi2I4KzgdVFLaV WM3v3C3egM8J2wXPKqpzc2Vh5oMSfjL3eC2ZYCOmP1NZRV8aZDe2N7PV6DOKQyYB5wkT0qiu o2WTzByH0jDRZ0FxTw3LihbJfzLcMGemsJnBs2Apm4Ph/i8zCSqa5dsxzBRpVhqOx1pwmK6l MVNYXDFrJsGF8XlVGxLf6MhKw93ZRooc5TbNjW0d5UlSlXyboR9LjaxmVq14UJGULM/FZb18 848dmeHKaysSeFYihEGs1k5RjQrDFelmHou7ki1ITqYRmpGD0ASXYfLyP5g15ivyzSRNiPao CVDhMJIA0csGPdiwwGzmOLNukGG3hwVJiX1L4qWOKqdE/s///M//s8nwYcf+Y0PJP/4BF4Sy 3ubmKt5clZu6LOnm6ri5nBBisnzz5MmTzWYjwNtIkLMvJ719NatJFpSvUhKfjtJzUm6fKixZ wbTTScedFFqZWdETHM/ay/ccNlNx6EQVR6xyzEKRZSgqmoq1cFVoxu55ggCUZZGEjEBGN5zm DUOqdYzDUPZvY4XhI/hYRMFyDzDC6knCD6cEJA3JpzR23mQJolEcKl+jL02wpOj3c3lTwRGV CsU4xXEgxs+s/xyI6hbdh01RIFTv4fQnxFmoRM0biu4C1nycL3AtJTgDVlOCkB8VD0lI6/vg nO2Z9zCUpRzzeFPVF377TNiEbkkDpnTLWCcBY7HlDJoyLeelDs7ZXi4TPpm6i2MqzpSE5w6e Dbrbe8JazA9PipOZgQhRlgajCt3Oss5dHpFQWZSyfBlksEFQHiiTAxPL1ecoa3zrSqAKkImB pn9EyoumKr1HI0AToOvM8pGJZWomQB3sWi0SjEbHFrz8ginohJvfMFhJf2yiOjG+LrmSHBcn VGNxqPsh+IcV3kOwlxmOHyRhScyK0oMQswxza9wx6EP+IPnF+DD2GlLysAWIPGQBIg9cgMiD FiDysAWIPFQBIg9ZgMgDFaBu0tC+EGnTjJbkLq2cA78c+Ntbr88V2NK72L/Oh/a+vxjhzLSS EMCjkpaxYZuFvy/qCOWhPKH3lgV5nQ/kW6UK+SapMhw3PpQnD5Iq7fQCre/VmRCDB+O5E1tP 1GkMO08UjWVP3PufA/gyvXvr7ETP99HCcNe+YzQYIhvN/zb81rnUih7GlHFWkmVKbRw8T9TA BqXlzGfJBDk5MrSN2nB4sD4dZYg1x/Uf/xAnrW4d7waOm3/+581Gjpdfzq8ndwrbk+DCRZw1 CXJYye4IVi2Dt8or18J1A0i5vZ5eCp9E7HQXK6Ml3nF+AUWwm3y5tdK4l2gM5zPteT778hwT U3VgQfI5BAlzvjfsl7Vl8Y6VS/f+uydHYti4O6DR64h8pnrIHWqGnGl41Av5yioh96sN8qWK IJ+qA3L74u87GQ+hi5MDa9jJ4jTwdHqL5oUNfc7YsMswXuw3SCaYxQ9Id6DLXWVLmioyHHkz 8/BmP0zIBFW4mILOWnzwJIELPfb+NLD7258Fblq02VRpZhIRvIeXQ4IQxaXhzSar5AqQ7gSX +0ODs+VR3qh2MLHtz5gYepIunBa3U7jThbMRnqMPaKNCFzgeURE0HgVd4Hj0IdW6GmXOyr9D +87x67oGXHWhdzCjrDzMu7rhhtmziycHodR3GTkOEZa4P/SzmoNBvnivZGfK08zrWWqo53Pf XcA1ukOxb8Q2BNXYdwdIjY7yVk/73uFRZq65KYUOMK0fkdjiAevU8DZxjXLToSUl58xx7Pu0 mDv8qKT5NEtmfFw8Mz4MzlKCNMu9IyWx9HoR+gxFWk4Ow1o366FYi189Fuv011S6ra7PmKzz fnZcNgnYaQ5WBnfwhaIzSCKY0JxLInBzSSL+FoZHEnH9lUkEup5JxL1nKfB4LonGgJ3mYJtE HO5Yu3VBhKvdmxy+Fkul6ouR8IgKVEfUdPzJiRPuPAtHGJ9QfBuWkm9GChaLBGUoDknIRze5 8aVVhyhkrUVD2TiefWBCcRzK0o4YGRtPM2ew3B0yVwfLzQFzcZjcGyzXBsutai71NWptxtRa SExup5tH5mDdNrb49W0jKDs2jJ2aYzvzC8w/vpKKcz1HhXya52UGL1sEIPqRDdVC8LxCh+YY gugG0f0PuCT7n1C5vJRtYxR/nPblqTGsrFpEeJllUUWCxJXkCmIYP/IVhOpFlu0hP/xw88rX KKiKPzaZ4U4WixRkzvv3Ue5NxLMVK8j7d8flnXoOVD/A5g9fw/4O74YFyVX32f5Fho+FYauP mek9uqP7cHQfanQOSPepjuLbkCENScjDGpJQLd77V39/886T7110i16hcxiWENX9qbzwwP2Y RYZnDWyqHUb0Mip+QB9Z+fQkIxms8MCOob3xDS+dTe3hoAQ7TF4DetUQHRR9xufcYzb2fjI5 OB+77nqplZGA7S9gWj11CTR1vH06Q/J0ZjtK1p5jJnS57tesnOVChnk/Oxbj9mU7mqPhokxr luX5UGua5SJsQXNio+eyXp5qtqcJkVgdVaAUY9kc1TRMVjTeaWZHo2wX8eORN5t40dTIdP2r NY/p6IQdURhzSNnUhlX+AZHakKSsiJ4mx8rcxXqwzNGrh8pCe00LxTV9mijh9ewE8oTzThHb LeQiurxaOJVmXAmGTb9+fLuYuD37AtFPhqxmS/Ljpw9heLDhJkpbop8/BbIoSDS/NV2Oa80S JKI5UZCYBqYwUQ1MQeIaBgtBiD5AMxWGqQmQ+owkSOIDT5C0Z0Rhkp4RBYnmG2q4P9aaJUhE c6IgMQ1MYaIamILE9W9BWo7fQjUdvwVrO34L1nj85th6aN2vsp7e8g4O1p2vKeXddgv/5w/e MWkRN6yWIzvuBH/W99VAeVVXjSl69dTA49nNGGPXXS+166YB1m8igQcRYrpcPGtjy5RENArC U+MzCmJRilHmu1GsJ+JHy/GhkZesh+CEbaIBA7s3bc1xY/vceN85o7AVyHdzp0JWVjRgMsCe wsr7Ij2F8BxlOFF2BgTg7M9t+pGdytL3DijOEyg5Gc2+io5BghYqU4Syp/K/s4nz1OhLgwjt p+D96ALm9svy1Z1TvQsWKftR0zPXExngZrYJsZZnH51QtDzNqbdSC1QHdDLta7XhEjVBXDaG FxMGbdUMmQQtzy5bkeXlGamtow8XQXQf1Li2YYwMtxDMN8xLtEzL0B1fRVvZZD0HVh6pDxMP PXXwuOipQ8fHuLNkJlbQS6SwK6uxzbZmUiXlwlrbEz+AxXl051QfmFmTe9Za4VjA+16pmVli lxItOGHf0zUTSqwpoQKSJk3llkBd72wm0LDjLSAfXNsRkg86hSGDOxgymPkk1kS4L9Pl93HW kS5v3rXn7DNjwNDLJj94jGo9UzOnCjeFPzh123wZbhyZHxMusRrv6HGl7eMhOHVf9h2oJdRg Lt96ZB/HTrTxqTSdOLdm7poaw+4IfQC+mANQvbzz14oKMGGMAkwQm/qcGMQwJWMHsy5YrEm2 MKnJG+3ShsmidQ3E00+VGHh65HxcBSWULZRdE21qn3o2i7bZQBY3dY0KatvFMQW0LU0JuvPm glQIa50sA3YJa2CDGTXLvCsn36aZmiIclzpJtz/cm/fKTs7qWXCHJJYJY90zsugTAcx0nFub OJyxDe7dskwbA1MXyhBWdVxy1tOOS1tDpRWePrDOXey3sAF6/bIo1161LgqaXguj3OvZJ/Um nHeK2PIuEgDzBJqellYT5Fg0OeMr4z/+oc43V6nmrXRk4Z124FExowMLvNvvFFdxucpKkBGi hwtXBMX26crhq3IE1/TJEcJrFsRHkzliwnmniO1uUuE2QvlVb1dfvfTR0tEa1fXy4vlU7SC0 j9KYDC3XJpPGL1EnTV5pAXUj1nPRnUtOuFuZg+788s/d/E6LkeNOCi2T+s49fe/2xsvwO955 ioKWkSWFlmIknmxemHz1Fh2mO9ihc2Ddza7Z2YFzRGBHPy4LMmiUdr+TQTHN/kEsScjwypLf yxJ0Zv36bHTh6O9lzglF1T+IKbiu8qhmBSz7R8k1Gf6HyTZZeTzCvZP/GNbkKGcfcLnyP4pB 7M8/iCkULp2bMsW6KSYrO4HErwtIljqAQ8edFFoZqDRNft2+A6ZF7H0JnqyE/Wh45elH0ZVr PxalPPoRUcONiVN9oNfvb379+HqxmzRI/iWe/euPH/253ry/eXPzKRRPKJv+9uLjmxfvg5jV UoWx7OPr//vrmxBJ2BKFsUqCxOF3Wu4pulteELDihcFWz51GOGvgmkVWMowbfaz40flFknwy XUakVUFzRC/50x8vy2J5dOrA9fHvAZgyFNVvkgxBIA3Hh635QnHlVaCoZ5H+Y1PEYZhQbDi5 a0lE3pRnw5Wh1lSB4kl56t2H5xUy7dSypBG3nf24fHWQLZfx6TU7Ikwq461pdkzLW67sOOpy +dp5KxY4VBWmfPyE6HtTxW5F9HNpWCuzYnlTYPomQO55GxH6GoBhyhkcgzVMUlrxvItw8bYM kQPel5cwQftQ44IuLw9b8Xw07T63ZGEdhECt0U2wuugGUX61XRCmgG33Tbi4YmOPKA9Tpdw0 hzBZ8xNrAkJUBmBNiK4X8NxUIXoAwPS3aPkdG2uiOkyyfSqb+BQwc36q71/EMaoCtC2/Fqcg rcuvBQ2UFX4tjK/rWfH8nbH8aDgDZE8UJB/wuwh9aWByBp49YbUKMVx/J+dxFpng5i5vGsaS I8NhJBuetKz3KDJ0Ka2I5IyPBwkuQkWzuJXKm0YejFzHkZVHWD7cx6eIjd2WK0l1Bm+eLWaD pCO/vYvso5jis+EiPztS8WQXbzgD0LHCsq9hGIaK2HTRqRUh3y0ZLg4FXVkYp4Hs6I5822qG zLcqWtMFSwpWoMImBWzWDBd14mxIFjJxgbJosiwwJbknvKQEIxXvCYZK57Iy3lxvR1QjfqA0 XDhJWzr25aUw9MXsCM8XY6tuRxSCJ0e56cbKwZrKLE9luMPJlsd8F74VE6zgQNu1yCSXeRY4 LDo8NjTGTfw2JHljeHLRhoTUhu6SDQmto+VLixUSdUsQ6/Q1k6vR4LB6ORqUZ+7t4U7wZ7RB 9VsbgShevUmWB2DNYjgo+qyGc49nd7SNXXe91HLFlmF5PvJY9GVBDHYhDmcLchMRZwpygxBn go3cyw8p2TIFuHWF87DmJw8S3XlUBzHI/xoYThPg6hZR7FimRLXvrTuCyv/2Fs4T7vYWTkeq KA6xa4NRhbkIhlMZLoKxoYGs3R0+CsIVIsYFkX8e5zwhMjknCpRwnOscZd6PjLZMmOBD5ryH h+cf4/aHqRZngc94uYkj37FGy4uxjnymG1Ls6fj9HYGjUHIGjEbJGTAqJWe46GS1/n7UH1li NV5PpUZmbrgMdoibOR4Apc04uNH7HQtMxtPJNkyidxLCJo4JYhPEfLi4kmzBbAsXZ5ItiG2i JTZeXDbokJrC2fdcg/D1HdglOomaObDKR/hyPLTEZD4LH4JHdoaNp9b1brORbXmiz4ZMqWyV PvYSoQqcrW2pZbxVVue5g3Cp3Xar89yT/XwL7pDEMnm0AcISrwo0cNqcER8BFyLAdBpbG1PM 2MbPiNult/lcdzCrOi7TGXELru4iBqgSl7lGQ6fFfoPpoghbOggrLat9XS4veNryheRSL7II G38JInGNzWsngzHoAqO5FrCh4k2ZZVDNbVkQosGgd5HJ0PhIjLlddKSzSUWLljFgWGUdEjDq rCrwEdIQ3JCkw7mIRboeZ7AwFOF4fmOZTkEO1mIqZULFZaGj2uXDw7IOKxLzqxHLal7LGNX8 a4pDt10ns314evkYnhrjRVzZh5iBV8UU0/OJKvB29vzjyHEnhYOQInqso2r6hbTO0XqprVNY nekkwaoIbZW9YrUzYD5qJxE73cXKaIl3nPx8f3x3e1PGt+/LZLli0TyY44JXosMw3aAieUeW BxHWRC9IjHEwNkb0EVXZ8hyiFdtHFJ+DmAVEYQP5Sr6m4mtXGCarMwC2TK/r+m3pRKVWc2WF p3cSgMPqnQSgPNhJwEXwZ3UVyJXXVH+g6FP1cY9ntxCMXXe91MpIjn0yU9U9saa4Rfdk6SVj S5oojhFZJJowckeY7yIMk3nwyU4GUs9/VZSPBLu8TJoMkVmHHfvNho7FvUtCdjosVdzykFR8 PhMlz5cNTWnlaidTWWUm6K20siiz8ogLV0tbtVXWdrorLRZVl5u5bbF0t5UrrjS0QnU+fLTd bKrQWmVsq7rS3DpKcENczRVaq8xtVdeay2jLW2dzudY6c4XqSnMJipsaUepcd0nFVUb32qvt zlJ3k7N0pbVMca2h5ORsJzmtM5PprbSSRnGVuZeyVm2VtZ3uSoubAt+5mgs6q2zliisN5WSu lnLhKlOFpoOtXa9notPdO7e9Z6UDrTnH8kYqXrAxvf8Pu546WBxnGKbmB1dbdUR+hq21a88N 41exMsP4Vx7FdUm6L7g6Bj54CKKqgqvlBIrf2Np+iGzwMEHb5/xyu/XxPnW3maVpLr6UicEn 23ETY1s/aALl2amikeNOCq3LXdTQE8vGOJa3lkxPFFnSxScgpN4bi3k3PMIZHLuIfO/GFT1P OKfEhmT+71+KppXGNfJ9yZUz0aj23VsqeMxX/9pRLdXC9tGjLNfZTz2KepWf4lSTamZCZjJd 54mR4QFFPTWmeJ4CZsuqtVQM7CeJnu+6OJynSFbrCzOPyGIJeZQQw0a0gAZ+ssJkLqtnrbj2 zAEY4cb/rp7AEtprZrC4ps8UlvB6dg5rwnmniC1LjzyvaF9sDiWlJTxUYTrr2COmiRKIH2+W E05QABp+gtOfRrzL4ssi8k50KA0n1e14DigzbCqx42ExnRhuQbIjslk2t2O64CLxDFuNqiyK Q6Q9v0g+WADJqQyRlWBPkT9LUyWsyyaIlndkqExaAxBHdiv/oxqeKU508UEKf2B4MVO1B/Pj CvOh18P7AzucksOCV6Y2ByJkVWPFFL3aKvB4vqkaue56qV1DFS9f9qvmtBqRMjtPvWYiXIbv lQjp+B2TFr3wPokTYtldDwLJHdKOgVelOdPzSXLwdnawOHLcSeEgpDQqklVliWvu+N/1BUao O8ae1LPMkA05TPZ8mdy63yvgq7uxoLsmjzA9nzwC3rJs8N1kHhk57qTQykCAOnZdWw+W2q/O fbazyYdDrNNQ1pRvhfVkSzCpYAgajpGPKllTzcZAnkxsDBuEx2oAaaZpo4jgr74GZWVsujfX TNKQ6IjMr/rZEuEiBJfxMJVdaiWmPTMW2dCNRq0wz8fpqQImt64wGXZ1bQm6a2pLpudTW4K3 rEJ8PFlbjhx3UmhlIEAda8u//fT2B0zzqHqRiQLDvpY7/50nBr6XZbW8ec2Wx3z9tSWTzW3T llQfGvqSOYWgumEjBMM5JjNTFhW3cAe2nNlezVQun5oxErw8ofj25oJNl3GbieDOej+K11kG r795khjmeI0EP+IsQ4l3xAqaIEH6CdHf/p8fxRtTE2RkeIsLz2D8Fd0fyqhO/G3pmLzTuiNi MfzSM/+/KxuC/IPGad6Zdkvb0cDF1rmp+2JNdUOTYGw0oo1nq/UhKm7iGhnmPo00LGA/lHVi uNDPhuZDlCHq2/L1PG+MJyJtyP4m4ujG1D234fKtgz6hO8pofiwLCm8lWJKpfdBLbTlfOeql guZgko/G1R7EFaoJfHjMWADNqs4pKPr0TrnHs93Tseuul9q951USCtfz8p3MCz1VVyq/3dWC StwUusil5p276mi3BZxHLKBXpSgo+qQo93g2Rceuu16qh/d+NNnaz3DyrY8axf3ShKmFo30E 3a+K1vtBnKoh/To5Lv1qPSr9ypfzLS6FdKDMRu+Z2of166oY+uqT677OrxN8HS8SfLWtPng0 mCZkD7BZvvu1Y0NaG9ufPn3KLGfgze4w3Gw/YwwDbx/N2PJIteCESwcTGNrBBoa2NCIvExcr GNzFDAa3s8PqyEVrROVgQWXlPSxw2hsAaHsTAG1nhENCJA6pkNglQWK1Xbz1PnXwPrXzvswj XMAiqIMZUsfBHKljZRaKTw6lFND2pgDazgiHnIG6nAF/dzX7hK7vFMucVYvZZUIIngiVyU72 o13rrAborqodgsTQDrHK0FaxekQ0jWKrnefCjlbB3pRWwcoa6Gy65f5Ow96eTsPKoFucOcQN oO0NAbSVEZnVATdhAutLKDk/w8WtzPpDmrnF3WLJKAsCcp+Dv9vvZ1i+ny5AXGepBLWGqRFj dRSljRhinzIZsUqX/DbBDiWYw+2N4HA7O84ORpwdLDhbeV9FVkdshP8MbG8AA9tZ4JAPKod8 UNnlg+ri0DQxsN42RRkb3J1kKR2Rzdl2WWyiLBg6r63CWNt1Tp/wQF6lJD4dN7VLJ7W27KXW uX1cszG5EtVNoVWHQ6I5u3LXnoDwZ7Eqa0m1YDnVJRzuELm5bV1CXPsDxLU/QBz6A3anIltD Tg422GV6kiHkMCbjcAcjAG5nh+XJ29YMhnawAo7XWhlxX8QORjC0gxEMbTyNCEZQRBymLACt 1gD/nyz8Y54ZywDoWgH8f4tlXzKqI3+XjB7LnC6CAt9duEZEc1MCyyVg0m6pMxOwzl0P167I yFiyQ3bRv+G+8qmn3kehv3/9evvm5pfnz5/++erR010HnPArZUNdbBkxsx6meP/jm95DxT+Y vkvJZrudxRi4lo2HR9h8ba/3P3402T6DmeD64XU4rpcvAnL9/DBhfBoykP5kPwckU3GL2fCI albI/bJhgvavTFlnDjPB9eJTOC5j1llp13QCrTTMm+yVbY15rBG69aygs/1Pfeb6fsk3zDzB vpkL0/0bU4aYw0xwGTOEA9cbY4ZYadhiGn6O/CL0c7T/rw9b1MT/9WHJm7ohxDvx6mb/8dft X3958/zq45JnpIr8W3JE9q9vDKk7hzFwLSZIc1tHuPCOq+Z2/+sLEVe/Dr07Rrm8gYz/3kUJ vFXd1EtTqhwp+pffsf6lVBE+Cx44ZPrHP/xrt1DLhf+xaSMsyXul/4AFsvLCHE7cg7+IUEn3 f7MKvYRvn830Up/pwawxPeWI4qUhyjCcUscpoFJrLqQSYBlUibcNK40niSfWm+WiutRsf/3E /u7fYjY8Ur3rUdLd26e/wtbMesYb4ejtB1y5QsrzrDfS3dunBKVRk83FWuvq7QuKyP2MF+Dk zQ9/99czPghHh2JE3coPnS041LbEUNuiAg9isV95WcyINYRtiHsdl4D3WjPh7wF20dDjnWNj R1EUn1zDrSi5BFxRmwm5gvi3gcWUZgjOc7mkTqfjljqd1mzqdADb1OnwtqkTO6wiHLSA2BkU J0uWTAh3VUWFyuSMz7NdR6mHY2kxZphWxCmNyFzaEMs0IZZpEUeIDPPcVD0rEmNQzwrlXV3S R4+3pNvnKty40GXPFVC5prTQck1sYe9Sciu8g9gqUoyyZFKouNrmik7DJW90OjM5pHO2yycd 2jUK45TEZY2IIRYV8pkoa3kcMkqroWUVlbrGh0N0nN4Yae46dOryx7aY6D1IR/DDocbu9JzS u9WZS+/W2TK9O8PtaodkaQlShu263Z6VuxbfxPdKsES9NGuC5akWmjSKaemw9CjwroESWs4N UI1zQ3FSiPVgzc0TmHM7qPI/IiNP5PTe0T6Xg45LDgf8TO4GJ7uczQ21y9VpWdOmQFOy3s06 kwgF51wi1Nws3rFkSHHmYF2r4Gpdq7ZUOieEuwbyiVCauYFOJZ4MYRJRAEybaZGhBzSdgExl bT3Jg3s5Newc+jl9wmGNpzVCB5JcUVwthlWBhfI6b+rqNDWK75ACEMo7GGjQGt0ueNhBQnn5 FVfVUgC5e/Dsc1XaZKCr6TMTKzzOWAtU43gpYjtI2KyzGNAOYutlFzFb5olF/AHMlfrakvva hVyE08Dcg2xpu6JgIFZhttQ81xt4JcY1jq0yv3uuuCot004AremVatXkwQDqnPmsg3DtFoau bBvYVZhb3jYarsImOweNoR866Pxw+Nw48VgnDpu8AO3aiQIdy/7dKZqpU9XONb8ZLUHnXdEw 0GZ3jmQHm6knuN7BwyKzaaLwfDeumoFiVzd5WZNJauFkQz5R73PyE8qqSWpw8CI+TdPOD4os SOE6o0lacLAfCoGWy1AI8DNDIXCyGwoB0jrjFcfRbpflAHEFtzBxldlgcVfbkHGwZeCyqJ5e gTb3VEBV6Rmxrzz6iibqLg7s3IN5Bq/cLnkG7sE827Ylc9a37biELmURUHHJH4CfyRzgZJcz uJ122SKHpVj74HC4S3i4wkyAuJtdiDjUNkisbnaYFeBw1+aMK1naUzT5YbgGvWSQwLtaJLQs TapY3UEjgh0qb6nikvpSaSYHSHe7XCDhtsHEUeFwgpXDXeOdK1nbc3Sx5uhuy9HWktLhPA0D O1tS5raWVA47+xl4rgsr5owdqDh+ju1Lg7+ubFNAtW9TopSND6KJBgVg2+TQAsL4xQcji54J RBjfahRNtcvSL3AP5BOmp0WfmHsYn6B+W/BoVGOu9OcQHfDkNGznkwAE8qtOFn2qp08euvoT nzAbZ091CzuvWkQY30rWIYgpPi9Go4IK4itaismZOwac/chQjorJLq/0qYWE8a+py2op2QQg iF9pVl5QvRS0FhHEN76dfcGv+e3urj7hYrHaBedA/iTobtEj5h7EpyyieGqxv/OJu4fxqYzL vIQyuuSdBAXxM2f91qhebFQ6SBj/+BhjwbPxkGWtTw1ctLhUwlpEEN+qEtF6ajGo80wAAvlF CnRc9AsAYfyqF5uVarRJZ7U/5ZlVDktZo4ME8Y+gL1czu4w7/zpIMP9Oy/2PDhLIv7vFhOPu YXwqz0v+lOcwvlSIz27P+gPuYXyicLHXgk90dE3YSp9mlqs7jzyWqnV/mjhe8Ia52s99gJLL tAfgZ2Y8wMlusoNbajeGhgNG9iNfQLuO50HH2pgicZldEHh3g0DL1qTyUA57y0vpLfAuKS40 ZtJcONqlusBah+vYOEzecrhbqJjCbKCYm22YGNQySCTCS7eQDEIEaJcAAX4mPOBkFxxA2oam iG7RWNLJrYMJcKdwgsJcQMHNMqQAdd28SQq+J3lx92ZPPBk5nMBhX59QmJvLG7coi6ddoHly iGrAz51vYU52Ec13m9hlqUtUz9eS5lMKnbr8MTyqsMg/tFuSWNpeLl7jNEgJQLukBOBnUgKc 7FICkA6hcZhw5nDXZo4r2drT5PNbB5Z7TqDK/2xxkU5tNpJuDsnHVJySj+Hnko85WSYf2GmM rqLpfzm9a3mOsobl9tEl9pKsvzi7/drFpLGyfBPX9ICOrJvVLkFxZSmz5oD3t3UGLnG04WbC iBtHK25GZnAGLXbYfwmOsvJoFf19rh2q78Q/658XaPXX3AouVH2uBm89J+X2iULR3w8+5b5T 5VbGtmjHx7CSOrrsmcz03LDCvkB0MDz5Y2TJcIH2KDE8AWOkIbQ+IXw8+dNccEKXn7Uxx4zI QDF/1WtfL7+DaMt2j0hRBmEqSsYVhKmqj94ZoKWi6I6G4spR0YRJQXjoK8PEM1e1bHWU4DIY Gy6qJliMxfAQGcsYNUprRAJlf+PjZrZM4tHuIFQpQbCAGKgcUZwuv0Vnn2NJsJJ0jBrDg1NG Jnh8c682L2uJ4OHVEDwNQXvYp5ea3kCyZspMT7MZmeB50TBMrMhRVvQCsXVZKlyOStlwNoxR bkQ2HbaFLuSn1zefbnbvolvUnxIU3qG7KK/EqaBxd9XHM95gPNrG386z62/p2eNv5FnS1tLf xrf02/oGZeBbZZHWM3GB7rfy71tlydazbxY40bB+m7Dx3t23yiXcs2+VatA5/1YBA7++Zbi+ Vf3I2vZv5FM7wvs2nvEB0rfKG9yzb5U5uGffKnfAUPpbeQX9uW/jlZj/MPo1nI08DvcFLM38 MfCqGUOmN/XWomJGjY7aRj63OVGuveN/hzOiAGsdHOztdFYFtlX2mSCVBsw+oTiN2OkuM/G8 S8o+0a/4CsjV1ZcGI1g6uUoQ6/DF8A7qf/7Th7o81lGe4+K4+edNgs4oKyvYiruhZZmR7T+1 CkxS3//nP/375iPw/2Xzr9yff9v+r//FBE0W1fylLkQIYwXr66i+B2VhKLdAybfwvRu9EzIX Yz0HjJsGNFMxECUwiJx32Z0wjDend4RNJnmrsCq7tLo+uaXzfnY+fRKw0xzsNjZknYLpAc6F aH3A3Pez8IHlv9YvyIGfTmjz0/tfO0c1+3Wh8cuAKotTFtz1eVF9GXYJaf1arBVb+3q1/ob1 FHDw7uw/vuExbLFkWel/nOG36D6Pqv95dneF4H+a3RRnyf+87F1nhCbx/0CzJ57F/p9gNr2v 0HJ1Ytvcyxp1TV+hU/bpLEgDZnsL04id7mLXX+jwa7oL8sdD9laFF7zDKn6qPYbOuesy8A5r GyJjl+EbWLoR/+vMrQfmbl58eAMmZw3hr9p497OVoEN66sRWPR+otf70J6tx3mTZFfq7/U97 qEhwv/9lGjdVqoXT9vrPT3dxRFgAqA9DDDWDDwGq6+4M/jqCNCsjryBgUj578syHIcM57raP r2Qo4yjzisccHhf10C9hpuTOh4Eg+rnbAbiSAR+LKPNioElUHz0ZWL3jyYC9cjT7zSR+DDXU rB4MFOde2fECAxA/As+aJWWRgKLcgwGXrG7HPjkalyS9TPfprAl8Q0H8GWiC7mJU+dSy3jmS EXgHpK3ktj4VJaGZl/45yqK6ju592m3mwAS43H3ISvojbHnxsUiy3YSjOjQ4o7g4NGkYPtgA GoyM9xhwGYhM5MowZLhIgtKV/N9QZLw2DEXGW8lwZCEjTbB9CEQX0raAycn/Bgpj0Pivopqg oIRBi2hVl3GwmogXgpDWhecKGFZx+X0oMhlUv8Z8F2VHvyLVkRwi4he6jog/FOjNw4aU3tYc 2LAW+XX7GMkZ8ac7fI2BV/eChCpBXxqfkYXk8LYkbQo+IRaMyGv0DESniJz2eeQz6FFpvAPG ifzzYEcTxB4aHTzrMc6EAkQPpqiO5DM93jTe9sDplQAU3nb45+AQmTdHOSy4e5I0bCQVxBog ClEGiobfKunJUkXYP79V9ATT8nveMITk8raMNQ/ejQy/p8+fwjssQILzym/iA4j8K/IQ+ZcE qKVIkGqKUHlDvh9HAEuyfZCecEcUpDcsyEIUR2AK1REFLrn8FoSKjWWaOER2yvZhOqbAFKxz CmS8A8YYw5GFaBIlWZBqpSUL0z3kbCG6iEAUrH8HZIFqvixYCgbrIUmyUNmh7SkF4QrSXwIi 3jMJwsRvimDZKjoinsXCkMJWEBKGKkTnB4hC5YdQvQbGFKzVpyivfCf5JBcc9whB1BRwxBxH Gf6KkiCMgdr+ULEVJKZghZzFeYSpf3lpKM4w9R2silgOQjI+yBJg45TR92THOq58rXob+w0o FSa/tEm6dWvqb5Jk8jUpCbOWnuzSUERHVrnGvmWqo9nzNXpvMlwkuGa5ORBdFizW84jcBjIq TLSHjHX2377bZhGALET9msh9H4HCOKCj3jWDJMwRjabqXkDZ79Ru2dds8haqPlu8W89JuX2s UPQbvKfcd6p8buOu9Vbsd5jEKMuiApUNGe5l7pZ8/7L51+7nv23lpuuXf/rT5s3uF/WYllwj 9tvArNFYbVcuD5/j9W0uaE9mPXDgGY8jUBGXyXwzackCI28/BvhzFVU4AMtCN9+Bxo+hbgrY xOlHQpZqK0sOeprrdtsSwOGTxZ0NlkTvf3sJc2031NOgXw6f0ex0nSXHh7qkZVzKOfWuph0U OUNdyTnXVLKgaDiSfry2K/tTkcB0d+y/9ddzgvKqw+fXw2C5nTtn3rJm4dFkszFy3EmhEnvM bXuA6/mHkl10WbqWenB7MAMLfw4zz+4MQ3BkGttHM+eMHk3duvVoJ1Umb9t6tJOc06GxP5l0 c0/YyHnzKx9kYkRG53t+evH3v7L2EDyEE0iyNWTiDWtGj010RBtcUFRXNWJ/N8y+JsqgdeRG +rWMkmK5VeyCfpguoYvXLmvq4/qByV53t1XEt4eyvN0etISUd1kwZAd4UCtYQzhvATg+rO/8 tcYlC1rAg1pBL4x8wYjW3b5UH2K3Qn2Il4r0OGPiAuZxyIIT1Fn4gGp6bwAd0sSAKCvWcUMm z2xsipKkvh6fI12sHzsVWRujO8Q6k1lqFbFSfVX87iKH5327czDOJtYrbVuOarLDj58/u0pr hA4kcQgGmQjGvD/HiCy9mj0gB/S6WALNdfGUOQQ+S9ZZlyVLttk0TVlC4hpXFN6JTPeQdNu7 SeGhmBRPS+tJKZmUNjLoSUSjnYQsxW3h8B5Qka+L2yJfl+7Q9S2re3sDW4V1VrbKq01NRo88 GExN5DMMK0wF5XWm1lFh2d2Wr0Bl3SFHV0OF7ko7UZSM/Fk0VCi4tdut0joTCf7q8hgOQ6+L RtBcaSFf13B4C6VVWGmnUF5v6vQrKSMr8+j+gPZcoULjCt+SqrN4ZTl6uMseXhA2wIqIvDZB uzsBbgLIDxmqQS8i3/p6h7cJsy1L1MsnWOfsVpjDGtFvbM5Pr37YREVRUjgnWEC0iQ+4HeOF lJNNWtYb2tr7Ch2a45GNTP+Vaf8bj8ZW6Ztbz7pEfCxNqj6x5YC6S+jNuyiuy82HGsGRJkRI WYvRNKm+qcHMy+Tw7X3EBf3GnjLGwzcvWD+09QrLD10VoxYy5gwXpch5GSDocJ5zKm0lAnVg W4Dhp1YmQCDzG/9oc0L7u0sj+OxjD740Gy0nbeTIJHHopjDwynFJsrKDwhQJqs/IYYQpVRxn DDu11YayuiOLHHrSUkUxdOQBXMg6IWT/36d8xDrjyEvArCvLS3NusUMHO66q77QMYRXT4Ifr 3CzzaXFuVnLOBeuRQ6jiR4NATVO6MCpJ3P3aHZm4C06X1DYZNV6cBpuOneWJ7dZ9RvlPf/LQ Pnppv3xpqTyZQpVbVl4uhpCHqqxRu/m2K8Bjkn6iVZlrhdDAilhcwQrRTtwyAlfkBiAr0CUQ zXChbx0RrGIqjy1O72ozl1PwzqasOtH+6U+TpZWJtdIKnPLr5cux44wlKc6okzWgYDPbyOit x0s/sbrnVRk30Fvi3fdRX4klGHSb41iuQL3+6eWN2JSxgZ1XuB0fQcr69ePMxrDSyYxhf6eM qWp0pfXaobF4aIuOd3esEYUY4j+6bqQ0q4uhTRrlOLsXq3VwIjlRaXn8cQLfNbs2EaCy7ILP +409uV3HUBTj8vDZqRwyvEUxTL//3p6Vgd06cEzBqesmDHLoFwDaLpT+G6NYirLgeOaJlsE6 4Y9xeXbovjL0YpNZ4aX3ckftb3dNnG16g4ZbgjMF+xryJRi0XAe8/PDmF14t4VKfR+L/exfd wsCURhXa/GtZbxJMbv9tE9XxCZ/F2JKHwC+NJYVdIicOndbEcXU2cVudTRxaK+OGiVcvWTok sbZZ4hUit7SsNi+jLG4yfuDrnyBUnjGexC7xPfGmx2Kcc7xjvItH4JziXnkqxHbLwMfXL169 ez29+N/yCYgtoXwudJFTomxp+TtXh/JukbUD2ZJC8po4W4w9pXiR1MApQLak8KySibPFWFPy lxGXGTnEllA8krRIKCC2hPKl2EVOibKlbd/YXSRtMdaUFlnTMWfyh34WCTlishJIHRb+AO1a L6VuS36gEGZP+as3P/4IDQIjnGiYwXX34cWnlz9vPjKlGhUxYq11t4OO2+3ZRnQUtq1Emj52 S4rH7mnx2CkxjhWqHbIHhztOuIKKu00PuCb4E/DDkA7+VRcG4JuxbmBb/aa7CWBzREV7kPyf 2gjw7bBLDrt8c6yRy64ihp6a2EDcQZ29ELzyMzUBvhoBRj++znlik5EY0HVGFPVKc3OLHWCa IPUl+OpN4B2Gr06BmMx+ofrwInv6lp+Owrb4lOnUPBqXdxOXJvddntsZt2MV0K5osky1jOZR zBh2Gb/xPgARQfsFrolaYXIudxhCbUZXndQd4vIcJNsq2/TlWMi8diavt2cLEbMZxxSX/042 ETRnVevyO9mV777bvvs0YZZw+N2sejpn1dPf06onc1Y9+T2tyskWpuWm7BJOv5tlrGZaME66 WtWBbTXz/Uyb/71lt4Fx7PM8EA0ruwtEE8Jd5/Vk0/v9TrNvjqHz1cDRwmYbsyAT1jxNfFvw 0mnkJKxPy8ntDL0jNJm/PfruO8sGdj7rq2TLmV9Dvnp98/IBaD99fAjSNw9B+sODkD6EqS8f IlJfPoilDxGpLx8kUn9+iEj9+UEsfYhI/flBIvX9Q0Tq+wex9CEi9f2DROqN2uqI5lNvQSya matH10FbGsZnHwIAu7Q3zuT2rY47tXWKulNbZ8EV1A9ntn1r5E79gFY/XGQ7tE/O3PatlDv1 A1r9cJHt0G45c9u3Xu7UD2j1w0W2Q3vmzG1o1XiDZWrYvn8arlH7/qml/Qxo3Zi5kFo2Yk6U dsnnRGmX29wow5tp2Ug5UT6AleEj07YxcuG0bIScKB/AyvCRadvYuHBaNjJOlA9gZfjItG1M XDiXGhFoHMwNSNCBEaeztt5pWORObd2eOBPbpqMzsW2mcyd+KJOt2xln4gez+KEi2b7lcWW2 bn+ciR/M4oeKZPsWyZXZul1yJn4wix8qku1bKlfm5fbKZswTkRhjuxbr4+bN5ocNC8vN5u3m 5d83Slsz4X9LbPA+rh5998RuFdLR/47ZYEBytgy9bcvKCO2SEIBWZcSJ0SqnOTFalQo3xvBG suwQnjK8me/CU94EZ3z9W3DKn8Mzho9Ju0bWLXFehKcMb2W7yxftXooTnT8yN/JwvryLbhG8 DP1wPuQkyrejJ0HD+nB4YB8oujs8uA/o7sG9wA/uQ/7wXtQP7gO5f3AvKFW8mOgx8a6Qobt0 onnm2FtjQ9obQ19NsBq8vi3x8yvLTVZuXcWO2WBAFlFse4unmwEds8mAg91pAeu+KiO0y0oA tGseHSmtWnE3zgegtOqmO1HaTU05UoYPud3UnBvlx4VyABncVAg+PwlcCD4/sbSeAV+8/cEu 5RxJ7XKYE+kvD2DoL3b5wY0zfNjt5iQdKcMH3W5O1o0yfGT+FD4yf3qAyPzpASjDR+bbB4jN tw8Q9LcPEPYHqJB+eYCM9AB13ANUcZYdCDfK8CG37EA4UYaPzF/DR+avDxCZvz4A5QNE5gO0 vr8+RPP76wO0v78+QAP88u2Lj6/fv/rlfXjmXz7+8v71p+C87158fPPTL29fBSe2mux2Ylw1 K7nOB5iCsZ3kWecDqVCMo2x5mocPoAyDrIo4jLGquszKY4M25D4/lBnJtlUabb5GVZrU/KdF eCtiF1yG49GIijgwbVJeiqyMksC0VjnWge+/rQqVE6FVjeUS5NBhfmHVoDgRWtX8LozBCUOn yg/vQsciYwwd6h/sFkidGENHpF33xokwdKDtOjYuhKEj0W4y2YkwdJjtJpJdCINHot2OJTfG 4KG226/lxBg6IoPHY/hoDB6LwSPxQ+hI/BA8Ej8EJwwdiXbTOk6EocNsN6XjQhg6Ev/7ZfBu xKph4hr+KM2LKH8w+gQXx0NEie041MuP+gE9yY41QrcP6IEYzG4JCj0iHPgQsyG61War9V6w ETnLVg/lB4zHFyccqqlHenS+hqbPH2JjheCd8TyPLG/xlJTbpzPXH9mdGxVEZROEJ8idTpD5 PIlMtsxEPsuHS27w/sB8tukA8IdLrJBJjfkrWxbQw8KtiIBjWQvHky9hjzAgGW0yX77EFPAi Mg+2F81yHbebZqcMHW/vWrK0Kgm9arUUe+28Gm1mMsQJwzvHCdPxj5PRhhOToZ+fuBv6+Ym/ ocNJW4OdFXE2s3J7k3XSSkpd3o/jeGc7mc5KQyvxOqYNZoe+TBs09eQ1wyr3hRYj1aVIAF2n GGAKnq+QFwYKi9g51g5BZGDXRPa1z7Gqq5FbTdd5U2GH90gY2C0amIJnNNRwPby9hRzuZiNX 8bSSHhzSioHdLGQKK+0z9j34j7aL4lDpuT5EIHqE68MAn0fbygywSmU2qzphpNsbLgMbi3E0 LtS4PBKVKndWeVT3+cZlRVwMXRiVDRjbf7bkpIRrwbNRZUF8Q0bdMjJ1z8jUw0T+Sq0ZsYuS JKXitlXbkEgVt9BINZ8QwZQQLRNs8apLa2yLV3LJIsXI6hbsZfSpSid8XIrjTsMtijstL2Nx kdzxIZ/nxR0jxuFsymhCZayB8LFQg5HgmO7sY7GlcYvEVskrDrPbUQwu2cnhblZyFT8by9LR SqHgaKdQ8rK0Sg/UaUDXKjh2H4WSl6V0smpZbBa6+smtZVhfK4kHB+LFiVx+S/t8OQXn/4DS Za4fmClJGYv3D7SfV2WWtM8i5N37CLl053158St60v4gEXSdxW9aR3GnxZKM/6iIpKyI1K9I RG9bJMwKtfpsTMx/sR9XfN6Pf4mjZy3mN/Hvbx3/BuYlxC8Y+Yif+eVyEb/kDxhx1nHb4LMf 7b9XqEiY5n11QsW2e8W4vxTfJkks41z6cVU3896Uh88G7+xaAJEMV6MA7Rbethg/oNUm/ARN 52RHxLNQBi+iTFD1jnZkUTFnVOtiadM8T+5EROZoiIs1syy5Cw2Lyqu4zPOymInoXY+wZ2RV GmS/JcoWYs9ZmBjtR0Ocj9znZIkO3O3YxFHbOS6HI75i/QJUgyzKsIwQ5I0MlrmD8Cy+tGFP A6U/CBFU9U5vfzzd9Wkz+XLH090gCWfe/yA2r3+QpRdEujRZpmhRMxxWb5CgJQaZFMscHWyB hYjHLwOwyVRdZulgUx2sr3j6TLr1TAcjYH/QHVKnlODbn/Yrf9Gzp/06fg90FW1a1rFqrhAE IM7LWuOF7wC0BbqorOzTYTKSMSgd9T6JmgJctNcMeV5QPuOILgHM7rnuwXz6jWotyECeayBg jSfFV9MDsTYcPHP5kkBO8uVg+cb1DUqRS5afX+wAMw84skzio3/0JYBcuKjfJ/JE/ZhHU8tE oJtNbjFoWSfKJ5PqScLL51VK4tOROzqNpqG5cxlIt05VRE/2dUer4GwZKDlbF1V1WZXT3dCp SVIBV+dIOwIpuZzY4JhoVdCSL6N5VIF1LTPC18UspzLPJtYtEkxeDYhOpfzcVqjWnsB8aP/4 ILZf+2DFh1Xx8QjRxmnnzAo/ZHXuJGNzXtcqf0olv/p0FLbnM3TPp/LJcy1oQncytzwfR+Lz +WwjSL2TUNB0Jg6yyoIfwzhqCVzqAlZ5xA51FIc7zpqCiptN9M7BInq3tMWAOdu/SPyqjBt4 Djzir3nzN8FHT4J/+PTbXzb/ymjhOfD/1b4FnjcUJbAugO70R8AZzvMBxI7B7vnDOp5a0mPS mQYUXGKH3Xax40672G2XHTfHYaExdlxhjN2WFsEcnKDCYbaewx2Xk0DF2a4c1Ufk0LkAuGPX AlSc7eI50Hp/TOy4BMMUPNsRxoBZWV7MCHY0cK5haTZtLnriDE12WefjiGs4RxTXWpN+43Gj wT4+ceBqnmmwN2edY8bvNJztW5n9s+H2nkXjGNrRsMxxV1Aba2mN0Fe79+Ql2qOI8OBN9nc0 e/pf0FWVXR7F3lF4HHPnirzpnjMJKpKrarpBn7JJwJU+niTQJIfmqI2mlrwZBUJgXUdTrbeL wymVej4y7HtdN/eEonzzK8UZphgNulwyujz7USqLXV+KlLVDww9ox3zGNJyyGY0ctp4ysOOO gcht2ylcVjwdca0LdDnp3dQluR0AhlpuO8s6DddJEqG1Jnw7NwPdjTMZZkvht67XhtapP9PH UF/IXWJKqRocY6zXXJWk/F82VnMoTa2GY5FqtVYZaVt/vsMkRlkWFahsyKDq5DFkrDd92K8I LZKH86LLln51v6SAZNCtBonqiV3TEJ+nhtlMOjPMbl1E12XSlTNaD3vPjsMmpuBZxQCDS93A wyT2hNl2i+JMdNRVH9CdWL1V+XYt0J632J8woTbEAmnNXOY5pns4dmFB3oOt+c/k+sz6LWVt QS+xDuz7KM6IFTdHOjDHJxTfWjFzpC1zJs9SLJCOhmCLfCxkcZNbsQqoLXeeVriyyM4CZ8vK xkZXtLyCKsDI3GMd2K+t4rgFOvBmpU2GaIHWQ6mY2QGzSEbiDmnLjCJyf4XzCrr1RnIFbObn TdL04FjlnNpdq7p/fP3i1bvXZtsE7puZ1ZXoLSyyWpf/rdUySjgTTyirrC3swN/MwASxHhHr oFgZqIC/mYFiBpX1UM3mSeh8x+fQWNcjAq2ujs2rT3RhYGpjYd1w0kDreYwPdXmsI9bIF8fN P28SdEZZWcFyklhJ2o6Wkl7+7eYvm39lfvClJPa1+QiHP1ERo827qGiiDHSg5+XVv15l2NXL t29ev/8k7IszzNyYlWCj+NgRVJ9RPWexAHl227uQQ4LpnHa9dFhInRFDb1w42xiyadHbSK6I uynuq1nV6X6+0O49JuX2iUKQFUwxnXbd9dK5wLOcgJciZxwziyuwsF7dD0dk0QT5U20CU/Dq gO2z7XcToGnDSIMTa+MePYIOQqsxZSAZW9h7MECNzOyRsxmsjup7g/Puhz/+4Y0ICpTOLg2T iEYCxz1m1VN82v2wrXJ79C9O6B92rxBUjm46LwhB+SFDtaPeS0d81PrjogNzfsyVQW+Ji14c 71mdUiDipPXSNUg/HKCb66p0T1FcJshR7ROqiavOK1RFK7QwiVbmiaRXdVG7oRE5OXp1cyov Gbpz1HrLejLO5SMHF1fzaBTflofPjmq/1Sh1UokaWkKm4g2FsxLcN/X3GlNbjW3FQpXxyZUX VcU6rKDY1uJivw3vLNBymQ2+xbasqkyMlSsrL2/LKIErO6wjUuqsiEypq9K4R+8kjWOE9xy/ R8y/+mH/I3Ypya2Ce5y3ivyDVBlmHcS7lRSdDc4JNiRwS6pO+3dJpyavXEqHMBhchGb7z4oo G3McHFpcRZ1nGYfYVjz+XWKcjcZS18iCIZvQFH9XxPeIwim6e23X6Fb8/T2i+3VdFw5xxeGO QeQ6v0vgPiB0uyofgCL/szYj9QTu2YirrclF3NPfI55/jAua2QeTw91bMq7WKjsni6rs1vwI zd8jWn/KyoNrMKGhBD2f9r4ngT8r4lrXdykBUtWxAPReKgn1v//35hVOU1QDx5kN8iCZynSz EFObtGyKZLv5f2WzyfHxRDcZvkUsWf/4hzqftWMx6pkVH5uiABv+BQbd8gaKX9+/eX/z6T8f /cvmgtlnU8BYfENPmGz4leBpWW/uy2b7DXPcm1/sk+qN2wzKm192NyhDsdsYEbTK+BY5a30o M7cqhun8HBWJYxcbfMKVs84Nq6mjg7tfr7DbqIupOI8aZJTv3rx//WmlKsvbv7nX8Eyf5Srn +kaoudXqTOf3qNJv7snfXEP34SVX439WRI6m7lIXg+Y74jbnyX1DeVSd4ISwsyaY6Fbxy+D9 Hqn5/tUP7xzH8VLFvXRIVYXEOTtMkbiVnJ7h94jyXyqY4HWY5q+cJ4RvotRNAe48c05NYVhn n3M66upuKdjq/i4jsl9u3vxmH1QOd4rbVgMscYpPrscXUmq6jRwGM4o2LbPygur16k1VrVeP s5KgBK/WL3kWWK1eoyjxUr/gwocA8ZmJtXHHrF+d7CkfVK5UPiJ6rI848dIvonytPnMurldH W0lWJ9ddtTq+o8Nqb+F02ErVqrysVSW4WK36ZX19xPJGdfHIG1y/WZ83s7I4fs5XpzNB1EP7 lo2p16fX0dd2fPQzv44wQaur8jRlvpfp+qYERTWrUNfXiNAWrdZOoClarY3WhztlOT72UV5d L8GEz/rmK/WKsKrGBV0fZ1XjEWdMeX2cQZfDQ9kr0kgcFevjjMAU/+oMXtfl+qKZZg05+eTx an2jD7WSjzpF6+v09MLGR6vrJJ+KAXThguT16qtjrPLKK34Vg0+9ALoeUeZTq9QoL8+r80mN 4LlNv0HQ6j6HT5VE/BKbeHlO84pfFrJSvSl8iufZswE8e6p7xrzHYCiCg52rRxeRRweT6WIP 3dWNwIGwjm28uvmLI5jpWqud4PP60fL6dIKbQjzaHlSstjrzGah7xFbulUxf+L0Tq4dt6+tv 1p31sZv4+E34HSOrIxzl8Wl1aw3a6wfKoF3de2j7NPdMnXVpV0c6reP1046gvT7SQdtjeoNp r4900CbV+ikxWnt1a5l+tn7kx7QLv1Qr/CK+8Iv56lCvHnoydc8855fs7P8e2rRcHfD4lJfr pxqYxur8kt96rIn4eNzkEVkdX5dofX8FdCuPBZGc4vUjML6Q6UPgoxtlUb26DY5PHhklPpWX 1QUTLj9e3SPnyqtjjGuvrkxB26NLzpS9DD+vXwEr19fhMFS++Cw3Ir/VSuSxoASLnZ5LpWVT rR6TMIKsPK5fy4PJ02O9OtVB3Sv0lZ+6R8JhEsGDcWsrZVyszu517tN+Inpo1s+JeeVW4hXh TPvsY3qG0Op8KjYyr9b2a76jZC/umVk/K9as3jgvCPhf9x1dqrLbfi6h+btsZ3XfAHmzfgMk SQ45azlpHTEY2Waue7yk14oRzsk0ReKWXDe/6wZKsUHbIb3ct9+LUIqN4K26ezRr6o4RLHR/ j9j9uSQUVoBcQ3tPpKpPBaTxdD9WRP4kjcvecZXBcUe35rnhNA+B4zwDvyyO8My93DqZlCAY h2fhNNAI63gCCFzoqSSIHwMiv8c5IBYEfnmdc64Riu0/6zKeTuGa6Vo19yzXemub4aQ/obJb 63+X2ZRwGLKagvyfl9HYsKB2SGEOd2+LuFqr7JwnVWW3dkho/h7NUO3QADme0+EhqxGoOUel UHOLxPrbdpOWneC/6+FFgktXfwm4sMv6QSih5PYklGogPK7uYiHg3U3kT7ivtjGDzQcuRnIF xcpleoalLuyAtyW3iyGm4HmlNFAkKKNRAJ6n3333JCDX01BcUFAD0JD7xeJiyVL6PtAKJN4P o3KSJkR40qaIg0QLKmiz+BSHJdN5+QkN28RuDgFYYEEvCAtrbsIQtcgQCQ/rA0Fo8gA0vM0N UiqQ7+vHLUuY3JyQEKUrK0Ok+IE5BKCh4WiC1DyHzyGswSEy3yFIzOAqRLzQUx0oCx9yNvSj KES1nKDDEfZdB2FqFh9xs+QpmvwQJmg4CmEPQUESv45C9FMqw+tatmGi90Hq9ipIc8yqwRAN H2L5JoQ5UYV9n64CmrsQheqOhKkyApXxOExPJy7zCgfJgLRMQqQVS/IQzUTB6uQQQ4BTFIco EPDoT4gOZfQlDMujMDTXYWgeh6F5EobmaRiaZ2Fovg9D8zwMzZ+DVBSLrXicbOYn+9sZJO39 EOUJET67AoDNf2wsrBGTTABX5orkZz/lo4qeDkR8AkZ+wTyK/Cir/jdMEsvfjQLicwyKipgq kAIY8ffsbOAuP2D8rX7AMFr97kbDvU8wqFW/8v6rHWIq5qbah2YTjNsUTcULPoqSX3T0pYYU 7h+XbhipJIoW9Pd7mOi294bI3reShqITrQrg2YHus+3S9s7QM+0jGKm+QT9RfvHuXg/kvTbF MdEiQYln0RWSn7xHI7/uiPpbC5seilhLya7RVuI2KTU/lAgULaH85g1a/wXtUp8nWPOifjzS vq61r8fa1xPt66n29Uz7+l77eq59/VkNkUiJuQWJhWWGhuJs6vXE3nEXX1cn29ltwLpN7oOG +8S+sCyp6jKtKlvjWribfa3SWhNPDpF3co68kyHyuuYBF3HWJOg/NhZLxL3dbXvRvU8jf2yu 3jjRsBzp5i+PiKtks7jCtvn3zb/v/v2Pf4i2JasKTvAcjPgJER7FWStiP7iA1SRCAFUKCDIc kVbEf3Jh3Upq/nlzi6sKlv8SXKOYlvX95v8X1VX0LwxJikctFn5xZfZjD/eYSDH/Ek78pq/W gf8G8QFTQmHBX7j0n9zxKzRSwoH/BCE0PEXSmSm/5oyNo/xfQCmXVO1vzlXmvbndR+dQw+aC 3kl8to4VPNfROfEP7kDvK9SK+U8ubGqC2mhuf4M4aa1JhCVJB0la96mwJOj8LwA98yenWrj4 EBxnAgdQOgf+wR1wBDsWhFz8FuIa3q9qxfy3EJNbGnXmtR/cIUvjohXznyBEWXp1Yo1Ga37/ 2TpKsRB0kd1FtLhFrBMVIiCI4lbEfoBA3PjFReInF8I1D62Q/+TCrOxiQPyUQhaXVYkL1VGK OKjIo56w/eAO0PMRUt4HmkmclLC0gaNHbcyJn5yAVl3REz+FkHSi+QQ//ulPjPR4HQso/ADo Ee5rFhJ+czOI8qqVsB9cUDQ1Ona5VH5xp7rD1i2WEOgDCJn4DeITwkrxkF/CiWDWh2kd+G8u Zt0DlOA2juUXr/8RQmnrb/ubi9MoSeo2KroP0V5QKEKdS/c1F1OYxCymMCmfPXnWqojf8wol T7HbKGlTl/8COPzowy2/hFNKOnEqrLlN2tSBH1wgy9ptV9Ju68MVa0Rp2Sn3362zlHeCp0OF pwONp1dK/CjfnXPvIEVKoLqv1mmf9BbsE2mEptDjz12MnUWEZbDxjkv4LyEqjn0tJb+4Ez5E tGVof7diqGyknH+0DkdUSDn8bsUNOUgx/O7ErBnt5fAhHHLclbn2txAX0s/iVopQvYeDxtKh /ebOYuwjnNpxEBezIO7jqOpcus+5HAgtOC4Qy4Pt+Xmu1/4GJVYFnTohFXVRnly3EvZDCJ50 giet4GknEAmfo5x518rEbyEumk7IfnFRWSAaSWz3xZ3aULWVS16VZdZJ4CcXfmlQ08ZL+3s2 6CQpCS9+hdo8Fkr72P7eJ1mmOXIBB7DRXOsCv+a8YoH4l1kX1qfKbpecoe/AfsRlkeK2UPef 3ApEu6Ijfi7YcWQDxJMg5D+lmvha0MSLoQDXZwvO1d284y26n3csRATMucbVgiOZdyP5Yc4x nVVL2+c2593FA6AQv9leqRrlF08u2NXWyflYFoSEXLBs+uXXbHrQeSsvs06s4w8tFPsHehFd H6X/nPMNZngIyUC1wm3p4r9AoSQ1ghmlTi4/wbGKCtSWHfFTCOmJdEL4yYWsmrqSXSP5JZ1g Y3WXy1VBB+hdZoNRxXFUJywUVdkVaP5rFl8SfPcE8KzRa/HwaxYPbWNcZhD9FT3xm+qEVvvB bRW/90WlucE3d750OheBr6NEjhra30JcKOKiE0+ZBfSZqOThZ8VGPtWpjkibYAMZJ+87bX2P jf+qFGnVikmZnTsx/83FbIiat0Fpf3Nxeds1o+LnrNFVPJOJmQs5g2PdFF0Q4BenZz/68Y/8 Aid4Uru1R/zkQnEzkJCK33MGEcTqfkyhpiLyrvtWUV59zyn5DaCtC//NxUc4Cymk/CcXnqJW xH5wAT4WUZs1299czGrIVgi/Zk2EjNd3/mXfn/0oEikr2qBTNmI9dlL+uxUfZLvafbQOCUql HH63Yllo29+duOylZSeUebb9LcT1Cd6rbOXio3WQg3JlRC5+9pWo8t07E9WNdA5N3OvA79mY vOdReU/gDqaOqvviXGL/fefQ9bFpFMsQtr+FuO5kovdK46pNEP6Li1A3wuO/OpGs2bqPzgF3 3fLugzvgrhPMf3WibmzT/uZiei/H3e1vEDewKoHuWgf5NRdPDW9qmiKmdZtl2t+cq2BJknRi /puLeyMbaWVDuzLDf4HoHGVN1362v4W4ZnlVysUHdzi2JsAPLsAdCs+P2c7Qubjwewc5VvwE 9EWZSbn0UylfoeMlpOInF8pUl1NEP73d/fT28qqOLi+EiyoYAD6MEB8UyLsRybshy7sxzTud p4sc8VMK9zkbFXUDCU0iITI3yC/p1CgOjSIeszYj2kZlbRTSO0V+p4jHpHcj0jtZF/WfvWPX Hsmv3ok33aqrEPQACq0VURGtpIWUJEckku7tZ+t4p7ndjZz2d7rj/m7gnD5/NkSACEAwEbpL aVt65Jd0go654sY/pSP0oViXVXHvJEPIHuYYIzpGdg5SgaJM97IV9ADdWtqZG0f5jv0nnLoP xWEfxwfNkQtUgFg30yDtUpoCYjkYdc3hQKbCKsS6LScd1spUmDLe1EUqiGA9VFygAu4qqgNA MABMWqTIh/CRp51wrioEHIkJnul3Jei8i4oFRzzXYwPHqjo0c8MScG/I3HgMXC9zRqVkx9xn BzzMOU0QiRcBOC2X3Pt5ghnAwlgMXJssW3SfH64xV1jBjRb1WUW1GDw20F1ybljfddG9wKUY ER//9Kfdj6z+f4vuuhpDF0G+AsmHrKT8hLzESEkHudHdbzTH/U97da5DF3WgKDuWvTv/Up0O cnijSXqInOvqPzvHQ4Mzigu4SUMiFJmEnXk0KZhW0AG0JRpV0AFYH3pgiJT0kC8NUt2/NH0o YF5bs7ITdACxwKDEUyeQALhWr6tyVYEEQH+O5QAF0Uk6CHTXWUNc9RAp0SByKlOTqBDKX8fT MEIkQUjzBile4CIZhqUXSVDJemdqfHSCHsB6FLhSAULQA5SRjSpQAQMzypEVQvBhjPnQg0Y0 QxbW74+0/CclHWQQWD2o/OvDwPWD4kyo6kj6pNLSWk3mvIFb1DTXTqJBtJwgJR2kQJfeFT46 h1HMDiO2irASHfyrd4J524G+KpTAUZGohmUCalyt2HUCCWindAaFWxd34LqslDzPv1QnzKoM 3ZlLOogWlWosEj0BiZaChMKGmt6Rf851CwQi+ZdONRlncVXY+5GpgEx12Ou1t5QMIXotrkl1 qBbPvUgFjaprVagCh22PIhvA1AmFsVgFD6rxXqSCxnWtJlWhvPpkLjpUSkdQrVBq0hFUz1Gq dAgdVNe6WAOjkfdo4PW4NtOkKnSQsTuJChkFdxjScU2lSUfQUaSMai0QFk3OuuKDnNgJVaBe UUmJClHGFbpIBbER/p6w+ImOiMeVjh+5aqoogxcMdQUh02Ba7SQlKmQUN8NoGVZFUqSBhlVS J1JBFOWVVvOqQg0I15/rKJCoENaxLTDFUYa/dvPC006q0lQdMqpChnXjoFqEz0EgOpECSrFe toRAAUz4M/BqFFvDmNJjSYshmO5icRbJ2c+hsAMOY0SJDUzi9m1FuENFQAayDhZ3jUX30Tkk Xc7pPjoHdEYFlbNumqSD9NWO/OqccF3lrPE/RZniryrsgH3WlV/SqTwe5fS0KugAcEl51hBZ LgcyCWN/FAB8dU59AsmvuVaabyXZxcmfnz37jq/m83X93V7fwjIWA18njQqCdRyXaJAKxwNI heMBJN8f5Oz0SDqEEnTMkdy6NemiqZB4j0uZX8ZiHZwPYfkQEMX1yNZOqkP5hNcQKYQakJb5 KJKETIXBtvN+c8pIqkGbgbcgGAD2EX3cTRKOxUNwkkdjKAiHQJZf8dBEKR6Cq/jPz8dYLh1B p1irKU5c7nE3XTfloCrEya0OBIEGYL3CIYSLNFCZw67FQZxLqQ4tSNlV1EOhBqyaAahqhgB+ qmIIEkctdOBEgZZSDVqXxf3dAChkKiw57OFngiodqsg1+DlOjwMkF6kguelSFWiAIsFRMcAI mQa7Q4M44RIVouy21EUjkL77ctpJU6rlnjJdpIJg92MkTtRoSEU+hpMprJ54RzII+JHo4cZP Dvs4asjAwl48BCuz42PxEDxRx/biEZhUVTUB5uIhuD7Epzl6xW2oRlE2p9U7jZTqKJ6IHyHW wMrO0IFMg6X7S3RGWVTswXWAHzgOFbPOeazWO2lKw2YED9oQ2Nx3S5pBIyelGhTiZ3+gz58M qmjVYawQ07spOIjH4DSZwqbJBDRHFHXdxkkXTaUaJnqlJ/Xn8p5QPKzZpVSFqjswBzINNmon Rs1EnuzP0SAIrUyDlaMiKkQaqBp3rFqZBqPV0EOQaJCGokGSCZEKKtBdQ0bGS6kGrQZsIFAB VVRHgwwoRBqI1UgJLoeNfi/WwYch7DAE7OWq9FCoA/GetUw1Og6xUq7Dh610NWymq/hMp6oh Ra7BUVym6XTzOnDT1eo0L4shXgg14OmesH4QTEAOwIqDpiAnPTSJBqnxOaKIVKOqU3PRVUb+ jzyuy35IOxRqQDKMWjKI04lKvRrX6KNEH6Y2zHbEQ0g2MBt2tDX10DspVaHTA5nJQYy6R2wg 02D4ONEFkdIBVG4cG8g0WD4oWiDQAUOzhjblFcsBo1B2Ug0Kd6TCjssBVoo1cIWiWzSokTrh ABjjKBslryLX4fhY0iGUyzSYshtuINNg96TfMDgUqkB+DldDiZO5KoQMIhEEGmDczR/38Zt4 D8evhjm0F+tgdXfXSKpB4SgxT6oBuJercG1X1lCoAfPhKJVLdMhEm9IJVeCFDhuUS7e42S7a 8/E0Qd0k/UiqQavDAFUdNECCijJBOqaVaTB+ik2eYBhKVWgaDQxLI92m9l/WYSgGSM0FVApE mcXtqKv7UBy0DTwDmQKD3RIahgskoMbJESnu4rtzRvSEarn5R5N0kDRJcO/MvzqnU0lozBJS 4e9FHQgrIcSpIt6zMqg68W/NuRo4V5pzdxpI+Vack0xzTTLVMY0wPWnuQqJAjrrd/FtxhvHC 8++uHz3SQL1UgWaZHkz4VpxzxMbQGkBIVAg+6IB2zrT9lEM55Vt3lj1HXaSASDbECIkKGfpD Bh4RqkcZfCvONNLVaVQNnIcmtCIV1K2gKd+684hDiFSQcspDlSiQIcmA4QwjxhGmE0ogqz2+ KBD+KR1J+ZzllKeKeyfpIOy/fUlkL1QXKSBMag0B350zPNjcO/Kv3ukW3Z+vVVchkICq4tWN gugkKiRBKdEhXNJB6ijBd727+OwdL/v4oLryb+lcNlSpW8Rn50j4BRWsY6f4rsh6GK5UAO6t 7/cAy6/WiZ/w2kVqDaSIdBAdQugQwDcr1sUI18mHcDVnaUINmCRD40AyhEyQdVINqs7uDYUa sDpFBF0PgK1QAvOdWjt337rzPh4hQDQAKbWwIhqC+uHdSDqAVkp2U2UDGImqEYxE1QiGj/mx HiOFeAjuF0xH0iH0noyB92QI09O2lw1h8RgVqyDWYy/27VUXGlRzUBT4NTUqUNxb0wOUxXBN 0kL40cVdMXmisRfr4OP+1zdDJJcNYRG5L+IxUoiHYLUDpglHQL0jNZQP4TEmcTlGC/EQjOLT BJZLR1CcyrH0hHwEpxPBQ3QcPN7tm4KeUD0C89EsbD6I7scqquNQUe1UacIJIGtG8uZuEt46 DZVOcmFnJB1CZ2JxOhJxxcpA1dAJfOcyVLkl4kWkkUbnMFTIcjwGg3AIzFnjFk1lxM5hpFBV E6WBS4fQskDwpMFEokqXoQrfkTfGC/EIrHQgNeEEsJxi5eIxGN5rnIQLh6FCncaPnvz5u7FC 5zBUIBFsAx7jW/kIPpP2M0kvxGpdPuE0UuIvT40VuHgIpmjCeIrGlssTj0PhEHj+PJGnQNgC MfSocJxXzyRMEQ1BWkOmSzWoPuhTZQOYXpvp0gFUG95qQg14VPrBvWQImQjIcSogxQBUDJy1 ilKVDWDjAfjYZaCidoBU2QDGehujqO6kA+g4zMU4xMPYG8TdKJ8Mc0m1jxplyK4JB8DBtMlA PAAnTZ7fF2gMlw4DBRQPE0/IhrAijkZhbqUDqDpEU2VDWFZexjgQDoF1dBwDQTgETvCN2KAk jmBcOADm+mhtIB6Ai4kEKsapU9Xl3f0IKKQDKGz1GPsupAPoOMNOFNFqlCjDFBEX64zisBOr YBoP4hAEA4C62j8WD8EpycfQlOQjIEFfxkAQDoH8qPEYKsRD8CgKO+EAOCz3QqSCmmQAaZIR YOxdk4y8e7aL9PqBCwaAZyPEMx2CSDWAgGQIGdJw0RC0r/HnIolQNgb3TprSuMF8Nm4xmagY gYoxZNSG9NIRlPV7KRuHDuNPcxopDVuSXjqG1ihVZoFGDiOFYYL3Uh06jq5RZFXPRnV2Lx1B B3WiFI6AE9Wd5jBSmAhSNR2kqYpFcxgoaJN0mnACOI4wIR1ACYpHQILiCdiYkAs1YJ4lUxEg xRq4SIaUINEgFc6HGC4agSY8lWINDDOP49zUSTUoG8FXaIpZcdAUWKU3BZdiDcxqtimwFHfg 6o7FtFKk2m/dWZ0+U0RDUDUGVUOQVtoV2QCmWa7IFBgZmE10s9nnsCnUpAPooNnSpAPo0Dai 23aL7nfy2hblW3ce2KZLB1DVQ1Wmw5SbwHqJDiGlMnOoyloYXLm1K9TBUS/pIHG1K5RuSPet O+/lTtGBbAgri2KMA+EA2G8hGQoHQHUuXpUNYBNB2E8Eo8jIGJaRIayOJ+1rxUPwlzHwyxCk pZQmHAKbQz0GgnAAbAgaAxuCdOAF1XU5wLWyDkZ2WOlrtZ+ao5ZhFVEPKojqXhDNaT+wQZFp MKVSkgINoNY1vaSHEC0YpNKcBoEUAhUw7GlrQh2oVy6aUAcOIq4TtSCSH2BWuz9jMZApMLnf R/nWnfWypwkHwASdRziQDWBKvlZEA5CWXTXhAEjraGwdF04A1XHRUM7hKdnd1nL+svvqnAq5 8th+KA4w3pc78gYyBQb3hWb9GuJAqABzCK0Oa0UqqN/2oUkUSL8jRRUoAOViG02iQGqqewLf qvNZnRPSZQpMrv3KT+n4RY/ZL2rcsgRQNcVn53iX1IN4kpIWIu5j1FNVlekw1Q5FNALt++2/ E/IRvN/5NBaPwKMsMuE0Uhpkl5HDWEHLOkP5CK5lo4F4BFYOx0zIB/As7w85jcUtWNyaqSWP IhqBBrExchgpDLPw2GVCRQ/m2IWr0Pb+lxYnPzVHPllYDyCtUAfi/iK8oXAAVFJsINSBSk2r y3TYOSXyOPBIqkHVnKXLOOzSXmnTIuSn5rhXSQZCHagEU5fpMCWUugxgcOvp7v1vL+Fk/g1t cUOhBP5y+Cz3C6oCCfjQ3vKpQKRIglARw2s2RwUkRRLUJ3b/KR3hz5W8EV0X6aD+jOpApsEG iN6xZrEub+TTJBLCqrK6W5xVBRJAT2q0wlfvdF8h7WqWkZRDxQ2zu/49B00yhMCu+TGMS1Wo vP5EFWiArLykWKbCUKpBiwGo0J2bNO06dwOZCosjmVaqRIPI+RdNokO6Kwg1yRCy77PPUKpB 6/uKDiKqlakw+TqEKtAAg2hM9AhMuivwVIEOKIcA3QK0LwcmcMkQcj3GXOugQ5zgQf5pZRqs HqRnd/e8/D4PEgoEKuA0yqanYRbNlEpAE6kgeeO6KtABT4aAJwPA0yHg6QAQj/yIdU9YwR2X u044ALIak4yAXKgBxb/j7Kw6TCicJ9FnDVqhXEeBYAC4HiH0EFe3MXk0BAnZEPb9GPW9Bqrl HbyaRIMMk6AepEAdPxkCngwAT4cAPZnVa5kHMg02LKv1oKySKEXKDrSxWAOfBmzddcfyuzvz owoGgOsR4noEeTzGPB6CxpgRBLr5Y4OEVINORMA48Pc5PF82KA1SqkJpRgaNH5dokDzB6aCw tDINdkflaxoDmQq7e/rdn3UQlwwhrB94P4Zx6RB6fjwGnkUEi9vXd/CnHxIMhSqwu75X+Vac kxqfuwZXFykg/Pz68bOnGqgVKaAcDg7J80RDoQIU/+yLw60GVcQaGMd79mcAbYUDoJzwGchU WHYH/w7tVMQKmGTywnpFwAH8TvudfIdL+Vac1Wc0dJECEv9ooFakgJRr1zWJCtGvUx9JObS7 Wn+XNHxLNu3xk066El9ES4b4VjqAXk7lGMmFOhC2Ko+AQjgAsr70GMiFAOyu59/BzdP99vex WAPDu0bySZWRVIPeonsWlUPaTqpBux8DrBTrYKXhHgoHQEK7B4qGwgGQjwvGcaA4aAoUZ8nQ WCHjsCre9ft85JfqtJe9Wk2iQW5R9zSSLtJATdGtSOuiDhRn3YBXfqlOMKmvO3OJDpHvqumi DqQFRQ0F+73nHXrNuRV1IFhN6t+50CQdpEBUeVxBEXQAOEu810PaizSQ7lMv0kB1PsSApIPU 0aV3hQ/pUClR2U0Ctr9h1kVz5AIVkJOjDgCBAjgMAtiLNJAewF6kgNCABikc5KyEgZxj1WGv 52kpUSHJUQckR81Zy22doAMoJ5r6z87xLql7J/hoHRgJP1bJT2nqoZ9wUpT0jNlLFMgoa2pC FZhNeC2FClCZf9IkCgSme0dcUqgCMdExmAyc98rs40g6gmbZQXYrpxwGCslhBE0OQxCNjiMj hVAH9k/KaCIVNBXFxUQU1+hOw9ToTnMuYNFRN6qTqbAvTdndrKOLVJBWM/YSFXKRV71pEgVC 8j1/d1hDSaEKrORkmCZRIPeV5n5f6Y7jGLyvRhF4X2kVjSLSQPB0T/dm0FCoAZsKXmWa8lp1 0VTu0nrIzEUA6t7D2e0ruIlf2SU76TJWyZWb1yZdxipKzTTloCmAOKq6fZdj8QgsliYm4K3D SEF9MW/KYawgb/obi8fgMplV6JymlJpsFEWqC1chuxzTK4Krw1VcVvfKI7PTTq1St2glfkph /0Bj/8kd78lOWUnrP6WjclmN8i2d+UhAcRbf0hm60HDrg4KQog4UxfLFn+6rd8pUl6x3OMrb 6fpP6ag5qQ6EjekVJ/4pHbs6rPvoHA4q3UGhOyjvG8lP6djd6tl99A5EdSCqw769vkUDSGEH hGZGPuSsCnpAFR1whuVrVrpMwuJEDmqVb+ncd/L7z95RjZU4UaIlZmN8za1WHU+a20l10qMz 1qKTjVgGxrYCBZBqrqnqRDQnojlpBonv3lkveZpIgvoOd//ZOcLlclH8pXfuBBLArwDZ9+cr h0Id2DejA5mE4SNWQ9R+98616larDn3V2n/3zuRWdSS3mlMWHVCmuwuRCmL9lBjpICGSoNtB 8G71oMmLkeSXdCrzqDtjo3xL57OWXcVn54iy9PF17yg+FcdnTzTHZ09UR23TyUCmwo6o6O+d HgolsH/kuv+UjmctfcSn5niKiiRD9QDTSTWoVpSkRELu1Bpb3uYoPliKUFW5FXSAVKsuU7W+ VF7n7j+lYxJrivxTOso9e/JLdeovRNEkCkSj5p/SsTjvlaftVEkHOWoJfFSTFrMK49y7iU/p mB8jtWlrv3XnfaRV5apwAJT3dQ5kElakmdZ2dIIewHrJdVOp3kmRAlK7cKpEQspYDtGVb8VZ Teb+UL780ruiQ6mEVkqi4qpPz88RVvj5l3TSbhnUJB3kVsugt2oGhcPvajXWfkvn8vBZcYQv 6aQ+JaoKekCtOtaqQ6TWirf9NWnwyYZ2t/ImCVXQA4pbtcy337pzfwH8QCZhWhdQ6wHCR6q7 pZqjvA9BFfQAuRzZf2qOamp0gg6gdd/7b+msdbJytZeVxyetQWi/pXOiVOrdQqz4/VR1eKo4 DPJ1J5AAlNdRcVSSUkokJI9Uk/JIMYj3/RVH8d07N2rl38+EtF9EU+2uruRf5Kg4tfNk7W89 +sS3dKZqwuRUTRV9SKCPCOCybdw7is/OUbk0rP+UjrHWcRGfvWN376P8kk6DhKn0dKmw2jvj X9JJvjEsv3qni1qqxKd0ZD3aWutdS0kPUfOtvGqx+1A71u234tyfBVIFEqClTKWmTDWoTCq9 MlFWjPrPzhGWutVavf2WzgjmBxVn8d07H+ESHqy2lIqsh6l3NWqSIUTroqhCCdRKU62WpppW 2hik/ZbOTaH0yPlX50S0MkHUEkFQhtTmvP1WnPs1U1XQA3LVMVcdIs2lH3uSk6pzUnTUV4j7 b91Zi8JeJEG50p3uLpHkv4uyVJ34p3RU7jpQvnVn3WftToNOoqZP+907a7dS6iIJ0oYK2kBB e/C4/5bOSuVF+pqL/QcD6asTTpT8qUkH0BFKA9CBO9Wctc58+604q3cg6yIVpDxv3H0rzsq+ ck2iQGiuudM+g9GI3A7qi14kQeojx6pAAuSuRfmlOh10t4PmWFVEd64qnbgeuNe688B14KhN So3mpEBABwCqO9/prn0+grqmoEot0gkkQG05qNJosN+wkkw0VyFRIWot3X4rzvA+YZNRnUQK NeB5gOmHLoMhgN7/168o1SQ9pEaJ6l6jvuQ2atFvlHLfKPV5Uyji/pFq5bt3lqeH+k/pSNRm XB6i4h+UvwyiuLaCDnDO4aJzRb0TSEAx6Hp0gh5QqnXJWW6Lhq9LhJUo5F/SqaxzNZLa7875 rq60OGy/wXnmBfBdOvuAKLjmi67iBfFzrtxM3X2Al+w3ucDicHTsIksXtaBzLh3PeS/U7srT JD3kdgC41Z1Vs9rP3rFUNotrkh5SyeuVlG/dWQ7SdZEOqoeQWgPIvq8q6AFfy0Kzgn93zpBz hn4oMoD953/+5//ZHIuG5fJ6e8AF3EaesUyNM7I7Xd+RP/4BF6yZzLLNVbzZXJWbmnXgNlfH zeWEEBPmm6dPn242G8BugGTHSDSlKZ0nT55wje2j7fHrRugRVmUhNlgr4L9Hy5bBz0Nsa5tA u1kndLzsa45OBjbHFRY2Rx8TY6cojFdEYewVhUnpZCCDu1vIlFabmF1XubWBAHY0D1TWGkeq LBr4s2CdQCvmTVPfXVcLTrvouspsfWRYt9hgCu5xAVYRB6uIq1VkrVUpLhIHwwScKRvT6Ieb Vx9evJ80fmT9ZiPQW5Y1BXGGD7DYpFLtJMaW9GX7quoSqcQsh8MxOL+cUV3zQZc5QDsFbDDi 9R39FUqVrRnv3u1/5ZsEl6zoSHc92pb/QxTfipVOKw8U+CCgpM9IjAEWbfSvXUTrZlASyFKp Bri0SPDZlG1Q2z6fKUfPBzbxPWeJvVEC724V16PRYft0xrCn9jTJUugmhCKQx4tQY323WYxg noyijsQxqo6XQVxNUdOyhPIw6yQ+UOroN0rbkNpWwK2WY+ZRbYQHThytBJU1doKetaXwMGHk YJnAu2dzoWdtFmuJ2ODBofi1Cu6GtYr2ljnVCumqOiE1FGXNoCOi71+8e21vU6vgblaraOyK KJbReye76P0qq+i9fwXKSIgnBbfEOt3y6BbdIof4aRXcY6hVtLfsFi6lcsjlrYK7ZVzNM9Zb z61Dxy9udgicwLuHTehZm1VD3e1glsC7myX07M1C5wKuVS6bysG2XmmFgb2yg5Xsr0vkcfwa 20DP3qysPLIhlYNdQmGFYULR3rIq3oqt8C7W9UorLOyV3ayE9TNXI7nOShu5rpuJ/OCBq41C aaWRQtnNSjiy4Gok11lpI9d1MpGfhHA0UeisM1Ho2ptITi7GMfQKs5iWtUEkOqMreBiurO4n 2SfMEqx1vJsi0T625LTRAjDwTzOFH121j5yC492jR5yQtY0f6tZZp+t669Spu35HkUuLwOHu NnE1a5v4wRx7mzjc3SauZm0TrHcmV3cpcjCs11nRFZW69vUBzZIrlNnPPlylJD4dN1cvN1eH jdDdknL7aEU1wbxeGodNCHeKh0J1csLn0U5yt8FVpu/g5y5KPsMqJ/3qMGPXqWzs5zKkjjE9 hFU0gqX+uswczJI6LnZJJVvD8sGnENkbmTtZl1ubtUvLGu2TwqVXIFUcbJI69pbhLHcZgHK4 g0Ucb2fNIUrgsVeHuTuh4GBNq2FnTxzlzvm813GwqleyNCxOYr7c4mBXp+JiVqdjaVVWYweD GNrFFga3NKNckWrlmlQrHVOtLMgKy6SSk2lSy8625CQOzzp3bTXt3XYL/+c+48MOk/iKOVW7 1pXENa4o2aU1Qgc2Htvo2lfC3T5uOkWHiOlUtvxsoN9smOTKUESQ74wmRNRVCRu5iwBUwrCF pHegadPFMiN1h/4ckrFTcUlHebbQM6okj13ockQcKl0OdwkV4C0taXKHWUJAd3aIQldzEXRL Z+jmTGRA16XPuleaWfiUgGEQU+IWyJS4RDdXsI/v0mHhXOAdjSnNa+bcmDQlcKjAoSspFFw6 kkLD0h4S3zoYw9AuljC4vRn71CXLdBp62eDShkll8eiZle8n22toxSZAlqECsEPIsHPIcB+y AVdOkpI487VajonXqdkGNTm4mJUcnMxJDrZmYDj75GIJV3AyhmvY2XOsy4tLegm8gzVCwc4Y nLoOPzoNl4Fj6jL4wAW26zl+910/OXTYXP2wPUS3G9B2MY3BXRtBfskLytC562vMNIWSWwtd 9Sx12PXD4S7hAbxlPFcOO4AY2MmKdPtkxoYn1gx+/UFgsI0Hh9KI3Tom2LpbAkjqsqmoVXA0 hlrsJ+rsccqnjtnUPpfmLp01DncyJPPOqbltZw9XhVsCF47JCw+wLsxvW3P4xghwLJTeCaGI G2UsP1mndrCng0r1NnOeRZMqDhEsdeySm8Gz0mWrQKvgZhFoWNvjVsO0Cm722NcwDNwUzjEk VNxsEjp2VrlnpRU5yS0j5clTe2sY2MEQuBLDtDOxtcE1WnL3aMktomWqp3UuVL2Z7phGrgct d+kBcLhToHLbPkB+W5RuOwhLl5LA8ZaWwI0kDpYA3MUSfuGJvSX7OPnzs2ffORrUarna1aq5 mIfu6LVTHlK0nM0Tai7mOc03SJXxhINwcp5x0NScg2sx59DtSpTLGLqP//zPrDNl9m6DSXl9 zVTgx/f8x22Ju3+fN/xXt+mAH+mRMTGMosI9eooVUVO4ZQN4N8zZLLrGLupoWJNlK0zjWu7G cTUX8+DexmiFgZ2es4mdoouRxGW/p1TRp0uFOEFndcZUoVcFKdzJZ4HLcCFuRDIiF2DWMUeW d6FO9gv6QC/3HzQPlrjaqAnEJiMwEN8KsmFea/LIadJE1XIuDELNpSg0BS5X1MCtmruBQs/B QteS6tLJQ3dQe/guPMvDBJ7HTLj1djFTOO1YLyKnWClstqcLM5DT7DyHuxiCrOfmOVR0Yhzt EUquVgktS9tSl637gHaxJrXYpS/MKPkRjnV7XVrl7l+xc9tIOzK21fYsby2LZajJFXU5+90q uCSB0LCzBy4ZsjHmSXs2DO4ksjcF4PZ2PHM05JmjJc/sTOFnduITcllN73UcbOqV7AwT9zza GyXwejfxFGW076Z1jO3SeUQo11hwn9a3CGx7SaXfZiig2OPHzxdTcqpXBGYvdpsU86YZusjx Z/G3xWiHHk96HuIPvrlkIq4w2LfUSZWcMME7mxXEo3OuG5g0vdm46zFauOHxOodQA9yhKHO8 ZSnmz+g5muLSBLfv9DkYs6vplwbVDkezWwUXq4SGpVmUuGzP5fDxlBec3oqdMnun4RCuTsUu YOTU0KS8LLX/ZYXqiOXhtrH7DsxqtVzMalUszcoiCk2RQ0y1Gi4mtSrOezYyvLxvUSPWglVV lfNeb0XJJXC9lmWU04hlWxY0B8s6FRe7Oh27pSK4KtJlzV7gXezhCpZRxG/qdTCG412MEVcB WxnDetTIZXAp8A7GCAU7YxrHNZ7GdZGncVjlOeOicTjexeEOpnC85dmOO+cDOXfu53HunDYS HJHLqj1DuyyPM7jTXL3T9Eiv4z5Pbz1R0k5X5gd3y7iSs2lcy3YS5466jbg6DafpmztqGhkp G2LhqIS9PRzushmWvyZltIRvotQ+YFltJID/Ylydhiea59bwNhK/jeRinavqvppVnplQ4Prt ZlTFBFJurxWirGAE6Zz7TpXbVSMC/Xgmrh9P9YUe71Ahnnt9PNsderxTmKdJCKJwO5IXB38R WQmCD4+rPRPZjKKsgIpWW02eQOjryS/nM8QiS3vCDg7ZQWqUu1Yc1VXU/t6eBAUu4qxJEHea LiCcwS6XzxjVGjE0ig0kCkKy7jMixSP+pzPNm2gv3hPyIjvgsn3V0Y8m3R2y8pJi/nqYH1XB /u9N0qQpqtt/fMniiFD+x5uozCv+x5+oSLtnHv2I+D++LKwSaZ9z96M5sf97k5AI/vOlYQ5o X3oHqaW59uVBhzjB3oUd1fVOvH7rRXNi9Q7/40uUwduC4q8vVZ5cw3/+NE/bd888aeJr/seX SLzPQLp/venE59mXp0I5/BeIxjuWqtuYPLpu/wlB9r3460sFB9v4H28ilp1q/9xUx0/gP3+a p/CfNw1maZ+0/3iTsWq/9q/2WR8wvt2RKEX8lzfdKYL/AlkVwiKaJzj17jbQO7pPDu0/vmR3 T7/7M/8TjGh/Tu9DkJ0ft/94J+B9fmKJ519/981BiM5/njxpn//07HLx/4J1avdRBc9mds7o XClf7b9t51cf5LVuYrIgJVJH6Zt2UC5ymNsQ/eRV0yJcdeW0iOr5/ITIhPtOlbdD/1YMQWfY xzDW17WncDaoSAdFIwQPvYoBgVUU8nkOUHGdqQFFeHZ4X0WEXMo6WZzf0L0xMF4HpSS0xsVx z+LENAnjzngdilLE5KWlDkPJH1UNF2hEg3Exnj2JTyhMAqP4sLeZN7TlexyaMD7EYQ0MTViF JozTsDFYBuaD8LLuQpMHYfvSsMIbjo4FlNcHwcguNaYoWCVQJlDn8xeoQ1Bisr+g6Na5bpmY auZdE495ZujKmOeb4Iv9N98bc6JZGHO68Sz0oZ2IQvHsszIOEkk0I4+GvUvZEbXtJEKCrelc QkA8epbg7Wy3cuS4k8KZ7O3QoWbglQE++QX4tBTg01SAT7ZLir2BONZMHESW8vyULmzXrlxu EBcK0i/7O8SFouVaszSQpLS6Iqg+u9ySrSi5G6oo2xrbiLfuJoU7GI7Ymw5o4aHtEj4fEBn3 euk2daunbqnuZle7LOpo2WRFtmRaq+BmW6vkdr/4c97Kze9LfLRTaaeDR2KX7X+x6yuascWu v4FBLLe7FSxHk5iGs03Den3RJHJSLOp+7Qg/oiMTapJ2zmRWATtePC98W7xzvmOdDfJVlDjU w62CY2IIpRXpcRUdR9cUG8078kuCnQ0EtTUmsg4zU3WzUei4Gyn0VlpJ4sjdTFBaZScouhhK Jlsy0trvlkW7zTkOJlv0EECo/t7FZZYlwzcy880zxjjyaXM47n/4afvyw6Prp4+2ZUNVn1gX PcrQToXs3r7cv/zl7dsXn17b8cdk//K/t29ufnn+/Omfr65nvBignH1J0P7Va6k/F5AByteX p3bePHX2B2X7nz5Kgu9nvBmg3H0h+9c3xjgboHx9mYuzIczdH7p/bZE2Q5izPye8f/OeEbx8 8+bq1eu/zXgzQDn7gsn+jTltBihfX+bibAhz9ieL9m/fG0MzQPn6MheaIczTn7kabYDy9OWJ lS9PVvry683VC8iqi550IHc/6P7tJ3NIdJSzL3Wz//gra6SeP3s244OCWMneWTeXtQaolb78 9Zc3z68+LnohIM785Ly/MbeSA5SvL3ORNYQ5+9Pc7n99YUyTAWqlLzzCf130QkA0/nYZfLud L0KbqTaq2L/4dbq8rWd8+SI0408/hGZ8/9+hGX+9Ccp4W+7/+nGLmvivH0PQfY72//UB6P7r Qzi6m/96cxOC7etp//I9GPfy/QzdfPdjhu/T37c/4OPTRets6aJ0/98vZmqpWc6nbqRhLE2i /au/hrZ0QBrGUlHxBLZ0QBrM0pfBU39AGsxSVlGGt1QlDWbp+/9+AEtV0mCW/jo37vGx9NfZ Uc5aS1O8//FNaEsHpIEsrfc/zPX61luqkwazNHzZH5CGs/Tnh7D05wew9MePD2CpShrGUkwf IE4HpMEsffPpASxVScNYWmQPUPYHpMEsff/2ASxVSQNZWu7f/xLcUp00jKUV3X8Ink8HpHaW XhtIT/X+54+TaA/OZv/zr4E5q2z/4W1gzrrcf/wlMCfJ9jdvjJzzqyaTAxO0f2HOTQtLJBak c7nJ2VKLlsTdUpuWZH69azKdbvc3f51JJ2XdL8HDZ6unrhMVO6U+vn7x6p3uGajvhNyWparh tq4iyhEZUymOtnwXdLgeE4HUhSGapoi0zQpCXNYJv7VbeKHEJbqL8ioDy/9Vu1NBc2y3JyIa /8cmj27Rhv266hz/baDKUTZ3+Ud5ss2jahNV7Aecs9lEDT2JX5u4LgsaHTYxYRJyqmP+S+zu aH/BJKX+xPAmycW/6QF0U1o1BNVkc0SU3oOE35e82ZxKQon4u2VGlpf2N/rS4HP7O6sSCAXs XeOUYqtHFMeIkPZDWJqXNGF/EpQTuJK5vWeI/WKRfguiC7mHjSItvDqVBctFVY0LGrPQs9yT 4gzBv7SMy4xlMBbYOt5GNId/xE3v8AMez2WeP1I/ruEjxTW6QGQrv58Bzba1Qvn5DH5XcRzV Cfxi0YMjrijvnuMf9/CgNel+UoZALJxoU1fxBjbJYRYNLAehjNnb3q4lgqeGtSGHNvIgw2zh nkr+YjGkRC+pxb+KhCWWLGYiQ0HuOxaN3FHRbg2oInrq/t22ET/S63VwtssxifmvLYvkWShU RxTp/2xFqmCSFJC4/L61jYjIPaInVPPIakiFCh6zNSJNjmCjGkZtrlFKpSxZ1qUlQWnUZJRA fIk4naHbdUhHXhGWB+Jm2ayEiwXs2P/NuGsE1jB+uHm1TyKWL4vdjzVC7HNbpdEk+TTU1Ze2 LTF4sNCyLHAfUEQoRltUTeeTaehaX/hNaHa+jK5ZM/vCDNuyIhmfTH5IoKsPFaui4Qomow8S aOVDmzf2Z9Zo4D6vdN/beNI7o9Yqv9+xdpY3DDZeduBVPi1k62molS9vPpyf7X69efHTNHPv bMXGGsPd+18+vb6ZJJOu1lwLYe6drdluoDFoqlm61t2aj/131V4+OJPFRygnblLGt6wJ29I7 usiu4Kz54yomVwki+Fgs8g9w1vxpWaOrHLP+Ycz6XItejKHWvhASpzahGOBc+MvK0gMNaOUD 3DPIAs86Rwv5fAhyZOZ3GT6h09lzDHNkT2sYTlnw90BHH+C1SdYy1NN1+gTOkT9HRWNhfwdb wc6vJrDzoYM6+kJiVv8XFn70QCsf4jNpqqW8qQIcGNnfK/bvbLM5QjlwJ2Vswa2gHLiPRURt LNdwDvz8tSELfg3nwF+jlA20F4gFwJlxa8wiGs6Bn8EOGbKIEh3o5kORsAGVnR8a1MGXy+Vi 4YGCsuLuZhd2M3GvuLvxiXTa/vDLL58+LDOryFV+fHr97sPbF5/evP/JyqMe7uZbnJUF2nPM ojc9zo3/+rs/bx89/X77/Nn20fVSlbmo4eNnO9+w5XO0Ll5rim4W/Pxp++rNzV/fvr652aVQ BJf9HcHX++YQ2lk1L9/dPfb0U52xs/ZWUVrvM5/ns/YS0Ov9uku6wZK9j72Os783n17togxH BJlDqGBX+cO6YBeYuYO5dBu/FPwq/+A6nQgX1v4p+FX+uWTQAX6Vf1bZsgO6+RDV8Qmf0fYQ xbdVFhWIWbk4GWGlGcIGi1p2QTGEBbhKLxaJbFAOYQlf0VlhBOiF8N+hDbIgCGIRImV2Xp06 irqdNTWGGcfFgqFBnFhhBRPeEsYx+4fL5mbZFjXc/awIapLSxc+hhpWfsJLS9mo71tkVlwHO mv9A2GiF3rORUVxW9zU+nqb7vzNYa38gFuaznYaw4kxxkexxQVGdRjFanmSfwa7xZyEjTyLX +KF/zqxVGHSs/MWHmCwORVSAAyOsJpfbplng7CB2rKxN2MWnqDiygVeTwS2T00VuCmjnA0mK 3Y8v/u80a+toz/TX1x/fv347Tybc7fl+OcNKPbrMM3YIe86lZO/dHfh+YfgX05MBKsCBEWWI 9aXfl3Sm3huhXLhJ2dTxMnELsWe9aSqYeUPJywi26cxS6zh7/k8sa9/+v3KmYKkIe07+Bh4+ GPODjnPnj4oMYdoUx21VTQ835uFrfCMX1tBO152TyNV+zNVFk1B3X9i/rGxTK296rLs/J9bL u7eJsBbo7gN+crhiiXlVoMsBzy/4GXRW+Ms++DODRs8EcJ0PyT6KY5sQSayPP9vKMjwSvs43 irK8ubPJFira3a+8pscrTKrvrPK5irb3i+WluilYblruLc5g1/hjqlOHyDV+yF9XPLnn1kGN Wl5+b587ebo1Px6+6JtbEF3y4/n6kUXuUFFu3KYc0WPceNl/fOfqUtToOCv+2yxZjg4VYM0Y sxG4mVZDuXEvxPIA48bLoo6NKixNH4BX+QS/Z5J0Grrel+lqdxq62hf20yE4HO3mFxsEUMv0 0aArfIE/NukzAFv7lNwXe7Ej2xygCewafwzlZoRc40f/cyHiZvDW/oECg5kjbgh09sG2SpjB r/Wv/VyIwjkFZx/titQkep1flgFTsFb+ZPhwPhqyxADjwssa1XLGag1hxZknZdzpbx9NkuoQ d9bHZtbH7qxPzKxP7FgRRWW9VCNpCBfO+nh49GwmqXSII+v1EyMrQFxYIZNfze1XH2BceO+b c3W7TNtCXFnniq4OsWItED3WUXXa8WM520ONk+N0uZ1EuvnB95/ua5RF98teKEA3H4rj3CyE DnFjraPpaWEV4MbYJNWWNkWBDMb2ODv+izjgt0tKuoX35mdGqhM4N37+lj1cws8Jl/3QsVb+ VKhOc9O5jiHIiXmh0tMhTqztvzPFc4Sy4y5rBlk0WEW4cIp/5pcMxzA79gobUk4BWDOy/7J4 bmijAiwZK1jFqq7gGO0MpYKw5lycIFIB1oz8+OyymT3EmpXP2cC2B35Gc45YQ7lzL9QOE7gV /FVUwBylhQ8tcr0fWzgQjIvpHXGLGk5+Zri4hZPFNnE3wK70xyYOR2g/v6ziclbL2e+mso1N iVzlh21MKlgff6xjcULHyV+C4hpRmzjUkKv8sInDAdbHH6s4nNGx8xeuLmDgxfZbx7jxJjg6 ZOUVTq/k6zNz9BrUzZdTlcx0EVSEKyc2cmJnztLIWTpz1kbO2pnzbOQ8O3KydCV4voiOYCvZ f7Ok/82V/zRT6lWEGydsd7uqyNUJwbHEZXYd6+YPK07897IPHcqNuyKmkgcId05DMnKIK6up PAPClZMaOekKTmPoqWXoSUzwnkb1ERkmcKeAzj4ov2cGQrNoO78Yw3IoFIAz4xYXM0YPQNbM LGSoiBnUFPnT2DX+9D+339n4peKt/WP/GRaFRyg3bvizYL+CceC1T4sJ7Bp/iE1azOBd/CsP n63DNcSu8af/uRyuKby9f3VMdvGpmp+vGqHcuFFGSXMwcXcoN26lVBn4VaSzHwWLVgsPBMyZ nWnl0dxOmyngGh8s40gi3fzABWaxa+LvUG7cvP4xMAuMK69t3iGr8w6xjnviHPdZRGkUn3ZN gelVXOZ5VCRzW/rmwJY+4YpPLe7g11ZcBDjtyxi4xgdxY6GFD/znSh8Gz7UseMGQa/wgWRXV uVVMtVA7X+BeJNBiqmJebCbJxzhnfjDNzM5RztyNFXdjz90UdRUb2mYd48Kb4NqKW8W58rP/ tncmcg5awbyv6nK2hp5CuvpRZ8RMz0EuzDk5WsW7inPlZ/8tx7sErWC2iHcd6eoHH62CdUY/ eqSrH7W9J/U6X0hZmzrWE0BnH2r4uxwIFefMz9UW85ICW8VukZ+GWCt/LmW9eKpecbfng9m0 OElnTxEOQZPXLMNZQ5zRmdk4zePZ+6tHXI6XWQuq8SXPkk7c9gy3d3eHNDoXfjpy98OLmzcv t+9ffDKYJXHf1rL9o+2Pf7cxjQO/sW3XtrZdf0vb+j2Dy6Ytbxx8SMuuLS2zvkA9mGWPLS2b 3hb5kJY9sbRsemvlQ1r21NKyp9/csmeWlj375pZ9b2nZ99/csueWlk0f33pIy/5sadmfv31N +51tVTs9/fmgtlk3A9++HXhk2xA8+vYtwSPbpuDRt28LSG1pG7HumnrbJt+tWLasg307u2h1 xUYbd/cmwzrct7SssjGr+oY2FRG9IgiuP182S+K+pWVbdDSbxUDfzCZ4PAWZyqIAfTObaFzB ZD0yWNXBbO2StZ1tP/SRdUe0qxKMA5Ye6Extamh6oC01UxXbaStU55gQfDZF+YSGs2c1IizR Y+rgm6Li7F27pdLSp4VtlZOeQGl18WaAdwjN1am80JJfN2IMS491LBvEgl+F2tKLW6zM3BI3 PVlF8kNKFpx27eavhZfDFFxfDylVkXCXcA5UHxeamJHjQcw+P8vYH1KVZSYf0+pyBS2zz9OT iqrVSrDyqBh+w3/m85Fgy6FhkYmL7aPt8asW304szKS6XOKYEIprY4XS1f+ZUtupxs1xZGXs yXE4+hLgIrlF974sNYpuQ3CQiy+LQPimTRwR5EuR+BKcYJnOk6NdpfdmYaWYesdICTsiG1+a 9rEyXxZc+2aSpPQmKHwjA8WnkvrWIijDqTeFd4FB3vmUMfgHpEi8KyFEIu8kOUeZL8Ud8rbi DvuWM3QHRz49SVLfgKS+7WSKvQmgBiXeMVH6NgnwOFcUnzxZYJtfRX1r0GNWHnwpSupbDZ8i 4hsdQMH33XnSYELL2rc3dmoqTwbvWvRzecC+tTnj8M1fGc69KzB40sCboWy8zSBXP3pSFCXF qW/mKgsYMHmSVGXlmzuqhpx8OVhFGIKiLDLfWK1RgEqoRhXyroJIfEK+kUKQtxWwW/rsT+Ld NQYO38RlHOfIt8iQE069Y5VfkO1Lwhp+XwrxWrcvywVT734MRVnmnUnoCRW+FHXkG6v0vvJN 2yZEg9nkEfGdDGqKEDNsTRFo5qIpAlTPTREkdgv/2pVz+NevTUGx7yD1EnnHyOWEat8Evpzg uKhnpxkmkpMmpvD2+BJVP+M8NfdtvsUPZq0jQuDm+Mfb6WlrO5IDprDeVBw9eaAu92NIKzag rMvGm0jErR9HRU+8Z+jH8qVBDfLkIDSJat/UIfcE5nGIJw3FOaqjZDFaJoQ7lsn2Yqnj8WyZ 4CglK84zxRliXakQTAmKsyBEaRomaGlKgvAU4eKItzUhiALxMMye4K8oiE18Ns6XCCURjRZZ uspxRp+iu2UrlvXTimgV5wzJoH6d42Ig3nkLQEXCUTEQoTi+vQ9kVziyGgWlI3CrC1quTezj LAzV2zc3n/av33349P8WufrWbonm/aePAWh+fv3iVRiW/Zv3bz69efH2zX+//ujPCGQhWG5e f/y0f/HjpzA2cbYfXv/4y8fXwejCpMCPbz7eBIgwCNmLlz/7E71//VsAcz6+fvfL3/yi+iZQ obsJVOpuAiXXTbD0uglTEdyErwluwlQFN2HrgpugpfcmTHG5CVteBFGA0H168ebt/w1R/Foi //IniAIUwJYoRAkUVKFiO2wZFJz+hbDjCVUKNb5QUdfSwUcIurcvwmQy/+pB8ISoH1Qm/3gP VT+Eqh5C1Q7hKgeNicX7315/vPFLwkC1zQNUNoHqmsBVjUYXoPcftuYKW3EFqrcCVVuC5gPL 9AFoAlR+56iO6uPy1KIyzzxHspcT0R4cyDBNZcPBb3byY+FT2XBT4BKLNt+9wIOJaXKTw/pJ 2T/+ISv+YgP8y+Z9uSFNfNrw+2zKepPgGsWwQ+yPf/j3f//3zeu6ZsK4TNDm0R//8Mc/3NCy 2shbz+SZkI5/66rlpGAJ/r1g0dfoK8r+9/+CpZA//vEP/J8//OEmrnFFN7ARe1MWm08N2vxX VGwePd08evKX777/y+Mnm+vvvrv+w/8fXJr46O+5BgA= --mP3DRpeJDSE+ciuQ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 5:26:38 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 4962937B405 for ; Tue, 15 Jan 2002 05:26:21 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g0FDOto94708; Tue, 15 Jan 2002 15:24:55 +0200 (EET) (envelope-from ru) Date: Tue, 15 Jan 2002 15:24:55 +0200 From: Ruslan Ermilov To: Emiel Kollof Cc: freebsd-current@FreeBSD.ORG Subject: Re: World broken again? Message-ID: <20020115152455.R46269@sunbay.com> References: <20020115131045.GA1838@laptop.hackerheaven.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020115131045.GA1838@laptop.hackerheaven.org> User-Agent: Mutt/1.3.23i 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, Jan 15, 2002 at 02:10:45PM +0100, Emiel Kollof wrote: [share/man/man3/Makefile breakage] Already fixed in src/share/man/man3/Makefile,v 1.21. Cheers, -- Ruslan Ermilov Oracle Developer/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 Tue Jan 15 7:31:42 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id 2407A37B41A for ; Tue, 15 Jan 2002 07:31:40 -0800 (PST) Received: (qmail 12114 invoked by uid 1001); 15 Jan 2002 15:31:36 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 15 Jan 2002 15:31:36 -0000 Date: Tue, 15 Jan 2002 10:31:36 -0500 (EST) From: Kenneth Culver To: Michael McGoldrick Cc: current@FreeBSD.ORG Subject: Re: rpcbind panic In-Reply-To: <20020114215335.A15798@linuxdriven.net> Message-ID: <20020115103118.L12092-100000@alpha.yumyumyum.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 I can second this. I have seen the same panic, but was too lazy to hand copy it. Ken On Mon, 14 Jan 2002, Michael McGoldrick wrote: > Kernel and world built with sources cvsupped as of Mon Jan 14 18:44:04 GMT from > cvsup.freebsd.org. > The panic message is hand copied. Please send me a mail if other details (eg dme > sg) are required. > > Kernel trap 12 with interrupts disabled > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x28 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc01d9f07 > stack pointer = 0x10:0xcb5b8b4c > frame pointer = 0x10:0xcb5b8b5c > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 178 (rpcbind) > kernel: type 12 trap, code = 0 > stopped at _mtx_unlock_sleep+0x9f : cmpl $0,0x28(%ebx) > > > 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 Jan 15 7:33:13 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id 3B72537B400 for ; Tue, 15 Jan 2002 07:33:04 -0800 (PST) Received: (qmail 12128 invoked by uid 1001); 15 Jan 2002 15:33:00 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 15 Jan 2002 15:33:00 -0000 Date: Tue, 15 Jan 2002 10:33:00 -0500 (EST) From: Kenneth Culver To: Michael McGoldrick Cc: current@FreeBSD.ORG, Subject: Re: Trace for rpcbind panic In-Reply-To: <20020114225456.A25590@linuxdriven.net> Message-ID: <20020115103215.L12092-100000@alpha.yumyumyum.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 This is the same backtrace I got when I tried it too... The system would get all the way through booting, then fam (I'm assuming) sent something to rpcbind, which then caused this panic. Ken On Mon, 14 Jan 2002, Michael McGoldrick wrote: > The trace was short, so I wrote the whole thing down. > > _mtx_unlock_sleep(c232c834,0,0,0) at _mtx_unlock_sleep+0x9f > unp_externalize(c0b6ab00,c0b6ac00,cb5d3ccc,cb5d3c8c,cb5d3ccc) at unp_externalize > +0x38e > soreceive(ca29d420,cb5d3c18,cb5d3c44,0,cb5d3c1c) at soreceive+0x376 > recvit(ca284304,b,cb5d3ccc,0,ca284200) at recvit+0x121 > recvmsg(ca284304,cb5d3d20,281221c8,bfbfd550,2328) at recvmsg+0xdb > syscall(2f,2f,2f,2328,bfbfd550) at syscall+0x2d4 > syscall_with_err_pushed() at syscall_with_err_pushed+0x1b > --- syscall(27, FreeBSD ELF, recvmsg), eip=0x280c0657, esp=0xbfbfd500, ebp=0xbfb > fd5cc --- > > 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 Jan 15 8:18: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 3AA3237B41A; Tue, 15 Jan 2002 08:18:18 -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 g0FGIGl14999; Tue, 15 Jan 2002 09:18:17 -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 g0FGIFx80739; Tue, 15 Jan 2002 09:18:16 -0700 (MST) (envelope-from imp@village.org) Date: Tue, 15 Jan 2002 09:17:45 -0700 (MST) Message-Id: <20020115.091745.128932529.imp@village.org> To: shizukakudo_99@yahoo.com Cc: freebsd-current@FreeBSD.ORG, freebsd-mobile@FreeBSD.ORG Subject: Re: Melco LPC4-CLX-CB support in 5.0-Current NEWCARD From: "M. Warner Losh" In-Reply-To: <20020115110853.2273.qmail@web11401.mail.yahoo.com> References: <20020115110853.2273.qmail@web11401.mail.yahoo.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: <20020115110853.2273.qmail@web11401.mail.yahoo.com> Shizuka Kudo writes: : kernel: found-> vendor=0x10ec, dev=0x8138, revid=0x10 ... : kernel: cardbus0: (vendor=0x10ec, dev=0x8138) at 0.0 irq 11. Try adding this ID to the dc driver? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 8:39: 6 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 4D63037B404; Tue, 15 Jan 2002 08:39:02 -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 g0FGcxl15151; Tue, 15 Jan 2002 09:39:00 -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 g0FGcxx80913; Tue, 15 Jan 2002 09:38:59 -0700 (MST) (envelope-from imp@village.org) Date: Tue, 15 Jan 2002 09:38:28 -0700 (MST) Message-Id: <20020115.093828.25994755.imp@village.org> To: shizukakudo_99@yahoo.com Cc: freebsd-current@FreeBSD.ORG, freebsd-mobile@FreeBSD.ORG Subject: Re: Melco LPC4-CLX-CB support in 5.0-Current NEWCARD From: "M. Warner Losh" In-Reply-To: <20020115.091745.128932529.imp@village.org> References: <20020115110853.2273.qmail@web11401.mail.yahoo.com> <20020115.091745.128932529.imp@village.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: <20020115.091745.128932529.imp@village.org> "M. Warner Losh" writes: : In message: <20020115110853.2273.qmail@web11401.mail.yahoo.com> : Shizuka Kudo writes: : : kernel: found-> vendor=0x10ec, dev=0x8138, revid=0x10 : ... : : kernel: cardbus0: (vendor=0x10ec, dev=0x8138) at 0.0 irq 11. : : Try adding this ID to the dc driver? Obviously I wasn't paying attention to the rest of the thread. Please ignore this. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 10:20:20 2002 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 3682737B404; Tue, 15 Jan 2002 10:20:06 -0800 (PST) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g0FIK5201121; Tue, 15 Jan 2002 10:20:05 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.1 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Tue, 15 Jan 2002 10:20:05 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: stable@freebsd.org Subject: cvsup7.freebsd.org down until further notice 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 CVSup7.freebsd.org is having hardware problems. It will be down until further notice -- probably at least 2 weeks. For a list of mirror sites, see: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html#CVSUP-MIRRORS John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 15:53:59 2002 Delivered-To: freebsd-current@freebsd.org Received: from router.hackerheaven.org (qn-213-73-194-22.quicknet.nl [213.73.194.22]) by hub.freebsd.org (Postfix) with ESMTP id A33DD37B404 for ; Tue, 15 Jan 2002 15:53:55 -0800 (PST) Received: by router.hackerheaven.org (Postfix, from userid 1000) id 553A11C14; Wed, 16 Jan 2002 00:53:24 +0100 (CET) Date: Wed, 16 Jan 2002 00:53:23 +0100 From: Emiel Kollof To: freebsd-current@freebsd.org Subject: Netatalk broken in current? Lock order reversal? Message-ID: <20020115235323.GA37379@laptop.hackerheaven.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i X-Mailer: Mutt 1.3.23i (2001-10-09) X-Editor: Vim http://www.vim.org/ X-Info: http://www.hackerheaven.org/ X-Info2: http://www.cmdline.org/ X-Info3: http://www.coolvibe.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 My kernel compile from fresh CURRENT sources bombed today with this: linking kernel.debug ddp_input.o: In function `atintr': /usr/src/sys/netatalk/ddp_input.c:51: multiple definition of `atintrq1_present' intrq.o(.data+0x0):/usr/src/sys/net/intrq.c: first defined here ddp_input.o: In function `atintr': /usr/src/sys/netatalk/ddp_input.c:51: multiple definition of `atintrq2_present' intrq.o(.data+0x4):/usr/src/sys/net/intrq.c: first defined here *** Error code 1 So that leaves Appletalk right out (which I use. I do own macs...). It compiles fine if I leave options NETATALK out of my config I also had some strange panics and these messages appear once in a while: lock order reversal 1st 0xc185e934 filedesc structure @ /usr/src/sys/kern/kern_descrip.c:925 2nd 0xc0419b00 Giant @ /usr/src/sys/kern/kern_descrip.c:959 The panics moan about a kernel trap and some mutex stuff involving Giant. It only happens when I start Samba. Any leads? Cheers, Emiel -- Demographic polls show that you have lost credibility across the board. Especially with those 14 year-old Valley girls. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 16:13:16 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id A5D3C37B405 for ; Tue, 15 Jan 2002 16:13:11 -0800 (PST) Received: (qmail 5263 invoked from network); 16 Jan 2002 00:13:10 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 16 Jan 2002 00:13:10 -0000 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: <20020115235323.GA37379@laptop.hackerheaven.org> Date: Tue, 15 Jan 2002 16:12:24 -0800 (PST) From: John Baldwin To: Emiel Kollof Subject: RE: Netatalk broken in current? Lock order reversal? 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 15-Jan-02 Emiel Kollof wrote: > My kernel compile from fresh CURRENT sources bombed today with this: > > linking kernel.debug ddp_input.o: In function `atintr': > /usr/src/sys/netatalk/ddp_input.c:51: multiple definition of > `atintrq1_present' intrq.o(.data+0x0):/usr/src/sys/net/intrq.c: first defined > here > ddp_input.o: In function `atintr': /usr/src/sys/netatalk/ddp_input.c:51: > multiple definition of `atintrq2_present' > intrq.o(.data+0x4):/usr/src/sys/net/intrq.c: first defined here > *** Error code 1 > > So that leaves Appletalk right out (which I use. I do own macs...). It > compiles fine if I leave options NETATALK out of my config > > I also had some strange panics and these messages appear once in a while: > > lock order reversal 1st 0xc185e934 filedesc structure @ > /usr/src/sys/kern/kern_descrip.c:925 > 2nd 0xc0419b00 Giant @ /usr/src/sys/kern/kern_descrip.c:959 This one is due to not releasing the filedesc lock when grabbing Giant to free oldofile in fdalloc(). > The panics moan about a kernel trap and some mutex stuff involving > Giant. It only happens when I start Samba. Having the actual panic messages would be very helpful here. -- 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 Jan 15 16:20: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 3221737B405 for ; Tue, 15 Jan 2002 16:20: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 <20020116002013.MUDJ3578.rwcrmhc52.attbi.com@InterJet.elischer.org> for ; Wed, 16 Jan 2002 00:20:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA83682 for ; Tue, 15 Jan 2002 16:03:29 -0800 (PST) Date: Tue, 15 Jan 2002 16:03:27 -0800 (PST) From: Julian Elischer To: current@freebsd.org Subject: LINT not compiling: 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 ../../../dev/usb/uhci.c: In function `uhci_dump_all': ../../../dev/usb/uhci.c:694: structure has no member named `hlink' ../../../dev/usb/uhci.c: At top level: ../../../dev/usb/uhci.c:1270: warning: `uhci_reset' defined but not used ../../../dev/usb/uhci.c:261: warning: `uhci_dump_ii' used but never defined *** Error code 1 (continuing) cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I/usr/include -DGPROF -DGPROF4 -DGUPROF -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -malign-functions=4 -fno-builtin -mpreferred-stack-boundary=2 -pg -mprofiler-epilogue ../../../netatm/atm_subr.c ../../../netatm/atm_subr.c: In function `atm_initialize': ../../../netatm/atm_subr.c:137: `atmintrq_present' undeclared (first use in this function) ../../../netatm/atm_subr.c:137: (Each undeclared identifier is reported only once ../../../netatm/atm_subr.c:137: for each function it appears in.) *** Error code 1 (continuing) cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I/usr/include -DGPROF -DGPROF4 -DGUPROF -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -malign-functions=4 -fno-builtin -mpreferred-stack-boundary=2 -pg -mprofiler-epilogue ../../../netipx/spx_usrreq.c ../../../netipx/spx_usrreq.c: In function `spx_input': ../../../netipx/spx_usrreq.c:226: incompatible type for argument 3 of `ipx_pcbconnect' *** Error code 1 (continuing) cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I/usr/include -DGPROF -DGPROF4 -DGUPROF -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -malign-functions=4 -fno-builtin -mpreferred-stack-boundary=2 -pg -mprofiler-epilogue ../../../compat/svr4/svr4_fcntl.c ../../../compat/svr4/svr4_fcntl.c: In function `fd_truncate': ../../../compat/svr4/svr4_fcntl.c:298: `uap' undeclared (first use in this function) ../../../compat/svr4/svr4_fcntl.c:298: (Each undeclared identifier is reported only once ../../../compat/svr4/svr4_fcntl.c:298: for each function it appears in.) ../../../compat/svr4/svr4_fcntl.c:291: warning: unused variable `ft' ../../../compat/svr4/svr4_fcntl.c:287: warning: unused variable `length' ../../../compat/svr4/svr4_fcntl.c:287: warning: unused variable `start' ../../../compat/svr4/svr4_fcntl.c: At top level: ../../../compat/svr4/svr4_fcntl.c:311: warning: type defaults to `int' in declaration of `length' ../../../compat/svr4/svr4_fcntl.c:311: `vattr' undeclared here (not in a function) ../../../compat/svr4/svr4_fcntl.c:311: warning: data definition has no type or storage class ../../../compat/svr4/svr4_fcntl.c:313: syntax error before `switch' ../../../compat/svr4/svr4_fcntl.c:94: warning: `svr4_to_bsd_flags' defined but not used ../../../compat/svr4/svr4_fcntl.c:68: warning: `svr4_to_bsd_cmd' defined but not used ../../../compat/svr4/svr4_fcntl.c:246: warning: `fd_revoke' defined but not used../../../compat/svr4/svr4_fcntl.c:283: warning: `fd_truncate' defined but not used ../../../compat/svr4/svr4_fcntl.c:114: warning: `bsd_to_svr4_flags' defined but not used ../../../compat/svr4/svr4_fcntl.c:135: warning: `bsd_to_svr4_flock' defined but not used ../../../compat/svr4/svr4_fcntl.c:163: warning: `svr4_to_bsd_flock' defined but not used ../../../compat/svr4/svr4_fcntl.c:190: warning: `bsd_to_svr4_flock64' defined but not used ../../../compat/svr4/svr4_fcntl.c:218: warning: `svr4_to_bsd_flock64' defined but not used *** Error code 1 (continuing) cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I/usr/include -DGPROF -DGPROF4 -DGUPROF -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -malign-functions=4 -fno-builtin -mpreferred-stack-boundary=2 -pg -mprofiler-epilogue ../../../compat/svr4/svr4_misc.c ../../../compat/svr4/svr4_misc.c:625: warning: type defaults to `int' in declaration of `vref' ../../../compat/svr4/svr4_misc.c:625: warning: parameter names (without types) in function declaration ../../../compat/svr4/svr4_misc.c:625: conflicting types for `vref' ../../../sys/vnode.h:675: previous declaration of `vref' ../../../compat/svr4/svr4_misc.c:625: warning: redundant redeclaration of `vref' in same scope ../../../sys/vnode.h:675: warning: previous declaration of `vref' ../../../compat/svr4/svr4_misc.c:625: warning: data definition has no type or storage class ../../../compat/svr4/svr4_misc.c:626: syntax error before `(' ../../../compat/svr4/svr4_misc.c:627: warning: type defaults to `int' in declaration of `vpold' ../../../compat/svr4/svr4_misc.c:627: `fdp' undeclared here (not in a function) ../../../compat/svr4/svr4_misc.c:627: warning: data definition has no type or storage class ../../../compat/svr4/svr4_misc.c:628: syntax error before `->' ../../../compat/svr4/svr4_misc.c:628: warning: type defaults to `int' in declaration of `fd_rdir' ../../../compat/svr4/svr4_misc.c:628: `vp' undeclared here (not in a function) ../../../compat/svr4/svr4_misc.c:628: warning: data definition has no type or storage class ../../../compat/svr4/svr4_misc.c:629: syntax error before `(' ../../../compat/svr4/svr4_misc.c:99: warning: `svr4_mknod' declared `static' but never defined ../../../compat/svr4/svr4_misc.c:101: warning: `timeval_to_clock_t' declared `static' but never defined ../../../compat/svr4/svr4_misc.c:102: warning: `svr4_setinfo' declared `static' but never defined ../../../compat/svr4/svr4_misc.c:106: warning: `svr4_hrtcntl' declared `static' but never defined ../../../compat/svr4/svr4_misc.c:108: warning: `bsd_statfs_to_svr4_statvfs' declared `static' but never defined ../../../compat/svr4/svr4_misc.c:110: warning: `bsd_statfs_to_svr4_statvfs64' declared `static' but never defined ../../../compat/svr4/svr4_misc.c:111: warning: `svr4_pfind' declared `static' but never defined *** Error code 1 (continuing) cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I/usr/include -DGPROF -DGPROF4 -DGUPROF -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -malign-functions=4 -fno-builtin -mpreferred-stack-boundary=2 -pg -mprofiler-epilogue ../../../compat/svr4/svr4_stream.c ../../../compat/svr4/svr4_stream.c: In function `svr4_sendit': ../../../compat/svr4/svr4_stream.c:242: `fp' undeclared (first use in this function) ../../../compat/svr4/svr4_stream.c:242: (Each undeclared identifier is reported only once ../../../compat/svr4/svr4_stream.c:242: for each function it appears in.) ../../../compat/svr4/svr4_stream.c: In function `svr4_recvit': ../../../compat/svr4/svr4_stream.c:367: `fp' undeclared (first use in this function) ../../../compat/svr4/svr4_stream.c: At top level: ../../../compat/svr4/svr4_stream.c:1920: redefinition of `svr4_sys_getmsg' ../../../compat/svr4/svr4_stream.c:1901: `svr4_sys_getmsg' previously defined here ../../../compat/svr4/svr4_stream.c: In function `svr4_sys_getmsg': ../../../compat/svr4/svr4_stream.c:1922: declaration for parameter `fp' but no such parameter ../../../compat/svr4/svr4_stream.c:1923: number of arguments doesn't match prototype ../../../compat/svr4/svr4_stream.c:1901: prototype declaration ../../../compat/svr4/svr4_stream.c: At top level: ../../../compat/svr4/svr4_stream.c:83: warning: `svr4_do_getmsg' used but never defined {standard input}: Assembler messages: {standard input}:4076: Error: Symbol svr4_sys_getmsg already defined. *** Error code 1 (continuing) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 16:21: 2 2002 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id 930CF37B405 for ; Tue, 15 Jan 2002 16:20:55 -0800 (PST) Received: (from david@localhost) by bunrab.catwhisker.org (8.11.6/8.11.6) id g0G0KtN08308 for current@freebsd.org; Tue, 15 Jan 2002 16:20:55 -0800 (PST) (envelope-from david) Date: Tue, 15 Jan 2002 16:20:55 -0800 (PST) From: David Wolfskill Message-Id: <200201160020.g0G0KtN08308@bunrab.catwhisker.org> To: current@freebsd.org Subject: -CURRENT as of 14 Jan seems slow 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 been tracking -CURRENT daily, both on a dual-833 MhZ "build machine" and on my laptop. I still do the bulk of my "real work" while running -STABLE, so the main workout I give -CURRENT is in building the following day's -CURRENT. I mention this in order to provide a bit of perspective in what follows. After ensuring that the update to my local CVS repository is complete, I do a "cvs update" against the sources for the OS, checking for anything weird (especially conflicts with local patches, which I resolve), then, as root, under script (well, and screen, too), I issue a crude little csh alias. On the build box, it looks like (with escapes to avoid the wrapping): whoami && mount && cd /usr/src && uname -a && \ date && make -j8 buildworld && \ date && make kernel KERNCONF=FREEBEAST && \ date && make installworld && \ date && mergemaster -u 0022 -i && \ date && df -k (On the laptop, the kernel name changes, and I use -j4 for the "make buildworld"; it is otherwise identical.) For grins, I am in the habit of keeping as many as 2 of the resulting "script" output files. And this works out nicely for quantifying the observation that yesterday's -CURRENT was considerably slower than usual: freebeast(4.5-RC)[2] grep '^... Jan 1[45]' current{,.?} current:Tue Jan 15 05:42:01 PST 2002 current:Tue Jan 15 11:02:31 PST 2002 current:Tue Jan 15 12:06:17 PST 2002 current:Tue Jan 15 12:29:18 PST 2002 current:Tue Jan 15 12:51:16 PST 2002 current.0:Mon Jan 14 05:23:25 PST 2002 current.0:Mon Jan 14 07:07:11 PST 2002 current.0:Mon Jan 14 07:27:03 PST 2002 current.0:Mon Jan 14 08:34:55 PST 2002 current.0:Mon Jan 14 08:43:45 PST 2002 current.0:Mon Jan 14 08:44:40 PST 2002 (That was the "build machine"; here's the laptop) g1-7(4.5-RC)[1] grep '^... Jan 1[45]' current{,.?} current:Tue Jan 15 06:36:02 PST 2002 current:Tue Jan 15 11:52:14 PST 2002 current:Tue Jan 15 12:39:47 PST 2002 current:Tue Jan 15 12:58:32 PST 2002 current:Tue Jan 15 13:00:15 PST 2002 current.0:Mon Jan 14 06:42:15 PST 2002 current.0:Mon Jan 14 08:37:31 PST 2002 current.0:Mon Jan 14 08:58:35 PST 2002 current.0:Mon Jan 14 09:09:22 PST 2002 current.0:Mon Jan 14 09:10:10 PST 2002 So, on the build machine, the "make -j8 buildworld" took 1:43:46 on Monday, but today, it took 5:20:30. On the laptop, the times were 1:55:16 and 5:16:12, respectively. Even I noticed *those* differences! (And part of the "make buildworld" on the laptop was on battery power, while I was driving in to work.... It's actually even worse than that, because of what I needed to do to the laptop's AC adapter after I got in to work, but that's rather beside the point for this note.) Now, I'm not doing anything to try to cut corners -- I don't mount any file systems noatime; I'm not using -DNOCLEAN; none of that stuff. And I certainly didn't change /etc/make.conf between the runs. And neither machine was doing anything else at the time: I build -STABLE before building -CURRENT, so by the time the build machine was building -CURRENT, it wasn't doing anything else. I've made a list of the files that got updated in Monday's cvs update, but this message is rather long enough without adding 88 more lines. I can trim off obviously unrelated files, I suppose -- then again, it could well be that changes that went in this morning have already addressed the issue. In any case, here's a summary of recent CVSup activity: freebeast(4.5-RC)[4] tail /var/log/cvsup-history.log CVSup begin from cvsup14.freebsd.org at Fri Jan 11 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Fri Jan 11 03:53:28 PST 2002 CVSup begin from cvsup14.freebsd.org at Sat Jan 12 03:47:05 PST 2002 CVSup ended from cvsup14.freebsd.org at Sat Jan 12 03:54:10 PST 2002 CVSup begin from cvsup14.freebsd.org at Sun Jan 13 03:47:03 PST 2002 CVSup ended from cvsup14.freebsd.org at Sun Jan 13 03:54:02 PST 2002 CVSup begin from cvsup14.freebsd.org at Mon Jan 14 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Mon Jan 14 03:53:27 PST 2002 CVSup begin from cvsup14.freebsd.org at Tue Jan 15 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Tue Jan 15 03:54:00 PST 2002 (After updating the CVS repository on the build machine, I use that as a source and update a CVS repository on the laptop, so save for various kernel options, the base OS should be pretty close between the two.) So... is this worth pursuing a bit more? Thanks, david (http://www.catwhisker.org/~david/resume.{ps,pdf,html,txt}) -- David H. Wolfskill david@catwhisker.org I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 16:44: 5 2002 Delivered-To: freebsd-current@freebsd.org Received: from router.hackerheaven.org (qn-213-73-194-22.quicknet.nl [213.73.194.22]) by hub.freebsd.org (Postfix) with ESMTP id 37E0037B419; Tue, 15 Jan 2002 16:43:57 -0800 (PST) Received: by router.hackerheaven.org (Postfix, from userid 1000) id 69FAF1C14; Wed, 16 Jan 2002 01:43:23 +0100 (CET) Date: Wed, 16 Jan 2002 01:43:22 +0100 From: Emiel Kollof To: John Baldwin Cc: freebsd-current@freebsd.org Subject: Re: Netatalk broken in current? Lock order reversal? Message-ID: <20020116004322.GA413@laptop.hackerheaven.org> References: <20020115235323.GA37379@laptop.hackerheaven.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i X-Mailer: Mutt 1.3.23i (2001-10-09) X-Editor: Vim http://www.vim.org/ X-Info: http://www.hackerheaven.org/ X-Info2: http://www.cmdline.org/ X-Info3: http://www.coolvibe.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 * John Baldwin (jhb@FreeBSD.org) wrote: > > > The panics moan about a kernel trap and some mutex stuff involving > > Giant. It only happens when I start Samba. > > Having the actual panic messages would be very helpful here. Hmm, I will proceed to crash my machine again and have a go in hand copying them... I'll be back in a flash :-) Cheers, Emiel -- Anyone who uses the phrase "easy as taking candy from a baby" has never tried taking candy from a baby. -- Robin Hood To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 16:47:16 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id 741AA37B400 for ; Tue, 15 Jan 2002 16:47:14 -0800 (PST) Received: (qmail 17111 invoked from network); 16 Jan 2002 00:47:11 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 16 Jan 2002 00:47:11 -0000 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: <200201160020.g0G0KtN08308@bunrab.catwhisker.org> Date: Tue, 15 Jan 2002 16:46:17 -0800 (PST) From: John Baldwin To: David Wolfskill Subject: RE: -CURRENT as of 14 Jan seems slow 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 16-Jan-02 David Wolfskill wrote: > So... is this worth pursuing a bit more? Two questions: 1) Do you have WITNESS on in your kernel config? 2) If yes, have you tried building with a kernel without witness? -- 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 Jan 15 16:50:44 2002 Delivered-To: freebsd-current@freebsd.org Received: from router.hackerheaven.org (qn-213-73-194-22.quicknet.nl [213.73.194.22]) by hub.freebsd.org (Postfix) with ESMTP id 0AFAA37B404; Tue, 15 Jan 2002 16:50:42 -0800 (PST) Received: by router.hackerheaven.org (Postfix, from userid 1000) id 69FAF1C14; Wed, 16 Jan 2002 01:43:23 +0100 (CET) Date: Wed, 16 Jan 2002 01:43:22 +0100 From: Emiel Kollof To: John Baldwin Cc: freebsd-current@freebsd.org Subject: Re: Netatalk broken in current? Lock order reversal? Message-ID: <20020116004322.GA413@laptop.hackerheaven.org> References: <20020115235323.GA37379@laptop.hackerheaven.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i X-Mailer: Mutt 1.3.23i (2001-10-09) X-Editor: Vim http://www.vim.org/ X-Info: http://www.hackerheaven.org/ X-Info2: http://www.cmdline.org/ X-Info3: http://www.coolvibe.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 * John Baldwin (jhb@FreeBSD.org) wrote: > > > The panics moan about a kernel trap and some mutex stuff involving > > Giant. It only happens when I start Samba. > > Having the actual panic messages would be very helpful here. Hmm, I will proceed to crash my machine again and have a go in hand copying them... I'll be back in a flash :-) Cheers, Emiel -- Anyone who uses the phrase "easy as taking candy from a baby" has never tried taking candy from a baby. -- Robin Hood To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 16:56: 6 2002 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id 446F337B402; Tue, 15 Jan 2002 16:56:04 -0800 (PST) Received: (from david@localhost) by bunrab.catwhisker.org (8.11.6/8.11.6) id g0G0u3A08394; Tue, 15 Jan 2002 16:56:03 -0800 (PST) (envelope-from david) Date: Tue, 15 Jan 2002 16:56:03 -0800 (PST) From: David Wolfskill Message-Id: <200201160056.g0G0u3A08394@bunrab.catwhisker.org> To: jhb@FreeBSD.org Subject: RE: -CURRENT as of 14 Jan seems slow Cc: current@FreeBSD.org 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 >Date: Tue, 15 Jan 2002 16:46:17 -0800 (PST) >From: John Baldwin >On 16-Jan-02 David Wolfskill wrote: >> So... is this worth pursuing a bit more? >Two questions: >1) Do you have WITNESS on in your kernel config? Yes, in both the build machine & the laptop -- since before I made a "local" hierarchy within my CVS repository (September 9, 2001). >2) If yes, have you tried building with a kernel without witness? No, not since I put it in to re-sync with GENERIC. I could try that, I suppose -- but as noted, I've had WITNESS in there for a while; something seems to have changed during that one 24-hr. period that affected things rather radically. And I thought it notable. :-} I gather no one else has noticed this? Cheers, david -- David H. Wolfskill david@catwhisker.org I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 17: 4:44 2002 Delivered-To: freebsd-current@freebsd.org Received: from router.hackerheaven.org (qn-213-73-194-22.quicknet.nl [213.73.194.22]) by hub.freebsd.org (Postfix) with ESMTP id BB10037B400; Tue, 15 Jan 2002 17:04:41 -0800 (PST) Received: by router.hackerheaven.org (Postfix, from userid 1000) id 8D02C1C14; Wed, 16 Jan 2002 02:04:15 +0100 (CET) Date: Wed, 16 Jan 2002 02:04:15 +0100 From: Emiel Kollof To: John Baldwin Cc: freebsd-current@freebsd.org Subject: Re: Netatalk broken in current? Lock order reversal? Message-ID: <20020116010414.GA425@laptop.hackerheaven.org> References: <20020115235323.GA37379@laptop.hackerheaven.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i X-Mailer: Mutt 1.3.23i (2001-10-09) X-Editor: Vim http://www.vim.org/ X-Info: http://www.hackerheaven.org/ X-Info2: http://www.cmdline.org/ X-Info3: http://www.coolvibe.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 * John Baldwin (jhb@FreeBSD.org) wrote: > > > lock order reversal 1st 0xc185e934 filedesc structure @ > > /usr/src/sys/kern/kern_descrip.c:925 > > 2nd 0xc0419b00 Giant @ /usr/src/sys/kern/kern_descrip.c:959 > > This one is due to not releasing the filedesc lock when grabbing Giant to free > oldofile in fdalloc(). Is that going to cause data loss? I also saw messages like these: /var: lost blocks 62 files 8 > > The panics moan about a kernel trap and some mutex stuff involving > > Giant. It only happens when I start Samba. > > Having the actual panic messages would be very helpful here. It crashed very reproducable with this panic (hand copied): exclusive (sleep mutex) Giant (0xc0462c00) locked @ /usr/src/sys/i386/i386/trap.c:1102 panic: system call pwrite returning with mutex(s) held Debugger("panic") panic: kernel trap doesn't have ucred Cheers, Emiel -- So far as I can remember, there is not one word in the Gospels in praise of intelligence. -- Bertrand Russell To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 17:11:27 2002 Delivered-To: freebsd-current@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 7714E37B400 for ; Tue, 15 Jan 2002 17:11:22 -0800 (PST) Received: by freesbee.wheel.dk (Postfix, from userid 1002) id 10B1F5DB8; Wed, 16 Jan 2002 02:11:21 +0100 (CET) Date: Wed, 16 Jan 2002 02:11:21 +0100 From: "Niels Chr. Bank-Pedersen" To: current@FreeBSD.org Subject: Re: -CURRENT as of 14 Jan seems slow Message-ID: <20020116021120.A2020@bank-pedersen.dk> Mail-Followup-To: "Niels Chr. Bank-Pedersen" , current@FreeBSD.org References: <200201160056.g0G0u3A08394@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201160056.g0G0u3A08394@bunrab.catwhisker.org>; from david@catwhisker.org on Tue, Jan 15, 2002 at 04:56:03PM -0800 X-PGP-Fingerprint: 18D0 73F3 767F 3A40 CEBA C595 4783 D7F5 5DD1 FB8C X-PGP-Public-Key: http://freesbee.wheel.dk/~ncbp/gpgkey.pub 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, Jan 15, 2002 at 04:56:03PM -0800, David Wolfskill wrote: [...] > > I gather no one else has noticed this? Not here at least (timestamps are CET): note% ls -l /var/log/build/buildworld.log* -rw-r--r-- 1 root wheel 5728428 15 Jan 22:58 /var/log/build/buildworld.log -rw-r--r-- 1 root wheel 5727901 12 Jan 15:14 /var/log/build/buildworld.log.0 -rw-r--r-- 1 root wheel 5728013 11 Jan 04:35 /var/log/build/buildworld.log.1 -rw-r--r-- 1 root wheel 5701184 5 Jan 18:34 /var/log/build/buildworld.log.2 -rw-r--r-- 1 root wheel 5701184 5 Jan 18:34 /var/log/build/buildworld.log.3 note% egrep ' real.* user.* sys' /var/log/build/buildworld.log* /var/log/build/buildworld.log: 3860,96 real 2480,12 user 513,99 sys /var/log/build/buildworld.log.0: 4310,09 real 2948,09 user 560,00 sys /var/log/build/buildworld.log.1: 8044,91 real 2941,55 user 555,54 sys /var/log/build/buildworld.log.2: 4099,63 real 2935,31 user 562,73 sys /var/log/build/buildworld.log.3: 4099,63 real 2935,31 user 562,73 sys > david Cheers, Niels Chr. -- Niels Christian Bank-Pedersen, NCB1-RIPE. "Hey, are any of you guys out there actually *using* RFC 2549?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 17:12: 5 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 7837137B417 for ; Tue, 15 Jan 2002 17:11:58 -0800 (PST) Received: (qmail 1951 invoked from network); 16 Jan 2002 01:11:57 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 16 Jan 2002 01:11:57 -0000 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: <20020116010414.GA425@laptop.hackerheaven.org> Date: Tue, 15 Jan 2002 17:11:14 -0800 (PST) From: John Baldwin To: Emiel Kollof Subject: Re: Netatalk broken in current? Lock order reversal? 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 16-Jan-02 Emiel Kollof wrote: > * John Baldwin (jhb@FreeBSD.org) wrote: >> >> > lock order reversal 1st 0xc185e934 filedesc structure @ >> > /usr/src/sys/kern/kern_descrip.c:925 >> > 2nd 0xc0419b00 Giant @ /usr/src/sys/kern/kern_descrip.c:959 >> >> This one is due to not releasing the filedesc lock when grabbing Giant to >> free >> oldofile in fdalloc(). > > Is that going to cause data loss? I also saw messages like these: > > /var: lost blocks 62 files 8 No, that's softupdates stuff. I think releasing filedesc is ok this case, but usually I would recode it to move malloc's and free's around to avoid having to drop and reacquire locks. >> Having the actual panic messages would be very helpful here. > > It crashed very reproducable with this panic (hand copied): > > exclusive (sleep mutex) Giant (0xc0462c00) locked @ > /usr/src/sys/i386/i386/trap.c:1102 > panic: system call pwrite returning with mutex(s) held Hmm, erm, go kick Alfred really hard. :) This function locks Giant and then doesn't ever unlock it. This looks to be breakage from his fget() changes perhaps. -- 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 Jan 15 17:12: 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 0C5EB37B400 for ; Tue, 15 Jan 2002 17:11:57 -0800 (PST) Received: (qmail 13333 invoked from network); 16 Jan 2002 01:11:56 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 16 Jan 2002 01:11:56 -0000 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: <200201160056.g0G0u3A08394@bunrab.catwhisker.org> Date: Tue, 15 Jan 2002 17:11:13 -0800 (PST) From: John Baldwin To: David Wolfskill Subject: RE: -CURRENT as of 14 Jan seems slow 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 16-Jan-02 David Wolfskill wrote: >>Date: Tue, 15 Jan 2002 16:46:17 -0800 (PST) >>From: John Baldwin > >>On 16-Jan-02 David Wolfskill wrote: >>> So... is this worth pursuing a bit more? > >>Two questions: > >>1) Do you have WITNESS on in your kernel config? > > Yes, in both the build machine & the laptop -- since before I made a > "local" hierarchy within my CVS repository (September 9, 2001). > >>2) If yes, have you tried building with a kernel without witness? > > No, not since I put it in to re-sync with GENERIC. I could try that, I > suppose -- but as noted, I've had WITNESS in there for a while; something > seems to have changed during that one 24-hr. period that affected things > rather radically. And I thought it notable. :-} > > I gather no one else has noticed this? Alfred added several more locks for file I/O stuff that could be the hit you are seeing. -- 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 Jan 15 17:35:17 2002 Delivered-To: freebsd-current@freebsd.org Received: from router.hackerheaven.org (qn-213-73-194-22.quicknet.nl [213.73.194.22]) by hub.freebsd.org (Postfix) with ESMTP id 0306C37B400; Tue, 15 Jan 2002 17:35:14 -0800 (PST) Received: by router.hackerheaven.org (Postfix, from userid 1000) id F03901C14; Wed, 16 Jan 2002 02:34:48 +0100 (CET) Date: Wed, 16 Jan 2002 02:34:48 +0100 From: Emiel Kollof To: John Baldwin Cc: freebsd-current@freebsd.org Subject: Re: Netatalk broken in current? Lock order reversal? Message-ID: <20020116013448.GA584@laptop.hackerheaven.org> References: <20020116010414.GA425@laptop.hackerheaven.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i X-Mailer: Mutt 1.3.23i (2001-10-09) X-Editor: Vim http://www.vim.org/ X-Info: http://www.hackerheaven.org/ X-Info2: http://www.cmdline.org/ X-Info3: http://www.coolvibe.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 * John Baldwin (jhb@FreeBSD.org) wrote: > > /var: lost blocks 62 files 8 > > No, that's softupdates stuff. I think releasing filedesc is ok this case, > but usually I would recode it to move malloc's and free's around to avoid > having to drop and reacquire locks. Ah right... Good to know... > > exclusive (sleep mutex) Giant (0xc0462c00) locked @ > > /usr/src/sys/i386/i386/trap.c:1102 > > panic: system call pwrite returning with mutex(s) held > > Hmm, erm, go kick Alfred really hard. :) This function locks Giant and then > doesn't ever unlock it. This looks to be breakage from his fget() changes > perhaps. Ah... Alfred? You will be let off easy this one time. Next time I'll send the Beastie after you. Right after you finish cramping that box of CAT5 cable over there in 30 cm long pieces, oh and you have to repeat "I will never leave my locks on Giant unfreed" too every time you finish one. Right. got that? Good. ;-) Oh, on another note, is someone working at that netatalk breakage? Who do I have to discipline for that? :-) Cheers, Emiel -- Too much of a good thing is WONDERFUL. -- Mae West To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 17:41:16 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 30AF837B400; Tue, 15 Jan 2002 17:41:12 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 16 Jan 2002 01:41:11 +0000 (GMT) To: Emiel Kollof Cc: John Baldwin , freebsd-current@FreeBSD.org Subject: Re: Netatalk broken in current? Lock order reversal? In-Reply-To: Your message of "Wed, 16 Jan 2002 02:34:48 +0100." <20020116013448.GA584@laptop.hackerheaven.org> Date: Wed, 16 Jan 2002 01:41:10 +0000 From: Ian Dowse Message-ID: <200201160141.aa95174@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 In message <20020116013448.GA584@laptop.hackerheaven.org>, Emiel Kollof writes: > >Oh, on another note, is someone working at that netatalk breakage? Who >do I have to discipline for that? :-) Could you try the following patch in src/sys/netatalk? The problem was caused by the -fno-common compiler option that was added to the kernel build flags recently. This compiles for me, but I haven't checked that it actually works. Ian Index: ddp_input.c =================================================================== RCS file: /dump/FreeBSD-CVS/src/sys/netatalk/ddp_input.c,v retrieving revision 1.12 diff -u -r1.12 ddp_input.c --- ddp_input.c 13 Feb 2000 03:31:58 -0000 1.12 +++ ddp_input.c 16 Jan 2002 01:30:50 -0000 @@ -27,8 +27,6 @@ static struct ddpstat ddpstat; static struct route forwro; -const int atintrq1_present = 1, atintrq2_present = 1; - static void ddp_input(struct mbuf *, struct ifnet *, struct elaphdr *, int); /* Index: ddp_usrreq.c =================================================================== RCS file: /dump/FreeBSD-CVS/src/sys/netatalk/ddp_usrreq.c,v retrieving revision 1.22 diff -u -r1.22 ddp_usrreq.c --- ddp_usrreq.c 17 Nov 2001 03:07:08 -0000 1.22 +++ ddp_usrreq.c 16 Jan 2002 01:32:34 -0000 @@ -14,6 +14,7 @@ #include #include #include +#include #include #include @@ -547,6 +548,8 @@ { atintrq1.ifq_maxlen = IFQ_MAXLEN; atintrq2.ifq_maxlen = IFQ_MAXLEN; + atintrq1_present = 1; + atintrq2_present = 1; mtx_init(&atintrq1.ifq_mtx, "at1_inq", MTX_DEF); mtx_init(&atintrq2.ifq_mtx, "at2_inq", MTX_DEF); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 17:48:26 2002 Delivered-To: freebsd-current@freebsd.org Received: from router.hackerheaven.org (qn-213-73-194-22.quicknet.nl [213.73.194.22]) by hub.freebsd.org (Postfix) with ESMTP id 6C92337B405; Tue, 15 Jan 2002 17:48:23 -0800 (PST) Received: by router.hackerheaven.org (Postfix, from userid 1000) id BBD3B1C14; Wed, 16 Jan 2002 02:47:57 +0100 (CET) Date: Wed, 16 Jan 2002 02:47:56 +0100 From: Emiel Kollof To: Ian Dowse Cc: John Baldwin , freebsd-current@FreeBSD.org Subject: Re: Netatalk broken in current? Lock order reversal? Message-ID: <20020116014756.GC584@laptop.hackerheaven.org> References: <20020116013448.GA584@laptop.hackerheaven.org> <200201160141.aa95174@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201160141.aa95174@salmon.maths.tcd.ie> User-Agent: Mutt/1.3.25i X-Mailer: Mutt 1.3.23i (2001-10-09) X-Editor: Vim http://www.vim.org/ X-Info: http://www.hackerheaven.org/ X-Info2: http://www.cmdline.org/ X-Info3: http://www.coolvibe.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 * Ian Dowse (iedowse@maths.tcd.ie) wrote: > >Oh, on another note, is someone working at that netatalk breakage? Who > >do I have to discipline for that? :-) > > Could you try the following patch in src/sys/netatalk? The problem > was caused by the -fno-common compiler option that was added to > the kernel build flags recently. Right... Applied it. Building as I mail this. > This compiles for me, but I haven't checked that it actually works. I will test it. (run netatalk and transfer some files to and fro) Cheers, Emiel -- "Gee, Toto, I don't think we are in Kansas anymore." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 19:22:42 2002 Delivered-To: freebsd-current@freebsd.org Received: from web11406.mail.yahoo.com (web11406.mail.yahoo.com [216.136.131.236]) by hub.freebsd.org (Postfix) with SMTP id 4083C37B417 for ; Tue, 15 Jan 2002 19:22:36 -0800 (PST) Message-ID: <20020116032236.79715.qmail@web11406.mail.yahoo.com> Received: from [202.167.61.228] by web11406.mail.yahoo.com via HTTP; Tue, 15 Jan 2002 19:22:36 PST Date: Tue, 15 Jan 2002 19:22:36 -0800 (PST) From: Shizuka Kudo Subject: Re: Melco LPC4-CLX-CB support in 5.0-Current NEWCARD To: freebsd-current@freebsd.org, freebsd-mobile@freebsd.org In-Reply-To: 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 All, Thank you for your support. The card should have been recognized in NEWCARD. It is my fault that I thought my Thinkpad was running NEWCARD but in fact was a custom kernel without rl support. In addition, I did not experience the hang that was mentioned by another YAMAMOTO san. --- Taku YAMAMOTO wrote: > At Tue, 15 Jan 2002 03:08:53 -0800 (PST), > Shizuka Kudo wrote: > > > > Dear all, > > > > Does anyone have tested whether this card works > with > > current 5.0 NEWCARD? I tried it on a Thinkpad 600X > > with current 5.0 cvsupped yestersday and received > a > > > > kernel: found-> vendor=0x10ec, dev=0x8138, > > revid=0x10 > (snip) > > It may work with device rl. > (see /sys/pci/if_rlreg.h) > -- > YAMAMOTO, Taku > Member of Advanced Computer and Communication > Studies Society > (ACCESS for short), Information Processing Center, > Saitama Univ. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of > the message __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 19:24:58 2002 Delivered-To: freebsd-current@freebsd.org Received: from router.hackerheaven.org (qn-213-73-194-22.quicknet.nl [213.73.194.22]) by hub.freebsd.org (Postfix) with ESMTP id 3C8D237B402; Tue, 15 Jan 2002 19:24:55 -0800 (PST) Received: by router.hackerheaven.org (Postfix, from userid 1000) id D5F871C05; Wed, 16 Jan 2002 04:24:28 +0100 (CET) Date: Wed, 16 Jan 2002 04:24:28 +0100 From: Emiel Kollof To: Ian Dowse Cc: John Baldwin , freebsd-current@FreeBSD.org Subject: Re: Netatalk broken in current? Lock order reversal? Message-ID: <20020116032428.GA810@laptop.hackerheaven.org> References: <20020116013448.GA584@laptop.hackerheaven.org> <200201160141.aa95174@salmon.maths.tcd.ie> <20020116014756.GC584@laptop.hackerheaven.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020116014756.GC584@laptop.hackerheaven.org> User-Agent: Mutt/1.3.25i X-Mailer: Mutt 1.3.23i (2001-10-09) X-Editor: Vim http://www.vim.org/ X-Info: http://www.hackerheaven.org/ X-Info2: http://www.cmdline.org/ X-Info3: http://www.coolvibe.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 * Emiel Kollof (coolvibe@hackerheaven.org) wrote: > > This compiles for me, but I haven't checked that it actually works. > > I will test it. (run netatalk and transfer some files to and fro) It compiled, and after making a connection with Appletalk with one of my macs, file transfers went off without a hitch. I copied some big files (several MB's) from my CURRENT machine and my mac, and after checking with cmp(1) the files seemed to have no corruption. So basically, it does work. Hope that helped a bit... Now let's hope Alfred will fix my kernel trap when I run Samba... I tend to need it around here :-( Cheers, Emiel -- SCORPIO (Oct 23 - Nov 21) You are shrewd in business and cannot be trusted. You will achieve the pinnacle of success because of your total lack of ethics. Most Scorpio people are murdered. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 20:16:57 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx.netcontents.net (mx.netcontents.net [63.86.97.101]) by hub.freebsd.org (Postfix) with SMTP id B496A37B402 for ; Tue, 15 Jan 2002 20:16:55 -0800 (PST) Received: (qmail 13609 invoked by uid 99); 15 Jan 2002 23:13:47 -0500 Date: 16 Jan 2002 04:13:47 -0000 Message-ID: <20020116041347.13608.qmail@mx.netcontents.net> To: current@freebsd.org From: jade@liveteens.com () Subject: LIVE TEENS GETTING WILD, free signup! 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 Below is the result of your feedback form. It was submitted by (jade@liveteens.com) on Tuesday, January 15, 19102 at 23:13:47 --------------------------------------------------------------------------- : If you want live, wild teens on their webcams you should check this out , signup is free just use your credit card to verify your age and you're in. And best of all they're real people, you can enter a 1 on 1 session and might meet the someone to fulfill all your fantasies. If it's celebs you're looking for, look no farther than here , We even have the rare Brittany/Justin video set, No credit card required!!! You received this e-mail because you were added to our monthly mailing list, if you want to be removed simply e-mail mail@angelteen.com with the subject "REMOVE". --------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 22: 3:45 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 2877437B404; Tue, 15 Jan 2002 22:03:42 -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 RAA19908; Wed, 16 Jan 2002 17:03:20 +1100 Date: Wed, 16 Jan 2002 17:04:31 +1100 (EST) From: Bruce Evans X-X-Sender: To: David Wolfskill Cc: , Subject: RE: -CURRENT as of 14 Jan seems slow In-Reply-To: <200201160056.g0G0u3A08394@bunrab.catwhisker.org> Message-ID: <20020116163247.L857-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 Tue, 15 Jan 2002, David Wolfskill wrote: > >Date: Tue, 15 Jan 2002 16:46:17 -0800 (PST) > >From: John Baldwin > >Two questions: > > >1) Do you have WITNESS on in your kernel config? > > Yes, in both the build machine & the laptop -- since before I made a > "local" hierarchy within my CVS repository (September 9, 2001). > > >2) If yes, have you tried building with a kernel without witness? > > No, not since I put it in to re-sync with GENERIC. I could try that, I > suppose -- but as noted, I've had WITNESS in there for a while; something > seems to have changed during that one 24-hr. period that affected things > rather radically. And I thought it notable. :-} > > I gather no one else has noticed this? File locking seems to cause only the usual few percent of slowdown for each round of major locking changes. I haven't completed benchmarking the file locking pessimizations. I don't use WITNESS or INVARIANTS for benchmarking of course. Maybe the file locking changes cause much larger pessimizations when WITNESS is turned on than most locking changes. I can see how they might: WITNESS seemed to slow down creation and destruction of mutexes more than most mutex operations last time I checked, and there is a descriptor for each file and each file descriptor. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 15 23:38:53 2002 Delivered-To: freebsd-current@freebsd.org Received: from lecs.cs.ucla.edu (Lecs.CS.UCLA.EDU [131.179.144.100]) by hub.freebsd.org (Postfix) with ESMTP id 1F73937B417 for ; Tue, 15 Jan 2002 23:38:52 -0800 (PST) Received: (from asrivaths@localhost) by lecs.cs.ucla.edu (8.9.3/8.9.3) id XAA23971 for freebsd-current@freebsd.org; Tue, 15 Jan 2002 23:38:51 -0800 Date: Tue, 15 Jan 2002 23:38:51 -0800 From: Arvind Srivaths Message-Id: <200201160738.XAA23971@lecs.cs.ucla.edu> To: freebsd-current@freebsd.org Subject: size of /usr/src 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 created a separate partition for /usr/src (around 420MB) and cvsup ran out of space. Can someone give me a rough idea of how big it is? Also, I should be able to use growfs (after booting off of a floppy) to increase the size of the partition (if the slice has space), right? How about moving partitions - is there an easier way than creating a partition at the end of the slice and copying partitions down? Thanks, Arvind To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 1: 2:54 2002 Delivered-To: freebsd-current@freebsd.org Received: from outel.org (outel.org [207.173.133.28]) by hub.freebsd.org (Postfix) with ESMTP id 829D837B400 for ; Wed, 16 Jan 2002 01:02:50 -0800 (PST) Received: from [192.168.1.20] (athlon [192.168.1.20]) by outel.org (8.11.6/8.11.6) with ESMTP id g0G92Lx15155; Wed, 16 Jan 2002 01:02:21 -0800 (PST) (envelope-from qumqats@outel.org) Date: Wed, 16 Jan 2002 01:02:31 -0800 From: "Joel M. Baldwin" To: Arvind Srivaths , freebsd-current@FreeBSD.ORG Subject: Re: size of /usr/src Message-ID: <1675513040.1011142951@[192.168.1.20]> In-Reply-To: <200201160738.XAA23971@lecs.cs.ucla.edu> References: <200201160738.XAA23971@lecs.cs.ucla.edu> X-Mailer: Mulberry/2.1.2 (Win32 Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 current /usr/src is 524M. That include 83M of kernel object files in /usr/src/sys/i386/compile from a couple of different kernel builds. /usr/obj which holds the object files from a buildworld is 460M. If you're going to do a full cvs repository then /home/ncvs on my system is 1391M. --On Tuesday, January 15, 2002 11:38 PM -0800 Arvind Srivaths wrote: > > Hi, > > I created a separate partition for /usr/src (around 420MB) and cvsup > ran out of space. Can someone give me a rough idea of how big it is? > Also, I should be able to use growfs (after booting off of a floppy) > to increase the size of the partition (if the slice has space), > right? How about moving partitions - is there an easier way than > creating a partition at the end of the slice and copying partitions > down? > > Thanks, > > Arvind > > 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 Jan 16 1:21:11 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id D0E4937B421 for ; Wed, 16 Jan 2002 01:20:58 -0800 (PST) Received: (from uucp@localhost) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) id g0G9KBm19600; Wed, 16 Jan 2002 10:20:12 +0100 (MET) >Received: (from andreas@localhost) by klemm.gtn.com (8.11.6/8.11.3) id g0G8mRS16503; Wed, 16 Jan 2002 09:48:27 +0100 (CET) (envelope-from andreas) Date: Wed, 16 Jan 2002 09:48:27 +0100 From: Andreas Klemm To: John Hay Cc: gaspeak@va.prestige.net, Beech Rintoul , freebsd-current@FreeBSD.ORG, apsfilter-help@apsfilter.org Subject: Re: ghostscript-gnu build broken Message-ID: <20020116084827.GA16483@titan.klemm.gtn.com> References: <20020113222504.GA85380@titan.klemm.gtn.com> <200201140617.g0E6HdY89334@zibbi.icomtek.csir.co.za> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <200201140617.g0E6HdY89334@zibbi.icomtek.csir.co.za> User-Agent: Mutt/1.3.23.1i X-Operating-System: FreeBSD 4.5-RC X-Disclaimer: A free society is one where it is safe to be unpopular Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" 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 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable HP released a new version. 1.0.1. They have fixed a bug in the sources. Could someone try the new version with optimization -O / -O2 turned on ? I only can do it in 10 hours from now. Andreas /// --=20 Andreas Klemm Apsfilter Homepage http://www.apsfilter.org Support over mailing-lists (only!) http://www.apsfilter.org/support Mailing-list archive http://www.apsfilter.org/Lists-Arc= hives Songs from our band >> 64Bits << http://www.64bits.de Inofficial band pages with add-on stuff http://www.apsfilter.org/64bits.ht= ml --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8RT5bd3o+lGxvbLoRAq+vAJoChasEctyTGKYHDkrRcaa8a1frRACfSJ+f vAmQy0BuctsLRTubPTic9Sg= =30TV -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 1:57:36 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 1AD7037B41D for ; Wed, 16 Jan 2002 01:57:33 -0800 (PST) Received: from dialup-209.245.128.158.dial1.sanjose1.level3.net ([209.245.128.158] helo=blossom.cjclark.org) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Qmp1-0000eT-00; Wed, 16 Jan 2002 01:57:32 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id g0G9vTA34611; Wed, 16 Jan 2002 01:57:29 -0800 (PST) (envelope-from cjc) Date: Wed, 16 Jan 2002 01:57:29 -0800 From: "Crist J . Clark" To: "Joel M. Baldwin" Cc: Arvind Srivaths , freebsd-current@FreeBSD.ORG Subject: Re: size of /usr/src Message-ID: <20020116015729.O31328@blossom.cjclark.org> References: <200201160738.XAA23971@lecs.cs.ucla.edu> <1675513040.1011142951@[192.168.1.20]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1675513040.1011142951@[192.168.1.20]>; from qumqats@outel.org on Wed, Jan 16, 2002 at 01:02:31AM -0800 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 Wed, Jan 16, 2002 at 01:02:31AM -0800, Joel M. Baldwin wrote: > > My current /usr/src is 524M. That include 83M of kernel > object files in /usr/src/sys/i386/compile from a couple > of different kernel builds. /usr/obj which holds the > object files from a buildworld is 460M. If you're going > to do a full cvs repository then /home/ncvs on my system > is 1391M. Hmmm... $ du -kd 0 /export/stable/src 315854 /export/stable/src $ du -kd 0 /export/stable/src 383116 /export/stable/src $ du -kd 0 /export/ncvs 1248390 /export/ncvs -- "It's always funny until someone gets hurt. Then it's hilarious." 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 Wed Jan 16 5: 7:18 2002 Delivered-To: freebsd-current@freebsd.org Received: from reliant.nielsenmedia.com (reliant.nielsenmedia.com [63.114.249.15]) by hub.freebsd.org (Postfix) with ESMTP id 123DB37B404 for ; Wed, 16 Jan 2002 05:07:14 -0800 (PST) Received: from nmrusdunsxg1.nielsenmedia.com (nmrusdunsxg1.nielsenmedia.com [10.9.11.119]) by reliant.nielsenmedia.com (8.11.5/8.11.5) with ESMTP id g0GD78R10397 for ; Wed, 16 Jan 2002 08:07:08 -0500 (EST) Received: from nmrusdunsxg2.nielsenmedia.com (unverified) by nmrusdunsxg1.nielsenmedia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 16 Jan 2002 08:06:56 -0500 Received: by nmrusdunsxg2.nielsenmedia.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 08:07:05 -0500 Message-ID: From: "Sarnovsky, Jesse" To: "'current@FreeBSD.org'" Subject: Date: Wed, 16 Jan 2002 08:07:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 help To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 6: 9:20 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.acns.ab.ca (h24-64-56-135.cg.shawcable.net [24.64.56.135]) by hub.freebsd.org (Postfix) with ESMTP id EA7A737B400 for ; Wed, 16 Jan 2002 06:09:14 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0GE9EI80391 for ; Wed, 16 Jan 2002 07:09:14 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0GE99d00858 for current@freebsd.org; Wed, 16 Jan 2002 07:09:09 -0700 (MST) (envelope-from davidc) Date: Wed, 16 Jan 2002 07:09:08 -0700 From: Chad David To: current@freebsd.org Subject: socket shutdown delay? Message-ID: <20020116070908.A803@colnta.acns.ab.ca> Mail-Followup-To: current@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 Has anyone noticed (or fixed) a bug in -current where socket connections on the local machine do not shutdown properly? During stress testing I'm seeing thousands (2316 right now) of these: tcp4 0 0 192.168.1.2.8080 192.168.1.2.2215 FIN_WAIT_2 tcp4 0 0 192.168.1.2.2215 192.168.1.2.8080 LAST_ACK tcp4 0 0 192.168.1.2.8080 192.168.1.2.2214 FIN_WAIT_2 tcp4 0 0 192.168.1.2.2214 192.168.1.2.8080 LAST_ACK tcp4 0 0 192.168.1.2.8080 192.168.1.2.2213 FIN_WAIT_2 tcp4 0 0 192.168.1.2.2213 192.168.1.2.8080 LAST_ACK tcp4 0 0 192.168.1.2.8080 192.168.1.2.2212 FIN_WAIT_2 tcp4 0 0 192.168.1.2.2212 192.168.1.2.8080 LAST_ACK tcp4 0 0 192.168.1.2.8080 192.168.1.2.2211 FIN_WAIT_2 tcp4 0 0 192.168.1.2.2211 192.168.1.2.8080 LAST_ACK tcp4 0 0 192.168.1.2.8080 192.168.1.2.2210 FIN_WAIT_2 tcp4 0 0 192.168.1.2.2210 192.168.1.2.8080 LAST_ACK Both the client and the server are dead, but the connections stay in this state. I tested with the server on -current and the client on another box, and all of the server sockets end up in TIME_WAIT. Is there something delaying the last ack on local connections? Thanks. FreeBSD colnta 5.0-CURRENT FreeBSD 5.0-CURRENT #17: Sun Jan 13 03:51:32 MST 2002 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 #17: Sun Jan 13 03:51:32 MST 2002 davidc@colnta:/mnt1/obj/usr/src/sys/COLNTA Preloaded elf kernel "/boot/kernel/kernel" at 0xc0521000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc05210a8. Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (1004.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x383fbff real memory = 1073725440 (1048560K bytes) avail memory = 1039327232 (1014968K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 3, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec00000 Pentium Pro MTRR support enabled Using $PIR table, 7 entries at 0xc00f12d0 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_button0: on acpi0 acpi_pcib0: port 0xcf8-0xcff on acpi0 IOAPIC #0 intpin 18 -> irq 2 IOAPIC #0 intpin 16 -> irq 5 IOAPIC #0 intpin 19 -> irq 10 pci0: on acpi_pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0xb800-0xb80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xb400-0xb41f irq 2 at device 4.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xb000-0xb01f irq 2 at device 4.3 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at device 12.0 (no driver attached) dc0: port 0xa800-0xa8ff mem 0xeb800000-0xeb8003ff irq 10 at device 13.0 on pci0 dc0: Ethernet address: 00:04:5a:61:f5:6a miibus0: on dc0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0 port 0x778-0x77b,0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on ppbus0: ppbus0: PRINTER PJL,MLC,PCL,PCLXL,POSTSCRIPT plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it orm0:
 
------=_NextPart_000_0005_01C19EB4.860BB2A0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 10:33:49 2002 Delivered-To: freebsd-current@freebsd.org Received: from marlborough.cnchost.com (marlborough.concentric.net [207.155.248.14]) by hub.freebsd.org (Postfix) with ESMTP id A961037B420 for ; Wed, 16 Jan 2002 10:33:34 -0800 (PST) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by marlborough.cnchost.com id NAA19174; Wed, 16 Jan 2002 13:33:28 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <200201161833.NAA19174@marlborough.cnchost.com> To: Arvind Srivaths Cc: freebsd-current@freebsd.org Subject: Re: size of /usr/src In-reply-to: Your message of "Tue, 15 Jan 2002 23:38:51 PST." <200201160738.XAA23971@lecs.cs.ucla.edu> Date: Wed, 16 Jan 2002 10:33:27 -0800 From: Bakul Shah 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 Your questions belong to freebsd-questions! > I created a separate partition for /usr/src (around 420MB) and cvsup ran > out of space. Can someone give me a rough idea of how big it is? Also, > I should be able to use growfs (after booting off of a floppy) to increase > the size of the partition (if the slice has space), right? How about moving > partitions - is there an easier way than creating a partition at the end > of the slice and copying partitions down? Are you creating a 5.0-CURRENT or a 4-STABLE /usr/src? On a -STABLE: $ du -s /usr/src 355799 /usr/src On a -CURRENT: $ du -s /usr/src 389637 /usr/src FFS likes to have about 10% free space + add a few more (may be 4%) for the inodes space. So you need a partition of at least 450MB. You need to leave another 20% ~ 50% free for future source fat (second law of computer thermodynamics). A partition of 1GB wouldn't hurt! You need another 40MB or more for each kernel on whichever partition you build them. More if you turn debugging on. Instead of building kernels in /usr/src/sys/compile, you can do cd /usr/src make buildkernel KERNCONF= to build them in /usr/obj/usr/src/sys/. You don't need to boot from a floppy -- just unmount the partition. In case of the root partition you can growfs if you boot in single user. I believe initially the root partition is mounted read-only so growfs change are safe. I would reboot immediately afterwards though. For moving partitions I would use dump/restore to/from a networked machine rather than copying them around. For that you may need to boot from a floppy. Or you can just install released kernels and do something worthwhile (like build some furniture) in the time you will save :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 12:20:19 2002 Delivered-To: freebsd-current@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 1214A37B419 for ; Wed, 16 Jan 2002 12:20:05 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id VAA08710 for freebsd-current@freebsd.org; Wed, 16 Jan 2002 21:20:04 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id g0GKISJ05153; Wed, 16 Jan 2002 21:18:28 +0100 (MET) (envelope-from j) Date: Wed, 16 Jan 2002 21:18:28 +0100 (MET) Message-Id: <200201162018.g0GKISJ05153@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 1.0b.1 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: <200201160738.XAA23971@lecs.cs.ucla.edu> <200201161833.NAA19174@marlborough.cnchost.com> From: j@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: size of /usr/src X-Original-Newsgroups: local.freebsd.current To: freebsd-current@freebsd.org 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 Bakul Shah wrote: > On a -CURRENT: > $ du -s /usr/src > 389637 /usr/src > > FFS likes to have about 10% free space + add a few more (may > be 4%) for the inodes space. So you need a partition of at > least 450MB. j@uriah 57% df -k /usr/src Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/vinum/src 595455 434778 113041 79% /usr/src That is -current as of around christmas. There's a stale /sys/i386/compile directory in it, but that doesn't contribute much to the above since there are no .o files in it. The file system is a 1 KB fsize/8 KB bsize one; if you use larger block sizes, waste of space might be more. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 12:39:30 2002 Delivered-To: freebsd-current@freebsd.org Received: from canonware.com (dsl081-058-209.sfo1.dsl.speakeasy.net [64.81.58.209]) by hub.freebsd.org (Postfix) with ESMTP id A5AAD37B404; Wed, 16 Jan 2002 12:39:26 -0800 (PST) Received: by canonware.com (Postfix, from userid 1001) id C1B4ABA; Wed, 16 Jan 2002 12:44:09 -0800 (PST) Date: Wed, 16 Jan 2002 12:44:09 -0800 From: Jason Evans To: Bruce Evans Cc: David Wolfskill , jhb@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: -CURRENT as of 14 Jan seems slow Message-ID: <20020116124409.K451@canonware.com> References: <200201160056.g0G0u3A08394@bunrab.catwhisker.org> <20020116163247.L857-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020116163247.L857-100000@gamplex.bde.org>; from bde@zeta.org.au on Wed, Jan 16, 2002 at 05:04:31PM +1100 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, Jan 16, 2002 at 05:04:31PM +1100, Bruce Evans wrote: > On Tue, 15 Jan 2002, David Wolfskill wrote: > > > >Date: Tue, 15 Jan 2002 16:46:17 -0800 (PST) > > >From: John Baldwin > > >Two questions: > > > > >1) Do you have WITNESS on in your kernel config? > > > > Yes, in both the build machine & the laptop -- since before I made a > > "local" hierarchy within my CVS repository (September 9, 2001). > > > > >2) If yes, have you tried building with a kernel without witness? > > > > No, not since I put it in to re-sync with GENERIC. I could try that, I > > suppose -- but as noted, I've had WITNESS in there for a while; something > > seems to have changed during that one 24-hr. period that affected things > > rather radically. And I thought it notable. :-} > > > > I gather no one else has noticed this? > > File locking seems to cause only the usual few percent of slowdown for > each round of major locking changes. I haven't completed benchmarking > the file locking pessimizations. I don't use WITNESS or INVARIANTS > for benchmarking of course. Maybe the file locking changes cause much > larger pessimizations when WITNESS is turned on than most locking > changes. I can see how they might: WITNESS seemed to slow down creation > and destruction of mutexes more than most mutex operations last time I > checked, and there is a descriptor for each file and each file descriptor. Note that additional locking with witness turned on can drastically affect performance. Chances are that Alfred's changes in combination with witness are what caused the slowdown. During certain stages of the lockmgr conversion to mutexes, I saw similar performance degradations (a factor of ~5-10, IIRC). Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 13:28:52 2002 Delivered-To: freebsd-current@freebsd.org Received: from router.hackerheaven.org (qn-213-73-194-22.quicknet.nl [213.73.194.22]) by hub.freebsd.org (Postfix) with ESMTP id 2870437B404 for ; Wed, 16 Jan 2002 13:28:50 -0800 (PST) Received: by router.hackerheaven.org (Postfix, from userid 1000) id C026B1C05; Wed, 16 Jan 2002 22:28:13 +0100 (CET) Date: Wed, 16 Jan 2002 22:28:13 +0100 From: Emiel Kollof To: freebsd-current@freebsd.org Subject: Kernel panic... (was Re: Netatalk broken in current? Lock order reversal?) Message-ID: <20020116212813.GD432@laptop.hackerheaven.org> References: <20020116010414.GA425@laptop.hackerheaven.org> <20020116013448.GA584@laptop.hackerheaven.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020116013448.GA584@laptop.hackerheaven.org> User-Agent: Mutt/1.3.25i X-Mailer: Mutt 1.3.23i (2001-10-09) X-Editor: Vim http://www.vim.org/ X-Info: http://www.hackerheaven.org/ X-Info2: http://www.cmdline.org/ X-Info3: http://www.coolvibe.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 * Emiel Kollof (coolvibe@hackerheaven.org) wrote: > > > exclusive (sleep mutex) Giant (0xc0462c00) locked @ > > > /usr/src/sys/i386/i386/trap.c:1102 > > > panic: system call pwrite returning with mutex(s) held > > > > Hmm, erm, go kick Alfred really hard. :) This function locks Giant and then > > doesn't ever unlock it. This looks to be breakage from his fget() changes > > perhaps. Alfred? Are you listening? Are you tending to this already? It's not only Samba that makes my machine panic. Also icecast does (when you start to stream to it). Oh, has anyone else seen these panics as well? Just wondering... Cheers, Emiel -- Never let your schooling interfere with your education. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 13:30: 7 2002 Delivered-To: freebsd-current@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id B25FA37B421 for ; Wed, 16 Jan 2002 13:29:58 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 829C110DE00; Wed, 16 Jan 2002 13:29:58 -0800 (PST) Date: Wed, 16 Jan 2002 13:29:58 -0800 From: Alfred Perlstein To: Emiel Kollof Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic... (was Re: Netatalk broken in current? Lock order reversal?) Message-ID: <20020116132958.L26067@elvis.mu.org> References: <20020116010414.GA425@laptop.hackerheaven.org> <20020116013448.GA584@laptop.hackerheaven.org> <20020116212813.GD432@laptop.hackerheaven.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020116212813.GD432@laptop.hackerheaven.org>; from coolvibe@hackerheaven.org on Wed, Jan 16, 2002 at 10:28:13PM +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 * Emiel Kollof [020116 13:29] wrote: > * Emiel Kollof (coolvibe@hackerheaven.org) wrote: > > > > exclusive (sleep mutex) Giant (0xc0462c00) locked @ > > > > /usr/src/sys/i386/i386/trap.c:1102 > > > > panic: system call pwrite returning with mutex(s) held > > > > > > Hmm, erm, go kick Alfred really hard. :) This function locks Giant and then > > > doesn't ever unlock it. This looks to be breakage from his fget() changes > > > perhaps. > > Alfred? Are you listening? Are you tending to this already? It's not > only Samba that makes my machine panic. Also icecast does (when you > start to stream to it). > > Oh, has anyone else seen these panics as well? Just wondering... It would help if someone cc'd me on these. :P -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 13:34:40 2002 Delivered-To: freebsd-current@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 0D76F37B47A for ; Wed, 16 Jan 2002 13:34:26 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id AB87410DE05; Wed, 16 Jan 2002 13:34:26 -0800 (PST) Date: Wed, 16 Jan 2002 13:34:26 -0800 From: Alfred Perlstein To: Emiel Kollof Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic... (was Re: Netatalk broken in current? Lock order reversal?) Message-ID: <20020116133426.M26067@elvis.mu.org> References: <20020116010414.GA425@laptop.hackerheaven.org> <20020116013448.GA584@laptop.hackerheaven.org> <20020116212813.GD432@laptop.hackerheaven.org> <20020116132958.L26067@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020116132958.L26067@elvis.mu.org>; from bright@mu.org on Wed, Jan 16, 2002 at 01:29:58PM -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 * Alfred Perlstein [020116 13:30] wrote: > * Emiel Kollof [020116 13:29] wrote: > > * Emiel Kollof (coolvibe@hackerheaven.org) wrote: > > > > > exclusive (sleep mutex) Giant (0xc0462c00) locked @ > > > > > /usr/src/sys/i386/i386/trap.c:1102 > > > > > panic: system call pwrite returning with mutex(s) held > > > > > > > > Hmm, erm, go kick Alfred really hard. :) This function locks Giant and then > > > > doesn't ever unlock it. This looks to be breakage from his fget() changes > > > > perhaps. > > > > Alfred? Are you listening? Are you tending to this already? It's not > > only Samba that makes my machine panic. Also icecast does (when you > > start to stream to it). > > > > Oh, has anyone else seen these panics as well? Just wondering... > > It would help if someone cc'd me on these. :P Fix should be in now. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 13:39: 4 2002 Delivered-To: freebsd-current@freebsd.org Received: from router.hackerheaven.org (qn-213-73-194-22.quicknet.nl [213.73.194.22]) by hub.freebsd.org (Postfix) with ESMTP id 078AD37B419 for ; Wed, 16 Jan 2002 13:39:01 -0800 (PST) Received: by router.hackerheaven.org (Postfix, from userid 1000) id 8AF9F1C17; Wed, 16 Jan 2002 22:38:34 +0100 (CET) Date: Wed, 16 Jan 2002 22:38:34 +0100 From: Emiel Kollof To: Alfred Perlstein Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic... (was Re: Netatalk broken in current? Lock order reversal?) Message-ID: <20020116213834.GA440@laptop.hackerheaven.org> References: <20020116010414.GA425@laptop.hackerheaven.org> <20020116013448.GA584@laptop.hackerheaven.org> <20020116212813.GD432@laptop.hackerheaven.org> <20020116132958.L26067@elvis.mu.org> <20020116133426.M26067@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020116133426.M26067@elvis.mu.org> User-Agent: Mutt/1.3.25i X-Mailer: Mutt 1.3.23i (2001-10-09) X-Editor: Vim http://www.vim.org/ X-Info: http://www.hackerheaven.org/ X-Info2: http://www.cmdline.org/ X-Info3: http://www.coolvibe.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 * Alfred Perlstein (bright@mu.org) wrote: > > It would help if someone cc'd me on these. :P > > Fix should be in now. Great! Thanks! Remind me to buy you a beer if I ever get to meet you in real life :-) Right.. cvsup it is... Cheers, Emiel -- If you can survive death, you can probably survive anything. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 13:40:27 2002 Delivered-To: freebsd-current@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 0FDC937B41A for ; Wed, 16 Jan 2002 13:39:59 -0800 (PST) Received: from pool0454.cvx21-bradley.dialup.earthlink.net ([209.179.193.199] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Qxmm-0000vi-00; Wed, 16 Jan 2002 13:39:56 -0800 Message-ID: <3C45F32A.5B517F7E@mindspring.com> Date: Wed, 16 Jan 2002 13:39:54 -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: Chad David Cc: current@freebsd.org Subject: Re: socket shutdown delay? References: <20020116070908.A803@colnta.acns.ab.ca> 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 Chad David wrote: > Has anyone noticed (or fixed) a bug in -current where socket connections > on the local machine do not shutdown properly? During stress testing > I'm seeing thousands (2316 right now) of these: > > tcp4 0 0 192.168.1.2.8080 192.168.1.2.2215 FIN_WAIT_2 > tcp4 0 0 192.168.1.2.2215 192.168.1.2.8080 LAST_ACK > > Both the client and the server are dead, but the connections stay in this > state. > > I tested with the server on -current and the client on another box, and > all of the server sockets end up in TIME_WAIT. Is there something delaying > the last ack on local connections? A connection goes into FIN_WAIT_2 when it has received the ACK of the FIN, but not received a FIN (or sent an ACK) itself, thus permitting it to enter TIME_WAIT state for 2MSL before proceeding to the CLOSED state, as a result of a server initiated close. A connection goes into LAST_ACK when it has sent a FIN and not received the ACK of the FIN before proceeding to the CLOSED state, as a result of a client initiated close. Since it's showing IP addresses, you appear to be using real network connections, rather than loopback connections. There are basically several ways to cause this: 1) You have something on your network, like a dummynet, that is deteministically dropping the the ACK to the client when the server goes from FIN_WAIT_1, so that the server goes to CLOSING instead of going to FIN_WAIT_2 (client closes first), or the FIN in the other direction so that the server doesn't go to TIME_WAIT from FIN_WAIT_2 (server closes first). 2) You have intentionally disabled KEEPALIVE, so that a close results in an RST instead of a normal shutdown of the TCP connection (I can't tell if you are doing a real call to "shutdown(2)", or if you are just relying on the OS resource tracking behaviour that is implicit to "close(2)" (but only if you don't set KEEPALIVE, and have disabled the sysctl default of always doing KEEPALIVE on every connection). In this case, it's possible that the RST was lost on the wire, and since RSTs are not retransmitted, you have shot yourself in the foot. Note: You often see this type of foolish foot shooting when running MAST, WAST, or webbench, which try to factor out response speed and measure connection speed, so that they benchmark the server, not the FS or other OS latencies in the document delivery path (which is why these tools suck as real world benchmarks go). You could also cause this (unlikely) with a bad firewall rule. 3) You've exhausted your mbufs before you've exhausted the number of simultaneous connections you are permitted, because you have incorrectly tuned your kernel, and therefore all your connections are sitting in a starvation deadlock, waiting for packets that can never be sent because there are no mbufs available. 4) You've got local hacks that your aren't telling us about (shame on you!). 5) You have found an introduced bug in -current. Note: I personally think this one is unlikely. 6) Maybe something I haven't thought of... Note: I personally think this one is unlikely, too... ;^) See RFC 793 (or Stevens) for details on the state machine for both ends of the connection, and you will see how your machine got into this mess in the first place. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 14:20:43 2002 Delivered-To: freebsd-current@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 97ED437B400 for ; Wed, 16 Jan 2002 14:20:40 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id XAA10267 for freebsd-current@freebsd.org; Wed, 16 Jan 2002 23:20:39 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id g0GMHEW37153; Wed, 16 Jan 2002 23:17:14 +0100 (MET) (envelope-from j) Date: Wed, 16 Jan 2002 23:17:14 +0100 (MET) Message-Id: <200201162217.g0GMHEW37153@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 1.0b.1 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: <200201160738.XAA23971@lecs.cs.ucla.edu> <200201161833.NAA19174@marlborough.cnchost.com> <200201162018.g0GKISJ05153@uriah.heep.sax.de> From: j@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: size of /usr/src X-Original-Newsgroups: local.freebsd.current To: freebsd-current@freebsd.org 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 j@uriah.heep.sax.de (Joerg Wunsch) wrote: > j@uriah 57% df -k /usr/src > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/vinum/src 595455 434778 113041 79% /usr/src > > That is -current as of around christmas. Bakul got back to me and questioned that number -- he was right. :) The above filesystem doesn't only contain a checked out copy of the src/ stuff but also of doc/, which adds another 60+ MB to it. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 14:29:38 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.acns.ab.ca (h24-64-56-135.cg.shawcable.net [24.64.56.135]) by hub.freebsd.org (Postfix) with ESMTP id A0F6037B400 for ; Wed, 16 Jan 2002 14:29:09 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0GMT9I81929; Wed, 16 Jan 2002 15:29:09 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0GMT8H01682; Wed, 16 Jan 2002 15:29:08 -0700 (MST) (envelope-from davidc) Date: Wed, 16 Jan 2002 15:29:08 -0700 From: Chad David To: Terry Lambert Cc: Chad David , current@freebsd.org Subject: Re: socket shutdown delay? Message-ID: <20020116152908.A1476@colnta.acns.ab.ca> Mail-Followup-To: Terry Lambert , Chad David , current@freebsd.org References: <20020116070908.A803@colnta.acns.ab.ca> <3C45F32A.5B517F7E@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C45F32A.5B517F7E@mindspring.com>; from tlambert2@mindspring.com on Wed, Jan 16, 2002 at 01:39:54PM -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, Jan 16, 2002 at 01:39:54PM -0800, Terry Lambert wrote: > Chad David wrote: > > Has anyone noticed (or fixed) a bug in -current where socket connections > > on the local machine do not shutdown properly? During stress testing > > I'm seeing thousands (2316 right now) of these: > > > > tcp4 0 0 192.168.1.2.8080 192.168.1.2.2215 FIN_WAIT_2 > > tcp4 0 0 192.168.1.2.2215 192.168.1.2.8080 LAST_ACK > > > > Both the client and the server are dead, but the connections stay in this > > state. > > > > I tested with the server on -current and the client on another box, and > > all of the server sockets end up in TIME_WAIT. Is there something delaying > > the last ack on local connections? > > A connection goes into FIN_WAIT_2 when it has received the ACK > of the FIN, but not received a FIN (or sent an ACK) itself, thus > permitting it to enter TIME_WAIT state for 2MSL before proceeding > to the CLOSED state, as a result of a server initiated close. > > A connection goes into LAST_ACK when it has sent a FIN and not > received the ACK of the FIN before proceeding to the CLOSED > state, as a result of a client initiated close. I've got TCP/IP Illistrated V1 right beside me, so I basically knew what was happening. Just not why. Like I said in the original email, connections from another machine end up in TIME_WAIT right away, it is only local connection. > > Since it's showing IP addresses, you appear to be using real > network connections, rather than loopback connections. In this case yes. Connections to 127.0.0.1 result in the same thing. > > There are basically several ways to cause this: > > 1) You have something on your network, like a dummynet, > that is deteministically dropping the the ACK to > the client when the server goes from FIN_WAIT_1, > so that the server goes to CLOSING instead of going > to FIN_WAIT_2 (client closes first), or the FIN in > the other direction so that the server doesn't go > to TIME_WAIT from FIN_WAIT_2 (server closes first). Nothing like that on the box. > > 2) You have intentionally disabled KEEPALIVE, so that > a close results in an RST instead of a normal > shutdown of the TCP connection (I can't tell if > you are doing a real call to "shutdown(2)", or if > you are just relying on the OS resource tracking > behaviour that is implicit to "close(2)" (but only > if you don't set KEEPALIVE, and have disabled the > sysctl default of always doing KEEPALIVE on every > connection). In this case, it's possible that the > RST was lost on the wire, and since RSTs are not > retransmitted, you have shot yourself in the foot. > > Note: You often see this type of foolish foot > shooting when running MAST, WAST, or > webbench, which try to factor out response > speed and measure connection speed, so that > they benchmark the server, not the FS or > other OS latencies in the document delivery > path (which is why these tools suck as real > world benchmarks go). You could also cause > this (unlikely) with a bad firewall rule. I haven't changed any sysctls, and other than SO_REUSEADDR, the default sockopts are being used. I also do not call shutdown() on either end, and both the client and server processes have exited and the connections still do not clear up (in time they do, around 10 minutes). > > 3) You've exhausted your mbufs before you've exhausted > the number of simultaneous connections you are > permitted, because you have incorrectly tuned your > kernel, and therefore all your connections are sitting > in a starvation deadlock, waiting for packets that can > never be sent because there are no mbufs available. The client eventually fails with EADDRNOTAVAIL. Here are the mbuf stats before and after. Before test: ------------------------------------------------------------------------ colnta->netstat -m mbuf usage: GEN list: 0/0 (in use/in pool) CPU #0 list: 51/144 (in use/in pool) CPU #1 list: 51/144 (in use/in pool) Total: 102/288 (in use/in pool) Maximum number allowed on each CPU list: 512 Maximum possible: 67584 Allocated mbuf types: 102 mbufs allocated to data 0% of mbuf map consumed mbuf cluster usage: GEN list: 0/0 (in use/in pool) CPU #0 list: 50/86 (in use/in pool) CPU #1 list: 51/88 (in use/in pool) Total: 101/174 (in use/in pool) Maximum number allowed on each CPU list: 128 Maximum possible: 33792 0% of cluster map consumed 420 KBytes of wired memory reserved (54% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines After test: ------------------------------------------------------------------------ colnta->netstat -m mbuf usage: GEN list: 0/0 (in use/in pool) CPU #0 list: 59/144 (in use/in pool) CPU #1 list: 43/144 (in use/in pool) Total: 102/288 (in use/in pool) Maximum number allowed on each CPU list: 512 Maximum possible: 67584 Allocated mbuf types: 102 mbufs allocated to data 0% of mbuf map consumed mbuf cluster usage: GEN list: 0/0 (in use/in pool) CPU #0 list: 58/86 (in use/in pool) CPU #1 list: 43/88 (in use/in pool) Total: 101/174 (in use/in pool) Maximum number allowed on each CPU list: 128 Maximum possible: 33792 0% of cluster map consumed 420 KBytes of wired memory reserved (54% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines and colnta->netstat -an | grep FIN_WAIT_2 | wc 2814 16884 219492 and a few minutes later: colnta->netstat -an | grep FIN_WAIT_2 | wc 1434 8604 111852 The box currently has 630MB free memory, and is 98.8% idle. I'm not sure what other information would be useful? > > 4) You've got local hacks that your aren't telling us > about (shame on you!). Nope. Stock -current, none of my patches applied. > > 5) You have found an introduced bug in -current. > > Note: I personally think this one is unlikely. Me too, but I can't think of any reason why the machine wouldn't send the last ack. I must be starving something... I'll go over my code again, and see if I can find a bug. > > 6) Maybe something I haven't thought of... > > Note: I personally think this one is unlikely, > too... ;^) Well if you don't know, where does that leave me? :). > > See RFC 793 (or Stevens) for details on the state machine for > both ends of the connection, and you will see how your machine > got into this mess in the first place. I've been reading it... Thanks. -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 15:51:45 2002 Delivered-To: freebsd-current@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id D2F7E37B417 for ; Wed, 16 Jan 2002 15:51:31 -0800 (PST) Received: from pool0446.cvx21-bradley.dialup.earthlink.net ([209.179.193.191] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16Qzpy-00011k-00; Wed, 16 Jan 2002 15:51:23 -0800 Message-ID: <3C4611D7.F99A5147@mindspring.com> Date: Wed, 16 Jan 2002 15:50:47 -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: Chad David Cc: current@freebsd.org Subject: Re: socket shutdown delay? References: <20020116070908.A803@colnta.acns.ab.ca> <3C45F32A.5B517F7E@mindspring.com> <20020116152908.A1476@colnta.acns.ab.ca> 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 Chad David wrote: > > A connection goes into FIN_WAIT_2 when it has received the ACK > > of the FIN, but not received a FIN (or sent an ACK) itself, thus > > permitting it to enter TIME_WAIT state for 2MSL before proceeding > > to the CLOSED state, as a result of a server initiated close. > > > > A connection goes into LAST_ACK when it has sent a FIN and not > > received the ACK of the FIN before proceeding to the CLOSED > > state, as a result of a client initiated close. > > I've got TCP/IP Illistrated V1 right beside me, so I basically > knew what was happening. Just not why. > > Like I said in the original email, connections from another machine > end up in TIME_WAIT right away, it is only local connection. Maybe there is a bug in the interrupt thread code, or in the scheduler for NETISR processing. Like I said before, I think this is unlikely. The other possibility is a bug in simultaneous client and server closes, but without information about your client and server program's operation (e.g. if it's an HTTP session, and the client closes without waiting for a response, or the server responsed and closes), that's as close as I can give you. I *really* doubt that, since I think it would have shown before. The other possibility might be the sequence numbers on a re-used connection going backwards. If that were to happen, you might see the sate machien push pack into LAST_ACK when it shouldn't. Be sure that you use the sysctl to set the sequence number algorithm to the one specified in the RFC, instead of the broken OpenBSD version that supposedly prevents predictive session hijack (which should be an application level thing about verification of the peer, anyway). Also make sure that the keepalive sysctl is set on (1). > > Since it's showing IP addresses, you appear to be using real > > network connections, rather than loopback connections. > > In this case yes. Connections to 127.0.0.1 result in the same thing. OK, so it's not lost packets because of the use of the network driver. This makes me lean toward the sequence number or RST with no mbufs available problem. [ ... test net intentionally lossy ... ] > Nothing like that on the box. OK. It was low hanging fruit, but unlikely, but had to be asked. > > 2) You have intentionally disabled KEEPALIVE, so that > > a close results in an RST instead of a normal > > shutdown of the TCP connection (I can't tell if > > you are doing a real call to "shutdown(2)", or if > > you are just relying on the OS resource tracking > > behaviour that is implicit to "close(2)" (but only > > if you don't set KEEPALIVE, and have disabled the > > sysctl default of always doing KEEPALIVE on every > > connection). In this case, it's possible that the > > RST was lost on the wire, and since RSTs are not > > retransmitted, you have shot yourself in the foot. > > > > Note: You often see this type of foolish foot > > shooting when running MAST, WAST, or > > webbench, which try to factor out response > > speed and measure connection speed, so that > > they benchmark the server, not the FS or > > other OS latencies in the document delivery > > path (which is why these tools suck as real > > world benchmarks go). You could also cause > > this (unlikely) with a bad firewall rule. > > I haven't changed any sysctls, and other than SO_REUSEADDR, > the default sockopts are being used. This doesn't tell me the setting of the keepalive sysctl. By default, it won't be on unless the sysctl forces it on, which it does by default, unless it's been changed, or the default has been changed in -current (don't know). So check this one. > I also do not call > shutdown() on either end, and both the client and server > processes have exited and the connections still do not clear > up (in time they do, around 10 minutes). You should probably call shutdown(2), if you want your code to be mostly correct. You also didn't say that they in fact drain after that period of time. I suspect that you are just doing a large number of connections. I frequently ended up with 50,000+ connections in TIME_WAIT state (I rarely use the same machine for both the client and the server, since that is not representative of real world use), and, of course, it takes 2MSL for TIME_WAIT to drain connections out. My guess is that you have ran out of mbufs (your usage stats tell me nothing about the abailable number of real mbufs; even the "0 requests for memory denied" is not really as useful as it would appear in the stats), or you just have an incredibly large number of files open. The FreeBSD file allocation table entry allocation for a large number of simultaneously open files is bad. Similarly, the FreeBSD allocation of the port space is a linear lookup that has exponential time increase as the number of connections go up. The same is true of the lookup of the INPCB and TCPCB on incoming packets. It would be useful to log state transitions for a connection case known to be bad -- that is, log the states starting after the problem has started with a new connection pair or ten, in order to see what's getting lost where. > > 3) You've exhausted your mbufs before you've exhausted > > the number of simultaneous connections you are > > permitted, because you have incorrectly tuned your > > kernel, and therefore all your connections are sitting > > in a starvation deadlock, waiting for packets that can > > never be sent because there are no mbufs available. > > The client eventually fails with EADDRNOTAVAIL. Yes, this is the outbound connection limitation because of the ports. There's three bugs there, in FreeBSD, as well, but they generally limit the outbound connections, rather than causing problems. One tuning variable you probably want on the machine making the connections is to up the TCP port range to 65535; you will have to do two sysctls in order to do this. This will delay your client failure by about a factor of 8-10 times as many connections (outbound connections count against the total, but inbound connections do not, since they do not use up socket/port pairs be source). > Allocated mbuf types: > 102 mbufs allocated to data These are probably TCP options on otherwise idle connections. > 0% of mbuf map consumed > mbuf cluster usage: > GEN list: 0/0 (in use/in pool) > CPU #0 list: 58/86 (in use/in pool) > CPU #1 list: 43/88 (in use/in pool) > Total: 101/174 (in use/in pool) > Maximum number allowed on each CPU list: 128 > Maximum possible: 33792 > 0% of cluster map consumed > 420 KBytes of wired memory reserved (54% in use) I'm not sure if the 54% is of the available or max wired. If the max, this could be your problem. > colnta->netstat -an | grep FIN_WAIT_2 | wc > 2814 16884 219492 > > and a few minutes later: > colnta->netstat -an | grep FIN_WAIT_2 | wc > 1434 8604 111852 This indicates a 2MSL draining. The resource track close could also be slow. You could probably get an incredible speedup by doing explicit closes in the client program, starting with the highest used fd, and working down, instead of going the other way (it's probably a good idea to modify the FreeBSD resource track close to so the same thing). There are some other inefficiencies in the fd code that can be addressed... nominally, the allocation is a linear search at the last valid one going higher. For most servers, this could be significantly improved by linking free fd's in a sparse list onto a "freelist", and maintaining a pointer to that, instead of the index to the first free one, but that should only impact you on allocation (like the inpcb hash, which fails pretty badly, even when you tune up the hash size to some unreasonable amount, and the port allocation for outbound connections, which is, frankly, broken. Both could benefit from a nice btree overhaul). THe timer code is also pretty sucky, even with a very large callout wheel. It would be incredibly valuable to have fixed interval timers ordered by entry on interval specific lists (e.g. MSL and 2MSL lists, as well as other common ones), so that the scan of the timer entries could be stopped at the first one whose expiration time was after the current time for the given interval callout. This would save you almost all of your callout list traversals, which, with the wheel, have to be ordered (see the Rice University paper on opportunistic timers for a glancing approach at solving the real problem here). These aren't biting you, though, because the quick draining is happening, indicating that it's not really the timer code or the other code that's your immediate problem (though you might speed draining by a factor of 3 just by fixing the timers to use ordered lists per interval, rather than the callout wheel). > The box currently has 630MB free memory, and is 98.8% idle. OK, this means that you aren't getting anywhere near the KVA limits, and that you aren't eating as much of core as you might be otherwise. In practice, you can reserve as much as 50% of physical memory for use in mbufs, if you are tuned correctly. The limits that implies, assuming you are sending a lot of data, are 315MB/32k ~= 10,000 client and server connections, or 20,000 server only connections (if the client is on another machine). After that, your transmit windows ont he server and receive windows on the client are full. OOPS. Halve that for -current, since the default window size was doubled. OK... you very well could be hitting the limits here, with the number of sockets available and the amount of memory you have to burn in mbufs. Try setting your max window size down to 16k, or even 8k (you really want to set the transmit windows large and the receive windows small for a server, but that's not an option in the current code, I think, and anyway, since you are running both on the same machine, that makes it impossible for you to tune a single machine for optimal performance as only a client or only a server. > I'm not sure what other information would be useful? See above. > > 4) You've got local hacks that your aren't telling us > > about (shame on you!). > > Nope. Stock -current, none of my patches applied. Heh... "not useful information without a date of cvsup, and then possibly not even then". Moving target problems... Can you repeat this on 4.5RC? If so, try 4.4-RELEASE. It may be related to the SYN cache code. The SYN-cookie code is vulnerable to the "ACK gun" attack, and since the SYN cache code falls back into SYN cookie (it assumes that the reason it didn't find the corresponding SYN in the SYN cache is that it overflowed and was discarded, turning naked ACK attempts into SYN-cookie attempts completely automatically), you might be hitting it that way. If that's the case, then I suggest leaving the SYN cache enabled, and disabling the SYN cookie. If that doesn't fix it, then you may also want to try disabling the SYN cache. Other than that, once you've tried this, then I will need to know what the failure modes are, and then more about the client and server code (kqueue based? Standard sockets based?), and then I can suggest more to narrow it down. Another thing you may want to try is delay closing the server side of the connection for 1-2 seconds after the last write. This is the canonical way of forcing a client to do the close first in all cases, which totally avoids the server-side-close-first case, which also avoids the FIN_WAIT_2. For real code, you would have to add a "close cache" and timer. Hope this helps... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 16:19:52 2002 Delivered-To: freebsd-current@freebsd.org Received: from gw.visp.com.au (gw.visp.com.au [202.61.170.5]) by hub.freebsd.org (Postfix) with ESMTP id 0157837B400 for ; Wed, 16 Jan 2002 16:19:39 -0800 (PST) Received: from spyderweb.com.au (new48.visp.com.au [202.61.170.48]) by gw.visp.com.au (8.9.3/8.8.7) with SMTP id KAA30107 for ; Thu, 17 Jan 2002 10:07:35 +1030 Date: Thu, 17 Jan 2002 10:49:01 +1030 From: Timothy Aslat To: freebsd-current@freebsd.org Subject: Downgrading Message-Id: <20020117104901.24d09d36.tim@spyderweb.com.au> Organization: Spyderweb Consulting X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd5.0) 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 All, Quick question. Where would I find information on downgrading a -CURRENT to a -STABLE or -RELEASE? I'm just trying to avoid doing a reinstall and re-setup from scratch. Regards Tim -- | The most exciting phrase to | Tim Aslat | | hear in science, the one that | http://www.spyderweb.com.au | | heralds new discoveries, is | Spyderweb Consulting | | not "Eureka!" (I found it!) | P: 82270800 M: 0401088479 | | but "That's funny ..." | Webmaster for | | -- Isaac Asimov | http://www.goodiesruleok.com | | No, "Eureka" is Greek for | The Ultimate Goody Fansite | | "This bath is too hot! | admin@goodiesruleok.com | | -- Dr Who | | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 16:39:48 2002 Delivered-To: freebsd-current@freebsd.org Received: from router.hackerheaven.org (qn-213-73-194-22.quicknet.nl [213.73.194.22]) by hub.freebsd.org (Postfix) with ESMTP id EF78037B402 for ; Wed, 16 Jan 2002 16:39:43 -0800 (PST) Received: by router.hackerheaven.org (Postfix, from userid 1000) id 1278D1C05; Thu, 17 Jan 2002 01:39:18 +0100 (CET) Date: Thu, 17 Jan 2002 01:39:18 +0100 From: Emiel Kollof To: Timothy Aslat Cc: freebsd-current@freebsd.org Subject: Re: Downgrading Message-ID: <20020117003918.GB484@laptop.hackerheaven.org> References: <20020117104901.24d09d36.tim@spyderweb.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020117104901.24d09d36.tim@spyderweb.com.au> User-Agent: Mutt/1.3.25i X-Mailer: Mutt 1.3.23i (2001-10-09) X-Editor: Vim http://www.vim.org/ X-Info: http://www.hackerheaven.org/ X-Info2: http://www.cmdline.org/ X-Info3: http://www.coolvibe.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 * Timothy Aslat (tim@spyderweb.com.au) wrote: > Hi All, > > Quick question. Where would I find information on downgrading a > -CURRENT to a -STABLE or -RELEASE? Well, that's going to be a hard one. If you have been running CURRENT for a while, and compiling ports in CURRENT, you will probably have lots of apps that use libc5. And since STABLE has no 5.x compat libraries, you would have to compile those all over again anyway. If it's a freshly upgraded machine, I suppose a cvsup back to RELENG_4 and a rebuild of world and kernel would work. I tried that once when I decided to upgrade once to CURRENT, and something in CURRENT was broken, so I had to revert my system back in some way. Lucky for me my compiler was still functional, and also the rest of my toolchain, so I had little problems. This was three or four months ago. You could try it, and possibly hose your system, but it also might work. Reinstalling is always an option. Just make sure you back up the important data. YMMV, and #include . If someone here has better (and safer) ways to downgrade, feel free to post :-) Cheers, Emiel -- Frisbeetarianism, n.: The belief that when you die, your soul goes up the on roof and gets stuck. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 16:43:59 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.acns.ab.ca (h24-64-56-135.cg.shawcable.net [24.64.56.135]) by hub.freebsd.org (Postfix) with ESMTP id 69A6D37B405 for ; Wed, 16 Jan 2002 16:43:49 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0H0hgI82489; Wed, 16 Jan 2002 17:43:42 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0H0hgQ02155; Wed, 16 Jan 2002 17:43:42 -0700 (MST) (envelope-from davidc) Date: Wed, 16 Jan 2002 17:43:42 -0700 From: Chad David To: Terry Lambert Cc: Chad David , current@freebsd.org Subject: Re: socket shutdown delay? Message-ID: <20020116174342.A2097@colnta.acns.ab.ca> Mail-Followup-To: Terry Lambert , Chad David , current@freebsd.org References: <20020116070908.A803@colnta.acns.ab.ca> <3C45F32A.5B517F7E@mindspring.com> <20020116152908.A1476@colnta.acns.ab.ca> <3C4611D7.F99A5147@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C4611D7.F99A5147@mindspring.com>; from tlambert2@mindspring.com on Wed, Jan 16, 2002 at 03:50:47PM -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, Jan 16, 2002 at 03:50:47PM -0800, Terry Lambert wrote: > Chad David wrote: > > > A connection goes into FIN_WAIT_2 when it has received the ACK > > > of the FIN, but not received a FIN (or sent an ACK) itself, thus > > > permitting it to enter TIME_WAIT state for 2MSL before proceeding > > > to the CLOSED state, as a result of a server initiated close. > > > > > > A connection goes into LAST_ACK when it has sent a FIN and not > > > received the ACK of the FIN before proceeding to the CLOSED > > > state, as a result of a client initiated close. > > > The direct cause is a bug in my client. I call close(2) out side of the main loop (one line off :( ), so none of the client side sockets were getting closed. When I fixed this all of the connections went to TIME_WAIT right away. I'm still not convinced that all is well though, as on Solaris 5.9 and 4.4-STABLE I do not see the problem with the bad client. I'll address your points below, but if you don't feel like chasing this anymore that is fine with me... I'll add it to my list of things to try and understand on my next vacation :). > Also make sure that the keepalive sysctl is set on (1). colnta->sysctl -a | grep keepalive net.inet.tcp.always_keepalive: 1 > > This doesn't tell me the setting of the keepalive sysctl. By > default, it won't be on unless the sysctl forces it on, which > it does by default, unless it's been changed, or the default > has been changed in -current (don't know). So check this one. It must be on by default. > > > I also do not call > > shutdown() on either end, and both the client and server > > processes have exited and the connections still do not clear > > up (in time they do, around 10 minutes). > > You should probably call shutdown(2), if you want your code > to be mostly correct. Call shutdown(2) instead of close(2)? > > I suspect that you are just doing a large number of connections. One connection at a time, as fast as the client can loop, with a small (1k) amount of data being returned by the server. > > I frequently ended up with 50,000+ connections in TIME_WAIT > state (I rarely use the same machine for both the client and > the server, since that is not representative of real world > use), and, of course, it takes 2MSL for TIME_WAIT to drain > connections out. Agreed, I'm still testing functionality. I just got hit with this while trying to check for simple memory leaks and broken code (not load testing). > > My guess is that you have ran out of mbufs (your usage stats > tell me nothing about the abailable number of real mbufs; > even the "0 requests for memory denied" is not really as > useful as it would appear in the stats), or you just have > an incredibly large number of files open. colnta->sysctl -a | grep mbuf kern.ipc.nmbufs: 67584 kern.ipc.mbuf_wait: 64 kern.ipc.mbuf_limit: 512 > > > 3) You've exhausted your mbufs before you've exhausted > > > the number of simultaneous connections you are > > > permitted, because you have incorrectly tuned your > > > kernel, and therefore all your connections are sitting > > > in a starvation deadlock, waiting for packets that can > > > never be sent because there are no mbufs available. > > > > The client eventually fails with EADDRNOTAVAIL. > > Yes, this is the outbound connection limitation because of the > ports. There's three bugs there, in FreeBSD, as well, but they > generally limit the outbound connections, rather than causing > problems. > > One tuning variable you probably want on the machine making the > connections is to up the TCP port range to 65535; you will have > to do two sysctls in order to do this. This will delay your > client failure by about a factor of 8-10 times as many > connections (outbound connections count against the total, but > inbound connections do not, since they do not use up socket/port > pairs be source). With the fixed client it never fails. I moved a few GB through it without any problem. > > > > and a few minutes later: > > colnta->netstat -an | grep FIN_WAIT_2 | wc > > 1434 8604 111852 > > This indicates a 2MSL draining. The resource track close could > also be slow. You could probably get an incredible speedup by > doing explicit closes in the client program, starting with the > highest used fd, and working down, instead of going the other > way (it's probably a good idea to modify the FreeBSD resource > track close to so the same thing). If I had been doing any explicit closes :(. > > There are some other inefficiencies in the fd code that can be > addressed... nominally, the allocation is a linear search at > the last valid one going higher. For most servers, this could > be significantly improved by linking free fd's in a sparse > list onto a "freelist", and maintaining a pointer to that, > instead of the index to the first free one, but that should only > impact you on allocation (like the inpcb hash, which fails > pretty badly, even when you tune up the hash size to some > unreasonable amount, and the port allocation for outbound > connections, which is, frankly, broken. Both could benefit from > a nice btree overhaul). I actually implemented something for this type of problem over Christmas with one of the Solaris engineers. It was inspired by Jeff Bonwick's vmem stuff (Usenix 2001), but was bit mask based, so the actual storage overhead was a lot less, with what appeared to be very good allocate and free times (O(n) as the worst case with O(1) typically). I still need to add support for layering to allow it to scale across multiple processors... but I'm getting off topic. > > THe timer code is also pretty sucky, even with a very large > callout wheel. It would be incredibly valuable to have fixed > interval timers ordered by entry on interval specific lists > (e.g. MSL and 2MSL lists, as well as other common ones), so > that the scan of the timer entries could be stopped at the > first one whose expiration time was after the current time for > the given interval callout. This would save you almost all of > your callout list traversals, which, with the wheel, have to be > ordered (see the Rice University paper on opportunistic timers > for a glancing approach at solving the real problem here). I think I have that paper around here somewhere... is it older, like from around 1990? > > These aren't biting you, though, because the quick draining is > happening, indicating that it's not really the timer code or > the other code that's your immediate problem (though you might > speed draining by a factor of 3 just by fixing the timers to > use ordered lists per interval, rather than the callout wheel). Maybe tomorrow night :). > > > > 4) You've got local hacks that your aren't telling us > > > about (shame on you!). > > > > Nope. Stock -current, none of my patches applied. > > Heh... "not useful information without a date of cvsup, > and then possibly not even then". Moving target problems... The original email has the uname and a dmesg, but: FreeBSD colnta 5.0-CURRENT FreeBSD 5.0-CURRENT #17: Sun Jan 13 03:51:32 MST 2002 > > Can you repeat this on 4.5RC? If so, try 4.4-RELEASE. It > may be related to the SYN cache code. I do not have a RC or RELEASE box, but 4.4-STABLE does not do this. > > The SYN-cookie code is vulnerable to the "ACK gun" attack, > and since the SYN cache code falls back into SYN cookie > (it assumes that the reason it didn't find the corresponding > SYN in the SYN cache is that it overflowed and was discarded, > turning naked ACK attempts into SYN-cookie attempts completely > automatically), you might be hitting it that way. > > If that's the case, then I suggest leaving the SYN cache > enabled, and disabling the SYN cookie. If that doesn't fix > it, then you may also want to try disabling the SYN cache. I'll have to look into this stuff to understand what you are saying. > > Other than that, once you've tried this, then I will need to > know what the failure modes are, and then more about the > client and server code (kqueue based? Standard sockets > based?), and then I can suggest more to narrow it down. Very simple sockets. Basically: ... accept() -> read() -> write() -> close() ... The actual read(), write(), close(), takes place in a seperate thread, but there is only one thread active at a time. > > Another thing you may want to try is delay closing the > server side of the connection for 1-2 seconds after the > last write. This is the canonical way of forcing a client > to do the close first in all cases, which totally avoids > the server-side-close-first case, which also avoids the > FIN_WAIT_2. For real code, you would have to add a "close > cache" and timer. Give that each connection is in its own thread this is very doable... > > Hope this helps... If nothing else I'm learning... I just wish I could read as fast as you can type :). -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 17:16:58 2002 Delivered-To: freebsd-current@freebsd.org Received: from white.imgsrc.co.jp (ns.imgsrc.co.jp [210.226.20.2]) by hub.freebsd.org (Postfix) with ESMTP id 21CE037B400 for ; Wed, 16 Jan 2002 17:16:50 -0800 (PST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [2001:218:422:2::130]) by white.imgsrc.co.jp (Postfix) with ESMTP id 95F1724DD2 for ; Thu, 17 Jan 2002 10:16:47 +0900 (JST) Received: from waterblue.imgsrc.co.jp (waterblue.imgsrc.co.jp [2001:218:422:2::160]) by black.imgsrc.co.jp (Postfix) with ESMTP id 4B1A31E4816 for ; Thu, 17 Jan 2002 10:16:46 +0900 (JST) Date: Thu, 17 Jan 2002 10:16:46 +0900 Message-ID: <7m7kqh22v5.wl@waterblue.imgsrc.co.jp> From: Jun Kuriyama To: Current Subject: panic: bioqdisksort() User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.1 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") 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 got a panic with kernel around "Jan 16 09:02:54 JST". Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = 00000000 fault virtual address = 0xcaeef040 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01cc833 stack pointer = 0x10:0xf4f33a84 frame pointer = 0x10:0xf4f33a90 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 19128 (make) kernel: type 12 trap, code=0 Stopped at bioqdisksort+0x2b: movl 0xc0(%ebx),%eax db> t bioqdisksort(c8ea80a8,caeeef80,c8ea7000,f4f33adc,c014e3de) at bioqdisksort+0x2b adstrategy(caeeef80) at adstrategy+0x39 arstrategy(d54f271c,d54f271c,ec363c20,f4f33b08,c019f8d3) at arstrategy+0x2de diskstrategy(d54f271c,c8efd100,d54f271c,0,f4f33b14) at diskstrategy+0xcd spec_strategy(f4f33b2c,f4f33b38,c0290821,f4f33b2c,f4f33bfc) at spec_strategy+0x19b spec_vnoperate(f4f33b2c,f4f33bfc,d54f271c,0,c0334380) at spec_vnoperate+0x15 ufs_strategy(f4f33b68,f4f33b74,c01ec78e,f4f33b68,f2c42f00) at ufs_strategy+0xa9 ufs_vnoperate(f4f33b68) at ufs_vnoperate+0x15 breadn(f2c42f00,0,800,0,0) at breadn+0xc2 bread(f2c42f00,0,800,0,f4f33bfc) at bread+0x1d ffs_read(f4f33c20,2000,f4f33d20,2000,0) at ffs_read+0x2c3 vn_read(caeed100,f4f33c90,ca9f2200,0,f4ea6404) at vn_read+0x130 dofileread(f4ea6404,caeed100,3,8088000,2000) at dofileread+0xae read(f4ea6404,f4f33d20,807e0e0,8095b00,8095b00) at read+0x51 syscall(2f,2f,2f,8095b00,8095b00) at syscall+0x25f syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (3, FreeBSD ELF, read), eip = 0x8061cd7, esp = 0xbfbfe748, ebp = 0xbfbfe764 --- (kgdb) where #0 dumpsys () at ../../../kern/kern_shutdown.c:492 #1 0xc01bdc6b in boot (howto=260) at ../../../kern/kern_shutdown.c:335 #2 0xc01be10d in panic (fmt=0xc02eac6a "from debugger") at ../../../kern/kern_shutdown.c:634 #3 0xc013fb4d in db_panic (addr=-1071855565, have_addr=0, count=-1, modif=0xf4f338f0 "") at ../../../ddb/db_command.c:452 #4 0xc013faeb in db_command (last_cmdp=0xc0339d64, cmd_table=0xc0339b84, aux_cmd_tablep=0xc03306f8, aux_cmd_tablep_end=0xc03306fc) at ../../../ddb/db_command.c:348 #5 0xc013fbb7 in db_command_loop () at ../../../ddb/db_command.c:474 #6 0xc0141f33 in db_trap (type=12, code=0) at ../../../ddb/db_trap.c:72 #7 0xc02bfd4a in kdb_trap (type=12, code=0, regs=0xf4f33a44) at ../../../i386/i386/db_interface.c:167 #8 0xc02d0da0 in trap_fatal (frame=0xf4f33a44, eva=3404656704) at ../../../i386/i386/trap.c:837 #9 0xc02d0ae9 in trap_pfault (frame=0xf4f33a44, usermode=0, eva=3404656704) at ../../../i386/i386/trap.c:756 #10 0xc02d0653 in trap (frame={tf_fs = -1071972328, tf_es = -1070006256, tf_ds = 16, tf_edi = -185965564, tf_esi = -924155736, tf_ebp = -185386352, tf_isp = -185386384, tf_ebx = -890310784, tf_edx = -890311808, tf_ecx = -924160000, tf_eax = -185965776, tf_trapno = 12, tf_err = 0, tf_eip = -1071855565, tf_cs = 8, tf_eflags = 66178, tf_esp = -924155904, tf_ss = 13507}) at ../../../i386/i386/trap.c:426 #11 0xc01cc833 in bioqdisksort (bioq=0xc8ea80a8, bp=0xcaeeef80) at ../../../kern/subr_disklabel.c:91 #12 0xc014c951 in adstrategy (bp=0xcaeeef80) at ../../../dev/ata/ata-disk.c:293 #13 0xc014e3de in arstrategy (bp=0xd54f271c) at ../../../dev/ata/ata-raid.c:243 #14 0xc01cc6d5 in diskstrategy (bp=0xd54f271c) at ../../../kern/subr_disk.c:390 #15 0xc019f8d3 in spec_strategy (ap=0xf4f33b2c) at ../../../fs/specfs/spec_vnops.c:494 #16 0xc019f1ed in spec_vnoperate (ap=0xf4f33b2c) at ../../../fs/specfs/spec_vnops.c:119 #17 0xc0290821 in ufs_strategy (ap=0xf4f33b68) at vnode_if.h:762 #18 0xc0290fe5 in ufs_vnoperate (ap=0xf4f33b68) at ../../../ufs/ufs/ufs_vnops.c:2657 #19 0xc01ec78e in breadn (vp=0xf2c42f00, blkno=0, size=2048, rablkno=0x0, rabsize=0x0, cnt=0, cred=0x0, bpp=0xf4f33bfc) at vnode_if.h:762 #20 0xc01ec6c9 in bread (vp=0xf2c42f00, blkno=0, size=2048, cred=0x0, bpp=0xf4f33bfc) at ../../../kern/vfs_bio.c:585 #21 0xc02886fb in ffs_read (ap=0xf4f33c20) at ../../../ufs/ufs/ufs_readwrite.c:278 #22 0xc01ff044 in vn_read (fp=0xcaeed100, uio=0xf4f33c90, cred=0xca9f2200, flags=0, td=0xf4ea6404) at vnode_if.h:279 #23 0xc01d5306 in dofileread (td=0xf4ea6404, fp=0xcaeed100, fd=3, buf=0x8088000, nbyte=8192, offset=-1, flags=0) at ../../../sys/file.h:179 #24 0xc01d5189 in read (td=0xf4ea6404, uap=0xf4f33d20) at ../../../kern/sys_generic.c:133 #25 0xc02d118b in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134830848, tf_esi = 134830848, tf_ebp = -1077942428, tf_isp = -185385612, tf_ebx = 134734048, tf_edx = 134774784, (kgdb) up 11 #11 0xc01cc833 in bioqdisksort (bioq=0xc8ea80a8, bp=0xcaeeef80) at ../../../kern/subr_disklabel.c:91 91 TAILQ_FOREACH(bn, &bioq->queue, bio_queue) (kgdb) list 86 struct bio *bn; 87 struct bio *be; 88 struct thread *td = curthread; 89 90 if (td && td->td_ksegrp->kg_nice > 0) { 91 TAILQ_FOREACH(bn, &bioq->queue, bio_queue) 92 if (BIOTOBUF(bp)->b_vp != BIOTOBUF(bn)->b_vp) 93 break; 94 if (bn != NULL) { 95 mtx_lock(&dksort_mtx); -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 17:27:46 2002 Delivered-To: freebsd-current@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 216C537B416 for ; Wed, 16 Jan 2002 17:27:36 -0800 (PST) Received: from pool0199.cvx22-bradley.dialup.earthlink.net ([209.179.198.199] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16R1L2-0002PY-00; Wed, 16 Jan 2002 17:27:32 -0800 Message-ID: <3C462820.F4E39DF8@mindspring.com> Date: Wed, 16 Jan 2002 17:25:52 -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: Chad David Cc: current@freebsd.org Subject: Re: socket shutdown delay? References: <20020116070908.A803@colnta.acns.ab.ca> <3C45F32A.5B517F7E@mindspring.com> <20020116152908.A1476@colnta.acns.ab.ca> <3C4611D7.F99A5147@mindspring.com> <20020116174342.A2097@colnta.acns.ab.ca> 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 Chad David wrote: > The direct cause is a bug in my client. I call close(2) out side of the > main loop (one line off :( ), so none of the client side sockets were > getting closed. When I fixed this all of the connections went to > TIME_WAIT right away. > > I'm still not convinced that all is well though, as on Solaris 5.9 and > 4.4-STABLE I do not see the problem with the bad client. So it's the resource track close of the sockets. If the client and the server were the same program, you could be seeing this as a timing thing on order of operation. I'm guessing they aren't, though... > I'll address your points below, but if you don't feel like chasing this > anymore that is fine with me... I'll add it to my list of things to > try and understand on my next vacation :). Unless there's something that jumps out at you, this is probably a good plan. 8-). > > Also make sure that the keepalive sysctl is set on (1). [ ... it's on, so it's not the RST instead of FIN/FIN-ACK/2MSL losing the RST that isn't retransmitted ... ] > > You should probably call shutdown(2), if you want your code > > to be mostly correct. > > Call shutdown(2) instead of close(2)? Nope. Before close. Depending on the argument, perhaps not before the last read or write, then the close. > > I suspect that you are just doing a large number of connections. > > One connection at a time, as fast as the client can loop, with > a small (1k) amount of data being returned by the server. So you would shutdown() after the request, but before reading the response, to indicate that you have no more request data to send. > > My guess is that you have ran out of mbufs (your usage stats > > tell me nothing about the abailable number of real mbufs; > > even the "0 requests for memory denied" is not really as > > useful as it would appear in the stats), or you just have > > an incredibly large number of files open. > > colnta->sysctl -a | grep mbuf > kern.ipc.nmbufs: 67584 > kern.ipc.mbuf_wait: 64 > kern.ipc.mbuf_limit: 512 This number is how many mbufs possible. It represents the map size for the page table entries, and doesn't really indicate that there are physical pages of RAM available to back them. However, since this is only ~33M of memory, this is nothing. With the 1K size of the data you are sending from the server, this puts you at a connection max of 16,000, assuming all data is sent but not yet ACK'ed... or 8,000, given that both client and server are on the same machine. The absolute worst case sits down around 6,000 (ACK packets, driver mbufs, socket option mbufs, etc., dragging it down a little). So it's unrelated to that, but we already knew that because of the program change. 8-). > > > The client eventually fails with EADDRNOTAVAIL. [ ... ] > With the fixed client it never fails. I moved a few GB through it > without any problem. You will want to up the user ports on the clients when you start stress testing it from multiple client machines, anyway. > > This indicates a 2MSL draining. The resource track close could > > also be slow. You could probably get an incredible speedup by > > doing explicit closes in the client program, starting with the > > highest used fd, and working down, instead of going the other > > way (it's probably a good idea to modify the FreeBSD resource > > track close to so the same thing). > > If I had been doing any explicit closes :(. Yes, but your ordering is reverse optimal, actually, so you are going to be rate limited at the client. Did the client actually exit? If it didn't, that would explain everything. > > There are some other inefficiencies in the fd code that can be > > addressed... nominally, the allocation is a linear search at > > the last valid one going higher. For most servers, this could > > be significantly improved by linking free fd's in a sparse > > list onto a "freelist", and maintaining a pointer to that, > > instead of the index to the first free one, but that should only > > impact you on allocation (like the inpcb hash, which fails > > pretty badly, even when you tune up the hash size to some > > unreasonable amount, and the port allocation for outbound > > connections, which is, frankly, broken. Both could benefit from > > a nice btree overhaul). > > I actually implemented something for this type of problem over Christmas > with one of the Solaris engineers. It was inspired by Jeff Bonwick's > vmem stuff (Usenix 2001), but was bit mask based, so the actual storage > overhead was a lot less, with what appeared to be very good allocate and > free times (O(n) as the worst case with O(1) typically). This would be nice for FreeBSD, assuming we could pry it out of you. 8-). [ ... timer code, Rice U. Opportunistic Timers ... ] > I think I have that paper around here somewhere... is it older, > like from around 1990? No, you are probably thinking of the WRL paper by Jeff Mogul. The paper I'm referring to is late mid-90's. > > > Nope. Stock -current, none of my patches applied. > > > > Heh... "not useful information without a date of cvsup, > > and then possibly not even then". Moving target problems... > > The original email has the uname and a dmesg, but: > FreeBSD colnta 5.0-CURRENT FreeBSD 5.0-CURRENT #17: Sun Jan 13 03:51:32 MST 2002 I would need to check it out, and build my own copy, and see if I could repeat it (I'd need your broken client and your server code. It would be much better to see if other well known and tested versions of FreeBSD exhibited the same symptoms, and, if not, track it down with a bsearch of the CVS tree by date. > > Can you repeat this on 4.5RC? If so, try 4.4-RELEASE. It > > may be related to the SYN cache code. > > I do not have a RC or RELEASE box, but 4.4-STABLE does not do this. OK, that's interesting. The reason I meantioned the RC stuff (FreeBSD 4.5 from the RELENG_4 head tag checkout) is that a major difference is the MFC of the SYN cache/cookie code. > > The SYN-cookie code is vulnerable to the "ACK gun" attack, > > and since the SYN cache code falls back into SYN cookie > > (it assumes that the reason it didn't find the corresponding > > SYN in the SYN cache is that it overflowed and was discarded, > > turning naked ACK attempts into SYN-cookie attempts completely > > automatically), you might be hitting it that way. > > > > If that's the case, then I suggest leaving the SYN cache > > enabled, and disabling the SYN cookie. If that doesn't fix > > it, then you may also want to try disabling the SYN cache. > > I'll have to look into this stuff to understand what you are saying. Do that; it's probably where the problem is, given that 4.4 doesn't have it. > > Other than that, once you've tried this, then I will need to > > know what the failure modes are, and then more about the > > client and server code (kqueue based? Standard sockets > > based?), and then I can suggest more to narrow it down. > > Very simple sockets. Basically: > ... accept() -> read() -> write() -> close() ... OK; there's a potential latency issue in the accept filter code, but if you aren't using kqueue, then that's not it. > The actual read(), write(), close(), takes place in a seperate thread, > but there is only one thread active at a time. Yep; ignore this angle on the problem. > > Another thing you may want to try is delay closing the > > server side of the connection for 1-2 seconds after the > > last write. This is the canonical way of forcing a client > > to do the close first in all cases, which totally avoids > > the server-side-close-first case, which also avoids the > > FIN_WAIT_2. For real code, you would have to add a "close > > cache" and timer. > > Give that each connection is in its own thread this is very doable... This would at least isolate it to the client vs. server code and order of operation. If it's the server close, then the issue is perhaps a re-ACK after FIN ACK from the close making the SYN cache think it has a new connection, then a re-FIN, with the close, to get it into the strange state... > > Hope this helps... > > If nothing else I'm learning... I just wish I could read as fast > as you can type :). Heh. My max rate is 135 WPM, which is 6*135 CPM or 13.5 CPS, or 135 BAUD, which is slow as molasses compared to most people's read rates (by about 2 orders of magnitude). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 17:59:48 2002 Delivered-To: freebsd-current@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 5A24037B416 for ; Wed, 16 Jan 2002 17:59:44 -0800 (PST) Received: from pool0199.cvx22-bradley.dialup.earthlink.net ([209.179.198.199] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16R1q8-0005AN-00; Wed, 16 Jan 2002 17:59:40 -0800 Message-ID: <3C462FFF.22701A04@mindspring.com> Date: Wed, 16 Jan 2002 17:59:27 -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: Timothy Aslat Cc: freebsd-current@freebsd.org Subject: Re: Downgrading References: <20020117104901.24d09d36.tim@spyderweb.com.au> 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 Timothy Aslat wrote: > > Hi All, > > Quick question. Where would I find information on downgrading a > -CURRENT to a -STABLE or -RELEASE? > > I'm just trying to avoid doing a reinstall and re-setup from scratch. THis belongs on -questions. In general, you can boot from a CDROM of the version you want to downgrade to, choose "upgrade" from the sysinstall menu, and then proceed to "upgrade". It will not install your sources for you (you will have to do that manually). You may also have a number of issues with configuration file data, though it should leave libraries and other things intact. The only other things that should be able to go wrong are any libraries in developement that have not had their version numbers bumped for interface changes, and the boot blocks, which you can deal with by manually reinstalling via the "holographic shell" via a manual run of "disklabel -B" using the installed files by specifying the path to them, prior to the reboot. FWIW, I have, in practice, "upgraded" a large number of -current machines from an October 2000 snapshot to a 4.3-RELEASE CDROM version, with no problem, if locally booted, and with some effort when doing the upgrade from an NFS mounted CDROM over the network (mostly, SSH problems with the pam.conf files when the SSH changed to need explicit pam.conf entries, and not using the generic entries if the SSH ones were missing, as the PAM design documents with which SSH does not comply indicate you should do...). You also have to run the sysinstall from the CDROM, which is not on the CDROM itself, and is hidden in the boot images -- and must be named "sysinstall", because it's a crunched binary. The only other issue is that you must manually copy ove /dev/MAKEDEV and /dev/MAKEDEV.local, and run "sh MAKEDEV all" to get the /dev/random set up correctly, but all this can be done prior to the reboot. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 22:10: 7 2002 Delivered-To: freebsd-current@freebsd.org Received: from femail25.sdc1.sfba.home.com (femail25.sdc1.sfba.home.com [24.254.60.15]) by hub.freebsd.org (Postfix) with ESMTP id C34E437B400 for ; Wed, 16 Jan 2002 22:10:02 -0800 (PST) Received: from dosmonos ([24.249.124.238]) by femail25.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20020117061002.LPAF25713.femail25.sdc1.sfba.home.com@dosmonos> for ; Wed, 16 Jan 2002 22:10:02 -0800 Date: Thu, 17 Jan 2002 01:08:41 -0500 (EST) From: Mike Brancato X-Sender: funnyguy@dosmonos To: freebsd-current@freebsd.org Subject: boot floppy problems... 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 Just leting you guys know that the Jan 15th and Jan 16th boot floppies aren't working. the Jan 13th snaps are though. mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 16 23: 7:28 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 1CC6637B405 for ; Wed, 16 Jan 2002 23:07:16 -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 SAA21809; Thu, 17 Jan 2002 18:06:11 +1100 Date: Thu, 17 Jan 2002 18:07:26 +1100 (EST) From: Bruce Evans X-X-Sender: To: Michael Reifenberger Cc: FreeBSD-Current Subject: Re: panic during fdisk'ing a md(4) device In-Reply-To: <20020114152940.W429-200000@nihil> Message-ID: <20020117175846.H491-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 Mon, 14 Jan 2002, Michael Reifenberger wrote: > On Tue, 15 Jan 2002, Bruce Evans wrote: > ... > > Try this version. Only disklabel.h has many changes. The code for > > avoiding creation of bogus 'c' partitions didn't work at all. > > This works during startup but the following commands cases a panic > while executing newfs (BT is attached): > > mdconfig -a -t swap -s 128M -o reserve -u 10 > disklabel -r -w md10 auto > (When looking into /dev now I see two! md10c devices!) > newfs -f 4096 /dev/md10c > tunefs -n enable /dev/md10c > mount /dev/md10c /tmp Oops. There should be no alias for md10c. Try this version. It fixes the "may want an alias case" in dkmodminor() and moves all the dk inlines to subr_diskslice.c. %%% Index: kern/subr_disk.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_disk.c,v retrieving revision 1.50 diff -u -2 -r1.50 subr_disk.c --- kern/subr_disk.c 4 Nov 2001 11:56:22 -0000 1.50 +++ kern/subr_disk.c 14 Jan 2002 11:42:38 -0000 @@ -301,5 +301,5 @@ error = 0; - pdev = dkmodpart(dkmodslice(dev, WHOLE_DISK_SLICE), RAW_PART); + pdev = dkmodslice(dkmodpart(dev, -RAW_PART), WHOLE_DISK_SLICE); dp = pdev->si_disk; @@ -349,5 +349,5 @@ error = 0; - pdev = dkmodpart(dkmodslice(dev, WHOLE_DISK_SLICE), RAW_PART); + pdev = dkmodslice(dkmodpart(dev, -RAW_PART), WHOLE_DISK_SLICE); dp = pdev->si_disk; if (!dp) @@ -365,5 +365,5 @@ struct disk *dp; - pdev = dkmodpart(dkmodslice(bp->bio_dev, WHOLE_DISK_SLICE), RAW_PART); + pdev = dkmodslice(dkmodpart(bp->bio_dev, -RAW_PART), WHOLE_DISK_SLICE); dp = pdev->si_disk; bp->bio_resid = bp->bio_bcount; @@ -400,5 +400,5 @@ dev_t pdev; - pdev = dkmodpart(dkmodslice(dev, WHOLE_DISK_SLICE), RAW_PART); + pdev = dkmodslice(dkmodpart(dev, -RAW_PART), WHOLE_DISK_SLICE); dp = pdev->si_disk; if (!dp) @@ -416,5 +416,5 @@ dev_t pdev; - pdev = dkmodpart(dkmodslice(dev, WHOLE_DISK_SLICE), RAW_PART); + pdev = dkmodslice(dkmodpart(dev, -RAW_PART), WHOLE_DISK_SLICE); dp = pdev->si_disk; if (!dp) Index: kern/subr_diskmbr.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_diskmbr.c,v retrieving revision 1.54 diff -u -2 -r1.54 subr_diskmbr.c --- kern/subr_diskmbr.c 11 Dec 2001 05:35:43 -0000 1.54 +++ kern/subr_diskmbr.c 9 Jan 2002 10:34:30 -0000 @@ -209,5 +209,5 @@ /* Read master boot record. */ bp = geteblk((int)lp->d_secsize); - bp->b_dev = dkmodpart(dkmodslice(dev, WHOLE_DISK_SLICE), RAW_PART); + bp->b_dev = dkmodslice(dkmodpart(dev, -RAW_PART), WHOLE_DISK_SLICE); bp->b_blkno = mbr_offset; bp->b_bcount = lp->d_secsize; Index: kern/subr_diskslice.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_diskslice.c,v retrieving revision 1.96 diff -u -2 -r1.96 subr_diskslice.c --- kern/subr_diskslice.c 12 Sep 2001 08:37:45 -0000 1.96 +++ kern/subr_diskslice.c 17 Jan 2002 04:19:10 -0000 @@ -68,4 +68,5 @@ static struct disklabel *clone_label __P((struct disklabel *lp)); +static dev_t dkmodminor __P((dev_t dev, int mynor, int slicehint)); static void dsiodone __P((struct bio *bp)); static char *fixlabel __P((char *sname, struct diskslice *sp, @@ -77,4 +78,5 @@ struct disklabel *lp)); static void set_ds_labeldevs __P((dev_t dev, struct diskslices *ssp)); +static void set_ds_labeldevs_unaliased __P((dev_t dev, struct diskslices *ssp)); static void set_ds_wlabel __P((struct diskslices *ssp, int slice, int wlabel)); @@ -123,4 +125,106 @@ /* + * XXX should be able to share more code between disk_dev_synth(), + * disk_clone() and here. + * XXX using dsname() only slightly insulates us from complications. + */ +static dev_t +dkmodminor(dev_t dev, int mynor, int slicehint) +{ + dev_t newdev, newdev_alias; + const char *sname; + char partname[2]; + + newdev = makedev(major(dev), mynor); + if ((dev->si_flags & SI_NAMED) == 0) + return (newdev); /* XXX should panic. */ + if (newdev->si_flags & SI_NAMED) { + /* We have found a device, but may want an alias. */ + if (dkslice(newdev) == WHOLE_DISK_SLICE || + dkslice(newdev) == COMPATIBILITY_SLICE || + dkpart(newdev) != RAW_PART || slicehint) + return (newdev); + + /* We do want an alias. There can be only one. XXX. */ + newdev_alias = LIST_FIRST(&newdev->si_children); + if (newdev_alias != NULL) + return (newdev_alias); + sname = dsname(dev, dkunit(newdev), dkslice(newdev), + dkpart(newdev), partname); + return (make_dev_alias(newdev, "%s%s", sname, partname)); + } + sname = dsname(dev, dkunit(newdev), dkslice(newdev), dkpart(newdev), + partname); + if (dkslice(newdev) == WHOLE_DISK_SLICE && dkpart(newdev) != RAW_PART) { + printf("bad disk name, sname = '%s', partname = '%s'\n", + sname, partname); + Debugger("dkmod"); + } + if (dkslice(newdev) == COMPATIBILITY_SLICE || + dkpart(newdev) != RAW_PART) + return (make_dev(dev->si_devsw, mynor, dev->si_uid, + dev->si_gid, dev->si_mode, "%s%s", sname, partname)); + newdev = make_dev(dev->si_devsw, mynor, dev->si_uid, + dev->si_gid, dev->si_mode, "%s", sname); + if (dkslice(newdev) == WHOLE_DISK_SLICE) + return (newdev); +#if 0 + newdev_alias = make_dev_alias(newdev, "%s%s", sname, partname); +#else + /* + * Don't blindly create the alias. since it is bogus if the slice + * is unlabeled. Passing another hint to tell use when to do this + * would be too messy even for this prototype version. Now there + * are problems getting the alias created if the label is discovered + * later (these are fixed here but not in subr_disk.c). + */ + if (slicehint) + newdev_alias = NULL; + else + newdev_alias = make_dev_alias(newdev, "%s%s", sname, partname); +#endif + return (slicehint ? newdev : newdev_alias); +} + +dev_t +dkmodpart(dev_t dev, int part) +{ + int slicehint; + + /* + * XXX temporary hack: callers pass part == -RAW_PART instead of + * part == RAW_PART as a hint that they want a device whose name + * doesn't contain the partition letter for RAW_PART, if possible. + * This is possible unless the slice is COMPATIBILITY_SLICE. This + * is non-optional if the slice is WHOLE_DISK_SLICE. + */ + if (part == -RAW_PART) { + slicehint = 1; + part = RAW_PART; + } else + slicehint = 0; + return (dkmodminor(dev, (minor(dev) & ~7) | part, slicehint)); +} + +dev_t +dkmodslice(dev_t dev, int slice) +{ + /* + * Here we hint that we don't want a partition letter unless we + * don't already have one, our partition is RAW_PART, and our slice + * is not COMPATIBILITY_SLICE. These cases are distinguished by + * SI_ALIAS being set. The hint is not used in other cases. + */ + return (dkmodminor(dev, (minor(dev) & ~0x1f0000) | (slice << 16), + (dev->si_flags & SI_ALIAS) == 0)); +} + +u_int +dkunit(dev_t dev) +{ + return (((minor(dev) >> 16) & 0x1e0) | ((minor(dev) >> 3) & 0x1f)); +} + +/* * Determine the size of the transfer, and make sure it is * within the boundaries of the partition. Adjust transfer @@ -649,4 +753,5 @@ char *msg; u_char mask; + char *oldsname; int part; char partname[2]; @@ -728,11 +833,29 @@ ) continue; - dev1 = dkmodslice(dkmodpart(dev, RAW_PART), slice); -#if 0 - sname = dsname(dev, unit, slice, RAW_PART, partname); -#else - *partname='\0'; - sname = dev1->si_name; -#endif + dev1 = dkmodslice(dkmodpart(dev, -RAW_PART), slice); + if (dev1->si_devsw == NULL) { + Debugger("dsopen: no devsw (can't happen)"); + dev1->si_devsw = dev->si_devsw; + } + /* + * XXX we want a device name without any partition letter + * in it for use in error messages. dev1->si_name doesn't + * give this for the compatibility slice since there is no + * alias for the raw partiton on that slice. + * + * XXX dsname() is only used for the regression check; + * partname is only used to throw away the partition name + * in the regression check. + */ + if (slice == COMPATIBILITY_SLICE) + sname = dkmodslice(dkmodpart(dev, -RAW_PART), + WHOLE_DISK_SLICE)->si_name; + else + sname = dev1->si_name; + oldsname = dsname(dev, unit, slice, RAW_PART, partname); + if (strcmp(sname, oldsname) != 0) + printf( + "dsopen: dsname = '%s', partname = '%s', sname = '%s'\n", + oldsname, partname, sname); /* * XXX this should probably only be done for the need_init @@ -969,6 +1092,55 @@ struct diskslices *ssp; { + int slice; + + set_ds_labeldevs_unaliased(dev, ssp); + if (ssp->dss_first_bsd_slice == COMPATIBILITY_SLICE) + return; + slice = dkslice(dev); + if (slice == COMPATIBILITY_SLICE) + set_ds_labeldevs_unaliased( + dkmodslice(dev, ssp->dss_first_bsd_slice), ssp); + else if (slice == ssp->dss_first_bsd_slice) + set_ds_labeldevs_unaliased( + dkmodslice(dev, COMPATIBILITY_SLICE), ssp); } +static void +set_ds_labeldevs_unaliased(dev, ssp) + dev_t dev; + struct diskslices *ssp; +{ + struct disklabel *lp; + int part; + struct partition *pp; + int slice; + struct diskslice *sp; + + slice = dkslice(dev); + sp = &ssp->dss_slices[slice]; + if (sp->ds_size == 0) + return; + lp = sp->ds_label; + for (part = 0; part < lp->d_npartitions; part++) { + pp = &lp->d_partitions[part]; + if (pp->p_size == 0) + continue; + /* + * Just dkmod'ing to a partition creates all the necessary + * device entries for it. This is a bit weird, but it + * corresponds to userland stat'ing of nonexistent devfs + * directory entries creating them, and at least we avoid + * creating entries for nonexistent empty devices here. + * + * XXX userland can even exploit bugs to create invalid + * devices, e.g., ones with slice numbers larger than the + * max. Such slice numbers leak into the unit number + * or so-called "spare" bitfields. + */ + if (dev->si_flags & SI_ALIAS) + Debugger("unexpeced dk alias"); + (void)dkmodpart(dev, part); + } +} static void Index: sys/disklabel.h =================================================================== RCS file: /home/ncvs/src/sys/sys/disklabel.h,v retrieving revision 1.63 diff -u -2 -r1.63 disklabel.h --- sys/disklabel.h 4 Nov 2001 09:01:02 -0000 1.63 +++ sys/disklabel.h 17 Jan 2002 03:26:30 -0000 @@ -438,26 +438,8 @@ (((slice) << 16) | (((unit) & 0x1e0) << 16) | \ (((unit) & 0x1f) << 3) | (part)) -static __inline dev_t -dkmodpart(dev_t dev, int part) -{ - return (makedev(major(dev), (minor(dev) & ~7) | part)); -} - -static __inline dev_t -dkmodslice(dev_t dev, int slice) -{ - return (makedev(major(dev), (minor(dev) & ~0x1f0000) | (slice << 16))); -} - #define dkpart(dev) (minor(dev) & 7) #define dkslice(dev) ((minor(dev) >> 16) & 0x1f) #define dksparebits(dev) ((minor(dev) >> 25) & 0x7f) -static __inline u_int -dkunit(dev_t dev) -{ - return (((minor(dev) >> 16) & 0x1e0) | ((minor(dev) >> 3) & 0x1f)); -} - struct bio; struct buf; @@ -470,4 +452,7 @@ struct disklabel *lp)); void disksort __P((struct buf *ap, struct buf *bp)); +dev_t dkmodpart __P((dev_t dev, int part)); +dev_t dkmodslice __P((dev_t dev, int slice)); +u_int dkunit __P((dev_t dev)); char *readdisklabel __P((dev_t dev, struct disklabel *lp)); void bioqdisksort __P((struct bio_queue_head *ap, struct bio *bp)); %%% Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 17 0:48:18 2002 Delivered-To: freebsd-current@freebsd.org Received: from draco.macsch.com (draco.macsch.com [192.73.8.1]) by hub.freebsd.org (Postfix) with ESMTP id E6EE337B425 for ; Thu, 17 Jan 2002 00:48:07 -0800 (PST) Received: from mailmuc.muc.eu.mscsoftware.com (mailmuc.muc.macsch.com [161.34.37.20]) by draco.macsch.com (8.9.3/8.9.3) with ESMTP id AAA21739 for ; Thu, 17 Jan 2002 00:43:33 -0800 (PST) Received: from hunter.muc.macsch.com (hunter.muc.macsch.com [172.17.22.32]) by mailmuc.muc.eu.mscsoftware.com (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g0H8lMv01473; Thu, 17 Jan 2002 09:47:22 +0100 Received: from hunter.muc.macsch.com (localhost.muc.macsch.com [127.0.0.1]) by hunter.muc.macsch.com (8.11.6/8.11.6) with ESMTP id g0H8ldI00847; Thu, 17 Jan 2002 09:47:41 +0100 (CET) (envelope-from Georg.Koltermann@mscsoftware.com) Date: Thu, 17 Jan 2002 09:47:39 +0100 Message-ID: From: Georg-W Koltermann To: freebsd-current@freebsd.org Subject: PANIC when connecting USB device User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) Organization: MSC Software X-Attribution: gwk MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") 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, I frequently see panics when I connect or disconnect USB devices. It seems this is fallout from application software not handling the device correctly, i.e. it only occurs (IIRC) after some application program had problems with the device, an example being gphoto2 which is currently unable to talk to my Powershot G2 camera. Looking at the dump I get the impression that the panic that it shows is not the original problem, it rather looks like a second panic which occured while the kernel tried to sync the disks after a first, invisible panic. -current is from 1/7/2002. The dump shows: (kgdb) core-file vmcore.14 IdlePTD at phsyical address 0x0046f000 initial pcb at physical address 0x0035bc40 panicstr: bremfree: bp 0xd3bf08d0 not locked panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xf fault code = supervisor write, page not present instruction pointer = 0x8:0xc026d340 stack pointer = 0x10:0xe300ac44 frame pointer = 0x10:0xe300ac44 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 22 (irq14: ata0) trap number = 12 panic: page fault syncing disks... panic: bremfree: bp 0xd3bf08d0 not locked Uptime: 1h34m50s pfs_vncache_unload(): 2 entries remaining /dev/vmmon: Module vmmon: unloaded dumping to dev ad0s2b, offset 2000128 dump ata0: resetting devices .. done 1023 1022 1021 [--trimmed--] 2 1 0 --- #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:492 492 if (!dodump) (kgdb) where #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:492 #1 0xc01b4b7b in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:335 #2 0xc01b4fb5 in panic (fmt=0xc02e9f02 "bremfree: bp %p not locked") at /usr/src/sys/kern/kern_shutdown.c:634 #3 0xc01e432d in bremfree (bp=0xd3bf08d0) at /usr/src/sys/kern/vfs_bio.c:545 #4 0xc01e58ff in vfs_bio_awrite (bp=0xd3bf08d0) at /usr/src/sys/kern/vfs_bio.c:1534 #5 0xc0197954 in spec_fsync (ap=0xe300aaec) at /usr/src/sys/fs/specfs/spec_vnops.c:404 #6 0xc019753d in spec_vnoperate (ap=0xe300aaec) at /usr/src/sys/fs/specfs/spec_vnops.c:119 #7 0xc0272e35 in ffs_sync (mp=0xc7550e00, waitfor=2, cred=0xc2069b00, td=0xc0397184) at vnode_if.h:441 #8 0xc01f09dd in sync (td=0xc0397184, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:657 #9 0xc01b47c4 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:244 #10 0xc01b4fb5 in panic (fmt=0xc0308f7e "%s") at /usr/src/sys/kern/kern_shutdown.c:634 #11 0xc02b2c0f in trap_fatal (frame=0xe300ac04, eva=15) at /usr/src/sys/i386/i386/trap.c:842 #12 0xc02b2951 in trap_pfault (frame=0xe300ac04, usermode=0, eva=15) at /usr/src/sys/i386/i386/trap.c:756 #13 0xc02b24bb in trap (frame={tf_fs = 24, tf_es = -486539248, ---Type to continue, or q to quit--- tf_ds = -1070268400, tf_edi = 0, tf_esi = -948659264, tf_ebp = -486495164, tf_isp = -486495184, tf_ebx = 0, tf_edx = -1, tf_ecx = -946040064, tf_eax = -951159948, tf_trapno = 12, tf_err = 2, tf_eip = -1071197376, tf_cs = 8, tf_eflags = 66182, tf_esp = -486495136, tf_ss = -1071189245}) at /usr/src/sys/i386/i386/trap.c:426 #14 0xc026d340 in free_inodedep (inodedep=0xc79c9300) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2170 #15 0xc026f303 in handle_written_inodeblock (inodedep=0xc79c9300, bp=0xd3c1dc8c) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3796 #16 0xc026ebfa in softdep_disk_write_complete (bp=0xd3c1dc8c) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3442 #17 0xc01e6f91 in bufdone (bp=0xd3c1dc8c) at /usr/src/sys/sys/buf.h:452 #18 0xc01e6e6e in bufdonebio (bp=0xd3c1dc8c) at /usr/src/sys/kern/vfs_bio.c:2744 #19 0xc0147881 in ad_interrupt (request=0xc7a550c0) at /usr/src/sys/sys/bio.h:107 #20 0xc013d476 in ata_intr (data=0xc73bd380) at /usr/src/sys/dev/ata/ata-all.c:587 #21 0xc01a8432 in ithread_loop (arg=0xc73bd300) at /usr/src/sys/kern/kern_intr.c:533 #22 0xc01a78d8 in fork_exit (callout=0xc01a8304 , arg=0xc73bd300, frame=0xe300ad48) at /usr/src/sys/kern/kern_fork.c:783 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 17 1:18:19 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 3C22D37B417 for ; Thu, 17 Jan 2002 01:18:10 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g0H9HYV40628; Thu, 17 Jan 2002 11:17:34 +0200 (EET) (envelope-from ru) Date: Thu, 17 Jan 2002 11:17:34 +0200 From: Ruslan Ermilov To: Terry Lambert Cc: Timothy Aslat , freebsd-current@FreeBSD.ORG Subject: Re: Downgrading Message-ID: <20020117111734.H27310@sunbay.com> References: <20020117104901.24d09d36.tim@spyderweb.com.au> <3C462FFF.22701A04@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C462FFF.22701A04@mindspring.com> User-Agent: Mutt/1.3.23i 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, Jan 16, 2002 at 05:59:27PM -0800, Terry Lambert wrote: > Timothy Aslat wrote: > > > > Hi All, > > > > Quick question. Where would I find information on downgrading a > > -CURRENT to a -STABLE or -RELEASE? > > > > I'm just trying to avoid doing a reinstall and re-setup from scratch. > > THis belongs on -questions. > > In general, you can boot from a CDROM of the version you > want to downgrade to, choose "upgrade" from the sysinstall > menu, and then proceed to "upgrade". > > It will not install your sources for you (you will have to > do that manually). > > You may also have a number of issues with configuration file > data, though it should leave libraries and other things intact. > > The only other things that should be able to go wrong are any > libraries in developement that have not had their version numbers > bumped for interface changes, and the boot blocks, which you > can deal with by manually reinstalling via the "holographic > shell" via a manual run of "disklabel -B" using the installed > files by specifying the path to them, prior to the reboot. > > FWIW, I have, in practice, "upgraded" a large number of -current > machines from an October 2000 snapshot to a 4.3-RELEASE CDROM > version, with no problem, if locally booted, and with some > effort when doing the upgrade from an NFS mounted CDROM over > the network (mostly, SSH problems with the pam.conf files > when the SSH changed to need explicit pam.conf entries, and not > using the generic entries if the SSH ones were missing, as the > PAM design documents with which SSH does not comply indicate > you should do...). You also have to run the sysinstall from > the CDROM, which is not on the CDROM itself, and is hidden in > the boot images -- and must be named "sysinstall", because it's > a crunched binary. The only other issue is that you must > manually copy ove /dev/MAKEDEV and /dev/MAKEDEV.local, and run > "sh MAKEDEV all" to get the /dev/random set up correctly, but > all this can be done prior to the reboot. > FWIW, modern -CURRENT's should be able to downgrade to -STABLE without problems. If it's broken, please let me know, and I'll fix it. I mean "if it WILL be broken", as tonight's -CURRENT has successfully built -STABLE. Didn't test the `installworld' part, but I don't believe there are any problems with it. Cheers, -- Ruslan Ermilov Oracle Developer/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 Thu Jan 17 1:28:24 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 8504B37B402; Thu, 17 Jan 2002 01:28:19 -0800 (PST) Received: from pool0014.cvx22-bradley.dialup.earthlink.net ([209.179.198.14] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16R8qI-0002tq-00; Thu, 17 Jan 2002 01:28:18 -0800 Message-ID: <3C4698EC.8FF8BB7D@mindspring.com> Date: Thu, 17 Jan 2002 01:27:08 -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: Ruslan Ermilov Cc: Timothy Aslat , freebsd-current@FreeBSD.ORG Subject: Re: Downgrading References: <20020117104901.24d09d36.tim@spyderweb.com.au> <3C462FFF.22701A04@mindspring.com> <20020117111734.H27310@sunbay.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 Ruslan Ermilov wrote: > FWIW, modern -CURRENT's should be able to downgrade to -STABLE > without problems. If it's broken, please let me know, and I'll > fix it. I mean "if it WILL be broken", as tonight's -CURRENT > has successfully built -STABLE. Didn't test the `installworld' > part, but I don't believe there are any problems with it. Config file changes are still a problem: they won't be reflected back, due to version changes (if any). There were a number of problems with /etc/pam.conf compatability and OpenSSH v1 vs. v2 and already generated certs needing to be regenerated as a result, last time I went back to 4.x from a 5.x. The MAKEDEV problem is more pronounced moving from -current, since -current has devfs. My recommendation would be *against* using "makeinstallworld", since with a CDROM approach, the devfs isn't mounted on /dev, so the devices get made correctly (devfs would also throw a wrench into the NFS mounted CDROM approach I talked about before; sorry). As I said before about boot blocks: all bets are off: I have no idea whether or not they are capable of booting older versions of the code correctly any more; there have been some recent problems because of some changes, and because of a bzero that Alfred was rumored to have lost from Jon Mini and James Harris' contributions toward an updated FORTH-based "nextboot"... ;^). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 17 1:59:30 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 95DBD37B402 for ; Thu, 17 Jan 2002 01:59:20 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g0H9wjm47072; Thu, 17 Jan 2002 11:58:45 +0200 (EET) (envelope-from ru) Date: Thu, 17 Jan 2002 11:58:45 +0200 From: Ruslan Ermilov To: Terry Lambert Cc: Timothy Aslat , freebsd-current@FreeBSD.ORG Subject: Re: Downgrading Message-ID: <20020117115845.K27310@sunbay.com> References: <20020117104901.24d09d36.tim@spyderweb.com.au> <3C462FFF.22701A04@mindspring.com> <20020117111734.H27310@sunbay.com> <3C4698EC.8FF8BB7D@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C4698EC.8FF8BB7D@mindspring.com> User-Agent: Mutt/1.3.23i 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, Jan 17, 2002 at 01:27:08AM -0800, Terry Lambert wrote: > Ruslan Ermilov wrote: > > FWIW, modern -CURRENT's should be able to downgrade to -STABLE > > without problems. If it's broken, please let me know, and I'll > > fix it. I mean "if it WILL be broken", as tonight's -CURRENT > > has successfully built -STABLE. Didn't test the `installworld' > > part, but I don't believe there are any problems with it. > > Config file changes are still a problem: they won't be > reflected back, due to version changes (if any). There > were a number of problems with /etc/pam.conf compatability > and OpenSSH v1 vs. v2 and already generated certs needing > to be regenerated as a result, last time I went back to 4.x > from a 5.x. > Um, what do you mean by "config file changes"? Of course you can't use stock 5.0-CURRENT config files, it's clear. As for config(8), it's in bootstrap-tools, and shouldn't be a problem. Buildkernel works fine here. > The MAKEDEV problem is more pronounced moving from -current, > since -current has devfs. > > My recommendation would be *against* using "makeinstallworld", > since with a CDROM approach, the devfs isn't mounted on /dev, > so the devices get made correctly (devfs would also throw a > wrench into the NFS mounted CDROM approach I talked about > before; sorry). > I avoid these problems by installing with DESTDIR=/STABLE. :-) > As I said before about boot blocks: all bets are off: I have > no idea whether or not they are capable of booting older > versions of the code correctly any more; there have been > some recent problems because of some changes, and because of > a bzero that Alfred was rumored to have lost from Jon Mini > and James Harris' contributions toward an updated FORTH-based > "nextboot"... ;^). > Not sure about this one. Perhaps the following would be safe: 1) You copy your /, /var, and /usr holding disks. 2) You mount copies to /mnt. 3) You ``installworld'' and ``installkernel'' with DESTDIR=/mnt 4) You install 4.x bootblocks (from /mnt/boot) to /mnt Cheers, -- Ruslan Ermilov Oracle Developer/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 Thu Jan 17 2:27:55 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 0C45B37B416; Thu, 17 Jan 2002 02:27:52 -0800 (PST) Received: from pool0014.cvx22-bradley.dialup.earthlink.net ([209.179.198.14] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16R9lu-0003wp-00; Thu, 17 Jan 2002 02:27:50 -0800 Message-ID: <3C46A6D8.57B453A2@mindspring.com> Date: Thu, 17 Jan 2002 02:26:32 -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: Ruslan Ermilov Cc: Timothy Aslat , freebsd-current@FreeBSD.ORG Subject: Re: Downgrading References: <20020117104901.24d09d36.tim@spyderweb.com.au> <3C462FFF.22701A04@mindspring.com> <20020117111734.H27310@sunbay.com> <3C4698EC.8FF8BB7D@mindspring.com> <20020117115845.K27310@sunbay.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 Ruslan Ermilov wrote: > Um, what do you mean by "config file changes"? Of course > you can't use stock 5.0-CURRENT config files, it's clear. > As for config(8), it's in bootstrap-tools, and shouldn't > be a problem. Buildkernel works fine here. Configuration files, like /etc/pam.conf. For example, if you move from a version that has no "ssh" lines to one that has (requires) them, ssh will suddenly stop working. If you've generated machine key files (happens, the first time you boot, from /etc/rc, if ssh is enabled), then you change key generation versions, you have to manually delete the key files, or ssh quits working. If you have a /dev directory that was created with device nodes, and you change between versions of FreeBSD that have different major/minor for /dev/random, ssh quits working and complains about a library not containing crypto code, even though that's not really the problem. (OK, you could portray this more as "ssh sucks", but the principle works with other programs). > > The MAKEDEV problem is more pronounced moving from -current, > > since -current has devfs. > > I avoid these problems by installing with DESTDIR=/STABLE. :-) That works, if you have a seperate parittion for it, and can mount it up. It gets ugly at boot time, if you aren't a FORTH hacker, though... 8^p [ ... evil boot blocks ... ] > Perhaps the following would be safe: > > 1) You copy your /, /var, and /usr holding disks. > 2) You mount copies to /mnt. > 3) You ``installworld'' and ``installkernel'' with DESTDIR=/mnt > 4) You install 4.x bootblocks (from /mnt/boot) to /mnt Yes, this would work, assuming you had different DOS partitions for /mnt and /, so you could have seperate space for the disklabel and boot blocks. I've used something similar to this myself. There's a lot of work that could be done in this area to make FreeBSD more friendly to the casual developer who wanted to spend time pounding code rather than learning the intricacies of "how to do `magic' disk layout", and was willing to build word and install from sources. It's actually a lot easier to just do it from CDROM, if you can trust the boot blocks (big "if", until someone drags their PC up on the altar and tries it... 8^)). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 17 3:17: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 07CAD37B41A for ; Thu, 17 Jan 2002 03:17:34 -0800 (PST) Received: (qmail 10560 invoked from network); 17 Jan 2002 11:17:33 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 17 Jan 2002 11:17:33 -0000 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: Thu, 17 Jan 2002 03:16:49 -0800 (PST) From: John Baldwin To: Mike Brancato Subject: RE: boot floppy problems... 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 17-Jan-02 Mike Brancato wrote: > Just leting you guys know that the Jan 15th and Jan 16th boot floppies > aren't working. the Jan 13th snaps are though. How do they not work? We can't fix anything if you don't tell us what is wrong. :) > mike -- 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 Thu Jan 17 6: 1:52 2002 Delivered-To: freebsd-current@freebsd.org Received: from femail15.sdc1.sfba.home.com (femail15.sdc1.sfba.home.com [24.0.95.142]) by hub.freebsd.org (Postfix) with ESMTP id 40B7437B417; Thu, 17 Jan 2002 06:01:50 -0800 (PST) Received: from dosmonos ([24.249.124.238]) by femail15.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20020117140149.XZUU22207.femail15.sdc1.sfba.home.com@dosmonos>; Thu, 17 Jan 2002 06:01:49 -0800 Date: Thu, 17 Jan 2002 09:00:34 -0500 (EST) From: Mike Brancato X-Sender: funnyguy@dosmonos To: John Baldwin Cc: freebsd-current@FreeBSD.org Subject: RE: boot floppy problems... 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 oh, well. They say something along the lines of "Disk error: lba is 0x9 (should be 0x10)" or similar. then it trys to boot the kernel twice using the loader, but fails with the path 0:fd(0,a)/kernel i tried it in vmware with the same results comming right from the image. mike On Thu, 17 Jan 2002, John Baldwin wrote: > > On 17-Jan-02 Mike Brancato wrote: > > Just leting you guys know that the Jan 15th and Jan 16th boot floppies > > aren't working. the Jan 13th snaps are though. > > How do they not work? We can't fix anything if you don't tell us what is > wrong. :) > > > mike > > -- > > 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 Thu Jan 17 10:20:55 2002 Delivered-To: freebsd-current@freebsd.org Received: from hanmail.net (catv-kwangjoo-210205028145.usr2.hananet.net [210.205.28.145]) by hub.freebsd.org (Postfix) with SMTP id D4D0637B41A for ; Thu, 17 Jan 2002 10:19:50 -0800 (PST) Reply-To: p-2580@hanmail.net From: ¿£µå¶óÀÎ To: <29sexy@FreeBSD.ORG> Subject: ¼ºÀεéÀ» À§ÇÑ ¸®ºä...(¹Ì¼º³âÀÚŬ¸¯±ÝÁö!!)[±¤°í] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="= Multipart Boundary 0118020321" Date: Fri, 18 Jan 2002 03:21:02 +0900 X-User: 2.52-knloipos-lsmmju-Iinoo Message-Id: <20020117181950.D4D0637B41A@hub.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 This is a multipart MIME message. --= Multipart Boundary 0118020321 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit

±ÍÇÏÀÇ ¸ÞÀÏÁÖ¼Ò´Â À¥¼­ÇÎÁß,

¿¡¼­ ¾Ë°Ô µÈ°ÍÀ̸ç,

E-Mail ÁÖ¼Ò ¿Ü¿¡, ´Ù¸¥ Á¤º¸´Â °®°í ÀÖÁö ¾Ê½À´Ï´Ù.

Á¤ÅëºÎ ±Ç°í»çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡ [±¤°í]¶ó°í Ç¥±âÇÑ ¸ÞÀÏÀÔ´Ï´Ù. ¿øÄ¡ ¾ÊÀ¸¸é ¼ö½Å°ÅºÎ¸¦ ´­·¯ÁÖ¼¼¿ä

--= Multipart Boundary 0118020321 Content-Type: application/octet-stream; name="speed2.htm" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="speed2.htm" PGh0bWw+Cgo8aGVhZD4KPHRpdGxlPrHNx8/Ax8DMuN7Az8HWvNK0wrrSuf3A +8C4t87D67Xmx9Gw1L7GtM+457Ciwb6758DMxq6/obD4sLO1x77uwfi43sDP wda80sDUtM+02TwvdGl0bGU+CjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29u dGVudD0iTmFtbyBXZWJFZGl0b3IgdjQuMCI+CjxzY3JpcHQgbGFuZ3VhZ2U9 J0phdmFzY3JpcHQnPgp2YXIgZXhpdD10cnVlOwpmdW5jdGlvbiBieWUoKQp7 CmlmIChleGl0KQp3aW5kb3cub3BlbignaHR0cDovL2xvdmVrb3JlYS50di9s aW5rLmpzcD9pZD1tYWluJywnX2JsYW5rJywnd2lkdGg9ODAwLGhlaWdodD02 MDAsc3RhdHVzPTEsbG9jYXRpb249MSxtZW51YmFyPTEsdG9vbGJhcj0xLHNj cm9sbGJhcnM9MScpOwp9Cjwvc2NyaXB0Pgo8L2hlYWQ+Cjxib2R5IG9udW5s b2FkPSJieWUoKTsiIGJnY29sb3I9ImJsYWNrIj4KPFAgYWxpZ249Y2VudGVy PjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDlwdCI+PEZPTlQgY29sb3I9cmVk PjxCPrHNx8/AxyDAzLjewM8gwda80rTCIAq60rn9wPvAuLfOIMPrtebH0bDU IL7GtM+45yCwosG+ILvnwMzGrr+hILD4sLO1x77uwfgguN7AzyDB1rzSwNS0 z7TZPC9CPjwvRk9OVD48L1NQQU4+IAo8VEFCTEUgYm9yZGVyQ29sb3I9I2Zm Y2MzMyBoZWlnaHQ9Mjg1IGNlbGxTcGFjaW5nPTAgY2VsbFBhZGRpbmc9MCB3 aWR0aD02NjkgCmFsaWduPWNlbnRlciBiZ0NvbG9yPSNmZmZmZmYgYm9yZGVy PTI+CjxUQk9EWT4KPFRSIGhlaWdodD0yODU+CjxURCB3aWR0aD02NjMgYmdD b2xvcj0jMzM5OTk5IGNvbFNwYW49MyBoZWlnaHQ9MTE3Pgo8UCBzdHlsZT0i TUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IExJTkUtSEVJ R0hUOiAxMDAlIiAKYWxpZ249Y2VudGVyPjxCPjxGT05UIGNvbG9yPWJsdWU+ vLrAzrXpILSpsbizqiDH0bn4wuvAuiCwocDUIMfPtMIgvLrAzrvnwMzGriE8 L0ZPTlQ+PC9CPjwvUD4KPFAgc3R5bGU9Ik1BUkdJTi1UT1A6IDBweDsgTUFS R0lOLUJPVFRPTTogMHB4OyBMSU5FLUhFSUdIVDogMTAwJSIgCmFsaWduPWNl bnRlcj48U1BBTiBzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogYmxhY2siPjxG T05UIGNvbG9yPXdoaXRlPjxCPrjwtee758DMxq4gCry6wM7AzsH1ILLAISDH yr/kx9W0z7TZLiC5zLy6s+Igw+LA1LHdwfY8L0I+PC9GT05UPjwvU1BBTj48 L1A+CjxQIHN0eWxlPSJNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006 IDBweDsgTElORS1IRUlHSFQ6IDEwMCUiIAphbGlnbj1jZW50ZXI+PEI+PEZP TlQgY29sb3I9Ymx1ZT4mbmJzcDs8L0ZPTlQ+PC9CPjxhIGhyZWY9Imh0dHA6 Ly93d3cuc3NleHkubmV0L3BhcnRuZXIvY2hlY2sucGhwP3NzZXh5X2NvZGU9 aW5kZXgzXzAxIiB0YXJnZXQ9Il9ibGFuayI+PElNRyAKc3JjPSJodHRwOi8v d3d3LnNleHlzZXhrb3JlYS5jb20vcGFydG5lci9iYW5uZXIvMy5naWYiIGJv cmRlcj0wPjwvYT4gJm5ic3A7PGEgaHJlZj0iaHR0cDovL3NleHlhZG9uZy5j b20vaW5kZXgucGhwP1BhcnRuZXJJZD1pbmRleCIgdGFyZ2V0PSJfYmxhbmsi PjxJTUcgCmhlaWdodD03MSBzcmM9Imh0dHA6Ly9zZXh5YWRvbmcuY29tL2Jh bm5lci9iYW5uZXI5Ni5naWYiIHdpZHRoPTEzMz48L2E+IAombmJzcDs8L1A+ PC9URD48L1RSPgo8VFIgaGVpZ2h0PTM1Pgo8VEQgd2lkdGg9NjYzIGJnQ29s b3I9c2lsdmVyIGNvbFNwYW49Mz4KPFA+PFNQQU4gc3R5bGU9IkZPTlQtU0la RTogOXB0Ij6xzcfPwMcgRS1tYWlswda80rTCILDUvcPGx8DMs6ogtb/Io8i4 te7AxyCw+LCztcgguN7Az8HWvNK4piC89sH9x9EgsM3AuLfOILHixbggCrCz wM7BpLq4tMIgvvjAvcC7IL7Lt8EgteW4rrjnILz2vcWwxbrOuKYgv/jHz73H ILDmv+wgwKfAxyC89r3FsMW6zrimIMWsuK/Hz7+pIMHWvcOx5iC52bb4tM+0 2S4gCiZuYnNwO7Cou+fH1bTPtNkuPC9TUEFOPjwvUD48L1REPjwvVFI+CjxU UiBoZWlnaHQ9MzU+CjxURCB3aWR0aD02NjMgYmdDb2xvcj1ibGFjayBjb2xT cGFuPTM+CjxQIGFsaWduPWNlbnRlcj48YSBocmVmPSJodHRwOi8vMjRzZXh0 di5jb20vbGluay5qc3A/aWQ9aW5kZXgiIHRhcmdldD0iX2JsYW5rIj48SU1H IApzcmM9Imh0dHA6Ly93d3cuc2V4eXNleGtvcmVhLmNvbS9wYXJ0bmVyL2Jh bm5lci80LmdpZiIgYm9yZGVyPTA+PC9hPiZuYnNwOyAKPC9QPjwvVEQ+PC9U Uj4KPFRSIGhlaWdodD0zNT4KPFREIHdpZHRoPTY2MyBiZ0NvbG9yPXJlZCBj b2xTcGFuPTM+CjxQIHN0eWxlPSJNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1C T1RUT006IDBweDsgTElORS1IRUlHSFQ6IDEwMCUiIAphbGlnbj1jZW50ZXI+ PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+PEZPTlQgY29sb3I9d2hp dGU+or4gW7GksO1dIDEwMCUgv8/A/Lmrt+EgCiZsdDvD5rDdJmd0OyC8usDO u+fAzMauISEhIL/Ax8IgJmd0O6K+PC9GT05UPjwvU1BBTj48L1A+CjxQIHN0 eWxlPSJNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweDsgTElO RS1IRUlHSFQ6IDEwMCUiIAphbGlnbj1jZW50ZXI+PFNQQU4gc3R5bGU9IkZP TlQtU0laRTogMTBwdCI+PEZPTlQgY29sb3I9d2hpdGU+or4gvLrAzsD8v+sg uau34SC758DMxq4gvsizuyAKor48L0ZPTlQ+PC9TUEFOPjwvUD4KPFAgc3R5 bGU9Ik1BUkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBMSU5F LUhFSUdIVDogMTAwJSIgCmFsaWduPWNlbnRlcj48U1BBTiBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0Ij48Rk9OVCBjb2xvcj13aGl0ZT6iviC8usDOtb+/tbvz IC0mZ3Q7ILy6wM6/6yAKtb+/tbvzICi8scXDwMcgxvjAuiDA2sCvKSAmZ3Q7 or48L0ZPTlQ+PC9TUEFOPjwvUD4KPFAgc3R5bGU9Ik1BUkdJTi1UT1A6IDBw eDsgTUFSR0lOLUJPVFRPTTogMHB4OyBMSU5FLUhFSUdIVDogMTAwJSIgCmFs aWduPWNlbnRlcj48YSBocmVmPSJodHRwOi8vc2V4eWFkb25nLmNvbS9pbmRl eC5waHA/UGFydG5lcklkPWluZGV4IiB0YXJnZXQ9Il9ibGFuayI+PElNRyAK c3JjPSJodHRwOi8vc2V4eWFkb25nLmNvbS9iYW5uZXIvYmFubmVyNTguZ2lm Ij48L2E+PC9QPgo8UCBzdHlsZT0iTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4t Qk9UVE9NOiAwcHg7IExJTkUtSEVJR0hUOiAxMDAlIiAKYWxpZ249Y2VudGVy PjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPjxGT05UIGNvbG9yPXdo aXRlPqK+ILy6wM7Hw7ehvawgLSZndDsgvLrAzr/rIL7fIArHw7ehvawgtb+/ tbvzIKK+PC9GT05UPjwvU1BBTj48L1A+CjxQIHN0eWxlPSJNQVJHSU4tVE9Q OiAwcHg7IE1BUkdJTi1CT1RUT006IDBweDsgTElORS1IRUlHSFQ6IDEwMCUi IAphbGlnbj1jZW50ZXI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+ PEZPTlQgY29sb3I9d2hpdGU+or4gvLrAzrC2t6+4riAtJmd0OyC8usDOIL7f IArG98XkICZndDsgor48L0ZPTlQ+PC9TUEFOPjwvUD48L1REPjwvVFI+CjxU UiBoZWlnaHQ9MzU+CjxURCB3aWR0aD02NjMgYmdDb2xvcj0jZmZjY2NjIGNv bFNwYW49Mz4KPFAgYWxpZ249Y2VudGVyPjxCPjxGT05UIGNvbG9yPWJsdWU+ sbmzuyC8usDOv6m8uiDIuL/4sKHA1CAxwKcgCrvnwMzGriEhPC9GT05UPjwv Qj48L1A+PC9URD48L1RSPgo8VFIgaGVpZ2h0PTM1Pgo8VEQgd2lkdGg9NjYz IGJnQ29sb3I9YmxhY2sgY29sU3Bhbj0zPgo8UCBhbGlnbj1jZW50ZXI+Jm5i c3A7PGEgaHJlZj0iaHR0cDovL3d3dy5tb2xsY2EuY28ua3IvcGFydG5lci9s aW5rLmFzcD9wYXJ0bmVyPW1haW4iIHRhcmdldD0iX2JsYW5rIj48SU1HIGhl aWdodD01NSAKc3JjPSJodHRwOi8vYmFubmVyLm1vbGNhbGl2ZS5qcC9iYW5u ZXIvZGJhbm5lci8xNy5naWYiIHdpZHRoPTM2NCAKYm9yZGVyPTA+PC9hPjwv UD48L1REPjwvVFI+CjxUUiBoZWlnaHQ9MzU+CjxURCB3aWR0aD02NjMgYmdD b2xvcj1yZWQgY29sU3Bhbj0zPgo8UCBhbGlnbj1jZW50ZXI+Jm5ic3A7PFNQ QU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+PEZPTlQgY29sb3I9Ymx1ZT4m bmJzcDs8SU1HIGhlaWdodD0wIApzcmM9Imh0dHA6Ly93d3cub2ttb2xjYXBh cnRuZXIuY29tL3Bwc3RhdGlzdGljcy9wcF9iYW5uZXJfc2hvd19pbWFnZS5h c3A/YWZmaWxpYXRlX2lkPXB5ajIwMjMiIAp3aWR0aD0wIGJvcmRlcj0wIG5v c2F2ZT48QSB0YXJnZXQ9Il9ibGFuayIgaHJlZj0iaHR0cDovL3d3dy5tb2xs Y2EuY28ua3IvcGFydG5lci9saW5rLmFzcD9wYXJ0bmVyPW1haW4iPjxJTUcg CmhlaWdodD02MCBhbHQ9Iry6wM4gwPy/6yC49MSrIL6+uK7B7iIgCnNyYz0i aHR0cDovL3d3dy5va21vbGNhLmNvbS9jb3Vyc2UvYmFubmVyX2ltZy9mMTgw MDYwXzEuZ2lmIiB3aWR0aD0xODAgCmJvcmRlcj0wPjwvRk9OVD48L0E+PC9T UEFOPjwvUD4KPFAgYWxpZ249Y2VudGVyPjxhIGhyZWY9Imh0dHA6Ly9wYXJ0 bmVyLjY5c2V4dWFsLmNvbS9wYXJ0bmVyLnBocD9yZWNvbV9pZD1pbmRleCIg dGFyZ2V0PSJfYmxhbmsiPjxJTUcgCnNyYz0iaHR0cDovL2Jhbm5lci42OXNl eHVhbC5jb20vYmFubmVyX2ltZy9iYW5uZXJfODQuZ2lmIiAKYm9yZGVyPTA+ PC9hPjwvUD48L1REPjwvVFI+CjxUUiBoZWlnaHQ9MzA+CjxURCB3aWR0aD0x OTUgYmdDb2xvcj0jNjY2NjY2PjwvVEQ+CjxURCB3aWR0aD0xNzA+CjxQIGFs aWduPWNlbnRlcj48U1BBTiAKc3R5bGU9IkZPTlQtU0laRTogMTZwdCI+PEI+ PGEgaHJlZj0iaHR0cDovL2xvdmVrb3JlYS50di9saW5rLmpzcD9pZD1tYWlu IiB0YXJnZXQ9Il9ibGFuayI+PEZPTlQgY29sb3I9cmVkPiEhsbggsOYgsKEg seIhITwvRk9OVD48L2E+PC9CPjwvU1BBTj48L1A+PC9URD4KPFREIHdpZHRo PTI5NCBiZ0NvbG9yPSM2NjY2NjY+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJM RT4KPFAgc3R5bGU9Ik1BUkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTog MHB4OyBMSU5FLUhFSUdIVDogMTAwJSIgCmFsaWduPWNlbnRlcj48U1BBTiBz dHlsZT0iRk9OVC1TSVpFOiA5cHQiPjxGT05UIGNvbG9yPXdoaXRlPrHNx8/A xyBFLW1haWzB1rzStMIgsNS9w8bHwMyzqiAKtb/Io8i4te7AxyCw+LCztcgg uN7Az8HWvNK4piC89sH9x9EgsM3AuLfOILHixbggsLM8L0ZPTlQ+PC9TUEFO PjwvUD4KPC9ib2R5PgoKPC9odG1sPgoK --= Multipart Boundary 0118020321-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 17 11:40:17 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 D255C37B404; Thu, 17 Jan 2002 11:40:10 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 17 Jan 2002 19:40:09 +0000 (GMT) To: Mike Brancato Cc: John Baldwin , freebsd-current@FreeBSD.org Subject: Re: boot floppy problems... In-Reply-To: Your message of "Thu, 17 Jan 2002 09:00:34 EST." Date: Thu, 17 Jan 2002 19:40:09 +0000 From: Ian Dowse Message-ID: <200201171940.aa68346@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 In message , Mike Brancato wr ites: >oh, well. They say something along the lines of >"Disk error: lba is 0x9 (should be 0x10)" >or similar. then it trys to boot the kernel twice using the loader, but >fails with the path 0:fd(0,a)/kernel Hmm, the error is actually "Disk error 0x9 (lba=0x10)". I think this is my fault. Error 9 is "data boundary error (attempted DMA across 64K boundary or >80h sectors)", so by changing the buffers to being static in revision 1.35 of boot2.c, I broke the guarantee that single transfers don't cross a 64k boundary, which is important for floppies :-( I'll fix this shortly. Thanks for pointing out the problem! Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 17 11:50: 7 2002 Delivered-To: freebsd-current@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 7C75337B402 for ; Thu, 17 Jan 2002 11:49:56 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id UAA28137 for freebsd-current@freebsd.org; Thu, 17 Jan 2002 20:49:55 +0100 (CET) Received: (from j@localhost) by uriah.heep.sax.de (8.11.6/8.11.6) id g0HJn4l28015; Thu, 17 Jan 2002 20:49:04 +0100 (MET) (envelope-from j) Date: Thu, 17 Jan 2002 20:49:04 +0100 (MET) Message-Id: <200201171949.g0HJn4l28015@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 1.0b.1 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: From: j@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: boot floppy problems... X-Original-Newsgroups: local.freebsd.current To: freebsd-current@freebsd.org 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 Mike Brancato wrote: > oh, well. They say something along the lines of > "Disk error: lba is 0x9 (should be 0x10)" > or similar. then it trys to boot the kernel twice using the loader, > but fails with the path 0:fd(0,a)/kernel I have to confirm this, for a self-made "make release" of yesterday. Using the primary bootstrap of the harddisk, and loading fd(0,a)/boot/loader gets it running, so /boot/loader itself is OK. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 17 14: 2:47 2002 Delivered-To: freebsd-current@freebsd.org Received: from ns.plaut.de (ns.plaut.de [194.99.75.166]) by hub.freebsd.org (Postfix) with ESMTP id 2B45D37B404 for ; Thu, 17 Jan 2002 14:02:41 -0800 (PST) Received: (from uucp@localhost) by ns.plaut.de (8.9.3/8.9.3) with UUCP id XAA29131; Thu, 17 Jan 2002 23:01:23 +0100 (CET) (envelope-from root@nihil.plaut.de) Received: from localhost (root@localhost) by nihil.plaut.de (8.11.3/8.8.8) with ESMTP id g0HM0xJ00552; Thu, 17 Jan 2002 23:00:59 +0100 (CET) (envelope-from root@nihil) Date: Thu, 17 Jan 2002 23:00:59 +0100 (CET) From: Michael Reifenberger To: Bruce Evans Cc: FreeBSD-Current Subject: Re: panic during fdisk'ing a md(4) device In-Reply-To: <20020117175846.H491-100000@gamplex.bde.org> Message-ID: <20020117225217.O521-101000@nihil> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-910510754-1011304859=:521" 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-910510754-1011304859=:521 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 17 Jan 2002, Bruce Evans wrote: ... > Oops. There should be no alias for md10c. Try this version. It fixes > the "may want an alias case" in dkmodminor() and moves all the dk inlines > to subr_diskslice.c. This patch works better. This brings us back to the original problem :-) Now it doesn't panic during fsck immediately, it panics after unconfiguring the md(4) device (which leaves the /dev/md11* devices in place instead removing them) reconfiguring and then doing a new `disklabel ...` which tries to do a (still existing) new 'make_dev("md11s1")'.... See the attached backroot.sh. Bye! ---- Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS --0-910510754-1011304859=:521 Content-Type: APPLICATION/x-sh; name="backroot.sh" Content-Transfer-Encoding: BASE64 Content-ID: <20020117230059.B521@nihil> Content-Description: Content-Disposition: attachment; filename="backroot.sh" IyFiaW4vc2gKCmJsb2NrX3NpemU9NTEyCmJsb2Nrcz0kKCgxMjAgKiAxMDI0 ICogMTAyNCAvICRibG9ja19zaXplKSkKaGVhZHM9MTYKc2VjdG9ycz02Mwpj eWxfc2l6ZT0kKCgkaGVhZHMgKiAkc2VjdG9ycykpOwpjeWxpbmRlcnM9JCgo JGJsb2NrcyAvICRjeWxfc2l6ZSArIDIpKQplY2hvICIkY3lsX3NpemUgJGJs b2NrcyAkY3lsaW5kZXJzIgoKZGQgaWY9L2Rldi96ZXJvIG9mPXJvb3QuaW1h Z2UgXAoJYnM9JGJsb2NrX3NpemUgY291bnQ9JCgoJGN5bF9zaXplICogJGN5 bGluZGVycykpCm1kY29uZmlnIC1kIC11IDExIAptZGNvbmZpZyAtYSAtdCB2 bm9kZSAtZiByb290LmltYWdlIC11IDExCmZkaXNrIC1mIC0gLWlCdiAvZGV2 L21kMTEgPDxFT0YxCmcgYyRjeWxpbmRlcnMgaCRoZWFkcyBzJHNlY3RvcnMK cCAxIDE2NSAkc2VjdG9ycyAkKCgkY3lsX3NpemUgKiAkY3lsaW5kZXJzKSkK YSAxCkVPRjEKZGlza2xhYmVsIC1yIC13IG1kMTFzMSBhdXRvCgptZGNvbmZp ZyAtZCAtdSAxMSAKbWRjb25maWcgLWEgLXQgdm5vZGUgLWYgcm9vdC5pbWFn ZSAtdSAxMQpkaXNrbGFiZWwgLXIgLXcgbWQxMXMxIGF1dG8K --0-910510754-1011304859=:521-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 17 14:26:55 2002 Delivered-To: freebsd-current@freebsd.org Received: from femail48.sdc1.sfba.home.com (femail48.sdc1.sfba.home.com [24.254.60.42]) by hub.freebsd.org (Postfix) with ESMTP id EC6BA37B402 for ; Thu, 17 Jan 2002 14:26:48 -0800 (PST) Received: from dosmonos ([24.249.124.238]) by femail48.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20020117222648.HNNK26133.femail48.sdc1.sfba.home.com@dosmonos>; Thu, 17 Jan 2002 14:26:48 -0800 Date: Thu, 17 Jan 2002 17:25:32 -0500 (EST) From: Mike Brancato X-Sender: funnyguy@dosmonos To: Ian Dowse Cc: freebsd-current@FreeBSD.org Subject: Re: boot floppy problems... In-Reply-To: <200201171940.aa68346@salmon.maths.tcd.ie> 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 no problem. keep up the good work. mike On Thu, 17 Jan 2002, Ian Dowse wrote: > In message , Mike Brancato wr > ites: > >oh, well. They say something along the lines of > >"Disk error: lba is 0x9 (should be 0x10)" > >or similar. then it trys to boot the kernel twice using the loader, but > >fails with the path 0:fd(0,a)/kernel > > Hmm, the error is actually "Disk error 0x9 (lba=0x10)". I think > this is my fault. Error 9 is "data boundary error (attempted DMA > across 64K boundary or >80h sectors)", so by changing the buffers > to being static in revision 1.35 of boot2.c, I broke the guarantee > that single transfers don't cross a 64k boundary, which is important > for floppies :-( I'll fix this shortly. Thanks for pointing out the > problem! > > Ian > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 17 14:52:59 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 2804A37B405 for ; Thu, 17 Jan 2002 14:52:48 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 17 Jan 2002 22:52:47 +0000 (GMT) To: Mike Brancato Cc: freebsd-current@FreeBSD.org Subject: Re: boot floppy problems... In-Reply-To: Your message of "Thu, 17 Jan 2002 17:25:32 EST." Date: Thu, 17 Jan 2002 22:52:47 +0000 From: Ian Dowse Message-ID: <200201172252.ab04938@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 In message , Mike Brancato wr ites: >no problem. >keep up the good work. > >mike Ok, it's fixed now. If you'd like to try it, there's an updated version of the kern.flp from today's -CURRENT snapshot at: http://www.maths.tcd.ie/~iedowse/FreeBSD/kern.flp Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 17 15: 2:14 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.acns.ab.ca (h24-64-56-135.cg.shawcable.net [24.64.56.135]) by hub.freebsd.org (Postfix) with ESMTP id 5D2A137B404 for ; Thu, 17 Jan 2002 15:01:40 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0HN1cI85453; Thu, 17 Jan 2002 16:01:38 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0HN1cw07502; Thu, 17 Jan 2002 16:01:38 -0700 (MST) (envelope-from davidc) Date: Thu, 17 Jan 2002 16:01:38 -0700 From: Chad David To: Terry Lambert Cc: Chad David , current@freebsd.org Subject: Re: socket shutdown delay? Message-ID: <20020117160138.A7434@colnta.acns.ab.ca> Mail-Followup-To: Terry Lambert , Chad David , current@freebsd.org References: <20020116070908.A803@colnta.acns.ab.ca> <3C45F32A.5B517F7E@mindspring.com> <20020116152908.A1476@colnta.acns.ab.ca> <3C4611D7.F99A5147@mindspring.com> <20020116174342.A2097@colnta.acns.ab.ca> <3C462820.F4E39DF8@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C462820.F4E39DF8@mindspring.com>; from tlambert2@mindspring.com on Wed, Jan 16, 2002 at 05:25:52PM -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, Jan 16, 2002 at 05:25:52PM -0800, Terry Lambert wrote: > Chad David wrote: > > The direct cause is a bug in my client. I call close(2) out side of the > > main loop (one line off :( ), so none of the client side sockets were > > getting closed. When I fixed this all of the connections went to > > TIME_WAIT right away. > > > > I'm still not convinced that all is well though, as on Solaris 5.9 and > > 4.4-STABLE I do not see the problem with the bad client. > > So it's the resource track close of the sockets. Maybe, but it looks like TCP is ignoring the client FIN when sent from the local machine (see the below tcpdump). > > If the client and the server were the same program, you could > be seeing this as a timing thing on order of operation. I'm > guessing they aren't, though... No, they are seperate programs. I've written a sample client and server that demonstrate the issue (I can send them to you if you care). The problem occurs when the client does not close any of its sockets, and just runs until there are no more to be had. At that point it exits. The server accepts the connections, does one read(2), one write(2), and then closes the connection (in a seperate thread). The client was able to connect 3976 times before it fails, at which point it exits and I killed the server. The (cleaned up) output of tcpdump -S -i lo0 is: 15:17:08.742699 localhost.2233 > localhost.9999: S 1241089741:1241089741(0) win 65535 (DF) 15:17:08.742741 localhost.9999 > localhost.2233: S 1530034189:1530034189(0) ack 1241089742 win 65535 15:17:08.742756 localhost.2233 > localhost.9999: . ack 1530034190 win 32767 (DF) 15:17:08.742987 localhost.2233 > localhost.9999: P 1241089742:1241089767(25) ack 1530034190 win 32767 (DF) 15:17:08.743233 localhost.9999 > localhost.2233: P 1530034190:1530034446(256) ack 1241089767 win 32755 (DF) 15:17:08.743340 localhost.9999 > localhost.2233: F 1530034446:1530034446(0) ack 1241089767 win 32755 (DF) 15:17:08.743374 localhost.2233 > localhost.9999: . ack 1530034447 win 32639 (DF) 15:20:19.793831 localhost.2233 > localhost.9999: F 1241089767:1241089767(0) ack 1530034447 win 32639 (DF) 15:21:23.793759 localhost.2233 > localhost.9999: F 1241089767:1241089767(0) ack 1530034447 win 32639 (DF) 15:22:27.792756 localhost.2233 > localhost.9999: F 1241089767:1241089767(0) ack 1530034447 win 32639 (DF) 15:23:31.791632 localhost.2233 > localhost.9999: F 1241089767:1241089767(0) ack 1530034447 win 32639 (DF) 15:25:39.791074 localhost.2233 > localhost.9999: R 1241089768:1241089768(0) ack 1530034447 win 32639 (DF) I don't know the code that well (which I'm working on), so I have to ask, what can be preventing the server socket (which has no process), from sending an ack before the client socket (which also has no process) gives up and sends a reset? > > > > I'll address your points below, but if you don't feel like chasing this > > anymore that is fine with me... I'll add it to my list of things to > > try and understand on my next vacation :). > > Unless there's something that jumps out at you, this is probably > a good plan. 8-). Something jumped out.. > > > > > You should probably call shutdown(2), if you want your code > > > to be mostly correct. > > > > Call shutdown(2) instead of close(2)? > > Nope. Before close. Depending on the argument, perhaps not > before the last read or write, then the close. I read Stevens, and now I understand... this whole adventure was worth it if for no other reason then I now understand this point! > > > > This indicates a 2MSL draining. The resource track close could > > > also be slow. You could probably get an incredible speedup by > > > doing explicit closes in the client program, starting with the > > > highest used fd, and working down, instead of going the other > > > way (it's probably a good idea to modify the FreeBSD resource > > > track close to so the same thing). > > > > If I had been doing any explicit closes :(. > > Yes, but your ordering is reverse optimal, actually, so you are > going to be rate limited at the client. > > Did the client actually exit? If it didn't, that would explain > everything. As you already know, the client does exit, but it looks to me like it is the server sockets problem, not the clients? > > > > I actually implemented something for this type of problem over Christmas > > with one of the Solaris engineers. It was inspired by Jeff Bonwick's > > vmem stuff (Usenix 2001), but was bit mask based, so the actual storage > > overhead was a lot less, with what appeared to be very good allocate and > > free times (O(n) as the worst case with O(1) typically). > > This would be nice for FreeBSD, assuming we could pry it out > of you. 8-). Assuming I can ever get it into a presentable state... between work family and FreeBSD I've decided to sleep when I'm dead. > > > [ ... timer code, Rice U. Opportunistic Timers ... ] > > > I think I have that paper around here somewhere... is it older, > > like from around 1990? > > No, you are probably thinking of the WRL paper by Jeff Mogul. > The paper I'm referring to is late mid-90's. I'll go find it. > > > > > > Nope. Stock -current, none of my patches applied. > > > > > > Heh... "not useful information without a date of cvsup, > > > and then possibly not even then". Moving target problems... > > > > The original email has the uname and a dmesg, but: > > FreeBSD colnta 5.0-CURRENT FreeBSD 5.0-CURRENT #17: Sun Jan 13 03:51:32 MST 2002 > > I would need to check it out, and build my own copy, and see > if I could repeat it (I'd need your broken client and your > server code. It would be much better to see if other well > known and tested versions of FreeBSD exhibited the same symptoms, > and, if not, track it down with a bsearch of the CVS tree by date. If need be I will do this tonight. I have a local cvs repo, and a nice fast devel. machine so it shouldn't take too long. > > > > Give that each connection is in its own thread this is very doable... > > This would at least isolate it to the client vs. server code > and order of operation. If it's the server close, then the > issue is perhaps a re-ACK after FIN ACK from the close making > the SYN cache think it has a new connection, then a re-FIN, > with the close, to get it into the strange state... ?? > > > > > If nothing else I'm learning... I just wish I could read as fast > > as you can type :). > > Heh. My max rate is 135 WPM, which is 6*135 CPM or 13.5 CPS, or > 135 BAUD, which is slow as molasses compared to most people's > read rates (by about 2 orders of magnitude). Just an indirect comment about your tendancy to reply in more detail that a lot other others, nothing else :). Again, thank you. -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 17 15:17:33 2002 Delivered-To: freebsd-current@freebsd.org Received: from femail38.sdc1.sfba.home.com (femail38.sdc1.sfba.home.com [24.254.60.32]) by hub.freebsd.org (Postfix) with ESMTP id 5CC9237B421 for ; Thu, 17 Jan 2002 15:17:21 -0800 (PST) Received: from dosmonos ([24.249.124.238]) by femail38.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20020117231721.IRNQ3734.femail38.sdc1.sfba.home.com@dosmonos>; Thu, 17 Jan 2002 15:17:21 -0800 Date: Thu, 17 Jan 2002 18:16:05 -0500 (EST) From: Mike Brancato X-Sender: funnyguy@dosmonos To: Ian Dowse Cc: freebsd-current@FreeBSD.org Subject: Re: boot floppy problems... In-Reply-To: <200201172252.ab04938@salmon.maths.tcd.ie> 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 seems to work in vmware now. maybe i'll cvsup my source and rebuild my machine tonight. fun. thanks. mike On Thu, 17 Jan 2002, Ian Dowse wrote: > In message , Mike Brancato wr > ites: > >no problem. > >keep up the good work. > > > >mike > > Ok, it's fixed now. If you'd like to try it, there's an updated > version of the kern.flp from today's -CURRENT snapshot at: > > http://www.maths.tcd.ie/~iedowse/FreeBSD/kern.flp > > Ian > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 17 16:23: 3 2002 Delivered-To: freebsd-current@freebsd.org Received: from fl-mta03.durocom.com (fl-mta03.durocom.com [216.53.195.244]) by hub.freebsd.org (Postfix) with ESMTP id 4706E37B400; Thu, 17 Jan 2002 16:22:42 -0800 (PST) Received: from [198.69.78.81] by fl-mta03.durocom.com with SMTP id <20020118002239.HNGN2366.fl-mta03@[198.69.78.81]>; Thu, 17 Jan 2002 19:22:39 -0500 From: rej@caae.com To: kuro18@hotmail.com Subject: Great News Date: Thu, 17 Jan 2002 18:17:36 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_6295_00005913.0000003E" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: <20020118002239.HNGN2366.fl-mta03@[198.69.78.81]> 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_000_6295_00005913.0000003E Content-Type: text/html; ViaPro

To be removed from future mailings CLICK HERE

 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 17 17:20:38 2002 Delivered-To: freebsd-current@freebsd.org Received: from web14008.mail.yahoo.com (web14008.mail.yahoo.com [216.136.175.124]) by hub.freebsd.org (Postfix) with SMTP id EB59E37B416 for ; Thu, 17 Jan 2002 17:20:20 -0800 (PST) Message-ID: <20020118012020.97262.qmail@web14008.mail.yahoo.com> Received: from [216.103.213.142] by web14008.mail.yahoo.com via HTTP; Thu, 17 Jan 2002 17:20:20 PST Date: Thu, 17 Jan 2002 17:20:20 -0800 (PST) From: k Macy Subject: -CURRENT AIO bug Re: How well does EVFILT_AIO work? To: Terry Lambert , Julian Elischer Cc: alc@imimic.com, freebsd-current@freebsd.org, Doug White , k Macy , freebsd-hackers@FreeBSD.ORG In-Reply-To: <3C4236D0.77A21A14@mindspring.com> 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 turns that this problem is specific to AIO in -CURRENT. I wrote a simple program that uses the three different completion mechanisms (polling with aio_error, polling with kevent, and using SIGIO) to fill up a file by writing 8kb at a time to the file and then reading 8kb at a time from the file. The lower the average latency, the more frequently it can send off a new request. It can be found at: http://www.eventdriven.org/aio_lat_test.tgz Don't try using the aiotest_sigio (on FreeBSD), the siginfo_t doesn't get filled. Yet another PR that I have to file. Here are the results (in ms): 10 32MB files 4-way Sun server over NFS Memory: 4096M real, 924M free, 768M swap in use, 7234M swap free > uname -a SunOS orbit 5.8 Generic_108528-11 sun4u sparc SUNW,Ultra-Enterprise > ./aiotest_sigio write sk_msecs: 112350 max_latency: 560 reads sk_msecs: 119670 max_latency: 780 > ./aiotest_aio_error write sk_msecs: 45570 max_latency: 240 reads sk_msecs: 48280 max_latency: 630 > ./aiotest_sigio write sk_msecs: 117260 max_latency: 410 reads sk_msecs: 124100 max_latency: 600 > ./aiotest_aio_error write sk_msecs: 45050 max_latency: 780 reads sk_msecs: 46550 max_latency: 1530 10 32MB files 600Mhz Laptop local disk UDMA33 Mem: 68M Active, 134M Inact, 30M Wired, 15M Cache, 35M Buf, 656K Free kmacy@netherworld [15:20][~/src/bugs] uname -a FreeBSD netherworld.eventdriven.org 4.5-RC FreeBSD 4.5-RC #1: Wed Jan 16 21:30:55 PST 2002 root@netherworld.e ventdriven.org:/usr/src/sys/compile/NETHERWORLD i386 kmacy@netherworld [15:08][~/src/bugs/aio] ./aiotest_aio_error write sk_msecs: 72890 max_latency: 930 reads sk_msecs: 56830 max_latency: 930 kmacy@netherworld [15:11][~/src/bugs/aio] ./aiotest_kevent write sk_msecs: 71300 max_latency: 1380 reads sk_msecs: 54500 max_latency: 1380 kmacy@netherworld [15:14][~/src/bugs/aio] ./aiotest_aio_error write sk_msecs: 73970 max_latency: 990 reads sk_msecs: 56790 max_latency: 990 kmacy@netherworld [15:17][~/src/bugs/aio] ./aiotest_kevent write sk_msecs: 73620 max_latency: 980 reads sk_msecs: 59620 max_latency: 1860 2-way 1.0GHZ FreeBSD weizen.extendedsolutions.com 5.0-20020106-CURRENT FreeBSD 5.0-20020106-CURRENT #3: Thu Jan 10 18:58:36 PS T 2002 root@weizen.extendedsolutions.com:/usr/src/sys/i386/compile/HADES i386 Mem: 11M Active, 188M Inact, 111M Wired, 1760K Cache, 111M Buf, 691M Free (~420x slower) (~420x slower) 10 1MB files local disk (UDMA33) > aiotest_aio_error write sk_msecs: 959540 max_latency: 29960 reads sk_msecs: 959970 max_latency: 29960 Same machine compiled UP: > aiotest_aio_error write sk_msecs: 810010 max_latency: 29960 reads sk_msecs: 779950 max_latency: 29960 > uname -a FreeBSD weizen.extendedsolutions.com 5.0-20020106-CURRENT FreeBSD 5.0-20020106-CURRENT #0: Thu Jan 17 15:36:56 PS T 2002 root@weizen.extendedsolutions.com:/usr/src/sys/i386/compile/HADES_UP i386 --- Terry Lambert wrote: > Julian Elischer wrote: > > the threads package doesn't do file IO > asynchronoulsy > > in fact there ahve been several people > threatenning to use AIO > > to make the threads package to that asychronously > too. > > Which is incredibly funny, if you think about it, > since there > are two ways to implement a call conversion threads > package: > > 1) Trade a sync call for an async call plus a > context > switch > > 2) Trade a blocking call for a non-blocking call > plus > a context switch > > So... how do you do a non-blocking aio_wait again? > 8-) 8-). > > -- Terry __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 17 23:34: 0 2002 Delivered-To: freebsd-current@freebsd.org Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by hub.freebsd.org (Postfix) with ESMTP id 6071E37B416 for ; Thu, 17 Jan 2002 23:33:51 -0800 (PST) Received: from sdn-ar-004azphoep274.dialsprint.net ([206.133.140.204] helo=p98y) by blount.mail.mindspring.net with smtp (Exim 3.33 #1) id 16R9EO-0007VK-00; Thu, 17 Jan 2002 04:53:14 -0500 From: YOUR-SITEservicetop@earthlink.net To: Subject: New - Just Curious Date: Thu, 17 Jan 2002 23:47:38 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_6F12_00007491.00002AC3" X-Priority: 3 X-MSMail-Priority: Normal 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 ------=_NextPart_000_6F12_00007491.00002AC3 Content-Type: text/html;
Dear Consumer,

Increase your business sales! How??

By targeting millions of buyers via e-mail !!

We are offering over 10 million FRESH ,
DELIVERABLE, e-mail addresses on CD-ROM.
The cd-rom includes targeted addresses, such as business opportunity
seekers, sports buffs, mlm, impulsive buyers and investors.
The cd-rom also includes general internet, United States,
United kingdom, mixed domains, International, Canadian,
earthlink, aol, compuserve, misc. and much more. The list's
are divided into groups and are compressed. This will allow
you to use the names right off the cd.

ORDER IN THE NEXT 7 DAYS AND RECEIVE 4
BONUSES!!

*BONUS #1 Receive an additional cd-rom with millions of fresh,
deliverable general internet e-mail addresses free!!

 *BONUS #2 Receive 2000 how to books, reports and manuals
on cd-rom with reprint resale rights! Produce for pennies
and sale for BIG dollars!

 *BONUS #3 Receive the Mass mailer bulk delivery software,
with full operating instructions. This software will get the mail
out QUICK! NOTE---THIS SOFTWARE ALONE WILL COST
YOU 99.95 JUST ABOUT ANYWHERE ON THE WEB! (those who
order and do research will know that this offer is a steal) GUARANTEED!!

 *BONUS #4 Receive the informational guide to bulk e-mail.
This guide will give you all the information you need to get started!

 THIS IS A ONE TIME PACKAGE DEAL WORTH
HUNDREDS OF DOLLARS!!

I'M NOT DONE YET!!!!!!

LET ME HELP GET YOU STARTED.

Recieve Full and Total resale rights to one of the hottest selling
devices on the net......LISTEN CLOSE....

READY TO KNOW?

CONFIDENTIAL!

The SOFTWARE They Want BANNED In all 50 STATES.
Why? Because these secrets were never intended to reach your eyes...
Get the facts on anyuone!

Locate Missing Persons, find Lost Relatives, obtain Addresses
and Phone Numbers of old school friends, even Skip Trace Dead
Beat Spouses. This is not a Private Investigator, but a
sophisticated SOFTWARE program DESIGNED to automatically
CRACK YOUR CASE with links to thousands of Public Record databases.

Find out SECRETS about your relatives, friends, enemies,
and everyone else! Even your spouse! With the New,
INTERNET SPY AND YOU!

It's absolutely astounding! Here's what you can learn.

License plate number!
Get anyone's name and address with just a license plate number!

Driving record!
Get anyone's driving record!

Social security number!
Trace anyone by social security number!

Address!
Get anyone's address with just a name!

Unlisted phone numbers!
Get anyone's phone number with just a name even unlisted numbers!
Locate!
Long lost friends, relatives, a past lover who broke your heart!

E-mail!
Send anonymous e-mail completely untraceable!

Dirty secrets!
Discover dirty secrets your in-laws don't want you to know!

Investigate anyone!
Use the sources that private invesigators use (all on the Internet)
secretly!

Ex-spouse!
Learn how to get information on an ex-spouse that will help you
win in court! (Dig up old skeletons)!

Criminal search Background check!
Find out about your daughter's boyfriend!

Find out!
If you are being investigated!

Neighbors!
Learn all about your mysterious neighbors! Find out what they
have to hide!

People you work with!
Be astonished by what you'll learn about people you work with!

Education verification!
Did he really graduate college? Find out!

Internet Spy and You!
Software will help yuou discover ANYTHING about anyone, with
clickable hyperlinks and no typing in internet addresses! Just
insert the floppy disk and Go!

You will be shocked and amazed by the secrets that can be
discovered about absolutely everyone! Find out the secrets
they don't want you to know! About others, about yourself!

It's INCREDIBLE what you can find out using Internet Spy and You
and the Internet! You'll be riveted to your computer screen!
Get the software they're trying to ban! Before it's too late!

ACT NOW! THIS IS A LIMITED TIME OFFER!


RECEIVE THIS PACKAGE FOR THE ONE TIME
UNBELIEVABLE LOW, LOW PRICE OF ONLY<<< $69.97>>>
YOU WON'T FIND IT ANY CHEAPER....GUARANTEED....NOW IS
YOUR CHANCE TO GET IN ON THE HOTTEST FORM OF ONLINE
ADVERTISING AVAILABLE. DON'T MISS OUT. THIS INDUSTRY
IS JUST BEGINNING...

SIMPLY SEND $69.97,
ORDER INFORMATION:

SIMPLY SEND, FAX or CALL YOUR ORDER IN.

We Accept Visa - Mastercard - Discover, Check and Money Orders.

INCLUDE THE FOLLOWING INFORMATION
TO COMPLETE YOUR ORDER:

YOUR NAME:

ADDRESS:

STATE: CITY:

ZIP:

PHONE NUMBER:

FAX NUMBER:

EMAIL ADDRESS


CREDIT CARD #.
EXP. DATE:

NAME ON CARD.

Sign Here:__________________________________ Date:_____________

 This is a super low cost of $69.97 .
MAILING YOUR ORDER IN - COMPLETELY FILL OUT THE INFORMATION
ABOVE AND
SEND TO: CYBER CC
9163 W UNION HILLS DR #105-14
PEORIA, AZ 85382

If You fax a check, there is no need for you to mail the
original. We will draft a new check, with the exact
information from your original check. All checks
will beheld for bank clearance. (4-7 days)
Make payable to: CYBER CC
FAX TO: 602-392-8288

PASTE CHECK HERE
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

WHEN PLACING AN ORDER BY PHONE,
SPEAK LOUD AND CLEAR AND SPELL OUT
ALL WORDS. WE NEED ALL THE INFORMATION ABOVE TO COMPLETE
ANY ORDER. CALL 602-392-8288 AND ENTER *3 AND THEN LEAVE YOUR ORDER.







This mailing is done by an independent marketing co.
We apologize if this message has reached you in error.
Save the Planet, Save the Trees! Advertise via E mail.
No wasted paper! Delete with one simple keystroke!
Less refuse in our Dumps! This is the new way of
the new millennium!

To be removed m6216551@yahoo.com
To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 18 2: 6: 6 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.hal-pc.org (hal-pc.org [204.52.135.1]) by hub.freebsd.org (Postfix) with ESMTP id AAE9437B417 for ; Fri, 18 Jan 2002 02:05:50 -0800 (PST) Received: from y7f6s9 (206.180.128.203.dial-ip.hal-pc.org [206.180.128.203]) by mail.hal-pc.org (8.9.1/8.9.0) with ESMTP id EAA20083 for ; Fri, 18 Jan 2002 04:05:49 -0600 (CST) From: als@hal-pc.org To: current@FreeBSD.ORG Date: Fri, 18 Jan 2002 04:07:44 -0600 Subject: UNSUBSCRIBE Message-ID: <3C479F90.9380.1427FFC8@localhost> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) 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 Please unsubscribe als@hal-pc.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 18 2:54:39 2002 Delivered-To: freebsd-current@freebsd.org Received: from ns.plaut.de (ns.plaut.de [194.99.75.166]) by hub.freebsd.org (Postfix) with ESMTP id 3A40937B419; Fri, 18 Jan 2002 02:54:31 -0800 (PST) Received: (from uucp@localhost) by ns.plaut.de (8.9.3/8.9.3) with UUCP id LAA34191; Fri, 18 Jan 2002 11:53:11 +0100 (CET) (envelope-from root@nihil.plaut.de) Received: from localhost (root@localhost) by nihil.plaut.de (8.11.3/8.8.8) with ESMTP id g0IAqWV00464; Fri, 18 Jan 2002 11:52:32 +0100 (CET) (envelope-from root@nihil) Date: Fri, 18 Jan 2002 11:52:31 +0100 (CET) From: Michael Reifenberger To: Alfred Perlstein , Cc: FreeBSD-Current Subject: Re: new panic under -current In-Reply-To: <20020114230841.A533-100000@nihil> Message-ID: <20020118113428.O447-200000@nihil> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-588361863-1011351151=:447" 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-588361863-1011351151=:447 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, the panic I think is for you Alfred. The fsck related problems I describe below are for Kirk. On Mon, 14 Jan 2002, Michael Reifenberger wrote: > Date: Mon, 14 Jan 2002 23:16:26 +0100 (CET) > From: Michael Reifenberger > To: Alfred Perlstein > Cc: FreeBSD-Current > Subject: Re: new panic under -current > > On Mon, 14 Jan 2002, Alfred Perlstein wrote: > ... > > Can you cvsup and try to reproduce this? Maybe. Today I did: - reducing my mainmem to 64M using hw.physmem=64M - compiling and cleaning some packages garaphics/[mplayer|ogle] a few times - starting X + kde - drinking some coffee - starting the kde browser PENG I somewhat suspect either procfs or linprocfs. (I see many ?? in the backtrace and they are setup as modules) My setup regarding this: /dev - devfs /proc - procfs /tmp - md(4) /compat/linux/dev - devfs /compat/linux/proc - procfs Ok, thats one thing. The second is after reboot I go into singleuser and do: - `fsck -p` (works OK) - `mount /usr` ...mount pending error: blocks: 243, files 1... (Hmm. maybe a leftover from the panic) - `reboot` ... syncing 2 2 2 2 2 2 2... giving up on 2 buffers ... (Why?) After that I have to redo the fsck to get a clean filesystem. I have this seen only after fsck's and after panics in conjunction with 'mount pending errors'... During normal shutdown no 'giving up' messages are occuring. Any clues? Bye! ---- Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS --0-588361863-1011351151=:447 Content-Type: TEXT/plain; name="bt.txt" Content-Transfer-Encoding: BASE64 Content-ID: <20020118115231.T447@nihil> Content-Description: Content-Disposition: attachment; filename="bt.txt" R05VIGdkYiA0LjE4DQpDb3B5cmlnaHQgMTk5OCBGcmVlIFNvZnR3YXJlIEZv dW5kYXRpb24sIEluYy4NCkdEQiBpcyBmcmVlIHNvZnR3YXJlLCBjb3ZlcmVk IGJ5IHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwgYW5kIHlvdSBh cmUNCndlbGNvbWUgdG8gY2hhbmdlIGl0IGFuZC9vciBkaXN0cmlidXRlIGNv cGllcyBvZiBpdCB1bmRlciBjZXJ0YWluIGNvbmRpdGlvbnMuDQpUeXBlICJz aG93IGNvcHlpbmciIHRvIHNlZSB0aGUgY29uZGl0aW9ucy4NClRoZXJlIGlz IGFic29sdXRlbHkgbm8gd2FycmFudHkgZm9yIEdEQi4gIFR5cGUgInNob3cg d2FycmFudHkiIGZvciBkZXRhaWxzLg0KVGhpcyBHREIgd2FzIGNvbmZpZ3Vy ZWQgYXMgImkzODYtdW5rbm93bi1mcmVlYnNkIi4uLg0KSWRsZVBURCBhdCBw aHN5aWNhbCBhZGRyZXNzIDB4MDA0MGYwMDANCmluaXRpYWwgcGNiIGF0IHBo eXNpY2FsIGFkZHJlc3MgMHgwMDI4MWQ0MA0KcGFuaWNzdHI6IGJ3cml0ZTog YnVmZmVyIGlzIG5vdCBidXN5Pz8/DQpwYW5pYyBtZXNzYWdlczoNCi0tLQ0K RmF0YWwgdHJhcCAxMjogcGFnZSBmYXVsdCB3aGlsZSBpbiBrZXJuZWwgbW9k ZQ0KZmF1bHQgdmlydHVhbCBhZGRyZXNzCT0gMHg4MA0KZmF1bHQgY29kZQkJ PSBzdXBlcnZpc29yIHdyaXRlLCBwYWdlIG5vdCBwcmVzZW50DQppbnN0cnVj dGlvbiBwb2ludGVyCT0gMHg4OjB4YzAxYTBlZjQNCnN0YWNrIHBvaW50ZXIJ ICAgICAgICA9IDB4MTA6MHhjOTYzMGI4NA0KZnJhbWUgcG9pbnRlcgkgICAg ICAgID0gMHgxMDoweGM5NjMwYjljDQpjb2RlIHNlZ21lbnQJCT0gYmFzZSAw eDAsIGxpbWl0IDB4ZmZmZmYsIHR5cGUgMHgxYg0KCQkJPSBEUEwgMCwgcHJl cyAxLCBkZWYzMiAxLCBncmFuIDENCnByb2Nlc3NvciBlZmxhZ3MJPSBpbnRl cnJ1cHQgZW5hYmxlZCwgcmVzdW1lLCBJT1BMID0gMA0KY3VycmVudCBwcm9j ZXNzCQk9IDQxOTY1IChrZGVpbml0KQ0KdHJhcCBudW1iZXIJCT0gMTINCnBh bmljOiBwYWdlIGZhdWx0DQoNCnN5bmNpbmcgZGlza3MuLi4gcGFuaWM6IGJ3 cml0ZTogYnVmZmVyIGlzIG5vdCBidXN5Pz8/DQpVcHRpbWU6IDI0bTQ3cw0K cGZzX3ZuY2FjaGVfdW5sb2FkKCk6IDEgZW50cmllcyByZW1haW5pbmcNCg0K ZHVtcGluZyB0byBkZXYgYWQwczNiLCBvZmZzZXQgNDA2MzIzMg0KZHVtcCBh dGEwOiByZXNldHRpbmcgZGV2aWNlcyAuLiBkb25lDQo2NCA2MyA2MiA2MSA2 MCA1OSA1OCA1NyA1NiA1NSA1NCA1MyA1MiA1MSA1MCA0OSA0OCA0NyA0NiA0 NSA0NCA0MyA0MiA0MSA0MCAzOSAzOCAzNyAzNiAzNSAzNCAzMyAzMiAzMSAz MCAyOSAyOCAyNyAyNiAyNSAyNCAyMyAyMiAyMSAyMCAxOSAxOCAxNyAxNiAx NSAxNCAxMyAxMiAxMSAxMCA5IDggNyA2IDUgNCAzIDIgMSANCi0tLQ0KIzAg IGR1bXBzeXMgKCkgYXQgLi4vLi4vLi4va2Vybi9rZXJuX3NodXRkb3duLmM6 NDkyDQo0OTIJCWlmICghZG9kdW1wKQ0KKGtnZGIpICMwICBkdW1wc3lzICgp IGF0IC4uLy4uLy4uL2tlcm4va2Vybl9zaHV0ZG93bi5jOjQ5Mg0KIzEgIDB4 YzAxNjY1ZTAgaW4gYm9vdCAoaG93dG89MHgxMDQpIGF0IC4uLy4uLy4uL2tl cm4va2Vybl9zaHV0ZG93bi5jOjMzNQ0KIzIgIDB4YzAxNjZhMmYgaW4gcGFu aWMgKGZtdD0weGMwMjM4MzU4ICJid3JpdGU6IGJ1ZmZlciBpcyBub3QgYnVz eT8/PyIpIGF0IC4uLy4uLy4uL2tlcm4va2Vybl9zaHV0ZG93bi5jOjYzNA0K IzMgIDB4YzAxOTZhMGYgaW4gYndyaXRlIChicD0weGM0OWI5NjA0KSBhdCAu Li8uLi8uLi9rZXJuL3Zmc19iaW8uYzo2NzYNCiM0ICAweGMwMTk2ZmM2IGlu IGJhd3JpdGUgKGJwPTB4YzQ5Yjk2MDQpIGF0IC4uLy4uLy4uL2tlcm4vdmZz X2Jpby5jOjk4OQ0KIzUgIDB4YzAxZGRiMzggaW4gZmZzX2ZzeW5jIChhcD0w eGM5NjMwYTQwKSBhdCAuLi8uLi8uLi91ZnMvZmZzL2Zmc192bm9wcy5jOjIx Nw0KIzYgIDB4YzAxZGMxYmEgaW4gZmZzX3N5bmMgKG1wPTB4YzEyNTI4MDAs IHdhaXRmb3I9MHgyLCBjcmVkPTB4YzA5YzdmMDAsIHRkPTB4YzAyNTZmYzQp IGF0IHZub2RlX2lmLmg6NDQxDQojNyAgMHhjMDFhM2UwNiBpbiBzeW5jICh0 ZD0weGMwMjU2ZmM0LCB1YXA9MHgwKSBhdCAuLi8uLi8uLi9rZXJuL3Zmc19z eXNjYWxscy5jOjY2OQ0KIzggIDB4YzAxNjYyNDEgaW4gYm9vdCAoaG93dG89 MHgxMDApIGF0IC4uLy4uLy4uL2tlcm4va2Vybl9zaHV0ZG93bi5jOjI0NA0K IzkgIDB4YzAxNjZhMmYgaW4gcGFuaWMgKGZtdD0weGMwMjRiMGRlICIlcyIp IGF0IC4uLy4uLy4uL2tlcm4va2Vybl9zaHV0ZG93bi5jOjYzNA0KIzEwIDB4 YzAyMTdiZDAgaW4gdHJhcF9mYXRhbCAoZnJhbWU9MHhjOTYzMGI0NCwgZXZh PTB4ODApIGF0IC4uLy4uLy4uL2kzODYvaTM4Ni90cmFwLmM6ODQyDQojMTEg MHhjMDIxNzhmOSBpbiB0cmFwX3BmYXVsdCAoZnJhbWU9MHhjOTYzMGI0NCwg dXNlcm1vZGU9MHgwLCBldmE9MHg4MCkgYXQgLi4vLi4vLi4vaTM4Ni9pMzg2 L3RyYXAuYzo3NTYNCiMxMiAweGMwMjE3MzAzIGluIHRyYXAgKGZyYW1lPXt0 Zl9mcyA9IDB4MTAwMDAxOCwgdGZfZXMgPSAweDEwMDAxMCwgdGZfZHMgPSAw eGM5NjcwMDEwLCB0Zl9lZGkgPSAweGM5NjA2MDA0LCANCiAgICAgIHRmX2Vz aSA9IDB4Yzk2MDYwMDQsIHRmX2VicCA9IDB4Yzk2MzBiOWMsIHRmX2lzcCA9 IDB4Yzk2MzBiNzAsIHRmX2VieCA9IDB4MCwgdGZfZWR4ID0gMHg0LCB0Zl9l Y3ggPSAweGM5NjA2MDA0LCANCiAgICAgIHRmX2VheCA9IDB4NCwgdGZfdHJh cG5vID0gMHhjLCB0Zl9lcnIgPSAweDIsIHRmX2VpcCA9IDB4YzAxYTBlZjQs IHRmX2NzID0gMHg4LCB0Zl9lZmxhZ3MgPSAweDEwMjgyLCANCiAgICAgIHRm X2VzcCA9IDB4YzE1ZmIwZDAsIHRmX3NzID0gMHhjOTY3MWQwMH0pIGF0IC4u Ly4uLy4uL2kzODYvaTM4Ni90cmFwLmM6NDI2DQojMTMgMHhjMDFhMGVmNCBp biB2cHV0ICh2cD0weDApIGF0IG1hY2hpbmUvYXRvbWljLmg6MTQ0DQojMTQg MHhjMTM1ZjQ1YSBpbiA/PyAoKQ0KIzE1IDB4YzAxYTBlYjcgaW4gdnJlbGUg KHZwPTB4Yzk2NzFkMDApIGF0IHZub2RlX2lmLmg6NjU0DQojMTYgMHhjMDFh YTEyYyBpbiB2bl9jbG9zZSAodnA9MHhjOTY3MWQwMCwgZmxhZ3M9MHgxLCBj cmVkPTB4YzE1ZDU2MDAsIHRkPTB4Yzk2MDYwMDQpIGF0IC4uLy4uLy4uL2tl cm4vdmZzX3Zub3BzLmM6MjYwDQojMTcgMHhjMDFhYWJhNiBpbiB2bl9jbG9z ZWZpbGUgKGZwPTB4YzE1N2NhODAsIHRkPTB4Yzk2MDYwMDQpIGF0IC4uLy4u Ly4uL2tlcm4vdmZzX3Zub3BzLmM6NzMwDQojMTggMHhjMDE1MTA2YSBpbiBm ZHJvcF9sb2NrZWQgKGZwPTB4YzE1N2NhODAsIHRkPTB4Yzk2MDYwMDQpIGF0 IC4uLy4uLy4uL3N5cy9maWxlLmg6MjI5DQojMTkgMHhjMDE1MDViMiBpbiBm ZHJvcCAoZnA9MHhjMTU3Y2E4MCwgdGQ9MHhjOTYwNjAwNCkgYXQgLi4vLi4v Li4va2Vybi9rZXJuX2Rlc2NyaXAuYzoxNDY1DQojMjAgMHhjMDE1MDU2NCBp biBjbG9zZWYgKGZwPTB4YzE1N2NhODAsIHRkPTB4Yzk2MDYwMDQpIGF0IC4u Ly4uLy4uL2tlcm4va2Vybl9kZXNjcmlwLmM6MTQ1MQ0KIzIxIDB4YzAxNGVl Y2UgaW4gY2xvc2UgKHRkPTB4Yzk2MDYwMDQsIHVhcD0weGM5NjMwZDIwKSBh dCAuLi8uLi8uLi9rZXJuL2tlcm5fZGVzY3JpcC5jOjcwMw0KIzIyIDB4YzAy MTgwNjAgaW4gc3lzY2FsbCAoZnJhbWU9e3RmX2ZzID0gMHgyZiwgdGZfZXMg PSAweDJmLCB0Zl9kcyA9IDB4MmYsIHRmX2VkaSA9IDB4MCwgdGZfZXNpID0g MHgzOGUwYWRhMCwgDQogICAgICB0Zl9lYnAgPSAweGJmYmZlOGNjLCB0Zl9p c3AgPSAweGM5NjMwZDc0LCB0Zl9lYnggPSAweDM4ZGY4MWM4LCB0Zl9lZHgg PSAweGJmYmZlOTM0LCB0Zl9lY3ggPSAweGJmYmZlOWNjLCANCiAgICAgIHRm X2VheCA9IDB4NiwgdGZfdHJhcG5vID0gMHhjLCB0Zl9lcnIgPSAweDIsIHRm X2VpcCA9IDB4MzhkOTY4NTcsIHRmX2NzID0gMHgxZiwgdGZfZWZsYWdzID0g MHgyODMsIA0KICAgICAgdGZfZXNwID0gMHhiZmJmZThhMCwgdGZfc3MgPSAw eDJmfSkgYXQgLi4vLi4vLi4vaTM4Ni9pMzg2L3RyYXAuYzoxMDM0DQojMjMg MHhjMDIwYmJiZCBpbiBzeXNjYWxsX3dpdGhfZXJyX3B1c2hlZCAoKQ0KIzI0 IDB4MzhkZDcwZWMgaW4gPz8gKCkNCiMyNSAweDM4N2ViNGMxIGluID8/ICgp DQojMjYgMHgzODVjZGRhNCBpbiA/PyAoKQ0KIzI3IDB4Mzg1YmU2OGEgaW4g Pz8gKCkNCiMyOCAweDM4NWMyNzA3IGluID8/ICgpDQojMjkgMHgzODViZmQ2 OSBpbiA/PyAoKQ0KIzMwIDB4Mzg2NTRjZjYgaW4gPz8gKCkNCiMzMSAweDM4 NWY3NDBlIGluID8/ICgpDQojMzIgMHgzODYwNjNiMiBpbiA/PyAoKQ0KIzMz IDB4Mzg2NGZmNTIgaW4gPz8gKCkNCiMzNCAweDM4ZjUzMGQxIGluID8/ICgp DQojMzUgMHg4MDRjYjM2IGluID8/ICgpDQojMzYgMHg4MDRkN2YzIGluID8/ ICgpDQojMzcgMHg4MDRkZDRjIGluID8/ICgpDQojMzggMHg4MDRlZWRjIGlu ID8/ICgpDQojMzkgMHg4MDRhZGYxIGluID8/ICgpDQooa2dkYikg --0-588361863-1011351151=:447-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 18 3: 7:17 2002 Delivered-To: freebsd-current@freebsd.org Received: from www.yahho.com (28.c210-85-16.ethome.net.tw [210.85.16.28]) by hub.freebsd.org (Postfix) with SMTP id DA13037B420; Fri, 18 Jan 2002 03:06:59 -0800 (PST) Received: from saturn by tpts1.seed.net.tw with SMTP id PSdexVwXQCuW0AJ; Fri, 18 Jan 2002 19:15:16 +0800 Message-ID: From: SV7O80PF@ksmail.seed.net.tw To: zNI@tpts4.seed.net.tw Subject: MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_t75bPXRkhRqbq3Hnf" X-Priority: 3 X-MSMail-Priority: Normal Date: Fri, 18 Jan 2002 03:06:59 -0800 (PST) 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_t75bPXRkhRqbq3Hnf Content-Type: multipart/alternative; boundary="----=_NextPart_t75bPXRkhRqbq3HnfAA" ------=_NextPart_t75bPXRkhRqbq3HnfAA Content-Type: text/html; charset="big5" Content-Transfer-Encoding: base64 PGh0bWw+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9YmlnNSI+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBGcm9udFBhZ2UgNC4wIj4NCjxtZXRhIG5hbWU9IlByb2dJZCIgY29udGVu dD0iRnJvbnRQYWdlLkVkaXRvci5Eb2N1bWVudCI+DQo8dGl0bGU+t1GmXqj9u1CxoaRIquymuMHb sG2qurT+qP223DwvdGl0bGU+DQo8L2hlYWQ+DQoNCjxib2R5Pg0KDQq3UaZeqP27ULGhpEiq7Ka4 wduwbaq6tP6o/bbcPyCxeqq6qkKkzSC3UbnvsXq7oaFBIHcgDQqn1qjspUikVaq6uvSttqzdrN0g Xl9fX19fX19fX19eIKVWpNGsT63TvkGmWMXKt1Kquql1uGChQSEgDQqkXbdRqNOt0672uqnB27Bt ttyhSCBcKCotKikvIGlWaWRlb7tQp0GqurLEpECmuMHbsG08YnI+DQo8YSBocmVmPSJodHRwOi8v d3d3Lml2aWRlby5jb20udHciPmh0dHA6Ly93d3cuaXZpZGVvLmNvbS50dzwvYT48YnI+DQo8YSBo cmVmPSJodHRwOi8vd3d3Lml2aWRlby5jb20udHcvZmxhc2gvcm9tYW5jZS5hc3AiPmh0dHA6Ly93 d3cuaXZpZGVvLmNvbXR3L2ZsYXNoL3JvbWFuY2UuYXNwPC9hPg0KPHA+oUA8L3A+DQo8cD6hQA0K PG9iamVjdCBjbGFzc2lkPSJjbHNpZDpEMjdDREI2RS1BRTZELTExY2YtOTZCOC00NDQ1NTM1NDAw MDAiIGNvZGVCYXNlPSJodHRwOi8vZG93bmxvYWQubWFjcm9tZWRpYS5jb20vcHViL3Nob2Nrd2F2 ZS9jYWJzL2ZsYXNoL3N3Zmxhc2guY2FiI3ZlcnNpb249NCwwLDIsMCIgaGVpZ2h0PSIzMjQiIHdp ZHRoPSI1NTAiPg0KICA8cGFyYW0gTkFNRT0iX2N4IiBWQUxVRT0iMTQ1NTIiPg0KICA8cGFyYW0g TkFNRT0iX2N5IiBWQUxVRT0iODU3MyI+DQogIDxwYXJhbSBOQU1FPSJNb3ZpZSIgVkFMVUU9Imh0 dHA6Ly93d3cuaXZpZGVvLmNvbS50dy9mbGFzaC91bmNsZS5zd2YiPg0KICA8cGFyYW0gTkFNRT0i U3JjIiBWQUxVRT0iaHR0cDovL3d3dy5pdmlkZW8uY29tLnR3L2ZsYXNoL3VuY2xlLnN3ZiI+DQog IDxwYXJhbSBOQU1FPSJXTW9kZSIgVkFMVUU9IldpbmRvdyI+DQogIDxwYXJhbSBOQU1FPSJQbGF5 IiBWQUxVRT0iLTEiPg0KICA8cGFyYW0gTkFNRT0iTG9vcCIgVkFMVUU9Ii0xIj4NCiAgPHBhcmFt IE5BTUU9IlF1YWxpdHkiIFZBTFVFPSJIaWdoIj4NCiAgPHBhcmFtIE5BTUU9IlNBbGlnbiIgVkFM VUU+DQogIDxwYXJhbSBOQU1FPSJNZW51IiBWQUxVRT0iLTEiPg0KICA8cGFyYW0gTkFNRT0iQmFz ZSIgVkFMVUU+DQogIDxwYXJhbSBOQU1FPSJTY2FsZSIgVkFMVUU9IlNob3dBbGwiPg0KICA8cGFy YW0gTkFNRT0iRGV2aWNlRm9udCIgVkFMVUU9IjAiPg0KICA8cGFyYW0gTkFNRT0iRW1iZWRNb3Zp ZSIgVkFMVUU9IjAiPg0KICA8cGFyYW0gTkFNRT0iQkdDb2xvciIgVkFMVUU+DQogIDxwYXJhbSBO QU1FPSJTV1JlbW90ZSIgVkFMVUU+DQogIDxwYXJhbSBOQU1FPSJTdGFja2luZyIgVkFMVUU9ImJl bG93Ij48ZW1iZWQgc3JjPSJodHRwOi8vd3d3Lml2aWRlby5jb20udHcvZmxhc2gvdW5jbGUuc3dm IiBxdWFsaXR5PSJoaWdoIiBwbHVnaW5zcGFnZT0iaHR0cDovL3d3dy5tYWNyb21lZGlhLmNvbS9z aG9ja3dhdmUvZG93bmxvYWQvaW5kZXguY2dpP1AxX1Byb2RfVmVyc2lvbj1TaG9ja3dhdmVGbGFz aCIgdHlwZT0iYXBwbGljYXRpb24veC1zaG9ja3dhdmUtZmxhc2giIHdpZHRoPSI1NTAiIGhlaWdo dD0iMzI0Ij4NCjwvb2JqZWN0Pg0KPC9wPg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4= ------=_NextPart_t75bPXRkhRqbq3HnfAA-- ------=_NextPart_t75bPXRkhRqbq3Hnf-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 18 4:28:10 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 DB6C137B419; Fri, 18 Jan 2002 04:27:54 -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 XAA07397; Fri, 18 Jan 2002 23:27:44 +1100 Date: Fri, 18 Jan 2002 23:29:03 +1100 (EST) From: Bruce Evans X-X-Sender: To: Michael Reifenberger Cc: FreeBSD-Current , Subject: Re: panic during fdisk'ing a md(4) device In-Reply-To: <20020117225217.O521-101000@nihil> Message-ID: <20020118232153.H792-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 Thu, 17 Jan 2002, Michael Reifenberger wrote: > On Thu, 17 Jan 2002, Bruce Evans wrote: > ... > > Oops. There should be no alias for md10c. Try this version. It fixes > > the "may want an alias case" in dkmodminor() and moves all the dk inlines > > to subr_diskslice.c. > This patch works better. > This brings us back to the original problem :-) > Now it doesn't panic during fsck immediately, it panics after unconfiguring > the md(4) device (which leaves the /dev/md11* devices in place instead removing > them) reconfiguring and then doing a new `disklabel ...` which tries to do > a (still existing) new 'make_dev("md11s1")'.... > See the attached backroot.sh. It somehow worked here, but after fixing the non-removal of the /dev/md11*, I got back what is probably the original panic too. At least with my fixed changes, the panic is caused by not clearing pointers in destroy_dev(). The pointers come back in make_dev() and bite you a little later. My orginal fixes helped by not doing all the necessary calls to destroy_dev(). devfs still leaks 2 DEVFS allocations and 6 devbuf allocations for every iteration of the script. %%% Index: kern/kern_conf.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_conf.c,v retrieving revision 1.104 diff -u -2 -r1.104 kern_conf.c --- kern/kern_conf.c 9 Jan 2002 04:58:49 -0000 1.104 +++ kern/kern_conf.c 18 Jan 2002 12:19:35 -0000 @@ -384,4 +384,5 @@ dev->si_drv2 = 0; dev->si_devsw = 0; + bzero(&dev->__si_u, sizeof(dev->__si_u)); /* XXX */ dev->si_flags &= ~SI_NAMED; dev->si_flags &= ~SI_ALIAS; Index: kern/subr_disk.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_disk.c,v retrieving revision 1.50 diff -u -2 -r1.50 subr_disk.c --- kern/subr_disk.c 4 Nov 2001 11:56:22 -0000 1.50 +++ kern/subr_disk.c 14 Jan 2002 11:42:38 -0000 @@ -301,5 +301,5 @@ error = 0; - pdev = dkmodpart(dkmodslice(dev, WHOLE_DISK_SLICE), RAW_PART); + pdev = dkmodslice(dkmodpart(dev, -RAW_PART), WHOLE_DISK_SLICE); dp = pdev->si_disk; @@ -349,5 +349,5 @@ error = 0; - pdev = dkmodpart(dkmodslice(dev, WHOLE_DISK_SLICE), RAW_PART); + pdev = dkmodslice(dkmodpart(dev, -RAW_PART), WHOLE_DISK_SLICE); dp = pdev->si_disk; if (!dp) @@ -365,5 +365,5 @@ struct disk *dp; - pdev = dkmodpart(dkmodslice(bp->bio_dev, WHOLE_DISK_SLICE), RAW_PART); + pdev = dkmodslice(dkmodpart(bp->bio_dev, -RAW_PART), WHOLE_DISK_SLICE); dp = pdev->si_disk; bp->bio_resid = bp->bio_bcount; @@ -400,5 +400,5 @@ dev_t pdev; - pdev = dkmodpart(dkmodslice(dev, WHOLE_DISK_SLICE), RAW_PART); + pdev = dkmodslice(dkmodpart(dev, -RAW_PART), WHOLE_DISK_SLICE); dp = pdev->si_disk; if (!dp) @@ -416,5 +416,5 @@ dev_t pdev; - pdev = dkmodpart(dkmodslice(dev, WHOLE_DISK_SLICE), RAW_PART); + pdev = dkmodslice(dkmodpart(dev, -RAW_PART), WHOLE_DISK_SLICE); dp = pdev->si_disk; if (!dp) Index: kern/subr_diskmbr.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_diskmbr.c,v retrieving revision 1.54 diff -u -2 -r1.54 subr_diskmbr.c --- kern/subr_diskmbr.c 11 Dec 2001 05:35:43 -0000 1.54 +++ kern/subr_diskmbr.c 9 Jan 2002 10:34:30 -0000 @@ -209,5 +209,5 @@ /* Read master boot record. */ bp = geteblk((int)lp->d_secsize); - bp->b_dev = dkmodpart(dkmodslice(dev, WHOLE_DISK_SLICE), RAW_PART); + bp->b_dev = dkmodslice(dkmodpart(dev, -RAW_PART), WHOLE_DISK_SLICE); bp->b_blkno = mbr_offset; bp->b_bcount = lp->d_secsize; Index: kern/subr_diskslice.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_diskslice.c,v retrieving revision 1.97 diff -u -2 -r1.97 subr_diskslice.c --- kern/subr_diskslice.c 17 Jan 2002 18:33:18 -0000 1.97 +++ kern/subr_diskslice.c 18 Jan 2002 10:02:09 -0000 @@ -68,4 +68,5 @@ static struct disklabel *clone_label __P((struct disklabel *lp)); +static dev_t dkmodminor __P((dev_t dev, int mynor, int slicehint)); static void dsiodone __P((struct bio *bp)); static char *fixlabel __P((char *sname, struct diskslice *sp, @@ -77,4 +78,5 @@ struct disklabel *lp)); static void set_ds_labeldevs __P((dev_t dev, struct diskslices *ssp)); +static void set_ds_labeldevs_unaliased __P((dev_t dev, struct diskslices *ssp)); static void set_ds_wlabel __P((struct diskslices *ssp, int slice, int wlabel)); @@ -122,8 +124,89 @@ } +/* + * XXX should be able to share more code between disk_dev_synth(), + * disk_clone() and here. + * XXX using dsname() only slightly insulates us from complications. + */ +static dev_t +dkmodminor(dev_t dev, int mynor, int slicehint) +{ + dev_t newdev, newdev_alias; + const char *sname; + char partname[2]; + + newdev = makedev(major(dev), mynor); + if ((dev->si_flags & SI_NAMED) == 0) + return (newdev); /* XXX should panic. */ + if (newdev->si_flags & SI_NAMED) { + /* We have found a device, but may want an alias. */ + if (dkslice(newdev) == WHOLE_DISK_SLICE || + dkslice(newdev) == COMPATIBILITY_SLICE || + dkpart(newdev) != RAW_PART || slicehint) + return (newdev); + + /* We do want an alias. There can be only one. XXX. */ + newdev_alias = LIST_FIRST(&newdev->si_children); + if (newdev_alias != NULL) + return (newdev_alias); + sname = dsname(dev, dkunit(newdev), dkslice(newdev), + dkpart(newdev), partname); + return (make_dev_alias(newdev, "%s%s", sname, partname)); + } + sname = dsname(dev, dkunit(newdev), dkslice(newdev), dkpart(newdev), + partname); + if (dkslice(newdev) == WHOLE_DISK_SLICE && dkpart(newdev) != RAW_PART) { + printf("bad disk name, sname = '%s', partname = '%s'\n", + sname, partname); + Debugger("dkmod"); + } + if (dkslice(newdev) == COMPATIBILITY_SLICE || + dkpart(newdev) != RAW_PART) { + newdev = make_dev(dev->si_devsw, mynor, dev->si_uid, + dev->si_gid, dev->si_mode, "%s%s", sname, partname); + dev_depends(dev, newdev); + return (newdev); + } + newdev = make_dev(dev->si_devsw, mynor, dev->si_uid, + dev->si_gid, dev->si_mode, "%s", sname); + dev_depends(dev, newdev); + if (dkslice(newdev) == WHOLE_DISK_SLICE) + return (newdev); +#if 0 + newdev_alias = make_dev_alias(newdev, "%s%s", sname, partname); +#else + /* + * Don't blindly create the alias. since it is bogus if the slice + * is unlabeled. Passing another hint to tell use when to do this + * would be too messy even for this prototype version. Now there + * are problems getting the alias created if the label is discovered + * later (these are fixed here but not in subr_disk.c). + */ + if (slicehint) + newdev_alias = NULL; + else + newdev_alias = make_dev_alias(newdev, "%s%s", sname, partname); +#endif + return (slicehint ? newdev : newdev_alias); +} + dev_t dkmodpart(dev_t dev, int part) { - return (makedev(major(dev), (minor(dev) & ~7) | part)); + int slicehint; + + /* + * XXX temporary hack: callers pass part == -RAW_PART instead of + * part == RAW_PART as a hint that they want a device whose name + * doesn't contain the partition letter for RAW_PART, if possible. + * This is possible unless the slice is COMPATIBILITY_SLICE. This + * is non-optional if the slice is WHOLE_DISK_SLICE. + */ + if (part == -RAW_PART) { + slicehint = 1; + part = RAW_PART; + } else + slicehint = 0; + return (dkmodminor(dev, (minor(dev) & ~7) | part, slicehint)); } @@ -131,5 +214,12 @@ dkmodslice(dev_t dev, int slice) { - return (makedev(major(dev), (minor(dev) & ~0x1f0000) | (slice << 16))); + /* + * Here we hint that we don't want a partition letter unless we + * don't already have one, our partition is RAW_PART, and our slice + * is not COMPATIBILITY_SLICE. These cases are distinguished by + * SI_ALIAS being set. The hint is not used in other cases. + */ + return (dkmodminor(dev, (minor(dev) & ~0x1f0000) | (slice << 16), + (dev->si_flags & SI_ALIAS) == 0)); } @@ -667,4 +757,5 @@ char *msg; u_char mask; + char *oldsname; int part; char partname[2]; @@ -746,11 +837,29 @@ ) continue; - dev1 = dkmodslice(dkmodpart(dev, RAW_PART), slice); -#if 0 - sname = dsname(dev, unit, slice, RAW_PART, partname); -#else - *partname='\0'; - sname = dev1->si_name; -#endif + dev1 = dkmodslice(dkmodpart(dev, -RAW_PART), slice); + if (dev1->si_devsw == NULL) { + Debugger("dsopen: no devsw (can't happen)"); + dev1->si_devsw = dev->si_devsw; + } + /* + * XXX we want a device name without any partition letter + * in it for use in error messages. dev1->si_name doesn't + * give this for the compatibility slice since there is no + * alias for the raw partiton on that slice. + * + * XXX dsname() is only used for the regression check; + * partname is only used to throw away the partition name + * in the regression check. + */ + if (slice == COMPATIBILITY_SLICE) + sname = dkmodslice(dkmodpart(dev, -RAW_PART), + WHOLE_DISK_SLICE)->si_name; + else + sname = dev1->si_name; + oldsname = dsname(dev, unit, slice, RAW_PART, partname); + if (strcmp(sname, oldsname) != 0) + printf( + "dsopen: dsname = '%s', partname = '%s', sname = '%s'\n", + oldsname, partname, sname); /* * XXX this should probably only be done for the need_init @@ -987,6 +1096,55 @@ struct diskslices *ssp; { + int slice; + + set_ds_labeldevs_unaliased(dev, ssp); + if (ssp->dss_first_bsd_slice == COMPATIBILITY_SLICE) + return; + slice = dkslice(dev); + if (slice == COMPATIBILITY_SLICE) + set_ds_labeldevs_unaliased( + dkmodslice(dev, ssp->dss_first_bsd_slice), ssp); + else if (slice == ssp->dss_first_bsd_slice) + set_ds_labeldevs_unaliased( + dkmodslice(dev, COMPATIBILITY_SLICE), ssp); } +static void +set_ds_labeldevs_unaliased(dev, ssp) + dev_t dev; + struct diskslices *ssp; +{ + struct disklabel *lp; + int part; + struct partition *pp; + int slice; + struct diskslice *sp; + + slice = dkslice(dev); + sp = &ssp->dss_slices[slice]; + if (sp->ds_size == 0) + return; + lp = sp->ds_label; + for (part = 0; part < lp->d_npartitions; part++) { + pp = &lp->d_partitions[part]; + if (pp->p_size == 0) + continue; + /* + * Just dkmod'ing to a partition creates all the necessary + * device entries for it. This is a bit weird, but it + * corresponds to userland stat'ing of nonexistent devfs + * directory entries creating them, and at least we avoid + * creating entries for nonexistent empty devices here. + * + * XXX userland can even exploit bugs to create invalid + * devices, e.g., ones with slice numbers larger than the + * max. Such slice numbers leak into the unit number + * or so-called "spare" bitfields. + */ + if (dev->si_flags & SI_ALIAS) + Debugger("unexpeced dk alias"); + (void)dkmodpart(dev, part); + } +} static void %%% Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 18 4:46:59 2002 Delivered-To: freebsd-current@freebsd.org Received: from ns.plaut.de (ns.plaut.de [194.99.75.166]) by hub.freebsd.org (Postfix) with ESMTP id 6DD0137B419; Fri, 18 Jan 2002 04:46:56 -0800 (PST) Received: (from uucp@localhost) by ns.plaut.de (8.9.3/8.9.3) with UUCP id NAA35800; Fri, 18 Jan 2002 13:45:39 +0100 (CET) (envelope-from root@nihil.plaut.de) Received: from localhost (root@localhost) by nihil.plaut.de (8.11.3/8.8.8) with ESMTP id g0ICjJJ00612; Fri, 18 Jan 2002 13:45:19 +0100 (CET) (envelope-from root@nihil) Date: Fri, 18 Jan 2002 13:45:19 +0100 (CET) From: Michael Reifenberger To: Bruce Evans Cc: FreeBSD-Current , Subject: Re: panic during fdisk'ing a md(4) device In-Reply-To: <20020118232153.H792-100000@gamplex.bde.org> Message-ID: <20020118134228.D499-100000@nihil> 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 Fri, 18 Jan 2002, Bruce Evans wrote: ... > It somehow worked here, but after fixing the non-removal of the > /dev/md11*, I got back what is probably the original panic too. At > least with my fixed changes, the panic is caused by not clearing > pointers in destroy_dev(). The pointers come back in make_dev() and > bite you a little later. My orginal fixes helped by not doing all the > necessary calls to destroy_dev(). > > devfs still leaks 2 DEVFS allocations and 6 devbuf allocations for every > iteration of the script. ... Does this mean that your latest patch removes the panic but leaks some resources. Bye! ---- Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 18 5:10:38 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 2BAD537B402; Fri, 18 Jan 2002 05:10:33 -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 AAA10281; Sat, 19 Jan 2002 00:10:27 +1100 Date: Sat, 19 Jan 2002 00:11:46 +1100 (EST) From: Bruce Evans X-X-Sender: To: Michael Reifenberger Cc: FreeBSD-Current , Subject: Re: panic during fdisk'ing a md(4) device In-Reply-To: <20020118134228.D499-100000@nihil> Message-ID: <20020119000938.L1062-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 Fri, 18 Jan 2002, Michael Reifenberger wrote: > On Fri, 18 Jan 2002, Bruce Evans wrote: > ... > > devfs still leaks 2 DEVFS allocations and 6 devbuf allocations for every > > iteration of the script. > ... > Does this mean that your latest patch removes the panic but leaks some > resources. No :). It means that I think it is an old leak in devfs. The leak was hard to see before because the system paniced. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 18 16:34:22 2002 Delivered-To: freebsd-current@freebsd.org Received: from ns.plaut.de (ns.plaut.de [194.99.75.166]) by hub.freebsd.org (Postfix) with ESMTP id 7293737B402 for ; Fri, 18 Jan 2002 16:34:16 -0800 (PST) Received: (from uucp@localhost) by ns.plaut.de (8.9.3/8.9.3) with UUCP id BAA40878 for current@freebsd.org; Sat, 19 Jan 2002 01:33:03 +0100 (CET) (envelope-from root@nihil.plaut.de) Received: from localhost (root@localhost) by nihil.plaut.de (8.11.3/8.8.8) with ESMTP id g0J0WeU00496 for ; Sat, 19 Jan 2002 01:32:40 +0100 (CET) (envelope-from root@nihil) Date: Sat, 19 Jan 2002 01:32:40 +0100 (CET) From: Michael Reifenberger To: FreeBSD-Current Subject: next panic with bwrite: buffer not busy??? Message-ID: <20020119013000.X485-100000@nihil> 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, a new one under -current+X11+kde while surfing: 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"... IdlePTD at phsyical address 0x00430000 initial pcb at physical address 0x0029d260 panicstr: bwrite: buffer is not busy??? panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x80 fault code = supervisor write, page not present instruction pointer = 0x8:0xc01abba4 stack pointer = 0x10:0xc963db84 frame pointer = 0x10:0xc963db9c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 27674 (kdeinit) trap number = 12 panic: page fault syncing disks... panic: bwrite: buffer is not busy??? Uptime: 3h45m55s pfs_vncache_unload(): 1 entries remaining dumping to dev ad0s3b, offset 4063232 dump ata0: resetting devices .. done 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 dumpsys () at ../../../kern/kern_shutdown.c:492 492 if (!dodump) (kgdb) #0 dumpsys () at ../../../kern/kern_shutdown.c:492 #1 0xc016dda0 in boot (howto=260) at ../../../kern/kern_shutdown.c:335 #2 0xc016e1ef in panic (fmt=0xc02503d8 "bwrite: buffer is not busy???") at ../../../kern/kern_shutdown.c:634 #3 0xc01a16bf in bwrite (bp=0xc49951e4) at ../../../kern/vfs_bio.c:676 #4 0xc01a1c76 in bawrite (bp=0xc49951e4) at ../../../kern/vfs_bio.c:989 #5 0xc01e88a8 in ffs_fsync (ap=0xc963da40) at ../../../ufs/ffs/ffs_vnops.c:217 #6 0xc01e6f2a in ffs_sync (mp=0xc134f600, waitfor=2, cred=0xc09c7f00, td=0xc02707c4) at vnode_if.h:441 #7 0xc01aeab6 in sync (td=0xc02707c4, uap=0x0) at ../../../kern/vfs_syscalls.c:669 #8 0xc016da01 in boot (howto=256) at ../../../kern/kern_shutdown.c:244 #9 0xc016e1ef in panic (fmt=0xc0263a1e "%s") at ../../../kern/kern_shutdown.c:634 #10 0xc022c034 in trap_fatal (frame=0xc963db44, eva=128) at ../../../i386/i386/trap.c:842 #11 0xc022bd5d in trap_pfault (frame=0xc963db44, usermode=0, eva=128) at ../../../i386/i386/trap.c:756 #12 0xc022b767 in trap (frame={tf_fs = 16777240, tf_es = 1048592, tf_ds = -916914160, tf_edi = -916222972, tf_esi = -916222972, tf_ebp = -916202596, tf_isp = -916202640, tf_ebx = 0, tf_edx = 4, tf_ecx = -916222972, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = -1071989852, tf_cs = 8, tf_eflags = 66178, tf_esp = -1050462704, tf_ss = -916856832}) at ../../../i386/i386/trap.c:426 #13 0xc01abba4 in vput (vp=0x0) at machine/atomic.h:144 #14 0xc144845a in ?? () #15 0xc01abb67 in vrele (vp=0xc959e000) at vnode_if.h:654 #16 0xc01b4ddc in vn_close (vp=0xc959e000, flags=1, cred=0xc14e3000, td=0xc9638c04) at ../../../kern/vfs_vnops.c:260 #17 0xc01b5856 in vn_closefile (fp=0xc1617580, td=0xc9638c04) at ../../../kern/vfs_vnops.c:730 #18 0xc015882a in fdrop_locked (fp=0xc1617580, td=0xc9638c04) at ../../../sys/file.h:229 #19 0xc0157d72 in fdrop (fp=0xc1617580, td=0xc9638c04) at ../../../kern/kern_descrip.c:1465 #20 0xc0157d24 in closef (fp=0xc1617580, td=0xc9638c04) at ../../../kern/kern_descrip.c:1451 #21 0xc015668e in close (td=0xc9638c04, uap=0xc963dd20) at ../../../kern/kern_descrip.c:703 #22 0xc022c4c4 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 954248608, tf_ebp = -1077942072, tf_isp = -916202124, tf_ebx = 954171848, tf_edx = -1077941968, tf_ecx = -1077941816, tf_eax = 6, tf_trapno = 12, tf_err = 2, tf_eip = 953772119, tf_cs = 31, tf_eflags = 643, tf_esp = -1077942116, tf_ss = 47}) at ../../../i386/i386/trap.c:1034 #23 0xc022001d in syscall_with_err_pushed () #24 0x38dd70ec in ?? () #25 0x387eb4c1 in ?? () #26 0x385cdda4 in ?? () #27 0x385be68a in ?? () #28 0x385c2707 in ?? () #29 0x385bfd69 in ?? () #30 0x38654cf6 in ?? () #31 0x385f740e in ?? () #32 0x386063b2 in ?? () #33 0x3864ff52 in ?? () #34 0x38f530d1 in ?? () #35 0x804cb36 in ?? () #36 0x804d7f3 in ?? () #37 0x804dd4c in ?? () #38 0x804eedc in ?? () #39 0x804adf1 in ?? () (kgdb) Bye! ---- Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 19 3:55:18 2002 Delivered-To: freebsd-current@freebsd.org Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by hub.freebsd.org (Postfix) with ESMTP id 5431937B400 for ; Sat, 19 Jan 2002 03:55:14 -0800 (PST) Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout0.freenet.de with esmtp (Exim 3.33 #3) id 16Ru5Y-0007qm-00 for current@freebsd.org; Sat, 19 Jan 2002 12:55:12 +0100 Received: from ae3f6.pppool.de ([213.6.227.246] helo=Magelan.Leidinger.net) by mx1.freenet.de with esmtp (Exim 3.33 #3) id 16Ru5Y-0002zY-00 for current@freebsd.org; Sat, 19 Jan 2002 12:55:12 +0100 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.11.6/8.11.6) with ESMTP id g0JBdne00922 for ; Sat, 19 Jan 2002 12:39:50 +0100 (CET) (envelope-from netchild@Leidinger.net) Message-Id: <200201191139.g0JBdne00922@Magelan.Leidinger.net> Date: Sat, 19 Jan 2002 12:39:48 +0100 (CET) From: Alexander Leidinger Subject: ls -lh: wrong aligning of size filed for symlinks 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 Hi, "ls -lh" does misalign the size field for symlinks (missing space in front of the size), /usr/share/locale: ---snip--- drwxr-xr-x 2 root wheel 512B Jan 12 15:48 tr_TR.ISO8859-9 lrwxr-xr-x 1 root wheel 15B Jan 12 15:43 tr_TR.ISO_8859-9 -> tr_TR.ISO8859-9 drwxr-xr-x 2 root wheel 512B Jan 12 15:48 uk_UA.ISO8859-5 drwxr-xr-x 2 root wheel 512B Jan 12 15:48 uk_UA.KOI8-U lrwxr-xr-x 1 root wheel 11B Jan 12 15:43 zh_CN.EUC -> zh_CN.eucCN drwxr-xr-x 2 root wheel 512B Jan 12 15:48 zh_CN.eucCN drwxr-xr-x 2 root wheel 512B Jan 12 15:48 zh_TW.Big5 ---snip--- Bye, Alexander. -- The three Rs of Microsoft support: Retry, Reboot, Reinstall. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 19 7:50:26 2002 Delivered-To: freebsd-current@freebsd.org Received: from genesis.k.pl (genesis.korbank.pl [195.117.162.253]) by hub.freebsd.org (Postfix) with ESMTP id 78CD137B419 for ; Sat, 19 Jan 2002 07:50:23 -0800 (PST) Received: (from ns88@localhost) by genesis.k.pl (8.11.3/8.11.3) id g0JFlRM93542 for freebsd-current@freebsd.org; Sat, 19 Jan 2002 16:47:27 +0100 (CET) (envelope-from ns88) Date: Sat, 19 Jan 2002 16:47:26 +0100 From: Tomasz Paszkowski To: freebsd-current@freebsd.org Subject: Some dmesg errors Message-ID: <20020119164726.A16687@genesis.k.pl> 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 Hello, I've jest cvsuped to recent current and got some errors in dmesg buffer: 1) 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: Sat Jan 19 15:53:25 GMT 2002 ns88@COcos5.ONLINE.PL:/usr/src/sys/i386/compile/COCOS5 Preloaded elf kernel "/boot/kernel/kernel" at 0xc0358000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc03580a8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 801821689 Hz CPU: Pentium III/Pentium III Xeon/Celeron (801.82-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x387f9ff WARNING: Driver mistake: make_dev(perfmon) called before SI_SUB_DRIVERS 2) microuptime() went backwards (509.4041326 -> 508.388712) microuptime() went backwards (533.4159377 -> 532.512632) -- _ _ _ _ _ / \ | | / / / \ / \ --- Tomasz Paszkowski ------------------------------ | |\ \| | \ \ |/ \||/ \| === IPv4://3646987138 === IPNg://3ffe:8010:88::2 === /_/ \__/ /_/ \_/ \_/ ---------------------------- http://plikoskop.pl --- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 19 8:20: 1 2002 Delivered-To: freebsd-current@freebsd.org Received: from jesus.apogeetelecom.com (jesus.apogeetelecom.com [64.245.60.241]) by hub.freebsd.org (Postfix) with ESMTP id 4A0C837B41A for ; Sat, 19 Jan 2002 08:19:51 -0800 (PST) Received: (from eliedtke@localhost) by jesus.apogeetelecom.com (8.11.6/8.11.6) id g0JGJop67919 for FreeBSD-current@freebsd.org; Sat, 19 Jan 2002 10:19:50 -0600 (CST) (envelope-from eliedtke) Date: Sat, 19 Jan 2002 10:19:50 -0600 From: Eric Liedtke To: FreeBSD-current@freebsd.org Message-ID: <20020119161950.GA67913@apogeetelecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 mymail.txt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 19 11:14:10 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 66A1837B405 for ; Sat, 19 Jan 2002 11:14:05 -0800 (PST) Received: from localhost (localhost [::1]) by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet6 id g0JJE4m00101 for ; Sun, 20 Jan 2002 04:14:04 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) In-Reply-To: <20020114.212602.69432904.imp@village.org> References: <20020114.212602.69432904.imp@village.org> X-User-Agent: Mew/1.94.2 XEmacs/21.5 (alfalfa) 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: 27 From: Makoto Matsushita To: current@FreeBSD.org Subject: Re: sudo redu Date: Sun, 20 Jan 2002 04:13:57 +0900 Message-Id: <20020120041357U.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 FYI: pam_setcred() call seems used in OpenSSH, ftpd, rshd, login, and su already included in FreeBSD source code. imp> OK. This looks like a problem in 1.6.4p1 of sudo. It isn't a problem imp> with 1.6.3p7_2. 1.6.4 works on -stable, but not -current. I've checked about new sudo's behavior on some OSes: Debian (woody) sudo-1.6.4.1 OK (tested on 1 machine) FreeBSD 2.2.8-RELEASE sudo-1.6.5.1 OK (tested on 1 machine) FreeBSD 3.4-stable sudo-1.6.5.1 NG (tested on 1 machine) FreeBSD 4-stable sudo-1.6.5.1 OK (tested on some machines) FreeBSD 5-current sudo-1.6.5.1 OK / NG (tested on some machines) "OK / NG" means that "some machines work fine, but some machines goes wrong". *** I don't know what's the real problem, but it seems that sudo doesn't have the problem IMHO. Anyone has a solution about this problem? -- - 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 Sat Jan 19 14:12:44 2002 Delivered-To: freebsd-current@freebsd.org Received: from ciao.cc.columbia.edu (ciao.cc.columbia.edu [128.59.59.11]) by hub.freebsd.org (Postfix) with ESMTP id A2E0637B400; Sat, 19 Jan 2002 14:12:34 -0800 (PST) Received: from localhost by ciao.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA03536; Sat, 19 Jan 2002 17:12:30 -0500 (EST) Date: Sat, 19 Jan 2002 17:12:29 -0500 (EST) From: Alp Atici To: freebsd-hackers@FreeBSD.ORG, Subject: FreeBSD 5.x In-Reply-To: <20020119132054.F909@gelatinous.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 Is gcc 3.x going to be the default compiler starting from FBSD 5.x series? Is the development on current branch compiled using gcc 3.0 (or up)? Is 5.x series going to be based on a preemptible kernel? Thanks, Alp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 19 15:14:14 2002 Delivered-To: freebsd-current@freebsd.org Received: from espresso.q9media.com (espresso.q9media.com [216.254.138.122]) by hub.freebsd.org (Postfix) with ESMTP id E507137B404 for ; Sat, 19 Jan 2002 15:14:11 -0800 (PST) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g0JNAe396078; Sat, 19 Jan 2002 18:10:40 -0500 (EST) (envelope-from mike) Date: Sat, 19 Jan 2002 18:10:40 -0500 From: Mike Barcroft To: Alp Atici Cc: freebsd-current@FreeBSD.ORG Subject: Re: FreeBSD 5.x Message-ID: <20020119181040.A68881@espresso.q9media.com> References: <20020119132054.F909@gelatinous.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from aa878@columbia.edu on Sat, Jan 19, 2002 at 05:12:29PM -0500 Organization: The FreeBSD Project 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 removed from CC. One list is enough.] Alp Atici writes: > Is gcc 3.x going to be the default compiler starting from > FBSD 5.x series? Is the development on current branch > compiled using gcc 3.0 (or up)? Yes. Not yet. > Is 5.x series going to be based on a preemptible kernel? That's the plan. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 19 16: 0:39 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 94ED337B417 for ; Sat, 19 Jan 2002 16:00:36 -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 BC087206 for ; Sun, 20 Jan 2002 01:00:34 +0100 (CET) Message-Id: <5.0.2.1.0.20020120005621.02190c38@164.8.8.5> X-Sender: rozmanal@164.8.8.5 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 20 Jan 2002 00:58:05 +0100 To: freebsd-current@FreeBSD.ORG From: Aleksander Rozman - Andy Subject: kernel has problems starting 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 have quite a big problem. I made "world" with newest CURRENT. Now I have all binaries 5.0, but I can't get kernel to work. It compiles ok, installs ok, but when I start system it's stops when it tells mounting root on ufs://ad0s1a. (I used GENERIC as well as my own config) I am using VMWare (I need to have FreeBSD on my development machine, but not as main OS). I installed FreeBSD 4.4 and everything worked OK with generic kernel of 4.4, but it doesn't with generic from 5.0 If anybody has any idea why it stops, please do tell me. 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 Sat Jan 19 17: 5:32 2002 Delivered-To: freebsd-current@freebsd.org Received: from philotas.hosting.swbell.net (philotas.hosting.swbell.net [216.100.99.7]) by hub.freebsd.org (Postfix) with ESMTP id 0525F37B402 for ; Sat, 19 Jan 2002 17:05:30 -0800 (PST) Received: from imimic.com (adsl-216-63-78-19.dsl.hstntx.swbell.net [216.63.78.19]) by philotas.hosting.swbell.net id UAA18501; Sat, 19 Jan 2002 20:05:19 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <3C4A1771.26C05F1@imimic.com> Date: Sat, 19 Jan 2002 19:03:45 -0600 From: "Alan L. Cox" Organization: iMimic Networking, Inc. X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: k Macy Cc: Terry Lambert , Julian Elischer , freebsd-current@freebsd.org, Doug White Subject: Re: -CURRENT AIO bug Re: How well does EVFILT_AIO work? References: <20020118012020.97262.qmail@web14008.mail.yahoo.com> Content-Type: text/plain; charset=x-user-defined 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 k Macy wrote: > > It turns that this problem is specific to AIO in > -CURRENT. I wrote a simple program that uses > the three different completion mechanisms (polling > with aio_error, polling with kevent, and using SIGIO) > to fill up a file by writing 8kb at a time to the > file and then reading 8kb at a time from the file. > I believe that I've fixed this problem. Please update to revision 1.112 of kern/vfs_aio.c and retry your tests. Best regards, Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 19 17: 6:55 2002 Delivered-To: freebsd-current@freebsd.org Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by hub.freebsd.org (Postfix) with ESMTP id B462C37B417 for ; Sat, 19 Jan 2002 17:06:34 -0800 (PST) Received: from sdn-ar-006azphoep282.dialsprint.net ([158.252.129.84] helo=nutf) by mclean.mail.mindspring.net with smtp (Exim 3.33 #1) id 16RztK-0007Ey-00; Sat, 19 Jan 2002 13:06:59 -0500 From: TOP-LISTING53x@YAHOO.com To: Subject: Marketing Services Date: Sun, 20 Jan 2002 09:39:13 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_280D_00006E9D.00000BCF" X-Priority: 3 X-MSMail-Priority: Normal 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 ------=_NextPart_000_280D_00006E9D.00000BCF Content-Type: text/html;
WE DELIVER TARGETED UNIQUE SEARCH ENGINE
TRAFFIC TO YOUR WEB SITE

BOTTOM LINE
IF YOUR POTENTIAL CUSTOMERS
CAN'T find YOUR WEB SITE in the first 10
to 20 matches ON A SEARCH ENGINE, YOU
JUST LOST MONEY!
IT'S THAT SIMPLE!

Improving search engine TRAFFIC means:
MORE HITS

MORE BUSINESS

MORE SUCCESS
The most important advertising dollar
spent should be for search engine
TRAFFIC!
1. Approximately 95% of all Internet
users start with a search engine query.


 2. Anyone who comes to your site from a
major search
engine is 100 times more likely to
become a customer
because they were specifically looking
for your product,
goods or services.

 3. Search engine traffic gives you
substantially more
for your advertising dollar than banners
or anything else.
Moreover, having a Banner Ad on a web
site doesn't mean your Ad
was seen or even targeted to your
market.


 Can't Get Your Companies Web Site
Indexed by the Search Engines?


Unfortunately, this is all too common of
a Problem. You're not the only one
frustrated about the length of time it
takes to be listed, or all the pitfalls involved.
It takes anywhere from 2 days to as much
as 3 months to be listed on all the search engines.

WHEN DO YOU SUBMIT?

Engines at any time delay their indexing
for maintenance and many other reasons.


WE Know exactly how each search engine
works, and we know when to submit and what to
submit. Search engines are changing daily and
we study them each day. Your competitors
ARE @ the mercy of OUR Marketing Departments.
Over 6 Years in the search engine wars
and We have Masters words like:
MP3 - BOOKS - WEB SITE HOSTING - MARKETING -
- FREE WEB SITES - CASINO - - CASINO REVIEWS -
BALLS - LOGOS - ART - ATTORNEY'S - NEW CAR PARTS -
OLD CAR PART - - NETWORK MARKETING - WATER FILTERS -
- SCALES - AND THE LIST GOES ON - -

If you've submitted your site and come
to find no listing,

what do you do now?
Contact:

THE CYBER TRAFFIC TECHNICIANS.


You need US in your corner, WE will
take CONTROL of the submission cycle of your
domain.

The cost is 348 US Dollars for 12 months
of service.

This Price is good for this month only
and with this order we give you a free
Consultation after 100 days to improve
your listings(a $375.00 value). We only
offer this to our clients when they order
the 12 month search engine submission
service. The free Consultation is to make
the necessary changes to improve your
listing and move you to the top of each
Search Engine.

When you start our service we do not
make any changes to your web site and
after 100 days we only make suggestions
that WILL improve your search engine placement.


DON'T delay act NOW, Today!!!

People are looking for your company
right now!!!


WE WILL PUT YOUR WEB SITE IN FRONT OF
THEM!!
More Search Engines = More Traffic!

WE increase your site's exposure and get
your domain more traffic!

WE submit your domain to 69 (sixty-nine)
search engines!

 It's simple - WE get you indexed on more
search engines and
Drive more traffic to your domain!

We compiled a list of the major
international and domestic search engines!

This is your opportunity to increase
your domain's traffic,
Quickly!

WE update (submit) your domain weekly or
as needed plus, WE provide you with a monthly
report (by request only!)

Here's the complete list:
 AltaVista
HotBot
InfoSeek/Go Network (Web Results)
InfoSeek/Go Network (Proven Picks)
AOL Search
Direct Hit
Excite
Fast/All The Web
Google
Goto.com
IWon
Lycos
MSN
NBCi (Formerly Snap)
Netscape
Open Directory
WebCrawler
Yahoo
Plus
Acoon (Germany)
Aeiwi (USA)
AltaVista (France)
AltaVista (Germany)
AltaVista (Itlay)
AltaVista (Switzerland)
Blitz (Germany)
Excite (Australia)
Excite (France)
Excite (Italy)
Excite (UK)
FindOnce (UK)
Free (France)
FrequentFinders (USA)
GoEureka (Australia)
Indibil (Spain)
InfoMak (USA)
Infoseek (Germany)
InfoTiger (USA)
Lokace (France)
Lycos (Chile)
Lycos (Columbia)
Lycos (France)
Lycos (German)
Lycos (Italian)
Lycos (Japan)
Lycos (Peru)
Lycos (Spain)
Lycos (Sweden)
Lycos (UK)
MaxiSearch (Germany)
Origo (Norway)
QuestFinder (USA)
SearchEngine (UK)
Sharelook (Italy)
ShinySeek (Italy)
Speedfind (Germany)
SplatSearch (USA)
Spray (France)
SunSteam (Norway)
SuperSnooper (USA)
Superva (Italian)
Sympatico (Canadian)
UK Max (UK)
Unearth (New Zealand)
Voila (France)
Voila (Spain)
Walhello (USA)
WebSearch (Australia)
WebWombat (Australia)
Yagua (Paraguay)
It's easy!!
Just fax or mail the following to:
 FAX: 1-(602) 392-8288.

 US MAIL:
 CyberCO
8190 W Deer Valley Road Suite 104-265
Peoria, AZ 85382
WE WILL CONTACT YOU IN 2 BUSINESS DAYS
AND WE DO NOT START THE WORK UNTIL
WE SPEAK WITH YOU!!


-- Order Form --

PAYMENT TYPES:

CHECK - CREDIT CARD - MONEY ORDER

All orders must be completely filled
out!

Company Name:

Address:

State: City:
Zip:

Contact Name:

Contact Telephonel:

Contact Fax:

Contact E-mail Address:

Web site Address:


A few of your top Keywords:

Questions:

Credit Card #.

Name On Card.

Sign Here:__________________________________

Date:_____________

--*** NOTE ***--
348.00 US Dollars WILL COVER 12 MONTHS
OF SERVICE.























--------------------------------------
--------------------------------------
To be removed from future mailings!!!!
All REMOVE requests AUTOMATICALLY
honored upon receipt.
href="mailto:sendhere11@excite.com?subject=NOBIZ"mail
to:
sendhere11@excite.com?subject=NOBIZ
PLEASE understand that any effort to disrupt, close or block
this REMOVE account can only result in difficulties for others
wanting to be removed from our mailing list as it will be impossible
to take anyone off the list if the remove instruction is not received.


----------------------------------------
----------------------------------




 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 19 18:39:18 2002 Delivered-To: freebsd-current@freebsd.org Received: from web14007.mail.yahoo.com (web14007.mail.yahoo.com [216.136.175.123]) by hub.freebsd.org (Postfix) with SMTP id 35ECC37B405 for ; Sat, 19 Jan 2002 18:39:03 -0800 (PST) Message-ID: <20020120023902.23973.qmail@web14007.mail.yahoo.com> Received: from [216.103.213.142] by web14007.mail.yahoo.com via HTTP; Sat, 19 Jan 2002 18:39:02 PST Date: Sat, 19 Jan 2002 18:39:02 -0800 (PST) From: k Macy Subject: profiled kernel build fails was Re: -CURRENT AIO bug To: "Alan L. Cox" Cc: freebsd-current@freebsd.org In-Reply-To: <3C4A1771.26C05F1@imimic.com> 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 Thanks for working on this. I was going to try running a profiled kernel on -CURRENT and -STABLE to see what the difference was in time distribution. On -STABLE it built without a hitch. However, on -CURRENT I got the following even after doing a make clean: ../../../libkern/mcount.c: In function `mcount': ../../../libkern/mcount.c:91: `mcount_lock' undeclared (first use in this function) ../../../libkern/mcount.c:91: (Each undeclared identifier is reported only once ../../../libkern/mcount.c:91: for each function it appears in.) machine/atomic.h:141: warning: inlining failed in call to `atomic_cmpset_int' ../../../libkern/mcount.c:91: warning: called from here machine/atomic.h:234: warning: inlining failed in call to `atomic_store_rel_int' ../../../libkern/mcount.c:242: warning: called from here ../../../libkern/mcount.c: In function `mcount': ../../../libkern/mcount.c:91: `mcount_lock' undeclared (first use in this function) ../../../libkern/mcount.c:91: (Each undeclared identifier is reported only once ../../../libkern/mcount.c:91: for each function it appears in.) machine/atomic.h:141: warning: inlining failed in call to `atomic_cmpset_int' ../../../libkern/mcount.c:91: warning: called from here machine/atomic.h:234: warning: inlining failed in call to `atomic_store_rel_int' ../../../libkern/mcount.c:242: warning: called from here --- "Alan L. Cox" wrote: > k Macy wrote: > > > > It turns that this problem is specific to AIO in > > -CURRENT. I wrote a simple program that uses > > the three different completion mechanisms (polling > > with aio_error, polling with kevent, and using > SIGIO) > > to fill up a file by writing 8kb at a time to the > > file and then reading 8kb at a time from the file. > > > > I believe that I've fixed this problem. Please > update to revision 1.112 > of kern/vfs_aio.c and retry your tests. > > Best regards, > Alan __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 19 18:47:39 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 5703837B41D; Sat, 19 Jan 2002 18:47:29 -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 g0K2lED47539; Sat, 19 Jan 2002 21:47:18 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 19 Jan 2002 21:47:14 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Alp Atici Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: FreeBSD 5.x 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 Sat, 19 Jan 2002, Alp Atici wrote: > Is gcc 3.x going to be the default compiler starting from FBSD 5.x > series? Is the development on current branch compiled using gcc 3.0 (or > up)? > > Is 5.x series going to be based on a preemptible kernel? Can't answer the gcc question, but yes, John Baldwin currently has support for preemption in his SMPng development tree. 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 Sat Jan 19 21:22: 1 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 E788937B405; Sat, 19 Jan 2002 21:21:55 -0800 (PST) Received: from pool0141.cvx21-bradley.dialup.earthlink.net ([209.179.192.141] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16SAQT-0005eJ-00; Sat, 19 Jan 2002 21:21:54 -0800 Message-ID: <3C4A53EE.B882356C@mindspring.com> Date: Sat, 19 Jan 2002 21:21:50 -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: Alp Atici Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: FreeBSD 5.x 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 Alp Atici wrote: > Is gcc 3.x going to be the default compiler starting from > FBSD 5.x series? Is the development on current branch > compiled using gcc 3.0 (or up)? I think that the cut over will happen after the compiler no longer core dumps on: main() { int i; i = foo(); switch( i) { default: printf( "hello, stupid compiler!\n"); break; } } int foo() { return( 6); } > Is 5.x series going to be based on a preemptible kernel? A multithreaded kernel. Do ISRs count? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 19 21:32:23 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 62A6137B402 for ; Sat, 19 Jan 2002 21:32:21 -0800 (PST) Received: from pool0141.cvx21-bradley.dialup.earthlink.net ([209.179.192.141] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16SAaZ-0005h2-00; Sat, 19 Jan 2002 21:32:19 -0800 Message-ID: <3C4A5660.20E6E6D8@mindspring.com> Date: Sat, 19 Jan 2002 21:32:16 -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: Aleksander Rozman - Andy Cc: freebsd-current@FreeBSD.ORG Subject: Re: kernel has problems starting References: <5.0.2.1.0.20020120005621.02190c38@164.8.8.5> 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 Aleksander Rozman - Andy wrote: > I have quite a big problem. I made "world" with newest CURRENT. Now I have > all binaries 5.0, but I can't get kernel to work. It compiles ok, installs > ok, but when I start system it's stops when it tells mounting root on > ufs://ad0s1a. (I used GENERIC as well as my own config) > I am using VMWare (I need to have FreeBSD on my development machine, but > not as main OS). I installed FreeBSD 4.4 and everything worked OK with > generic kernel of 4.4, but it doesn't with generic from 5.0 > > If anybody has any idea why it stops, please do tell me. Update your bootblocks. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 19 21:36:38 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 225E637B41D for ; Sat, 19 Jan 2002 21:36:34 -0800 (PST) Received: (from dan@localhost) by dan.emsphone.com (8.11.6/8.11.6) id g0K5aTs82218; Sat, 19 Jan 2002 23:36:29 -0600 (CST) (envelope-from dan) Date: Sat, 19 Jan 2002 23:36:29 -0600 From: Dan Nelson To: Terry Lambert Cc: Alp Atici , freebsd-current@FreeBSD.ORG Subject: Re: FreeBSD 5.x Message-ID: <20020120053629.GE81627@dan.emsphone.com> References: <3C4A53EE.B882356C@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C4A53EE.B882356C@mindspring.com> User-Agent: Mutt/1.3.25i 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 (Jan 19), Terry Lambert said: > Alp Atici wrote: > > Is gcc 3.x going to be the default compiler starting from FBSD 5.x > > series? Is the development on current branch compiled using gcc 3.0 > > (or up)? > > I think that the cut over will happen after the compiler > no longer core dumps on: > > main() > { > int i; > > i = foo(); > > switch( i) { > default: > printf( "hello, stupid compiler!\n"); > break; > } > } > > int > foo() > { > return( 6); > } Doesn't core on me (gcc30+bounds-checking port, FreeBSD-current). In fact, I've got USE_GCC30 in my make.conf and build all my ports with it (at least the ports that aren't broken and hardcode cc or gcc). -- 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 Sat Jan 19 22: 5:52 2002 Delivered-To: freebsd-current@freebsd.org Received: from espresso.q9media.com (espresso.q9media.com [216.254.138.122]) by hub.freebsd.org (Postfix) with ESMTP id BB2D437B400 for ; Sat, 19 Jan 2002 22:05:47 -0800 (PST) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g0K62TS98671; Sun, 20 Jan 2002 01:02:29 -0500 (EST) (envelope-from mike) Date: Sun, 20 Jan 2002 01:02:28 -0500 From: Mike Barcroft To: Dan Nelson Cc: Terry Lambert , Alp Atici , freebsd-current@FreeBSD.ORG Subject: Re: FreeBSD 5.x Message-ID: <20020120010228.C68881@espresso.q9media.com> References: <3C4A53EE.B882356C@mindspring.com> <20020120053629.GE81627@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020120053629.GE81627@dan.emsphone.com>; from dnelson@allantgroup.com on Sat, Jan 19, 2002 at 11:36:29PM -0600 Organization: The FreeBSD Project 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 Dan Nelson writes: > In the last episode (Jan 19), Terry Lambert said: > > Alp Atici wrote: > > > Is gcc 3.x going to be the default compiler starting from FBSD 5.x > > > series? Is the development on current branch compiled using gcc 3.0 > > > (or up)? > > > > I think that the cut over will happen after the compiler > > no longer core dumps on: > > > > main() > > { > > int i; > > > > i = foo(); > > > > switch( i) { > > default: > > printf( "hello, stupid compiler!\n"); > > break; > > } > > } > > > > int > > foo() > > { > > return( 6); > > } > > Doesn't core on me (gcc30+bounds-checking port, FreeBSD-current). In > fact, I've got USE_GCC30 in my make.conf and build all my ports with it > (at least the ports that aren't broken and hardcode cc or gcc). Interesting. The sparc64 toolchain suffers from this problem, so a number of files on the sparc64 p4 branch have custom versions. Anyway, I'm told this problem has been fixed in 3.1, which is the planned version of GCC for 5.0-RELEASE. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 19 22:23:32 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 4165C37B404 for ; Sat, 19 Jan 2002 22:23:27 -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 RAA22564; Sun, 20 Jan 2002 17:23:13 +1100 Date: Sun, 20 Jan 2002 17:24:39 +1100 (EST) From: Bruce Evans X-X-Sender: To: k Macy Cc: "Alan L. Cox" , Subject: Re: profiled kernel build fails was Re: -CURRENT AIO bug In-Reply-To: <20020120023902.23973.qmail@web14007.mail.yahoo.com> Message-ID: <20020120164213.L7131-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 Sat, 19 Jan 2002, k Macy wrote: > Thanks for working on this. I was going to try running > a profiled kernel on -CURRENT and -STABLE to see what > the difference was in time distribution. On -STABLE > it built without a hitch. However, on -CURRENT I got > the following even after doing a make clean: > > ../../../libkern/mcount.c: In function `mcount': > ../../../libkern/mcount.c:91: `mcount_lock' undeclared > (first use in this function) The mcount_lock stuff apparently never even compiled. It is only used for the !GUPROF && SMP case, but it cannot work in that case since mcount_lock is not declared. Unfortunately, LINT only tests the GUPROF case, which compiles but is even more broken at runtime in the SMP case. GUPROF worse fine in the !SMP case and should be non-optional (it gives about 100000 times as much resolution as PROF on current machines, instead of only 1000 times as much as on 486's when it was written). This fix has not been tested. It has some chance of working, because RELENG_4 uses similar code. However, it is certainly broken if the atomic functions that it calls are not inlined (then the functions will call MCOUNT_ENTER() on entry). I think this only happens if mcount.c is compiled with -O0. This bug is missing in RELENG_4 too. %%% Index: profile.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/profile.h,v retrieving revision 1.25 diff -u -2 -r1.25 profile.h --- profile.h 30 Oct 2001 15:04:57 -0000 1.25 +++ profile.h 20 Jan 2002 06:05:24 -0000 @@ -65,4 +65,5 @@ #define MCOUNT_DECL(s) u_long s; #ifdef SMP +extern int mcount_lock; #define MCOUNT_ENTER(s) { s = read_eflags(); disable_intr(); \ while (!atomic_cmpset_acq_int(&mcount_lock, 0, 1)) \ %%% Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message